Methods and systems for managing initial access and contention based data transmission

By employing contention-based preconfigured grants for data transmission without random access preambles and responses, the solution addresses the inefficiencies in EDT procedures, enhancing capacity and reducing latency and battery consumption in 5G and LTE systems, including NTN networks.

WO2026015278A1PCT designated stage Publication Date: 2026-01-15GOOGLE LLC
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
PCT/US2025/034924
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2024-07-12
Filing Date
2025-06-24
Publication Date
2026-01-15

AI Technical Summary

Technical Problem

Existing 5G and LTE communication systems, including non-terrestrial networks (NTNs), face challenges in reducing uplink and downlink signaling overhead during Early Data Transmission (EDT) procedures, particularly for Narrowband Internet-of-Things (NB-IoT) and enhanced Machine Type Communication (eMTC) devices, which are often deployed in remote areas with limited terrestrial connectivity, as they rely on conventional random access procedures that increase latency and battery consumption.

Method used

Implementing contention-based preconfigured grants that allow data transmission without the need for a random access preamble and response, optimizing the initial access and data transmission process by utilizing preconfigured uplink resources, thereby reducing the number of messages required in the RA procedure.

Benefits of technology

This approach enhances data transmission capacity, reduces latency, and improves battery life in user equipment by minimizing unnecessary signaling, thus optimizing network performance in NTN and terrestrial networks.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure US2025034924_15012026_PF_FP_ABST
    Figure US2025034924_15012026_PF_FP_ABST
Patent Text Reader

Abstract

Devices and methods for managing initial access and data transmission in contention based random access procedure use a contention-based (CB) preconfigured grant configuration received from a radio access network (RAN) node within a system information block. A user equipment (UE) receives (504) the CB preconfigured grant configuration from the RAN node and transmits (508), to the RAN node, a CB physical uplink shared channel (PUSCH) transmission including a radio resource control (RRC) connection request message. The RAN node transmits to the UE an RRC connection setup message in response to the RRC connection request message to establish the connection between the RAN node and the UE.
Need to check novelty before this filing date? Find Prior Art

Description

METHODS AND SYSTEMS FOR MANAGING INITIAL ACCESS AND CONTENTIONBASED DATA TRANSMISSIONFIELD OF THE DISCLOSURE

[0001] This disclosure generally describes methods and devices operating in a wireless communication system (such as but not limited to the ones described in 5G standard documents, known as 3GPP communication systems), and particularly to managing initial access and data transmission between a user equipment and a base station, without exchanging a random access preamble and a random access response.BACKGROUND

[0002] This background description is provided for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0003] The 5G technology builds upon the framework developed for Long Term Evolution (LTE) terrestrial networks (TNs). However, 5G (as well as LTE) systems now extend to communications employing non-terrestrial networks (NTNs) tailored for the Narrowband Intemet-of-Thing (NB-IoT) or the enhanced Machine Type Communication (eMTC) scenarios. In an NTN, a radio frequency (RF) transceiver is mounted on a satellite or an uncrewed aircraft system (UAS) (e.g., a drone, a balloon, a plane, etc.). For simplicity, the discussion below refers to all flying apparatuses with an RF transceiver used for intermediating wireless communications as satellites. In addition to satellites, an NTN typically includes a satellite gateway (simply referred to as “sat-gateway” or sometimes as “NTN gateway”) that bridges NTN’s access to a public data network, feeder links between sat-gateways and satellites, service links from the satellite to user equipment (i.e., terminal devices that may be mobile), and inter-satellite links (ISL) between satellites when the satellite is part of a satellite constellation.

[0004] A satellite may belong to one of several types based on altitude, orbit, beam footprint size, and beam footprint movement. The types include Low-Earth Orbit (LEO) satellite, Medium-Earth Orbit (MEO) satellite, Geostationary Earth Orbit (GEO) satellite, UAS platform (including High Altitude Platform Station (HAPS)), and High Elliptical Orbit (HEO) satellite. The GEO satellites are also known as the Geosynchronous Orbit (GSO) satellites, and LEO / MEO satellites are also known as non-GSO (NGSO) satellites. A GSO satellite communicates with one or more sat-gateways, deployed over a satellite targeted coverage area (e.g., a region, country, continent, etc.). A non-GSO satellite, at different times, communicates with one or several serving sat-gateways. An NTN may be designed to provide service and feeder links continuity between successive serving sat-gateways, with sufficient time overlap to proceed with mobility anchoring and hand-over procedures.

[0005] A satellite may support a transparent payload or a regenerative (with on-board processing) payload, and typically generate several beams for a given service area bounded by its field of view. The footprints of the beams typically have an elliptic shape and depend on the onboard antenna configuration and the satellite’s elevation angle. For a transparent payload, a satellite applies RF filtering and / or frequency conversion and amplification but refrains from changing the waveform signal. For a regenerative payload, a satellite applies RF filtering, frequency conversion and amplification, demodulation and decoding, routing, and / or coding / modulation. The regenerative payload approach is effectively equivalent to the satellite performing most of the functions of a base station (BS), e.g., that is, a 5G Next Generation base station (gNB), or an LTE base station (eNB).

[0006] The NB-IoTs and the eMTC devices are expected to be particularly suitable for operating in remote areas with limited or no terrestrial connectivity. The NB-IoT devices are used in a variety of industries including, for example: (a) transportation (maritime, road, rail, air) and logistics, (b) solar, oil, and gas harvesting, (c) utilities, (d) farming, (e) environmental monitoring, and (f) mining. These industries deploy satellites to enable connectivity beyond terrestrial coverage. Satellite deployment for NB-IoT or eMTC devices is complementary to terrestrial deployments.

[0007] Technical features related to NTNs were included in 3GPP Release 17, but since then, they have been optimized in Release 18 and commercial deployments are ongoing. Based on real deployment or deployment plans, 3GPP has identified further aspects of NTNs that need to be addressed. For example, because in NTN for NB-IoT, the uplink (UL) capacity is tightly coupled to the downlink (DL) control signaling capacity, one objective of Release 19 is to improve Early Data Transmission (EDT). EDT allows a terminal device to transmit data during a Random Access (RA) procedure. The RA procedure conventionally includes four messages: first, the terminal device transmits an RA preamble (msgl) to the network, then the network replies with a random access response (RAR) (msg2), followed by the terminal device transmitting payload data (msg3), and finally, the network releases the connection (msg4). Reducing the UL and DL signaling for completing the EDT in a contention-based (CB) data transmission could enhance capacity for data transmission network, reduce latency, and improve UE’s battery lifetime.

[0008] The traditional communication systems and associated methods do not provide for using radio resource control (RRC) connection establishment, resume, and reestablishment procedures with a Message 3 (Msg3), without a random access preamble and a random access response between a user equipment (UE) and a radio access network (RAN) node.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate one or more embodiments and, together with the description, explain these embodiments.

[0010] FIG. l is a block diagram of an example wireless communication system in which a UE and a BS of this disclosure implement an RA procedure without a random access preamble and without a random access response.

[0011] FIG. 2A is a block diagram of an example protocol stack according to which the UE of FIG. 1 communicates with BSs.

[0012] FIG. 2B is a block diagram of another example protocol stack according to which the UE of FIG. 1 communicates with BSs.

[0013] FIG. 3A is a block diagram of an example NTN node with transparent payload, in which a BS is on the ground and connects to a satellite via a sat-gateway.

[0014] FIG. 3B is a block diagram of an example NTN node with regenerative payload, in which a BS is located on a satellite.

[0015] FIGs. 4A to 4C are signal diagrams of random access methods performed by a UE without a random access preamble and without a random access response, according to embodiments.

[0016] FIG. 5 is a flow chart of a random access method performed by a UE, based on a CB preconfigured grant configuration, for an RRC connection request, according to an embodiment.

[0017] FIG. 6 is a flow chart of a random access method performed by a UE, based on a CB preconfigured grant configuration, for an RRC resume request, according to an embodiment.

[0018] FIG. 7 is a flow chart of a random access method performed by a UE, based on a CB preconfigured grant configuration, for an RRC reestablishment request, according to an embodiment.

[0019] FIG. 8A is a flow chart of a random access method performed by a UE, based on a CB preconfigured grant configuration and a RACH configuration, for a given cause, according to an embodiment.

[0020] FIGs. 8B and 8C are flow charts of a random access method performed by a UE, based on a CB preconfigured grant configuration and a RACH configuration, for an RRC reestablishment request, according to an embodiment.

[0021] FIG. 8D is a flow chart of a random access method performed by a UE, based on a CB preconfigured grant configuration and a RACH configuration, for an RRC early data request, according to an embodiment.

[0022] FIG. 9 is a flow chart of a random access method performed by a UE, based on a CB preconfigured grant configuration and a RACH configuration, for a transport block, according to an embodiment.

[0023] FIG. 10 is a flow chart of a random access method performed by a UE, based on a CB preconfigured grant configuration and a RACH configuration, uplink data and MAC control element, according to an embodiment.

[0024] FIG. 11 is a flow chart of a random access method performed by a BS, based on a CB preconfigured grant configuration, for an RRC connection request, according to an embodiment.

[0025] FIG. 12 is a flow chart of a random access method performed by a BS, based on a CB preconfigured grant configuration, for an RRC resume request, according to an embodiment.

[0026] FIG. 13 is a flow chart of a random access method performed by a BS, based on a CB preconfigured grant configuration, for an RRC reestablishment request, according to an embodiment.

[0027] FIG. 14 is a flow chart of a random access method performed by a UE, based on a CB preconfigured grant configuration and a RACH configuration, for early data transmission, according to an embodiment.

[0028] FIG. 15 is a flow chart of a random access method performed by a BS, based on a CB preconfigured grant configuration and a RACH configuration, for uplink data, according to an embodiment.

[0029] FIG. 16 is a frequency -time diagram of plural CB and non-CB occasions separated by guard times, with the CB occasions being longer than the non-CB occasions according to an embodiment.

[0030] FIG. 17 is a frequency -time diagram of plural CB and non-CB occasions separated by guard times, with the CB occasions being shorter than the non-CB occasions according to an embodiment.DETAILED DESCRIPTION OF THE DRAWINGS

[0031] Methods and devices described in this section embody techniques related to managing initial access methods using RRC request messages and data transmission on physical uplink shared channel (PUSCH) occasions without random access preamble and without random access response. To enhance capacity for data transmission, a CB preconfigured grant reduces the UL and DL signaling for completing an EDT by, for example: transmitting msg3 of the RA procedure without msgl and / or msg2 (RAR), and / or efficient delivery (reduced overhead of msg4 (e.g., RRCEarlyDataComplete). One aspect addressed in the following embodiments ismanaging the initial access and data transmission in an NTN network. The concepts discussed in this document equally apply to TN networks.

[0032] The embodiment descriptions in this section refer to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. The detailed descriptions do not preclude other embodiments within the scope of the appended claims. The embodiments are not limited to the described configurations but may be extended to other arrangements.

[0033] Reference throughout this section to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout the specification are not necessarily all referring to the same embodiment. Further, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments.

[0034] As discussed in more detail below, a UE and / or a network node (e.g., BS or a component of the BS) of a RAN may use the techniques of this disclosure for managing initial access to the RAN. Referring to FIG. 1, an example wireless communication system 100 includes a UE 102, a first BS 104, a second BS 106, and a core network (CN) 110. The BSs 104 and 106 (also called RAN nodes) may operate in a RAN 105 connected to the CN 110 and other BS components, such as satellites, as will be described with reference to FIGs. 3A and 3B below. The CN 110 may be implemented as an evolved packet core (EPC) 111 or a fifth generation (5G) core (5GC) 160, for example. The CN 110 can also be implemented as a sixth generation (6G) core and future evolutions.

[0035] The BS 104 covers at least a cell 124, and the BS 106 covers at least a cell 126. If the BS 104 is a gNB, the cell 124 is an NR cell. If the BS 104 is an ng-eNB or eNB, the cell 124 is an evolved universal terrestrial radio access (E-UTRA) cell. Similarly, if the BS 106 is a gNB, the cell 126 is an NR cell, and if the BS 106 is an ng-eNB or eNB, the cell 126 is an E-UTRA cell. Cells 124 and 126 may be in the same Radio Access Network Notification Areas (RNA) or different RNAs. In general, the RAN 105 can include any number of terrestrial and nonterrestrial nodes or BSs, and each of the BSs can cover one, two, three, or any other suitablenumber of cells. In the following, a “RAN node” is interchangeably used with the BS, or a part of the BS, for example, a distributed unit (DU), or a central unit (CU), or a cell. The UE 102 may support at least a 5G NR (or simply, “NR”) or E-UTRA air interface to communicate with the BSs 104 and 106. Each of the BSs 104, 106 connects to the CN 110 via an interface (e.g., SI or NG interface). The BSs 104 and 106 also can be interconnected via an interface (e.g., X2 or Xn interface) for interconnecting NG RAN nodes.

[0036] Among other components, the EPC 111 may include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116. The SGW 112 in general is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW 116 provides connectivity from the UE to one or more external packet data networks, e.g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC 160 includes a User Plane Function (UPF) 162 and an Access and Mobility Management Function (AMF) 164, and / or Session Management Function (SMF) 166. Generally speaking, the UPF 162 is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., the AMF 164 is configured to manage authentication, registration, paging, and other related functions, and the SMF 166 is configured to manage packet data unit (PDU) sessions.

[0037] As illustrated in FIG. 1, the BS 104 supports a cell 124, and the BS 106 supports a cell 126. Cells 124 and 126 may partially overlap, so that the UE 102 can select, reselect, or hand over from one of the cells 124 and 126 to the other. To directly exchange messages or information, the BS 104 and BS 106 can support an X2 or Xn interface. In general, the CN 110 may connect to any suitable number of terrestrial and / or non-terrestrial BSs supporting NR cells and / or EUTRA cells.

[0038] As discussed in detail below, the UE 102 and / or the RAN 105 or BS 104 / 106 may utilize the techniques of this disclosure when the radio connection between the UE 102 and the RAN 105 is suspended, e.g., when the UE 102 operates in an inactive or idle state of the protocol for controlling radio resources between the UE 102 and the RAN 105. For clarity, the examplesbelow refer to the RRC INACTIVE or RRC IDLE state of the radio resource control (RRC) protocol.

[0039] The BS 104 is equipped with a transceiver and processing hardware 130 that can include one or more general-purpose processors (e.g., CPUs) and a non-transitory computer- readable memory 131 storing instructions that the one or more general-purpose processors execute. Additionally, or alternatively, the processing hardware 130 can include special-purpose processing units. The processing hardware 130 in an example embodiment includes a processor 132 to process data that the BS 104 will transmit in the downlink direction, or process data received by the BS 104 in the uplink direction. The processing hardware 130 can also include a transmitter 136 configured to transmit data in the downlink direction. The processing hardware further may include a receiver 134 configured to receive data in the uplink direction. The BS 106 can include generally similar components. In particular, components 140, 142, 144, and 146 of the BS 106 may be similar to the components 130, 132, 134, and 136, respectively.

[0040] The UE 102 is equipped with a transceiver and processing hardware 150 that may include one or more general-purpose processors such as CPUs and non-transitory computer- readable memory 151 storing machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. The processing hardware 150 in an example embodiment includes a processor 152 to process data that the UE 102 will transmit in the uplink direction, or process data received by UE 102 in the downlink direction. The processing hardware 150 can also include a transmitter 156 configured to transmit data in the downlink direction. The processing hardware may further include a receiver 154 configured to receive data in the uplink direction.

[0041] FIG. 2A illustrates, in a simplified manner, an example protocol stack 200A according to which the UE 102 can communicate with an eNB / ng-eNB or a gNB 201 (e.g., one or more of the BSs 104, 106). In the example stack 200A, a physical (PHY) layer 202 provides transport channels to a medium access control (MAC) sublayer 204, which in turn provides logical channels to an RLC sublayer 206. RLC sublayer 206 in turn provides RLC channels to a PDCP sublayer 208. PDCP sublayer 208 in turn can provide data transfer services to a radio resource control (RRC) sublayer 210, an Internet Protocol (IP) layer and / or a Service Data AdaptationProtocol (SDAP) sublayer (not shown in FIG. 2A). The PDCP sublayer 208 receives packets (e g., from the RRC sublayer 210, the SDAP sublayer, or the IP layer, layered directly or indirectly over the PDCP layer 208) that can be referred to as service data units (SDUs), and output packets (e.g., to the RLC layer 206) that can be referred to as protocol data units (PDUs). Except where the difference between SDUs and PDUs is relevant, this disclosure for simplicity refers to both SDUs and PDUs as “packets”. In some embodiments, the PHY layer 202, MAC sublayer 204, RLC sublayer 206, PDCP sublayer 208, RRC sublayer 210 are EUTRA layers or sublayers. In other embodiments, the PHY layer 202, MAC sublayer 204, RLC sublayer 206, PDCP sublayer 208, RRC sublayer 210 are NR layers or sublayers.

[0042] The RRC sublayer 210 provides data transfer services to a Non-Access-Stratum (NAS) layer 212. The NAS layer 212 includes a mobility management (MM) sublayer and / or a session management (SM) sublayer. In some embodiments, the MM sublayer is an EPS MM (EMM) sublayer. In other embodiments, the MM sublayer is a 5G MM (5GMM) sublayer. In some embodiments, the SM sublayer is an EPS SM (ESM) sublayer. In other embodiments, the SM sublayer is a 5G SM (5GSM) sublayer. When the BS (gNB or eNB 104 / 106) receives UL NAS PDUs from the UE 102, the BS forwards the UL NAS PDUs to the CN 110 without processing the UL NAS PDUs. When the BS receives DL NAS PDUs from the CN 110, the BS forwards the DL NAS PDUs to the UE 102 without processing the DL NAS PDUs. That is, the BS is transparent to the NAS layer 212.

[0043] On a control plane, the PDCP sublayer 208 can provide signaling radio bearers (SRBs) to the RRC sublayer 210 to exchange RRC messages or NAS messages (e g., MM messages and / or SM messages), for example. On a user plane, the PDCP sublayer 208 can provide Data Radio Bearers (DRBs) to support user plane data exchange. User plane data exchanged on the PDCP sublayer 208 can be SDAP PDUs, Internet Protocol (IP) packets or Ethernet packets.

[0044] FIG. 2B illustrates an example protocol stack 200B similar to the protocol state 200A, except that the BS is not transparent to the NAS layer 212 (gNB / eNB 104 / 106). When the BS (gNB or eNB 104 / 106) receives a UL NAS PDU from the UE 102, the BS may process the UL NAS PDU and transmits a DL NAS PDU to the UE 102. When the BS receives DL NAS PDUs from the CN 110, the BS may forward the DL NAS PDUs to the UE 102 without processing theDL NAS PDUs. In other words, the BS may be equipped with a portion of functions of the NAS layer 212 (e g., a portion of NAS procedures initiated by the UE or processing UL PDUs).

[0045] FIG. 3A illustrates a certain type of NTN deployment referred to as transparent payload architecture, which involves a satellite gateway 302 and a “transparent” satellite 304 for extending the range of the Uu interface. In one embodiment, the satellite 304 implements a frequency conversion and a Radio Frequency (RF) amplifier in both the uplink and downlink directions. With that being said, the satellite function is similar to that of an analogue RF repeater. As a result, satellite 304 repeats the Uu radio interface from the feeder link (between the NTN gateway and the satellite) to the service link (between the satellite and the UE) in the downlink direction and vice versa in the uplink direction. The Satellite Radio Interface (SRI) on the feeder link is the Uu, and the NTN gateway 302 supports all necessary functions to forward the signal of the Uu interface. The NTN gateway 302 can be placed at the same site as the BS (e g., eNB, gNB) 104 locations or be connected to the BS 104 at a distance via a wired link. It is also possible to connect more than one NTN gateway to a BS. Different transparent satellites may be connected to the same BS on the ground, via the same NTN gateway, or via different NTN gateways.

[0046] FIG. 3B illustrates a certain type of NTN deployment 300B referred to as regenerative payload architecture, which involves the UE 102, the satellite gateway 302, a satellite 304, and the BS 104 on the satellite 304. Satellite 304 implements a Radio Frequency (RF) filtering, an RF amplifier, and a frequency conversion in both the uplink and / or downlink directions. As a result, the BS 104 communicates with the UE 102 via the satellite 304 and the Uu radio interface in the downlink direction and vice versa in the uplink direction. The BS 104 communicates with the CN 110 via a feeder link (between the NTN gateway 302 and the satellite 304) and a link between the NTN gateway 302 and the CN 110. The NTN gateway 302 can be placed at the same site as the CN 114 location or be connected to the CN 110 at a distance via a wired link or a wireless link.

[0047] In the following scenarios, the BS 104 operating in the system of FIG. 1 communicates with the UE 102 and the CN 110 via the satellite 304 as shown in FIGs. 3 A and 3B. The BS 104 may be located either on the ground, as in FIG. 3A or mounted on the satellite 304, as in FIG.3B. The events in FIGs. 4A-15 that are similar are labeled with similar reference numbers (e.g., event 404 of FIGs. 4A-4C is similar to event 504 of FIGs. 5, 6, and 7, event 804 in FIGs. 8 A to 8D, and event 904 of FIG. 9 and so on), with differences discussed below where appropriate. With the exception of the differences shown in the figures and discussed below, any of the alternative embodiments discussed with respect to a particular event (e.g., for messaging and processing) may apply to events labeled with similar reference numbers in other figures. Note that the descriptions below, although discussed in the context of an NTN network, equally apply to communication between a UE and a BS in a terrestrial network.

[0048] FIG. 4A illustrates a scenario 400 A, in which the BS 104 transmits (e.g., broadcasts) 404 a random access channel (RACH) configuration and a contention-based preconfigured grant configuration to the UE 102 via a cell (e.g., cell 124) and satellite 304. In the following, all the communications between the UE 102 and the BS 104 occur via the cell and the satellite 304. In some embodiments, the BS 104 transmits (e.g., broadcasts) the RACH configuration and the CB preconfigured grant configuration using a system information block (SIB). The SIB may be an SIB1 or another SIB. The BS 104 may transmit (e.g., broadcasts) 404 the RACH configuration and the CB preconfigured grant configuration to the UE using a first SIB and a second SIB, respectively. The first SIB may be an SIB1, and the second SIB may be an SIB other than the SIB1 (e.g., an SIB 19, a SIB31, an SIB 32, or an SIB33). The SIB broadcast discussed with regard to FIG. 4A may be applied to any of the embodiments and / or figures discussed in this document.

[0049] In some embodiments, the RACH configuration includes configuration parameters for UEs to perform an RA procedure with the BS 104 via the satellite 304. In one embodiment, the RACH configuration includes configuration parameters for a four-step RA procedure. In another embodiment, the RACH configuration includes configuration parameters for a two-step RA procedure. For example, the configuration parameters include preamble information, power ramping parameters, random access control information, and / or physical RACH (PRACH) configuration. The preamble information configures a number of random access preambles. The power ramping parameters configure power ramping for transmitting a preamble, the random access control information configures a maximum number of preamble transmissions, a randomaccess response window size, and / or a contention resolution timer value. The PRACH configuration configures a root sequence index and PRACH configuration information.

[0050] The CB preconfigured grant configuration configures UL time and frequency resources on the cell that UEs (e.g., the UE 102) may use to transmit data (e.g., control-plane data and / or user-plane data) without receiving a dynamic UL grant on a physical DL control channel (PDCCH) or in a random access response (RAR). In some embodiments, the UL time and frequency resources include one or more physical UL shared channel (PUSCH) occasions in the time domain and frequency domain. The UL time and frequency resources are shared among UEs. Based on the CB preconfigured grant configuration, the BS 104 attempts to receive or receives one or more UL transmissions on the UL time and frequency resources from one or more UEs. In some embodiments, the CB preconfigured grant configuration does not configure a random access preamble.

[0051] Various possible parts of the CB preconfigured grant configuration (i.e., UL time resources, UL frequency resources, power related parameters, redundancy version for repetitions, orthogonal cover code) are now discussed in more detail.

[0052] The UL frequency resources (i.e., frequencies allowed for UE UL transmission) may be specified in one or more frequency domain configurations. In some embodiments, the CB preconfigured grant configuration includes at least one of the following configurations and parameters: a frequency domain resource allocation configuration, a subcarrier configuration, a paging occasion (PO) number, a frequency start configuration, a PRB-per-PO number, and a guard band configuration.

[0053] The frequency domain resource allocation configuration configures the UL frequency resources (e.g., CB PUSCH occasion(s) in the frequency domain). To simplify the following description, “PUSCH occasion” is understood to mean “CB PUSCH occasion”.

[0054] The subcarrier configuration configures one or more subcarriers for the UL frequency resource. In some embodiments, the subcarrier configuration is a subcarrier index.

[0055] A PO number indicates a number of PUSCH occasions in the frequency domain in a time instance. The PO number is a positive integer. For example, the PO number may be 1, 2, 4, 8 or 16.

[0056] The frequency start configuration indicates a starting physical resource block (PRB) of a PUSCH occasion. For example, the frequency start configuration is an offset with respect to PRB 0.

[0057] The PRB-per-PO number indicates the number of PRBs per PUSCH occasion.

[0058] A guard band configuration configures a guard band (e.g., in units of PRBs) between PUSCH occasions in the frequency domain.

[0059] The UL time resources (i.e., times allowed for UE UU transmission) may be specified in one or more time domain configurations. In some embodiments, the CB preconfigured grant configuration includes at least one of the following: a PUSCH offset or periodicity and a time domain allocation configuration.

[0060] The offset or the periodicity configures the PUSCH occasions in the time domain. The periodicity configures a periodicity for each of the PUSCH occasions in the time domain. The offset indicates a starting slot or subframe for each of the PUSCH occasions.

[0061] The time domain allocation configuration configures symbols used for a UL transmission or multiple UL transmissions (e.g., repetitions). In one embodiment, the symbols are in a slot or a subframe. In another embodiment, the symbols are in multiple slots or subframes. In some embodiments, the time domain allocation configuration configures a start symbol, a start slot and / or a start subframe, and / or one or more lengths indicating the number of symbols, the number of slots, and / or the number of subframes.

[0062] In some embodiments, the CB preconfigured grant configuration includes at least one the following configurations and parameters: a scrambling configuration, a repetition number, a redundancy version (RV) configuration, a modulation and coding scheme (MCS) configuration, a waveform configuration, a configuration parameter, one or more hybrid automatic repeat request (HARQ) process IDs (i.e., numbers) or a HARQ ID offset for a UL transmission or multiple UL transmissions (e.g., repetitions), a HARQ configuration, a frequency-hopping configuration, and a demodulation reference signal (DMRS) configuration.

[0063] The scrambling configuration configures data scrambling in a UL transmission or multiple UL transmissions (e.g., repetitions). For example, the scrambling configuration includes or is an identifier used to initialize data scrambling for a UL transmission or multiple ULtransmissions (e.g., repetitions). If the CB preconfigured grant configuration does not include the scrambling configuration, the UE 102 applies a physical cell ID of the cell 124 to initialize data scrambling for a UL transmission or multiple UL transmissions (e.g., repetitions).

[0064] The repetition number indicates the number of multiple UL transmissions (e.g., repetitions).

[0065] The redundancy version (RV) configuration indicates each of multiple UL transmissions (e.g., repetitions) of a UL packet data unit (PDU) or transport block.

[0066] The MCS configuration configures an MCS for a UL transmission or multiple UL transmissions (e.g., repetitions). For example, the MCS configuration includes an MCS index indicating an MCS. In some embodiments, the MCS configuration configures DFT-s-OFDM (i.e., Discrete Fourier Transform-Spread Orthogonal Frequency Division Multiplexing) or CP- OFDM (i.e., Cyclic Prefix Orthogonal Frequency Division Multiplexing) for the UL transmission or multiple UL transmissions. In some embodiments, the MCS configuration includes multiple MCSs. For example, the MCS configuration includes multiple MCS indexes indicating respective MCSs. The UE 102 may select a MCS from the configured MCSs, based on one or more parameters and / or one or more condition(s) against the parameter(s). In some embodiments, the parameter(s) includes a volume of data to be transmitted and / or DL signal strength of the cell 124. For example, the MCS configuration configures a first MCS and a second MCS. If the parameter is below a first threshold, the UE 102 selects the first MCS. Otherwise (i.e., if the parameter is above the first threshold), UE 102 selects the second MCS. If the parameter is equal to the first threshold, the UE 102 may select the first MCS or the second MCS. In another example, the MCS configuration configures a first MCS, a second MCS, and a third MCS. If the parameter is below a first threshold, the UE 102 selects the first MCS.Otherwise, if the parameter is above the first threshold and below a second threshold, the UE 102 selects the second MCS. If the parameter is above the second threshold, UE 102 selects the third MCS. If the parameter is equal to the first threshold, the UE 102 may select the first MCS or the second MCS. If the parameter is equal to the second threshold, the UE 102 may select the second MCS or the third MCS. The first threshold and the second threshold for the different parameters are different.

[0067] The waveform configuration configures DFT-s-OFDM or CP-OFDM for a UL transmission or multiple UL transmissions (e.g., repetitions). In some embodiments, the CB preconfigured grant configuration includes multiple waveform configurations corresponding to or associated with different MCSs in the MCS configuration.

[0068] The configuration parameter configures one or more PUSCH formats or types. The BS 104 attempts to decode or decodes a UL transmission with the one or more PUSCH formats or types.

[0069] The CB preconfigured grant configuration may include one or more HARQ process IDs (i.e., numbers) or a HARQ ID offset for a UL transmission or multiple UL transmissions (e.g., repetitions). Alternatively, the CB preconfigured grant configuration does not include or configure the number of HARQ processes for a UL transmission or multiple UL transmissions (e.g., repetitions). In some embodiments, the CB preconfigured grant configuration does not configure a HARQ process ID (i.e., a number) or a HARQ ID offset for a UL transmission or multiple UL transmissions (e.g., repetitions).

[0070] The HARQ configuration configures whether HARQ is enabled or disabled for a UL transmission or multiple UL transmissions (e.g., repetitions).

[0071] The CB preconfigured grant configuration may include a frequency-hopping configuration for a UL transmission or multiple UL transmissions (e.g., repetitions).Alternatively, the CB preconfigured grant configuration does not configure frequency hopping for the UL transmission or multiple UL transmissions.

[0072] The CB preconfigured grant configuration may also include a DMRS configuration for UL transmission or multiple UL transmissions (e.g., repetitions).

[0073] The power related resources (i.e., transmission power, ramping power, etc. allowed for UE UL transmission) may be specified in one or more power control configurations. In some embodiments, the CB preconfigured grant configuration includes power control configuration parameters for a UL transmission or multiple UL transmissions (e.g., repetitions). The UE 102 determines a transmission power for the UL transmission(s) 408-1, 408-M based on the power control parameters, and applies the transmission power to the UL transmission(s) 408- 1, ..., 408-M or each of the UL transmission(s) 408-1, ..., 408-M. In some embodiments, the UE102 uses the transmission power to transmit each of the UL transmission(s) 408-1, ..., 408-M. In some embodiments, the power control configuration parameters include a received target power (value) and / or a scaling factor (e.g., an alpha value). The scaling factor applies to a DL pathloss estimated by the UE 102. In some embodiments, the UE 102 uses formula (1) with the received target power and the alpha value to determine a transmission power:Transmission power = Received target power + scaling factor x DL pathloss. (1)

[0074] In other embodiments, the UE 102 uses another formula with the received target power, the alpha value, and one or more additional adjustment values to determine a transmission power for the UL transmission(s) 408-1, ..., 408-M. In some embodiments, the UE 102 uses the transmission power to transmit each of the UL transmi ssion(s) 408-1, ..., 408-M. For example, the additional adjustment value(s) includes a first additional adjustment value and a second adjustment value. The first additional adjustment value may be determined based on the number of PRBs for a UL transmission or each of UL transmissions. The second additional adjustment value may be determined based on the MCS for the UL transmission or each of UL transmissions. The transmitted power is then calculated using formula (2):Transmission power = Received target power + scaling factor x DL pathloss + the first adjustment value + the second adjustment value. (2)

[0075] In some embodiments, the first adjustment value is given by 10 logio (2Hx number of PRBs), where p is a numerology (value) which is one of 0, 1, 2, 3 4, 5, or 6, which corresponds to subcarrier spacing: 15 KHz, 30 KHz, 60 KHz, 120 KHz, 240 KHz, 480 KHz, and 960 KHz, respectively. The UE 102 determines the numerology in accordance with the subcarrier spacing that the UE 102 uses to communicate with the BS 104 and determines the first adjustment value for the UL transmi ssion(s) 408-1, ... , 408-M, based on the determined numerology.Alternatively, the first adjustment value may be 0 (i.e., it is omitted). In some embodiments, the CB preconfigured grant configuration includes an indicator indicating the first adjustment value = 10 logio (2" x number of PRBs) is applied. If the CB preconfigured grant configuration does not indicate the first adjustment value, the UE 102 considers that the first adjustment value = 0 (i.e., it is omitted). In some embodiments, the second adjustment value = lOlogio (2BPRRKs— 1), where Ks = a predetermined value (e.g., 1.25) and BPRE (Bits Per Resource Element) is thenumber of bits per resource element related to the MCS. Alternatively, the second adjustment value = 0 (i.e., it is omitted). In some embodiments, the CB preconfigured grant configuration includes an indicator indicating the second adjustment value = lOlogio (2BPRE-Ks— 1 ) is applied. If the CB preconfigured grant configuration does not indicate the first adjustment value, the UE 102 considers that the second adjustment value = 0 (i.e., it is omitted).

[0076] In some other embodiments, the UE 102 compares the transmission power calculated above with a UE configured maximum output power (e.g., PCMAX). If the calculated transmission power is larger than the UE configured maximum output power, the UE 102 uses the UE configured maximum output power to transmit (each of) the UL transmission(s) 408-1, ..., 408- M. In some embodiments, UE 102 determines the UE configured maximum output power based on a power class that represents the maximum transmission power supported by the UE 102. In some embodiments, the UE 102 obtains a pathtloss (value) as follows:Pathloss = signaled reference signal power value - measured reference signal power value. (3)

[0077] The UE 102 receives the signaled reference signal power value from the BS 104 in a SIB broadcast by the BS 104. For example, the SIB is an SIB1, an SIB 19, or an SIB31. The UE 102 measures a reference signal to obtain the measured reference signal power value. For example, the reference signal is a cell-specific reference signal (CRS). In another example, the reference signal is a synchronization signal (SS) / physical broadcast channel (PBCH) block.

[0078] In some embodiments, the UE 102 uses power control parameters in the CB preconfigured grant configuration and the RACH configuration to determine a transmission power for the UL transmission(s) 408-1, ..., 408-M or each of the UL transmission(s) 408-1, ..., 408-M. In some embodiments, the UE 102 uses the transmission power to transmit each of the UL transmission(s) 408-1, 408-M. In some embodiments, the CB preconfigured grant configuration includes a received target power value and does not include a scaling factor. If the RACH configuration includes a scaling factor (e.g., an alpha value), the UE 102 uses the scaling factor from the RACH configuration and the received target power from the CB preconfigured grant configuration to determine a transmission power with the formula above (i.e., (1) or (2)). In one embodiment, if the RACH configuration does not include a scaling factor, the UE 102 uses adefault scaling factor value and the received target power to determine a transmission power with the formula above (i.e., (1) or (2)). In some embodiments, the default scaling factor value is 1 (i.e., no scaling). In other embodiments, the default scaling factor value is larger than 1. In yet other embodiments, the default scaling factor value is smaller than 1.

[0079] In other embodiments, the CB preconfigured grant configuration does not include a received target power and includes a scaling factor. If the RACH configuration includes a scaling factor (e.g., an alpha value) as described below, the UE 102 uses the scaling factor (either from the CB preconfigured grant configuration or the RACH configuration) and the received target power with the formula (1) or (2) to determine the transmission power for the UL transmission(s) 408-1, ..., 408-M. In some embodiments, the UE 102 uses the transmission power to transmit each of the UL transmission(s) 408-1, 408-M.

[0080] In some alternative embodiments, the CB preconfigured grant configuration does not include power control configuration parameters. In such cases, the UE 102 may use power control configuration parameters from the RACH configuration to determine a transmission power for the UL transmission(s) 408-1, ..., 408-M. For example, the RACH configuration includes a preamble received target power value, a power offset value, and / or a scaling factor (e g., an alpha value). In one embodiment, the preamble received target power value is an msgA preamble received target power. The power offset value may indicate a power offset between a preamble transmission and an Msg3 transmission or a power offset between a preamble transmission and an MsgA transmission. The scaling factor may be an alpha value for an Msg3 transmission or an alpha value for an MsgA transmission. The UE 102 may then determine a transmission power for the UL transmission(s) 408-1, ..., 408-M as follows:Transmission power = preamble received target power + power offset + scaling factor x DL pathloss. (4)

[0081] After receiving the RACH configuration and the CB preconfigured grant configuration, the UE 102 initiates a communication session with the BS 104. UE 102 may operate in an idle state, an inactive state or a connected state to initiate the communication session. UE 102 may determine to use the CB preconfigured grant configuration for the communication session instead of the RACH configuration. The communication session may be a mobile originatedsession or a mobile terminated session (i.e., the UE 102 receives a paging from the BS 104 and initiates the communication session in response to the paging). In response to initiating the data communication session, UE 102 generates 406 a first UL PDU based on the CB preconfigured grant configuration. Note that the UE may be in an idle, inactive, or connected state with the network at step 406. In some embodiments, the first UL PDU is a first UL MAC PDU. In some embodiments, UE 102 includes a first UL radio resource control (RRC) message in the first UL MAC PDU. In some embodiments, UE 102 includes a UL common control channel (CCCH) message (e.g., UL-CCCH-Message) in the first UL MAC PDU, where the UL CCCH message includes the first UL RRC message. In some embodiments, the first UL RRC message is an RRC connection request message or an RRC setup request message. In other embodiments, the first UL RRC message is an RRC connection resume request message or an RRC resume request message. In yet another embodiment, the first UL RRC message is an RRC early data request message. In yet another embodiment, the first UL RRC message is an RRC connection reestablishment request message or an RRC reestablishment request message. In some embodiments, the UE 102 includes a user plane (UP) data packet or a non-access stratum (NAS) PDU in the first UL PDU or the first UL RRC message.

[0082] In some embodiments, the UE 102 may include a UE identity / identifier (ID) of the UE 102 in the first UL PDU or the first UL RRC message (e.g., the RRC connection resume request message, the RRC resume request message, the RRC connection reestablishment request message, or the RRC reestablishment request message). In some embodiments, the UE ID is a RAN ID. For example, the RAN ID is a first cell radio network temporary identifier (C-RNTI). In some embodiments, the UE 102 receives the first C-RNTI from the BS 104 and stores the first C-RNTI before initiating the communication session. In another example, the RAN ID is an inactive radio network temporary identifier (LRNTI). In other embodiments, the UE ID is a NAS ID. For example, the NAS ID is an S-Temporary Mobile Subscription Identifier, a 5G S- Temporary Mobile Subscription Identifier, or a 6G S-Temporary Mobile Subscription Identifier.

[0083] The UE 102 then transmits 408 the first UL PDU to the BS 104, based on the CB preconfigured grant configuration. In some embodiments, the UE 102 transmits 408 the first UL PDU in one or more UL transmissions 408-1, 408-M to the BS 104, where is an integerlarger than zero. Al may be one of 1, 2, 4, 8, 16, 32, 64, and / or 128. In some embodiments, the CB preconfigured grant configuration configures UL transmission resources for the UL transmission(s) on symbols within a slot or subframe. In such cases, the UE 102 transmits the UL transmission(s) on the symbols within the slot or subframe. In other embodiments, the CB preconfigured grant configuration configures UL transmission resources for the UL transmission(s) on symbols in multiple slots or subframes. In such cases, the UE 102 transmits the UL transmission(s) on the symbols in the multiple slots or subframes. If Al is larger than one, the UL transmissions 408-2, 408-M are repetitions. In some embodiments, each of the UL transmission(s) is a HARQ transmission or a PUSCH transmission. In some embodiments, the UE 102 encodes the first UL PDU (i.e., a transport block including the first UL PDU) and a cyclic redundancy check (CRC) of the first UL PDU into an encoded block and transmits the encoded block or a portion thereof in each of the UL transmission(s). In some embodiments, the CB preconfigured grant configuration includes a repetition number (i.e., AT) as described above and the UE 102 determines Alin accordance with the repetition number. In some embodiments, if the CB preconfigured grant configuration does not include the repetition number, the UE 102 transmits 408 only one UL transmission (i.e., the UL transmission 408-1) to the BS 104. In some embodiments, UE 102 does not transmit a random access preamble to transmit the first UL PDU.

[0084] In some embodiments, the UE 102 may apply scrambling to (each of) the UL transmission(s) 408-1, ..., 408-M. The UE 102 generates a scrambling sequence using a scrambling sequence generator and applies the scrambling sequence to bits transmitted in (each of) the UL transmission(s) 408-1, ..., 408-M. UE 102 initializes the scrambling sequence generator with an initial scrambling sequence. In some implementations, the UE 102 generates (e.g., computes or calculates) an initial scrambling sequence using a radio network temporary identifier (RNTI), a power of 2, and / or a scrambling identity. In some implementations, the CB preconfigured grant configuration configures the scrambling identity. In other implementations, the scrambling identity is a physical cell identity of the cell. In some implementations, the scrambling sequence generator is defined in a 3GPP specification (e.g., 3GPP TS 36.211 or 38.211). In some implementations, the RNTI is a CB-RNTI as described below. In other implementations, the RNTI has a fixed value (e.g., 0). In cases where scrambling is applied to(each of) the UL transmission(s) 408-1, 408-M as described above, the BS 104 applies descrambling to (each of) the UL transmi ssion(s) 408-1, ..., 408-M. The BS 104 may generate a scrambling sequence using the scrambling sequence generator used by the UE 102 and uses the scrambling sequence to perform descrambling to the scrambled bits in (each of) the UL transmi ssion(s) 408-1, ..., 408-M. After the descrambling, BS 104 obtains unscrambled bits from the scrambled bits. The BS 104 then may process the unscrambled bits (e.g., decode the unscrambled bits to obtain the UL PDU). The BS 104 initializes the scrambling sequence generator with an initial scrambling sequence. In some implementations, the BS 104 generates (e g., computes or calculates) the initial scrambling sequence using the RNTI, the power of 2, and / or the scrambling identity as the UE 102.

[0085] The redundancy version for repetitions (i.e., how many times a transmission is repeated when the previous transmission is not detected by the BS) may be specified in one or more configurations of redundancy version for repetitions. In some embodiments, the BS 104 configures the same RV (e.g., RV 0) for each of the UL transmissions (i.e., repetitions) in the CB preconfigured grant configuration as described above, and the UE 102 transmits the first UL PDU (e.g., the same portion of the encoded block) in each of the UL transmissions using the same RV. For example, the CB preconfigured grant configuration includes a field / IE configuring the RV (e.g., RV 0) applied to the UL transmissions (i.e., repetitions). In such cases, the BS 104 decodes each UL transmission using the same RV.

[0086] In other embodiments, the BS 104 configures different RVs for the UL transmissions in the CB preconfigured grant configuration as described above, and the UE 102 transmits the different RVs of the first UL PDU in the UL transmissions. In such cases, the BS 104 receives each of the UL transmissions and decodes each UL transmission using the corresponding RV. For example, the different RVs of the first UL PDU may be different portions of the encoded block. In one embodiment, some of the portions may partially overlap. In another embodiment, the portions do not overlap. In some embodiments, the BS 104 may configure different RVs for the UL transmissions 408-1, ..., 408-M as shown in Table 1. For example, the CB preconfigured grant configuration includes an RV configuration (e.g., the third row, the fourth row, the fifthrow or the sixth row in Table 1). The UE 102 and the BS 104 apply the RV sequence to the UL transmissions.Table 1

[0087] The orthogonal cover code (OCC) resources may be specified in one or more OCC configurations. The OOC is primarily used in conjunction with various Multiple Access schemes in 5G to provide better separation of user’s data and reduce interference. In some embodiments, the CB preconfigured grant configuration includes an OCC. The UE 102 applies the OCC to the UL transmission(s) 408-1, ..., 408-M. For example, UE 102 applies the OCC to the encoded block or the portion of the encoded block and then transmits the encoded block or the portion of the encoded block. In other embodiments, the CB preconfigured grant configuration includes a set of OCCs. In one embodiment, the UE 102 selects (e.g., randomly) an OCC 1 from the set and applies the OCC 1 to the UL transmission(s) 408-1, ..., 408-M. For example, UE 102 applies the OCC 1 to the encoded block or the portion of the encoded block and then transmits the encoded block or the portion of the encoded block. In some scenarios, another UE, called “additional UE” in this document (not illustrated in FIG. 1) may select an OCC 2 from the set of OOCs. This additional UE applies the OCC 2 to UL transmi ssion(s) and transmits the UL transmi ssion(s) in the same PUSCH occasion(s) as the UL transmission(s) 408-1, ..., 408-M of UE 102. In such cases, the UL transmission(s) of the additional UE and the UL transmission(s) 408-1, ..., 408-M of UE 102 are overlapped. Because different OCCs are applied to the UL transmi ssion(s) of the additional UE and the UL transmission(s) 408-1, 408-M of the UE 102, the interferences among the other UL transmission(s) and the UL transmission(s) 408-1, ..., 408-M are minimizedor eliminated. As a result, the BS 104 successfully receives and decodes the UL transmission(s) of the additional UE and the UL transmi ssion(s) 408-1, 408-M of UE 102, using the OCC 2 and OCC 1, respectively. In some embodiments, OCCs in the set of OOCs have the same length. In other embodiments, at least two OCCs in the set of OOCs have different lengths. In some embodiments, the OCCs correspond to or are associated with different MCSs in the MCS configuration. In other embodiments, the CB preconfigured grant configuration does not configure an OCC. Thus, the UE 102 do not use an OCC to transmit the UL transmi ssion(s) and the BS 104 does not use an OCC to receive the UL transmission(s).

[0088] As previously discussed, the CB preconfigured grant configuration includes one or more power control configuration parameters configuring a transmission power. The UE 102 determines the transmission power for the UL transmission(s) 408-1, ..., 408-M in accordance with the power control configuration parameter(s) introduced above.

[0089] For example, the BS 104 determines to transmit a first DL PDU to the UE 102 after (e g., in response to) receiving the first UL PDU. To transmit the first DL PDU, the BS 104 may transmit 410 a downlink control information (DCI) and a CRC of the DCI on a PDCCH to the UE 102. The BS 104 scrambles the CRC with a CB radio network temporary identifier (CB- RNTI). In some embodiments, the BS 104 scrambles the DCI with the CB-RNTI. The DCI includes a DL assignment to schedule one or more DL transmissions of the first DL PDU to the UE 102 as described below. In some embodiments, the first DL PDU does not include or is not a random access response. In other embodiments, the first DL PDU includes or is a random access response. In some embodiments, the BS 104 transmits 412 the first DL PDU to the UE 102, based on the DL assignment.

[0090] After transmitting the first UL PDU as described above, the UE 102 may monitor a PDCCH using the CB-RNTI. While monitoring PDCCH with the CB-RNTI, the UE 102 receives 410 the DCI and the CRC of the DCI on the PDCCH from the BS 104. The UE 102 determines that the CRC is scrambled with the CB-RNTI based on the CB-RNTI and the DCI. The UE 102 receives 412 the first DL PDU from the BS 104 in accordance with the DL assignment, e.g., in response to determining the CRC is scrambled with the CB-RNTI.

[0091] In some embodiments, the BS 104 transmits 412 the first DL PDU in one or more DL transmissions 412-1, ..., 4 / 2-Vto the UE 102, where Vis an integer larger than zero. Vmay be one of 1, 2, 4, 8, 16, 32, 64, and / or 128. In some embodiments, the DL assignment configures DL time and frequency resources for the DL transmission(s). The BS 104 transmits the DL transmi ssion(s) on the DL time and frequency resources to the UE 102, and the UE 102 receives the DL transmission(s) on the DL time and frequency resources. The DL time resources may include symbols within one or more slots or subframes. In other embodiments, the DL time resources include symbols across multiple slots or subframes. In some embodiments, the DL transmissions 412-2, .. . , 412-N are repetitions. In some embodiments, each of the DL transmi ssion(s) is a HARQ transmission or a physical DL shared channel (PDSCH) transmission. In some embodiments, the BS 104 encodes the first DL PDU (i.e., a transport block including the first DL PDU) and a CRC of the first DL PDU into an encoded block and transmits the encoded block or a portion thereof in each of the DL transmission(s). In some embodiments, the DL assignment includes a repetition number (i.e., N). In such cases, the BS 104 transmits 412 the N DL transmission(s) in accordance with the repetition number and the UE 102 may receive or attempt to receive 412 the AfDL transmission(s) in accordance with the repetition number. If the DL assignment does not include a repetition number, the BS 104 may transmit the first DL PDU in only one DL transmission (i.e., 412-1). If the DL assignment does not include a repetition number, the UE 102 may receive or attempt to only receive the DL transmission 412-1 in accordance with the DL assignment. In some embodiments, the UE 102 discards the CB-RNTI in response to receiving the first DL PDU.

[0092] In some embodiments, the BS 104 configures the same RV (e.g., RV 0) for each of the DL transmission(s) in the DL assignment and / or the CB preconfigured grant configuration, and the BS 104 transmits the first DL PDU (e.g., the same portion of the encoded block) in each of the DL transmission(s) using the same RV. For example, the DL assignment or the CB preconfigured grant configuration includes a field / IE configuring a RV (e.g., RV 0) applied to the DL transmissions (i.e., repetitions). In such cases, the UE 102 receives and decodes each DL transmission using the same RV.

[0093] In other embodiments, the BS 104 configures the different RVs for the DL transmissions in the DL assignment and transmits the different RVs of the first DL PDU in the DL transmissions. In such cases, the UE 102 receives each of the DL transmissions and decodes each DL transmission using the corresponding RV. For example, the different RVs of the first DL PDU may be different portions of the encoded block. In one embodiment, some of the portions partially overlap. In another embodiment, the portions do not overlap. In some embodiment, the BS 104 may configure different RVs for the DL transmissions 412-1, .. ., 412-N in the CB preconfigured grant configuration or the DL assignment. For example, the CB preconfigured grant configuration or the DL assignment indicates an RV configuration (e.g., the third row, the fourth row, the fifth row or the sixth row in Table 2). The UE 102 and the BS 104 apply the RV configuration to the DL transmissions 412-1, .. . , 412-N based on the indication and / or the Table 2. In other embodiments, the DL assignment indicates a (single) RV. The UE 102 and the BS 104 apply RVs to the DL transmissions 412-1, 412-N as & on the indicated RV and Table 2.Table 2

[0094] In some embodiments, the UE 102 and the BS 104 determine the CB-RNTI based on one or more parameters and one multiplier applied to at least one parameter. In some embodiments, the parameters include a slot number, a subframe number, a symbol number, a system frame number (SFN), a hyper SFN, a resource block number, a carrier identifier, and / or a contention resolution window size associated with when a UL transmission 408-K is transmitted,where 1 < K <M. In one example, K= 1. In another example, K = M. In some embodiments, the slot number identifies a slot where the UL transmission 408-K transmitted, where 1 < K < M. If the UL transmission 408-K is transmitted on symbols on two slots (i.e., a first slot and a second slot), the slot may be the first slot or the second slot. In some embodiments, the subframe number identifies a subframe where the UL transmission 408-K is transmitted. In some embodiments, the SFN identifies a frame including the slot or the subframe. In some embodiments, the hyper SFN identifies a hyper frame including the slot or the subframe. In some embodiments, the symbol number identifies a symbol in the slot or the subframe. For example, the symbol is the first symbol of the slot or the subframe. In another example, the symbol is the first symbol of symbols where the UL transmission 408-K is transmitted. In some embodiments, the resource block number identifies a resource block of resource blocks where the UL transmission 408-K is transmitted. For example, the resource block number is the lowest resource block number. In another example, the resource block number is the highest resource block number. In some embodiments, the carrier identifier identifies a carrier where the UL transmission 408-K is transmitted. In the case where OCC(s) is / are configured as described above, the parameter(s) include an OCC identifier (ID) identifying an OCC selected by the UE, applied to the CB PUSCH transmission, or configured for the CB PUSCH occasion.

[0095] In some embodiments, the CB-RNTI is associated with the CB PUSCH occasion in which the CB PUSCH transmission (e.g., the CB PUSCH transmission 408-1) is transmitted. In some embodiments, the CB-RNTI is associated with the last CB PUSCH occasion in which the last CB PUSCH transmission (e.g., the CB PUSCH transmission 408-M) is transmitted in the case of repetitions. In other embodiments, the CB-RNTI is associated with the first CB PUSCH occasion in which the first CB PUSCH transmission (e.g., the CB PUSCH transmission 408-1) is transmitted in the case of repetitions. Generally, the value space of CB-RNTI(s) is different from the value space of RA-RNTI(s). In some embodiments, the CB PUSCH occasion(s) configured in the CB preconfigured grant configuration do not overlap with PRACH occasion(s) in the RACH configuration. Thus, the BS 104 ensures the value space of CB-RNTI(s) is different from the value space of RA-RNTI(s).

[0096] In some embodiments, a CB-RNTI is determined as follows:CB-RNTI = 1 + s_id + 14 * t_id + 14 x 80 * f_id + 14 x 80 x 8 x ul_carrier_id. (5)

[0097] In formula (5), s_id is an index of the first OFDM symbol of a CB PUSCH occasion (0< s_id < 14) and t_id is an index of the first slot of a CB PUSCH occasion in a system frame. For example, 0 < t id < 80. If the cell is operated with numerology p = 0, 1, 2 or 3, t id is determined based on the numerology p. If the cell is operated with numerology p = 5 or 6, t_id is an index of the 120 kHz slot in a system frame that contains the CB PUSCH occasion. Further, f id is an index of a CB PUSCH occasion in the frequency domain, where 0 < f id < 8 (8 being the maximum number of CB PUSCH occasions that can be configured in the frequency domain). If only a single CB PUSCH occasion is configured for the cell in the frequency domain, the term “14 x 80 x f id” is omitted. Also in formula (5), ul_carrier_id indicates a UL carrier used for a CB PUSCH transmission. In some embodiments, a value range of the ul carrier id depends on the maximum number of UL carriers that can be configured for the cell. For example, UL carriers 7, ... , C are configured for the cell, where C is a positive integer. ul_carrier_id values 0, ... , C-l indicate UL carriers 1, ... , C, respectively. If only a single UL carrier is configured for the cell, the term “14 x 80 x 8 x ul_carrier_id” is omitted.

[0098] When OCC(s) is / are configured as described above, the CB-RNTI may further be determined based on an OCC ID (occ id) identifying an OCC. In this case, occ id is considered in the formula for determining the CB-RNTI. Formula (6) below consider the occ id in determining a CB-RNTI:CB-RNTI = 1 + s_id + 14 x t_id + 14 x 80 x f_id + 14 x 80 x 8 x ul_carrier_id + 14 x 80 x 8 x 2 x occ_id (6)

[0099] In formula (6), occ id is an index of an OCC for a CB PUSCH transmission. For example, 0 < occ id < 2. In another example, 0 < occ id < 4. In yet another example, 0 < occ id< 16. In one embodiment, a value range of the occ id depends on the maximum number of OCCs that can be configured for CB PUSCH occasion(s) or CB PUSCH transmission. The UE 102 determines the occ_id by identifying the OCC (e.g., a first OCC) that the UE 102 applies to the CB PUSCH transmission (e.g., the CB PUSCH transmission 408).

[0100] If the BS 104 simultaneously receives CB PUSCH transmissions from the UE 102 and an additional UE (not shown in Fig. 4A), on the same CB PUSCH occasion with the first OCCand a second OCC respectively, the BS 104 uses a first CB-RNTI and a second CB-RNTI to send DCI 1 and DCI 2 to the UE 102 and the additional UE, respectively, similar to event 410. In some implementations, the BS 104 determines the first CB-RNTI and the second CB-RNTI based on the first OCC and the second OCC, respectively. For example, a first occ id and a second occ id identify the first OCC and the second OCC, respectively. The BS 104 determines the first CB-RNTI and the second CB-RNTI based on the first occ id and the second occ id, respectively, as described above. In some embodiments, the BS 104 transmits the DCI 1 and the DCI 2 on the same PDCCH. In other embodiments, BS 104 transmits the DCI 1 and the DCI 2 on different PDCCHs. The UE 102 determines a first CB-RNTI (same as the first CB-RNTI used by the BS 104) and the additional UE determines a second CB-RNTI (same as the second CB- RNTI used by the BS 104), as described above. Thus, UE 102 receives DCI 1 using the first CB- RNTI and the additional UE receives the DCI 2 using the second CB-RNTI. In some embodiments, DCI 1 and DCI 2 are DL assignments. For example, the CB PUSCH occasion is the CB PUSCH occasion where the UE 102 transmits the CB PUSCH transmission 408. DCI 1 is the DL assignment 410. DCI 2 is a DL assignment scheduling one or more DL transmissions of a DL PDU for the additional UE, similar to event 410. The DL PDU for the additional UE includes contention resolution for the additional UE. The DL transmission(s) for the additional UE is different from the DL transmission(s) 412.

[0101] In other embodiments, the CB-RNTI is determined as:CB-RNTI = l+t_id + 1 O*f_id + 60*(SFN_id mod (Wmax / 10)). (7)

[0102] In formula (7), t_id is an index of the first subframe of the CB PUSCH occasion (0< t_id <10), and f id is an index of the CB PUSCH occasion in the frequency domain (0 < f id < 6, 6 being the maximum number of CB PUSCH occasions that can be configured in the frequency domain). If only a single CB PUSCH occasion is configured for the cell in the frequency domain, the term “10 x f id” is omitted. Also in formula (7), System Frame Number identifier (SFN id) is an index of a radio frame of the CB PUSCH occasion, and Wmax is 400, and is a maximum possible contention resolution window size in subframes.

[0103] When OCC(s) is / are configured as described above, the CB-RNTI may further be determined based on an OCC ID (occ id) identifying an OCC. In this case, occ id is consideredin the formula for determining the CB-RNTI as exemplified below (with occ id as described above):CB-RNTI = CB-RNTI=l+t_id + 10*f_id + 60*(SFN_id mod (Wmax / 10)) + 60 x 40 x occ_id.(8)

[0104] In yet other embodiments, the CB-RNTI is determined as: CB-RNTI=1 + floor(SFN_id / 4) + 256xCarrier_id. (9)

[0105] In formula (9), SFN id is an index of a radio frame of the CB PUSCH occasion, and “floor” is a function that returns a minimum value of its variable. Further, carrier id is an index of a UL carrier associated with the CB PUSCH transmission. In some embodiments, a value range of the carrier id depends on the maximum number of UL carriers that can be configured for the cell. If only a single UL carrier is configured for the cell, the term “256xcarrier_id” is omitted.

[0106] When OCC(s) is / are configured as described above, the CB-RNTI may be further determined based on an OCC ID (occ id) identifying an OCC. In this case, occ id is considered in the formula for determining the CB-RNTI as exemplified below (with occ id is as described above):CB-RNTI = 1 + floor(SFN_id / 4) + 256xcarrier_id + 256 x the maximum number of carriersxocc id. (10)

[0107] In yet other embodiments, the CB-RNT is determined as:CB-RNTI = 1 + floor(SFN_id / 4) + 256X(H-SFN mod 2). (11)

[0108] In Formula (11), SFN id is an index of a radio frame of the CB PUSCH occasion. In the case of repetitions across multiple radio frames, the radio frame is the first radio frame of the multiple radio frames. Further, H-SFN is an index of a hyper frame of the CB PUSCH occasion. In the case of repetitions across multiple hyper frames, the radio frame is the first hyper frame of the multiple radio frames.

[0109] When OCC(s) is / are configured as described above, the CB-RNTI may be determined further based on an OCC ID (occ id) identifying an OCC. In this case, occ id is considered in the formula for determining the CB-RNTI as exemplified below (with the occ_id is as described above):CB-RNTI = 1 + floor(SFN_id / 4) + 256x(H-SFN mod 2) + 256x2xOcc_id. (12)

[0110] In some alternative embodiments, the BS 104 transmits 412 the DL transmission(s) to the UE 102 without transmitting the DL assignment. In some embodiments, the BS 104 transmits 412 the DL transmission(s) on DL transmission resources that the UE 102 has known. In some embodiments, the DL transmission resources are configured in the CB preconfigured grant configuration. In other embodiments, the DL transmission resources are configured in a preconfigured DL assignment configuration that the BS 104 transmits to the UE 102, before event 406. In one embodiment, the BS 104 broadcasts the preconfigured DL assignment configuration in an SIB via the satellite 304 and / or the cell 124. In another embodiment, the BS 104 transmits a dedicated message including the preconfigured DL assignment configuration to the UE 102, before event 406.[0U1] In some embodiments, the first DL PDU is a first DL MAC PDU. In some embodiments, the BS 104 includes a first DL RRC message in the first DL MAC PDU. In some embodiments, the BS 104 includes a DL CCCH message (e.g., DL-CCCH-Message) in the first DL MAC PDU, where the DL CCCH message includes the first DL RRC message. In some embodiments, the first DL RRC message is an RRC connection setup message or an RRC setup message. In other embodiments, the first DL RRC message is an RRC connection resume message or an RRC resume message. In yet other embodiments, the first DL RRC message is an RRC early data complete message. In yet other embodiments, the first DL RRC message is an RRC connection reestablishment message or an RRC reestablishment message. In yet other embodiments, the first DL RRC message is an RRC connection release message or an RRC release message. In some embodiments, the BS 104 includes a UP data packet or an NAS PDU in the first DL PDU or the first DL RRC message. In other embodiments, the second DL PDU does not include a PDU. In some embodiments, the UE 102 transitions to the connected state from the idle or inactive state in response to receiving the first DL RRC message (e.g., the RRC connection setup message, the RRC setup message, the RRC connection resume message or the RRC resume message).

[0112] Because the periodic UL transmission resources are shared among UEs, other UE(s) may transmit UL transmission(s) on the same CB PUSCH occasion(s) as UE 102. Therefore, theUL transmission(s) 408-1, ..., 408-M are CB data transmission(s). In such cases, the BS 104 needs to resolve a potential contention between the UE 102 and other UE(s). After receiving the first UL PDU, the BS 104 generates contention resolution information for the UE 102 and includes the contention resolution information in the first DL PDU. In some embodiments, the BS 104 identifies the UE 102 based on the UE ID thereof included in the first UL PDU. When the UE 102 receives the contention resolution information and verifies the contention resolution information addressed to the UE 102, the UE 102 determines that a contention resolution for transmission of the first UL PDU is successful (i.e., the UE 102 transmits the first UL PDU successfully). In some embodiments, the contention resolution information includes a portion of the first UL PDU (e.g., the first L bits of the first UL PDU). In other embodiments, the contention resolution information includes a portion of the UL CCCH message (e.g., the first £ bits of the UL CCCH message). In one embodiment, L is 48. In another embodiment, L larger than 48 and / or smaller than 73. In yet other embodiments, the contention resolution information includes the UE ID. In some embodiments, the contention resolution information is a MAC control element, and the BS 104 includes, in the first DL PDU, a MAC subheader to indicate the contention resolution information.

[0113] In some embodiments, the BS 104 may include a second C-RNTI for the UE 102 in the first DL PDU. In some embodiments, the UE 102 and the BS 104 use the second C-RNTI for subsequent communications (i.e., events 414, 416, 418 and / or 420). Thus, the BS 104 may transmit 414 a DCI and a CRC of the DCI on a PDCCH to the UE 102. The BS 104 scrambles the CRC with the second C-RNTI. In some embodiments, the BS 104 scrambles the DCI with the second C-RNTI. The DCI includes a UL grant (i.e., a dynamic grant) to schedule one or more UL transmissions 416-1, ..., 416-X, where X is an integer larger than zero. In the subsequent communication, the UE 102 monitors a PDCCH using the second C-RNTI. The UE 102 transmits 416 UL transmission s) 416-1, ..., 416-X of a second UL PDU in accordance with the UL grant. JVmay be one of 1, 2, 4, 8, 16, 32, 64, and / or 128. In some embodiments, the UL transmissions 416-2, .... 416-X are repetitions. In some embodiments, each of the UL transmission(s) is a HARQ transmission or a non-CB PUSCH transmission. In some embodiments, the UE 102 encodes the second UL PDU (i.e., a transport block including thesecond UL PDU) and a CRC of the first UL PDU into an encoded block and transmits the encoded block or a portion thereof in each of the UL transmission(s). In some embodiments, the UL grant includes a repetition number (i.e., X) and the UE 102 determines Uin accordance with the included repetition number. In some embodiments, if the UL grant does not include the repetition number, the UE 102 transmits 416 only one UL transmission (e.g., the UL transmission 416-1) to the BS 104.

[0114] In some embodiments, the BS 104 configures the same RV (e.g., RV 0) for each of the UL transmissions (i.e., repetitions) in the UL grant, and the UE 102 transmits the second UL PDU (e.g., the same portion of the encoded block) in each of the UL transmissions 416-1, ..., 416-X using the same RV. For example, the UL grant includes a field / IE configuring an RV (e.g., RV 0) applied to the UL transmissions (i.e., repetitions). In such cases, the BS 104 receives and decodes each UL transmission using the same RV.

[0115] In other embodiments, the BS 104 configures different RVs for the UL transmissions in the UL grant, and the UE 102 transmits the different RVs of the second UL PDU in the UL transmissions 416-1, ... , 416-X. In such cases, the BS 104 receives each of the UL transmissions and decodes each UL transmission using the corresponding RV. For example, the different RVs of the second UL PDU may be different portions of the encoded block. In one embodiment, some of the portions partially overlap. In another embodiment, the portions do not overlap. In some embodiments, the UL grant indicates an RV. The UE 102 and the BS 104 apply RVs to the UL transmissions 416-1, ..., 416-X based on the indicated RV and Table 3.Table 3

[0116] In the subsequent communication, the BS 104 may transmit 418 a DCI and a CRC of the DCI on a PDCCH to the UE 102. The BS 104 scrambles the CRC with the second C-RNTI. In some embodiments, the BS 104 scrambles the DCI with the second C-RNTI. The DCI includes a DL assignment to schedule one or more DL transmissions 420-1, ..., 420-Y of a second DL PDU, where Y is an integer larger than zero. The BS 104 transmits the DL transmission(s) 420-1, ..., 420-Y in accordance with the DL assignment. The UE 102 receives 420 the DL transmi ssion(s) 420-1, ..., 420-Y in accordance with the DL assignment. Y may be one of 1, 2, 4, 8, 16, 32, 64, and / or 128.

[0117] In some embodiments, the DL assignment configures DL time and frequency resources for the DL transmi ssion(s) 420-1, .... 420-Y. The BS 104 transmits the DL transmission(s) 420- 1, ..., 420-Y on the DL time and frequency resources to the UE 102, and the UE 102 receives the DL transmission(s) 420-1, ..., 420-Y on the DL time and frequency resources. The DL time resources include symbols within one or more slots or subframes. In other embodiments, the DL time resources include symbols across multiple slots or subframes. In some embodiments, the DL transmissions 420-2, 420-Y are repetitions. In some embodiments, each of the DL transmission(s) is a HARQ transmission or a PDSCH transmission. In some embodiments, the BS 104 encodes the second DL PDU (i.e., a transport block including the second DL PDU) and a CRC of the second DL PDU into an encoded block and transmits the encoded block or a portion thereof in each of the DL transmission(s). In some embodiments, the DL assignment includes a repetition number (i.e., Y). In such cases, the BS 104 transmits 420 the Y DL transmission(s) in accordance with the repetition number and the UE 102 may receive or attempt to receive 420 the Y DL transmission(s) in accordance with the repetition number. If the DL assignment does not include the repetition number, the BS 104 may transmit the second DL PDU in only one DL transmission (i.e., 420-1). If the DL assignment does not include a repetition number, the UE 102 may receive or attempt to only receive the DL transmission 420-1 in accordance with the DL assignment.

[0118] In some embodiments, the BS 104 configures the same RV (e.g., RV 0) for each of the DL transmission(s) in the DL assignment, and the BS 104 transmits the second DL PDU (e.g.,the same portion of the encoded block) in each of the DL transmission(s) using the same RV. For example, the DL assignment includes a field / IE configuring a RV (e.g., RV 0) applied to the DL transmissions (i.e., repetitions). In such cases, the UE 102 receives and decodes each DL transmission using the same RV.

[0119] In other embodiments, the BS 104 configures the different RVs for the DL transmissions in the DL assignment and transmits the different RVs of the second DL PDU in the DL transmissions. In such cases, the UE 102 receives each of the DL transmissions and decodes each DL transmission using the corresponding RV. For example, the different RVs of the second DL PDU may be different portions of the encoded block. In one embodiment, some of the portions partially overlap. In another embodiment, the portions do not overlap. In some embodiment, the BS 104 may configure different RVs for the DL transmissions 420-1, ... , 420-Y in the DL assignment. For example, the DL assignment indicates an RV configuration (e.g., the third row, the fourth row, the fifth row or the sixth row in Table 1). The UE 102 and the BS 104 apply the RV configuration to the DL transmissions 420-1, ..., 420-Y based on the indication and / or the Table 1. In other embodiments, the DL assignment indicates a (single) RV. The UE 102 and the BS 104 apply RVs to the DL transmissions 420-1, ..., 420-Y\ S,Q on the indicated RV and Table 2. In some embodiments, events 418 and 420 may occur before or during or after events 414 and 416.

[0120] In some embodiments, the second UL PDU is a second UL MAC PDU. In some embodiments, the UE 102 includes a second UL RRC message in the second UL MAC PDU. In some embodiments, the UE 102 includes a UL dedicated control channel (DCCH) message (e g., UL-DCCH-Message) in the first UL MAC PDU where the UL DCCH message includes the second UL RRC message. In some embodiments, the second UL RRC message is an RRC connection setup complete message or an RRC setup complete message. In other embodiments, the second UL RRC message is an RRC connection resume complete message or an RRC resume complete message. In yet other embodiments, the second UL RRC message is an RRC connection reestablishment complete message or an RRC reestablishment complete message. In some embodiments, the UE 102 includes a UP data packet or an NAS PDU in the second ULPDU or the second UL RRC message. In some embodiments, the UE 102 may transmit one or more additional UL PDUs to the BS 104, similar to transmitting the second UL MAC PDU.

[0121] In some embodiments, the second DL PDU is a second DL MAC PDU. In some embodiments, the BS 104 includes a second DL RRC message in the second DL MAC PDU. In some embodiments, the BS 104 includes a DL DCCH message (e.g., DL-DCCH-Message) in the second DL MAC PDU, where the DL DCCH message includes the second DL RRC message. In some embodiments, the second DL RRC message is an RRC connection release message or an RRC release message to end or stop the data communication session or transition the UE 102 to the idle or inactive state. In some embodiments, the BS 104 includes a UP data packet or an NAS PDU in the second DL PDU or the second DL RRC message. The BS 104 may transmit one or more additional DL PDUs to the UE 102, similar to transmitting the second DL PDU. In such cases, after transmitting the second DL PDU and / or the additional DL PDU(s), the BS 104 may transmit a third DL PDU including an RRC connection release message or an RRC release message to the UE 102 to end or stop the data communication session or transition the UE 102 to the idle or inactive state. In some embodiments, the UE 102 ends or stops the data communication session or transitions to the idle or inactive state from the connected state, in response to receiving the second DL RRC message, the RRC connection release message or the RRC release message.

[0122] In other embodiments, after (e.g., in response to) receiving the first DL PDU or the first DL RRC message (e.g., the RRC early data complete message, the RRC connection release message, or the RRC release message), the UE 102 ends or stops the communication session with the BS 104 (i.e., there is no subsequent communication between the UE 102 and the BS 104). In such cases, the UE 102 may remain in the idle or inactive state.

[0123] After ending or stopping the communication session (e.g., a first communication session) with the BS 104, the UE 102 may initiate a second communication session with the BS 104 and performs communication with the BS 104, similar to events 406, 408, 410, 412, 414, 416, 418, and 420.

[0124] Contention resolution information for different UE may be multiplexed in a DL PDU. In some alternative embodiments, OCC(s) are not used for calculating the CB-RNTI in the casewhere OCC(s) is / are configured as described above. If the BS 104 simultaneously receives CB PUSCH transmissions from the UE 102 and the additional UE, on the same CB PUSCH occasion, with the first OCC and the second OCC, respectively, the BS 104 uses a CB-RNTI (i.e., the same CB-RNTI) to send a DCI on a PDCCH to both the UE 102 and the additional UE. The UE 102 and the additional UE determine the same CB-RNTI (same as the CB-RNTI used by the BS 104) as described above. Thus, UE 102 and the additional UE receive the same DCI on the PDCCH using the same CB-RNTI. In some embodiments, the DCI is a DL assignment similar to block 410. For example, the CB PUSCH occasion is the CB PUSCH occasion where the UE 102 transmits the CB PUSCH transmission 408 and the DCI is the DL assignment 410. The BS 104 includes contention resolution information (i.e., first contention resolution information) for the UE 102 and second contention resolution information for the additional UE in the DL PDU 412. The UE 102 and the additional UE receive the DL PDU 412 in accordance with the DCI 410. The UE 102 and the additional UE retrieve the first contention resolution information and the second contention resolution information, respectively, from the DL PDU 412. In some embodiments, the BS 104 includes the first contention resolution information and the second contention resolution information in a MAC control element. In the DL PDU 412A, the BS 104 may include a MAC subheader indicating the MAC control element. The MAC subheader may include a logical channel ID. In the MAC control element or the MAC subheader, the BS 104 includes a first ID and a second ID indicating the first contention resolution information and the second contention resolution respectively. The UE 102 uses the first ID to identify the first contention resolution information in the DL PDU 412 and ignores or discards the second contention resolution information therein. Similarly, the additional UE uses the second ID to identify the second contention resolution information in the DL PDU 412 and ignores or discards the first contention resolution information therein. In one embodiment, the first ID and the second ID are associated with the first OCC and the second OCC, respectively. For example, the first ID and the second ID are a first occ id and a second occ id identifying the first OCC and the second OCC, respectively. In another example, the first ID and the second ID are derived based on the first OCC and the second OCC, respectively. For example, the first ID and the second ID are (the first occ id - 1) and (the second occ id - 1), respectively. In otherembodiments, the BS 104 includes, in the DL PDU 412, a first MAC subheader and a second MAC subheader for the first contention resolution information and the second contention resolution information, respectively. In some embodiments, BS 104 may include the first ID and the second ID in the first MAC subheader and the second MAC subheader respectively.

[0125] Next, the handling of the UL transmission timing for the UL transmission(s) 408 is discussed. In some embodiments, the UE 102 determines a timing adjustment (TA, e.g., TTA) and applies the TA to transmit the UL transmission(s) 7, .. ., M. In some embodiments, the UL transmission(s) starts TA time unit(s) (e.g., second(s)) before the start of a corresponding downlink radio frame at the UE. In some embodiments, UE 102 determines the value of TA as a predetermined value or a default value. The predetermined value may be zero. For example, the value is 624 Ts or larger than 624 Ts(Ts being a basic time unit). In some other embodiments, the UE 102 determines the TA using a formula as below.

[0126] In some embodiments, Ts in the formula (13) is a time unit for LTE (e.g., as defined in 3GPP TS 36.211). In other embodiments, Ts in the formula (13) is a time unit for NR (e.g., Ts as defined in 3GPP TS 38.211). Further, NTA is a timing offset between uplink and downlink radio frames at the UE 102, and NrA.offet is a fixed timing advance offset. In some embodiments, NTA, off set = 0. In other embodiments, NrA.offset = 624. In some embodiments, the UE 102 applies the NTA = 0 for frame structure type 1. In other embodiments, the UE 102 applies the NTA = 624 for frame structure type 2. In some embodiments, if the UE 102 receives common TA parameters from the BS 104 (e.g., as described below), the UE 102 derives thefrom the commonTA parameters and an epoch time. Otherwise (i .e., if the UE 102 does not receive the common TA parameters), the UE 102 applies the N^^djOn= 0 or the N^^onis omitted in the formula (13). In some embodiments, the UE 102 derives thefrom the common TA parameters and an one-way propagation delay Delaycommon(t) which can be obtained as:

[0127] In formula (are given by the common TA parameters (e.g., a network-controlled common TA value, a drift rate of the common TA, and a drift rate variation of the common TA respectively), and tepochis an epoch time (e.g., epochTime). D eZaycommon(t) provides a distance at time t between the satellite 304 and an uplink time synchronization reference point divided by the speed of light. The uplink time synchronization reference point is the point where DL and UL are frame aligned with an offset given by NTA, offset-

[0128] In some embodiments, the UE 102 determines (e.g., computes) thebased on a UE position (e.g., Global navigation satellite system (GNSS) position) of the UE 102 and ephemeris information for the satellite 304. In some embodiments, UE 102 determines these quantities to pre-compensate a two-way transmission delay on a service link between the UE 102 and the satellite 304. If the UE 102 does not receive ephemeris information for the satellite 304, the UE 102 applies A / |^adj = 0 or the A / |^adj is omitted in the formula.

[0129] In some embodiments, the BS 104 broadcasts the ephemeris information and the common TA parameters, for example, in one or more SIBs (e.g., SIB19 or SIB31) for the satellite 304. UE 102 receives or acquires the ephemeris information and the common TA parameters before transmitting the first UL PDU. In some embodiments, the common TA parameters include a network-controlled common TA (i.e., value), a drift rate of the common TA, and / or a drift rate variation of the common TA. In some embodiments, the UE 102 is GNSS-capable and acquires a valid GNSS position as the UE position before transmitting the first UL PDU. Before performing transmission of the first UL PDU, the UE 102 determines a TA (e.g., TTA) based on the common TA parameters, the GNSS position, and satellite position and satellite velocity of the satellite 304 through the ephemeris information, as described above. The UE 102 applies the TA (e.g., TTA) to transmit the UL transmission(s) 408-1, .... 408-AL.

[0130] In some embodiments, the BS 104 includes a TA command in the first DL PDU to adjust UL transmission timing for UL transmissions from the UE 102. In some embodiments, the TA command is a MAC control element. In some embodiments, the BS 104 determines (e.g., calculates, derives, computes, or estimates) an index value (TA) to adjust UL transmission timing, based on the UL transmission(s) 408-1, ..., 408-AL and includes the index value in the TAcommand. Upon receiving the TA command, the UE 102 adjusts UL transmission timing for subsequent UL transmissions (e g., the UL transmission(s) 416-1, ..., 416-X) based the index value. In some embodiments, UE 102 determines a new NTA based on the index value and adjusts the UL transmission timing with the new NTA. In some embodiments, the UE 102 determines or updates the TA using the new NTA and the formula (13) to adjust the UL transmission timing.

[0131] In some embodiment, the BS 104 generates the TA command in a first format with a long index value instead of a second format with a short index value. In some embodiments, the first format is a / J-bi t TA command format, and the second format is a )-bit TA command, where P > Q. In other words, the P-bit TA command format includes aP-bit index value (TA) and the O-bit TA command format includes a O-bit index value TA). In one embodiment, P is an integer larger than 10 and Q is an integer smaller than 8. For example, P is 11 and Q is 6. In another example, P is 12 and Q is 6. In some embodiments, the UE 102 determines a new NTA = the index value x 16. In other embodiments, the UE 102 determines a new NTA = the index value X 16 x 64 / 2", where / / is a numerology (value) which may be is one of 0, 1, 2, 3 4, 5, and 6 corresponding to subcarrier spacing 15 KHz, 30 KHz, 60 KHz, 120 KHz, 240 KHz, 480 KHz, and 960 KHz, respectively.

[0132] In other embodiments, the BS 104 generates the TA command in the second format. Upon receiving the TA command with the second format, the UE 102 determines a new NTA based on an old NTA. The old NTA is the previous NTA used by the UE 102 to determine the UL transmission timing. For example, the old NTA = 0 or 624, which is used to determine the TA for the UL transmissions(s) 408-1, ..., 408-M. In some embodiments, the UE 102 determines a new NTA = an old NTA + (the index value -31) x 16. In other embodiments, the UE 102 determines a new NTA = an old NTA + (the index value -31) x 16 x 64 / 2", where u is a numerology (value), which was discussed above.

[0133] After transmitting the TA command (i.e., a first TA command), the BS 104 continuously measures UL transmissions (e.g., the UL transmission(s) 416-1, ..., 416-X from the UE 102 to determine whether to adjust UL transmission timing for the UE 102. In some embodiments, the BS 104 determines to adjust UL transmission timing for the UE 102. The BS 104 transmits a second TA command to the UE 102, similar to transmitting the first TAcommand as described above. In some embodiments, the first TA command is the first format and the second TA command is the second format. In other embodiments, the first TA command and the second TA command are in the first format. In yet other embodiments, the first TA command and the second TA command are in the second format. Upon receiving the second TA command with the second format, UE 102 determines a new NTA and a new TA as described above.

[0134] In some embodiments, the UE computes the frequency Doppler shift between the UE 102 and the satellite 304 and pre-compensates for the frequency Doppler shift in the UL transmissions, by considering the position of the UE 102 and the ephemeris information for the satellite 304.

[0135] In some embodiments, the UE 102 continuously updates the TA and frequency Doppler shift pre-compensation. If the UE 102 does not have a valid GNSS position and / or valid ephemeris information for the satellite 304, the UE 102 does not communicate with the BS 104 until the UE 102 reacquires a valid GNSS position and / or ephemeris information.

[0136] FIG. 4B illustrates a scenario 400B similar to the scenario 400A. Events 411 and 413 are similar to events 410 and 412. The differences between FIG. 4B and FIG. 4 A are described below. In the scenario 400B, the UE 102 stores 405 a dedicate RNTI, before initiating a communication session with the BS 104 to transmit the first UL PDU, as described for FIG. 4A. The BS 104 determines to transmit a first DL PDU to the UE 102 after (e.g., in response to) receiving the first UL PDU. To transmit the first DL PDU, the BS 104 may transmit 411 a downlink control information (DCI) and a CRC of the DCI on a PDCCH to the UE 102. In some embodiments, the BS 104 scrambles the CRC with the dedicated RNTI instead of the CB-RNTI in FIG. 4A. In some embodiments, the BS 104 scrambles the DCI with the dedicated RNTI instead of the CB-RNTI described for FIG. 4A. The DCI includes a DL assignment to schedule one or more DL transmissions of the first DL PDU to the UE 102 as described for event 412. In some embodiments, the BS 104 transmits 413 the first DL PDU to the UE 102, based on the DL assignment.

[0137] After transmitting the first UL PDU as described above, the UE 102 may monitor a PDCCH using the dedicated RNTI. While monitoring PDCCH with the dedicated RNTI, the UE102 receives 411 the DCI and the CRC of the DCI on the PDCCH from the BS 104. UE 102 determines that the CRC is scrambled with the dedicated RNTI based on the dedicated RNTI and the DCI. The UE 102 receives 413 the first DL PDU from the BS 104 in accordance with the DL assignment, e.g., in response to determining the CRC is scrambled with the dedicated RNTI. The dedicated RNTI is an RNTI that the BS 104 uniquely assign for the UE 102. Thus, the BS 104 does not include contention resolution information in the first DL PDU. UE 102 determines the first PDU is transmitted successfully in response to receiving the CRC scrambled with the dedicated RNTI.

[0138] In some embodiments, the dedicated RNTI is the first C-RNTI described in FIG. 4A. In other embodiments, the dedicated RNTI is not a C-RNTI. In some embodiments, the BS 104 includes the second C-RNTI in the first DL PDU as described for FIG. 4A. In such cases, events 414, 416, 418, and 420 in FIG. 4B are the same as events 414, 416, 418, and 420 in FIG. 4A. In other embodiments, the BS 104 does not include a C-RNTI (e.g., the second C-RNTI) in the first DL PDU. In such cases, the BS 104 scrambles the CRC 414 and the CRC 418 with the first C- RNTI. UE 102 receives 414 the DCI and the CRC and receives 418 the DCI and the CRC, using the first C-RNTI. The descriptions for events 414, 416, 418, and 420 in FIG. 4A can apply to FIG. 4B, where the second C-RNTI is replaced with the first C-RNTI.

[0139] FIG. 4C illustrates a scenario 400C similar to the scenarios 400A and 400B. Events 411 and 413 are similar to events 410 and 412, respectively. The differences between FIG. 4C and FIGs. 4A and 4B are described below. In the scenario 400C, the BS 104 transmits 409 a DCI and a CRC of the DCI on a PDCCH to the UE 102 to resolve contention with other UE(s). The BS 104 includes the contention resolution information for the UE 102 in the DCI and scrambles the CRC with the CB-RNTI instead of the first DL PDU. In some embodiments, the DCI neither includes a DL assignment nor a UL grant. In other embodiments, the DCI transmitted at 409 and the DCI transmitted at 410 may be combined as a single DCI which includes the contention resolution information and the DL assignment scheduling DL transmission(s) 413-1, 413-M.In such cases, events 409 and 410 are combined as a single event.

[0140] Next, several methods that are performed by a UE (e.g., the UE 102) or a BS (e.g., the BS 104, or a distributed unit (DU), or central unit (CU) of the BS 104) are discussed withreference to FIGs. 5-15. Descriptions for FIGs. 4A-4C can apply to FIGs. 5-15. Descriptions for FIGs. 16 and 17 can apply to FIGs. 4A-15. Each of these methods may be implemented using processing hardware such as one or more processors to execute instructions stored on a non- transitory computer-readable medium such as computer memory.

[0141] FIG. 5 is a flow chart of a method 500 that may be performed in a UE to establish a connection with a RAN node using a CB preconfigured grant configuration. Note that the UE may be in an idle or connected state with the network for this or any of the following methods discussed in this document. The method 500 starts with the UE receiving 504 a CB preconfigured grant configuration from a RAN node (e.g., the RAN 105 or BS 104). The CB preconfigured grant configuration may be part of a SIB, i.e., the RAN node broadcast the CB preconfigured grant configuration in a SIB. UE initiates 507 transmission of an RRC connection request message to establish a connection with the RAN node. Then, UE transmits 508 a UL transmission (e.g., CB PUSCH transmission), including the RRC connection request message, to the RAN node, based on the CB preconfigured grant configuration. In one embodiment, the order of steps 507 and 508 implies that the RRC procedure takes place before the CB PUSCH transmission. UE receives 512, from the RAN node, an RRC connection setup message in response to the RRC connection request message. UE transmits 516 an RRC connection setup complete message to the RAN node in response to the RRC connection setup message. The UE establishes a connection with the RAN node in accordance with the RRC connection setup message. In some embodiments, the connection includes a signaling radio bearer (SRB) (e.g., SRB1). By bypassing the preamble transmission and random access response steps, the UE may directly transmit the RRC connection request message, thereby reducing connection establishment latency.

[0142] In some embodiments, the RRC connection request message includes a cause (or indicator of a cause) which may indicate a reason for bypassing the traditional RA procedure. The cause or indicator may represent an emergency, mobile originated data, high priority access, mobile originated voice call, mobile originated exception data or delay tolerant access, mobile originated signaling, or mobile terminated access.

[0143] In some embodiments, the UE is in an idle state (e.g., RRC IDLE state) and transmits the CB PUSCH transmission to the RAN and transitions to a connected state (e.g., RRC CONNECTED state) in response to receiving the RRC connection setup message. In some embodiments, the UE includes a UL NAS message in the RRC connection setup complete message. For example, the UL NAS message is a Service Request message, an Attach Request message, a Tracking Area Update Request message, a Packet Data Network (PDN) Connectivity Request, a Registration Request message, or a PDU Session Establishment Request message. In some embodiments, the UE performs a security mode procedure with the RAN to activate security protection with the RAN. In some embodiments, the UE performs an RRC connection reconfiguration procedure with the RAN to establish a data radio bearer (DRB). The UE communicates security protected data with the RAN via the DRB.

[0144] In some embodiments, the RRC connection request message, the RRC connection setup message, and the RRC connection set complete may be replaced by an RRC setup request message, an RRC setup message, and an RRC setup complete message respectively. The “RRC connection reconfiguration procedure” may be replaced by an “RRC reconfiguration procedure”.

[0145] In one embodiment, which relies on FIG. 5, a wireless communication method is performed by a UE and includes receiving 504 the CB preconfigured grant configuration broadcast in a system information block, from a RAN node, preparing to transmit 507, to the RAN node, a CB PUSCH transmission including a RRC request message, and receiving 512 from the RAN node an RRC response message. In this embodiment, the RRC request message is an RRC connection request message and the RRC response message is an RRC connection setup message. The RRC request message may be an RRC resume request message and the RRC response message may be an RRC resume message. Alternatively, the RRC request message is an RRC reestablishment request message and the RRC response message is an RRC reestablishment message. In one embodiment, the CB preconfigured grant configuration includes at least one of: an uplink, UL, time domain resource configuration, a UL frequency domain resource configuration, a power control configuration, a redundancy version for repetitions configuration, an orthogonal cover code configuration, a contention resolution informationconfiguration, a UL transmission timing configuration, or a UL transmission power configuration.

[0146] The method may further include transmitting the CB PUSCH transmission including the RRC, request message and transmitting an RRC complete message to the RAN node. The method may also include receiving a RACH configuration, where the RRC request message includes a cause indication. The method may further include transmitting the RRC request message to the RAN node when the cause indication is related to mobile originated data, mobile originated exception data, or delay tolerant access, and performing a RA procedure, based on the RACH configuration, when the cause indication is not related to mobile originated data, mobile originated exception data, or delay tolerant access.

[0147] The method may also alternately include receiving a RACH, configuration, transmitting the RRC request message to the RAN node when the RRC request message is not an RRC connection reestablishment request message, and performing a RA procedure when the RRC request message is an RRC connection reestablishment request message. The method may alternately include receiving a RACH configuration, transmitting the RRC request message to the RAN node when the RRC request message is an RRC connection establishment request message, and performing a RA procedure when the RRC request message is different from an RRC connection reestablishment request message. The method may alternately include receiving a RACH configuration, transmitting the RRC request message to the RAN node when the RRC request message is an RRC early data request message, and performing a RA procedure when the RRC request message is different from an RRC early data request message. The method may alternately include receiving a RACH configuration, transmitting, to the RAN node, a UL PDU including UL data, when a transport block configured by the CB preconfigured grant configuration accommodates the UL data, and performing a RA procedure when the transport block does not accommodate the UL data. The method may alternately include receiving a RACH configuration, transmitting, to the RAN node, an UL PDU including UL data when a transmission is initiated to transmit the UL data, and performing a RA procedure when the transmission is initiated to transmit a MAC control element.

[0148] FIG. 6 is a flow chart of a method 600 that may be performed by a UE to resume a connection with a RAN, using a CB preconfigured grant configuration that may be broadcast in a SIB. The method 600 starts with step 504, which is described in FIG. 5. UE initiates transmission 607 of an RRC resume request message to resume a suspended connection with the RAN. Then, UE transmits 608 to the RAN a UL transmission, including the RRC resume request message, based on the CB preconfigured grant configuration. UE receives 612, from the RAN node, an RRC resume message in response to the RRC resume request message. UE transmits 616 an RRC resume complete message to the RAN node, in response to the RRC resume message. The UE resumes a suspended RRC connection with the RAN node, in accordance with the RRC connection resume message. In some embodiments, the connection includes at least one SRB (e.g., SRB1 and / or SRB2) and / or at least one DRB. By bypassing the preamble transmission and random access response steps (similar to the method of FIG. 5), the UE directly transmits the RRC connection resume request message, thereby reducing connection resume latency.

[0149] In some embodiments, the RRC connection resume request message includes a cause or indicator (also called “cause indicator” in this document), which may indicate emergency, mobile originated data, high priority access, mobile originated voice call, mobile originated exception data or delay tolerant access, mobile originated signaling, or mobile terminated access.

[0150] In some embodiments, the UE is in an idle state (e.g., RRC IDLE state with a suspended RRC connection) or in an inactive state (e.g., RRC INACTIVE state) and transmits the CB PUSCH transmission to the RAN and transitions to a connected state (e.g., RRC CONNECTED state) in response to receiving the RRC connection resume message. In some embodiments, the UE includes a UL NAS message in the RRC connection resume complete message. For example, the UL NAS message is a Service Request message, an Attach Request message, a Tracking Area Update Request message, a PDN Connectivity Request, a Registration Request message or a PDU Session Establishment Request message.

[0151] FIG. 7 if a flow chart of a method 700 that may be performed by a UE to reestablish a connection with a RAN, using a CB preconfigured grant configuration that may be broadcast in a SIB. The method 700 begins at block 504, which is described in FIG. 5. UE initiates transmission 707 of an RRC reestablishment request message to reestablish a connection withthe RAN. UE transmits 708 a UL transmission including the RRC reestablishment request message to the RAN node, based on the CB preconfigured grant configuration. UE receives 712, from the RAN node, an RRC reestablishment message in response to the RRC reestablishment request message. UE transmits 716 an RRC reestablishment complete message to the RAN node, in response to the RRC reestablishment message. The UE reestablishes an RRC connection with the RAN in accordance with the RRC connection reestablishment message. In some embodiments, the connection includes an SRB (e.g., SRB1). By bypassing the preamble transmission and random access response steps, the UE directly transmits the RRC connection reestablishment request message, thereby reducing connection reestablishment latency.

[0152] In some embodiments, the UE in a connected state (e.g., RRC CONNECTED state) transmits the CB PUSCH transmission to the RAN node, and remains in the connected state in response to receiving the RRC connection reestablishment message. In some embodiments, the UE performs an RRC connection reconfiguration procedure with the RAN node to reestablish another SRB (e.g., SRB2) and / or a DRB. The UE communicates security protected data with the RAN via the DRB after completing the RRC connection reconfiguration procedure. In this or other embodiments, the “RRC connection reconfiguration procedure” may be replaced by a “RRC reconfiguration procedure”.

[0153] FIG. 8A is a flow chart of a method 800A that may be performed by a UE to determine whether to transmit an RRC request message in a CB PUSCH transmission, based on a cause (indicator), to initiate a transmission of the RRC request message. The method 800A starts with the UE receiving 804 from a RAN node (e.g., the RAN 105 or the BS 104), a RACH configuration and a CB preconfigured grant configuration. The CB preconfigured grant configuration may be part of a SIB. UE initiates 806A a transmission of an RRC request message, where the RRC request message includes a cause (e.g., a cause indicator). In some embodiments, the UE does not have a valid time alignment value or a valid TA value when initiating the transmission. UE determines 822 whether the cause indicator indicates mobile originated data, mobile originated exception data, or delay tolerant access. If the cause indicator indicates mobile originated data, mobile originated exception data, or delay tolerant access (i.e., “Yes” branch of block 822), the method proceeds to block 808, where the UE transmits the RRCrequest message to the RAN, using the CB preconfigured grant configuration. Otherwise, if the cause indicates none of the mobile originated data, mobile originated exception data, and delay tolerant access (i.e., “No” branch of block 822), the method proceeds to block 824, where the UE performs a RA procedure with the RAN node, using the RACH configuration. Then, UE transmits 826 the RRC request message to the RAN node in the RA procedure.

[0154] For example, if the cause indicates mobile originated signaling or mobile terminated access, the UE performs the RA procedure with the RAN node using the RACH configuration. In cases where the RA procedure is a four-step RA procedure, the UE transmits the RRC request message in a Message 3 of the four-step RA procedure. In cases where the RA procedure is a two-step RA procedure, the UE transmits the RRC request message in a Message A of the two- step RA procedure. In some embodiments, the RRC request message is an RRC connection request message or an RRC resume request message. The descriptions for FIGs. 5 and 6 may apply or combine with the description for FIG. 8A.

[0155] FIG. 8B is a flow chart of a method 800B similar to the method 800A, except that the method 800B includes blocks 806B and 823 instead of blocks 806A and 822. At block 823, the UE determines whether the RRC request message is an RRC connection reestablishment request message. If the RRC request message is not an RRC connection reestablishment request message (i.e., “No” branch of block 823), the method proceeds to block 808. Otherwise, if the RRC request message is an RRC connection reestablishment request message (i.e., “Yes” branch of block 823), the method proceeds to block 824.

[0156] FIG. 8C is a flow chart of a method 800C similar to the methods 800A and 800B. If the RRC request message is an RRC connection reestablishment request message (i.e., “Yes” branch of block 823), the method proceeds to block 808. Otherwise, if the RRC request message is not an RRC connection reestablishment request message (i.e., “No” branch of block 823), the method proceeds to block 824.

[0157] FIG. 8D is a flow chart of a method 800D similar to the methods 800A and 800B, except that the method 800D includes block 821 instead of blocks 822 and 823. At block 821, the UE determines whether the RRC request message is an RRC early data request message. If the RRC request message is an RRC early data request message (i.e., “Yes” branch of block821), the method proceeds to block 808. Otherwise, if the RRC request message is not an RRC early data request message (i.e., “No” branch of block 821), the method proceeds to block 824. For example, the RRC request message is an RRC connection request message, an RRC connection resume request message, or an RRC connection reestablishment request message. Descriptions for FIGs. 5-7 may apply to FIGs. 8B, 8C, and 8D.

[0158] FIG. 9 is a flow chart of a method 900 that may be performed by a UE to determine whether to use a CB preconfigured grant configuration to transmit UL data. As previously discussed, the CB preconfigured grant configuration may be received at the UE in a SIB from the RAN node. The method 900 begins at block 804, which was described in FIG. 8A. UE initiates 906 a transmission of UL data. In some embodiments, the UE does not have a valid time alignment value or a valid TA value when initiating the transmission. UE determines 929 whether a transport block configured by the CB preconfigured grant configuration accommodates the UL data. If a transport block configured by the CB preconfigured grant configuration accommodates the UL data (i.e., “Yes” branch of block 929), the method proceeds to block 908, where the UE transmits, to the RAN node, a UL PDU including the UL data, using the CB preconfigured grant configuration. Otherwise, if none of the transport block(s) configured by the CB preconfigured grant configuration accommodates the UL data (i.e., “No” branch of block 929), the method proceeds to block 824, which was described in FIG. 8A. Then, the UE transmits 926, to the RAN, a UL PDU including the UL data according to the RA procedure. If the RA procedure is a four-step RA procedure, the UE transmits the UL PDU in a Message 3 of the four-step RA procedure. If the RA procedure is a two-step RA procedure, the UE transmits the UL PDU in a Message A of the two-step RA procedure. The “UL data” may be replaced by a “UL data packet”. Descriptions for FIGs. 5-8C may apply to FIG. 9.

[0159] FIG. 10 is a flow chart of a method 1000 that may be performed by a UE to determine whether to use a CB preconfigured grant configuration to transmit UL data. The method 1000 begins at block 804, which was described in FIG. 8 A. The UE then initiates 1006 a transmission and determines 1030 whether the transmission is initiated to transmit a MAC CE or UL data. If the UE determines that the transmission is initiated to transmit UL data (i.e., “UL data” branch of block 1030), the method proceeds to block 908. Otherwise, if the UE determines that thetransmission is initiated to transmit a MAC CE (i.e., “MAC CE” branch of block 1030), the method proceeds to block 824. Then, the UE transmits 1027 the MAC CE to the RAN node according to the RA procedure. In some embodiments, the UE generates a UL PDU including the MAC CE and transmits the UL PDU to the RAN according to the RA procedure at block 1027. Descriptions for FIGs. 5-9 may apply to FIG. 10. If the RA procedure is a four-step RA procedure, the UE transmits the MAC CE in a Message 3 of the four-step RA procedure. If the RA procedure is a two-step RA procedure, the UE transmits the MAC CE in a Message A of the two-step RA procedure.

[0160] FIG. 11 is a flow chart of a method 1100 that may be performed by a BS to establish a connection with a UE using a CB preconfigured grant configuration that may be broadcast to the UE in a SIB. The method 1100 starts with the BS transmitting 1104 a CB preconfigured grant configuration followed by the optional transmission 1132 of a paging message to the UE. In response to the paging message, the UE performs a CB PUSCH transmission, which is received 1108 by the BS and the CB PUSCH transmission includes an RRC connection request message from the UE, based on the CB preconfigured grant configuration. In other words, if the BS transmits the paging message, the BS may receive the RRC connection request message in response to the paging message. In such cases, the RRC connection request message includes a cause (or indicator) indicating mobile terminated access. Otherwise, the RRC connection request message may include a cause indicating emergency, mobile originated data, high priority access, mobile originated voice call, mobile originated exception data or delay tolerant access, or mobile originated signaling. BS transmits 1112, to the UE, an RRC connection setup message in response to the RRC connection request message. BS receives 1116 an RRC connection setup complete message from the UE in response to the RRC connection setup message.

[0161] A wireless communication method performed by a RAN node that relies on the embodiment illustrated in FIG. 11 includes transmitting 1104, to a UE, a CB preconfigured grant configuration as part of a SIB, receiving 1108 from the UE, based on the CB preconfigured grant configuration, a CB PUSCH transmission including an RRC request message, and transmitting 1112 to the UE an RRC response message. In one embodiment, the RRC request message is an RRC connection request message and the RRC response message is an RRC connection setupmessage. In another embodiment, the RRC request message is an RRC resume request message and the RRC response message is an RRC resume message. In yet another embodiment, the RRC request message is an RRC reestablishment request message and the RRC response message is an RRC reestablishment message. The CB preconfigured grant configuration includes at least one of an uplink, UL, time domain resource configuration, a UL frequency domain resource configuration, a power control configuration, a redundancy version for repetitions configuration, an orthogonal cover code configuration, a contention resolution information configuration, a UL transmission timing configuration, or a UL transmission power configuration. The method may further include transmitting a paging message to the UE, and / or receiving an RRC complete message from the UE.

[0162] FIG. 12 is a flow chart of a method 1200 that may be performed by a BS to resume a connection with a UE using a CB preconfigured grant configuration. The method 1200 begins with blocks 1104 and 1132, which were described in FIG. 11. The BS receives 1208 a CB PUSCH transmission including an RRC connection resume request message from the UE, based on the CB preconfigured grant configuration. If the BS transmits the paging message, the BS may receive the RRC connection resume request message in response to the paging message. In such cases, the RRC connection resume request message includes a cause indicating a mobile terminated access. Otherwise, the RRC connection resume request message may include a cause indicating an emergency, mobile originated data, high priority access, mobile originated voice call, mobile originated exception data or delay tolerant access, or mobile originated signaling. Then, the BS transmits 1212, to the UE, an RRC connection resume message in response to the RRC connection resume request message. Next, the BS receives 1216 an RRC connection resume complete message from the UE in response to the RRC connection resume message.

[0163] FIG. 13 is a flow chart of a method 1300 that may be performed by a BS to reestablish a connection with a UE using a CB preconfigured grant configuration. The method 1300 begins at block 1304, which was described in FIG. 11. Then, the BS receives 1308 a CB PUSCH transmission, including an RRC connection reestablishment request message, from the UE, based on the CB preconfigured grant configuration. BS transmits 1312, to the UE, an RRC connection reestablishment message in response to the RRC connection reestablishment request message.BS receives 1316 an RRC connection reestablishment complete message from the UE, in response to the RRC connection reestablishment message. The descriptions for FIGs. 5-7 may apply to FIG. 11-13.

[0164] FIG. 14 is a flow chart of a method 1400 that may be performed by a UE to achieve early data transmission and an RRC connection procedure with the RAN node, using a CB preconfigured grant configuration and a RACH configuration, respectively. As previously mentioned, the CB preconfigured grant configuration may be broadcast by the RAN node via a SIB. The method 1400 begins with block 804, which was described in FIG. 8 A. UE initiates 1406 an early data transmission procedure with the RAN node. Then, the UE transmits 1408 a CB PUSCH transmission, including UL data, to the RAN node, based on the CB preconfigured grant configuration, in response to initiating the early data transmission procedure. Next, the UE initiates 1407 an RRC connection procedure with the RAN node. UE performs 1424 a random access procedure with the RAN node, based on the RACH configuration, in response to initiating the RRC connection procedure. The UE transmits 1426 an RRC request message of the RRC connection procedure to the RAN node during the RA procedure.

[0165] In some embodiments, the RRC connection procedure is an RRC connection establishment procedure and the RRC request is an RRC connection request message. In some embodiments, the RRC connection procedure is an RRC connection resume procedure and the RRC request is an RRC connection resume request message. In some embodiments, the RRC connection procedure is an RRC connection reestablishment procedure and the RRC request is an RRC connection reestablishment request message. The descriptions for FIGs. 5 to 13 may apply to FIG. 14.

[0166] A wireless communication method performed by a UE based on the embodiment illustrated in FIG. 14 includes receiving 804, from a RAN node a RACH configuration and a CB preconfigured grant configuration broadcast in a system information block, initiating 1406 an early data transmission procedure with the RAN node, and transmitting 1408, to the RAN node, a CB PUSCH, transmission including UL data, based on the CB preconfigured grant configuration, in response to the initiating. The method may further include preparing 1407 an RRC connection procedure with the RAN node, and performing 1424 a RA procedure with theRAN node based on the RACH configuration. The method may further include transmitting 1426 an RRC request message to the RAN node in the RA procedure. The CB preconfigured grant configuration includes at least one of: a UL time domain resource configuration, a UL frequency domain resource configuration, a power control configuration, a redundancy version for repetitions configuration, an orthogonal cover code configuration, a contention resolution information configuration, a UL transmission timing configuration, or a UL transmission power configuration. The method may also include transmitting a paging message to the UE and / or receiving an RRC complete message from the UE.

[0167] FIG. 15 is a flow chart of a method 1500 that may be performed by a BS to achieve early data transmission and an RRC connection procedure with UEs using a CB preconfigured grant configuration (broadcast with a SIB) and a RACH configuration respectively. The method 1500 starts with the BS transmitting 1504 a RACH configuration and a CB preconfigured grant configuration via a cell. The BS receives 1508 a CB PUSCH transmission including UL data, from a first UE (e.g., the UE 102), based on the CB preconfigured grant configuration. Then, the BS performs 1524 a RA procedure with a second UE based on the RACH configuration. Next, the BS receives 1726 an RRC request message of an RRC connection procedure from the second UE, according to the random access procedure. The descriptions for FIGs. 5-14 may apply to FIG. 15.

[0168] In some embodiments, the first UE and the second UE are the same UE. In other embodiments, the first UE and the second UE are different UEs. In some embodiments, the CB PUSCH transmission includes an RRC early data request message. In some embodiments, the UL data is included in the RRC early data request message. In other embodiments, the CB PUSCH transmission includes an RRC (connection) resume request message. In some embodiments, the UL data is a user-plane data packet (e.g., an IP packet, Ethernet packet, a short message service (SMS) message, or a native data packet or message). In some embodiments, the user-plane data packet is included in a UL NAS message and the CB PUSCH transmission includes the UL NAS message. In some embodiments, the UL NAS message is included in the RRC early data request message.

[0169] A method for wireless communication performed by a RAN node, based on the embodiment illustrated in FIG. 15 includes transmitting 1504, to a first UE, a RACH configuration and a CB preconfigured grant configuration (e.g., broadcast with a SIB), receiving 1508, from the first UE, a CB PUSCH transmission including UL data, based on the CB preconfigured grant configuration, and performing 1524 a RA procedure with a second UE based on the RACH configuration. The method may further include receiving an RRC request message for an RRC connection procedure, from the second UE for the RA procedure. The CB preconfigured grant configuration includes at least one of UL time configuration, UL frequency configuration, power control configuration, redundancy version for repetitions configuration, orthogonal cover code configuration, a contention resolution information for different UEs configuration, UL transmission timing configuration, or UL transmission power configuration.

[0170] FIG. 16 is a frequency -time graph illustrating a CB preconfigured grant configuration for a cell. In this CB preconfigured grant configuration, a BS (e.g., BS 104) configures a CB PUSCH occasion 1, 1650, that occurs periodically with a periodicity T. In CB preconfigured grant configuration, the BS specifies (i.e., indicates or includes) a time location of the CB PSUCH occasion 1 in the time domain. The time location may be defined using a starting time point (e.g., a starting slot or subframe) and / or the number of (consecutive) time units (e.g., slots or subframes). The CB preconfigured grant configuration may include an offset defining the starting point relative to the start of the period. In some embodiments, the CB PUSCH occasion 1 includes P (consecutive) slots or subframes, where P is an integer larger than zero (e.g., P is one of 1, 2, . .. , 16, or P is an even number). In one embodiment, the CB preconfigured grant configuration specifies the number P or the number (P - / ).

[0171] Further, the BS also configures the frequency location of the CB PSUCH occasion 1, 1650, in the frequency domain. The frequency location may be specified using a starting subcarrier or PRB and / or a bandwidth (e.g., one or more subcarriers or PRBs). In some embodiments, the bandwidth consists of S subcarriers, where S is an integer larger than zero (e.g., S is one of 1, 2, .. ., 18). The CB preconfigured grant configuration then specifies the number S or the number (S- / ). In other embodiments, the CB PUSCH occasion 1 includes UPRBs, where U is an integer larger than zero (e.g., U is one of 1, 2, . . 300). The CB preconfigured grant configuration then specifies the number U or the number (U- 7).

[0172] The BS 104 may configure one or more additional CB PUSCH occasions in the CB preconfigured grant configuration. None of the CB PUSCH occasion 1 and the additional CB PUSCH occasion(s) overlap with one another in frequency and time. The additional CB PUSCH occasion(s) may include the same slots or subframes as the CB PUSCH occasion 1. For example, as illustrated in FIG. 16, a CB PUSCH occasion 2, 1652, has the same time parameters (i.e., location within the period and periodicity) as CB PUSCH occasion 1. Thus, the CB PUSCH occasion 2 includes P (consecutive) slots or subframes.

[0173] The BS also specifies a frequency location of each of the additional CB PUSCH occasion(s) in the frequency domain. As in the case of the CB PUSCH occasion 1, this frequency location may include a starting subcarrier or PRB and / or a bandwidth (e.g., one or more subcarriers or PRBs). In some embodiments, the CB preconfigured grant configuration also specifies a guard band between two consecutive CB PUSCH occasions (e.g., guard band 1651 between the CB PUSCH occasion 1 and the CB PUSCH occasion 2). The bandwidth of the guard band may be one or more subcarriers or PRBs. The guard bands between pairs of consecutive CB PUSCH occasions may be the same or different.

[0174] In some embodiments, the additional CB PUSCH occasion(s) have the same bandwidth (e g., the same number of subcarriers or PRBs) as the CB PUSCH occasion 1. In other embodiments, the CB preconfigured grant configuration specifies a total number of CB PUSCH occasions (i.e., the CB PUSCH occasion 1 and the additional CB PUSCH occasion(s)) in the frequency domain in each period. In yet other embodiments, the CB preconfigured grant configuration specifies a total number of the additional CB PUSCH occasion(s) in the frequency domain in each period. In some embodiments, the CB preconfigured grant configuration indicates a starting subcarrier or PRB for CB PUSCH occasion 1 and the number S or U. The BS and UE(s) determine a frequency location for each of the additional CB PUSCH occasion(s) based on the starting subcarrier or PRB, the number S or U, the total number of the (additional) CB PUSCH occasion(s), and / or the guard band(s).

[0175] Some or all of the additional CB PUSCH occasion(s) may include different number(s) of subcarriers or PRBs from the CB PUSCH occasion 1 . In such cases, the CB preconfigured grant configuration specifies the number of subcarriers or PRBs for the CB PUSCH occasion(s) with different number(s) of subcarriers or PRBs. For example, the CB preconfigured grant configuration specifies the number of subcarriers or PRBs for the CB PUSCH occasion 2 in the same manner as described above for the CB PUSCH occasion 1. The BS and UE(s) determine a frequency location for each of the additional CB PUSCH occasion(s) based on the starting subcarrier or PRB, the number of subcarriers or PRBs for the each of the additional CB PUSCH occasion(s), and / or the guard band.

[0176] In some embodiments, the BS configures a first UE to transmit a non-CB PUSCH transmission on a non-CB PUSCH occasion 1654, where the first UE is UL synchronized with the BS. The bandwidth of the non-CB PUSCH occasion 1654 may be wider than, narrower than, or equal to the bandwidth of the CB PUSCH occasions 1 (labeled 1650) and 2 (labeled 1652). For example, the BS transmits a DCI including a UL grant to the first UE, configuring the first UE to transmit the non-CB PUSCH transmission on a non-CB PUSCH occasion 1654. The first UE transmits the non-CB PUSCH transmission on the non-CB PUSCH occasion in accordance with the DCI. In another example, the BS transmits an RRC message (e.g., an RRC reconfiguration message) to the first UE, including a configured grant configuration configuring the first UE to transmit the non-CB PUSCH transmission on the non-CB PUSCH occasion 1654. The first UE transmits the non-CB PUSCH transmission on the non-CB PUSCH occasion in accordance with the configured grant configuration. The BS may also configure a guard time 1656 between the CB PUSCH occasion(s) 1 and / or 2 and the non-CB PUSCH occasion 1654. A second UE (other than the first UE) may transmit a CB PUSCH transmission on the CB PUSCH occasion 1 (1650). Because the second UE is not UL synchronized with the BS on the cell, when the CB PUSCH transmission arrives at the BS, a portion of the CB PUSCH transmission may overlap the guard time. Because the non-CB PUSCH transmission does not overlap with guard time, the CB PUSCH transmission does not interfere with the non-CB PUSCH transmission. That is, by configuring the guard time, the BS ensures that a non-CB PUSCH transmission does not overlap with a CB PUSCH transmission. In some embodiments, a non-CB PUSCHtransmission (e.g., the non-CB PUSCH transmission 1654) following a CB PUSCH occasion (e g., the CB PUSCH occasion 1650) is shorter than the CB PUSCH occasion in the time domain. In other embodiments, the BS refrains from configuring a short non-CB PUSCH occasion / transmission (i.e., non-CB PUSCH occasion 1654) shorter than a normal non-CB PUSCH occasion / transmission (e.g., non-CB PUSCH occasion 1658). In such cases, the time period from the end of CB PUSCH occasion 1650 to the end of the period T may be considered a guard time.

[0177] In some embodiments, the BS configures a third UE to transmit a non-CB PUSCH transmission on the non-CB PUSCH occasion 1658. The non-CB PUSCH occasion / transmission 1658 may include P slots. The non-CB PUSCH occasion / transmission 1658 may last longer than the non-CB PUSCH transmission 1654 and / or than the CB PUSCH occasion. The third UE and the first UE may the same UE or different UEs. Above-described features related to the non-CB PUSCH occasion 1654 are pertinent for the non-CB PUSCH occasion 1658.

[0178] In some embodiments, the CB preconfigured grant configuration includes an association configuration configuring an association between a Synchronization Signal / physical broadcast channel (PBCH) block (SSB) and a CB PUSCH occasion. The association configuration may configure multiple SSBs to be associated with a particular CB PUSCH occasion. For example, the association configuration associates SSBs 0... V with the CB PUSCH occasion 1, where Eis an integer larger than zero. If the CB PUSCH occasion 2 is configured, the association configuration may associate the SSBs V+l, . . ., V+ W with the CB PUSCH occasion 2, where ff is an integer larger than zero. The association configuration may specify a one-to-one association between a particular SSB and a particular CB PUSCH occasion. In other words, the association configuration configures each of SSBs to be associated with a corresponding CB PUSCH occasion. For example, the association configuration configures SSB 0 to be associated with the CB PUSCH occasion 1 (1650) and SSB 1 to be associated with the CB PUSCH occasion 2 (1652). The association configuration may configure SSB 2 to be associated with the CB PUSCH occasion 1 (1660) in the next period and SSB 3 to be associated with the CB PUSCH occasion 2 (1662) in the next period. Alternatively, the association configuration configures SSB 0 to be associated with the CB PUSCH occasion 1 (1660) and SSB1 to be associated with the CB PUSCH occasion 2 (1662). In yet other embodiments, the association configuration configures an SSB to be associated with multiple CB PUSCH occasions. For example, the association configuration configures SSB 0 to be associated with the CB PUSCH occasion 1 and the CB PUSCH occasion 2.

[0179] The BS transmits (e.g., broadcasts) the SSBs described above via the cell. The UE (e.g., the UE 102) may select a CB PUSCH occasion based on an associated SSB received by the UE and transmit a CB PUSCH transmission on the selected CB PUSCH occasion (e.g., event(s) 408-1, .. ., 408-M). In some embodiments, if a signal strength or quality of an SSB received by the UE is above a threshold, the UE selects a CB PUSCH occasion associated with the SSB. Otherwise (i.e., the signal strength or quality is below the threshold), the UE does not select the CB PUSCH occasion associated to the SSB. In some embodiments, the UE does not select a CB PUSCH occasion if the UE does not receive a SSB associated with the CB PUSCH occasion.

[0180] In some embodiments, the CB preconfigured grant configuration configures transport block sizes for the CB PUSCH occasions (e.g., the CB PUSCH occasion 1 and the additional CB PUSCH occasion(s)) in the frequency domain and / or in the time domain. For example, the CB preconfigured grant configuration specifies different numbers of subcarriers or PRBs and / or different modulation and coding schemes (MCSs) for the CB PUSCH occasions, which causes different transport block sizes. The UE may select a CB PUSCH occasion with a transport block size that can accommodate a volume of UL data to be transmitted by the UE. For example, the CB preconfigured grant configuration configures a transport block size 1 and a transport bock size 2 for the CB PUSCH occasion 1 and the CB PUSCH occasion 2, respectively. When the transport block size 1 is larger than the transport block size 2, if the UE has a UL data packet to transmit and the transport block size 2 can accommodate a size of the UL data packet but the transport block size 1 cannot, the UE selects the CB PUSCH occasion 2 to transmit the UL data packet. In another example, the CB preconfigured grant configuration configures a transport block size 1 and a transport bock size 2 for the CB PUSCH occasion 1652 and the CB PUSCH occasion 1662, respectively. When the transport block size 1 is larger than the transport block size 2, if the UE has a UL data packet to transmit and the transport block size 2 may accommodate a size of the UL data packet but the transport block size 1 cannot, the UE selectsthe CB PUSCH occasion 1662 to transmit the UL data packet. The UE may select a CB PUSCH occasion based on a received SSB and a size of UL data to be transmitted as described above.

[0181] In some embodiments, the one or more CB PUSCH occasion(s) in each period are at different time locations within the period. In other embodiments, all the CB PUSCH occasion(s) are at the same time location in all periods.

[0182] FIG. 17 is another frequency -time graph illustrating a CB preconfigured grant configuration for a cell, similar to FIG. 16. The CB PUSCH occasion 1 labeled 1750 and the CB PUSCH occasion 2 labeled 1752 in FIG. 17 last less than the CB PUSCH occasion 1 (1650) and the CB PUSCH occasion 2 (1652) in FIG. 16. The duration of the CB PUSCH occasions in FIG. 16 is one or multiple slots. The duration of the CB PUSCH occasions in FIG. 17 may be shorter than a slot or not a multiple of slot duration. The BS configures a guard time 1756 complementary to the shorter CB-PUSCH occasion duration and a non-CB PUSCH transmission 1754 longer than the non-CB PUSCH occasion 1754. In the scenario illustrated in FIG. 17, the non-CB PUSCH transmission 1754 lasts substantially the same as the non-CB PUSCH occasion 1758 but has a different bandwidth. The non-CB PUSCH occasion / transmission 1754 is longer than the CB PUSCH occasion (s) 1750 and / or 1752 in the time domain. Unless otherwise configured, the CB PUSCH occasions 1760 and 1762 as well as the guard time 1766 repeat the frequency-time pattern described for the CB PUSCH occasions 1750 and 1752 with guard time 1756.

[0183] The following description may be applied to any of the embodiments discussed above. The description for any one of the above figures can apply to another of the above figures. Examples, embodiments, and methods described above may be combined, if there is no conflict. An event or block or step described above may be optional or omitted. For example, an event or block with dashed lines in the figures can be optional. In some embodiments, the term “message” is used and can be replaced by “information element (IE)”, and vice versa. In some embodiments, “IE” is used and can be replaced by “field”, and vice versa. In some embodiments, “configuration” can be replaced by “configurations” or “configuration parameters”, and vice versa. In some embodiments, the “longer timer value” and the “normal timer value” can be replaced by a first timer value and a second timer value respectively. In some embodiments, the“normal timer value” can be replaced by a “legacy timer value”. In some embodiments, the “function” can be replaced by a “feature”. The descriptions above may apply to communications without involving a satellite (i.e., 6G communications in a terrestrial network). In some embodiments, the “PUSCH” can be replaced by a “Narrowband PUSCH (NPUSCH)”. In some embodiments, the “PDCCH” can be replaced by “Machine Type Communication PDCCH (MPDCCH)” or “Narrowband PDCCH (NPDCCH)”. In some embodiments, the “orthogonal cover code” or “OCC” can be replaced by an “orthogonal code”.

[0184] A user device in which the techniques of this disclosure may be performed (e.g., the UE 102) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media-streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an internet-of-things (loT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0185] Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules may be software modules (e.g., code, or machine-readable instructions stored on non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module may include dedicated circuitry or logic that is permanently configured (e.g., as a special -purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), a digital signal processor (DSP), etc.) to perform certain operations. A hardware module may also include programmable logic or circuitry (e.g., as encompassed within a general -purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanentlyconfigured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[0186] When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general-purpose processors or one or more specialpurpose processors.

[0187] Numerical adjectives “first”, “second”, and “third” do not imply any order (are not ordinals) but are markers to distinguish separate instances of similar elements. References to the singular (e.g., “a” or “an”, “the”) should include the plural unless clearly indicated otherwise.

[0188] As used herein, a phrase referring to “at least one of’ or “one or more of’ a list of items refers to any combination of those items, including single members. For example, “at least one of: a, b, or c” is intended to cover the possibilities of: a only, b only, c only, a combination of a and b, a combination of a and c, a combination of b and c, and a combination of a and b and c.

[0189] Although the features and elements of the present embodiments are described in the embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the embodiments or in various combinations with or without other features and elements disclosed herein. The methods or flowcharts may be implemented in a computer program, software or firmware tangibly embodied in a computer-readable storage medium for execution by a specifically programmed computer or processor.

Claims

What is claimed is:

1. A wireless communication method performed by a user equipment, UE, (102), the method comprising: receiving (504) a contention-based, CB, preconfigured grant configuration broadcast in a system information block, from a radio access network, RAN, node (104); preparing to transmit (507), to the RAN node (104), a CB physical uplink shared channel, PUSCH, transmission including a radio resource control, RRC, request message; and receiving (512) from the RAN node (104) an RRC response message.

2. The method of Claim 1, wherein the RRC request message is an RRC connection request message and the RRC response message is an RRC connection setup message.

3. The method of Claim 1, wherein the RRC request message is an RRC resume request message and the RRC response message is an RRC resume message.

4. The method of Claim 1, wherein the RRC request message is an RRC reestablishment request message and the RRC response message is an RRC reestablishment message.

5. The method of any of Claims 1 to 4, wherein the CB preconfigured grant configuration includes at least one of an uplink, UL, time domain resource configuration, a UL frequency domain resource configuration, a power control configuration, a redundancy version for repetitions configuration, an orthogonal cover code configuration, a contention resolution information configuration, a UL transmission timing configuration, or a UL transmission power configuration.

6. The method of any of Claims 1 to 5, further comprising: transmitting the CB PUSCH transmission including the RRC, request message; and transmitting an RRC complete message to the RAN node.

7. The method of any of Claims 1 to 5, further comprising: receiving a random access channel, RACH, configuration, wherein the RRC request message includes a cause indication.

8. The method of Claims 7, further comprising: transmitting the RRC request message to the RAN node when the cause indication is related to mobile originated data, mobile originated exception data, or delay tolerant access; and performing a random access procedure, based on the RACH configuration, when the cause indication is not related to mobile originated data, mobile originated exception data, or delay tolerant access.

9. The method of any of Claims 1 to 5, further comprising: receiving a random access channel, RACH, configuration; transmitting the RRC request message to the RAN node when the RRC request message is not an RRC connection reestablishment request message; and performing a random access procedure when the RRC request message is an RRC connection reestablishment request message.

10. The method of any of Claims 1 to 5, further comprising: receiving a random access channel, RACH, configuration; transmitting the RRC request message to the RAN node when the RRC request message is an RRC connection establishment request message; and performing a random access procedure when the RRC request message is different from an RRC connection reestablishment request message.11 . The method of any of Claims 1 to 5, further comprising: receiving a random access channel, RACH, configuration; transmitting the RRC request message to the RAN node when the RRC request message is an RRC early data request message; and performing a random access procedure when the RRC request message is different from an RRC early data request message.

12. The method of any of Claims 1 to 5, further comprising: receiving a random access channel, RACH, configuration; transmitting, to the RAN node, an uplink, UL, packet data unit, PDU, including UL data, when a transport block configured by the CB preconfigured grant configuration accommodates the UL data; and performing a random access procedure when the transport block does not accommodate the UL data.

13. The method of any of Claims 1 to 5, further comprising: receiving a random access channel, RACH, configuration; transmitting, to the RAN node, an uplink, UL, packet data unit, PDU, including UL data when a transmission is initiated to transmit the UL data; and performing a random access procedure when the transmission is initiated to transmit a medium access control, MAC, control element.

14. A wireless communication method performed by a radio access network, RAN, node (104), the method comprising: transmitting (1104), to a user equipment, UE, (102), a contention-based, CB, preconfigured grant configuration as part of a system information block;receiving (1108) from the UE (102), based on the CB preconfigured grant configuration, a CB physical uplink shared channel, PUSCH, transmission including a radio resource control, RRC, request message; and transmitting (1112) to the UE (102) an RRC response message.

15. The method of Claim 14, wherein the RRC request message is an RRC connection request message and the RRC response message is an RRC connection setup message.

16. The method of Claim 14, wherein the RRC request message is an RRC resume request message and the RRC response message is an RRC resume message.

17. The method of Claim 14, wherein the RRC request message is an RRC reestablishment request message and the RRC response message is an RRC reestablishment message.

18. The method of any of Claims 14 to 17, wherein the CB preconfigured grant configuration includes at least one of an uplink, UL, time domain resource configuration, a UL frequency domain resource configuration, a power control configuration, a redundancy version for repetitions configuration, an orthogonal cover code configuration, a contention resolution information configuration, a UL transmission timing configuration, or a UL transmission power configuration.

19. The method of any of Claims 14 to 18, further comprising: transmitting a paging message to the UE, and receiving an RRC complete message from the UE.

20. A communication device (104, 102) comprising a transceiver (134, 136, 1 4, 156), a processor (132, 152) and computer-readable storage media (131, 151) storing executable instructions for the processor to perform any of the methods recited in claims 1-19, using the transceiver.

Citation Information

Patent Citations

  • Method, user equipment, base station, device and medium for contention-based uplink data transmission

    US20220210816A1