User Equipment, Access Network Node, and Method

Abstract

A method is provided that is performed by a User Equipment (UE) (3), the method including receiving from an access network node (5, 9) random access configuration information identifying a plurality of Physical Random Access Channel (PRACH) preamble formats to be used by the UE (3) in a random access procedure, each of the plurality of PRACH preamble formats being associated with a respective resource within a time period for which the random access configuration information is applicable, and each of the plurality of PRACH preamble formats being associated with a respective number of repetitions.

Description

[Technical field]

[0001] The present disclosure relates to wireless communication systems and devices thereof operating in accordance with 3rd Generation Partnership Project (3GPP®) standards or equivalents or derivatives thereof. The present disclosure is particularly, but not exclusively, related to improvements regarding random access procedures in so-called "5G" (or "Next Generation (NG)" or "New Radio (NR)") systems, for example, for very large cells, such as those that arise when NR is provided over non-terrestrial network portions that comprise airborne or space network nodes. [Background technology]

[0002] The latest development in 3GPP standards is the so-called "5G" or "New Radio" (NR) standard, which refers to an evolving communications technology that is expected to support a variety of applications and services, such as Machine Type Communication (MTC), Internet of Things (IoT) / Industrial Internet of Things (IIoT) communications, vehicular communications and autonomous vehicles, high-definition video streaming, and smart city services. 3GPP intends to support 5G with the so-called 3GPP NextGen Radio Access Network (RAN) and 3GPP NextGen core (NGC) networks. Various details of 5G networks are described, for example, in the "NGMN 5G White Paper" V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, which is available at https: / / www.ngmn.org / 5g-white-paper.html.

[0003] End-user communication devices are generally referred to as User Equipment (UE), which may be operated by a human or may comprise an automated (MTC / IoT) device. It will be understood that base stations in a 5G / NR communication system are typically referred to as new radio base stations ("NR-BS") or "gNBs", although they may also be referred to using the term "eNB" (or 5G / NR eNB), which is more typically associated with Long Term Evolution (LTE) base stations (also generally referred to as "4G" base stations). 3GPP Technical Specification (TS) 38.300 V16.7.0 and 3GPP TS 37.340 V16.7.0, among others, define the following nodes: gNB: A node that provides NR user plane and control plane protocol termination towards the UE and is connected to the 5G core network (5GC) via the NG interface. ng-eNB: A node that provides Evolved Universal Terrestrial Radio Access (E-UTRA) user plane and control plane protocol terminations towards the UE and is connected to the 5GC via the NG interface. En-gNB: A node that provides NR user plane and control plane protocol termination towards the UE and acts as a secondary node in E-UTRA-NR dual connectivity (EN-DC). NG-RAN node: Either a gNB or a ng-eNB.

[0004] 3GPP is also working with the satellite communications industry to define an integrated satellite and terrestrial network infrastructure in the context of 5G. This is referred to as a Non-Terrestrial Network (NTN), a term that refers to a network or a segment of a network that uses aircraft or spacecraft for the transmission of data and control signaling. Satellite refers to a spacecraft in a Low Earth Orbit (LEO), Medium Earth Orbit (MEO), Geostationary Earth Orbit (GEO), or Highly Elliptical Orbit (HEO). Aircraft refers to a High Altitude Platform (HAP), which encompasses Unmanned Aircraft Systems (UAS), including tethered UAS, lighter than air UAS, and heavier than air UAS, all typically operating quasi-stationarily at altitudes between 8 and 50 km.

[0005] 3GPP Technical Report (TR) 38.811 V15.4.0 is a study on new radios to support such non-terrestrial networks. This study includes, among other things, a description of NTN deployment scenarios and related system parameters (architecture, altitude, orbit, etc.), as well as adaptation of 3GPP channel models for non-terrestrial networks (propagation conditions, mobility, etc.). 3GPP TR 38.821 V16.1.0 provides further details on NTNs.

[0006] Non-terrestrial networks are - To help facilitate the deployment of 5G services in unserved and underserved areas in order to upgrade the performance of terrestrial networks; - enhancing service reliability by providing service continuity to user equipment or mobile platforms (e.g. passenger vehicles - aircraft, ships, high-speed trains, buses); - Increasing service availability everywhere, especially for critical communications, future rail / maritime / aviation communications, and - Enabling 5G network scalability through the provision of efficient multicast / broadcast resources for data delivery towards the network edge or even directly to user equipment. is expected.

[0007] Non-terrestrial network access is typically characterized by the following elements (among others): - NTN terminal: This can refer to a 3GPP UE or a UE specific to a satellite system if the satellite does not directly serve 3GPP UEs. - Service link, which refers to the radio link between user equipment and the space / airborne platform (which may be in addition to the radio link with the ground-based RAN). - Space or airborne platforms. - Gateways connecting satellite or aeronautical access networks to the core network, it will be appreciated that the gateways will most likely be collocated with base stations (e.g. gNBs). - Feeder link refers to the radio link between the gateway and the space / airborne platform.

[0008] A satellite or aircraft usually generates multiple beams over a given area. The beams have a typically elliptical footprint on the surface of the Earth. The beam footprint can move over the Earth with the movement of the satellite or aircraft in its orbit. Alternatively, the beam footprint may be fixed to the Earth, in which case some beam pointing mechanism (mechanical or electronic steering features) may be used to compensate for the movement of the satellite or aircraft.

[0009] Once the UE has detected and selected a cell (and / or beam in case of 5G), it can attempt to access that cell and / or beam using an Initial Radio Resource Control (RRC) Connection Setup procedure, which typically comprises a random access procedure with four distinct steps. For 5G, before attempting initial access, the UE can perform a preamble transmission to the network (e.g., a base station such as a gNB) via a Physical Random-Access Channel (PRACH) to start the process to acquire synchronization in the Uplink (UL). This step is often referred to as a PRACH transmission or simply a Message 1 (Msg1) transmission. In response, the network responds with a Random-Access Response (RAR) indicating reception of the preamble and giving a Timing-Alignment (TA) command to adjust the UE's transmission timing based on the timing of the received preamble. This step is often referred to as a Message 2 (Msg2) transmission. The UE then transmits a third message (Message 3 or "Msg3") to the network over the Physical Uplink Shared Channel (PUSCH). The particular message transmitted by the UE in this step, and the contents of the message, depend on the context in which the random access procedure is being used. However, in the example of an initial wireless RRC connection setup, Msg3 includes an RRC Setup Request or similar message carrying a randomly generated temporary UE identifier. The network responds with a fourth message (Message 4 or "Msg4") carrying the randomly generated UE identifier received in Msg3 for contention purposes to resolve any collisions between different UEs using the same preamble sequence. If successful, Msg4 also transitions the UE to a connected state.

[0010] Similar random access procedures may also be used in other contexts within NR, including, for example, handover, connection re-establishment, requesting UL scheduling when dedicated resources for the scheduling request are not configured for the UE, etc.

[0011] A so-called two-step random access procedure has been introduced (in addition to the four-step random access procedure mentioned above). The two-step random access is primarily intended to support, among other things, (ultra) low latency communications, control plane latency of 10 ms, fast handovers, efficient channel access in unlicensed spectrum, and transmission of small data packets. However, the invention can also be applied to larger cells such as non-terrestrial cells. The main difference is that the four-step random access procedure requires two round-trip cycles between the UE and the base station, while the two-step random access procedure aims to reduce latency and control signaling overhead by using a single round-trip cycle between the UE and the base station. Effectively, this is achieved by combining the UE's PRACH preamble (Msg1) transmission and the scheduled PUSCH transmission (Msg3) into a single message (called "MsgA"). Similarly, the random access response (RAR / Msg2) and the contention resolution message (Msg4) from the base station to the UE are combined in a two-step random access procedure (referred to as "MsgB").

[0012] As one skilled in the art will appreciate, although a contention-based PRACH procedure is described, a non-contention-based (or "contention-free") procedure may also be used in which a dedicated preamble is assigned to the UE by the base station.

[0013] In 5G NR, 64 preambles are currently defined for each time-frequency PRACH opportunity. Each preamble transmission includes two parts: a Cyclic Prefix (CP) part and a preamble sequence part. The sequence part includes a preamble signature, which can be repeated (e.g., in preamble formats used for low Signal-To-Noise-Ratio (SNR) situations). Because the UE may be located anywhere in the cell and cell sizes can vary widely, there is an inherent uncertainty about how long it will take for a given preamble transmission to be received. To allow for this uncertainty in preamble reception timing, a guard period (GP) or "guard time (GT)" is provided following the preamble transmission, during which no signal is transmitted. The guard period (along with the CP) is designed to account for the maximum expected UL timing offset (i.e., based on the distance the UE may be away from the base station when it is at the cell edge, as represented by the cell radius). A UL timing misalignment that is larger than the expected maximum and therefore outside the range provided by the GP will result in the preamble leaking into the next frame, which is referred to as preamble ambiguity.

[0014] Multiple preamble formats are defined, each defined by a different respective CP+sequence+GP set. Currently, there are a total of 13 preamble formats defined for 5G for two different ("short" and "long") preamble types. There are four preamble formats defined for long preambles (referred to as formats 0-3) and nine preamble formats defined for short preambles (referred to as formats A1-A3, B1-B3, C0 and C2). Figures 6 and 7 show the preamble formats for long and short preambles, respectively.

[0015] Current random access procedures have the potential to cause several problems that become particularly significant as cell sizes increase and / or the number of UEs operating within a cell increases significantly. These problems are particularly relevant (but not limited to) to NTN cells.

[0016] The type of preamble used in a cell is currently configured as part of the cell random access configuration, and therefore, within a given cell, only one type of preamble can be used for initial access. Conventional random access resources are designed to accommodate the worst-case scenario where the UE is at the cell edge, which can cause bottlenecks in large and dense cells. In legacy cells, this one-size-fits-all approach may not have been a limiting issue, since the UE was not expected to have pre-compensation capabilities (and the base station location was not known to the UE anyway), there were typically fewer UEs in the cell, and the size of the legacy cells was limited. However, this is no longer the case as cell sizes increase (especially for NTN) and cells become more dense. Even in very large cells, UEs with accurate timing advance pre-compensation (based on UE location) could theoretically achieve 64 or more preambles per sequence route in a compact preamble format, which would result in more efficient and available random access resources for these UEs, but the current one-size-fits-all approach lacks the flexibility to achieve this benefit.

[0017] In 5G, the deployment of terrestrial networks may be driven by coverage of population centers rather than coverage of geographic areas. This may lead to the creation of geographic areas where 5G services are not accessible through the radio coverage of the terrestrial network. In such cases, the UE may experience an inability to continuously provide 5G services by a single or combination of terrestrial networks while the UE is in motion, whether associated with a pedestrian user or aboard a moving land mobile terrestrial platform (e.g., car, coach, truck, train), air platform (e.g., commercial or private jet), or marine platform (e.g., marine vessel).

[0018] 3GPP is specifying service requirements for the next generation of new services and markets, including that 5G systems may provide services using satellite access. 3GPP also specifies that 5G systems shall support service continuity between land-based 5G access networks and satellite-based access networks owned by the same operator or by agreement between the operators.

[0019] NTN objectives for Release 18 include support for voice and low data rate service use cases using commercial smartphones, with more realistic assumptions on antenna gain. In NTN, both Very Small Aperture Terminal (VSAT) UEs (with higher power capability, e.g. 33 dBm) and commercial UEs (with limited power, e.g. 23 dBm) can coexist in the same cell. Commercial UEs are expected to connect to NTNs in the absence of TN coverage. However, commercial UEs with limited power may experience a higher number of random access failures (compared to VSAT UEs). This may be even worse in the case of the so-called Ka-band. Therefore, random access extensions are needed to guarantee connectivity to NTNs by commercial UEs.

[0020] The PRACH transmit power is determined based on the maximum UE transmit power, the observed path loss, and the power ramping procedure. Note that in the case of satellite communication (when the payload to UE distance is large), the power required to transmit the PRACH can be significantly higher due to the high associated path loss.

[0021] Due to the nature of the (contention-based) random access procedure, there may be relatively frequent collisions between random access preamble transmissions by different UEs using overlapping resources. In this case, UEs that adopt a relatively smaller maximum transmit power are more likely to fail to complete random access even when they adopt transmit power ramp-up. Therefore, current approaches are not ideal to support the service continuity requirements of NTNs.

[0022] It is possible to configure RACH resources for extended coverage (e.g., more repetitions), but this would waste scarce uplink resources when the density of commercial UEs connecting to the NTN is low compared to VSAT UEs (due to service continuity). [Prior art documents] [Non-patent literature]

[0023] [Non-Patent Document 1] 3GPP TS 38.300 V16.7.0 [Non-Patent Document 2] 3GPP TS 37.340 V16.7.0 [Non-Patent Document 3] 3GPP TR 38.811 V15.4.0 [Non-Patent Document 4] 3GPP TR 38.821 V16.1.0 Summary of the Invention [Problem to be solved by the invention]

[0024] SUMMARY Accordingly, the present disclosure seeks to provide a method, and associated apparatus, that addresses or at least alleviates (at least one or more of) the above-mentioned problems.

[0025] To facilitate understanding by those skilled in the art, the present disclosure will be described in detail in the context of 3GPP systems (5G networks including NTN), but the principles of the present disclosure may be applied to other systems. Although the present disclosure is motivated by NTN use cases, the exemplary embodiments may be applied to any large cell and support relatively low power UEs (e.g., IoT devices) in regular terrestrial cells. [Means for solving the problem]

[0026] Aspects of the present disclosure are set out in the accompanying independent claims, whilst optional advantageous features are set out in the accompanying dependent claims.

[0027] In one aspect, the present disclosure provides a method performed by a user equipment (UE), the method including receiving, from an access network node, random access configuration information identifying a plurality of physical random access (PRACH) preamble formats for use by the UE in a random access procedure, each PRACH preamble format associated with a respective resource within a time period for which the random access configuration information is applicable, and each PRACH preamble format associated with a respective number of repetitions.

[0028] In one aspect, the present disclosure provides a method performed by an access network node, the method including transmitting, to a user equipment (UE), random access configuration information identifying a plurality of physical random access (PRACH) preamble formats for use by the UE in a random access procedure, each PRACH preamble format associated with a respective resource within a time period for which the random access configuration information is applicable, and each PRACH preamble format associated with a respective number of repetitions.

[0029] In one aspect, the present disclosure provides a user equipment (UE) comprising means (e.g., a memory, a controller, and a transceiver) for receiving random access configuration information from an access network node identifying a plurality of physical random access (PRACH) preamble formats for use by the UE in a random access procedure, each PRACH preamble format associated with a respective resource within a time period for which the random access configuration information is applicable, and each PRACH preamble format associated with a respective number of repetitions.

[0030] In one aspect, the present disclosure provides an access network node comprising means (e.g., a memory, a controller, and a transceiver) for transmitting, to a user equipment (UE), random access configuration information identifying a plurality of physical random access (PRACH) preamble formats for use by the UE in a random access procedure, each PRACH preamble format associated with a respective resource within a time period for which the random access configuration information is applicable, and each PRACH preamble format associated with a respective number of repetitions.

[0031] Aspects of the disclosure extend to corresponding systems, apparatus, and computer program products, such as computer readable storage media having stored thereon instructions, which are operable to program a programmable processor to perform the methods described in the above or claimed aspects and possibilities, and / or to program a computer suitably adapted to provide an apparatus as described in any of the claimed aspects.

[0032] Each feature disclosed in this specification (which term includes the claims) and / or shown in the drawings may be incorporated in the present disclosure independently (or in combination with) any other disclosed and / or shown feature, if it is technically feasible to do so. In particular, but not by way of limitation, any feature of a claim that is dependent on a particular independent claim may be introduced into that independent claim in any combination or individually, unless doing so would cause technical incompatibility or result in something that makes no technical sense. [Brief description of the drawings]

[0033] Exemplary embodiments of the present disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which: [Figure 1] 1 illustrates generally a mobile (cellular or wireless) telecommunications system in which exemplary embodiments of the present disclosure may be applied; [Figure 2A] 2 illustrates a possible implementation of an access network that may be used in the system of FIG. 1; [Figure 2B] 2 illustrates a possible implementation of an access network that may be used in the system of FIG. 1; [Figure 2C] 2 illustrates a possible implementation of an access network that may be used in the system of FIG. 1; [Diagram 3] FIG. 2 is a simplified block diagram illustrating the salient components of a user equipment that may be used in the system shown in FIGS. 1 and 2A-2C. [Figure 4] FIG. 2 is a simplified block diagram showing the main components of a base station / access network node that may be used in the systems shown in FIGS. 1 and 2A-2C. [Diagram 5] FIG. 2 is a simplified block diagram illustrating the main components of a distributed base station that may be used in the systems shown in FIGS. 1 and 2A-2C. [Figure 6] 1 illustrates diagrammatically different preamble formats that may be used for a long preamble; [Figure 7]1 illustrates diagrammatically different preamble formats that may be used for a short preamble; [Figure 8] 1 and 2A-2C show different ways in which the random access channel configuration can be signaled in the systems shown in FIG. [Figure 9] 1 and 2A-2C show different ways in which a random access channel configuration may be signaled in the systems shown in FIG. 1 and FIG. 2A-2C. [Figure 10] 1 and 2A-2C show different ways in which the random access channel configuration can be signaled in the systems shown in FIG. [Figure 11] 1 and 2A-2C show different ways in which the random access channel configuration can be signaled in the systems shown in FIG. [Figure 12] 1 and 2A-2C , there are shown several exemplary architecture options for providing NTN functionality in the system shown in FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0034] overview FIG. 1 illustrates generally a mobile (cellular or wireless) telecommunications system 1 in which exemplary embodiments of the present disclosure may be applied.

[0035] In this system 1, users of mobile devices 3 (UE) can communicate with each other and other users via access network nodes, respective satellites 4 and / or base stations 5, and a data network 7 using an appropriate 3GPP Radio Access Technology (RAT), e.g., E-UTRA (4G) and / or NR (5G) RAT. In the case of the E-UTRA RAT, the base stations 5 may be referred to as "eNBs" or "ng-eNBs", and in the case of the NR RAT, the base stations 5 may be referred to as "gNBs". The UEs 3 may comprise Narrow-Band IoT (NB-IoT) or MTC UEs, or may include appropriate NB-IoT or MTC functionality. The satellites connect to the data network 7 via gateways 9, which are typically implemented as part of the base stations 5. As one skilled in the art will appreciate, although three UEs 3, one satellite 4, and one base station 5 (gateway 9) are shown in Figure 1 for illustrative purposes, the system, when implemented, will typically include other satellites (space / airborne platforms), radio access network nodes (base stations / gateways), and mobile devices (UEs). It will be appreciated that the non-terrestrial (space or airborne) platforms 4 can include one or more satellites and / or aircraft.

[0036] It will be appreciated that a number of base stations 5 form a (radio) access network or (R)AN, and a number of NTN nodes 4 (satellite and / or UAS platforms) form a non-terrestrial based network (NTN). Each NTN node 4 is connected to an appropriate gateway 9 (in this case co-located with the base station 5) using a so-called feeder link, and connected to a respective UE 3 via a corresponding service link. Thus, when served by an NTN node 4, a mobile device 3 communicates data to and from the base station 5 via the NTN node 4 using the appropriate service link (between the mobile device 3 and the NTN node 4) and the feeder link (between the NTN node 4 and the gateway 9 / base station 5). In other words, the non-terrestrial network forms part of the (R)AN, but may also provide satellite communication services independently of E-UTRA and / or 5G communication services. Further details of an exemplary (radio) access network 8 including a non-terrestrial network portion are provided with reference to Figures 2A-2C.

[0037] Although not shown in Figure 1, neighbouring base stations 5 are connected to each other via suitable base station-base station interfaces (so-called "X2" interfaces, "Xn" interfaces, etc.) The base stations 5 are also connected to data network nodes via suitable interfaces (so-called "S1", "NG-C", "NG-U" interfaces, etc.).

[0038] The data (or core) network 7 (e.g. EPC in LTE or NGC in NR / 5G) typically includes logical nodes (or "functions") for supporting communications in the telecommunications system 1 and for (among other things) subscriber management, mobility management, charging, security, call / session management. Typically, the data network 7 includes user plane entities and control plane entities. The so-called Mobility Management Entity (MME) in 4G or Access and Mobility Management Function (AMF) in 5G is responsible for handling connectivity and mobility management tasks for the mobile devices 3, including configuring any power saving mechanisms. The data network 7 is also coupled to other data networks, such as the Internet or a similar Internet Protocol (IP)-based network (not shown in FIG. 1).

[0039] Each NTN node 4 controls multiple directional beams (at least one beam) in which an associated NTN cell may be provided. Specifically, each beam has an associated footprint on the Earth's surface that corresponds to the NTN cell. Each NTN cell (beam) has an associated Physical Cell Identity (PCI) and / or beam identification information. The beam footprint may move as the NTN node 4 moves along its orbit. Alternatively, the beam footprint may be fixed to the Earth, in which case a suitable beam pointing mechanism (mechanical or electronic steering) may be used to compensate for the movement of the NTN node 4.

[0040] 2A-2C, the following is an overview of some architecture options for an access network 8 that may be used in the system of FIG. 1. As can be seen, UE 3 may communicate via an NTN RAN 8 operating in accordance with one or more compatible radio access technologies (RATs), e.g., E-UTRA and / or 5G RAT. In the illustrated example, NTN RAN 8 includes a non-terrestrial (space or airborne) platform 4 (e.g., comprising one or more satellites and / or airborne vehicles), a base station or "gNB" 5 that operates one or more associated cells, and a gateway 9. Communications via NTN RAN 8 are typically routed through a core network 7 (e.g., a 5G core network or an evolved packet core (EPC) network) that corresponds to the data network shown in FIG. 1.

[0041] As can be seen in Figures 2A-2C, the NTN RAN 8 can be implemented in a number of different ways.

[0042] For example, as seen in FIG. 2A, the base station 5 may include a terrestrially located base station 5 that transmits and receives communications addressed to and originated from the UE (3) via a terrestrially located gateway 9 and via a non-terrestrial platform 4 that does not have base station functionality, respectively. The non-terrestrial platform 4 relays these communications to and from the UE 3 in the cell operated by the base station 5, and to and from the gateway 9 as necessary. The non-terrestrial platform 4 transparently relays these communications without on-board processing, effectively acting as a so-called "bent pipe". In this implementation, the feeder link between the gateway 9 and the non-terrestrial platform 4 effectively functions as part of the NR-Uu interface (or reference point) between the base station 5 and the UE 3. Similarly, the service link between the non-terrestrial platform 4 and the UE 3 effectively functions as another part of the NR-Uu interface (or reference point) between the base station 5 and the UE 3. The base station's communication link with the core network 7 (e.g., for signaling via the N1, N2, N3 interfaces / reference points, etc.) is provided exclusively on the ground.

[0043] As can be seen in Fig. 2B, the base station 5 may comprise a distributed base station 5, for example with a Central Unit (CU) 5C / 5U located on the ground and a Distributed Unit (DU) 5D provided on-board the non-terrestrial platform 4. The terrestrial CU 5C / 5U (having a control plane part 5C and a user plane part 5U) performs some of the (typically higher layer) functions of the base station 5, while the non-terrestrial DU 5D performs other (typically lower layer) functions of the base station 5. The terrestrial CU 5C / 5U communicates with the non-terrestrial DU 5D via a gateway 9 and an F1 interface implemented via a satellite radio interface between the gateway 9 and the non-terrestrial platform 4 on which the DU 5D is provided.

[0044] The non-terrestrial platform 4 transmits communications destined for and originating from the UE(3) in the cell operated by the base station 5 to and from the gateway 9 as required. However, in this implementation, lower layer processing of communications destined for and originating from the UE(3) respectively is performed on the non-terrestrial platform 4 by the DU 5D, and higher layer processing of communications destined for and originating from the UE(3) respectively is performed by the terrestrially located CU5C / 5U.

[0045] Thus, in this implementation, the feeder link between the gateway 9 and the non-terrestrial platform 4 effectively serves as an F1 interface (or reference point) between the CU and DU of the base station 5, while the service link between the non-terrestrial platform 4 and the UE 3 effectively serves as an NR-Uu interface (or reference point) between the base station 5 and the UE 3. The base station's communication link with the core network 7 (e.g., for signaling over the N1, N2, N3 interfaces / reference points, etc.) is provided solely terrestrially.

[0046] As can be seen in Figure 2C, the base station 5 may for example be provided on board the non-terrestrial platform 4. The base station 5 (gNB) on board the non-terrestrial platform 4 transmits communications destined for and originating from the UE (3) in a cell operated by the base station 5, and optionally to and from the core network 7 via a gateway 9. However, in this implementation, processing of communications respectively destined for and originating from the UE (3) is performed on the non-terrestrial platform 4 by the base station 5.

[0047] Thus, in this implementation, the feeder link between the gateway 9 and the non-terrestrial platform 4 effectively functions as part of the N1 / N2 / N3 interface (or reference point) between the base station 5 and the core network 7. The base station's communication link with the core network 7 (e.g., for signaling over the N1, N2, N3 interfaces / reference points, etc.) is thus provided partly via the feeder link and partly terrestrially, while the service link between the non-terrestrial platform 4 and the UE 3 effectively functions as the NR-Uu interface (or reference point) between the base station 5 and the UE 3.

[0048] Thus, the base station 5 controls one or more associated cells via the non-terrestrial platform 11. It will be appreciated that the base station 5 may be configured to support both 4G and 5G, and / or any other 3GPP or non-3GPP communication protocol.

[0049] The UE 3 and base station 5 are mutually configured to perform both contention-based Random Access (RA) and Contention Free (CFRA) RA procedures (e.g., as described in the introduction). For example, a suitable contention-based or contention-free RA procedure may be used to communicate downlink data arriving at the base station to the UE for the additional purpose of an NR cell for a Non-Standalone (NSA) implementation in which the base station instructs the UE to initiate an RA procedure over a Physical Downlink Control Channel (PDCCH) carrying an allocated preamble to gain initial access to the cell, to re-establish a communication link (e.g., an RRC connection) during a handover procedure, etc.

[0050] Beneficially, the system 1 allows different types of random access resources to be used for different UEs by providing support for multiple preamble formats within a given cell (and per BandWidth Part (BWP)). Specifically, unlike legacy systems where a base station can only signal a single Random Access Channel (RACH) configuration within a cell and therefore can use a single preamble format (per BWP), a base station 5 in the system 1 can signal multiple different PRACH configurations with associated different PRACH preamble formats to a UE 3 within a single cell (per BWP). This allows any of multiple different PRACH configurations and associated PRACH preamble formats to be used by a given UE 3, and therefore also allows different UEs 3 to use different PRACH configurations and different PRACH preamble formats simultaneously. Different PRACH preamble formats can be multiplexed.

[0051] We now describe, by way of example only, various devices that may be used to implement system 1.

[0052] User Equipment FIG. 3 is a simplified block diagram showing the main components of a UE 3 for implementation in the systems shown in FIGS. 1 and 2A-2C.

[0053] As shown, the UE 3 comprises transceiver circuitry 31 operable to transmit and receive signals to and from a base station 5 via an air interface 33 and one or more antennas (e.g., indirectly via a non-terrestrial platform 11 and possibly a gateway 9 if applicable, or directly in a fully terrestrial scenario).

[0054] The UE 3 has a controller 37 which controls the operation of the UE 3. The controller 37 is associated with a memory 39 and is coupled to the transceiver circuitry 31. Although not necessary for its operation, the UE 3 may of course have all the usual functionality of a conventional UE 3 (e.g. a user interface 35 such as a touch screen / keypad / microphone / speaker to allow direct control and interaction with a user), which may be provided by any one or any combination of hardware, software and firmware, as appropriate.

[0055] The controller 37 is configured, in this example, to control the overall operation of the UE 3 by means of program or software instructions stored in memory 39. The software may be pre-installed in the memory 39 and / or may be downloaded, for example, over a telecommunications network or from a Removable Data Storage Device (RMD). As shown, these software instructions include, among other things, an operating system 41, a communications control module 43, and a PRACH module 45.

[0056] The communication control module 43 is operable to control the communication between the UE 3 and the base station 5. For example, the communication control module 43 controls the part performed by the UE 3 in the flow of uplink and downlink user traffic and the flow of control data sent from the base station 5, including, for example, control data for managing the operation of the UE 3. The communication control module 43 is responsible for controlling the part performed by the UE 3 in procedures such as, for example, reception of measurement control / configuration information, reception of system information, handover procedures, performing appropriate timing advances to compensate for timing offsets, etc.

[0057] The PRACH module 45 manages the execution of PRACH procedures, such as contention-based or contention-free random access procedures, on the UE side, including, for example, identifying available PRACH configurations from received system information, identifying appropriate preambles and / or cyclic shifts to be used for RA procedures, receiving signaling to assign PRACH preambles to the UE (for contention-free procedures), transmitting random access messages (e.g., Msg1 or MsgA carrying preambles and / or Msg3) to the base station, processing and receiving random access messages (e.g., random access response messages (Msg2, Msg4, and / or MsgB)) from the base station, and / or receiving and transmitting any other PRACH related signaling.

[0058] Access Network Node FIG. 4 is a block diagram illustrating the main components of a generic access network node, such as the base station 5 / gateway 9 shown in FIG. 1 and FIG. 2A-2C. This block diagram is also applicable to the NTN node 4. As shown, the access network node comprises a transceiver circuit 51 for transmitting and receiving signals to and from user equipment (such as the mobile device 3) over an air interface (one or more antennas) 53, and a network interface 55 for transmitting and receiving signals to and from the core network 7 and base stations. In the case of an NTN node, the network interface 55 is part of the air interface 53. The access network node comprises a controller 57 for controlling the operation of the access network node in accordance with software stored in a memory 59. The software may be pre-installed in the memory 59 and / or may be downloaded, for example, via the telecommunications network 1 or from a removable data storage device (RMD). The software comprises, among others, an operating system 61, a communication control module 63, and a PRACH management module 65. Although not shown in FIG. 4, the network interface 55 also typically includes an inter-base station interface portion (eg, Xn) and a core network interface portion (eg, NG-C / NG-U).

[0059] The communication control module 63 is responsible for processing (generating / sending / receiving) signaling between the access network nodes and other nodes, such as the UE 3, base stations, and core network nodes. Such signaling may include, for example, control data (e.g., NAS, RRC, paging, system information, and / or the like) for managing the operation of the mobile device 3. It will be understood that the communication control module 63 may include multiple sub-modules (or "layers") to support specific functions. For example, the communication control module 63 may include a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an SDAP sub-module, an IP sub-module, an RRC sub-module, etc.

[0060] The communication control module 63 is operable to control the communication between the access network nodes and the UE 3, and between the access network nodes and other network entities connected to the access network nodes. For example, the communication control module 63 controls the part played by the access network nodes in the flow of uplink and downlink user traffic, as well as the flow of control data sent to the UE 3 served by the access network nodes, including, for example, control data for managing the operation of the UE 3. The communication control module 63 is responsible for controlling the part played by the access network nodes (base stations) in procedures such as, for example, communication of measurement control / configuration information, broadcast of system information, handover procedures, determination and signaling of appropriate timing advance to compensate for timing offsets.

[0061] The PRACH management module 65 manages the configuration of various different PRACH configurations for different types of UEs and for generating corresponding configuration information for configuring those PRACH configurations (e.g., for provision in system information communicated under the overall control of the communication control module 63). The PRACH management module 65 also manages the execution of PRACH procedures, such as contention-based or contention-free random access procedures on the base station side. This includes, for example, managing the allocation and signaling of PRACH preambles to UEs (for contention-free procedures), the reception and processing of random access messages (e.g., Msg1 or MsgA and / or Msg3 carrying preambles) from the UEs, the transmission of random access messages (e.g., random access response messages (Msg2, Msg4, and / or MsgB)) to the UEs, and / or the reception and transmission of any other PRACH related signaling.

[0062] If the access network node includes a distributed base station (distributed gNB or en-gNB), as shown in FIG. 5, the network interface 55 also includes an E1 interface and an F1 interface (F1-C for the control plane and F1-U for the user plane) for communicating signals between the respective functions of the distributed base station. In this case, the software also includes at least one of a gNB-CU-CP module 5C, a gNB-CU-UP module 5U, or a gNB-DU module 5D. If present, the gNB-CU-CP module 5C hosts the control plane portion of the RRC layer and the PDCP layer of the distributed gNB or en-gNB. If present, the gNB-CU-UP module 5U hosts the user plane portion of the PDCP layer and the SDAP layer of the distributed gNB or the user plane portion of the PDCP layer of the distributed en-gNB. If present, the gNB-DU module 5D hosts the RLC, MAC, and PHY layers of the distributed gNB or en-gNB.

[0063] It will be appreciated by those skilled in the art that the central units (e.g., 5C and / or 5U) may be implemented and physically located with the base stations, or may be implemented at a remote location, either as a single physical element or as a cloud-based or virtualized system. It will also be appreciated that a single central unit may serve multiple base stations 5.

[0064] Detailed Description Various methods that may be used in the system 1 will now be described, by way of example only.

[0065] Figures 6 and 7 show preamble formats for long and short preambles, respectively. As can be seen, each preamble format has a different respective CP+sequence+GP set. PRACH preamble formats 0-3 are referred to as long preambles, and PRACH preamble formats A1-A3, B1-B3, C0 and C2 are referred to as short preambles. It can be seen that by increasing the number of RACH sequence repetitions, better UL coverage can be achieved since the base station 5 combines transmissions from multiple RACH sequences (at the expense of the overall available UL resources).

[0066] Different preamble sequences that may be used for the preamble are typically based on Constant Amplitude Zero Auto Correlation (CAZAC) sequences, such as Zadoff-Chu sequences. The CAZAC sequences on which the preamble is based have a sequence length L of a number of samples that is a prime number (839 for long preambles and 139 for short preambles) corresponding to the same number of orthogonal codes. Thus, for such prime length sequences, there are L-1 (838 for long preambles and 138 for short preambles) different possible nearly orthogonal root sequences that can be generated with low correlation between them (1 / √839 for long sequences), each corresponding to a unique root index.

[0067] Different preamble sequences that are essentially orthogonal to each other can also be generated from different cyclic shifts of the same root index. However, this orthogonality is conditional on the cyclic shifts between different sequences being larger than the difference between the respective timings at which they are transmitted. Any such UL timing mismatch will effectively cause a shift in the cycle (e.g., the UE transmits sequence 100, but the base station interprets this as sequence 102 or 118). Therefore, in some cases, only a reduced subset of the possible cyclic shifts can be used to generate different preambles depending on the timing uncertainty (and thus the cell size). When all the actually possible preamble sequences for a given root index are to be fully utilized, it may be necessary to use different root indexes to generate different preamble sequences.

[0068] The use of cyclic shifts enables a preamble derived from a given root sequence to be divided among 1 to 64 groups (corresponding to preamble signatures) using the number of possible cyclic shifts that depends on the maximum expected delay, i.e., the cell radius as shown in Table 1 below.

Table 1

[0069] As an example, considering the 4th row of Table 1, when a preamble sequence derived from a given root index is fully utilized (e.g., divided into 8 for a cell with radius r, where 6.34 km < r < 13.85 km), it can be seen that 7 other root indexes with low correlation must be used to achieve 64 preamble sequences.

[0070] A UE with no timing misalignment could theoretically use 839 preambles per sequence without needing to use other root indices. This can be achieved, for example, when the UE has a recently stored Timing Advance (TA) value, when the UE is at the cell center (and thus transmitting with no UL delay), or when the UE has positioning capability and knowledge of the base station location and can therefore pre-calculate the TA value and apply it to compensate for the misalignment that would otherwise occur (this is referred to as pre-compensation).

[0071] The concept of Zero-Correlation Zone (ZCZ) is used to describe the maximum expected delay / shift between one accepted sequence and the next. From this shift the base station can estimate the Timing Advance (TA) required for a TA command. The set of cyclic shifts that can be used within a cell is configured by the base station by the so-called Zero-Correlation Zone parameter, which forms part of the random access configuration provided by the base station in the system information (e.g. in System Information Block type 1 (SIB1)).

[0072] The 838 root indexes are divided among neighboring cells and may therefore be exhausted, ultimately limiting the number of available preambles in a given time / frequency resource.

[0073] The current theoretical cell size limit is about 100 km radius to allow for maximum timing mismatch caused by UL delay for UEs at the cell edge (up to 0.8 ms sequence length and maximum GP of 0.93 ms, i.e. preamble format 2 in FIG. 6 corresponds to the final limit). However, significantly larger cells (up to 1000 km radius) are expected in NTN, which may lead to larger differences in UL delay for different UE preambles on RACH, depending on the satellite altitude and the maximum angle between the satellite and the cell center.

[0074] The size of the cell adversely affects random access resources in multiple ways, and the effect is worse than the square of the cell radius. Specifically, the number of UEs in a cell scales with the square of the radius (quadratic scaling). Preamble formats with longer GPs result in longer preamble sequences and therefore fewer preambles per resource (linear scaling). Furthermore, long ZCZ can lead to poor sequence utilization (typically one signature per root), which can lead to more interference between preambles since different root sequences are not completely orthogonal. Poor sequence utilization also leads to over-utilization of root sequences, resulting in a progressive deterioration with cell size, and represents a fundamental physical limitation.

[0075] To avoid UL mismatch and preamble format issues that would result from providing NR over NTN, UEs are currently required to support at least UE-specific TA calculation for pre-compensation based on at least Global Navigation Satellite System (GNSS) acquired position and knowledge of serving satellite ephemeris. However, such capability TA pre-compensation may not be sufficient, and support for UEs without GNSS capability is not precluded for future releases of the standard.

[0076] The PRACH transmit power is determined based on the maximum UE transmit power, the observed path loss, and the power ramping procedure. Note that in the case of satellite communication (when the payload to UE distance is large), the power required to transmit the PRACH can be significantly higher due to the high associated path loss.

[0077] More specifically, 3GPP TS 38.213 V17.1.0, section 7.4, describes how a UE transmits a physical random-access channel (PRACH) on an active UL BWP b of carrier f of serving cell C based on a DL RS for serving cell C at a transmission opportunity i. PRACH,b,f,c The transmission power for (i) is P PRACH,b,f,c (i) = min{P CMAX,f,c (i),P PRACH,target,f,c +PL b,f,c}[dBm] where P CMAX,f,c (i) is the UE configured maximum output power defined in 3GPP TS 38.101-1, TS 38.101-2, and TS 38.101-3 for carrier f of serving cell C within transmission opportunity i, and P PRACH,target,f,c is the PRACH target received power PREAMBLE_RECEIVED_TARGET_POWER provided by higher layers for the active UL BWP b of carrier f of serving cell C, and PL b,f,c is the path loss for an active UL BWP b of carrier f based on the DL RS associated to the PRACH transmission on the active DL BWP of serving cell C, calculated by the UE in dB as referenceSignalPower upper layer filtered RSRP in dBm

[0078] The different power classes of UE 3 are based on their maximum transmit power capabilities, as summarized in Table 2.

[0079] [Table 2]

[0080] Furthermore, 3GPP TS 38.101-1 V17.5.0, section 6.2.4 states that the UE should determine its configured maximum output power P for carrier f of serving cell c in each slot. CMAX,f,c This specifies that the user is permitted to set the configured maximum output power P CMAX,f,c is set within the following bounds:

number

[0081] Effectively, this means that for each slot, the maximum transmit power may vary with a certain margin based on the UE implementation.

[0082] The relevant 3GPP standard (TS 38.331 V17.0.0) defines that the preamble format is broadcast using various information elements in SIB1 to provide the relevant RACH parameters (or information elements) as follows: - RACH-ConfigCommon: This information element is used to specify cell-specific random access parameters. It includes, among others, the RACH-ConfigGeneric and prach-RootSequenceIndex-r16 fields. - RACH-ConfigGeneric: This information element is used to specify the random access parameters for both normal random access and beam failure recovery. It contains the prach-ConfigurationIndex field, which provides, among other things, the format, location, and periodicity of the random access resources.

[0083] However, according to current 3GPP specifications, for initial acquisition purposes, only one preamble format can be broadcast per cell at a time.

[0084] Some of the fields that may be included in the RACH-ConfigCommon information element are summarized below:

number

[0085] Some of the fields that can be included in the RACH-ConfigGeneric information element are summarized below:

number

[0086] Commercial UEs (e.g., smartphones) are power limited and require RACH extensions (e.g., more repetitions), whereas VSAT devices have higher power capabilities and therefore do not require coverage extension solutions.

[0087] To support both commercial smartphones and VSAT devices to access NTN cells, while simultaneously minimizing random access failures, this system 1 employs multiple RACH formats that are multiplexed together per cell to meet the needs of different UE types / power classes.

[0088] Advantageously, this approach makes it possible to avoid (or reduce the need to) configure most (or all) of the RACH resources for extended coverage (e.g., more repetitions), which would waste scarce UL resources when the density of commercial UEs connecting to the NTN is low compared to VSAT UEs (due to service continuity).

[0089] As explained above, NR supports different PRACH formats with different repetition patterns, but the current specification only allows for a single RACH format per cell.

[0090] However, in NTN or other large cell scenarios, it may be beneficial to support multiple PRACH formats per cell and allow the UE 3 to select one PRACH format based on the conditions specified below.

[0091] This approach would result in better resource utilization (e.g., based on the percentage of power-limited UEs, the network could decide whether to use one or more PRACH formats with a higher number of repetitions).

[0092] Although this disclosure describes multiplexing two RACH formats, it will be appreciated that the same techniques may be applied to support multiplexing of more than two RACH formats.

[0093] Below are relevant details of the signaling to achieve RACH format multiplexing, and a description of some possible RACH resource selection criteria based on UE transmit power.

[0094] Option 1 FIG. 8 illustrates an example approach for implementing two or more PRACH preamble formats in a cell (eg, per UE type / power class / max power).

[0095] In this case, a single entry in the PRACH configuration table indicates the time opportunity for each PRACH format that may be multiplexed together. In the example shown in Figure 8, frequency resources are shared between two preamble formats, but the time opportunities are different. More specifically, the prach-ConfigurationIndex field of the RACH-ConfigGeneric information element is set to an appropriate value associated with a particular set of two or more PRACH preamble formats, each format associated with a respective resource (in the time / frequency domain). Each format may also be associated with a particular UE power class / maximum power value or UE type (e.g., VSAT UE or commercial UE).

[0096]

number

[0097] In this case, the "Preamble Format" column in Table 3 may be adapted to include multiple preamble formats (at least two preamble formats) (at least for some values ​​of PRACH configuration index). Another column may be added to indicate the associated UE type / power class / max power value (if appropriate). However, it will be appreciated that the associated UE type / power class / max power (for each preamble format or set of preamble formats) may be indicated using system information, etc.

[0098] [Table 3]

[0099] This approach is illustrated in Figure 8 using two different PRACH preamble formats as an example. As can be seen, in each RACH configuration period for which the random access configuration (RACH-ConfigGeneric information element) is applicable, different PRACH preamble formats are allocated to different resources (in this case different time domain resources such as different subframes / slots / symbols). Thus, each UE 3 in a cell can transmit a random access preamble using an appropriate PRACH preamble format on its allocated resource, thereby avoiding causing interference to other UEs 3 (of different types of power classes).

[0100] For a particular PRACH configuration period, the entries (PRACH configuration index) may indicate the subframes and / or slots corresponding to each PRACH format. In this case, the following cases are assumed: - Each subframe contains a single PRACH format type, and the entries indicate which subframes are mapped to which PRACH format types. - Each slot contains a single PRACH format type, and the entry indicates which slots are mapped to which PRACH format type. For example, slots 3, 6, 7, and 8 may be for PRACH format-1 and the remaining slots for PRACH format-2. Alternatively, even slots of each subframe may be allocated to PRACH format-1 and odd slots to PRACH format-2. - Within each slot, multiple PRACH formats may be supported, in which case the entry indicates which symbols / opportunities of the slot are used for each PRACH format type.

[0101] It will be appreciated that it may not be possible to define a new PRACH configuration table as described above. To ensure backward compatibility with legacy UEs, a new RACH configuration index may be defined that includes all RACH opportunities that correspond to the legacy RACH configuration table indexes. On top of the already existing RACH opportunities, new RACH opportunities corresponding to different RACH formats may be added for UEs that support multiple PRACH preamble format designs (which may be specified in new versions of the standard).

[0102] An example is given in Table 4 below, where entry #94 allocates preamble format A1 to legacy UEs and preamble format A3 to newer UEs.

[0103] [Table 4]

[0104] This approach may be particularly beneficial for technologies other than NR (e.g., 6G and beyond) that are less likely to have backward compatibility issues.

[0105] To handle the transmit power requirements corresponding to different RACH formats, an offset and / or power value may be provided for the preamble receive target power for each RACH format to take into account the fact that different receive power is required for the multiplexed RACH formats due to different RACH sequence repetition numbers of the formats.

[0106] This offset or power value may be a configured value or a fixed offset in the specification (e.g., per PRACH configuration index), or may be derived based on the number of repetitions of the PRACH sequence in the PRACH format (e.g., a larger offset may be used for a larger number of sequence repetitions).

[0107] Other RACH parameters, such as the root sequence index, the number of RACH preambles, etc., may be common to each RACH format. Since most of the parameters are common between formats, it is appropriate to multiplex RACH sequences corresponding to the same PRACH sequence length (LRA).

[0108] RACH format / opportunity selection for subsequent RACH attempts may be achieved using any of the following alternatives: - Alt-1: The same RACH format may be used for each RACH attempt of the random access procedure. - Alt-2: The UE is allowed to select a different RACH format (if the PRACH format selection criteria changes), but must use the same power ramping counter as was used in the last RACH attempt when the RACH format changes between attempts. - Alt-3: The UE is allowed to select a different RACH format (if the PRACH format selection criteria changes) and increments the power ramping counter as normal. - Alt-4: The UE is only allowed to select a different RACH format if the new PRACH format requires a lower transmission power than the current PRACH format. Alt-5: The UE is allowed to select a different RACH format (after observing N RACH failures, where the value of N can be configured for the UE) only if the new PRACH format has more repetitions or a longer PRACH sequence than the current PRACH format.

[0109] Option 2 9 illustrates another example approach for implementing more than one PRACH preamble format in a cell (e.g., per UE type / power class / max power), where multiple PRACH configuration indices are provided per cell along with other RACH configuration parameters shared by index.

[0110] For example, multiple PRACH configuration indexes may be provided using a single RACH-ConfigGeneric field in the RACH configuration:

number

[0111] Alternatively, each PRACH configuration index may be provided using a separate RACH-ConfigCommon field for each RACH configuration.

[0112] Note that this approach may require additional consideration on how to time multiplex multiple PRACH configuration indexes due to the risk of overlapping RACH opportunities corresponding to different RACH configuration indexes. To avoid overlapping RACH opportunities, the network (base station 5) selects RACH configuration indexes to be multiplexed that do not have overlapping RACH opportunities.

[0113] It should be appreciated that some of the parameters are provided independently for the second PRACH configuration index, including, for example, but not limited to: - a frequency offset (msg-1FrequencyStart) and the number of frequency domain PRACH resources (msg-1FDM) to perform frequency multiplexing between RACH formats; Preamble received target power (preambleReceivedTargetPower) and power ramping step (powerRampingStep) can be set independently to take into account different transmit power limitations of different UEs; The maximum number of allowed RACH attempts (preambleTransMax) can be set independently to account for different collision probabilities for RACH occasions; and - zeroCorrelationZoneConfig and restrictedSetConfig can be provided independently to account for different correlations of different RACH sequences.

[0114] It will be appreciated that the alternatives for RACH format selection for subsequent RACH attempts may be the same as for option 1 (see Alt-1 to Alt-5 listed above).

[0115] It will be appreciated that the mapping from Synchronization Signal Blocks (SSBs) to RACH is performed independently for each PRACH configuration index if a RACH opportunity is available. RACH opportunities are counted independently for each PRACH configuration index. The PDCCH order may be used to indicate the PRACH format to be used by the UE to initiate the RACH. In other words, the UE may select one of multiple PRACH formats based on the PDCCH order.

[0116] Option 3 Figure 10 illustrates another example approach for implementing more than one PRACH preamble format in a cell (e.g., per UE type / power class / max power). In this case, each PRACH configuration index is provided using a separate RACH-ConfigCommon field for each RACH configuration, as shown in Figure 10 (and below). This approach also allows for allocating different frequency resources to different PRACH preamble formats (or different UE power classes / power levels).

[0117]

number

[0118] Using a respective (different) RACH configuration for each UE type / power class allows configuring all random access parameters independently for each RACH preamble format. This approach allows greater flexibility in terms of RACH resource configuration, but incurs a relatively high signaling overhead. Furthermore, similar to option 2, time / frequency multiplexing of the RACH configurations needs to be carefully considered.

[0119] In this case, RACH format selection for the subsequent RACH attempt may be achieved using one of the following alternatives: - Alt-1: The same RACH format may be used for each RACH attempt of the random access procedure since all parameters (e.g. power ramping) are set independently. - Alt-2: The UE may be allowed to change the PRACH format between subsequent RACH attempts of the random access procedure, but the associated power ramping counters need to be updated based at least on the configured power ramp step for the new RACH format and the current power ramp power applied.

[0120] For Alt-2, the following formula can be used: New Power Ramping Step = Current power ramp power / power ramp step in new PRACH format

[0121] Option 4 Figure 11 illustrates another example approach for implementing two or more PRACH preamble formats over two or more cells. In this case, each PRACH configuration index (identifying the respective preamble format) is provided using a separate uplinkConfigCommon information element, as shown below. Effectively, each cell may be assigned to one or more UE types / power classes / maximum transmit power values, and different UEs may be served via different cells.

[0122] For example, a first PRACH preamble format (with an associated PRACH configuration index) may be configured via a first uplinkConfigCommon information element, and a second PRACH preamble format (with its associated PRACH configuration index) may be configured via a second uplinkConfigCommon information element (hereinafter denoted as "uplinkConfigCommon2"). It will be appreciated that a supplementaryUplink information element may be used to configure the second PRACH preamble format, if appropriate.

[0123]

number

[0124] Using this scheme, the base station 5 can configure two uplink cells, one with a relatively small number of RACH repetitions / formats and another with a relatively large number of RACH repetitions / formats. Each uplink cell can be associated with a UE with a particular power class value or maximum transmit power level. Thus, the criteria for selecting the correct uplink carrier can be based on the UE power class or maximum UE transmit power level. This scheme can also be extended to use more than two cells to support more than two UE power classes or transmit power levels, if appropriate.

[0125] Cells share SSB transmission / Remaining Minimum System Information (RMSI) as well as so-called Supplementary UpLink (SUL) functionality. For example, the network can configure a supplementary uplink carrier and indicate that the supplementary uplink carrier is associated with a set of (at least one) UE power class or UE maximum transmit power level.

[0126] This solution is also applicable to RACH multiplexing for the presence of UE GNSS capability. Specifically, the UE may select one of the uplink carriers to perform random access (and apply the associated RACH configuration) based on whether the UE's location is available or not.

[0127] Coverage expansion aspects To support two-step random access via a cell employing one of the options described above, the following approach may be used.

[0128] For each RACH format / configuration, the network may provide at least a partial (or complete) PUSCH configuration for transmitting MsgA. Parameters that may be specific to a particular PRACH preamble format / RACH configuration include: - the number of PUSCH repetitions, - Modulation and Coding Scheme (MCS) for PUSCH transmission, and - Frequency and time allocation of PUSCH opportunities Contains one or more of the following:

[0129] Alternatively, the MsgA configuration may be applicable only for a single PRACH format (i.e., the two-step RACH is enabled for a single PRACH format). The applicable PRACH preamble formats / RACH configurations may be predefined (e.g., in the relevant 3GPP specifications) or may be configured for the UE 3 by the base station 5.

[0130] A similar approach can be used for the four-step random access case. For example, the UE 3 may transmit a random access preamble (Msg1) to the base station 5 according to a RACH preamble format and / or on resources associated with coverage extension to initiate the random access procedure. In response to the preamble transmission, the base station 5 identifies the PUSCH resource with coverage extension to be used by the UE 3 to transmit the third message (Msg3) of the four-step random access procedure.

[0131] If UE3 selects a PRACH resource with extended coverage (e.g., more repetitions) (or uses a PRACH format corresponding to the coverage extended resource), the network can provide a PUSCH resource for Msg3 corresponding to a relatively higher number of repetitions.

[0132] It will be appreciated that the number of repetitions for a PUSCH corresponding to a coverage extended PRACH resource may either be configured via system information or explicitly provided by the network, for example via Downlink Control Information (DCI) for the PUSCH.

[0133] To support UEs that require coverage extension, RACH resource selection / iteration selection can be realized based on UE power class / maximum UE transmit power. The network provides appropriate configuration information on which RACH resource / format to use.

[0134] For example, for each power class / maximum transmit power level, the network may configure a signal strength threshold that indicates that the UE should use extended coverage RACH resources to transmit the preamble (Msg1 / MsgA) if the Reference Signal Received Power (RSRP) (e.g., RSRP for SSB) is less than the threshold for the given power class / maximum transmit power level.

[0135] Also, path loss may be used instead of RSRP, in which case the UE uses extended coverage RACH resources if the associated path loss determined by the UE is greater than a threshold.

[0136] If the instantaneous UE power level is low (e.g., due to in-device coexistence reasons) and the base station is unable to decode the UE's random access transmission, the UE may be configured to wait until its available transmit power is sufficient for RACH decoding at the base station.

[0137] Alternatively, RACH resource selection / iteration selection may be achieved based on the power difference between the instantaneous Pmax and the power required for successful reception at the base station.

[0138] For example, the network can configure RACH resources for different repetitions. If the required transmit power > Pmax + Offset, the UE will use the PRACH resource with a higher number of repetitions (if available). In this case, the offset may be UE implementation specific, fixed in the relevant 3GPP specification, or configured in the UE via system information.

[0139] It will be appreciated that this check may be required for each RACH attempt during an ongoing RACH (due to the power ramp).

[0140] Base Station Procedures The following is a description of some ways in which the base station may select an appropriate RACH format for multiplexing in a cell. It will be appreciated that based on the recorded event reports by the UEs, the network can determine how many UEs in coverage are unable to connect to a cell (NTN or non-NTN cell) due to low PRACH power. The network (base station) may be able to do so based on one or more of the following: - an indication from the UE regarding (e.g. at least one) instance in which a random access procedure for establishing a connection to the cell has failed; - an indication from the UE regarding (e.g., at least one) instance in which the random access procedure / connection establishment procedure was aborted due to lower UE transmit power; and - An indication from the UE regarding the instances (e.g., at least one instance) in which the UE failed to camp on a cell. For each such event, the UE may also indicate one or more of the following: - the average power difference between the required PRACH transmit power calculated by the UE and the maximum transmit power during the random access procedure; - cell identity, - location related information (e.g. GNSS / GPS coordinates or downlink beam identification information, e.g. SSB index), In the case of terrestrial mobile cells, it is also useful to include the time of occurrence of an event based on which the network can determine the satellite position and coverage at a given time, - The RACH format type configured in the associated RACH resource.

[0141] Using the above information and the power class information of the UE (provided in separate capability signaling), the network can determine whether to configure any additional PRACH formats (at least for some UEs / UE types) and which formats to use.

[0142] Signaling of multiple PRACH configurations There are various ways in which multiple PRACH configurations may be signaled by the base station 5 to the UEs 3 in a cell operated by the base station 5 (eg, a cell of the NTN).

[0143] It will be appreciated that the different PRACH configurations are typically provided in a system information broadcast (SIB1). In particular, the different PRACH configurations may be provided using information elements (IEs) of the initialUplinkBWP IE / BWP-Uplink Common IE, uplinkConfigCommon IE / UplinkConfigCommonSIB IE, and servingCellConfigCommon IE / ServingCellConfigCommonSIB IE of SIB1.

[0144] SIB1 contains information relevant when evaluating whether a UE is allowed to access a cell and defines the scheduling of other system information. It also contains radio resource configuration information common to all UEs and barring information that applies to the unified access control.

[0145] The IE ServingCellConfigCommonSIB is used to configure the cell specific parameters of the UE's serving cell in SIB1. The IE UplinkConfigCommonSIB provides the common uplink parameters of the cell. The IE BWP-UplinkCommon is used to configure the common parameters of the uplink BWP. They are "cell specific" and the network ensures the necessary alignment with the corresponding parameters of other UEs. The common parameters of the initial bandwidth part of the primary cell are also provided via system information. For all other serving cells the network provides the common parameters via dedicated signaling.

[0146] The IE RACH-ConfigCommon is used to specify cell-specific random access parameters for a given PRACH configuration. This IE contains, among other IEs, the RACH-ConfigGeneric IE and the prach-RootSequenceIndex-r16 IE. The IE RACH-ConfigGeneric is used to specify random access parameters for both normal random access and beam failure recovery. The IE prach-RootSequenceIndex-r16 provides the PRACH root sequence index and has a value in the range of 0.837 or 0.137 depending on whether the sequence length is 839 or 139.

[0147] The IE RACH-ConfigGeneric contains, among other IEs, a prach-ConfigurationIndex IE indicating the location and periodicity of the RA resources, a ra-ResponseWindow IE indicating the Msg2(RAR) window length in number of slots and varying depending on the UL TA mismatch, and a zeroCorrelationZoneConfig IE providing the cyclic shift configuration.

[0148] In one option, a respective RACH-ConfigCommon IE is included in SIB1 for each PRACH configuration, e.g., each RACH-ConfigCommon IE includes at least the version of the associated IE for defining the respective PRACH configuration (e.g., a respective RACH-ConfigGeneric IE for each PRACH configuration).

[0149] In another option, a single RACH-ConfigCommon IE is included in SIB1, but respective instances of all relevant IEs are included in the single RACH-ConfigCommon IE for each PRACH configuration, e.g., the single RACH-ConfigCommon IE includes at least respective versions of the relevant IEs for defining each PRACH configuration (e.g., respective RACH-ConfigGeneric IEs for each PRACH configuration).

[0150] In yet another option, a single RACH-ConfigCommon IE and a single RACH-ConfigGeneric IE are included in SIB1, but respective instances of all relevant IEs for each PRACH configuration are also included in the single RACH-ConfigCommon IE and the single RACH-ConfigGeneric IE as appropriate for each PRACH configuration. For example, the single RACH-ConfigCommon IE includes at least respective versions of the relevant RACH-ConfigCommon IEs (for each PRACH configuration) in addition to the single RACH-ConfigGeneric IE. The single RACH-ConfigGeneric IE included in the single RACH-ConfigCommon IE includes at least respective versions of the relevant RACH-ConfigGeneric IEs (e.g. respective prach-ConfigurationIndex IEs for each PRACH configuration) for defining each PRACH configuration.

[0151] Variations and Alternatives Detailed exemplary embodiments have been described above. As those skilled in the art will appreciate, multiple variations and alterations can be made to the above exemplary embodiments while still benefiting from the present disclosure embodied therein.

[0152] It will be understood that the descriptions of the features of and actions performed by base stations (or gNBs), NTN nodes, and UEs, with respect to base stations communicating via a non-terrestrial plane, may be equally applicable to base stations and UEs communicating solely in the terrestrial plane (i.e., as part of a terrestrial RAN without NTN RAN features such as gateways and space or airborne platforms).

[0153] Furthermore, the descriptions of the characteristics of a base station (or a gNB) and the actions performed by a base station (or a gNB) apply equally to distributed and non-distributed base stations.

[0154] Providing multiple PRACH configurations is also applicable for massive Machine-Type-Communication (mMTC) scenarios that specifically require a RACH (e.g., sensors with high UE density in large cells (both terrestrial and non-terrestrial) that require a RACH for small UL transmissions from IDLE / INACTIVE).

[0155] Also, although information elements having particular names have been described, it will be appreciated that information elements with different names but having a similar purpose may be used.

[0156] [Table 5]

[0157] It will be appreciated that there are various architecture options for implementing NTN in 5G / NR systems, some of which are shown diagrammatically in FIG. 12. The first option shown is an NTN based on satellite / aerial and terrestrial gNBs (satellite hub or gateway level) featuring an access network serving UEs with bent-pipe payloads. The second option is an NTN based on satellite / aerial featuring an access network serving UEs with gNBs. The third option is an NTN based on satellite / aerial featuring an access network serving relay nodes with bent-pipe payloads. The fourth option is an NTN based on satellite / aerial featuring an access network serving relay nodes with gNBs. It will be appreciated that other architecture options may also be used, for example a combination of two or more of the above-mentioned options. Alternatively, the relay nodes may include satellite / UAS. It will be appreciated that a similar architecture option may also be used in 4G / E-UTRA systems, but with eNBs instead of gNBs and EPCs instead of NGCs.

[0158] In the above description, the UE, NTN nodes (satellite / UAS platforms), and access network nodes (base stations) are described for ease of understanding as having multiple separate functional components or modules. These modules may be provided in this manner for certain applications, for example, where an existing system is being modified to implement the present disclosure, but in other applications, for example, in systems designed from the beginning with the features of the present invention in mind, these modules may be built into the overall operating system or code and therefore may not be identifiable as discrete entities.

[0159] In the above exemplary embodiment, a number of software modules have been described. As will be appreciated by those skilled in the art, the software modules may be provided in compiled or uncompiled form and may be provided to the UE, NTN node (satellite / UAS platform), or access network node (base station) as a signal over a computer network or on a recording medium. Furthermore, the functions performed by some or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the UE, NTN node (satellite / UAS platform), or access network node (base station) to update their functions.

[0160] Each controller may comprise any suitable form of processing circuitry including, for example, but not limited to, one or more hardware-implemented computer processors, microprocessors, Central Processing Units (CPUs), Arithmetic Logic Units (ALUs), Input / Output (IO) circuitry, internal memory / cache (program and / or data), processing registers, communication buses (e.g., control, data, and / or address buses), Direct Memory Access (DMA) facilities, hardware or software implemented counters, pointers, and / or timers, etc. Various other variations will be apparent to those skilled in the art and will not be described in further detail herein.

[0161] User equipment (or "UE", "mobile station", "mobile device", or "wireless device") in this disclosure is an entity connected to a network via a wireless interface.

[0162] It should be noted that the present disclosure is not limited to dedicated communication devices, but may be applied to any device having communication capabilities, as described in the following paragraphs.

[0163] The terms "user equipment" or "UE" (as this term is used by 3GPP), "mobile station," "mobile device," and "wireless device" are generally intended to be synonymous with each other and include standalone mobile stations such as terminals, cell phones, smartphones, tablets, cellular IoT devices, IoT devices, and machines. It will be understood that the terms "mobile station" and "mobile device" also encompass devices that remain stationary for long periods of time.

[0164] The UE may be, for example, an item of equipment for production or manufacturing and / or an item of energy related machinery (e.g., equipment or machinery such as boilers, engines, turbines, solar panels, wind turbines, hydroelectric generators, thermal generators, nuclear generators, batteries, nuclear systems and / or related equipment, heavy electrical machinery, pumps including vacuum pumps, compressors, fans, blowers, hydraulic equipment, pneumatic equipment, metal processing machinery, manipulators, robots and / or application systems thereof, tools, moulds or dies, rolls, conveying equipment, lifting equipment, material handling equipment, textile machinery, sewing machines, printing and / or related machinery, paper processing machinery, chemical machinery, mining and / or construction machinery and / or related equipment, machinery and / or implements for agriculture, forestry and / or fishing, safety and / or environmental protection equipment, tractors, precision bearings, chains, gears, power transmission equipment, lubrication equipment, valves, fittings, and / or application systems for any of the aforementioned equipment or machines).

[0165] A UE may be, for example, an item of transportation equipment (e.g., rail cars, automobiles, motorcycles, bicycles, trains, buses, carts, skating shoals, ships and other watercraft, aircraft, rockets, satellites, drones, balloons, and other such transportation equipment).

[0166] A UE may be, for example, an item of information and communications equipment (eg, information and communications equipment such as electronic computers and related equipment, communications and related equipment, electronic components, etc.).

[0167] The UE may be, for example, a refrigerator, a refrigerator application product, an item of trade and / or service industry equipment, a vending machine, an automated service machine, an office machine or equipment, a home appliance or electronic device (e.g., home appliances such as audio equipment, video equipment, loudspeakers, radios, televisions, microwave ovens, rice cookers, coffee machines, dishwashers, washing machines, dryers, electronic fans or related equipment, vacuum cleaners, etc.).

[0168] The UE may be, for example, an electrical application system or device (eg, an electrical application system or device such as an x-ray system, a particle accelerator, a radioisotope device, a sonic device, an electromagnetic application device, a power application device, etc.).

[0169] The UE may be, for example, an electronic lamp, a lighting fixture, a measuring instrument, an analyzer, a tester, or a surveying or detecting instrument (e.g., a smoke alarm, a human alarm sensor, a motion sensor, a wireless tag, or other surveying or detecting instrument), a watch or clock, laboratory equipment, optical equipment, medical equipment and / or systems, weapons, cutlery, hand tools, etc.

[0170] A UE may be, for example, a wireless-equipped personal digital assistant or associated equipment, such as a wireless card or module designed for attachment or insertion into another electronic device (eg, a personal computer, an electrical measuring instrument).

[0171] The UE may be a device or part of a system that uses various wired and / or wireless communication technologies to provide the applications, services, and solutions described below in relation to the "internet of things (IoT)."

[0172] Internet of Things devices (or "Things") may comprise appropriate electronics, software, sensors, network connectivity, etc. that enable these devices to collect and exchange data with each other and with other communicating devices. IoT devices may comprise automated equipment that follows software instructions stored in internal memory. IoT devices may operate without the need for human supervision or interaction. IoT devices may also remain stationary and / or inactive for long periods of time. IoT devices may be implemented as part of a (generally) stationary device. IoT devices may also be embedded in non-stationary equipment (e.g., vehicles) or attached to animals or people being monitored / tracked.

[0173] It will be appreciated that IoT technologies may be implemented on any communication device capable of connecting to a communication network to transmit / receive data, regardless of whether such communication device is controlled by human input or software instructions stored in memory.

[0174] It will be appreciated that IoT devices may also be referred to as machine type communication (MTC) devices or machine-to-machine (M2M) communication devices. It will be appreciated that a UE may support one or more IoT or MTC applications. Some examples of MTC applications are listed in the table below. This list is not exhaustive and is intended to illustrate some examples of machine type communication applications.

[0175] [Table 6]

[0176] Furthermore, the above-mentioned UE categories are merely examples of applications of the technical concepts and exemplary embodiments described herein. Of course, these technical concepts and embodiments are not limited to the above-mentioned UEs, and various modifications are possible.

[0177] Each feature disclosed in this specification (which term includes the claims) and / or shown in the drawings may be incorporated in the present disclosure independently (or in combination with) any other disclosed and / or shown feature, if it is technically feasible to do so. In particular, but not by way of limitation, any feature of a claim that is dependent on a particular independent claim may be introduced into that independent claim in any combination or individually, unless doing so would cause technical incompatibility or result in something that makes no technical sense.

[0178] Each PRACH preamble format may be associated with a respective UE uplink transmit power and / or UE power class.

[0179] The random access configuration information may indicate an association between one or more of the respective resources in the time domain within a period of time and a plurality of PRACH preamble formats, at least two of which may be associated with the same frequency.

[0180] The random access configuration information may identify, for each PRACH preamble format, a respective preamble reception target power.

[0181] The preamble receive target power may be identified by at least one of an offset or a power value.

[0182] The method performed by the UE may further include sending signaling to an access network node to initiate a random access procedure, the signaling including a random access preamble having one of a plurality of PRACH formats, and communicating with the access network node to complete the random access procedure.

[0183] The method performed by the UE may further include selecting one of the multiple PRACH formats based on at least one of a power class associated with the UE or a maximum transmit power supported by the UE.

[0184] The method performed by the UE may further include selecting one of the multiple PRACH formats based on a physical downlink control channel (PDCCH) order.

[0185] The random access configuration information may identify at least one entry of a PRACH configuration table for the cell, each of the at least one entry of the PRACH configuration table being associated with a different one of a plurality of PRACH preamble formats.

[0186] The random access configuration information may identify at least one common parameter for the at least one entry.

[0187] For example, the random access configuration information may include, for at least one entry: - the number of frequency domain PRACH resources for performing frequency multiplexing of the associated frequency offsets and PRACH preamble formats, - the associated preamble receive target power, - associated power ramping steps, - the maximum number of associated random access attempts, - the associated value of the zeroCorrelationZoneConfig information element, and - the associated value of the restrictedSetConfig information element One or more of the following may be identified:

[0188] The random access configuration information may be transmitted using a respective prach-ConfigurationIndex information element for each of the multiple PRACH preamble formats. The random access configuration information may be transmitted using a respective rach-ConfigGeneric information element for each of the multiple PRACH preamble formats.

[0189] The method performed by the UE may further include: applying a specific PRACH preamble format in a subsequent random access preamble during the random access procedure based on the random access configuration information; - the particular PRACH preamble format is the same as the RACH preamble format used in a previous random access attempt, or a particular PRACH preamble format differs from the RACH preamble format used in the previous random access attempt and uses the same power ramping counter as used in the previous random access attempt, or - a particular PRACH preamble format differs from the RACH preamble format used in a previous random access attempt and an associated power ramping counter is incremented, or - the particular PRACH preamble format is different from the RACH preamble format used in the previous random access attempt, and the particular PRACH preamble format is transmitted with a lower transmission power than the RACH preamble format used in the previous random access attempt, or - The particular PRACH preamble format is different from the RACH preamble format used in the previous random access attempt, and the particular PRACH preamble format has a higher repetition count or a longer PRACH sequence than the RACH preamble format used in the previous random access attempt.

[0190] The random access configuration information may be transmitted using a different respective rach-ConfigCommon information element for each of multiple PRACH preamble formats.

[0191] The method performed by the UE may further include: applying a specific PRACH preamble format in a subsequent random access preamble during the random access procedure based on the random access configuration information; - the particular PRACH preamble format is the same as the RACH preamble format used in a previous random access attempt, or - If a particular PRACH preamble format differs from the RACH preamble format used in the previous random access attempt, the associated power ramping counter is incremented.

[0192] The random access configuration information may identify a plurality of entries in the PRACH configuration table for a plurality of uplink cells or uplink configurations, respectively. The random access configuration information may identify at least one of an associated power class or an associated maximum transmit power level for at least one of the plurality of uplink cells or uplink configurations.

[0193] Multiple uplink cells or uplink configurations may be configured with a common synchronization signal block transmission. Multiple uplink cells or uplink configurations may have remaining minimum system information in common.

[0194] The random access configuration information may be applicable to at least one non-terrestrial cell.

[0195] At least one of the multiple PRACH preamble formats may be associated with a power class value of the UE or a maximum transmit power supported by the UE. At least one of the multiple PRACH preamble formats may be associated with a standard release supported by the UE.

[0196] Each resource may include at least one of a resource block or subcarrier in the frequency domain, a subframe, a slot, or a symbol.

[0197] The random access procedure may be a two-step random access procedure, and the method may further include obtaining, by the UE, from the access network node, information identifying, for each RACH preamble format, a respective physical uplink shared channel (PUSCH) configuration for a first message (MsgA) of the two-step random access procedure, where each respective PUSCH configuration may identify at least one of a number of PUSCH repetitions, a modulation and coding scheme for PUSCH transmission, or a frequency and time allocation of PUSCH opportunities.

[0198] A PUSCH configuration may be applicable to one or more specific PRACH formats. At least one RACH preamble format or resource may be associated with a coverage extension.

[0199] The method performed by the UE may further include sending signaling to the access network node for initiating the random access procedure using at least one RACH preamble format or resource associated with the coverage extension, and obtaining information identifying a PUSCH resource with coverage extension for transmitting a third message (Msg3) of the four-step random access procedure.

[0200] The method performed by the UE may further include receiving information identifying a number of repetitions associated with the PUSCH resource with coverage extension via the system information or via downlink control information (DCI) for the PUSCH.

[0201] Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0202] Although the present invention has been described above with reference to the embodiment, the present invention is not limited to the above. Various modifications that can be understood by those skilled in the art can be made to the configuration and details of the present invention within the scope of the present invention.

[0203] The program can be stored and provided to a computing device using various types of non-transitory computer readable media. The non-transitory computer readable media includes any type of tangible storage medium. Examples of the non-transitory computer readable media include magnetic recording media (e.g., flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (e.g., magneto-optical disks), CD-ROM (Read Only Memory), CD-R, CD-R / W, and semiconductor memory (e.g., mask ROM, PROM (Programmable ROM), EPROM (Erasable PROM), flash ROM, RAM (Random Access Memory)). The program may be provided to a computing device by various types of temporary computer readable media. Examples of the temporary computer readable media include electric signals, optical signals, and electromagnetic waves. The temporary computer readable media can provide the program to a computing device via a wired communication path such as electric wires and optical fibers, or via a wireless communication path.

[0204] This application claims priority to UK Patent Application No. 2206366.3, filed April 29, 2022, the disclosure of which is incorporated herein in its entirety.

[0205] For example, some or all of the above embodiments may be described as, but are not limited to, the following supplementary notes. (Appendix 1) 1. A method performed by a User Equipment (UE), comprising: receiving, from an access network node, random access configuration information for configuring the UE to perform a random access procedure, the random access configuration information identifying a plurality of Physical Random Access Channel (PRACH) preamble formats for the UE in the random access procedure; Including, Each PRACH preamble format is associated with a respective resource within which the random access configuration information is applicable; method. (Appendix 2) Each PRACH preamble format is associated with a respective UE uplink transmit power. The method described in Appendix 1. (Appendix 3) The random access configuration information indicates an association of one or more of each resource in the time domain within a period with a plurality of PRACH preamble formats; 3. The method according to claim 1 or 2. (Appendix 4) At least two of the multiple PRACH preamble formats are associated with the same frequency; 4. The method according to any one of claims 1 to 3. (Appendix 5) The random access configuration information identifies, for each PRACH preamble format, a respective preamble reception target power; 5. The method according to any one of claims 1 to 4. (Appendix 6) The preamble reception target power is identified by at least one of an offset and a power value. The method described in Appendix 5. (Appendix 7) transmitting signaling to an access network node to initiate a random access procedure, the signaling including a random access preamble having one of a plurality of PRACH formats; communicating with an access network node to complete a random access procedure; Further comprising: 7. The method according to any one of claims 1 to 6. (Appendix 8) selecting one of the plurality of PRACH formats based on at least one of a power class associated with the UE or a maximum transmit power supported by the UE. The method described in Appendix 7. (Appendix 9) and selecting one of the plurality of PRACH formats based on a Physical Downlink Control Channel (PDCCH) order. The method described in Appendix 8. (Appendix 10) the random access configuration information identifies, for the cell, at least one entry in a PRACH configuration table, each of the at least one entry in the PRACH configuration table being associated with a different one of a plurality of PRACH preamble formats; 10. The method according to any one of claims 1 to 9. (Appendix 11) the random access configuration information identifying at least one common parameter for the at least one entry; 11. The method according to claim 10. (Appendix 12) The random access configuration information includes, for at least one entry, - the number of frequency domain PRACH resources for performing frequency multiplexing of the associated frequency offsets and PRACH preamble formats, - the associated preamble receive target power, - associated power ramping steps, - the maximum number of associated random access attempts, and - the associated value of the zeroCorrelationZoneConfig information element, and - the associated value of the restrictedSetConfig information element Identifying one or more of: 12. The method according to claim 10 or 11. (Appendix 13) the random access configuration information is transmitted using a respective prach-ConfigurationIndex information element for each of a plurality of PRACH preamble formats; 13. The method according to any one of claims 1 to 12. (Appendix 14) the random access configuration information is transmitted using a respective rach-ConfigGeneric information element for each of a plurality of PRACH preamble formats; 14. The method according to any one of claims 1 to 13. (Appendix 15) Applying a specific PRACH preamble format in a subsequent random access preamble during a random access procedure based on the random access configuration information Further comprising: - the particular PRACH preamble format is the same as the RACH preamble format used in a previous random access attempt, or a particular PRACH preamble format differs from the RACH preamble format used in the previous random access attempt and uses the same power ramping counter as used in the previous random access attempt, or - a particular PRACH preamble format differs from the RACH preamble format used in a previous random access attempt and an associated power ramping counter is incremented, or - the particular PRACH preamble format is different from the RACH preamble format used in the previous random access attempt, and the particular PRACH preamble format is transmitted with a lower transmission power than the RACH preamble format used in the previous random access attempt, or - the particular PRACH preamble format is different from the RACH preamble format used in the previous random access attempt, and the particular PRACH preamble format has a greater number of repetitions or a longer PRACH sequence than the RACH preamble format used in the previous random access attempt; 15. The method of any one of claims 1 to 14. (Appendix 16) the random access configuration information is transmitted using a different respective rach-ConfigCommon information element for each of a plurality of PRACH preamble formats; 10. The method according to any one of claims 1 to 9. (Appendix 17) Applying a specific PRACH preamble format in a subsequent random access preamble during a random access procedure based on the random access configuration information Further comprising: - the particular PRACH preamble format is the same as the RACH preamble format used in a previous random access attempt, or - a particular PRACH preamble format is different from the RACH preamble format used in the previous random access attempt and an associated power ramping counter is incremented; 17. The method according to claim 16. (Appendix 18) The random access configuration information identifies a plurality of entries in the PRACH configuration table for a plurality of uplink cells or uplink configurations, respectively. 18. The method of any one of claims 1 to 9, 16, and 17. (Appendix 19) The random access configuration information includes, for at least one of a plurality of uplink cells or uplink configurations: - the associated power class, or - the associated maximum transmit power level Identifying at least one of 19. The method according to claim 18. (Appendix 20) A plurality of uplink cells or uplink configurations are configured with a common synchronization signal block transmission. 20. The method according to claim 18 or 19. (Appendix 21) The multiple uplink cells or uplink configurations have common remaining minimum system information. 21. The method of any one of claims 18 to 20. (Appendix 22) The random access configuration information is applicable to at least one non-terrestrial cell, 22. The method of any one of claims 1 to 21. (Appendix 23) At least one of the plurality of PRACH preamble formats is associated with a power class value of the UE or a maximum transmission power supported by the UE; 23. The method of any one of claims 1 to 22. (Appendix 24) At least one of the plurality of PRACH preamble formats is associated with a standard release supported by the UE; 24. The method of any one of claims 1 to 23. (Appendix 25) Each resource is - resource blocks or subcarriers in the frequency domain, - Subframe, - Slots, or - Symbol At least one of 25. The method of any one of claims 1 to 24. (Appendix 26) The random access procedure is a two-step random access procedure, The method further includes obtaining, for each RACH preamble format, information identifying a respective Physical Uplink Shared Channel (PUSCH) configuration for a first message (MsgA) of the two-step random access procedure. 26. The method of any one of claims 1 to 25. (Appendix 27) The respective PUSCH configurations are - the number of PUSCH repetitions, - a modulation and coding scheme for PUSCH transmission, or - Frequency and time allocation of PUSCH opportunities Identifying at least one of 27. The method according to claim 26. (Appendix 28) A PUSCH configuration is applicable to one or more specific PRACH formats; 28. The method according to claim 26 or 27. (Appendix 29) At least one RACH preamble format or resource is associated with coverage extension; 26. The method of any one of claims 1 to 25. (Appendix 30) transmitting signaling to an access network node for initiating a random access procedure using at least one RACH preamble format or resource associated with coverage extension; obtaining information identifying a PUSCH resource with coverage extension for transmitting a third message (Msg3) of a four-step random access procedure; Further comprising: 29. The method according to claim 29. (Appendix 31) receiving information identifying a number of repetitions associated with a PUSCH resource with coverage extension via system information or via Downlink Control Information (DCI) for the PUSCH; 31. The method according to claim 30. (Appendix 32) 1. A method performed by an access network node, comprising: transmitting random access configuration information to a User Equipment (UE) for configuring the UE to perform a random access procedure, the random access configuration information including identifying a plurality of Physical Random Access Channel (PRACH) preamble formats for the UE in the random access procedure; Each PRACH preamble format is associated with a respective resource within which the random access configuration information is applicable; method. (Appendix 33) A user equipment (UE), Means for receiving random access configuration information from an access network node for configuring a UE to perform a random access procedure, the random access configuration information identifying a plurality of Physical Random Access Channel (PRACH) preamble formats for the UE in the random access procedure. Equipped with Each PRACH preamble format is associated with a respective resource within which the random access configuration information is applicable; U.E. (Appendix 34) An access network node, means for transmitting random access configuration information to a User Equipment (UE) for configuring the UE to perform a random access procedure, the random access configuration information identifying a plurality of Physical Random Access Channel (PRACH) preamble formats for the UE in the random access procedure; Each PRACH preamble format is associated with a respective resource within which the random access configuration information is applicable; Access network node. [Explanation of symbols]

[0206] 1. Telecommunications Systems 3 Mobile Devices (User Equipment, UE) 4. Non-Ground Platforms 5 base station 7 Data Network 9. Gateway

Claims

1. 1. A method performed by a User Equipment (UE), comprising: receiving random access configuration information from an access network node, the random access configuration information identifying a plurality of Physical Random Access Channel (PRACH) preamble formats to be used by the UE in a random access procedure; Each of the plurality of PRACH preamble formats is associated with a respective resource within a period for which the random access configuration information is applicable; Each of the plurality of PRACH preamble formats is associated with a respective number of repetitions. method.

2. Each of the plurality of PRACH preamble formats is associated with a respective UE uplink transmit power. The method of claim 1.

3. selecting one of the plurality of PRACH preamble formats for use by the random access procedure based on a UE uplink transmit power associated with the one of the plurality of PRACH preamble formats. The method according to claim 1 or 2.

4. The random access configuration information identifies, for each of the plurality of PRACH preamble formats, a respective preamble reception target power.

4. The method according to any one of claims 1 to 3.

5. the preamble reception target power is identified by at least one of an offset or a power value; The method according to claim 4.

6. selecting the one of the plurality of PRACH formats is performed based on at least one of a power class associated with the UE or a maximum transmit power supported by the UE. The method according to claim 3.

7. transmitting information indicating at least one of the power class associated with the UE or the maximum transmit power supported by the UE; the random access configuration information is based on at least one of the power class associated with the UE or the maximum transmit power supported by the UE. The method according to claim 6.

8. and transmitting information indicating that the UE is unable to connect to an in-coverage cell due to low PRACH power; The random access configuration information is based on the information indicating that the UE cannot connect to the cell in coverage due to low PRACH power. The method of claim 7.

9. The random access configuration information identifies the plurality of PRACH preamble formats for at least one of the power class or the maximum transmit power.

9. The method according to any one of claims 6 to 8.

10. the random access configuration information indicating an association between at least one respective resource in a time domain within the period and each of the plurality of PRACH preamble formats.

10. The method according to any one of claims 1 to 9.

11. At least two of the plurality of PRACH preamble formats are associated with the same frequency.

11. The method according to any one of claims 1 to 10.

12. The random access configuration information includes a respective prach-ConfigurationIndex information element for each of the plurality of PRACH preamble formats.

12. The method according to any one of claims 1 to 11.

13. For each of the plurality of PRACH preamble formats, mapping a synchronization signal and a block to a respective PRACH configuration index indicated by the prach-ConfigurationIndex information element. The method of claim 12.

14. and indicating, via a Physical Downlink Control Channel (PDCCH) command, one of the plurality of PRACH formats for the UE to use in a random access procedure.

14. The method according to claim 12 or 13.

15. The random access configuration information includes, for each of the plurality of PRACH preamble formats, a respective rach-ConfigGeneric information element or a respective rach-ConfigCommon information element; 12. The method according to any one of claims 1 to 11.

16. the random access configuration information includes a single index that identifies an entry in a PRACH configuration table; the entries in the PRACH configuration table identify a respective time opportunity for each of the plurality of PRACH preamble formats.

12. The method according to any one of claims 1 to 11.

17. the random access configuration information indicating an association between at least one respective resource in a frequency domain and each of the plurality of PRACH preamble formats.

16. The method according to any one of claims 1 to 15.

18. At least two of the plurality of PRACH preamble formats overlap in the time domain.

20. The method of claim 17.

19. the random access configuration information identifying at least one entry in a PRACH configuration table for a cell; each of the at least one entry of the PRACH configuration table is associated with a different one of the plurality of PRACH preamble formats; 18. The method according to claim 16 or 17.

20. the random access configuration information identifying at least one common parameter for the at least one entry.

20. The method of claim 17.

21. The random access configuration information, for the at least one entry, - the number of frequency domain PRACH resources for performing frequency multiplexing of the associated frequency offset and the PRACH preamble format; - associated preamble receive target power, - associated power ramping steps; - the maximum number of associated random access attempts, the associated value of the zeroCorrelationZoneConfig information element, and - the associated value of the restrictedSetConfig information element Identifying one or more of:

21. The method of claim 19 or 20.

22. applying a specific PRACH preamble format in a subsequent random access attempt in the random access procedure based on the random access configuration information; - the particular PRACH preamble format is the same as the PRACH preamble format used in a previous random access attempt, or the particular PRACH preamble format is different from the PRACH preamble format used in a previous random access attempt and the same power ramping counter is used as was used in the previous random access attempt, or - the particular PRACH preamble format is different from the PRACH preamble format used in the previous random access attempt and an associated power ramping counter is increased, or the particular PRACH preamble format is different from the PRACH preamble format used in a previous random access attempt, and the particular PRACH preamble format is transmitted with a lower transmission power than the PRACH preamble format used in the previous random access attempt, or the specific PRACH preamble format is different from a PRACH preamble format used in a previous random access attempt, and the specific PRACH preamble format has a greater number of repetitions or a longer PRACH sequence than the PRACH preamble format used in the previous random access attempt; 22. The method of any one of claims 1 to 21.

23. and receiving, for each of the plurality of PRACH preamble formats, information identifying a respective Physical Uplink Shared Channel (PUSCH) configuration for the random access procedure.

23. A method according to any one of claims 1 to 22.

24. Each of the respective PUSCH configurations comprises: - number of PUSCH repetitions, - a modulation and coding scheme for PUSCH transmission, or - Frequency and time allocation of PUSCH opportunities Identifying at least one of 24. The method of claim 23.

25. The PUSCH configuration is applicable to at least one specific PRACH preamble format.

25. The method of claim 23 or 24.

26. the random access procedure is a two-step random access procedure, The respective Physical Uplink Shared Channel (PUSCH) configuration is for a first message (MsgA) of the two-step random access procedure.

26. A method according to any one of claims 23 to 25.

27. The random access configuration information identifies at least one PRACH preamble format or resource; The at least one PRACH preamble format or resource is associated with a coverage extension.

26. The method of any one of claims 1 to 25.

28. the random access procedure is a four-step random access procedure, The method comprises: transmitting signaling to the access network node to initiate a random access procedure using one of the at least one PRACH preamble format or resources associated with a coverage extension; receiving information identifying a PUSCH resource with coverage extension for transmitting a third message (Msg3) of the four-step random access procedure; Further comprising:

28. The method of claim 27.

29. receiving information identifying a number of repetitions associated with the PUSCH resource with coverage extension via system information or via Downlink Control Information (DCI) for the PUSCH; 29. The method of claim 28.

30. The at least one entry in the PRACH configuration table is configured for each of a plurality of uplink cells or uplink configurations; each of the plurality of uplink cells or uplink configurations is configured with a common synchronization signal block transmission; 20. The method of claim 19.

31. The at least one entry in the PRACH configuration table is configured for each of a plurality of uplink cells or uplink configurations; Each of the plurality of uplink cells or uplink configurations is configured to use a common remaining minimum system information.

20. The method of claim 19.

32. The random access configuration information, for at least one of the plurality of uplink cells or uplink configurations, - the associated power class, or – associated maximum transmit power level Identifying at least one of 32. The method of any one of claims 1 to 31.

33. the random access configuration information is applicable to at least one non-terrestrial cell.

33. A method according to any one of claims 1 to 32.

34. At least one of the plurality of PRACH preamble formats is associated with a standard release supported by the UE.

34. A method according to any one of claims 1 to 33.

35. Each of the resources is: – resource blocks or subcarriers in the frequency domain, - subframe, - Slots, or - Symbol At least one of:

35. The method of any one of claims 1 to 34.

36. 1. A method performed by an access network node, comprising: transmitting random access configuration information to a User Equipment (UE), the random access configuration information identifying a plurality of Physical Random Access Channel (PRACH) preamble formats to be used by the UE in a random access procedure; Each of the plurality of PRACH preamble formats is associated with a respective resource within a period for which the random access configuration information is applicable; Each of the plurality of PRACH preamble formats is associated with a respective number of repetitions. method.

37. A User Equipment (UE), means for receiving random access configuration information from an access network node identifying a plurality of Physical Random Access Channel (PRACH) preamble formats for use by the UE in a random access procedure; Each of the plurality of PRACH preamble formats is associated with a respective resource within which the random access configuration information is applicable; Each of the plurality of PRACH preamble formats is associated with a respective number of repetitions. U.E.

38. An access network node, means for transmitting random access configuration information to a User Equipment (UE), the random access configuration information identifying a plurality of Physical Random Access Channel (PRACH) preamble formats to be used by the UE in a random access procedure; Each of the plurality of PRACH preamble formats is associated with a respective resource within a period for which the random access configuration information is applicable; Each of the plurality of PRACH preamble formats is associated with a respective number of repetitions. Access network node.

Images