System and method for configuring transmission resources and implementing RACH in a wireless communication network

Abstract

To provide a system and a method for constructing a transmission resource and executing a RACH in a radio communication network.SOLUTION: A system and a method for a communication between a radio communication device and a radio communication node on the basis of the use of a timing advance (TA) estimated by the radio communication device. In the system and the method, the use of the timing advance estimated by the radio communication device for the communication with the radio communication node is determined, a RACH type for communication with the radio communication node is selected by the radio communication device, and a RACH communication with the radio communication node is started in accordance with the determination in regard to the use of the TA estimated by the selected RACH type and the radio communication device by the radio communication device.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present disclosure generally relates to wireless communication, and more specifically, to a system and method for configuring transmission resources and performing random access channel (RACH) communication in a wireless communication network.

Background Art

[0002] A wireless communication network can include network communication devices and network communication nodes. In some cases, the network communication devices can be terrestrial, and at least one of the network communication nodes can be non-terrestrial, such as being onboard a satellite, for example.

Summary of the Invention

Means for Solving the Problems

[0003] The exemplary embodiments disclosed herein are directed to solving one or more problems related to problems presented in the prior art and providing additional features that will be readily apparent by reference to the following forms for implementing the following inventions when considered in connection with the accompanying drawings. According to various embodiments, exemplary systems, methods, devices, and computer program products are disclosed herein. However, it is understood that these embodiments are presented by way of example and not limitation, and that various modifications to the disclosed embodiments can be made within the scope of the present disclosure, which will be apparent to those skilled in the art upon a thorough reading of the present disclosure.

[0004] In one embodiment, a method implemented by a first wireless communication node includes a wireless communication device determining the use of a timing advance (TA) estimated by the wireless communication device for communication with the wireless communication node. The method further includes the wireless communication device selecting a RACH type for communication with the wireless communication node. The method also includes the wireless communication device initiating RACH communication with the wireless communication node according to the decision regarding the selected RACH type and the use of a TA estimated by the wireless communication device.

[0005] In another embodiment, a method implemented by a wireless communication device includes the wireless communication device performing a cell lookup within a communication cell with respect to a communication signal. The method further includes the wireless communication device detecting an instruction that system information is to be transmitted according to a satellite beam base configuration. The method also includes the wireless communication device accessing the system information according to a satellite beam base configuration.

[0006] In another embodiment, a method implemented by a wireless communication node includes the wireless communication node transmitting RACH resource configuration information indicating the use of a timing advance (TA) estimated by the wireless communication node. The method further includes the wireless communication node receiving a Msg1 of the RACH procedure from a wireless communication device. The method also includes the wireless communication node transmitting a response message including a TA indicator to the wireless communication device in response to receiving the Msg1 of the RACH procedure.

[0007] The above and other aspects and their implementation will be described in detail in the drawings, description and claims. The present invention provides, for example, the following: (Item 1) A method, wherein the said method is The wireless communication device determines the use of a timing advance (TA) estimated by the wireless communication device for communication with the wireless communication node, The wireless communication device selects the RACH type for communicating with the wireless communication node, The wireless communication device initiates RACH communication with the wireless communication node in accordance with the selected RACH type and the decision regarding the use of the TA estimated by the wireless communication device. Methods that include... (Item 2) The RACH type is the method described in item 1, which corresponds to a 4-step RACH. (Item 3) The RACH type is the method described in item 1, which corresponds to a 2-step RACH. (Item 4) The wireless communication device decides to use the TA estimated by the wireless communication device for communication with the wireless communication node, The wireless communication device initiates the RACH communication by transmitting a message to the wireless communication node according to the estimated TA. The method described in any of items 1-3, further including the method described in any of items 1-3. (Item 5) The wireless communication device monitors the reception of scheduling information from the wireless communication node for receiving response messages in a configuration control resource set (CORESET) accompanied by a random access wireless network temporary identifier (RA-RNTI), The wireless communication device receives a response message from the wireless communication node in accordance with the received scheduling information. The method described in item 4, further including the method described in item 4. (Item 6) The method of any one of items 1-4, further comprising determining the use of the TA estimated by the wireless communication device according to RACH resource configuration information from the wireless communication node prior to initiating the RACH communication. (Item 7) The method according to item 6, further comprising receiving the RACH resource configuration information from the wireless communication node via at least one of broadcast information or RRC signaling information. (Item 8) The RACH resource configuration information described above includes the configuration of one or more RACH resource pools, as described in item 6. (Item 9) The method according to item 8, further comprising determining the use of the TA estimated by the wireless communication device in accordance with the presence of multiple RACH resource pools. (Item 10) The method according to item 8, wherein the configuration of one or more RACH resource pools includes at least one TA use enabled indicator, and the method further includes determining the use of the TA estimated by the wireless communication device according to the TA use enabled indicator. (Item 11) The method according to item 8, wherein the configuration of the RACH resource pool includes at least one RACH type indicator, and the method further includes selecting the RACH type according to the at least one RACH indicator. (Item 12) The method of item 5, further comprising determining the search space according to control resource configuration information received from the wireless communication node prior to initiating the RACH communication by the wireless communication device. (Item 13) The method according to item 12, wherein the control resource configuration information includes the configuration of one or more CORESETs and a mapping relationship between the CORESETs and a RACH resource pool, and the method further comprises determining which CORESETs should be used according to the RACH resource pool selected to start RACH and the mapping relationship. (Item 14) The method according to any one of items 1-13, further comprising determining, by the wireless communication device, at least one parameter of a timing window for response messages received from the network communication node, in accordance with the use of the TA estimated by the wireless communication device. (Item 15) The method according to item 1, wherein the wireless communication node includes a satellite-based node. (Item 16) A method, wherein the said method is The wireless communication device performs cell lookup within the communication cell regarding the communication signal, The wireless communication device detects an instruction that system information is transmitted according to a satellite beam-based configuration, The wireless communication device accesses the system information according to the configuration of the satellite beambase. Methods that include... (Item 17) The system information is the method described in item 16, which indicates at least one transmission resource. (Item 18) The satellite beambase configuration as described in item 16, wherein different components of the system information are transmitted over different satellite beams. (Item 19) The satellite beambase configuration as described in item 16, wherein different components of the system information are transmitted through different groups of at least one satellite beam. (Item 20) The wireless communication device obtains synchronization information from the cell search, Based on obtaining synchronization information via the aforementioned wireless communication device, communication information is received from a satellite network communication node. The wireless communication device processes the communication information and accesses the system information according to the satellite beambase configuration. The method described in item 16, including the method described in item 16. (Item 21) decoding, by the wireless communication device, a master information block (MIB); determining, by the wireless communication device, a satellite beam-based configuration according to an indicator in the MIB; The method according to item 16, further comprising. (Item 22) determining, by the wireless communication device, a terrestrial public mobile communication network (PLMN) associated with the communication cell; determining, by the wireless communication device, a satellite beam-based configuration according to an instruction of the PLMN; The method according to item 16, further comprising. (Item 23) The method according to item 16, further comprising determining, by the wireless communication device, configuration information common to two or more satellite beams included in a system information block. (Item 24) A method, the method comprising: transmitting, by a wireless communication node, RACH resource configuration information indicating use of a timing advance (TA) estimated by the wireless communication node; receiving, by the wireless communication node, Msg1 of a RACH procedure from the wireless communication device; transmitting, by the wireless communication node, a response message including a TA indicator to the wireless communication device in response to receiving Msg1 of the RACH procedure; The method comprising: (Item 25) transmitting, by the wireless communication node, configuration information of separate control resource sets (CORESETs) regarding a RACH with use of a TA estimated by the wireless communication device and a RACH without use of a TA estimated by the wireless communication device, prior to the receiving, by the wireless communication node, of Msg1 of the RACH procedure from the wireless communication device; The aforementioned wireless communication node transmits scheduling information to the corresponding CORESET in RACH according to the use of TA estimated by the wireless communication node, The wireless communication node transmits the response message to the wireless communication device according to the scheduling information. The method described in item 24, including the method described in item 24. (Item 26) The method according to item 24, wherein the wireless communication node transmits the RACH resource configuration information via at least one of broadcast information or RRC signaling information prior to receiving the RACH communication from the wireless communication device. (Item 27) The RACH resource configuration information described above includes the configuration of one or more RACH resource pools, as described in item 24. (Item 28) The use of the TA estimated by the wireless communication node is as described in item 27, according to the presence of multiple RACH resource pools. (Item 29) The method according to item 27, wherein the use of the TA estimated by the wireless communication node is indicated based on at least one TA use enabled indicator included in the configuration of one or more RACH resource pools. (Item 30) The method according to item 27, wherein the configuration of the at least one RACH resource pool includes at least one RACH type indicator, and the method further includes receiving the RACH communication corresponding to the RACH type indicator from the wireless communication device. (Item 31) The method described in item 24, wherein the wireless communication node includes a satellite-based node. (Item 32) Prior to receiving the RACH communication from the wireless communication device, the wireless communication node transmits an instruction that system information be transmitted according to a satellite beam-based configuration. The wireless communication node receives the RACH communication from the wireless communication device in accordance with the satellite beam-based configuration. The method described in item 24, including the method described in item 24. (Item 33) The system information is the method described in item 32, which indicates at least one transmission resource. (Item 34) The satellite beambase configuration as described in item 32, wherein different components of the system information are transmitted over different satellite beams. (Item 35) The method according to item 32, wherein the satellite beambase configuration indicates that different components of the system information are transmitted through different groups of at least one satellite beam. (Item 36) The method of item 32, wherein the wireless communication node transmits synchronization information for accessing the satellite beam-based configuration prior to receiving the RACH communication from the wireless communication device. (Item 37) The method according to item 32, wherein the wireless communication node transmits a master information block (MIB) including the satellite beam-based configuration indicator prior to receiving the RACH communication from the wireless communication device. (Item 38) Prior to receiving the RACH communication from the wireless communication device, the wireless communication node transmits the satellite beam-based configuration indicator via the terrestrial public mobile communication network (PLMN) associated with the communication cell. The wireless communication node receives the RACH communication from the wireless communication device according to the satellite beam-based configuration indicator. The method described in item 32, including the method described in item 32. (Item 39) The method according to item 32, wherein the wireless communication node transmits common configuration information to two or more satellite beams in a system information block prior to receiving the RACH communication from the wireless communication device. (Item 40) A computer-readable storage medium storing instructions, wherein, when executed by one or more processors, the instructions cause the one or more processors to perform the procedures described in item 1-39. [Brief explanation of the drawing]

[0008] Various exemplary embodiments of this solution are described in detail below with reference to the following figures or drawings. The drawings are provided for illustrative purposes only and merely depict exemplary embodiments of this solution to facilitate the reader's understanding of the solution. Therefore, the drawings should not be considered as limitations on the scope, scope, or availability of this solution. For clarity and for ease of illustration, please note that these drawings are not necessarily drawn to exact scale.

[0009] [Figure 1] Figure 1 illustrates an exemplary cellular communication network in which the techniques and other aspects disclosed herein may be implemented according to one embodiment of the present disclosure.

[0010] [Figure 2] Figure 2 illustrates block diagrams of exemplary base stations and user equipment devices according to several embodiments of the present disclosure.

[0011] [Figure 3] Figure 3 shows a schematic of an exemplary non-terrestrial communications network, including at least one unmanned aerial system-based radio communication node, according to several embodiments of the present disclosure.

[0012] [Figure 4]Figure 4 shows another exemplary non-terrestrial communications network, including at least one unmanned aerial system-based radio communication node, according to some embodiments of the present disclosure.

[0013] [Figure 5] Figure 5 shows a flowchart of a four-step RACH procedure according to some embodiments of the present disclosure.

[0014] [Figure 6] Figure 6 shows a two-step RACH procedure according to several embodiments of the present disclosure. [Modes for carrying out the invention]

[0015] Various exemplary embodiments of this solution are described below with reference to accompanying drawings to enable those skilled in the art to fabricate and use this solution. As will be obvious to those skilled in the art, after careful reading of this disclosure, various changes or modifications to the examples described herein can be made without departing from the scope of this solution. Therefore, this solution is not limited to the exemplary embodiments and uses described and illustrated herein. In addition, the specific order or hierarchy of steps in the methods disclosed herein is merely an exemplary approach. Based on design preferences, the specific order or hierarchy of steps in the disclosed methods or processes can be rearranged while remaining within the scope of this solution. Therefore, those skilled in the art will understand that the methods and techniques disclosed herein present various steps or actions in a sample order, and that this solution is not limited to the specific order or hierarchy presented unless expressly otherwise stated.

[0016] Figure 1 illustrates an exemplary wireless communication network and / or system 100 in which the techniques disclosed herein may be implemented according to embodiments of the present disclosure. In the following discussion, the wireless communication network 100 may be any wireless network, such as a cellular network or a narrowband Internet of Things (NE-IoT) network, and will be referred to herein as “Network 100”. Such exemplary Network 100 includes a base station 102 (hereinafter “BS102”), user equipment devices (hereinafter “UE104”) that can communicate with each other via a communication link 110 (e.g., a wireless communication channel), and clusters of cells 126, 130, 132, 134, 136, 138, and 140 covering a geographical area 101. In Figure 1, BS102 and UE104 are included in the respective geographical boundaries of cell 126. Each of the other cells 130, 132, 134, 136, 138, and 140 may include at least one base station, which operates within its allocated bandwidth and provides a suitable radio service area to its intended users.

[0017] For example, BS102 may operate with an allocated channel transmission bandwidth and provide an appropriate service area to UE104. Base station 102 and UE104 may communicate via downlink radio frames 118 and uplink radio frames 124, respectively. Each radio frame 118 / 124 may be further divided into subframes 120 / 127, which may include data symbols 122 / 128. In this disclosure, BS102 and UE104 are described herein as non-limiting examples of “communication nodes” capable of practicing the methods disclosed herein. Such communication nodes may be capable of wireless and / or wired communication according to various embodiments of the solution.

[0018] Figure 2 illustrates a block diagram of an exemplary wireless communication system 200 for transmitting and receiving wireless communication signals, such as orthogonal frequency division multiplexing (OFDM) / orthogonal frequency division multiple access (OFDMA) signals, according to several embodiments of the present solution. The system 200 may include components and elements configured to support known or conventional operating features that do not need to be described in detail herein. In one exemplary embodiment, the system 200 can be used to communicate (e.g., transmit and receive) data symbols within a wireless communication environment such as the wireless communication environment 100 in Figure 1, as described above.

[0019] System 200 generally includes a base station 202 (hereinafter, "BS202") and a user equipment device 204 (hereinafter, "UE204"). BS202 includes a BS (base station) transceiver module 210, a BS antenna 212, a BS processor module 214, a BS memory module 216, and a network communication module 218, each module being coupled and interconnected to one another via a data communication bus 220 as needed. UE204 includes a UE (user equipment) transceiver module 230, a UE antenna 232, a UE memory module 234, and a UE processor module 236, each module being coupled and interconnected to one another via a data communication bus 240 as needed. BS202 communicates with UE204 via a communication channel 250, which may be any radio channel or other medium suitable for data transmission as described herein.

[0020] As will be understood by those skilled in the art, System 200 may further include any number of modules other than those shown in Figure 2. Those skilled in the art will understand that various illustrative blocks, modules, circuits, and processing logic described in relation to the embodiments disclosed herein may be implemented in hardware, computer-readable software, firmware, or any practical combination thereof. To clearly illustrate this interchangeability and compatibility of hardware, firmware, and software, various illustrative components, blocks, modules, circuits, and steps are generally described in terms of their functionality. Whether such functionality is implemented as hardware, firmware, or software may depend on the specific application and the design constraints imposed on the overall system. Those familiar with the concepts described herein may implement such functionality in a manner suitable for each specific application, but such implementation decisions should not be construed as limiting the scope of this disclosure.

[0021] According to some embodiments, the UE transceiver 230 may be referred to herein as the “uplink” transceiver 230 and includes a radio frequency (RF) transmitter and an RF receiver, each having a circuit to which it is coupled to an antenna 232. A duplex switch (not shown) may, alternatively, couple the uplink transmitter or receiver to the uplink antenna in a time-duplex configuration. Similarly, according to some embodiments, the BS transceiver 210 may be referred to herein as the “downlink” transceiver 210, each having a circuit to which it is coupled to an RF transmitter and an RF receiver, each having a circuit to which it is coupled to an antenna 212. A downlink duplex switch may, alternatively, couple the downlink transmitter or receiver to the downlink antenna 212 in a time-duplex configuration. The operation of the two transceiver modules 210 and 230 can be time-coordinated, and the uplink receiver circuit is coupled to the uplink antenna 232 for receiving transmissions over the radio transmission link 250 at the same time that the downlink transmitter is coupled to the downlink antenna 212. In some embodiments, proximity time synchronization is present, with minimal protection time between changes in the duplex direction.

[0022] The UE transceiver 230 and base station transceiver 210 communicate via a radio data communication link 250 and are configured to cooperate with a suitably configured RF antenna arrangement 212 / 232 capable of supporting specific radio communication protocols and modulation schemes. In some illustrative embodiments, the UE transceiver 210 and base station transceiver 210 are configured to support industrial standards such as Long-Term Evolution (LTE) and new 5G standards. However, it should be understood that this disclosure is not necessarily limited to specific standards and associated protocols. Rather, the UE transceiver 230 and base station transceiver 210 may be configured to support alternative or additional radio data communication protocols, including future standards or their variations.

[0023] According to various embodiments, BS202 may be, for example, an evolved node B (eNB), a serving eNB, a target eNB, a femtostation, or a picostation. In some embodiments, UE204 may be embodied in various types of user devices such as mobile phones, smartphones, personal digital assistants (PDAs), tablets, laptop computers, and wearable computing devices. Processor modules 214 and 236 may be implemented or realized with general-purpose processors, content-addressable memory, digital signal processors, application-specific integrated circuits, field-programmable gate arrays, any suitable programmable logic devices, separate gate or transistor logic, separate hardware components, or any combination thereof, designed to perform the functions described herein. Thus, the processor may be realized as a microprocessor, controller, microcontroller, state machine, etc. The processor may also be implemented as a combination of computing devices, for example, a digital signal processor and a microprocessor, multiple microprocessors, one or more microprocessors combined with a digital signal processor core, or any other combination of such configurations.

[0024] Furthermore, steps of methods or algorithms described in relation to embodiments disclosed herein can be directly embodied in hardware, firmware, or software modules, or any practical combination thereof, executed by processor modules 214 and 236. Memory modules 216 and 234 can be implemented as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium known in the art. In this regard, memory modules 216 and 234 can be coupled to processor modules 210 and 230, respectively, so that processor modules 210 and 230 can read information from and write information to memory modules 216 and 234, respectively. Memory modules 216 and 234 can be integrated into their respective processor modules 210 and 230. In some embodiments, each of memory modules 216 and 234 may include cache memory for storing temporary variables or other intermediate information during the execution of instructions executed by processor modules 210 and 230, respectively. Each of the memory modules 216 and 234 may also include non-volatile memory for storing instructions to be executed by the processor modules 210 and 230, respectively.

[0025] The network communication module 218 generally represents the hardware, software, firmware, processing logic, and / or other components of the base station 202 that enable bidirectional communication between the base station transceiver 210 and other network components and communication nodes configured to communicate with the base station 202. For example, the network communication module 218 may be configured to support Internet or WiMAX traffic. In a typical deployment, but not limited to, the network communication module 218 provides an 802.3 Ethernet® interface so that the base station transceiver 210 can communicate with conventional Ethernet®-based computer networks. Thus, the network communication module 218 may include a physical interface for connection to a computer network (e.g., a mobile switching center (MSC)). The terms “configured for,” “configured as,” and their inflections refer to devices, components, circuits, structures, machines, signals, etc., that are physically built, programmed, formatted, and / or arranged to perform a specified operation or function, as used herein.

[0026] While aspects of the networking environments and devices that may be used to implement the systems, methods, and apparatus described herein have been discussed, further details are provided below.

[0027] Long transmission delays and extensive service areas can have a significant impact on radio communication systems. For example, in some cases, non-terrestrial radio communication nodes may be located on satellites. The high-speed movement of satellites can lead to Doppler frequency shifts. Furthermore, the distance from the satellite to the terrestrial radio communication device can result in long transmission round-trip times, which in turn result in large timing advance compensation during communication between the radio communication device and the radio communication node. Positioning radio communication nodes on satellites can also result in multiple satellite beams with a wide beam occupancy area forming a single satellite cell. This introduces delay differences inherent to large cells and can lead to an undesirable increase in the length of the temporal window for random access response (RAR) communication in random access channel (RACH) procedures.

[0028] In some respects, technical solutions to the technical problems detailed above may involve configuring transmission resources, such as RACH resources, in a manner specific to satellite beams, and reducing the risk of significant changes in RACH procedure design. For example, transmission parameters such as timing advance (TA) or scheduling offset can be configured per satellite beam, reducing the complexity of pre-compensation to account for time delays.

[0029] Figure 3 shows a schematic of an exemplary non-terrestrial communications network 300 including at least one unmanned aerial system-based radio communication node. In particular, Figure 3 shows a communications network 300 including a satellite or unmanned aerial vehicle (UAV) 302, user equipment (UE) 304, a gateway 306, and a data network 308. The satellite 302 can serve as a platform for base stations such as BS102 and 202 discussed above in relation to Figures 1 and 2, and the UE 304 can be analogous to UE104 and 204 discussed above in relation to Figures 1 and 2. The UE 304 and the BS on the satellite 302 can communicate via a communications link 310, and the BS on the satellite 302 and the gateway 306 can communicate via a feeder link 312. The gateway 306 can communicate with the data network 308 via a data link 314.

[0030] Figure 4 shows another exemplary non-terrestrial communications network 400 that includes at least one unmanned aerial system-based radio communication node. The communications network 400 shown in Figure 4 is similar to the communications network 300 shown in Figure 3, but includes an additional satellite or UAV platform 402. Figure 4 depicts a scenario in which the communications network includes a group of satellites that enable communications between the UE and a gateway or data network.

[0031] The gateway can be one of several gateways that can provide connectivity between satellite 302 / 402 and data network 308, and it may be a public terrestrial data network. The gateway can be deployed across the satellite's targeted service area, which may include a territorial or continental service area. In the example where the satellite is a non-geostationary Earth orbit satellite ("non-GEO satellite"), the satellite can be serviced continuously by one or more gateways at a time. The communication network can ensure that service links exist and that feeder link persistence is maintained between consecutive gateways with sufficient duration to allow mobility anchoring and handover to proceed. In some examples, UEs within a cell may be serviced by only one gateway.

[0032] A satellite can implement either a transparent or regenerative (with onboard processing) payload. The satellite can generate several beams over a service area whose boundaries may be limited by its field of view, which may depend on the onboard antenna characteristics and the satellite's minimum elevation angle. The beam's area on the Earth's surface may be elliptical in shape. In cases where the satellite implements a transparent payload, it can perform radio filtering, frequency conversion, and amplification, thereby allowing the signal to be repeated. In cases where the satellite platform implements a regenerative payload, the satellite can perform not only radio frequency filtering, frequency conversion, and amplification, but also demodulation / modulation, switching and / or routing, coding / modulation, etc., effectively performing, at least partially, the functions of an onboard base station.

[0033] In cases where a communication system includes a group of satellites, such as the communication system shown in Figure 4, the network may include inter-satellite links (ISLs) 412. In some such cases, satellites can implement regenerative payloads. ISLs can operate in the RF or optical frequency band.

[0034] Table 1 below lists the various types of satellites that can be used to implement the satellites / UAVs 302 and 402 shown in Figures 3 and 4. The satellite types and corresponding information shown in Table 1 are examples only and not limited to other types of platforms and satellites that may be used. [Table 1]

[0035] In some embodiments, GEO satellites and UAS platforms can be used to provide continental, territorial, or local services. In some embodiments, a group of LEO and MEO satellites can be used to provide services within both the Northern and Southern Hemispheres. In some cases, a group of satellites can even provide a global service area, including polar regions. In some such cases, appropriate orbital inclination, ISL, and beam can be selected.

[0036] (Aspect I: Improved RACH procedure)

[0037] This part of the discussion concerns the use of UE estimated timing advances (TAs) to assist the RACH procedure, where UE estimated TAs can be applied on the UE side before the transmission of the preamble in the RACH procedure to adjust the uplink transmission time. UEs can be embodied in various types of user devices such as mobile phones, smartphones, personal digital assistants (PDAs), tablets, laptop computers, and wearable computing devices, and BSs can include evolved NodeBs (eNBs), serving eNBs, target eNBs, femtostations, picostations, etc. In some examples, TAs can be estimated by the UE according to their information location and satellite position estimation table information received from broadcast information or system information or RRC signaling messages from the base station (BS). The following discussion concerns user control of the TA determined by the UE in a 4-step or 2-step RACH procedure.

[0038] Figure 5 shows a flowchart of a four-step RACH procedure, while Figure 6 shows a two-step RACH procedure. Referring to Figure 5, the four-step RACH procedure is performed between UE504 and base station (BS)502. UE504 and BS502 can be implemented using the UE and BS discussed above in relation to Figure 1-4. On the other hand, Figure 6 shows a two-step RACH procedure between UE604 and BS602. UE602 and BS604 can be implemented using the UE and BS discussed above in relation to Figure 1-4.

[0039] The four-step RACH process shown in Figure 5 may include step 1, which corresponds to Msg1 (random access preamble) 554 transmitted from the UE to the BS; step 2, which corresponds to Msg2 (random access response) 556 transmitted from the BS to the UE; step 3, which corresponds to Msg3 (scheduled transmission) 558; and step 4, which corresponds to Msg4 (conflict resolution) 560. Step 0 552 may correspond to resource configuration information broadcast by the BS.

[0040] The two-step RACH process shown in Figure 6 may include step 1, which corresponds to Msg1 (preamble + PUSCH payload) 652 transmitted by the UE to the BS, and step 2, which corresponds to Msg2 (random access response) 654 transmitted by the BS to the UE. Step 0 656 may correspond to resource configuration information broadcast by the BS.

[0041] Referring again to Figure 5, in step 0, the UE can receive information from the BS that may include, in part, the RACH resource configuration, PDSCH (Physical Downlink Shared Channel) resource configuration, PDCCH (Physical Downlink Control Channel) resource configuration (e.g., configuration of CORSET (Control Resource Set) and SS (Synchronization Signal)), PUSCH (Physical Uplink Shared Channel) resource configuration, and PUCCH (Physical Uplink Control Channel) resource configuration. In step 0, the UE can receive resource configuration information from the BS via BS broadcast, either within system information or RRC (Radio Resource Control) signaling.

[0042] In the 4-step RACH procedure, in step 1, the UE sends a random access preamble, also called PRACH (Physical RACH), to the BS. In step 2, the BS transmits a RAR (Random Access Response) indicating receipt of the preamble and providing a timing advance command, which adjusts the device's transmission timing based on the timing of the preamble received in step 1. The UE can use the RA-RNTI (Random Access Radio Network Temporary Identifier) ​​to monitor the PDCCH for RARs within the RAR window. In step 3, the UE transmits Msg3 via the UL resources indicated in the UL grant included in the RAR received from the BS in step 2. In response, in step 4, the UE receives Msg4 regarding conflict resolution. The UE and BS may exchange Msg3 and Msg4 to resolve potential conflicts arising from simultaneous transmission of the same RACH resource from multiple devices in the cell, e.g., preambles and RACH opportunities. If successful, Msg4 also causes the UE to move to a connected state.

[0043] In the two-step RACH procedure, in step 1, the UE sends a random access preamble via PRACH and a payload via PUSCH (physical uplink shared channel), and in step 2, it receives Msg2 within the Msg2 receive window and performs conflict resolution.

[0044] The following discussion relates to various approaches for controlling the use of UE estimated timing advance in RACH procedures, such as the 4-step and 2-step RACH procedures discussed above, or any other RACH procedures that are implemented.

[0045] (RACH with / without TA assistance as estimated by A.UE)

[0046] In some embodiments, the UE can estimate the Time Arrangement (TA) before initiating RACH and use this TA to assist RACH. For example, the UE can apply the estimated TA before transmitting the random access preamble to mitigate the impact of large transmission delays on the RACH procedure. In some embodiments, the UE can estimate the TA based on UE location information and satellite (BS) position estimation tables, or by other means. The following discussion provides examples of RACH procedures where the TA is not pre-compensated with a TA estimated by the UE (RACH without a TA estimated by the UE) and RACH procedures where the TA is pre-compensated with a TA estimated by the UE (RACH with a TA estimated by the UE). Pre-compensating for the TA may mean that the UE can apply the estimated TA before transmitting the random access preamble to the BS.

[0047] (1. RACH without TA estimated by UE)

[0048] In some cases, the BS can broadcast a common TA that can be received by all UEs within the cell serviced by the BS. UEs can receive and apply the common TA before transmitting their preamble to the BS. After receiving a RAR (Msg2 of 4-step RACH) containing a Random Access Preamble ID (RAPID) corresponding to the preamble transmission, or a RAR (Msg2 of 2-step RACH) containing a UE ID corresponding to the UE ID included in the payload portion of Msg1, UEs can adjust their TA with the TA indicator included in the corresponding RAR. In such cases, both the BS and UEs are aware of the UE-specific TA, as the common TA and the TA indicator included in the RAR are constructed by the BS. Both 4-step and 2-step RACH can be used when the TA estimated by the UE is not used to assist the RACH procedure as described above.

[0049] (2. RACH with TA estimated by UE)

[0050] An approach to utilizing the TA estimated by the UE can be described by referring to the type of RACH used by the UE.

[0051] (a. 4-step RACH)

[0052] The use of TA (Technical Analysis) estimated by UE (User Environment) in the RACH procedure can be implemented in various steps that constitute the RACH procedure.

[0053] For example, in step 1, the UE can estimate the TA according to available auxiliary information before transmitting the preamble to the BS, and apply the estimated TA. The auxiliary information may include UE location information and satellite position estimation tables, which the UE can use to derive an approximate UE-specific TA.

[0054] In step 2, the UE can receive Msg2, which may contain the RNTI corresponding to the transmitted preamble. The UE can correct the estimated TA according to the TA indicator included in Msg2. Note that at this point in the RACH procedure, the BS is unaware of the UE estimated TA because the TA compensated by the UE has not yet been shown to the BS.

[0055] In Step 3, as mentioned above, the BS is not yet aware of the UE estimated TA. To avoid invalid scheduling of Msg3 transmission to the BS, the UE can take any one or more of the following approaches:

[0056] One approach is for the BS to schedule the UE transmission of Msg3 by always assuming the maximum delay difference within the cell. In this method, Msg3 transmitted by the UE can be scheduled by UL grants provided within the RAR in Msg2. The UE can include the estimated TA in Msg3 transmitted to the BS. After the BS receives Msg3 from the UE, both the UE and the BS can become aware of the UE estimated TA.

[0057] Alternatively, the BS can schedule multiple k2 values ​​within a UL grant contained in the RAR. For example, if a UE receives a PDSCH with a RAR message ending in slot n for the corresponding PRACH transmission from the UE, the UE transmits the PUSCH in slot n + k2 + Δ, where k2 is jointly determined by the row index and subcarrier spacing (SCS) contained in the RAR UL grant, and Δ is determined by the SCS used. If multiple k2 values ​​are contained in the RAR, the UE estimated TA can select the appropriate k2 for the transmission of Msg3 based on the accurate TA. Thus, the BS can derive the UE estimated TA according to the reception time of Msg3.

[0058] One approach allows multiple k2 values ​​to be provided based on multiple time-domain resource indexes within a RAR UL grant. Another approach allows k2 indexes to be provided within a RAR UL grant, with each k2 index mapped to a k2 list. The mapping between k2 indexes and k2 lists can be predefined within the specification or configured by the BS, and the mapping relationships can be broadcast or delivered by system information or RRC signaling. In some examples, different k2 lists can be configured for different SCSs and / or different round-trip delays (RTDs). The UE can select a k2 list according to the k2 indexes and / or SCSs and / or RTDs included in the RAR.

[0059] In step 4 of the 4-step RACH procedure, the UE can receive Msg4 for conflict resolution.

[0060] (b.2 step RACH)

[0061] The use of TA inferred by UE in a two-step RACH procedure can be implemented in various steps that make up the two-step RACH procedure.

[0062] For example, in step 1, the UE applies a TA estimated by itself before transmitting the preamble. The UE can then transmit the payload over the PUSCH, and the payload is mapped to the selected preamble. The estimated TA can be indicated by the parameters contained in the payload.

[0063] In one approach, the estimated UE TA value can be included in the payload of Msg1. In another approach, the N least significant bits (LSBs) of the SFN (System Frame Number) and the slot index of the time-domain resource to which the preamble is transmitted can be included in the payload of Msg1 to indicate the estimated UE TA. In yet another approach, the absolute time value to which the preamble is transmitted can be included in the payload of Msg1. In yet another approach, a new TA MAC CE (MAC control element) can be used to deliver the estimated UE TA value.

[0064] In step 2, the UE receives the RAR within the RAR window. After successful conflict resolution, the UE can calibrate its TA according to the TA indicators contained in the RAR received from the BS. Since the TA estimated by the UE can be derived from the relevant information contained in the payload, together with the additional TA estimated by receiving the corresponding preamble, the BS can derive the accurate UE-specific TA and schedule the UE with the correct TA.

[0065] In some cases, additional delays may exist due to the feeder link between the satellite and the ground station (e.g., the delay associated with feeder link 312 shown in Figures 3 and 4). In some such cases, the UE may take additional delays into account by utilizing the additional information when estimating the TA. The feeder link between the satellite and the ground gateway is predictive, and therefore a mapping table containing delays in the feeder link relative to satellite position or time can be pre-stored on the UE side. In this way, the UE can calculate the delay in the service link and add it to the feeder link delay found in the mapping table to form the total propagation delay. In the case of GEO transparent, the satellite is relatively statistical relative to the ground gateway, and therefore the delay in the feeder link is practically fixed. A mapping table containing delays in the feeder link relative to satellite ID or satellite position, stored on the UE side, can be very useful for propagation delay calculation. The mapping table can be broadcast or predefined. According to the mapping table, the UE can select a suitable offset based on the satellite to which it is connected and adjust the estimated TA accordingly.

[0066] (B.RACH resource configuration)

[0067] As discussed above, in step 0, the UE may receive RACH resource configuration information prior to the transmission of the preamble to the BS. The UE may receive the RACH resource configuration from the BS, and the RACH resources may include separate RACH resource pools configured for RACH with or without the assistance of the UE estimated TA. In some embodiments, the RACH resource pool may include at least one of the following resources: preamble transmission resources, payload transmission resources, mapping between preamble and payload transmission resources, configuration of random response windows, parameters related to preamble transmission control, parameters related to payload transmission control, selection criteria for normal uplink (NUL) and complementary uplink (SUL), selection criteria for 2-step RACH and 4-step RACH, and SSB selection criteria, e.g., RSRP (Reference Signal Received Power) threshold.

[0068] For example, from the list of resources above, a preamble transmission resource may include at least one of the following: location of the preamble transmission resource in the time domain, location of the preamble transmission resource in the frequency domain, and location of the preamble transmission resource in the code domain, and it may then include at least one of the following: preamble index, preamble format, PRACH root sequence index, zeroCorrelationZoneConfig parameter, restrictedSetConfig (which determines the type of restricted set supported for different preamble formats), mapping between preamble and SSB (Synchronization Signal / PBCH Block), mapping between RACH opportunity (RO) and SSB, and grouping of preamble. PRACH transmission opportunity / RACH transmission opportunity (RO) refers to the location of the preamble transmission resource in the time and frequency domains.

[0069] From the list of resources above, a payload transmission resource may include at least one of the following: a payload transmission resource location in the time domain, a payload transmission resource location in the frequency domain, a payload transmission resource location in the code domain (e.g., orthogonal code, non-orthogonal code, or some other code that may be used within the physical layer; for convenience, the code may be referred to as “payload transmission code”), and bandwidth / PRB used for payload transmission. A payload transmission opportunity may refer to a payload transmission resource location in the time and frequency domains. “Payload transmission code” can provide better performance when used in NOMA (non-orthogonal multiple access) or MUSA (multi-user shared access) operation and when time / frequency resources are shared by multiple UEs.

[0070] From the list of resources above, the following aspects can be incorporated into the mapping configuration for mapping between preamble and payload transmission resources: Preamble transmission resources located in different ROs can be mapped to the same payload transmission opportunity with different payload transmission codes. Different preambles within one RO can be mapped to different payload transmission opportunities (with the same or different payload transmission codes). Multiple UEs using different preambles can be mapped to the same payload transmission resource (i.e., the same payload transmission code within the same payload transmission opportunity). A single preamble resource (preamble + RO combination) can be mapped to multiple payload transmission codes within a single payload transmission opportunity, enabling multi-layer data transmission (e.g., MIMO). Timing offsets between preamble transmission resources and payload transmission resources may differ with respect to different preamble transmission resources (e.g., the same or next time slot). Any combination of these aspects can be incorporated into the mapping configuration.

[0071] From the resource list above, the configuration of a random response window can include at least one of the following: the length of the RAR window, the start of the RAR window, and an offset to be used, for example, to delay the start of the RAR window. Any combination of these aspects can be incorporated into the random response window configuration.

[0072] From the list of resources above, the parameters related to preamble transmission control may include at least one of the following: the target received power of the preamble on the BS side, the maximum allowable transmission time of the preamble, and the power ramping step of the preamble. Any combination of these parameters may be included.

[0073] From the list of resources above, parameters related to payload transmission control may include the target received power of the payload on the BS side, the maximum allowable transmission time of the payload, the power ramp step of the payload, and the power offset between the preamble and the payload. Any combination of these parameters may be included.

[0074] The configuration of the RACH resources discussed above can be delivered to the UE in at least one of the following approaches: broadcast within broadcast information, delivered within system information, or signaled by RRC signaling.

[0075] (Instructions for UE regarding the use of UE estimated TA in C.RACH)

[0076] In some embodiments, the UE may need to be informed of the use of UE Estimation TA in the RACH procedure. The UE may be informed of the use of UE Estimation TA in any one or more of the approaches discussed below.

[0077] One approach is to instruct the UE to use UE-estimated TA in RACH, which can be implicit in the configuration of the RACH resource pool. For example, if a dedicated RACH resource pool is configured for RACH with the assistance of UE-estimated TA, then for a UE with the ability to estimate TA itself (e.g., derive TA based on UE location information and satellite position estimation tables), the UE can first attempt to initiate RACH with the assistance of the estimated TA by selecting RACH resources from the corresponding resource pool. In cases where UE-estimated TA is not available (e.g., UE location information is unavailable, or the estimated TA may not satisfy accuracy requirements), the UE can initiate a RACH procedure without the assistance of the estimated TA by selecting RACH resources from a RACH resource pool configured for RACH without the assistance of UE-estimated TA.

[0078] Alternatively, the UE can receive instructions from the BS regarding the use of UE Estimated TAs in the RACH procedure. For example, a 1-bit instruction can be sent from the BS to indicate whether UE Estimated TAs will be used for RACH. For instance, "1" could indicate that UE Estimated TAs may be used to assist RACH if they are available on the UE side, while "0" could indicate that UE Estimated TAs will not be used to assist RACH regardless of their availability. In another example, this instruction could be configured to indicate, for each RACH resource pool, whether the RACH resource pool can be used for RACH with the assistance of UE Estimated TAs. The instruction can be contained in at least one of the following ways: within broadcast information, within system information, or within RRC signaling (e.g., RRC reconfiguration messages).

[0079] Another approach is that indicators from the Broadcast Station (BS) can indicate the type of RACH procedure to be adopted. For example, an indicator can be used to enable UE Estimated TA for use in RACH. If the indicator is included in broadcast or system information, or in RRC signaling (e.g., RRC reconfiguration messages), then UE Estimated TA will be used for RACH if available on the UE side. If not, the absence of the indicator can indicate to the UE that UE Estimated TA will not be used in RACH. In another example, an indicator can be used to enable RACH without UE Estimated TA. If the indicator is included in broadcast or system information, or in RRC signaling (e.g., RRC reconfiguration messages), then RACH without location information may be supported. If not, the absence of the indicator can indicate the use of UE Estimated TA in RACH. This can also indicate that if UE Estimated TA is not available to the UE, the UE will not be able to access the Broadcast Station (BS).

[0080] Another approach is for the BS to control whether a general RACH procedure is supported. For example, a 2-bit instruction can be used to indicate the type of RACH procedure supported. For example, "00" may indicate that both RACH with UE estimation TA and RACH without UE estimation may be supported. "01" may indicate that only RACH with UE estimation TA is supported. "10" may indicate that only RACH without UE estimation TA is supported, and "11" may be reserved. The above exemplary mapping between bits and corresponding instructions is illustrative only, and other bit combinations and encodings can also be used to convey the same information.

[0081] At least one of the approaches discussed above can be configured per RACH resource pool or per cell. If the configuration is per RACH resource pool, and the instructions indicate that a given RACH resource pool can be used for RACH with the assistance of a UE estimated TA, then for a UE that estimates the TA itself (e.g., the ability to derive it based on UE location information and satellite position estimation tables), the UE can first attempt to initiate RACH with the assistance of an estimated TA by selecting a RACH resource from the corresponding resource pool. In cases where a UE estimated TA is not available (e.g., UE location information is not available, or the estimated TA may not satisfy accuracy requirements), the UE can initiate RACH without an estimated TA by selecting a RACH resource from the corresponding RACH resource pool.

[0082] In yet another approach, instructions for using UE estimated TAs can be implicitly indicated. For example, if an offset for delaying the start of the RAR window is configured separately for UEs with and without UE estimated TAs, it implies that both RACHs with and without location information will be supported. In cases where UE estimated TAs are available, the UE can use them to assist with RACHs. If only one offset is configured, it implies that only the corresponding RACH (either a RACH with a UE estimated TA or a RACH without a UE estimated TA) will be enabled. In this example, the offset can be included in broadcast information or system information, or in RRC signaling (e.g., RRC reconfiguration messages).

[0083] Both 4-step and 2-step RACH procedures, or any other RACH procedure, can be supported, regardless of whether a UE estimated TA is used for the RACH. All alternatives mentioned above can be used in conjunction with any other principles defined for selection between 2-step RACH, 4-step RACH, or other RACH types. For example, the UE first determines whether a UE estimated TA will be used within the RACH by, for example, selecting the corresponding RACH resource pool according to the alternatives given above, and then selects the RACH type (2-step RACH, 4-step RACH, or other RACH type) according to the criteria defined in the specification. Or, in another example, either a 2-step RACH or a 4-step RACH can be supported only for RACH with a UE estimated TA.

[0084] (RAR receive window control based on D.UE estimated TA)

[0085] The start and end of a RAR window may be configured based on whether UE Estimation TA is used within RACH.

[0086] (1. Start the RAR window)

[0087] (a. RACH without UE estimated TA)

[0088] To compensate for long transmission delays, a configurable offset can be indicated to the UE to delay the start of the RAR window. The offset can be broadcast, included in system information, or indicated by RRC signaling. This can be applied to 4-step RACH, 2-step RACH, or other RACH procedures when UE estimated TA is not used within RACH.

[0089] (b. RACH with UE estimated TA)

[0090] In the first approach, the start of the RAR window can be configured by the UE itself. In another approach, a configurable offset can be used to delay the start of the RAR window. This offset can be the same as the offset used for RACH without UE estimated TA, or a separate offset can be used for RACH with UE estimated TA. This offset can be broadcast, included in system information, or indicated by RRC signaling. The above approaches can be applied to 4-step RACH, 2-step RACH, or any other RACH procedure when UE estimated TA is used within the RACH.

[0091] (2. Extended RAR window)

[0092] (a. RACH without UE estimated TA)

[0093] The maximum RAR window length is 10ms, and if the latency difference is very large, the RAR window may need to be expanded.

[0094] (b. RACH with UE estimated TA)

[0095] Depending on the extent to which TA is compensated, if the delay difference after compensation from the UE side does not exceed 10ms, the RAR window may not need to be expanded; otherwise, the window will likely need to be expanded.

[0096] If the RAR window is extended, RAR windows for different ROs may overlap. To distinguish RARs for different ROs, the following approaches may be considered. For example, one approach is that the SFN index may be included in the RAR. The LSB of the SFN of the frame in which the preamble is transmitted may be included in the RAR (the SFN index can be obtained as SFN_RO + mod((SFN_preamble-SFN_RO) / 2), where SFN_RO is the SFN index in which the RO is located, and SFN_preamble is the SFN index in which the preamble is received on the BS side). The LSB may be included in either the subheader of the MACsubPDU or the RAR payload. Delaying the start of the RAR window and extending the RAR window length may be configured to be used together or separately.

[0097] (Distinction between RAR intended for RACH with / without E.UE estimated TA)

[0098] In some embodiments, RACH with and without UE Estimation TA can be supported simultaneously by BS. Since the RAR content and structure may differ for RACH with and without UE Estimation TA, and overlaps may exist between corresponding RAR windows, it is necessary to distinguish between RARs for RACH with and without UE Estimation TA. In some cases, this may affect step 2 of the RACH procedure.

[0099] In one approach, separate CORESET and / or SS can be configured for RACH with / without UE-estimated TA. In another approach, different RA-RNTI can be used to distinguish RAR for RACH with / without UE-estimated TA. For example, one configurable offset can be included in the formula for RA-RNTI calculation: RA-RNTI = 1 + s_id + 14×t_id + 14×80×f_id + 14×80×8 + 14×80×8×1×ul_carrier_id + offset Where s_id is the index of the first OFDM symbol of the specified PRACH, t_id is the index of the first slot of the specified PRACH within the system frame, f_id is the index of the specified PRACH in the frequency domain, and ul_carrier_id is the UL carrier used for Msg1 transmission (0 for the NUL carrier and 1 for the SUL carrier). The offset can be configured by the BS and can be adjusted according to the separation of consecutive ROs and the maximum delay difference within the communication network. Or, in another approach, the RA-RNTI can be calculated according to the following formula, and the resource pool identifier can be introduced as part of the RA-RNTI formula: RA-RNTI = 1 + s_id + 14×t_id + 14×80×f_id + 14×80×8×r_id + 14×80×8×1×N_r_id×ul_carrier_id Where s_id is the index of the first OFDM symbol of the specified PRACH, t_id is the index of the first slot of the specified PRACH within the system frame, f_id is the index of the specified PRACH in the frequency domain, r_id is the index of the selected resource pool (0 ≤ r_id < N_r_id), N_r_id is the total configured RA resource pool, and ul_carrier_id is the UL carrier used for Msg1 transmission (0 for the NUL carrier and 1 for the SUL carrier). Or, in another approach, the RA-RNTI can be calculated according to the following formula: RA-RNTI = 1 + s_id + 14×t_id + 14×80×F_id + 14×80×[max(F_id) - 1]×f_id + 14×80×[max(F_id) - 1]×8×ul_carrier_id Where s_id is the index of the first OFDM symbol of the specified PRACH, t_id is the index of the first slot of the specified PRACH within the system frame, f_id is the index of the specified PRACH in the frequency domain, and ul_carrier_id is the UL carrier used for Msg1 transmission (0 for NUL carrier and 1 for SUL carrier). F_id (0 ≤ F_id < max(F_id)) can be achieved by one of the following approaches. · Approach 1: The frame-related parameter is the "N" least significant bits of the system frame index. In this case, the maximum max(F_id) is 2 N equals. · Approach 2: The frame-related parameter is the index of the system frame, and max(F_id) is equal to the maximum number of system frame indices. · Approach 3: F_id is obtained as (system frame index) mod (ceil(RARwindow_length divided by system_frame_length)). If ceil(RAR_window_length divided by system_frame_length) is equal to N, then max(F_id) is equal to N. Here, ceil() represents the ceiling function that maps the number "x" to an integer at least as large as "x". mod() represents the modulo function that finds the remainder after division of one number by another number.

[0100] Different RA-RNTI formulas can be used for non-terrestrial networks with different round-trip delays or different satellite types. For example, an RA-RNTI formula as defined in Technical Specification 38321 can be used for the case of LEO, while a formula as defined in Approach 3 can be used for the case of GEO.

[0101] Alternatively, preamble grouping can be used. If the preamble is divided into different groups for RACH with and without UE estimated TA, the RAPID included in the RAR can be used to distinguish between three or more RACH types.

[0102] Another approach is that the instruction can be included in the RAR. For example, the instruction can be included in a subheader or RAR payload to distinguish between RARs for RACH with / without UE Estimated TA. For example, a 1-bit type indicator could be used, where "1" means it is a RAR for RACH with UE Estimated TA, "0" means it is a RAR for RACH without UE Estimated TA, or vice versa.

[0103] Another approach is that the instructions can be implicit in the type of RACH procedure used. For example, a RACH with UE estimation TA may always employ a two-step RACH, while a RACH without UE estimation TA may always employ a four-step RACH.

[0104] Any combination of the approaches discussed above can be used to distinguish between RARs intended for RACH with and / or without UE Estimation TA. Furthermore, different combinations of the above approaches (including combinations of the same approaches) may be considered when 2-step RACH, 4-step RACH, or other RACH procedures are simultaneously supported for RACH with and / or without UE Estimation TA. For example, a separated control resource set (CORESET) and / or search space (SS) can be configured for 2-step RACH with UE Estimation TA, 2-step RACH without UE Estimation TA, 4-step RACH with UE Estimation TA, and 4-step RACH without UE Estimation TA. For example, a separated CORESET and / or SS can be configured for 2-step and 4-step RACH, and preamble grouping can be further configured to distinguish between RACH with and without UE Estimation TA. Alternatively, in another example, a separate CORESET and / or SS can be configured for 2-step RACH / 4-step RACH, and a RAR instruction can be further used to distinguish between RACH with / without UE estimated TA.

[0105] (Distinguishing between RACH with and without UE estimated TA in F.BS)

[0106] Several approaches can be used by BS to distinguish whether RACH with UE estimated TA is being employed or RACH without UE estimated TA. One approach is preamble grouping, where the preamble can be divided into separate groups for RACH with / without UE estimated TA. For example, Group 1 is configured for RACH with UE estimated TA, Group 2 is configured for RACH without UE estimated TA, and then UE can initiate RACH with or without UE estimated TA by selecting a preamble from the corresponding group.

[0107] Alternatively, RACH resource partitioning in the time and / or frequency domains can be used. For example, separate RACH resource pools with no overlap can be configured within the frequency domain. The BS can then derive, based on the frequency resources from which Msg1 was received, that the received Msg1 (Msg1 for a 4-step RACH or Msg1 for a 2-step RACH) is for a RACH with or without a UE estimated TA. Alternatively, in another approach, RO partitioning in the time domain can be used to distinguish between RACHs with and without a UE estimated TA from the BS side. The BS can derive, based on the ROs detected by Msg1, that the received Msg1 (Msg1 for a 4-step RACH or Msg1 for a 2-step RACH) is for a RACH with or without a UE estimated TA. Alternatively, in yet another approach, RACH resources in both the frequency and time domains can be used, for example, by configuring separate RACH resource pools for RACH with or without UE estimated TA, and BS can derive RACH categories (RACH with or without UE estimated TA) according to the fact that the RACH resource pools are used for transmitting the preamble of Msg1 (Msg1 for 4-step RACH or Msg1 for 2-step RACH).

[0108] Another approach involves frequency hopping of the preamble transmission. For example, different frequencies can be used for RACH with or without UE estimated TA. BS can derive whether UE estimated TA is used for RACH depending on the frequency at which the preamble of Msg1 (Msg1 for 4-step RACH or Msg1 for 2-step RACH) is received.

[0109] Another approach involves using a preamble format to distinguish between RACH with and without UE-estimated TA at the BS. For example, different preamble formats could be configured separately for RACH with and without UE-estimated TA, and the BS could then derive, based on the preamble format, whether the received preamble is for RACH with or without UE-estimated TA.

[0110] The above approach, used on the BS side to distinguish between RACH with and without UE estimated TA assistance, can be used when both 2-step RACH and / or 4-step RACH are supported for RACH with and without UE estimated TA assistance.

[0111] Another approach involves using instructions within the PUSCH payload of Msg1 in a two-step RACH. For example, with respect to a two-step RACH, a 1-bit type indicator can be used to indicate whether the RACH is accompanied by or without a UE estimated TA. For instance, if the indicator value is set to "1", the UE estimated TA is used in the RACH, and information indicating the TA value estimated by the UE is included in the payload of Msg1. Otherwise, the UE estimated TA is not used in the RACH. Other encoding formats can also be used.

[0112] Different combinations of the above approaches (including combinations of the same approach) may be considered when 2-step RACH, 4-step RACH, or other RACH procedures are simultaneously supported for RACH with / without UE estimated TA. For example, a preamble can be divided into separate groups for 2-step RACH with UE estimated TA, 2-step RACH without UE estimated TA, 4-step RACH with UE estimated TA, and 4-step RACH without UE estimated TA. In another example, 2-step RACH and 4-step RACH can be separated by different preamble groups, while RACH with / without UE estimated TA can be distinguished by preamble frequency hopping. In yet another example, separate ROs can be configured for 2-step RACH and 4-step RACH, and in addition, RACH with / without UE estimated TA can be distinguished by preamble grouping.

[0113] With respect to the approaches discussed above, the mapping between RACH resources, e.g., RACH resources in the time and / or frequency and / or code domain, and RACH types, e.g., 2-step RACH / 4-step RACH and / or RACH with / without UE estimated TA, can be delivered to the UE in at least one of the following ways: by being broadcast in broadcast information, delivered in system information, or signaled by RRC signaling.

[0114] (G. Improvement of satellite RACH capacity)

[0115] To improve RACH capacity within the satellite service area, frequency domain partitioning can be used, and for each satellite beam, there may be several cells located within different non-overlapping frequency bands.

[0116] (Side II: 2-step CFRA)

[0117] To enable more efficient state transitions or handovers, one possible solution is two-step non-contradiction RACH (CFRA). Here, two-step CFRA is described in an NTN scenario, but its use is not limited to NTN. It can also be used in other scenarios, such as terrestrial communication systems.

[0118] (A.2 Procedure for Step CFRA)

[0119] Similar to a two-step CBRA, the basic procedure for a two-step CFRA can include the following two steps: Step 1: The UE transmits Msg1 with a dedicated preamble and dedicated PUSCH resources configured by the BS. Step 2: The UE receives a response by monitoring the PDCCH addressed to C-RNTI.

[0120] (B.2 How to determine the RA type / RA resource when a step CFRA is configured)

[0121] When a RACH procedure is initiated and a two-step CFRA resource is configured, the following approaches may be considered for determining the RACH type on the UE side.

[0122] Approach 1: If a two-step CFRA is configured (or if a two-step CFRA is configured within the current UL BWP), the UE should select the two-step RACH (or two-step CFRA) during the initialization phase of the RACH procedure.

[0123] Approach 2: The UE can determine whether a two-step CFRA (or two-step RACH) is applicable based on a pre-configured RSRP threshold. If a two-step CFRA (or two-step RACH) is applicable based on the RSRP threshold (e.g., the measurement result is above or "greater than" the pre-configured RSRP threshold), the UE can select a two-step RACH; otherwise, the UE can select a four-step RACH.

[0124] Regarding Approach 2 described above, the RSRP threshold can be either the RSRP threshold for the cell (or BWP) or the RSRP threshold for the SSB or CSI-RS. When the SSB / CSI-RS level RSRP threshold is used for RA type selection, at least the following two conditions may be considered: • Cond-1: If either the RSRP of SSB or CSI-RS is greater than (or equal to or greater than) a pre-configured RSRP threshold, a two-step RACH will be considered applicable. • Cond-2: If either the RSRP of the SSB or CSI-RS with a 2-step CFRA (or 4-step RACH) resource is greater than (or "equal to or greater than") the pre-configured RSRP threshold, then the 2-step CFRA (or 4-step CFRA) will be considered applicable. When a cell (or BWP) level RSRP threshold is used for RA type selection, the following conditions may be considered: • Cond-1: If the RSRP of a cell (or BWP) is greater than (or equal to or greater than) a pre-configured RSRP threshold, a two-step RACH will be considered applicable. In some cases, the above description of selection based on RSRP thresholds is applicable to all RSRPs related to RA type selection.

[0125] In some embodiments, once a 2-step RACH (or 4-step RACH) is selected, the UE may make further selections between a 2-step CFRA and a 2-step CBRA (or a 4-step CFRA and a 4-step CBRA) when making resource selections.

[0126] If RACH resource selection fails to detect certified SSBs and / or CSI-RSs with 2-step CFRA resources, the following approaches may be considered to determine the RACH type on the UE side.

[0127] Approach 1: For each Msg1 (or RACH) transmission attempt, if an authorized SSB and / or CSI-RS with a 2-step CFRA resource cannot be detected, the UE may choose a 4-step CBRA (or 4-step RACH).

[0128] Approach 2: For each Msg1 (or RACH) transmission attempt, if an authorized SSB and / or CSI-RS with a 2-step CFRA resource cannot be detected, and a 2-step CBRA is configured, the UE can determine whether a 2-step CBRA is applicable based on a pre-configured RSRP threshold. If a 2-step CBRA is applicable, the UE can select it. Otherwise, the UE can select a 4-step CBRA (or 4-step RACH).

[0129] In some embodiments, with respect to the above approaches 1 / 2 described, if a 4-step CBRA (or 4-step RACH) is selected, the UE can continue to use the 4-step CBRA (or 4-step RACH) in subsequent RACH retransmission attempts in the RACH procedure.

[0130] In some embodiments, with respect to approach 2, if CBRA is selected, the UE can continue to use CBRA in subsequent RACH retransmission attempts in the RACH procedure.

[0131] In some embodiments, after N failures are detected with respect to the 2-step CFRA, the UE can then select the 4-step CBRA in subsequent RACH retransmission attempts in the RACH procedure and continue using the 4-step CBRA.

[0132] In some embodiments, with respect to approach 1 / 2, if a 4-step RACH is selected and a 4-step CFRA is configured, the UE may select the 4-step CFRA if any certified SSB and / or CSI-RS with 4-step CFRA resources can be found; otherwise, the UE may select the 4-step CBRA.

[0133] In some embodiments, with respect to approach 1 / 2, if the UE first selects a 2-step CBRA, selects a preamble within one preamble group, performs the 2-step CBRA, and then, if the UE returns to the 4-step CBRA, the UE can select a preamble from the same preamble group selected in the 2-step CBRA and perform the 4-step CBRA.

[0134] (C. How to configure a dedicated 2-step CFRA resource)

[0135] The following two resource pools may be considered for a two-step CBRA. • A resource pool for preamble resources. Regarding the preamble resource pool, a 2-step RACH can either share a resource pool with a 4-step RACH, or it can have a separate resource pool dedicated to it. • Resource pool for PUSCH resources. Mapping rules defined in RAN1 can be used to map PUSCH resources in a resource pool to preambles in a preamble resource pool. In a 4-step RACH, a dedicated RA resource pool can be configured for the CFRA, and if a dedicated RA resource pool is not configured, the UE can use the common RA resource pool configured for the 2-step CBRA. In some examples, the common resource pool can be configured by the RACH-ConfigCommon IE. With respect to the 2-step CFRA, there will be two separate resource pools (i.e., the preamble resource pool and the PUSCH resource pool), so the following approaches can then be considered for configuring the 2-step CFRA resources.

[0136] Approach 1: Both a dedicated preamble resource pool and a dedicated PUSCH resource pool are configured within dedicated signaling for CFRA, in which case the 2-step CFRA resources are reserved from the two dedicated resource pools.

[0137] Approach 2: Neither a dedicated preamble resource pool nor a dedicated PUSCH resource pool is configured, in which case CFRA is resourceed from a common resource pool configured for the serving cell.

[0138] Approach 3: Only a dedicated PUSCH resource pool is configured. In this case, preamble resources are reserved from the common resource pool, but PUSCH resources are reserved from the dedicated resource pool.

[0139] Approach 4: Only a dedicated preamble resource pool is configured. In this case, preamble resources are reserved from the dedicated resource pool, while PUSCH resources are reserved from the common resource pool.

[0140] Regarding the configuration of PUSCH resources for a two-step CFRA, the following approaches may be considered.

[0141] Approach 1: PRACH resource pool + PUSCH resource pool + (reserved preamble) for each SSB, or (RO + reserved preamble) for each CSI-RS. In Approach 1, a PRU (PUSCH Resource Unit) can be configured for all preambles reserved for a two-step CFRA, with the same mapping rules defined in RAN1. A PRU can be reserved by reserving the corresponding preamble. For example, the number of preambles reserved for a two-step CFRA in each RO can be shown, and PRUs can be configured for these ROs. Then, a dedicated preamble for each selected SSB (or both ROs and preambles for each configured CSI-RS) can be configured, and using the configured preambles, the UE can determine the PRU based on the same mapping rules. In addition, since this is configured in a way specific to one UE, its PUSCH resource pool can differ for different UEs, and resources in the pool can still be used for other purposes if they are not reserved for that UE. In some embodiments, the total number of preambles reserved within each RO for a two-step CFRA (or the total number of preambles reserved for a two-step CFRA linked to each SSB within each RO) can be configured in the UE through RRC signaling.

[0142] Approach 2: PRACH resource pool for each SSB + (reserved preamble + reserved PRU), or (RO + reserved preamble + reserved PRU) for each CSI-RS. In Approach 2, the PRU for SSB or CSI-RS (and / or for each preamble) can be configured explicitly and separately.

[0143] Approach 3: Dedicated configuration of PRACH resource pool + PRU + (reserved preamble) for each SSB, or (RO + reserved preamble) for each CSI-RS. Compared to Approach 2, a dedicated PRU configuration is provided for all SSB / CSI-RS. By using a dedicated PRU configuration, each RO (RACH opportunity) will be mapped to one PRU (for example, all preambles within one RO will be mapped to the same PRU). By using a dedicated PRU configuration, different mapping rules can be used for connected mode and idle / inactive mode.

[0144] Approach 4: A common configuration of PRACH resource pool + PRU for each SSB + (reserved preamble + dedicated PRU configuration), or (RO + reserved preamble + dedicated PRU configuration) for each CSI-RS. In Approach 4, the UE determines the PRU for each SSB / CSI-RS based on both common and dedicated configurations. For example, the time domain configuration and / or frequency domain configuration are given in the common configuration of the PRU, while the code domain configuration and / or power domain configuration are given in the dedicated PRU configuration.

[0145] (RA prioritization for D.2 step RACH)

[0146] Two approaches can be considered for structuring RA prioritization.

[0147] Approach 1: Common set of RACH prioritization parameters, which are applicable to both 2-step and 4-step RACH.

[0148] Approach 2: Separate RACH prioritization parameters, which are applicable to 2-step and 4-step RACH as appropriate. With respect to Approach 2, in some embodiments, the absence of IE in the structure of the RACH prioritization parameters for 2-step RACH means that the same values ​​configured for 4-step RACH will also be used for 2-step RACH.

[0149] Approach 1 / 2 can be used in a combined method, with some parameters shared between 2-step RACH and 4-step RACH, and other parameters configured separately for 2-step RACH and 4-step RACH.

[0150] Regarding the RACH prioritization parameters for 2-step RACH, at least one of the following parameters may be considered: powerRampingStepHighPriority for the preamble, powerRampingStepHighPriority for PUSCH, and scalingFactorBI for 2-step RACH.

[0151] (RA type selection in E-beam failure recovery)

[0152] For RACH triggered by beam failure recovery, if a 4-step CFRA resource for the beam failure recovery request is explicitly provided by the RRC, the UE should select 4-step RACH. For RACH triggered by beam failure recovery, if a 4-step CFRA resource for the beam failure recovery request is not provided by the RRC, and both 2-step and 4-step CBRA resources are configured, the UE can determine whether 2-step CBRA is applicable based on a pre-configured RSRP threshold. If 2-step CBRA is applicable, the UE should select 2-step CBRA. Otherwise, the UE should select 4-step CBRA (or 4-step RACH).

[0153] (F. Handling Hybrid Automated Iterative Requests (HARQs))

[0154] With respect to UL grants for Msg1 payload transmission (or Msg1 transmission), the UE can consider the NDI for the HARQ process linked to the UL grant to be toggled, even if the timeAlignmentTimer is not running.

[0155] (Aspect III: Resource Configuration)

[0156] Upon power-on, the UE can perform a cell lookup, obtain time / frequency synchronization with the cell, and attempt to decode the Master Information Block (MIB), which contains information for decoding SIB1 (System Information Block 1). After successfully decoding the MIB, the UE can attempt to decode SIB1 and obtain the necessary acquisitions for (re)selection / access to the cell and other functions. SIB1 and other system information are scheduled by DCI (Downlink Control Information) 1-0 with SI-RNTI (System Information-RNTI), which may have a fixed value of FFFF, and scrambled CRC (Cyclic Redundancy Check). The information contained in SIB1 and MIB may be cell-specific. In cases where a single satellite cell includes multiple satellite beams, transmission resources and parameters can be configured per satellite beam or per group of satellite beams, which can be done by broadcasting different system information within each satellite beam or each group of satellite beams.

[0157] (A. Instructions for using configurations per satellite beam resource)

[0158] In one aspect, the indicator can be included in system information (e.g., MIB, SIB1, or other system information) to indicate that transmission resources are configured in a manner specific to satellite beams / groups of beams. In another approach, PLMN (Public Mobile Communications Network) can be used as an indicator. For example, if PLMN indicates that a cell is a satellite cell, the resources are configured in a manner per satellite beam or per group of satellite beams.

[0159] (B. Configuration of transmission resources per satellite beam)

[0160] Any combination of the following approaches can be used to configure transmission resources for each satellite beam.

[0161] In one approach, the common parts of the configuration of each beam can be included in common system information, e.g., common SIB1, while separate information elements (IEs) can be used to configure satellite beam-specific parameters, e.g., SIB1:ith can be used for the i-th satellite beam. In some embodiments, the common parts of the configuration can include at least one of the following information: cell selection information, cell access control related information, UAC prohibition information, ims-EmergencySupports, eCallOverIMS-Support, connection establishment failure information, SI-scheduling information, UE timers and constants, uplink configuration, downlink configuration, parameters used for pre-compensation (e.g., common TA in this beam, offset to delay the start of the RAR window if the value of the common TA is not reused as an offset), parameters used to extend the k2 (scheduling offset) range (k2 is the duration between DCI reception and the corresponding scheduled transmission), beam selection / switching information (may include beam index, beam location information, e.g., beam center location information, beam service area information).

[0162] The uplink configuration may include at least one of the following: UL frequency, configuration for the initial uplink BWP (bandwidth portion), which then may include at least one of the following: RACH configuration for competition-based RACH, PUSCH configuration, PUCCH configuration, timing matching timer, subcarrier spacing to be used, frequency domain location and bandwidth for this bandwidth portion, and whether an extended cyclic prefix should be used for this bandwidth portion. The downlink configuration may include at least one of the following: DL frequency, BCCH configuration, PCCH configuration, and configuration for the initial downlink BWP, which then may include at least one of the following: PDCCH configuration, PDSCH configuration, subcarrier spacing to be used, frequency domain location and bandwidth for this bandwidth portion, and whether an extended cyclic prefix should be used for this bandwidth portion.

[0163] Beam-specific system information may include at least one of the following: connection establishment failure information, SI-scheduling information, UE timers and constants, uplink configuration, downlink configuration, parameters used for pre-compensation (e.g., common TA within this beam, offset to delay the start of the RAR window if the common TA is not reused), parameters used to extend the k2 range (where k2 is the duration between DCI reception and the corresponding scheduled transmission), and beam selection / switching information (which may include beam index, beam location information, e.g., beam center location information, beam service area information).

[0164] The uplink information may include the UL frequency, at least one of the configurations for the initial uplink BWP (bandwidth portion), which may then include at least one of the following: the RACH configuration for competition-based RACH, the PUSCH configuration, the PUCCH configuration, the timing matching timer, the subcarrier spacing to be used, the frequency domain location and bandwidth of this bandwidth portion, and whether an extended cyclic prefix should be used for this bandwidth portion. The downlink configuration may include the DL frequency, at least one of the BCCH configuration, the PCCH configuration, and the configuration for the initial downlink BWP, which may then include at least one of the PDCCH configuration, the PDSCH configuration, the subcarrier spacing to be used, the frequency domain location and bandwidth of this bandwidth portion, and whether an extended cyclic prefix should be used for this bandwidth portion.

[0165] In cases where redundant information exists within both common system information (e.g., MIB / SIB1 / other system information) and satellite beam-specific system information (e.g., MIB / SIB1 / other system information), the beam-specific configuration may take precedence over the common configuration within the common system information when the UE utilizes the corresponding beam resource to gain access to the cell.

[0166] In an alternative approach, a separate IE may be used for each satellite beam, each IE containing at least the same amount of information carried within the SIB1 as defined in specification TS38331. In addition, at least one of the following information may be further considered: parameters used for pre-compensation (e.g., common TA in this beam, offset to delay the start of the RAR window if the common TA is not reused), parameters used to extend the k2 range (k2 is the duration between DCI reception and the corresponding scheduled transmission), and beam selection / switching information (may include beam index, beam location information, e.g., beam center location information, beam service area information).

[0167] Alternatively, default system information (e.g., MIB / SIB1 / other system information) can be provided for each cell. If any information elements differ from those in the default configuration for each beam, a delta portion can be provided for each beam and take precedence over the default configuration.

[0168] Another approach involves broadcasting some typical system information for each cell (defined as default configurations, each linked to an index) to the UE, or predefined in the specification, with only one index of default configurations, with or without a delta portion, broadcast to the UE for each beam.

[0169] (C. Fetching appropriate system information from the UE)

[0170] The UE may need to decide which of the configuration information described above should be used when communicating with the BS. Any combination of the approaches discussed below can be used.

[0171] One approach is to configure different frequency bands for different satellite beams within the same satellite cell. For example, the mapping between different frequencies and the SIB1 of each beam may be included in the MIB, or cell-specific system information (carrying the common part of the information, e.g., a common SIB1 (if available)). Depending on the frequency band used, the UE can determine which beam-specific system information should be fetched and utilized.

[0172] Alternatively, the UE may decide to update beam-specific system information based on beam pattern information, satellite position estimation tables, and UE location information. For example, beam pattern information may include at least one of the following: the number of satellite beams in the cell, the service area of ​​the satellite beams, and the location information of the satellite beam centers. The beam pattern information and satellite position estimation tables may be included in the MIB, or cell-specific system information (carrying a common portion of the information, e.g., common SIB1 (if available)).

[0173] In yet another approach, the UE can derive beam-specific information based on the selected SSB. For example, if a satellite beam and an SSB are mapped one-to-one, the UE can derive beam-specific system information to be used according to the selected SSB. The mapping between the SSB index and the beam-specific system information can be included in the MIB, or in the cell-specific system information (carrying the common portion of the information, e.g., common SIB1 (if available)).

[0174] (D. Distinction of beam-specific system information)

[0175] In some embodiments, any combination of the following approaches can be used, for example, to distinguish beam-specific system information such as beam-specific SIB1.

[0176] In one approach, separated CORESET / SS can be configured for different SIB1s constituting beam-specific resources with the same RNTI. In another approach, the same CORESET / SS can be used, but different RNTI values ​​can be used for scrambling beam-specific SIB1s. The above configurations for receiving beam-specific SIB1s can be configured by the BS and included in the MIB, or cell-specific system information (common parts of the information, e.g., carrying common SIB1s if available), or can be predefined within the specification.

[0177] (E. System Information Update)

[0178] After obtaining the corresponding beam-specific system information, for example, beam-specific SIB1, the UE can store beam-specific SIB1 and, if available, common SIB1. The UE can update beam-specific SIB1 if at least one of the following conditions is met:

[0179] Condition 1: The content within SIB1 is changed, triggering the system information change notification procedure; Condition 2: The UE determines that the satellite beam being used has changed; Condition 3: The UE moves out of the effective area of ​​the corresponding beam-specific SIB1.

[0180] With respect to the above solutions identified in Section AE, the system information may also be configured in a specific manner for each group of satellite beams. The grouping of satellite beams may be configured by BS in a spatial domain division method, a frequency domain division method, or a time domain division method.

[0181] (Side IV: Intermittent Reception (DRX) Configuration) Hybrid Automatic Repeat Request (HARQ) is a combination of high-rate transmission error correction coding and ARQ error control. HARQ is used in telecommunications systems for high-speed and reliable data transmission by allowing a scheduler (e.g., BS) to adjust the transmission policy, such as the coding scheme, redundant versions, etc., according to feedback from the receiver (e.g., UE in downlink transmission). Due to long transmission delays in non-terrestrial networks, receiver feedback may not always reflect the instantaneous conditions of the channel and therefore may not serve as a reliable criterion for determining the retransmission policy. Furthermore, waiting for feedback to determine how to schedule retransmissions can significantly increase data transmission delays. To address this problem, HARQ feedback can be disabled, meaning that the scheduler can schedule retransmissions without waiting for receiver feedback. Disabling feedback can be done in a per-HARQ process manner, indicating that the UE can continuously schedule with HARQ that supports feedback and HARQ that does not support feedback.

[0182] Intermittent Reception (DRX) mechanisms are introduced into communication systems for power saving on the UE side, allowing the UE to periodically enter a sleep state. Here, "entering a sleep state" means that the UE is not expected to monitor the PDCCH. In the current NR specification, DRX functionality can be achieved by setting a series of timers, and the timers used to control the DRX functionality are tightly linked to HARQ feedback. Therefore, if feedback is disabled for the HARQ process, the configuration of the DRX timers, e.g., timer start time, timer length, or timer presence, may differ from the DRX configured for HARQ with feedback. Currently, DRX is configured per medium access control (MAC) entity, meaning there is only one set of DRX configurations configured for MAC entities. Since both HARQ with and without feedback may be supported simultaneously for MAC entities, and the DRX configuration may differ with respect to HARQ with and without feedback, the current DRX configuration may need to be adjusted to meet the new requirements. The following approaches may be considered for DRX configuration.

[0183] In the first approach, a set of two DRX configurations can be configured for a single MAC entity. For example, two separate information elements (IEs), e.g., DRX-Config-HARQ-enabled and DRX-Config-HARQ-disabled, can be used separately to configure DRX configurations for HARQ with feedback and HARQ without feedback. Each IE includes at least one of the following parameters: -drx-onDurationTimer: Duration at the start of the DRX cycle -drx-SlotOffset: Delay before starting drx-onDurationTimer -drx-InactivityTimer: Duration after PDCCH opportunity indicating a new UL or DL ​​transmission for MAC entities. -drx-RetransmissionTimerDL (excluding broadcast processes, per DL HARQ process): Maximum duration until DL retransmission is received -drx-RetransmissionTimerUL (process per UL HARQ): Maximum duration until a grant for UL retransmission is received. -drx-RetransmissionTimerULOffset(process per UL HARQ): Offset used to delay the start of drx-RetransmissionTimerUL -drx-RetransmissionTimerDLOffset(per DL HARQ process, excluding broadcast processes): Offset used to delay the start of drx-RetransmissionTimerDL -drx-RetransmissionTimerOffset: Offset used to delay the start of both drx-RetransmissionTimerDL and drx-RetransmissionTimerUL. -drx-LongCycleStartOffset: Defines the subframe from which long and short DRX cycles begin. Long DRX cycle and drx-StartOffset-drx-ShortCycle: Short DRX cycle. -drx-ShortCycleTimer: Duration that the UE will follow for short DRX cycles. -drx-HARQ-RTT-TimerDL (excluding broadcast processes, DL) HARQ-specific process): Minimum duration before DL allocation for HARQ retransmission is expected by the MAC entity. -drx-HARQ-RTT-TimerUL (UL process per HARQ):UL Minimum duration before HARQ retransmission grant is expected by MAC entities -drx-HARQ-RTT-TimerDLOffset(per DL HARQ process, excluding broadcast processes): Offset used to delay the start of drx-HARQ-RTT-TimerDL -drx-HARQ-RTT-TimerULOffset(Process per UL HARQ): Offset used to delay the start of drx-HARQ-RTT-TimerUL -drx-HARQ-RTT-TimerOffset(Per HARQ Process): Offset used to delay the start of drx-HARQ-RTT-TimerUL and drx-HARQ-RTT-TimerDL. With respect to the parameters mentioned above, at least one of the following can be configured differently for DRX configurations with and without feedback for HARQ. - Parameter start timing - Parameter stopping timing - Parameter length - Presence of parameters For UEs configured with a DRX configuration, when the DRX function is activated, the UE will select the corresponding DRX configuration to be used based on whether HARQ is disabled (e.g., no feedback is required, or the scheduler can schedule retransmissions without waiting for feedback) or enabled (e.g., HARQ feedback is required for each downlink transmission).

[0184] In the second approach, a common IE, e.g., DRX-Config, can be used to configure the common part of the DRX configuration for the HARQ process, regardless of whether feedback is required. An additional IE, e.g., drx-Config-HARQ-disabled, may optionally be included in the common IE if HARQ without feedback is supported simultaneously with HARQ with feedback in a single MAC entity. The common part of the DRX configuration includes at least one of the following: -drx-onDurationTimer: Duration at the start of the DRX cycle -drx-SlotOffset: Delay before starting drx-onDurationTimer -drx-InactivityTimer: Duration after PDCCH opportunity indicating a new UL or DL ​​transmission for MAC entities. -drx-RetransmissionTimerDL (excluding broadcast processes, per DL HARQ process): Maximum duration until DL retransmission is received -drx-RetransmissionTimerUL (process per UL HARQ): Maximum duration until a grant for UL retransmission is received. -drx-RetransmissionTimerULOffset(process per UL HARQ): Offset used to delay the start of drx-RetransmissionTimerUL -drx-RetransmissionTimerDLOffset(per DL HARQ process, excluding broadcast processes): Offset used to delay the start of drx-RetransmissionTimerDL -drx-RetransmissionTimerOffset: Offset used to delay the start of both drx-RetransmissionTimerDL and drx-RetransmissionTimerUL. -drx-LongCycleStartOffset: Defines the subframes from which long and short DRX cycles begin, and drx-StartOffset -drx-ShortCycle: Short DRX cycle -drx-ShortCycleTimer: Duration that the UE follows a short DRX cycle. -drx-HARQ-RTT-TimerDL (excluding broadcast processes, DL) HARQ-specific process): Minimum duration before DL allocation for HARQ retransmission is expected by the MAC entity. -drx-HARQ-RTT-TimerUL (UL process per HARQ):UL Minimum duration before HARQ retransmission grant is expected by MAC entities -drx-HARQ-RTT-TimerDLOffset(per DL HARQ process, excluding broadcast processes): Offset used to delay the start of drx-HARQ-RTT-TimerDL -drx-HARQ-RTT-TimerULOffset(Process per UL HARQ): Offset used to delay the start of drx-HARQ-RTT-TimerUL -drx-HARQ-RTT-TimerOffset(Per HARQ Process): Offset used to delay the start of drx-HARQ-RTT-TimerUL and drx-HARQ-RTT-TimerDL. - An IE used to configure a special DRX configuration for use when HARQ is disabled, for example, drx-Config-HARQ-disabled, which includes at least one of the following: -drx-InactivityTimer -drx-RetransmissionTimerDL (process per DL HARQ, excluding broadcast processes) -drx-RetransmissionTimerUL (process per UL HARQ) -drx-RetransmissionTimerULOffset(process per UL HARQ): Offset used to delay the start of drx-RetransmissionTimerUL -drx-RetransmissionTimerDLOffset(per DL HARQ process, excluding broadcast processes): Offset used to delay the start of drx-RetransmissionTimerDL -drx-RetransmissionTimerOffset: Offset used to delay the start of both drx-RetransmissionTimerDL and drx-RetransmissionTimerUL. -drx-HARQ-RTT-TimerDL (process per DL HARQ, excluding broadcast processes) -drx-HARQ-RTT-TimerUL (UL process per HARQ) -drx-HARQ-RTT-TimerDLOffset(per DL HARQ process, excluding broadcast processes): Offset used to delay the start of drx-HARQ-RTT-TimerDL -drx-HARQ-RTT-TimerULOffset(Process per UL HARQ): Offset used to delay the start of drx-HARQ-RTT-TimerUL -drx-HARQ-RTT-TimerOffset(Per HARQ Process): Offset used to delay the start of drx-HARQ-RTT-TimerUL and drx-HARQ-RTT-TimerDL. For UEs configured with DRX configurations, when the DRX functionality is activated, the UE will select the corresponding DRX configuration to be used based on whether HARQ is disabled or enabled. For example, if HARQ is enabled, the UE will apply the DRX configuration indicated by the common DRX configuration (e.g., DRX-Config) IE, except for the configuration included in a specific IE for DRX when HARQ is disabled, e.g., drx-Config-HARQ-disabled. For example, if HARQ is disabled, the UE will apply the common part included in DRX-Config along with the special configuration indicated by a specific IE for DRX when HARQ is disabled, e.g., drx-Config-HARQ-disabled. If the same parameters are defined in both IEs, the UE will select the corresponding parameters depending on whether HARQ is disabled. Furthermore, in some examples, some parameters may be included in the common part for HARQ without feedback, but not in a specific IE, and then those parameters may be specified so that they are not required for DRX when HARQ is disabled. Those parameters may include at least one of the following: -drx-RetransmissionTimerDL -drx-RetransmissionTimerUL -drx-RetransmissionTimerULOffset -drx-RetransmissionTimerDLOffset -drx-RetransmissionTimerOffset -drx-HARQ-RTT-TimerDL -drx-HARQ-RTT-TimerUL -drx-HARQ-RTT-TimerDLOffset -drx-HARQ-RTT-TimerULOffset -drx-HARQ-RTT-TimerOffset

[0185] In a third approach, a common IE (e.g., DRX-Config-common) can be used to configure the common part of the DRX configuration, which is used jointly by the HARQ with and without feedback. Separate IEs can be used to configure specific DRX parameters for the HARQ with and without feedback, respectively. Alternatively, in another example, the common part of the DRX configuration used jointly by the HARQ with and without feedback is configured within a single IE (e.g., DRX-Config), and in addition, separate IEs can be used to configure specific DRX parameters for the HARQ with and without feedback, respectively. Separate defined IEs can be included in the IE (e.g., DRX-Config) used to configure the common part of the DRX configuration. The common part of the DRX configuration includes one or more parameters described in the common part of the DRX configuration in the second approach discussed above. On the other hand, separate IEs for the DRX configuration of the HARQ with and without feedback may include one or more parameters described in the DRX configuration in the first approach discussed above.

[0186] While various embodiments of the present solution have been described above, it should be understood that they are presented only as examples and not as limitations. Similarly, various schematic diagrams may depict exemplary architectures or configurations, which are provided to enable those skilled in the art to understand the exemplary features and functions of the present solution. However, such those skilled in the art will understand that the present solution is not limited to the illustrated exemplary architectures or configurations and can be implemented using various alternative architectures and configurations. In addition, as will be understood by those skilled in the art, one or more features of one embodiment can be combined with one or more features of another embodiment described herein. Therefore, the scope and scope of this disclosure should not be limited by any of the exemplary embodiments described above.

[0187] It should be understood that any reference to elements in this specification using designations such as "first," "second," etc., does not generally limit the quantity or order of those elements. Rather, these designations can be used in this specification as a convenient means of distinguishing between two or more elements or instances of elements. Therefore, the references to first and second elements do not mean that only two elements may be employed, or that the first element must precede the second element in any given form.

[0188] In addition, those skilled in the art will understand that information and signals can be represented using any of the various different techniques and methods. For example, data, instructions, commands, information, signals, bits, and symbols, which may be referenced in the above description, can be represented, for example, by voltage, electric current, electromagnetic waves, magnetic fields or particles, light fields or particles, or any combination thereof.

[0189] Those skilled in the art will further understand that any of the various illustrative logic blocks, modules, processors, means, circuits, methods, and functions described in relation to the aspects disclosed herein can be implemented by electronic hardware (e.g., digital implementation, analog implementation, or a combination thereof), firmware, various forms of programs or design code incorporating instructions (which may be referred to herein as “software” or “software modules” for convenience), or any combination of these techniques. To clearly illustrate the interchangeability of hardware, firmware, and software, various illustrative components, blocks, modules, circuits, and steps are described above in general terms of their functionality. Whether such functionality is implemented as hardware, firmware, or software, or a combination of these techniques, depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art can implement the described functionality in various ways for each specific application, but such implementation decisions do not constitute a departure from the scope of this disclosure.

[0190] Furthermore, those skilled in the art will understand that the various illustrative logic blocks, modules, devices, components, and circuits described herein can be implemented in or performed within an integrated circuit (IC), which may include a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic device, or any combination thereof. The logic blocks, modules, and circuits may further include antennas and / or transceivers and can communicate with various components within a network or device. The general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, or state machine. The processor may also be implemented as a computing device, e.g., a DSP and a microprocessor, multiple microprocessors, a combination of one or more microprocessors with a DSP core, or any other suitable combination of configurations for performing the functions described herein.

[0191] When implemented in software, the functionality can be stored on a computer-readable medium as one or more instructions or code. Therefore, steps of the methods or algorithms disclosed herein can be implemented as software stored on a computer-readable medium. A computer-readable medium includes both computer storage media and communication media, and any medium that can enable the transfer of computer programs or code from one location to another. The storage medium can be any available medium that can be accessed by a computer. Such a computer-readable medium, but not limited to, as an example, may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer.

[0192] In this document, the term “module” means, as used herein, software, firmware, hardware, and any combination of these elements for performing the associated functions described herein. In addition, for the purposes of discussion, various modules are described as separate modules. However, as will be obvious to those skilled in the art, two or more modules may be combined to form a single module that performs the associated functions according to embodiments of this solution.

[0193] In addition, memory or other storage devices and communication components may be employed in embodiments of this solution. For the purpose of clarity, it should be understood that the above description describes embodiments of this solution with reference to different functional units and processors. However, it will be apparent that any preferred distribution of functionality between different functional units, processing logic elements, or domains may be used without deviation from this solution. For example, functionality illustrated as being performed by separate processing logic elements or controllers may be performed by the same processing logic elements or controllers. Thus, references to specific functional units are not to indicate a strict logical or physical structure or organization, but merely to a preferred means for providing the functionality described.

[0194] Various modifications to the implementations described herein will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other implementations without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the implementations shown herein, but rather to be the broadest scope of novel features and principles disclosed herein, as limited in the following claims.

Claims

1. A method, wherein the said method is A wireless communication device receives a first message from a wireless communication node, the RAR being within a Random Access Response (RAR) window, the RAR window being configured using an offset, the offset being contained in system information or indicated via radio resource control (RRC) signaling, The wireless communication device transmits a second message of the Random Access Channel (RACH) procedure to the wireless communication node. Includes, The second message is a method that includes a timing advance (TA) estimated by the wireless communication device for the RACH procedure.

2. The method according to claim 1, wherein the start of the RAR window is delayed by the wireless communication device using the offset.

3. A wireless communication device, wherein the wireless communication device is at least one processor Equipped with, The aforementioned at least one processor is Receiving a first message from a radio communication node via a receiver, comprising a RAR within a Random Access Response (RAR) window, wherein the RAR window is configured using an offset, the offset being contained in system information or indicated via radio resource control (RRC) signaling, The second message of the Random Access Channel (RACH) procedure is transmitted to the wireless communication node via the transmitter. It is configured to do the following: The second message includes a timing advance (TA) estimated by the wireless communication device for the RACH procedure.

4. The wireless communication device according to claim 3, wherein the start of the RAR window is delayed by the wireless communication device using the offset.

5. A method, wherein the said method is A wireless communication node transmits a first message to a wireless communication device, the message comprising a Random Access Response (RAR) within a RAR window, the RAR window being configured using an offset, the offset being contained within system information or indicated via radio resource control (RRC) signaling. The wireless communication node receives a second message of the Random Access Channel (RACH) procedure from the wireless communication device. Includes, The second message is a method that includes a timing advance (TA) estimated by the wireless communication device for the RACH procedure.

6. The method according to claim 5, wherein the start of the RAR window is delayed by the wireless communication device using the offset.

7. A wireless communication node, wherein the wireless communication node is at least one processor Equipped with, The aforementioned at least one processor is The transmission of a first message comprising a Random Access Response (RAR) within a RAR window to a wireless communication device via a transmitter, wherein the RAR window is configured using an offset, the offset being contained in system information or indicated via radio resource control (RRC) signaling, The receiver receives a second message of the Random Access Channel (RACH) procedure from the wireless communication device. It is configured to do the following: The second message includes a timing advance (TA) estimated by the wireless communication device for the RACH procedure, which is a wireless communication node.

8. The wireless communication node according to claim 7, wherein the start of the RAR window is delayed by the wireless communication device using the offset.

Images