Method performed by user equipment, method performed by network node, user equipment and network node

Abstract

A communication system is disclosed in which one or more methods are performed for the adaptation of common signal / channel transmissions in the context of network energy saving (NES) including, for example, the configuration, adaptation, and / or activation of additional resources for (physical) random-access channel ((P)RACH) procedures.

Description

METHOD PERFORMED BY USER EQUIPMENT, METHOD PERFORMED BY NETWORK NODE, USER EQUIPMENT AND NETWORK NODE

[0001] The present disclosure relates to a communication system and to parts thereof.

[0002] The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof (including Long-Term Evolution (LTE)-Advanced, Next Generation or 5G networks, future generations, and beyond). The disclosure has particular, although not necessarily exclusive relevance to, the adaptation of common signal / channel transmissions in the context of network energy saving (NES) including, for example, the configuration, adaptation and / or activation of additional resources for (physical) random-access channel ((P)RACH) procedures.

[0003] Earlier developments of the 3GPP standards were referred to as the LTE of Evolved Packet Core (EPC) network and Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), also commonly referred as '4G'. More recently, the term '5G' and 'new radio' (NR) is used to refer to an evolving communication technology that supports a variety of applications and services. Various details of 5G networks are described in, for example, the 'NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, which document is available from https: / / www.ngmn.org / 5g-white-paper.html. 3GPP intends to support 5G by way of the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and the 3GPP NextGen core network.

[0004] Under the 3GPP standards, a NodeB (or an eNB in LTE, and gNB in 5G) is the radio access network (RAN) node (or simply 'access node', 'access network node' or 'base station') via which communication devices (user equipments or 'UEs') connect to a core network and communicate with other communication devices or remote servers. For simplicity, the present application may use the term access network node, RAN node (or simply RAN) or base station to refer to any such access nodes.

[0005] For simplicity, the present application will use the term mobile device, user device, or UE, to refer to any communication device that is able to connect to the core network via one or more base stations. Although the present application may refer to mobile devices in the description, it will be appreciated that the technology described can be implemented on any communication devices (mobile and / or generally stationary) that can connect to a communication system for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

[0006] In the current 5G architecture, the RAN architecture may be distributed with the base station structure split into two or more parts. In some RAN implementations there are two parts, known as the Central Unit (CU or gNB-CU) - sometimes referred to as a 'control unit' - and the Distributed Unit (DU or gNB-DU), connected by an F1 interface. This enables the use of a 'split' architecture in which the typically 'higher' CU layers (for example, but not necessarily or exclusively, Packet Data Convergence Protocol (PDCP) and Radio Resource Control (RRC) layers) and the, 'lower' DU layers (for example, but not necessarily or exclusively, Radio Link Control (RLC), Media (sometimes referred to as 'Medium') Access Control (MAC), and Physical (PHY) layers) are separated between a particular CU, and one or more DUs that are connected to and controlled by that CU via the F1 interface. Thus, for example, the higher layer CU functionality for a number of base stations may be implemented centrally (for example, by a single processing unit, or in a cloud-based or virtualised system), whilst retaining the lower layer DU functionality locally separately for each base station.

[0007] In more recently proposed RAN distributed architectures, in addition to the CU and DU, the concept of a Radio Unit (RU) - sometimes referred to as a 'remote unit' - has been introduced. In this architecture the RU is responsible for handling the digital front end (DFE), digital beamforming functionality and, typically, the functionality of the lower parts of the PHY layer, whilst the DU typically handles the higher parts of the PHY layer and the RLC and MAC layers. The CU in this architecture continues to be responsible for controlling one or more DUs (each DU corresponding to a different respective gNB) and to handle higher layer signalling (typically RRC and PDCP layers).

[0008] The actual functional split between the CU and DUs (and potentially RUs where applicable) of these distributed architectures is flexible allowing the functionality to be optimised for different use cases. Effectively, the split architecture enables a 5G network to use a different distribution of protocol stacks between CU and DUs (and potentially RUs) depending on, for example, midhaul availability and network design.

[0009] The choice of how to split functions in the architecture depends on, among other things, factors related to radio network deployment scenarios, constraints and intended supported use cases. Key considerations include: the need to support a specific quality of service for each service offered and for real / non-real time applications; support of specific user density and load demand in a given geographical area; and available transport networks with different performance levels.

[0010] In 5G, core network entities comprise logical nodes (or 'functions') including control plane functions (CPFs) and one or more user plane functions (UPFs). The CPFs include, amongst other things, one or more Access and Mobility Management Functions (AMFs), a session management function (SMF), an Authentication Server Function (AUSF), a Unified Data Management (UDM) entity for managing user specific data, a Policy Control Function (PCF), an Application Function (AF), a Security Anchor Function (SEAF), an Authentication credential Repository and Processing Function (ARPF), and / or the like. The AMF generally corresponds to the mobility management entity (MME) in 4G and performs many of the functions performed by the MME. Each UPF combines functionality of both the S-GW and P-GW - specifically user plane functionality of the S-GW (SGW-U) and user plane functionality of the P-GW (PGW-U). The SMF provides session management functionality (that formed part of MME functionality in 4G). The SMF also combines the some of the functionality provided by the S-GW and P-GW - specifically control plane functionality of the S-GW (SGW-C) and control plane functionality of the P-GW (PGW-C). The SMF also allocates IP addresses to each UE.

[0011] With the increasing usage of mobile communication for a wide range of different use cases, additional frequencies and bands are needed to accommodate this increasing demand. Accordingly, a variety of different frequency bands are available for 5G NR. These frequency bands include many of the existing frequency bands used by previous generations of telecommunication technology and many new frequency bands including bands in the millimetre wave region. The bandwidth available for frequency bands in the millimetre wave region is very much higher than for frequency bands used by earlier generations and thus allow for greater data speeds to be achieved albeit at the expense of the range of the signals.

[0012] The available frequency bands are grouped into two different frequency ranges referred to as frequency range 1 (FR1) containing the lower frequency bands and frequency range 2 (FR2) containing the higher frequency bands. FR1 bands are likely to carry much of the traditional cellular mobile communication traffic whereas the FR2 bands are aimed at providing short range very high data rate capability for 5G radio. Originally the FR1 band was intended to define bands below 6 GHz, but with anticipated additional spectrum allocations, the FR1 range has now been extended to 7.125 GHz.

[0013] Historically, communication systems have employed two core duplex schemes - frequency division duplex (FDD) and time division duplex (TDD). In FDD the frequency domain resource is split between downlink (DL) and uplink (UL) whereas in TDD the time domain resource is split between DL and UL. The appropriate duplex scheme to be used in a given scenario is broadly spectrum dependent, albeit with some overlap. Where lower frequency bands are used for communication, paired spectrum UL and DL resource allocations are generally employed and hence FDD is used. In contrast, for higher frequency bands the use of unpaired spectrum, and hence TDD, is becoming increasingly prevalent. Thus, TDD is widely used in commercial NR deployments.

[0014] The coverage in 5G is primarily beam-based rather than cell based. There is no cell-level reference channel from where the coverage of the cell could be measured. Instead, each cell has one or more so-called synchronisation signal block (SSB) beams. SSB beams form a matrix of beams covering an entire cell area. Each SSB beam carries an SSB comprising a primary synchronisation signal (PSS), secondary synchronisation signal (SSS), and physical broadcast channel (PBCH). SSBs are, therefore, sometimes referred to as an 'SS / PBCH blocks.

[0015] The UE searches for and performs measurements on the SSB beams. The measurements may, for example, be performed on the synchronisation signals carried by the SSB (e.g. of the synchronisation signal reference signal received power, 'SS-RSRP', synchronisation signal reference signal received quality, 'SS-RSRQ', and / or the synchronisation signal to noise or interference ratio, 'SS-SINR').

[0016] The UE maintains a set of candidate beams which may contain beams from multiple cells, and so a physical cell identifier (PCI) and beam ID (or SSB index) may be used to distinguish the SSB beams from one another. Effectively, therefore, the SSB beams are like mini cells which may be within a larger cell. Once a UE has detected and selected an SSB beam (e.g., based on the SSB measurements) it may attempt to access that cell and / or SSB beam using an initial RRC connection setup procedure comprising a random-access procedure.

[0017] Following selection of an initial SSB beam, measurements may also be performed on reference signals transmitted via a selected SSB beam for beam refinement purposes (for example of Channel state information reference signal (CSI-RS)). Specifically, reference signals (e.g., CSI-RSs) may be transmitted in different directions using finer (narrower) beams (which may be called CSI-RS beams) within the angular range of the SSB beam selected during an initial acquisition process.

[0018] The UE may attempt to access a cell via a selected beam using a contention-based random-access (CBRA) procedure that typically involves four distinct steps. Prior to attempting initial access the UE may perform transmission of a selected preamble (or 'signature') to a RAN node over a physical random-access channel (which may be referred to either as a 'PRACH' or a 'RACH' - the term (P)RACH will be used herein) for initiating a random-access procedure (also referred to as a (P)RACH procedure, or simply (P)RACH) for obtaining synchronisation in the uplink (UL). A so-called two-step random-access procedure has also been developed (in addition to the above described four-step random-access procedure). The two-step random-access is mainly intended for supporting (Ultra) Low Latency Communication, 10ms control plane latency, fast handover, efficient channel access in unlicensed spectrum, and transmission of small data packets, amongst other things. However, it may also apply to large cells such as non-terrestrial cells. The main difference is that whilst the four-step random-access procedure requires two round-trip cycles between the UE and the base station, the two-step random-access procedure aims to reduce latency and control-signalling overhead by using a single round trip cycle between the UE and the base station.

[0019] As those skilled in the art will appreciate, while a CBRA procedure is mentioned above, a non-contention based / 'contention free' random-access (CFRA) procedure may also be used in which a dedicated preamble is assigned by the RAN node to the UE.

[0020] Initial access from an idle mode is not the only time a (P)RACH procedure may be initiated by a UE. Typically, for example, a UE may perform a (P)RACH procedure in the context of other events including, for example: -　　for an RRC Connection re-establishment procedure (typically using a CBRA procedure); -　　on DL data arrival, when the UE is an RRC connected mode / state (or in an RRC inactive mode / state) while a small data transfer (SDT) procedure is ongoing, when the UL is not synchronised, e.g., an UL synchronisation status is "non-synchronised" (typically using a CBRA or a CFRA procedure); -　　on UL data arrival, when the UE is an RRC connected mode / state (or in an RRC inactive mode / state) while a small data transfer (SDT) procedure is ongoing, when the UL is not synchronised, e.g., an UL synchronisation status is "non-synchronised" (typically using a CBRA procedure); -　　on UL data arrival, when the UE is an RRC connected mode / state or during an RRC inactive mode / state while a small data transfer (SDT) procedure is ongoing, when there are no physical uplink control channel (PUCCH) resources for a scheduling request (SR) available (typically using a CBRA procedure); -　　on SR failure (typically using a CBRA procedure); -　　on RRC request upon synchronous reconfiguration, e.g. handover (typically using a CBRA or a CFRA procedure); -　　for initiating transition from an RRC inactive to an RRC connected mode / state, e.g., for an RRC connection resume procedure from the RRC inactive mode / state (typically using a CBRA procedure); -　　to establish a time alignment for a secondary timing alignment group (TAG) (typically using a CBRA or a CFRA procedure); -　　to initiate a request for 'other' system information (SI), e.g., on-demand SI (typically using a CBRA or a CFRA procedure); and / or -　　for the purposes of beam failure recovery (typically using a CBRA or CFRA procedure).

[0021] To facilitate the transmission of a (P)RACH preamble one or more time and frequency resource regions are typically specified for transmission of the associated (P)RACH preamble. These time and frequency regions are typically referred to as 'PRACH occasions' or 'RACH occasions (ROs)' (the term '(P)RACH occasion' will be used herein for consistency).

[0022] In earlier communication systems (e.g., LTE), a single RO was preconfigured (by a specific system information block ('SIB') - typically SIB2). However, in more advanced beam based communication systems (e.g., 5G / NR and beyond), where a preamble is sent using a specific beam selected by the UE (based on measurement of the SSBs received and measured in different beams), the RAN node needs to be able to determine which beam the UE has selected. To allow for this there is a mapping between the SSB transmitted via the selected beam, and the RO the UE uses for transmitting the preamble. The RAN node can detect which RO (and preamble) the UE uses and thus determine the SSB based beam selected by the UE based on the RO used (possibly, if necessary, in combination with the selected preamble and / or the (P)RACH slot in which the RO falls).

[0023] The time domain locations of the slots in which the ROs are provided (referred to as (P)RACH slots herein) are determined based on a (P)RACH configuration index (e.g., labelled 'prach-ConfigurationIndex' in at least some communication systems) configurable at the UE (e.g., by system information and / or by RRC signalling provided by the RAN node).

[0024] The mapping between the SSBs (and hence the beams), and the specific ROs (within the (P)RACH slots) to be used by the UE, is defined by a number of parameters that are configurable at the UE (e.g., by system information and / or by RRC signalling provided by the RAN node).

[0025] NPL 1: 'NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN), available from https: / / www.ngmn.org / 5g-white-paper.html.

[0026] As cellular communication systems evolve, there is also an increasing need for wireless communication networks having improved energy efficiency. This need is being driven, for example, by the fact that 5G (and beyond) communication systems are becoming more pervasive across industries and geographical areas, handling more advanced services and applications requiring very high data rates. Moreover, networks are becoming denser, use more antennas, larger bandwidths, and more frequency bands.

[0027] A reduction in the amount of energy needed to operate a communication network beneficially reduces both the operational expenditure or (OPEX), and the environmental impact, of operating the system. Moreover, for battery-powered devices (for example, a UE) reduced power consumption extends the battery life of the device. However, more recent developments of cellular communication systems (for example to implement wide channel bandwidths, to enable operations at significantly higher frequencies than previously, to provide improved capacity, and the like) tend to increase, rather than reduce, power demand and thus present significant challenges when it comes to energy saving.

[0028] In this context, a number of network energy saving (NES) techniques are typically implemented in cellular communication systems, and improvements to those NES techniques and completely new techniques are being developed. The NES techniques being considered include time, frequency, spatial, and power domain adaptation techniques.

[0029] One method of achieving energy savings in a cellular communication system is to reduce the energy requirements associated with communication between a UE and an associated RAN node. The energy consumption arising from such communication includes a dynamic part that is associated with data transmission and reception, and a static part that is associated with operations of the UE, and the RAN node, that are performed even when there is no ongoing data transmission or reception. The static part may include, for example, the power required to operate a UE in a mode in which the UE is able to receive and decode a physical downlink control channel (PDCCH) transmitted by a RAN node.

[0030] Energy saving modes may be configured for one or more devices in the system (e.g., a UE). For example, a UE may be configured to operate in an energy saving mode (which may also be referred to as a sleep mode) in which the UE performs a reduced number of transmissions, or in which the UE is configured not to attempt to transmit and / or to receive signals during a particular time period. Such operation is commonly referred to as DRX / DTX which stands for Discontinuous Reception (DRX) and Discontinuous Transmission (DTX). DRX for a UE includes idle mode DRX and connected mode DRX (C-DRX). In idle mode DRX, the UE periodically wakes up to monitor for paging messages and goes back to a sleep mode if paging message is not intended for it. In C-DRX, the UE powers down most of its circuitry when there are no packets to be received or transmitted. During this time, the UE nevertheless still monitors for a physical downlink control channel (PDCCH) occasionally during a DRX 'active' state, or DRX 'ON' period. The time during which UE does not monitor the PDCCH is often called a DRX 'sleep' or 'inactive' state, or DRX 'OFF' period.

[0031] However, most of the energy consumption (and associated OPEX), comes from the radio access network. In view of this, therefore, there remains an ongoing need to develop techniques for achieving more efficient operation (dynamically and / or semi-statically) at the RAN side, and potentially adaptation of transmissions and / or receptions for NES in time, frequency, spatial, and / or power domains with a finer granularity than is currently possible.

[0032] One NES technique that is being developed to help address this involves discontinuous operation of the cell or cells provided by a RAN node in a similar manner to DTX / DRX at the UE. This is often referred to as 'cell DTX / DRX'. With cell DTX / DRX, the RAN node operating a cell stops transmitting and receiving in that cell during certain periods of time. The UEs that are served by the cell may be provided with information that allows them to determine when the RAN node is in an active or 'ON' state (and is therefore able to communicate with the UE) and when it is in an inactive or 'OFF' state (and is therefore not able to communicate with the UE).

[0033] Earlier NES development has also focused, primarily, on NES enhancements aimed at reducing energy associated with connected mode UEs during a low cell load scenario. These enhancements deliberately avoided any impact on idle or legacy UE operation and focused on reducing energy associated with user specific signals and channels. However, this focus has limited the NES gains that are potentially achievable, especially in the RAN.

[0034] More recently, therefore, a number of procedures have been developed to reduce the amount of energy expenditure associated with idle / inactive mode UEs selecting, camping on, and / or reselecting cells. Much of the energy expenditure associated with these procedures arises from the transmission, reception, and processing of the minimum system information that a RAN node periodically sends to provide a UE with the parameters required for initial access to the cell and acquisition of any other system information.

[0035] Part of the minimum system information is carried by the SSBs which are periodically transmitted in the cells of the communication system. The PBCH in the SSB carries a master information block (MIB) that provides an initial part of the minimum system information. The MIB typically includes, for example, information identifying whether the cell is or is not barred for access, and information allowing subsequent acquisition of the remaining minimum system information (carried by system information block 1 (SIB1)). The minimum system information carried by the MIB and SIB1 effectively provides the UE with the parameters required for initial access to the cell and acquisition of any other system information.

[0036] To help reduce energy expenditure associated with the transmission, reception, and processing of the minimum system information, therefore, techniques / procedures are being developed to avoid unnecessary SSB and / or SIB1 transmission. By way of example, such techniques / procedures may include: -　　The application of 'SSB-less' or 'SIB1-less' operation in certain 'non-anchor' cells, which involves not transmitting SSBs or SIB1s in those cells. Instead, a UE may rely on an SSB or SIB1 transmission in a different 'anchor' cell for acquiring synchronisation and / or minimum system information. -　　The use of on-demand transmission, rather than automatic (periodic) transmission, of SSBs for camping onto certain cells (e.g., secondary cells (SCells) and / or non-serving cells) by UEs configured to connect to, and use, such cells; and -　　The use of on-demand transmission, rather than automatic (periodic) transmission, of system information block 1 (SIB1) for certain cells in which a UE is able to retrieve the system information carried by SIB1 by sending an uplink wake-up signal (WUS) to a corresponding RAN node and can perform synchronisation based on another cell in which SIB1 is transmitted.

[0037] The work to date on network energy savings has led to some agreement in relation to, and associated specification of, a number of techniques - primarily for RRC Connected, user specific signals and channels, and low load scenarios. These techniques include, for example: aspects of SSB-less secondary cell operation for inter-band carrier aggregation for FR1 and co-located cells, enhancement on cell DTX / DRX mechanism including the alignment of cell DTX / DRX and UE DRX in an RRC connected mode; and inter-node information exchange on cell DTX / DRX. The techniques also include, for example, techniques in spatial and power domains to enable: efficient adaptation of spatial elements; efficient adaptation of power offset values between physical downlink shared channel (PDSCH) and CSI-RS; mechanisms to inhibit legacy UEs from camping on cells adopting newer NES techniques; conditional handover (CHO) procedural enhancement; inter-node beam activation; and enhancements on restricting paging in a limited area.

[0038] Moreover, other techniques targeted at NES are also being developed including, for example, techniques for allowing common signal / channel transmission adaptivity to provide enhanced NES. Such adaptivity of common signal / channel transmissions may include, for example, adaptive of SSB transmissions in the time domain (e.g. adaption of periodicity); adaptivity of (P)RACH transmissions in the time domain; and adaptivity of paging occasions including confining the paging occasions in the time domain (whilst avoiding an increase in paging latency). Ideally, any enhanced adaptation technique that is introduced will avoid negative impacts on legacy UEs (unless significant benefits are gained).

[0039] There is, therefore, an ongoing need to for development of the core requirements, for these above features.

[0040] In relation to (P)RACH in particular, there is a need for development of techniques that support adaptation mechanisms for (P)RACH in the time-domain for UEs in an idle / inactive mode and / or UEs in a connected mode.

[0041] Preferably, techniques for (P)RACH in the time-domain will include support mechanisms for adaptation involving the provision of (P)RACH resources for NES-capable UEs in addition to (P)RACH resources for legacy UEs (if any). It will be appreciated that, in this case, NES-capable UEs may be able to use both the additional (P)RACH resources and the (P)RACH resources for legacy UEs. The configuration of such additional (P)RACH resources may, for example, be provided by semi-static signalling although a number of details still need to be established such as, for example, whether there may be an overlap between additional (P)RACH resources configured for NES-capable UEs and the conventional (P)RACH resources configured for legacy UEs. Nevertheless, there is still a need to develop an appropriate and efficient adaptation mechanism for such additional (P)RACH resources. Ideally, any such adaptation mechanism will not impact existing (P)RACH configuration tables that are specified in the relevant standard for legacy (P)RACH configuration.

[0042] The disclosure aims to describe one or more apparatus and / or one or more associated methods that at least partially contributes to addressing one or more of the above needs.

[0043] The disclosure has a method performed by a User Equipment, UE, the method comprising receiving, from a network node, first information configuring a second resource for a physical random access channel, PRACH, in addition to a first resource for the PRACH; and receiving, from the network node, second information indicating availability of the second resource.

[0044] The disclosure has a method performed by a network node, the method comprising transmitting, to a User Equipment, UE, first information configuring a second resource for a physical random access channel, PRACH, in addition to a first resource for the PRACH; and transmitting, to the UE, second information indicating availability of the second resource.

[0045] The disclosure has a User Equipment, UE, comprising means for receiving, from a network node, first information configuring a second resource for a physical random access channel, PRACH, in addition to a first resource for the PRACH; and receiving, from the network node, second information indicating availability of the second resource.

[0046] The disclosure has a network node comprising means for transmitting, to a User Equipment, UE, first information configuring a second resource for a physical random access channel, PRACH, in addition to a first resource for the PRACH; and means for transmitting, to the UE, second information indicating availability of the second resource.

[0047] In the context of (P)RACH adaptation involving the use of additional (P)RACH resources for a connected mode UE and / or for an idle / inactive mode UE, the conceivers of the apparatus and / or methods disclosed herein have considered (amongst other things) the development of a downlink control information (DCI) based adaptation mechanism that, beneficially, does not require the introduction of a new DCI format.

[0048] For example, the conceivers of the apparatus and / or methods disclosed herein have considered (amongst other things) a DCI-based adaptation mechanism for additional (P)RACH resources in which DCI using a DCI format that is used for scheduling of the PDSCH (e.g., DCI Format 1_0) may carry an adaptation indication for UEs in an idle / inactive mode and / or connected mode (albeit this does not preclude other DCI formats / signalling mechanisms being usable for providing an adaptation indication in addition to, or as an alternative to, the DCI format for scheduling the PDSCH). The DCI format used may, for example, be specifically configured for the scheduling of paging messages by addressing the DCI using a paging radio network temporary identifier (P-RNTI - e.g., by using the P-RNTI to scramble the cyclic redundancy check (CRC) bits of the corresponding DCI format 1_0).

[0049] The various functional means described below that are part of the UE may be provided by a memory and one or more processors that execute instructions stored in the memory. Similarly, the various functional means described below that are part of the access network node may be provided by a memory and one or more processors that execute instructions stored in the memory.

[0050] Various example described below may be implemented by means of a computer program product comprising computer implementable instructions for causing a programmable computer to carry out any of the methods described below. The computer implementable instructions may be provided as a signal or on a tangible computer readable medium.

[0051] Various apparatus and methods will now be described, by way of example, with reference to the accompanying drawings in which:

[0052] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system;Fig. 2 illustrates a typical frame structure that may be used in the communication system of Fig. 1;Fig. 3 illustrates an Abstract Syntax Notation One (ASN.1) representation of a possible implementation of an information element that may include further information elements used for configuring (P)RACH resources in the communication system of Fig. 1;Fig. 4 illustrates an Abstract Syntax Notation One (ASN.1) representation of a possible implementation of an information element that may be used to specify cell specific random-access parameters in the communication system of Fig. 1;Fig. 5 illustrates an Abstract Syntax Notation One (ASN.1) representation of a possible implementation of an information element that may be used to specify a generic set of random-access parameters in the communication system of Fig. 1;Fig. 6 is a simplified sequence diagram illustrating a method of facilitating (P)RACH adaptation in the communication system of Fig. 1;Fig. 7 is a simplified sequence diagram illustrating another method of facilitating (P)RACH adaptation in the communication system of Fig. 1;Fig. 8 is a simplified sequence diagram illustrating another method of facilitating (P)RACH adaptation in the communication system of Fig. 1;Fig. 9 is a simplified sequence diagram illustrating a method of facilitating a duration limited (P)RACH adaptation in the communication system of Fig. 1;Fig. 10 is a simplified sequence diagram illustrating another method for facilitating a duration limited (P)RACH adaptation in the communication system of Fig. 1;Fig. 11 is a simplified sequence diagram illustrating another method for facilitating a duration limited (P)RACH adaptation in the communication system of Fig. 1;Fig. 12A is a simplified illustration of one possible additional (P)RACH resource activation timing that may occur in the communication system of Fig. 1;Fig. 12B is a simplified illustration of one possible additional (P)RACH resource activation timing that may occur in the communication system of Fig. 1;Fig. 13 is a schematic block diagram illustrating the main components of a UE that may be used in the communication system of Fig. 1; andFig. 14 is a schematic block diagram illustrating the main components of a RAN node that may be used in the communication system of Fig. 1.

[0053] <Overview> 　　An exemplary communication system will now be described in general terms, by way of example only, with reference to Figs. 1 to 5.

[0054] Fig. 1 schematically illustrates a communication system 1 to which the examples described herein are applicable.

[0055] In the communication system 1 user equipment (UEs) 3 (3-1, 3-2, 3-3 ) (e.g. mobile telephones and / or other mobile devices) can communicate with each other via a corresponding radio access network (RAN) node 5-1, 5-2 that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, each RAN node 5 (5-1, 5-2) comprises a base station or 'gNB' that respectively operates one or more associated cells. In the illustrated communication system 1, the coverage provided by each RAN node 5 may be by means of a plurality of beams. It will be appreciated that while, for clarity of illustration, only a selection of possible beams are shown, the set of beams may include any suitable number of beams and each RAN node 5 may operate a respective set of beams or may provide coverage in a non-beamformed manner.

[0056] Communication via each RAN node 5 is typically routed through a core network 7 (e.g. a 5G core network, evolved packet core network (EPC), or any other core network).

[0057] As those skilled in the art will appreciate, whilst three UEs 3 and two RAN nodes 5 are shown in Fig. 1 for illustration purposes, the system, when implemented, will typically include other RAN nodes and UEs.

[0058] Each RAN node 5 controls one or more associated cells either directly, or indirectly via one or more other nodes (such as home base stations, relays, remote radio heads, distributed units, and / or the like). It will be appreciated that the RAN nodes 5 may be configured to support more than one radio access technology and its associated communication protocols (e.g., 4G, 5G, 6G, and / or later generation, and / or any other 3GPP or non-3GPP communication protocols).

[0059] The UEs 3 and their serving RAN node 5 are connected via an appropriate air interface (for example the so-called 'Uu' interface and / or the like). Neighbouring RAN nodes 5 may be connected to each other via an appropriate RAN node to RAN node interface (such as the so-called 'X2' interface, 'Xn' interface and / or the like).

[0060] The core network 7 includes a number of logical nodes (or 'functions') for supporting communication in the communication system 1. In this example, the core network 7 comprises control plane functions (CPFs) 10 and network node entities for the communication of user data (e.g. user plane functions (UPFs)) 11. The CPFs 10 include one or more network node entities for the communication of control signalling (e.g. Access and Mobility Management Functions (AMFs)) 10-1 , one or more network node entities for session management (e.g. Session Management Functions (SMFs)) 10-2 and a number of other functions 10-n. Additional functions may include, for example: an Authentication Server Function (AUSF) which facilitates security processes; a Unified Data Management (UDM) entity for managing user specific data (e.g., for access authorization, user registration, and data network profiles); a Policy Control Function (PCF); an Application Function (AF); a Security Anchor Function (SEAF) which is in a serving network and acts as a "middleman" during an authentication process between a UE and its home network; an Authentication credential Repository and Processing Function (ARPF) which maintains the authentication credentials; and / or the like. It will be appreciated that the nodes or functions may have different names in different systems.

[0061] Each RAN node 5 is respectively connected to the core network nodes via appropriate interfaces (or 'reference points') such as an N2 reference point between the RAN node 5 and the AMF 10-1 for the communication of control signalling, and an N3 reference point between the RAN node 5 and each UPF 11 for the communication of user data. The UEs 3 are each connected to the AMF 10-1 via a non-access stratum (NAS) connection over an appropriate reference point (e.g., N1 reference point (analogous to the S1 reference point in LTE)). It will be appreciated, that N1 communication is routed transparently via the RAN node 5.

[0062] Each UPF 11 is respectively connected to an external data network (e.g. an IP network such as the internet) via an appropriate reference point (e.g., N6 reference point) for communication of the user data.

[0063] The AMF 10-1 performs mobility management related functions, maintains the NAS signalling connection with each UE 3 and manages UE registration. The AMF 10-1 is also responsible for managing paging.

[0064] The SMF 10-2 is connected to the AMF 10-1 via an appropriate reference point (e.g., N11 reference point). The SMF 10-2 provides session management functionality (that formed part of MME functionality in LTE) and additionally combines some control plane functions (provided by the serving gateway and packet data network gateway in LTE). The SMF 10-2 also allocates IP addresses to each UE 3. The SMF 10-2 uses user information provided via the AMF to determine what session manager would be best assigned to the user. The SMF 10-2 may be considered effectively to be a gateway from the user plane to the control plane of the network. The SMF 10-2 also allocates IP addresses to each UE 3.

[0065] Each RAN node 5 is also configured for transmission of, and the UEs 3 are configured for the reception of, control information and user data via a number of downlink (DL) physical channels and for transmission of a number of physical signals. The DL physical channels correspond to resource elements (REs) carrying information originated from a higher layer, and the DL physical signals are used in the physical layer and correspond to REs which do not carry information originated from a higher layer.

[0066] The physical channels may include, for example, a physical downlink shared channel (PDSCH), a physical broadcast channel (PBCH), and a physical downlink control channel (PDCCH). The PDSCH carries data sharing the PDSCH's capacity on a time and frequency basis. The PDSCH can carry a variety of items of data including, for example, user data, UE-specific higher layer control messages mapped down from higher channels, system information blocks (SIBs), and paging. The PDCCH carries downlink control information (DCI) for supporting a number of functions including, for example, scheduling the downlink transmissions on the PDSCH and also the uplink data transmissions on a physical uplink shared channel (PUSCH). The PBCH provides at least the UEs 3 with the Master Information Block (MIB). It also, in conjunction with the PDCCH, supports the synchronisation of time and frequency, which aids cell acquisition, selection and re-selection. Specifically, a UE 3 may receive a Synchronization Signal Block (SSB), and the UE 3 may assume that reception occasions of a PBCH, primary synchronization signal (PSS) and secondary synchronization signal (SSS) are in consecutive symbols and form a SS / PBCH block. The RAN node 5 may transmit a number of SSBs corresponding to different DL beams. The total number of SSBs may be confined, for example, within a 5ms duration as an SS burst.

[0067] The DL physical signals may include, for example, reference signals (RSs) and synchronization signals (SSs). A reference signal (sometimes known as a pilot signal) is a signal with a predefined special waveform known to both the UE 3 and the RAN node 5. The reference signals may include, for example, cell specific reference signals, UE-specific reference signal (UE-RS), downlink demodulation signals (DMRS), and channel state information reference signal (CSI-RS).

[0068] Similarly, the UEs 3 are configured for transmission of, and the RAN node 5 is configured for the reception of, control information and user data via a number of uplink (UL) physical channels corresponding to REs carrying information originated from a higher layer, and UL physical signals which are used in the physical layer and correspond to REs which do not carry information originated from a higher layer. The physical channels may include, for example, the PUSCH, a physical uplink control channel (PUCCH), and / or a physical random-access channel (which may be abbreviated as either 'PRACH' or 'RACH' - the term (P)RACH will be used herein). The UL physical signals may include, for example, demodulation reference signals (DMRS) for a UL control / data signal, and / or sounding reference signals (SRS) used for UL channel measurement.

[0069] <Frame Structure> 　　Referring to Fig. 2, which illustrates the typical frame structure that may be used in the communication system 1, the RAN nodes 5 and UEs 3 of the communication system 1 communicate with one another using resources that are organised, in the time domain, into frames in this case of length 10ms. Each frame comprises ten equally sized subframes of 1ms length. Each subframe is divided into one or more slots comprising 14 (or in some cases 12) orthogonal frequency-division multiplexing (OFDM) symbols of equal length.

[0070] As seen in Fig. 2, the communication system 1 supports multiple different numerologies (subcarrier spacing (SCS), slot lengths and hence OFDM symbol lengths). Specifically, each numerology is identified by a parameter, μ, where μ=0 represents 15 kHz (corresponding to the LTE SCS). Currently, the SCS for other values of μ can, in effect, be derived from μ=0 by scaling up in powers of 2 (i.e., SCS = 15 x 2μ kHz). The relationship between the parameter, μ, and SCS (Δf) is as shown in Table 1:

[0071] <Control Information> 　　In the communication system 1, the RAN node 5 is configured to transmit control information to the UE 3 using one or more control resource sets (CORESETs). A CORESET is a set of time-frequency resources within which the UE 3 can search for DCI transmitted by a RAN node 5 on a PDCCH. A CORESET is analogous to the control region at the start of subframes in earlier generations of communication technology. Unlike earlier generations, however, in which the frequency domain of the control region typically corresponded to the total system bandwidth, the frequency domain location for CORESET is localised to a specific region in the frequency domain and has a variable width that can be set to any suitable value (typically in multiples of six resource blocks where each resource block comprises twelve subcarriers in the frequency domain).

[0072] A number of different DCI formats can be used by the RAN node 5, depending on requirements, for transmission on a PDCCH corresponding to one of the PDCCH candidates in one of the search spaces configured for a given UE 3. For example, the RAN node 5 may be able to transmit DCI using one or more of the currently standardised DCI formats as set out in Table 2.

[0073] Different DCI formats may or may not have the same DCI size. Moreover, DCI using a given DCI format may be configured for a specific purpose by addressing the DCI using a corresponding radio network temporary identifier (RNTIs) that a UE 3 may monitor for (e.g., by using the corresponding RNTI to scramble the cyclic redundancy check (CRC) bits of the DCI). Depending on the specific purpose to which the RNTI used relates, a given DCI format used may have different fields for carrying a different corresponding payload.

[0074] By way of example, DCI format 1_0 may have a CRC scrambled: 　　using a 'cell' RNTI (C-RNTI) for the purposes of scheduling a downlink transmission on the PDSCH or a PDCCH order on the PDSCH for initiating a random access procedure at the UE; 　　using a modulation and coding scheme C-RNTI (MCS-C-RNTI) for indicating an alternative MCS table is to be for the scheduled PDSCH; 　　using a configured scheduling RNTI (CS-RNTI) for indicating semi-persistent scheduling (SPS) on the PDSCH; 　　using a random access RNTI (RA-RNTI) to indicate the scheduling is for a random access response (RAR) / Msg2 on the PDSCH; 　　using a temporary C-RNTI (TC-RNTI) to indicate the scheduling is for a contention resolution message / Msg4 on the PDSCH; 　　using a system information RNTI (SI-RNTI) to identify scheduling for a broadcast / system information on the PDSCH; or 　　using a paging RNTI (P-RNTI) for indicating, to a population of UEs, resources for reception of a paging message on the PDSCH.

[0075] A DCI with DCI format 1_0 scrambled using P-RNTI may also be used to inform the UEs about system information modifications via certain SIBs, and / or earthquake and tsunami warning system (ETWS) / commercial mobile alert system (CMAS) notifications via other SIBs (e.g., SIB6, SIB7, or SIB8), using a 'short messages' field of that DCI format.

[0076] Typically, a UE 3 is capable of monitoring up to three different DCI sizes for DCI formats using a C-RNTI - typically used as an identifier for scheduling purposes. Additionally, a UE 3 is typically capable of monitoring one additional DCI size using other RNTIs for specific purposes (e.g., a slot format indication RNTI (SFI-RNTI), interruption RNTI (INT-RNTI) in the case of DCI formats 2_0 and 2_1 respectively, or the like). This constraint is sometimes referred to as the "3+1" size budget and is imposed because a DCI scrambled with a C-RNTI is, generally, more time critical than a DCI scrambled with a RNTI used for another specific purpose, and so requires the UE 3 to decode it promptly in order to be able to process the scheduled data transmission.

[0077] To take account of the constraint imposed by the DCI size budget, the sizes of some DCI formats may be aligned by padding, truncation, and / or determining a frequency domain resource assignment field differently.

[0078] A UE 3 may monitor a set of PDCCH candidates in one or more control resource sets (CORESETs) on an active DL bandwidth part, where monitoring implies decoding each PDCCH candidate according to the monitored DCI formats. The number of blind decodes (BDs) may be restricted on a per carrier basis of a serving cell. The number of BDs may refer to the number of monitored PDCCH candidates or the number of PDCCH candidates a UE is capable of decoding within a certain time frame, such as a slot or span of consecutive symbols in a slot. As an example, at a 15 kHz subcarrier spacing (SCS), the maximum number of BDs per slot per serving cell supported by a UE 3 may be 44 BDs.

[0079] <DCI format 1_0 scrambled using P-RNTI:> 　　The fields used for DCI format 1_0 when scrambled using P-RNTI may typically include, for example: -　　A short messages indicator field (e.g., 2 bits) for indicating whether the DCI includes only scheduling information for a paging transmission (e.g., set to

[0001] ), includes only a short message value (e.g., set to

[0010] ), or includes both (e.g., set to

[0011] ) - an example of the possible content of this field is shown in Table 3 below; -　　A short messages field (e.g., 8 bits) for providing a population of UEs with a short message regarding the content of the broadcast control channel (BCCH) - e.g., whether SIB6, SIB7 and / or SIB8 has been modified, whether there is an EWTS primary notification (SIB6), EWTS secondary notification (SIB7), and / or CMAS notification (SIB8) - an example of the possible content of this field is shown in Table 4 below; -　　A frequency domain resource assignment field (of variable length) for allocating a set of resource blocks (RBs) for the PDSCH; -　　A time domain resource assignment field (e.g., 4 bits) for carrying a pointer towards a row in a look-up table defining, for example, a slot offset, PDSCH mapping type, starting symbol, and number of allocated symbols; -　　A VRB-to-PRB mapping (e.g., 1 bit) to indicate whether the PDSCH uses non-interleaved (e.g., set to [0]) or interleaved (e.g., set to [1]) virtual resource block (VRB) to physical resource block (PRB) mapping; -　　A modulation and coding scheme (MCS) field (e.g., 5 bits) for defining a pointer to a relevant MCS look-up table; -　　A transport block (TB) scaling field (e.g., 2 bits) for configuring a scaling factor which may be applied when determining a transport block size (TBS) for either a paging message or a Msg2 transmission; -　　A tracking reference signal (TRS) availability indication (e.g., 1, 2, 3, 4, 5, or 6 bits) for providing a bitmap for up to 6 groups of TRS resource sets where the configuration of each TRS resource set is respectively associated with a bit of the bitmap; and -　　Reserved bits (e.g., (6 - M) bits where 'M' is the number of bits for the TRS availability indication field) for ensuring that all variations of DCI format 1_0 have the same size).

[0080] <Network Energy Saving (NES)> 　　The UEs 3 and RAN nodes 5 of the communication system 1 may also be mutually configured to be able to coordinate with one another appropriately to implement one or more NES techniques. The NES techniques may include, for example, conventional DTX / DRX at the UE 3, cell DTX / DRX at the RAN node 5, the use of SSB-less cells in which SSBs are not transmitted, the use of SIB1-less cells in which SIB1s are not transmitted, the provision of SSBs on-demand in one or more cells, and / or the provision of one remaining minimum system information (SIB1) transmissions on-demand in one or more cells. It will be appreciated that the UEs 3 may include UEs that support one or more of the NES techniques and UEs that do not support one or more of the NES techniques.

[0081] The communication system 1 may, for example, support SSB-less / SIB1-less operation for intra-band carrier aggregation (CA) scenarios, for example, where the UE 3 is able to retrieve system information from, and can perform synchronisation based on, another intra-band cell that transmits SSB and SIB1. For the non-CA scenario, the UE 3 may obtain system information from other associated carriers / cells and synchronise from other associated carriers / cells and / or synchronise from other signals transmitted in the cell. A cell in which a RAN node 5 transmits, and the UE 3 is capable of receiving, an SSB, system information and paging may be referred to as an anchor cell. Access may occur only via an anchor cell, or directly via the non-anchor NES cell if supported. Where access directly via a non-anchor NES cell is supported, system information transmitted in the anchor cell may also include the necessary information to access the non-anchor NES cell. A UE 3 will camp on an anchor cell rather than a non-anchor NES cell in which there is no SIB1 transmission (or no SSB or SIB1 transmission).

[0082] The communication system 1 may nevertheless support on-demand SSB / SIB1 transmissions (e.g., in an otherwise SSB-less or SIB1-less cell) to enable longer periods of cell inactivity to achieve network energy saving. SSB / SIB1 transmission in a serving cell may, for example, be triggered on-demand, for example by the UE 3 (or RAN node 5). The UE and RAN node 5 of the communication system 1 may, for example, be mutually configured to support the transmission of dedicated SSBs and / or SIB1s in (non-anchor NES) SCells on-demand.

[0083] The triggering of an on-demand SSB / SIB1 may, for example, be facilitated by the transmission, by a UE 3, of an appropriate trigger signal (or 'wake-up' signal (WUS)) in the uplink to cause the RAN node 5 to 'wake-up' from its current sleep state (or at least transition into a more awake / higher power level sleep state) and begin to transmit SSBs in the corresponding non-anchor / secondary cell. The configuration of the WUS, for example, the configuration of when and / or where in frequency the WUS can be transmitted, may be predefined or may be configured by a RAN node 5 (e.g., via system information and / or DCI).

[0084] A WUS may, for example be configured by appropriate common radio resource configuration information, comprising WUS configuration information (e.g., in a dedicated WUS configuration information element), provided as part of system information.

[0085] On-demand SSB / SIB1 transmission may, for example, be enabled semi-statically or dynamically. For example, common channel adaptation and / or on-demand SSB may be enabled via dedicated RRC signalling on a PCell and / or PScell if the UE has a PCell and / or PScell connection. On-demand SSB / SIB1 may be enabled via system information (e.g., where the content of system information includes a carrier indication field to indicate the applicable carrier / cell for the enabling of on-demand SSB transmission). On-demand SSB / SIB1 may be enabled via a DCI with an appropriate DCI format.

[0086] Depending on what energy saving technique is being implemented, and how that technique is being implemented, the RAN node 5 (and / or a specific subset of one or more cells that it operates) may be operated in one of a number of different NES modes or states. The possible NES modes may include, for example, simple 'on' or 'off' states. Nevertheless, the possible NES modes may include different predefined energy / power consumption states for the RAN node (or one or more cells operated by that RAN node) including: a number of different 'sleep' states in which the RAN node 5 is at least partially off / not fully on but may perform certain operations. These sleep states may be characterised, for example, by different relative power levels, for example: 'deep' sleep (lowest power); 'light' sleep (higher power relative to deep sleep); and micro sleep (higher power relative to both deep and light sleep). Moreover, the possible NES modes may include an active uplink state and an active downlink state in which the RAN node is respectively 'on' for communication in the uplink direction only, or for communication in the downlink direction only.

[0087] It will be appreciated that whilst a number of specific techniques are described, a given UE 3 or RAN node 5 need not implement every NES technique mentioned, and or may implement one or more other such NES techniques.

[0088] <Random-Access Procedures> 　　Each UE 3 and each RAN node 5 of the communication system 1 are mutually configured for performing their part of a (P)RACH procedure, for example when the UE 3 initially accesses the network or at other times when necessary.

[0089] For example, for initial access, on detection and selection of a beam the UE 3 is able to attempt access to the cell via that beam using an initial RRC connection setup procedure comprising a contention-based random-access (CBRA) procedure. Prior to attempting initial access, the UE 3 chooses random-access resources (including, for example, a preamble) to use to initiate the (P)RACH procedure. The UE 3 then sends the selected preamble (e.g., in 'Msg1') to the RAN node 5 over a (P)RACH for initiating the process to obtain synchronization in the uplink (UL).

[0090] In response to Msg1, the RAN nodes 5 responds with a random-access response (RAR) (or 'Msg2'). The RAR indicates reception of the preamble and typically includes, for example: a timing-alignment (TA) command for adjusting the transmission timing of the UE based on the timing of the received preamble; an uplink grant field indicating the resources to be used in the uplink for a physical uplink shared channel (PUSCH); a frequency hopping flag to indicate whether the UE is to transmit on the PUSCH with or without frequency; a modulation and coding scheme (MCS) field from which the UE can determine the MCS for the PUSCH transmission; and a transmit power control (TPC) command value for setting the power of the PUSCH transmission.

[0091] A random-access RNTI (RA-RNTI) is associated, by the RAN node 5, with the RO in which the preamble is sent by the UE 3. The RA-RNTI is used to scramble the CRC bits of a DCI (e.g., using DCI format 1_0) used for scheduling transmission of a PDSCH that carries the RAR.

[0092] The RA-RNTI may be computed follows: 　　　　RA-RNTI= 1 + s_id + 14 × t_id + 14 × 80 × f_id + 14 × 80 × 8 × ul_carrier_id 　　Where: 　　　　s_id is an index of the first OFDM symbol of the RO (0 ? s_id < 14); 　　　　t_id is an index of the first slot of the RO in a system frame (0 ? t_id < 80); 　　　　f_id is an index of the RO in the frequency domain (0 ? f_id < 8); and 　　　　ul_carrier_id is an identifier of the uplink carrier used for the random-access preamble transmission (0 for NUL carrier, and 1 for SUL carrier)

[0093] Following receipt of the RAR, the UE 3 then sends a third message ('Msg3') to the network over a physical uplink shared channel (PUSCH) based on the information in the RAR. The specific message sent by the UE in this step, and the content of the message, depends on the context in which the (P)RACH procedure is being used. In the example of initial radio RRC connection setup, however, Msg3 typically comprises an RRC setup request or similar message carrying a temporary randomly generated UE identifier. The network responds with a fourth message ('Msg4') which carries the randomly generated UE identifier received in Msg3 (for contention resolution purposes) to resolve any collisions between different UEs using the same preamble sequence. When successful, Msg4 also transfers the UE to a connected state.

[0094] While a four-step (P)RACH procedure is described it will be appreciated that, each UE 3 and RAN node 5 may be configured for performing a two-step (P)RACH procedure (e.g., as mentioned in the introduction). Effectively, the two-step (P)RACH procedure is achieved by combining the UE's (P)RACH preamble (Msg1) transmission and the scheduled PUSCH transmission (Msg3) into a single message (referred to as 'MsgA'). Similarly, the random-access response (RAR / Msg2) from the RAN node to UE and the contention resolution message (Msg4) are combined in the two-step random-access procedure (and referred to as 'MsgB').

[0095] Moreover, it will be appreciated that, while a contention-based random-access (CBRA) procedure is described each UE 3 and each RAN node 5 may also be mutually configured for performing a non-contention based 'contention free' random-access (CFRA) procedure in which a dedicated preamble may be assigned by the RAN node 5 to the UE 3. For example, while the UE 3 can trigger initiation of a CBRA procedure itself (e.g., when the UE 3 needs to connect to the network), initiation of a CFRA procedure may be triggered by the network. For example, a (P)RACH procedure may be initiated via a message sent via DCI with an appropriate DCI format (e.g. 1_0) in a PDCCH - such a message is commonly known as a PDCCH order. A CFRA procedure may be also initiated by a RAN node 5 when handover is required (e.g., using a handover command message).

[0096] The UE 3 may be configured to perform a (P)RACH procedure in the context of a number of different events including (but not limited to), for example: -　　for initial access to the network as described above (typically using a CBRA procedure); -　　for an RRC Connection re-establishment procedure (typically using a CBRA procedure); -　　on DL data arrival, when the UE is an RRC connected mode / state (or in an RRC inactive mode / state) while a small data transfer (SDT) procedure is ongoing, when the UL is not synchronised, e.g., an UL synchronisation status is "non-synchronised" (typically using a CBRA or a CFRA procedure); -　　on UL data arrival, when the UE is an RRC connected mode / state (or in an RRC inactive mode / state) while a small data transfer (SDT) procedure is ongoing, when the UL is not synchronised, e.g., an UL synchronisation status is "non-synchronised" (typically using a CBRA procedure); -　　on UL data arrival, when the UE is an RRC connected mode / state or during an RRC inactive mode / state while a small data transfer (SDT) procedure is ongoing, when there are no physical uplink control channel (PUCCH) resources for a scheduling request (SR) available (typically using a CBRA procedure); -　　on SR failure (typically using a CBRA procedure); -　　on RRC request upon synchronous reconfiguration, e.g. handover (typically using a CBRA or a CFRA procedure); -　　for initiating transition from an RRC inactive to an RRC connected mode / state, e.g., for an RRC connection resume procedure from the RRC inactive mode / state (typically using a CBRA procedure); -　　to establish a time alignment for a secondary timing alignment group (TAG) (typically using a CBRA or a CFRA procedure); -　　to initiate a request for 'other' system information (SI), e.g., on-demand SI (typically using a CBRA or a CFRA procedure); and / or -　　for the purposes of beam failure recovery (typically using a CBRA or CFRA procedure).

[0097] <RACH Resource Configuration / Selection> 　　The UE 3 is configured to send the (P)RACH preamble (e.g., Msg1 / MsgA) using an appropriate (P)RACH occasion (RO), within a (P)RACH slot, based on a (P)RACH configuration indicated by the RAN node 5 (e.g., via system information, appropriate RRC signalling, or the like). The (P)RACH configuration may, for example, be provided as a 'common' (P)RACH configuration or a 'dedicated' (P)RACH configuration.

[0098] A 'common' (P)RACH configuration may, for example, be used to specify cell specific random-access parameters (e.g., parameters which may be common to a plurality of (e.g., all, or a subset of) UEs 3 in a cell operated by a RAN node 5). It will, nevertheless, be appreciated that a single UE 3 may nevertheless be provided with the common (P)RACH configuration. The common (P)RACH configuration typically provides information that the UE 3 can use to identify the available (P)RACH preambles, and (P)RACH occasions, to enable the UE 3 to initiate a CBRA procedure.

[0099] The RAN node 5 may provide the common (P)RACH configuration via an appropriate information element (IE) (e.g., a 'RACH-ConfigCommon' IE or the like) in system information (e.g., SIB1) or using dedicated signalling (e.g., RRC) depending on the context.

[0100] Fig. 3 illustrates, by way of illustrative example only, an Abstract Syntax Notation One (ASN.1) representation of a possible implementation of an information element that may include one or more further information elements that may be used for configuring (P)RACH resources in the communication system 1.

[0101] As seen in Fig. 3, the common (P)RACH configuration may be provided in a (first) RACH-ConfigCommon IE 310a as part of another IE for configuring the common parameters of an uplink bandwidth part (BWP) (e.g., a "BWP-UplinkCommon IE" 312). Such parameters are "cell specific" and the network ensures the necessary alignment with corresponding parameters of other UEs.

[0102] For example, a common (P)RACH configuration may be provided in system information (e.g., SIB1) as part of common uplink configuration information (e.g., common uplink parameters) for configuring communication via an uplink carrier in a cell (e.g., a serving cell). The IE for configuring the common parameters of an uplink BWP (e.g., BWP-UplinkCommon IE 312 in Fig. 3) may, for example, form part of a common uplink configuration IE (e.g., an "UplinkConfigCommon IE") which, in turn, forms part of a serving cell common configuration IE (e.g., "ServingCellConfigCommon IE" / "ServingCellConfigCommonSIB IE", or the like) that is specifically used to configure cell specific parameters of a UE's serving cell in SIB1.

[0103] Where the RAN node 5 / UE 3 supports the use of an additional (supplementary) uplink carrier, a (potentially different) common (P)RACH configuration may also (or alternatively) be provided in the system information as part of common uplink configuration information for configuring uplink communication via that supplementary uplink carrier for that cell. Moreover, where reduced capability UEs may be present in the cell another (potentially different) common (P)RACH configuration may also (or alternatively) be provided in the system information as part of common uplink configuration information for configuring uplink communication for those reduced capability UEs.

[0104] A common (P)RACH configuration may, nevertheless, be provided in an RRC message for (re)configuring / modifying an RRC connection at the UE (e.g., an RRCReconfiguration message or the like). The common (P)RACH configuration may, for example, be provided as part of cell group configuration information (e.g., in a CellGroupConfig IE or the like) for configuring common cell specific parameters of a UE's serving cell, e.g., in a serving cell common configuration IE (e.g., a ServingCellConfigCommon IE or the like) forming part of the cell group configuration information. Each configured serving cell may be a cell of a master cell group (MCG), associated with a master RAN node (for dual connectivity), or of a secondary cell group (SCG), associated with a secondary RAN node (for dual connectivity).

[0105] A common (P)RACH configuration in the RRC message may, for example, be provided for synchronised reconfiguration (also known as reconfiguration with synchronisation or 'reconfiguration with sync') in one or more so called special cells (SpCells), where each SpCell is either a primary cell of an MCG (a 'PCell') or a primary cell of an SCG (a 'PSCell'). Another (potentially different) common (P)RACH configuration in the RRC message may also (or alternatively) be provided for one or more secondary cells (SCells) of an MCG and / or an SCG (an SCell being, for example, a cell that provides additional radio resources on top of an SpCell, e.g., as part of carrier aggregation). The common (P)RACH configuration for synchronised reconfiguration may, for example, be provided as part of an information element for configuring reconfiguration with synchronisation (e.g., a 'ReconfigurationWithSync' IE or the like). The (P)RACH related information carried by the information element for configuring reconfiguration with synchronisation information effectively defines the set of ROs for reconfiguration with synchronisation.

[0106] Where the RAN node 5 / UE 3 supports the use of an additional (supplementary) uplink carrier in a given cell (e.g., an SpCell or an SCell), a (potentially different) common (P)RACH configuration may also (or alternatively) be provided, for that supplementary uplink carrier, in the RRC message as part of the serving cell common configuration information for that cell.

[0107] A possible configuration of the common (P)RACH configuration IE is shown in Fig. 4, which illustrates, by way of illustrative example only, an ASN.1 representation of a possible implementation of an information element that may be used to specify cell specific random-access parameters in the communication system 1.

[0108] A 'dedicated' (P)RACH configuration, on the other hand, may be used to specify dedicated random-access parameters (e.g., parameters which may be dedicated to a specific UE 3 in a cell operated by a RAN node 5). The dedicated (P)RACH configuration typically provides information that the UE 3 can use to identify one or more dedicated (P)RACH preambles, and / or one or more dedicated (P)RACH occasions, to enable the UE 3 to initiate a CFRA procedure.

[0109] The RAN node 5 may provide the dedicated (P)RACH configuration via an appropriate information element (IE) (e.g., a 'RACH-ConfigDedicated' IE or the like) using dedicated (e.g., RRC) signalling depending on the context. For example, a dedicated (P)RACH configuration may be provided for synchronised reconfiguration in one or more SpCells, where each SpCell is either a PCell (of an MCG) or a PSCell (of an SCG). Where the RAN node 5 / UE 3 supports the use of an additional (supplementary) uplink carrier in a given cell (e.g., an SpCell), a (potentially different) dedicated (P)RACH configuration may also (or alternatively) be provided, for that supplementary uplink carrier, in the RRC message as part of the serving cell common configuration information for that cell. The dedicated (P)RACH configuration for synchronised reconfiguration may, for example, be provided as part of the information element for configuring reconfiguration with synchronisation (e.g., a 'ReconfigurationWithSync' IE or the like).

[0110] Both a common (P)RACH configuration and a dedicated (P)RACH configuration may include a set of 'generic' random-access parameters that may be used to specify the random-access parameters both for regular (P)RACH procedures (e.g., for initial access) and for (P)RACH procedures that occur less often (e.g., for beam failure recovery). The generic set of parameters effectively defines the set of time and frequency resources allocated to the set of ROs and also power control parameters and an RAR window. The generic set of parameters may, for example, include most of the physical layer parameters for (P)RACH transmission.

[0111] The generic set of parameters may, for example, be included in an appropriate IE (e.g., a 'RACH-ConfigGeneric' IE or the like as seen at 410 in Fig. 4) in the common / dedicated (P)RACH configuration.

[0112] A possible configuration of such an IE is shown in Fig. 5, which illustrates, by way of illustrative example only, an ASN.1 representation of a possible implementation of an information element that may be used to specify the generic set of random-access parameters in the communication system 1.

[0113] The set of parameters may typically include (amongst other parameters), for example: - a (P)RACH configuration index (e.g., a 'prach-ConfigurationIndex' IE 510, or the like) that points to a row, in a (P)RACH configuration table, that includes a set of parameters for defining the timing of (P)RACH radio frames, and (P)RACH slots within those radio frames. By way of example only, this may typically have a value in the range 0 to 255 (or possibly in a different range, e.g., from 256 to 262, for a RAN node / UE with different capabilities); - an indication of a number of ROs that are multiplexed in frequency (e.g., a 'msg1-FDM' IE 512, or the like) - i.e., the number of ROs allocated in the frequency domain, for the same time domain resource (symbol / slot / subframe). By way of example only, this may typically have a value of 1, 2, 4 or 8; - an indication of an offset of the lowest (P)RACH transmission occasion, in the frequency domain, with respect to the lowest indexed physical resource block (PRB 0) - e.g., configured to ensure that the corresponding (P)RACH frequency resource is entirely within a bandwidth of a configure UL bandwidth part (BWP) (e.g., a 'msg1-FrequencyStart' IE 514, or the like). By way of example only, this may typically have a value from 0 to 274; - an indication of a parameter for setting a number of root sequences required per cell for a selected (P)RACH preamble (e.g., a 'zeroCorrelationZoneConfig' IE 516, or the like). This parameter effectively configures / maps to another parameter (Ncs) that indicates the amount of cyclic shift of the root sequence (or base sequence) to provide orthogonality between different preambles generated from each shift of the root sequence; - an indication of a target power level at the network receiver side (e.g., a 'preambleReceivedTargetPower' IE 518, or the like). By way of example only, this may typically have a value from -202 to -60 dBm (with steps of 2dBm); - an indication of a maximum number of random-access preamble transmissions that may be performed before a failure is assumed / declared (e.g., a 'preambleTransMax' IE 520, or the like). By way of example only, this may typically have a value in the set {3, 4, 5, 6, 7, 8, 10, 20, 50, 100, 200}; - an indication of a power ramping step to be used for (P)RACH preamble (re)transmission (e.g., a 'powerRampingStep' IE 522, or the like). By way of example only, this may typically have a value in the set {0 dB, 2 dB, 4 dB, 6 dB}; and / or - an indication of a Msg2 (RAR) window length (e.g., in number of slots). (e.g., a 'ra-ResponseWindow' IE 524, or the like). By way of example only, this may typically have a value in the set {1, 2, 4, 8, 10, 20, 40, 80} (or possibly a different set of values for a RAN node / UE supporting higher SCS (Δf) - e.g., an SCS of 480 kHz or SCS 960 kHz).

[0114] The (P)RACH configuration index effectively indicates the available set of ROs for the transmission of the random-access preamble (e.g., in Msg1 / MsgA). Specifically, the index points to a row in a standardised (P)RACH configuration table. The indicated row defines the (P)RACH radio frames within which ROs are present by means of two parameters 'x' and 'y' where the radio frames containing a (P)RACH occasion is given by the system frame number (nSFN) which satisfies the equation: n_SFN mod x=y

[0115] It can be seen that the first of these two parameters ('x') defines the length, in radio frames, of a time period within which each (P)RACH radio frame (and hence the associated set of ROs) occurs. Effectively, therefore, the parameter 'x' represents a periodicity at which the (P)RACH radio frames (and hence the associated set of ROs) are repeated. This period may be referred to as the (P)RACH configuration period. For example, a value of x=2 and y=1 defines that (P)RACH radio frames occur every second radio frame - in this case in every odd numbered radio frame. Similarly, a value of x=2 and y=0 also defines that (P)RACH radio frames occur every second radio frame - but in this case in every even numbered radio frame. In both these examples the (P)RACH configuration period is two radio frames (i.e., 20ms for a conventional 10ms radio frame). Contrastingly, a value of x=16 and y=1 would indicate that the (P)RACH configuration period was 16 radio frames (160ms) with the (P)RACH radio frames occurring in the second radio frame of each 16 radio frame (P)RACH configuration period.

[0116] The indicated row of the standardised (P)RACH configuration table also defines the specific (P)RACH slots of the (P)RACH radio frames in which the ROs are provided and how many ROs there are in each (P)RACH radio frame. The manner in which the row defines the specific (P)RACH slots may vary depending on whether the ROs are in FR1 or FR2. There are a number of different (P)RACH configuration tables that may be used including (P)RACH configuration tables configured for FR1 paired (FDD) spectrum, FR1 unpaired (TDD) spectrum, and FR2 unpaired (TDD) spectrum.

[0117] It can be seen that there is a minimum number of (P)RACH configuration periods within which there are sufficient ROs for every SSB to be respectively associated with (mapped to) one or more ROs at least once. This minimum number of (P)RACH configuration periods is called an 'association period' and depends on the number of ROs within each period and the number of SSBs per RO (or ROs per SSB) as defined by the corresponding (P)RACH configuration. The length of the association period in time will depend on the length of each (P)RACH configuration period (i.e., the number of (10ms) radio frames within each (P)RACH configuration period). The association period may be restricted to having certain permitted values, for example equivalent to 10ms, 20ms, 40ms, 80ms, and 160ms (i.e., {1, 2, 4, 8, or 16} 10ms (P)RACH configuration periods; {1, 2, 4, or 8} 20ms (P)RACH configuration periods; {1, 2, or 4} 40ms (P)RACH configuration periods; {1, or 2} 80ms (P)RACH configuration periods; or a single 160ms (P)RACH configuration period).

[0118] Both a common (P)RACH configuration, and a dedicated (P)RACH configuration, include parameters for assisting in the mapping between the SSBs (and hence the beams), and the specific ROs (within the (P)RACH slots) to be used by the UE 3. One of those parameters, for example, is the indication of the number of ROs that are multiplexed in frequency (e.g., 'msg1-FDM' IE 512, or the like) provided as part of the generic (P)RACH configuration information described above. Another parameter that can be used in the mapping between the SSBs and ROs specifies the number of SSBs that are associated with a single RO. In the case of the common (P)RACH configuration (e.g., for CBRA) the parameter specifying the number of SSBs that are associated with a single RO also specifies a number of different contention-based preambles (preamble indices) that are associated with each SSB (the parameter in this case may be labelled an 'ssb-perRACH-OccasionAndCB-PreamblesPerSSB' IE, as seen at 412 in Fig. 4, or the like). Nevertheless, in the case of the dedicated (P)RACH configuration (e.g., for CFRA) the parameter specifying the number of SSBs that are associated with a single RO may not specify a total number of different preambles (preamble indices) that are associated with each SSB (the parameter in this case may be labelled an 'ssb-perRACH-Occasion' IE or the like). As seen in Fig. 4, for example, the parameter specifying the number of SSBs that are associated with a single RO may have an assigned value that is a proper fraction, e.g., 1 / 8, 1 / 4, or 1 / 2 , to indicate that more than one RO is associated with a single SSB, or may have an assigned value that is an integer, e.g., 1, 2, 4, 8, or 16, to indicate that more than one SSB is associated with a single RO.

[0119] As seen in Fig. 4, a common (P)RACH configuration may also include a parameter indicating the total number of preambles used for contention based and contention free 4-step or 2-step random access in the (P)RACH resources defined in the common (P)RACH configuration (excluding preambles used for other purposes (e.g. for SI request)) - e.g., a 'totalNumberOfRA-Preambles' IE 416, or the like.

[0120] A reference signal received power (RSRP) threshold (e.g., a 'rsrp-ThresholdSSB' IE 414, or the like) for the selection of an SSB (and hence associated beam) for a (P)RACH procedure - i.e., a UE 3 may select an SSB (and corresponding (P)RACH resource) from SSBs for which a measured RSRP exceeds (or is not less than) the RSRP threshold. A similar RSRP threshold (e.g., a 'rsrp-ThresholdSSB-SUL' IE 418, or the like) may be defined for the selection of an SUL carrier on which to perform a (P)RACH procedure.

[0121] A dedicated (P)RACH configuration may also include information which allocates one or more dedicated (P)RACH preambles to the UE 3 (e.g., using a 'resources' IE or the like). The RAN node 5 may use this information to indicate one or more dedicated preambles for one or more SSB beams and / or to indicate one or more dedicated preambles for one or more CSI-RS beams. As the RAN node 5 will not know, before sending this information, which SSB / CSI-RS beam will be selected by the UE 3 for the (P)RACH procedure, a respective dedicated preamble may be allocated for each candidate beam.

[0122] The information, in the dedicated (P)RACH configuration, that indicates one or more dedicated preambles for one or more SSB beams may, for example, comprise a list of information for one or more SSBs. The list may include, for each SSB respectively: an identifier of the SSB (e.g., an SSB index / ID); and a random-access preamble index (e.g., in a 'ra-PreambleIndex' IE) of the preamble that the UE 3 should use when performing CFRA upon selecting a candidate beam identified by the SSB index. An indication of one or more ROs, associated with an SSB, in which the UE 3 (e.g., a MAC entity of the UE 3) may transmit a (P)RACH preamble may also be provided together with that list (e.g., using a 'ra-ssb-OccasionMaskIndex' IE or the like).

[0123] The information, in the dedicated (P)RACH configuration, that indicates one or more dedicated preambles for one or more CSI-RS beams may, for example, comprise a list of information for one or more CSI-RS resources (each associated with a corresponding CSI-RS beam). The list may include, for each CSI-RS resource respectively: an identifier of the CSI-RS resource (e.g., a CSI-RS index / ID as defined in a measurement object associated with the serving cell configured to the UE 3 previously, e.g., using RRC signalling); an indication of one or more RA occasions (e.g., an 'ra-OccasionList' IE or the like) that a UE 3 (e.g., a MAC entity of the UE 3) may use for random-access preamble transmission when performing CFRA upon selecting a candidate beam identified by the CSI-RS ID; and a random-access preamble index (e.g., in a 'ra-PreambleIndex' IE) of the preamble that the UE 3 should use in the RA occasions associated with the CSI-RS ID. An indication may be provided, together with the list, of a parameter indicating a reference signal received power (RSRP) threshold (e.g., a 'rsrp-ThresholdCSI-RS' IE or the like) for the selection of a CSI-RS resource (and hence associated beam) for a (P)RACH procedure. Hence, a UE 3 may select a CSI-RS resource (and corresponding (P)RACH resource) from CSI-RSs for which a measured RSRP exceeds (or is not less than) the RSRP threshold.

[0124] It will be appreciated that the common and dedicated (P)RACH configurations defined above only cover a subset of scenarios for which a CBRA or CFRA based (P)RACH procedure may be performed by a UE 3. For example, as indicated above, a (P)RACH procedure may be used to initiate an SI request (e.g. for other SI such as on-demand SI). Similarly, as indicated above, a (P)RACH procedure may be used for the purposes of recovery following a beam failure.

[0125] <RACH configuration for SI Request:> 　　As indicated above, a (P)RACH procedure may be used to initiate an SI request (e.g. for other SI such as on-demand SI). In this case the preamble (e.g., Msg1) is used to indicate the other SI that is specifically requested. To cater for SI request procedures, the RAN node 5 may configure the UE 3 with dedicated (P)RACH resources for the purposes of a SI request. Specifically, an SI request configuration may be provided by the RAN node 5 to a UE 3 (e.g., using a 'SI-RequestConfig' IE or the like) to configure the UE 3 with appropriate (P)RACH resources (e.g., preamble associated with specific SI requests) and associated ROs.

[0126] An SI request configuration may, for example, be provided as part of SI scheduling information (e.g., using an SI-SchedulingInfo IE) provided as part of system information (e.g., SIB1).

[0127] The SI request configuration may include information indicating a configuration of dedicated (P)RACH occasions for SI requests (e.g., using a 'rach-OccasionsSI' IE or the like). This information may include, for example, an SI request specific (P)RACH configuration (e.g., a 'rach-ConfigSI' configuration). This SI request specific (P)RACH configuration may include all, or a subset of the generic set of parameters (e.g., provided in the 'RACH-ConfigGeneric' IE or the like) described above in respect of the common / dedicated (P)RACH configuration.

[0128] The SI request configuration may also include a parameter that specifies the number of SSBs that are associated with a single RO (e.g., an 'ssb-perRACH-Occasion' IE or the like). The parameter, in the SI request configuration, specifying the number of SSBs that are associated with a single RO may have an assigned value that is a proper fraction, e.g., 1 / 8, 1 / 4, or 1 / 2 , to indicate that more than one RO is associated with a single SSB, or may have an assigned value that is an integer, e.g., 1, 2, 4, 8, or 16, to indicate that more than one SSB is associated with a single RO.

[0129] The SI request configuration may also include a parameter that specifies a periodicity of the SI request configuration (e.g., a 'si-RequestPeriod' IE or the like) defined as a number of association periods. This SI request period may have an assigned value that is a proper fraction, e.g., 1 / 8, 1 / 4, or 1 / 2 , thus indicating that a SI request configuration period that is shorter than (i.e., a fraction of) the association period, or may have an assigned value that is an integer, e.g., 1, 2, 4, 8, or 16, indicate that a SI request configuration period that is longer than (i.e., an integer multiple of) the association period.

[0130] The SI request configuration may also include an indication, for requesting each of one or more SI messages, respective information indicating the resources (preamble and ROs) to be used for requesting that SI message. The respective information indicating the resources may include, for each SI message: a start index of a set of one or more preambles that includes a preamble to be used for requesting that SI message (e.g., using a 'ra-PreambleStartIndex' IE or the like); an indication of one or more ROs, associated with an SSB, in which the UE 3 may transmit a (P)RACH preamble (e.g., using a 'ra-ssb-OccasionMaskIndex' IE or the like) for requesting an SI message; and an index associated with an association period in the SI request period (e.g., using a 'ra-AssociationPeriodIndex' IE or the like) within which the UE can send a request for one or more SI messages corresponding to this respective information indicating the resources, using one or more preambles of the set of preambles indicated by the corresponding start index and one or more ROs indicated by the indication of one or more ROs associated with an SSB.

[0131] In order to determine which preamble of the indicated set of preambles to use, the UE 3 applies the following logic. If N SSBs are associated with an RO, and N is greater than or equal to 1, for the ithSSB (where i = 0, …, N-1) the UE 3 selects the preamble with a preamble index equal to the indicated start index plus i for the SI request. For N less than 1, the UE 3 selects the preamble with a preamble index equal to the indicated start index for the SI request.

[0132] <RACH configuration for Beam Failure Recovery:> 　　As indicated above, a (P)RACH procedure may be used for the purposes of recovery following a beam failure. To cater for beam failure scenarios, the RAN node 5 may configure the UE 3 with dedicated (P)RACH resources for beam failure recovery. Specifically, a beam failure recovery configuration may be provided by the RAN node 5 to a UE 3 (e.g., using a 'BeamFailureRecoveryConfig' IE or the like) to configure the UE with (P)RACH resources and candidate beams for beam failure recovery in case of beam failure detection.

[0133] A beam failure recovery specific configuration may, for example, be provided in an RRC message for (re)configuring / modifying an RRC connection at the UE (e.g., an RRCReconfiguration message or the like). The beam failure recovery specific configuration may, for example, be provided as part of cell group configuration information (e.g., in a CellGroupConfig IE or the like) for configuring cell specific parameters of a UE's serving cell, e.g., in a serving cell configuration information element (e.g., a ServingCellConfig IE or the like) forming part of the cell group configuration information. Each configured serving cell may be a cell of a master cell group (MCG), associated with a master RAN node (for dual connectivity), or of a secondary cell group (SCG), associated with a secondary RAN node (for dual connectivity).

[0134] A beam failure recovery specific configuration in the RRC message may, for example, be provided as part of serving cell configuration information for one or more SpCells (e.g., in as part of a 'SpCellConfig' IE or the like). Another (potentially different) beam failure recovery specific configuration in the RRC message may also (or alternatively) be provided for one or more SCells of an MCG and / or an SCG.

[0135] In more detail, a beam failure specific (P)RACH configuration (e.g., a 'rach-ConfigBFR' configuration) may be provided as part of the beam failure recovery configuration, which effectively defines a set of ROs that may be used for a potential beam failure recovery request. This beam failure specific (P)RACH configuration may include all, or a subset of the generic set of parameters (e.g., provided in the 'RACH-ConfigGeneric' IE or the like) described above in respect of the common / dedicated (P)RACH configuration.

[0136] The beam failure recovery configuration may also include a parameter indicating a reference signal received power (RSRP) threshold (e.g., a 'rsrp-ThresholdSSB' IE or the like) for the selection of an SSB by the UE 3 (and hence associated beam) for an attempted CFRA procedure to recover from beam failure.

[0137] The beam failure recovery configuration may also include a parameter that specifies the number of SSBs that are associated with a single RO (e.g., an 'ssb-perRACH-Occasion' IE or the like). The parameter, in the beam failure recovery configuration, specifying the number of SSBs that are associated with a single RO may have an assigned value that is a proper fraction, e.g., 1 / 8, 1 / 4, or 1 / 2 , to indicate that more than one RO is associated with a single SSB, or may have an assigned value that is an integer, e.g., 1, 2, 4, 8, or 16, to indicate that more than one SSB is associated with a single RO.

[0138] An indication of one or more ROs, associated with an SSB, in which the UE 3 (e.g., a MAC entity of the UE 3) may transmit a (P)RACH preamble (e.g., using a 'ra-ssb-OccasionMaskIndex' IE or the like) may also be provided in the beam failure recovery configuration.

[0139] The beam failure recovery configuration may also include a list of information for a set of reference signals (CSI-RS and / or SSB) corresponding to the candidate beams for recovery and the associated RA parameters (e.g., in a 'candidateBeamRSList,' IE or the like).

[0140] The list of information for the set of reference signals may include information which effectively allocates one or more dedicated (P)RACH preambles to the UE 3 (e.g., using a 'PRACH-ResourceDedicatedBFR' IE or the like). The RAN node 5 may use this information to indicate one or more dedicated preambles for one or more SSB beams and / or to indicate one or more dedicated preambles for one or more CSI-RS beams.

[0141] The information that indicates one or more dedicated preambles for one or more SSB beams may, for example, comprise a list of information for one or more SSBs associated with one or more candidate beams for beam failure recovery. The list may include, for each SSB respectively: an identifier of the SSB (e.g., an SSB index / ID); and a random-access preamble index (e.g., in a 'ra-PreambleIndex' IE) of the preamble that the UE 3 should use when attempting CFRA for beam failure recovery upon selecting a candidate beam identified by the SSB index.

[0142] The information that indicates one or more dedicated preambles for one or more CSI-RS beams may, for example, comprise a list of information for one or more CSI-RS resources (each associated with a corresponding candidate CSI-RS beam for beam failure recovery). The list may include, for each CSI-RS resource respectively: an identifier of the CSI-RS resource (e.g., a CSI-RS index / ID of a non-zero-power (NZP) CSI-RS resource configured in a CSI measurement configuration associated with the serving cell and configured to the UE 3 previously, e.g., using RRC signalling); an indication of one or more (P)RACH occasions (e.g., an 'ra-OccasionList' IE or the like) that a UE 3 (e.g., a MAC entity of the UE 3) may use for random-access preamble transmission when performing CFRA for beam failure recovery upon selecting a candidate beam identified by the CSI-RS ID; and a random-access preamble index (e.g., in a 'ra-PreambleIndex' IE) of a preamble that the UE 3 should use in the (P)RACH occasions associated with the CSI-RS ID.

[0143] <Additional, Feature-Specific, (P)RACH Configuration:> 　　The communication system 1 also supports the possibility of the RAN node 5 providing a list one or more 'additional' (P)RACH configurations. For example, as seen in Fig. 3, the list may be provided using an 'AdditionalRACH-ConfigList' IE 314 including one of more 'AdditionalRACH-Config' IEs 316, or the like, as part of the uplink configuration information described above (e.g., in the system information (e.g., SIB1) and / or in the RRC message for (re)configuring / modifying an RRC connection at the UE (e.g., an RRCReconfiguration message or the like)).

[0144] Each additional (P)RACH configuration may, for example, respectively represent a feature (or feature-combination) specific common (P)RACH configuration (e.g., configured by a further 'RACH-ConfigCommon' IE 310b), for UEs that support that feature or feature-combination) in addition to a standard or general common (P)RACH resource configuration (e.g., configured by the first RACH-ConfigCommon IE 310a) for UEs more generally as described above.

[0145] The features (or feature-combinations) that may be provided with a corresponding feature (or feature-combination) specific common (P)RACH configuration include, for example a respective feature or (feature-combination) associated with: -　　reduced capability (RedCap) operation; -　　small data transmission; -　　repetition of Msg1; -　　repetition of Msg3; -　　one or more specified network slice access stratum group (NSAGs); and / or -　　enhanced reduced capability (eRedCap) operation.

[0146] The feature (or feature-combination) specific common (P)RACH configuration may include a similar (or the same) set of random-access parameters as the standard or common (P)RACH resource configuration including, for example, those provided by the generic set of random-access parameters described above. However, the parameters of each feature (or feature-combination) specific common (P)RACH configuration may include information indicating one or more sets of one or more feature (or feature-combination) specific preambles (e.g., a list of one or more 'FeatureCombinationPreambles' IEs or the like as indicated at 420 in Fig. 4). It will be appreciated that whilst the information indicating one or more sets of one or more feature (or feature-combination) specific preambles is particularly applicable in the context of common (P)RACH configuration information (e.g., a further RACH-ConfigCommon IE 310b in Figs. 3 and 4) included as part of one or more 'additional' (P)RACH configurations (e.g., AdditionalRACH-Config IEs 316), this does not preclude the presence of such information indicating one or more sets of one or more feature (or feature-combination) specific preambles (e.g., a list of one or more 'FeatureCombinationPreambles' IEs 420) being present in as part of a general (e.g., non feature (or feature-combination)) common (P)RACH resource configuration (e.g., configured by the first RACH-ConfigCommon IE 310a in Figs. 3 and 4).

[0147] Each indicated set of one or more feature (or feature-combination) specific preambles may, for example, be associated with one or more feature (or feature-combination) specific (P)RACH parameters. The feature (or feature-combination) specific (P)RACH parameters may include, for example, an indication of a reference signal received power (RSRP) threshold (e.g., a 'rsrp-ThresholdSSB' IE or the like) and / or a subset of ROs where preambles are allocated for this feature (or feature combination).

[0148] Accordingly, in this way, a UE 3 can be configured with multiple (P)RACH configurations (e.g., by including a first RACH-ConfigCommon IE 310a and an additionalRACH-ConfigList IE including one or more further RACH-ConfigCommon IEs 310b within the common uplink configuration information. Each common (P)RACH configuration (e.g., first RACH-ConfigCommon IE 310a) effectively defines (P)RACH resources which can be used by different features.

[0149] <RACH resource selection:> 　　The UE 3 is configured to select the (P)RACH resources (RO and / or preamble) to use for a (P)RACH based procedure based on a number of factors.

[0150] The UE 3 initially identifies / selects an appropriate (P)RACH resource set from which to select the (P)RACH resources.

[0151] For example, where both a common (P)RACH configuration and one or more additional common (P)RACH configurations have been configured, (e.g., respectively by a standard / general RACH-ConfigCommon IE 310a and one or more AdditionalRACH-Config IEs) the UE 3 may be configured to select the (P)RACH resource set (from which to select corresponding (P)RACH resources) corresponding to the feature (or feature-combination) for which (P)RACH was initiated. For example, for initial access a (P)RACH resource set may be selected based on the standard / general common (P)RACH configuration. Contrastingly, for small data transmission, a (P)RACH resource set may be selected based on the additional common (P)RACH configuration corresponding to the feature (or feature-combination) associated with small data transmission.

[0152] Similarly, for an SI request, a UE 3 may select an appropriate set of (P)RACH resources based on the corresponding (P)RACH related parameters of an SI request configuration (e.g., of an 'SI-RequestConfig' IE or the like).

[0153] Similarly, for beam failure recovery, a UE 3 may select an appropriate set of (P)RACH resources based on the corresponding (P)RACH related parameters of a beam failure recovery configuration (e.g., of a 'BeamFailureRecoveryConfig' IE or the like).

[0154] Similarly, for reconfiguration with synchronisation, a UE 3 may select an appropriate set of (P)RACH resources based on the corresponding (P)RACH related parameters of a reconfiguration with synchronisation (e.g., of a 'ReconfigurationWithSync' IE or the like).

[0155] Where appropriate, the UE 3 may identify / select an appropriate beam (SSB based and / or CSI-RS based) and corresponding (P)RACH preamble for initiating a (P)RACH procedure. For example, if the (P)RACH procedure is triggered by a PDCCH order, the PDCCH order may provide a preamble index and an SSB to be used for the random access procedure. For other triggers, however, the UE 3 may select an SSB / CSI-RS which exhibits a measured signal strength (e.g., RSRP) what meets a corresponding signal strength threshold requirement indicated by the RAN node 5 (e.g., via an rsrp-ThresholdSSB IE / rsrp-ThresholdCSI-RS IE) as described above.

[0156] Then, based on the identified / selected SSB / CSI-RS resource, the UE 3 selects an RO which is mapped to the selected SSB / CSI-RS resource (the mapping between SSB / CSI-RS and available ROs being configured by RRC signalling and / or system information as described above).

[0157] For example, when a (P)RACH procedure is to be initiated for an SI request, RO selection may involve determining a next available RO from one or more ROs corresponding to a selected SSB in an association period indicated by the SI request configuration (e.g., by an 'ra-AssociationPeriodIndex' IE or the like), within an indicated SI request period (e.g., indicated by a 'si-RequestPeriod' IE or the like), subject to any restrictions on the ROs associated with that SSB, (e.g., indicated by a 'ra-ssb-OccasionMaskIndex' IE or the like (if configured)).

[0158] In other cases, RO selection may involve determining a next available RO from one or more ROs corresponding to an identified / selected SSB / CSI-RS subject to any restrictions on the ROs associated with that SSB / CSI-RS (e.g., indicated by a 'ra-ssb-OccasionMaskIndex' IE or the like (if configured)). The UE 3 (e.g., a MAC entity of the UE 3) may then select an actual RO to use randomly (and with equal probability) from among a set of consecutive ROs, starting with the next available RO, corresponding to a selected SSB.

[0159] For a (P)RACH transmission triggered by a PDCCH order, however, a (P)RACH mask index field provided as part of the PDCCH order (e.g., as part of DCI provided using DCI format 1_0) may indicate one or more ROs for the (P)RACH preamble transmission, where the ROs are associated with an SSB index indicated by an SSB index field of that PDCCH order (e.g., a field of the DCI provided using DCI format 1_0). By way of example only, a list of possible (P)RACH Mask Index values and associated meaning is provided in Table 5 below.

[0160] <(P)RACH adaptation> 　　Beneficially, as described in more detail later, each UE 3 and RAN node 5 of the communication system 1 may be mutually configured to implement one or more enhanced techniques or procedures for supporting provision of an indication of whether additional (P)RACH resources configured for the purposes of (P)RACH adaptation are activated or not activated. For the purposes of description this indication will be referred to as a '(P)RACH adaptation indication' but it will be appreciated that it may be given any suitable name.

[0161] The enhanced techniques / procedures may include, for example, one or more procedures for indicating that all, or a subset of, additional (P)RACH resources configured by one or more additional (P)RACH resource configurations are activated or not activated.

[0162] For example, each UE 3 and RAN node 5 of the communication system 1 may be configured to use DCI (e.g., using DCI format 1_0 scrambled using P-RNTI) for the purposes of activating (or deactivating) all, or a subset of, additional (P)RACH resources for the purposes of (P)RACH adaptation. Using DCI format 1_0 scrambled using P-RNTI allows the RAN node 5 to control the number of (P)RACH resources based, for example, on paging load. For example, if paging load is high, then the RAN node 5 may decide to activate additional (P)RACH resources configured for (P)RACH adaptation. Moreover, the RAN node 5 can potentially indicate the availability of additional resources (e.g., within the paging message itself) so that UEs 3 which need to perform a (P)RACH transmission can, if needed, use the additional resources.

[0163] Moreover, as described in more detail later, the enhanced techniques / procedures may beneficially include, for example, one or more techniques for determining the ongoing validity of such additional (P)RACH resources configured for (P)RACH adaptation (e.g., that have been activated by a (P)RACH adaptation indication as mentioned above). For example, a UE 3 may be configured to support one or more techniques for determining: a duration (e.g., a 'validity' duration / time) for which activated additional (P)RACH resources should be treated as remaining active; the timing at which the additional (P)RACH resources should be treated as becoming active / valid (e.g., a 'validity' start time or the like); and / or the timing at which activated additional (P)RACH resources should be treated as becoming inactive / invalid (e.g., a 'validity' end time or the like).

[0164] Beneficially, as described in more detail later, the enhanced techniques / procedures may beneficially include, for example, one or more techniques for handling a later (P)RACH adaptation indication while the (P)RACH resources activated by an earlier (P)RACH adaptation indication are still considered valid / active.

[0165] It will be appreciated that the use of whilst the DCI format 1_0 scrambled with P-RNTI is particularly applicable to a use case in which paging causes a UE 3 to trigger a (P)RACH procedure. Beneficially, as described in more detail later, each UE 3 and RAN node 5 of the communication system 1 may be configured to support one or more mechanisms for providing a (P)RACH adaptation indication that are tailored to other scenarios in which a UE 3 may needs to trigger a (P)RACH procedure.

[0166] Beneficially, as described in more detail later, the enhanced techniques / procedures may beneficially include, for example, one or more techniques for supporting configuration additional (P)RACH resources for (P)RACH adaptation for different features, or feature combinations.

[0167] Beneficially, as described in more detail later, the enhanced techniques / procedures may beneficially include, for example, one or more techniques for supporting the configuration additional (P)RACH resources differently for different SSBs thereby enabling a different distribution of (P)RACH resources per SSB.

[0168] < Content of (P)RACH Adaptation Indication> 　　As mentioned above, the communication system 1 may implement one or more enhancements for indicating that all, or a subset of, additional (P)RACH resources configured by one or more additional (P)RACH resource configurations are activated or not activated.

[0169] A number of possible such enhancements will now be described, by way of example only, with reference to Figs. 6 to 8.

[0170] Fig. 6 is a simplified sequence diagram illustrating a method of facilitating (P)RACH adaptation in the communication system 1.

[0171] As seen in Fig. 6, one or more additional (P)RACH resource configurations may be configured at a UE 3 for (P)RACH adaptation purposes at S610. Each such additional (P)RACH resource configuration may, for example, be respectively defined by an additional common (P)RACH configuration IE (e.g., a RACH-ConfigCommon IE or the like) and / or generic (P)RACH configuration IE (e.g., a RACH-ConfigGeneric IE or the like). Nevertheless, the additional (P)RACH resource configuration or configurations may, for example, be defined in a single generic (P)RACH configuration IE (e.g., a RACH-ConfigGeneric IE or the like) which is partitioned into a different respective set of parameters defining the (P)RACH resources corresponding to each additional (P)RACH resource configuration. The additional (P)RACH resource configuration or configurations may, for example, be provided by semi-static signalling (e.g., via RRC signalling or the like) together with (or separate to) the general (P)RACH configurations described in more detail above with reference to Figs. 3 to 5.

[0172] When (P)RACH adaptation is required, the RAN node 5 sends, to the UE 3 at S612, DCI including a (P)RACH adaptation indication using an appropriate DCI format masked / scrambled using an appropriate RNTI (e.g., DCI format 1_0 masked / scrambled with a P-RNTI). The (P)RACH adaptation includes information indicating whether the additional (P)RACH resources configured for the purposes of adaptation are activated or not activated. This may be sent, for example, to activate currently inactive additional (P)RACH resources or to deactivate currently active additional (P)RACH resources.

[0173] Nevertheless, whilst such an indication may be used for activating / deactivating an entire set of additional (P)RACH resources (e.g. all the additional (P)RACH occasions) that have been configured it may be beneficial to be able to selectively activate (and / or deactivate) a subset of the additional (P)RACH resources.

[0174] Fig. 7 is a simplified sequence diagram illustrating another method of facilitating (P)RACH adaptation in the communication system 1. In this method, the (P)RACH indication is used to provide information indicating which of a plurality of (P)RACH configurations (and hence the respective (P)RACH occasions configured by each indicated (P)RACH configuration) may be treated as active / available.

[0175] As with the method of Fig. 6, in this example, one or more additional (P)RACH resource configurations may be configured at a UE 3 for (P)RACH adaptation purposes at S710. Each such additional (P)RACH resource configuration may, for example, be respectively defined by an additional common (P)RACH configuration IE (e.g., a RACH-ConfigCommon IE or the like) and / or generic (P)RACH configuration IE (e.g., a RACH-ConfigGeneric IE or the like). Nevertheless, the additional (P)RACH resource configuration or configurations may, for example, be defined in a single generic (P)RACH configuration IE (e.g., a RACH-ConfigGeneric IE or the like) which is partitioned into a different respective set of parameters defining the (P)RACH resources corresponding to each additional (P)RACH resource configuration. The additional (P)RACH resource configuration or configurations may, for example, be provided by semi-static signalling (e.g., via RRC signalling or the like) together with (or separate to) the general (P)RACH configurations described in more detail above with reference to Figs. 3 to 5.

[0176] In this example, in a case where a plurality of additional (P)RACH resource configurations are provided for (P)RACH adaptation purposes at S710, when (P)RACH adaptation is required, the (P)RACH adaptation indication provided by the RAN node 5 may include information to indicate which of the additional (P)RACH resource configurations can be treated as activate (and / or inactive).

[0177] Specifically, the RAN node 5 may send, at S712, DCI including the (P)RACH adaptation indication using an appropriate DCI format masked / scrambled using an appropriate RNTI (e.g., DCI format 1_0 masked / scrambled with a P-RNTI). The (P)RACH adaptation indication in this example may include (or be provided together with) information indicating one or more (P)RACH resource configurations which is to be activated and / or an indication of one or more (P)RACH resource configurations which is not to be activated (or is to be deactivated).

[0178] Fig. 8 is a simplified sequence diagram illustrating another method of facilitating (P)RACH adaptation in the communication system 1. In this method, the (P)RACH indication is used to provide information explicitly indicating which of the (P)RACH occasions configured by one or more additional (P)RACH configurations for the purposes of adaptation may be treated as active / available.

[0179] As with the method of Fig. 6, in this example, one or more additional (P)RACH resource configurations may be configured at a UE 3 for (P)RACH adaptation purposes at S810. Each such additional (P)RACH resource configuration may, for example, be respectively defined by an additional common (P)RACH configuration IE (e.g., a RACH-ConfigCommon IE or the like) and / or generic (P)RACH configuration IE (e.g., a RACH-ConfigGeneric IE or the like). Nevertheless, the additional (P)RACH resource configuration or configurations may, for example, be defined in a single generic (P)RACH configuration IE (e.g., a RACH-ConfigGeneric IE or the like) which is partitioned into a different respective set of parameters defining the (P)RACH resources corresponding to each additional (P)RACH resource configuration. The additional (P)RACH resource configuration or configurations may, for example, be provided by semi-static signalling (e.g., via RRC signalling or the like) together with (or separate to) the general (P)RACH configurations described in more detail above with reference to Figs. 3 to 5.

[0180] In this example, when (P)RACH adaptation is required, the (P)RACH adaptation indication provided by the RAN node 5 may include information to indicate which of the additional (P)RACH occasions can be treated as activate (and / or inactive).

[0181] Specifically, the UE 3 may send, at S712, DCI including the (P)RACH adaptation indication using an appropriate DCI format masked / scrambled using an appropriate RNTI (e.g., DCI format 1_0 masked / scrambled with a P-RNTI). The (P)RACH adaptation indication in this example may include (or be provided together with) information indicating one or more (P)RACH occasions which is to be activated and / or an indication of one or more (P)RACH occasions which is not to be activated (or is to be deactivated).

[0182] In this example, the information indicating one or more (P)RACH occasions which is to be activated or deactivated may, for example, be in the form of an index value.

[0183] The index value may, for example, map to a corresponding (pre)configured (P)RACH occasion mask index representing a 'mask' that can be applied to the configured (P)RACH occasions to identify those (P)RACH occasions that are to be treated as active or inactive. Specifically, the index value may be one of a plurality of different possible index values where each possible index value points to a different respective (P)RACH occasion mask that represents a different corresponding pattern of active (and inactive) (P)RACH occasions.

[0184] Alternatively, the index value may, for example, map to a specific set of (P)RACH occasions for activation (or deactivation) that has been previously configured by the RAN node 5 using appropriate (e.g., RRC) signalling. Specifically, the index value may be one of a plurality of different possible index values, where each possible index value points to a different respective set of (P)RACH occasions configured by the RAN node 5 using appropriate (e.g., RRC) signalling.

[0185] It will be appreciated that, notwithstanding the specific examples described above, the available / active (or unavailable / inactive) additional (P)RACH resources may be indicated at any appropriate level of granularity - for example at a (P)RACH occasion per SSB level, an SSB to RO mapping cycle level, a (P)RACH configuration period level, and / or the like.

[0186] It will be appreciated that whilst a number of different methods of facilitating (P)RACH adaptation are described above with reference to Figs. 6 to 8 the methods are neither mutually exclusive nor mutually dependent on one another. For example, a given RAN node 5 and / or UE 3 may be configured to support all or a subset of the different types of (P)RACH adaptation indications described with reference to Figs. 6 to 8 and to use them (or be configured to use them) in different scenarios - for example based on load considerations, the ned for additional (P)RACH resources and / or the like.

[0187] <Determining Additional (P)RACH Resource Validity> 　　As mentioned above, the communication system 1 may implement one or more enhancements for determining the ongoing validity of such additional (P)RACH resources configured for (P)RACH adaptation (e.g., that have been activated via a (P)RACH adaptation indication as described above with reference to Figs. 6 to 8).

[0188] <Additional (P)RACH Resource Validity Duration:> 　　For example, once a (P)RACH indication is received, the additional (P)RACH resources (which are activated by the indication) may be considered active by the UE for a specific period of time or 'validity' duration.

[0189] A number of different ways in which such a 'validity' duration may be supported will now be described, by way of example only, with reference to Figs. 9 to 11.

[0190] Fig. 9 is a simplified sequence diagram illustrating a method of facilitating a duration limited (P)RACH adaptation in the communication system 1.

[0191] In the example of Fig. 9, a preconfigured validity duration is provided at the UE 3 as seen at S900. The preconfigured validity duration may be predefined at the UE 3 when it is initially setup, or may preconfigured via an earlier update or signalling from the network.

[0192] At an appropriate juncture, one or more additional (P)RACH resource configurations may be configured at a UE 3 for (P)RACH adaptation purposes as seen at S910. Each (P)RACH resource configuration may be provided, for example, in the manner described with reference to any of Figs 6 to 8.

[0193] Then, when (P)RACH adaptation is required, the RAN node 5 sends, to the UE 3 at S912, DCI including a (P)RACH adaptation indication using an appropriate DCI format masked / scrambled using an appropriate RNTI (e.g., DCI format 1_0 masked / scrambled with a P-RNTI). The (P)RACH adaptation indication may, for example, correspond to the (P)RACH adaptation indication described with reference to any of Figs 6 to 8.

[0194] At S914, when additional (P)RACH resources (e.g., (P)RACH occasions) configured at S910 are activated in accordance with corresponding information provided in (or together with) the (P)RACH adaptation indication, the activated additional (P)RACH resources (e.g., (P)RACH occasions) are then treated as active for the preconfigured validity duration. After expiry of the preconfigured validity duration the activated additional (P)RACH resources (e.g., (P)RACH occasions) may then be treated as inactive / invalid.

[0195] Fig. 10 is a simplified sequence diagram illustrating another method for facilitating a duration limited (P)RACH adaptation in the communication system 1.

[0196] In the example of Fig. 10, at an appropriate juncture, one or more additional (P)RACH resource configurations may be configured at a UE 3 for (P)RACH adaptation purposes as seen at S1010. Each additional (P)RACH resource configuration may be provided, for example, in the manner described with reference to any of Figs 6 to 8. In this example, however, the additional (P)RACH resource configuration or configurations may include (or be provided together with) information indicating one or more validity durations - for example a respective dedicated validity duration associated with each additional (P)RACH resource configuration, or a common / shared validity duration that may be associated with all (or a subset of two or more) additional (P)RACH resource configurations).

[0197] A given validity duration provided by / with the (P)RACH configuration or configurations may, for example, comprise an index that maps / points to one of a plurality of different possible (pre)configured duration values.

[0198] Then, when (P)RACH adaptation is required, the RAN node 5 sends, to the UE 3 at S1012, DCI including a (P)RACH adaptation indication using an appropriate DCI format masked / scrambled using an appropriate RNTI (e.g., DCI format 1_0 masked / scrambled with a P-RNTI). The (P)RACH adaptation indication may, for example, correspond to the (P)RACH adaptation indication described with reference to any of Figs 6 to 8.

[0199] At S1014, when additional (P)RACH resources (e.g., (P)RACH occasions) configured at S1010 are activated in accordance with corresponding information provided in (or together with) the (P)RACH adaptation indication, the activated additional (P)RACH resources (e.g., (P)RACH occasions) are then treated as active for the (corresponding) validity duration configured with the additional (P)RACH resource configuration or configurations. After expiry of the (corresponding) validity duration the activated additional (P)RACH resources (e.g., (P)RACH occasions) may then be treated as inactive / invalid.

[0200] Fig. 11 is a simplified sequence diagram illustrating another method for facilitating a duration limited (P)RACH adaptation in the communication system 1.

[0201] In the example of Fig. 11, at an appropriate juncture, one or more additional (P)RACH resource configurations may be configured at a UE 3 for (P)RACH adaptation purposes as seen at S1010. Each additional (P)RACH resource configuration may be provided, for example, in the manner described with reference to any of Figs 6 to 8.

[0202] Then, when (P)RACH adaptation is required, the RAN node 5 sends, to the UE 3 at S1112, DCI including a (P)RACH adaptation indication using an appropriate DCI format masked / scrambled using an appropriate RNTI (e.g., DCI format 1_0 masked / scrambled with a P-RNTI). The (P)RACH adaptation indication may, for example, correspond to the (P)RACH adaptation indication described with reference to any of Figs 6 to 8. In this example, however, the (P)RACH adaptation indication may include (or be provided together with) information indicating one or more validity durations - for example a respective dedicated validity duration associated with each additional (P)RACH resource configuration (or each (sub)set of (P)RACH occasions) to be activated, or a common / shared validity duration that may be associated with all (or a subset of) additional (P)RACH resource configurations / (P)RACH occasions.

[0203] A given validity duration provided by / with the (P)RACH adaptation indication may, for example, comprise an index that maps / points to one of a plurality of different possible (pre)configured duration values.

[0204] At S1114, when additional (P)RACH resources (e.g., (P)RACH occasions) configured at S1110 are activated in accordance with corresponding information provided in (or together with) the (P)RACH adaptation indication, the activated additional (P)RACH resources (e.g., (P)RACH occasions) are then treated as active for the (corresponding) validity duration configured by / with the (P)RACH adaptation indication. After expiry of the (corresponding) validity duration the activated additional (P)RACH resources (e.g., (P)RACH occasions) may then be treated as inactive / invalid.

[0205] It will be appreciated that in any of the different methods of facilitating duration limited (P)RACH adaptation that are described above with reference to Figs. 9 to 11, the validity duration may be indicated / measured using any appropriate units for example: an absolute time unit (e.g., ms, slots, or symbols); a duration of a (P)RACH configuration period; a duration of a single SSB-to-RO mapping cycle; a duration of a single (P)RACH association period; a duration of a single (P)RACH association pattern period; or the like.

[0206] It will also be appreciated that whilst a number of different methods of facilitating duration limited (P)RACH adaptation are described above with reference to Figs. 9 to 11 the methods are neither mutually exclusive nor mutually dependent on one another. For example, a given RAN node 5 and / or UE 3 may be configured to support all or a subset of the different methods of facilitating duration limited (P)RACH adaptation described with reference to Figs. 9 to 11 and to use them (or be configured to use them) in different scenarios.

[0207] As mentioned above, the UE 3 may be configured to support one or more techniques for determining the timing at which the additional (P)RACH resources should be treated as becoming active / valid (e.g., a 'validity' start time or the like), and / or the timing at which activated additional (P)RACH resources should be treated as becoming inactive / invalid (e.g., a 'validity' end time or the like).

[0208] < Additional (P)RACH Resource Activation Determination> 　　For example, upon receiving a (P)RACH adaptation indication as described above with reference to any of Figs. 6 to 11, the UE 3 may be configured to treat the additional (P)RACH resources (e.g., (P)RACH occasions) which have been indicated to be active by the (P)RACH adaptation to be active from a given time instance.

[0209] For example, the UE 3 may be configured to treat the additional (P)RACH resources (e.g., (P)RACH occasions) which have been indicated to be active by the (P)RACH adaptation to be active from a time instance corresponding to the (start of, or end of, the) symbol / slot in which the UE receives the (P)RACH adaptation indication (Tind) plus a time (duration) required for that UE to process the (P)RACH adaptation indication (Tprocess) - i.e., Tind+ Tprocess.

[0210] An example of such an activation time is illustrated at S1214-1(a) in Fig. 12A which is a simplified illustration of one possible additional (P)RACH resource activation timing that may occur in the communication system 1.

[0211] Nevertheless, the UE 3 may be configured to treat the additional (P)RACH resources (e.g., (P)RACH occasions) which have been indicated to be active by the (P)RACH adaptation to be active from some specific time occasion that occurs after, but is defined relative to, the time instance corresponding to the symbol / slot in which the UE receives the (P)RACH adaptation indication (Tind) plus a time (duration) required for that UE to process the (P)RACH adaptation indication (Tprocess) - i.e., some time occasion that is defined relative to after Tind+ Tprocess.

[0212] An example of such an activation time is illustrated at S1214-1(b) in Fig. 12B which is a simplified illustration of one possible additional (P)RACH resource activation timing that may occur in the communication system 1.

[0213] For example, the UE 3 may be configured to treat the additional (P)RACH resources (e.g., (P)RACH occasions) which have been indicated to be active by the (P)RACH adaptation to be active from a time occasion corresponding to the first (valid) additional (P)RACH resource which occurs after Tind+ Tprocess.

[0214] Alternatively, the UE 3 may be configured to treat the additional (P)RACH resources (e.g., (P)RACH occasions) which have been indicated to be active by the (P)RACH adaptation to be active from a time occasion corresponding to the start of the SSB-to-RO mapping cycle of the additional (P)RACH resources which occurs after Tind+ Tprocess.

[0215] Alternatively, the UE 3 may be configured to treat the additional (P)RACH resources (e.g., (P)RACH occasions) which have been indicated to be active by the (P)RACH adaptation to be active from a time occasion corresponding to the start of a (P)RACH association period of the additional (P)RACH resources which occurs after Tind+ Tprocess.

[0216] Alternatively, the UE 3 may be configured to treat the additional (P)RACH resources (e.g., (P)RACH occasions) which have been indicated to be active by the (P)RACH adaptation to be active from a time occasion corresponding to the start of a (P)RACH association pattern period of the additional (P)RACH resources which occurs after Tind+ Tprocess.

[0217] It will be appreciated that in the above examples, the time (duration) required for that UE to process the (P)RACH adaptation indication (Tprocess) may have a value that is (pre)configured at the UE 3.

[0218] <Additional (P)RACH Resource Deactivation Determination:> 　　The UE 3 may be configured to treat the additional (P)RACH resources (e.g., (P)RACH occasions) which have been indicated to be active by the (P)RACH adaptation to become inactive / invalid from another given time instance.

[0219] For example, the UE 3 may be configured to treat the additional (P)RACH resources (e.g., (P)RACH occasions) which have been indicated to be active by the (P)RACH adaptation as becoming active from a time instance corresponding to a start time (Tstart) at which those additional (P)RACH resources (e.g., (P)RACH occasions) were considered active plus a validity time / duration of the additional (P)RACH resources (Tduration) - i.e., Tstart+ Tduration. The start time (Tstart) may, for example, correspond to the symbol / slot at which the UE 3 treated those additional (P)RACH resources as being valid / active (e.g., in accordance with any of the techniques described above in which the activation time is the time instance corresponding to Tind+ Tprocessor some specific occasion defined relative to such a time instance). For example, the validity time / duration of the additional (P)RACH resources (Tduration) may be (but does not have to be) a validity time / duration configured (or preconfigured) in the manner described with reference to any of Figs. 9 to 11.

[0220] An example of such a deactivation / inactive / invalid time is illustrated at S1214-2(b) in Fig. 12B in which the additional (P)RACH resources are seen to be treated as being deactivated / inactive / invalid a validity time / duration (Tduration) after the additional (P)RACH resources were treated as being activated (at S1214-1(b)).

[0221] Nevertheless, the UE 3 may be configured to treat activated additional (P)RACH resources (e.g., (P)RACH occasions) as becoming active at some specific time occasion that occurs after, but is defined relative to, the (start of, or end of, the) symbol / slot from which the UE 3 treated those additional (P)RACH resources as becoming valid / active (i.e., the start time (Tstart)) plus the validity time / duration of the additional (P)RACH resources (Tduration) - i.e., some time occasion defined relative to Tstart+ Tduration.

[0222] An example of such a deactivation / inactive / invalid time is illustrated at S1214-2(a) in Fig. 12A in which the additional (P)RACH resources are seen to be treated as being deactivated / inactive / invalid some time after the validity time / duration (Tduration) has expired (i.e., after the time instance corresponding to Tstart+Tduration).

[0223] For example, the UE 3 may be configured to treat the additional (P)RACH resources (e.g., (P)RACH occasions) to be inactive / invalid from (after) the (the start or, or end of, the) end / last (or start) symbol of the additional (P)RACH resource which occurs after the validity time / duration (Tduration) has expired (i.e., after the time instance corresponding to Tstart+Tduration).

[0224] Alternatively, the UE 3 may be configured to treat the additional (P)RACH resources (e.g., (P)RACH occasions) to be inactive / invalid from the end (or start) symbol of the last (or first) (P)RACH resource of the SSB-to-RO mapping cycle which occurs after the validity time / duration (Tduration) has expired (i.e., after the time instance corresponding to Tstart+Tduration).

[0225] Alternatively, the UE 3 may be configured to treat the additional (P)RACH resources (e.g., (P)RACH occasions) to be inactive / invalid from the end (or start) symbol of the last (or first) (P)RACH resource of the (P)RACH association period which occurs after the validity time / duration (Tduration) has expired (i.e., after the time instance corresponding to Tstart+Tduration).

[0226] Alternatively, the UE 3 may be configured to treat the additional (P)RACH resources (e.g., (P)RACH occasions) to be inactive / invalid from the end (or start) symbol of the last (or first) (P)RACH resource of the (P)RACH association pattern period which occurs after the validity time / duration (Tduration) has expired (i.e., after the time instance corresponding to Tstart+Tduration).

[0227] In Figs 12(a) and 12(b), the validity time / duration (Tduration) is shown as being twice the (P)RACH configuration period for illustrative purposes. Nevertheless, the validity time / duration (Tduration) may be any suitable value.

[0228] <Time Overlapping Additional (P)RACH Resource Indications:> 　　As mentioned above, the enhanced techniques / procedures may beneficially include one or more techniques for handling a later (P)RACH adaptation indication while the (P)RACH resources activated by an earlier (P)RACH adaptation indication are still considered valid / active.

[0229] For example, in a case where a UE 3 receives another (P)RACH adaptation indication while (P)RACH resources indicated by a previous (e.g., the last / most recent) (P)RACH adaptation indication are still active / valid, the UE 3 may be configured to treat the (P)RACH resources activated by the previous (e.g., the last / most recent) (P)RACH adaptation indication becoming inactive / invalid and, instead, to activate the (P)RACH resources indicated by the newly received (P)RACH adaptation indication.

[0230] Alternatively, in a case where a UE 3 receives another (P)RACH adaptation indication while (P)RACH resources indicated by a previous (e.g., the last / most recent) (P)RACH adaptation indication are still active / valid, the UE 3 may be configured to treat both the previously activated and the newly indicated (P)RACH resources as being valid (in accordance with any corresponding validity timing / duration or the like for each of the provided indications).

[0231] <Encoding (P)RACH Adaptation Indication Within DCI> 　　As mentioned above, each UE 3 and RAN node 5 of the communication system 1 may be configured to use DCI with DCI format 1_0 scrambled using P-RNTI for the purposes of providing a (P)RACH adaptation indication and that the (P)RACH adaptation indication may include (or be provided with) an indication of all, or a subset of, additional (P)RACH resources to be activated (or deactivated).

[0232] There are a number of different fields of DCI format 1_0 scrambled using P-RNTI where such a (P)RACH adaptation indication can be provided.

[0233] For example, the reserved bits of a DCI format 1_0 scrambled with P-RNTI may be used. Specifically, one or more of these reserved bits, which are located after the TRS availability indication field, can be used for indicating (P)RACH adaptation. In this example, the number of bits used will be fewer than (or equal to) 6-M (where M is the number of bits for TRS availability indication).

[0234] Alternatively (or additionally), one or more of the bits reserved for the short messages field may be repurposed for providing the (P)RACH adaptation indication. It will be appreciated that the short messages field may be used in combination with another field of DCI format 1_0 (e.g., the reserved bits of DCI format 1_0 scrambled with P-RNTI as mentioned above). For example, one or more reserved bits of the short messages field may be used to indicate an activation status of additional (P)RACH resources. Any remaining information (e.g. identifying which (P)RACH resources are activated) may be provided using another field (e.g., the reserved bits of DCI format 1_0 scrambled with P-RNTI).

[0235] It will be appreciated that the specific fields / bits used for (P)RACH adaptation may be dependent on the value of short message indicator field of DCI format 1_0 scrambled with P-RNTI. For example, where the short message indicator field indicates that a short message and paging are present, then the reserved bits of DCI 1_0 scrambled with P-RNTI may be used for the purposes of (P)RACH adaptation. Where the short message indicator field indicates that only a short message is present then one or more of the fields typically used for resource allocation for the paging message may be repurposed for the purposes of (P)RACH adaptation. Where the short message indicator field indicates that only a paging message is present then the short messages field may be repurposed for the purposes of (P)RACH adaptation.

[0236] It will be appreciated that in the event that the number of bits available in the DCI format 1_0 scrambled with P-RNTI are insufficient for carrying all the information needed for (P)RACH adaptation purposes, then only part of (P)RACH adaptation indication may be sent.

[0237] For example, the RAN node 5 may configure the set of information that may be included within the DCI indication and, when doing so, configure that set of information to ensure that there is sufficient space available in a DCI using the DCI format 1_0 scrambled with P-RNTI to carry the information.

[0238] Alternatively (or additionally), in the event that there are fewer bits available than the number of bits required to indicate both a (P)RACH activation indication and other information (e.g. which (P)RACH resources / occasions are activated), then the (P)RACH adaptation indication may only include a relative (P)RACH activation indication (e.g. using a single bit). On receipt of such a (P)RACH activation indication, the UE 3 may treat all additional (P)RACH resources as having been activated.

[0239] Alternatively (or additionally), in the event that there are fewer bits available than the number of bits required to indicate both a (P)RACH activation indication and other information (e.g. which (P)RACH resources / occasions are activated), then the (P)RACH adaptation indication may include a (P)RACH activation indication (e.g. using single bit value) and a partial subset of the other information. For example, if the other information is a type of bit mask, then the (P)RACH indication may include only a subset of the bits of the bitmask that can be carried in the available space. The UE 3 may then treat the additional (P)RACH resources that are indicated by the partial information to be activated / valid. For the other (P)RACH resources, which are not covered by the partial information provided, the UE 3 may either: treat none of these other (P)RACH resources as valid / having been activated; or all of these other (P)RACH resources as valid / having been activated (in addition to those indicated by the partial information).

[0240] It will be appreciated that either of the different possible scenarios in which there are fewer bits available than the number of bits described above may occur when the available bit space within DCI 1_0 with P-RNTI can change (e.g., as described in above in respect of the example in which the specific fields / bits used for (P)RACH adaptation are dependent on the value of short message indicator field of DCI format 1_0 scrambled with P-RNTI).

[0241] <Indicating (P)RACH Adaptation for Other (P)RACH triggers> 　　As mentioned above, each UE 3 and RAN node 5 of the communication system 1 may be configured to support one or more further mechanisms for providing a (P)RACH adaptation indication that are tailored to other scenarios in which a UE 3 may needs to trigger a (P)RACH procedure.

[0242] The UE 3 and RAN node 5 of the communication system 1 may, for example, be mutually configured to support the provision of a (P)RACH adaptation indication, and possibly any of the other related information described above (e.g., an indication of (P)RACH resources / occasions to be activated / treated as valid), via different DCI signalling. Such different DCI signalling may use a different existing DCI format, a new DCI format, or DCI format 1_0 configured for a different purpose (e.g., by means of an RNTI other than a P-RNTI).

[0243] For example, the UE 3 and RAN node 5 of the communication system 1 may be configured to support provision of a (P)RACH adaptation indication (and possibly other information) using DCI format 1_0 configured for indicating scheduling for an RAR / Msg2 on the PDSCH (i.e., scrambled with an RA-RNTI). Nevertheless, the UE 3 and RAN node 5 of the communication system 1 may alternatively (or additionally) be configured to support provision of a (P)RACH adaptation indication (and possibly other information) using a DCI format 1_0 specifically configured for providing such a (P)RACH adaptation indication (e.g., by scrambling DCI format 1_0 with a new RNTI - e.g., a (P)RACH adaptation RNTI or the like).

[0244] Depending on the DCI used, the UE 3 may be configured to monitor a corresponding search space for the DCI containing a (P)RACH adaptation indication. For example, the UE 3 may be configured: to monitor a search space for RAR reception (where DCI using an RA-RNTI is used); to monitor a search space for paging reception (where DCI using a P-RNTI is used); to monitor a search space that is independently configured to the UE (or a search space for RAR reception) for reception of a (P)RACH adaptation indication DCI (where DCI using a new RNTI - e.g., a (P)RACH adaptation RNTI - is used).

[0245] The UE 3 may then attempt to detect a (P)RACH adaptation indication in a corresponding search space when a (P)RACH procedure is triggered at the UE 3. It will be appreciated that the UE 3 may be configured not to attempt to receive a (P)RACH adaptation indication in the event that the UE 3 has already received an earlier (P)RACH adaptation indication and additional (P)RACH resources are considered activated by the UE 3 in accordance with the earlier (P)RACH adaptation indication. The UE 3 may alternatively (or additionally) be configured not to attempt to receive a (P)RACH adaptation indication in the event that a (P)RACH procedure has completed.

[0246] Moreover, the UE 3 and RAN node 5 of the communication system 1 may alternatively (or additionally) be configured to support provision of a (P)RACH adaptation indication (and possibly other information) using signalling other than a DCI. For example, provision of a (P)RACH adaptation indication (and possibly other information) signalling on the PDSCH may be supported. For example, the UE 3 and RAN node 5 of the communication system 1 may be configured to support provision of a (P)RACH adaptation indication (and possibly other information) using an RAR / Msg2. The UE 3 and RAN node 5 of the communication system 1 may alternatively (or additionally) be configured to support provision of a (P)RACH adaptation indication (and possibly other information) using a paging message (e.g., scheduled by a DCI using DCI format 1_0 scrambled with P-RNTI). The UE 3 and RAN node 5 of the communication system 1 may alternatively (or additionally) be configured to support provision of a (P)RACH adaptation indication (and possibly other information) using independently scheduled signalling on the PDSCH.

[0247] Furthermore, the UE 3 and RAN node 5 of the communication system 1 may alternatively (or additionally) be configured to support provision of a (P)RACH adaptation indication (and possibly other information) within a PDCCH order for initiating a (P)RACH procedure at the UE 3.

[0248] <(P)RACH Configuration - Different Features or Feature Combinations> 　　As mentioned above, each UE 3 and RAN node 5 of the communication system 1 may be configured to support one or more techniques for supporting configuration additional (P)RACH resources for (P)RACH adaptation for different features, or feature combinations.

[0249] The way in which additional (P)RACH resources configured for (P)RACH adaptation may be configured for different features or feature combinations may depend on how the additional (P)RACH resources for adaptation are configured for general (non-feature / feature combination specific) (P)RACH adaptation.

[0250] For example, a first technique may be supported in the communication system 1 for use in a case where the additional (P)RACH resources for adaptation are configured (together with conventional (P)RACH resources) within the common (P)RACH configuration provided (e.g., provided via a modified version of the first RACH-ConfigCommon IE 310a in Figs. 3 and 4).

[0251] In this scenario, the additional (P)RACH resource configuration may be configured to indicate a respective subset of (P)RACH resources reserved for each feature or feature combination. For example, the configuration may indicate which of the (P)RACH occasions (and / or which of the (P)RACH preambles) are reserved for which feature / feature combination.

[0252] It will be appreciated that it is possible that the information indicating one or more sets of one or more feature (or feature-combination) specific preambles (e.g., a list of one or more FeatureCombinationPreambles IEs 420 in Fig. 4) may be reused for this purpose (e.g., as part of the first RACH-ConfigCommon IE 310a in Figs. 3 and 4).

[0253] For example, a separate (additional) information element indicating one or more sets of one or more feature (or feature-combination) specific preambles (e.g., a separate / additional list of one or more FeatureCombinationPreambles IEs similar to that described with reference to Fig. 4) may be provided for additional (P)RACH resources configured for adaptation, together with another information element indicating one or more sets of one or more feature (or feature-combination) specific preambles or conventional (P)RACH resources (e.g., the list of one or more FeatureCombinationPreambles IEs 420 described with reference to Fig. 4).

[0254] Alternatively, the same information element indicating one or more sets of one or more feature (or feature-combination) specific preambles defined for conventional (P)RACH resources (e.g., the list of one or more FeatureCombinationPreambles IEs 420 described with reference to Fig. 4) may also be used for indicating the additional (P)RACH resources applicable for different features or feature combinations associated with (P)RACH adaptation.

[0255] Alternatively (or additionally) a second technique may be supported in the communication system 1 for use in a case where the additional (P)RACH resources for adaptation are configured using an independent common (P)RACH configuration (e.g., provided via one or more additional RACH-ConfigCommon IEs).

[0256] In this scenario, the additional (P)RACH resource configuration may be configured as part of the list one or more 'additional' (P)RACH configurations described with reference to Fig. 3 (e.g., the AdditionalRACH-ConfigList IE 314) in the common uplink configuration, for example as part of the IE defining the common parameters of an uplink bandwidth part (BWP) (e.g., the BWP-UplinkCommon IE 312).

[0257] In this case, the information element indicating one or more sets of one or more feature (or feature-combination) specific preambles defined for conventional (P)RACH resources that may be provided as part of the common (P)RACH configuration information included as part of the 'additional' (P)RACH configuration or configurations described with reference to Figs. 3 and 4 may be reused for indicating the additional (P)RACH resources applicable for different features or feature combinations. For example, the list of one or more FeatureCombinationPreambles IEs 420 provided as part of the further RACH-ConfigCommon IE 310b provided in an AdditionalRACH-Config IE 316 may be used for indicating the additional (P)RACH resources applicable for different features or feature combinations.

[0258] It will be appreciated that an indicator may be provided within the configuration of additional (P)RACH resources which indicates to the UE 3 that these resources are applicable to (P)RACH adaptation so that UE 3 is able to determine that the configured resources are not necessarily always available.

[0259] <(P)RACH Configuration - Different SSBs> 　　As mentioned above, each UE 3 and RAN node 5 of the communication system 1 may be configured to support one or more techniques for supporting the configuration of additional (P)RACH resources differently for different SSBs.

[0260] For example, while the majority of a (P)RACH configuration may remain the same between different SSBs, a subset of the (P)RACH configuration may be respectively configured differently for each SSB (or for different subsets of the SSBs).

[0261] For example, (P)RACH resources within a common (P)RACH configuration (e.g., a modified version RACH-ConfigCommon IE shown in Fig. 4) may be partitioned into different SSBs in one or more different ways. For example, in one technique, a separate respective value of a (P)RACH configuration index may be provided for each of one or more SSBs (and / or for each of one or more subsets of SSBs). Alternatively (or additionally) a separate respective value of a (P)RACH configuration parameter (e.g., 'x' and 'y') may be configured for each of one or more SSBs (and / or for each of one or more subsets of SSBs). Alternatively (or additionally) a separate respective subset of (P)RACHs occasions and / or preambles (e.g., configured by single value of (P)RACH configuration index) may be respectively mapped to each of one or more SSBs (and / or to each of one or more subsets of SSBs).

[0262] It will be appreciated that, within the (P)RACH resources which are configured for one or more SSBs (or one or more subsets of SSBs), the SSB (or SSB subset) to (P)RACHs occasion mapping may be performed independently for a given set of (P)RACH resources. Moreover, a different SSB to (P)RACHs occasion mapping value may be configured for each such group of (P)RACH resources.

[0263] It will also be appreciated that other configuration parameters (e.g., power control parameters and / or the like) may be shared among (common to) all groups of (P)RACH resources.

[0264] <User Equipment> 　　Fig. 13 is a schematic block diagram illustrating the main components of a UE 3 as shown in Fig. 1.

[0265] As shown, the UE 3 has a transceiver circuit 31 that is operable to transmit signals to and to receive signals from a RAN node 5 via one or more antennas 33 (e.g., comprising one or more antenna elements). The UE 3 has a controller 37 to control the operation of the UE 3. The controller 37 is associated with a memory 39 and is coupled to the transceiver circuit 31. Although not necessarily required for its operation, the UE 3 might, 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 and / or the like for, allowing direct control by and interaction with a user) and this may be provided by any one or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in the memory 39 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example.

[0266] The controller 37 is configured to control overall operation of the UE 3 by, in this example, program instructions or software instructions stored within memory 39. As shown, these software instructions include, among other things, an operating system 41, and a communication control module 43.

[0267] The communication control module 43 is operable to control the communication between the UE 3 and its serving RAN node or RAN nodes 5 (and other communication devices connected to the RAN node 5, such as further UEs and / or core network nodes). The communication control module 43 is configured for the overall handling of uplink communication via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), random access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communication control module 43 is also configured for the overall handling of receipt of downlink communication via associated downlink channels (e.g., of DCI via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-persistent scheduling (e.g., SPS). The communication control module 43 is responsible, for example: for determining where to monitor for downlink control information; for determining the resources to be used by the UE 3 for transmission / reception of UL / DL communication (including interleaved resources and resources subject to frequency hopping); for managing frequency hopping at the UE side; for determining how slots / symbols are configured (e.g., for UL, DL or full duplex communication, or the like); for determining which bandwidth parts are configured for the UE 3; for determining how uplink transmissions should be encoded and the like.

[0268] It will be appreciated that the communication control module 43 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communication control module 43 may include a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an RRC sub-module, etc.

[0269] The communication control module 43 is configured, in particular, to control the UE's communication, where applicable, in accordance with any of the methods described herein.

[0270] < RAN node> 　　Fig. 14 is a schematic block diagram illustrating the main components of the RAN node 5 for the communication system 1 shown in Fig. 1. As shown, the RAN node 5 has a transceiver circuit 51 for transmitting signals to and for receiving signals from the communication devices (such as UEs 3) via one or more antennas 53 (e.g. a single or multi-panel antenna array / massive antenna), and a core network interface 55 (e.g. comprising the N2, N3 and other reference points / interfaces) for transmitting signals to and for receiving signals from network nodes in the core network 7. Although not shown, the RAN node 5 may also be coupled to other RAN nodes 5 via an appropriate interface (e.g. the so-called 'Xn' interface in NR). The RAN node 5 has a controller 57 to control the operation of the RAN node 5. The controller 57 is associated with a memory 59. Software may be pre-installed in the memory 59 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The controller 57 is configured to control the overall operation of the RAN node 5 by, in this example, program instructions or software instructions stored within memory 59.

[0271] As shown, these software instructions include, among other things, an operating system 61, and a communication control module 63.

[0272] The communication control module 63 is operable to control the communication between the RAN node 5 and UEs 3 and other network entities that are connected to the RAN node 5. The communication control module 63 is configured for the overall control of the reception and decoding of uplink communication, via associated uplink channels (e.g. via a physical uplink control channel (PUCCH), a random-access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communication control module 63 is also configured for the overall handling the transmission of downlink communication via associated downlink channels (e.g. via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-static signalling (e.g., CSI-RS, SSBs etc.). The communication control module 63 is also responsible, for example, for determining and scheduling the resources to be used by the UE 3 for receiving in DL / transmitting in UL, for configuring slots / symbols appropriately (e.g., for UL, DL, flexible, full duplex communication, or the like), for configuring one or more bandwidth parts for the UE 3, and for providing related configuration signalling to the UE 3.

[0273] It will be appreciated that the communication control module 63 may include a number of sub-modules (or 'layers') to support specific functionalities. 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.

[0274] The communication control module 63 is configured, in particular, to control the RAN node's communication, where applicable, in accordance with any of the methods described herein.

[0275] <Modifications and Alternatives> 　　A detailed example has been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above examples whilst still benefiting from the innovations embodied therein.

[0276] It will be appreciated, for example, that whilst cellular communication generation (2G, 3G, 4G, 5G, 6G etc.) specific terminology may be used, in the interests of clarity, to refer to specific communication entities, the technical features described for a given entity are not limited to devices of that specific communication generation. The technical features may be implemented in any functionally equivalent communication entity regardless of any differences in the terminology used to refer to them.

[0277] In the above description, the UEs and the RAN node are described for ease of understanding as having a number of discrete functional components or modules. Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the innovative features described herein, in other applications, for example in systems designed with the innovative features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities.

[0278] In the above example, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied to the base station, to the mobility management entity, or to the UE as a signal over a computer network, or on a recording medium. Further, the functionality performed by part, 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 base station or the UE in order to update their functionalities.

[0279] Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input / output (IO) circuits; internal memories / caches (program and / or data); processing registers; communication buses (e.g. control, data and / or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and / or timers; and / or the like. Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0280] The base station may comprise a 'distributed' base station having a central unit 'CU' and one or more separate distributed units (DUs).

[0281] The User Equipment (or "UE", "mobile station", "mobile device" or "wireless device") in the present disclosure is an entity connected to a network via a wireless interface.

[0282] It should be noted that the present disclosure is not limited to a dedicated communication device and can be applied to any device having a communication function as explained in the following paragraphs.

[0283] The terms "User Equipment" or "UE" (as the term is used by 3GPP), "mobile station", "mobile device", and "wireless device" are generally intended to be synonymous with one another, and include standalone mobile stations, such as terminals, cell phones, smart phones, tablets, cellular IoT devices, IoT devices, and machinery. It will be appreciated that the terms "mobile station" and "mobile device" also encompass devices that remain stationary for a long period of time.

[0284] A UE may, for example, be an item of equipment for production or manufacture and / or an item of energy related machinery (for example equipment or machinery such as: boilers; engines; turbines; solar panels; wind turbines; hydroelectric generators; thermal power generators; nuclear electricity generators; batteries; nuclear systems and / or associated equipment; heavy electrical machinery; pumps including vacuum pumps; compressors; fans; blowers; oil hydraulic equipment; pneumatic equipment; metal working machinery; manipulators; robots and / or their application systems; tools; molds or dies; rolls; conveying equipment; elevating equipment; materials handling equipment; textile machinery; sewing machines; printing and / or related machinery; paper converting machinery; chemical machinery; mining and / or construction machinery and / or related equipment; machinery and / or implements for agriculture, forestry and / or fisheries; safety and / or environment preservation equipment; tractors; precision bearings; chains; gears; power transmission equipment; lubricating equipment; valves; pipe fittings; and / or application systems for any of the previously mentioned equipment or machinery etc.).

[0285] A UE may, for example, be an item of transport equipment (for example transport equipment such as: rolling stocks; motor vehicles; motorcycles; bicycles; trains; buses; carts; rickshaws; ships and other watercraft; aircraft; rockets; satellites; drones; balloons etc.).

[0286] A UE may, for example, be an item of information and communication equipment (for example information and communication equipment such as: electronic computer and related equipment; communication and related equipment; electronic components etc.).

[0287] A UE may, for example, be a refrigerating machine, a refrigerating machine applied product, an item of trade and / or service industry equipment, a vending machine, an automatic service machine, an office machine or equipment, a consumer electronic and electronic appliance (for example a consumer electronic appliance such as: audio equipment; video equipment; a loud speaker; a radio; a television; a microwave oven; a rice cooker; a coffee machine; a dishwasher; a washing machine; a dryer; an electronic fan or related appliance; a cleaner etc.).

[0288] A UE may, for example, be an electrical application system or equipment (for example an electrical application system or equipment such as: an x-ray system; a particle accelerator; radio isotope equipment; sonic equipment; electromagnetic application equipment; electronic power application equipment etc.).

[0289] A UE may, for example, be an electronic lamp, a luminaire, a measuring instrument, an analyser, a tester, or a surveying or sensing instrument (for example a surveying or sensing instrument such as: a smoke alarm; a human alarm sensor; a motion sensor; a wireless tag etc.), a watch or clock, a laboratory instrument, optical apparatus, medical equipment and / or system, a weapon, an item of cutlery, a hand tool, or the like.

[0290] A UE may, for example, be a wireless-equipped personal digital assistant or related equipment (such as a wireless card or module designed for attachment to or for insertion into another electronic device (for example a personal computer, electrical measuring machine)).

[0291] A UE may be a device or a part of a system that provides applications, services, and solutions described below, as to "internet of things (IoT)", using a variety of wired and / or wireless communication technologies.

[0292] Internet of Things devices (or "things") may be equipped with appropriate electronics, software, sensors, network connectivity, and / or the like, which enable these devices to collect and exchange data with each other and with other communication devices. IoT devices may comprise automated equipment that follow software instructions stored in an internal memory. IoT devices may operate without requiring human supervision or interaction. IoT devices might also remain stationary and / or inactive for a long period of time. IoT devices may be implemented as a part of a (generally) stationary apparatus. IoT devices may also be embedded in non-stationary apparatus (e.g. vehicles) or attached to animals or persons to be monitored / tracked.

[0293] It will be appreciated that IoT technology can be implemented on any communication devices that can connect to a communication network for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

[0294] It will be appreciated that IoT devices are sometimes also 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 following table. This list is not exhaustive and is intended to be indicative of some examples of machine type communication applications.

[0295] Applications, services, and solutions may be an MVNO (Mobile Virtual Network Operator) service, an emergency radio communication system, a PBX (Private Branch eXchange) system, a PHS / Digital Cordless Telecommunication system, a POS (Point of sale) system, an advertise calling system, an MBMS (Multimedia Broadcast and Multicast Service), a V2X (Vehicle to Everything) system, a train radio system, a location related service, a Disaster / Emergency Wireless Communication Service, a community service, a video streaming service, a femto cell application service, a VoLTE (Voice over LTE) service, a charging service, a radio on demand service, a roaming service, an activity monitoring service, a telecom carrier / communication NW selection service, a functional restriction service, a PoC (Proof of Concept) service, a personal information management service, an ad-hoc network / DTN (Delay Tolerant Networking) service, etc.

[0296] Further, the above-described UE categories are merely examples of applications of the technical ideas and exemplary examples described in the present document. Needless to say, these technical ideas and examples are not limited to the above-described UE and various modifications can be made thereto.

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

[0298] For example, the whole or part of the exemplary embodiments disclosed above can be described as, but not limited to, the following supplementary notes. 　　(Supplementary note 1) 　　A method performed by a User Equipment, UE, the method comprising: Receiving, from a network node, first information configuring a second resource for a physical random access channel, PRACH, in addition to a first resource for the PRACH; and receiving, from the network node, second information indicating availability of the second resource. 　　(Supplementary note 2) 　　The method of supplementary note 1, wherein the second information is received in a Downlink Control Information, DCI, format 1_0. 　　(Supplementary note 3) 　　The method of supplementary note 2, wherein the DCI format is with paging radio network temporary identifier, P-RNTI. 　　(Supplementary note 4) 　　The method of any one of supplementary notes 1-3, further comprising: receiving, from the network node, third information indicating a validity duration of the second resource. 　　(Supplementary note 5) 　　The method of supplementary note 4, wherein the third information is preconfigured to the UE. 　　(Supplementary note 6) 　　The method of supplementary note 4 or 5, wherein a reference point for the availability of the second resource is a timing corresponding to where the UE receives the second information. 　　(Supplementary note 7) 　　The method of any one of supplementary notes 1-6, wherein one bit from bits within a short message field is used for the second information. 　　(Supplementary note 8) 　　The method of any one of supplementary notes 1-7, further comprising: receiving, from the network node, within a Physical Downlink Control Channel, PDCCH, order for triggering a PRACH, fourth information indicating availability of the second resource. 　　(Supplementary note 9) 　　A method performed by a network node, the method comprising: transmitting, to a User Equipment, UE, first information configuring a second resource for a physical random access channel, PRACH, in addition to a first resource for the PRACH; and transmitting, to the UE, second information indicating availability of the second resource. 　　(Supplementary note 10) 　　The method of supplementary note 9, wherein the second information is received in a Downlink Control Information, DCI, format 1_0. 　　(Supplementary note 11) 　　The method of supplementary note 10, wherein the DCI format is with paging radio network temporary identifier, P-RNTI. 　　(Supplementary note 12) 　　The method of any one of supplementary notes 9-11, further comprising: transmitting, to the UE, third information indicating a validity duration of the second resource. 　　(Supplementary note 13) 　　The method of supplementary note 12, wherein the third information is preconfigured to the UE. 　　(Supplementary note 14) 　　The method of supplementary note 12 or 13, wherein a reference point for the availability of the second resource is a timing corresponding to where the UE receives the second information. 　　(Supplementary note 15) 　　The method of any one of supplementary notes 9-14, wherein one bit from bits within a short message field is used for the second information. 　　(Supplementary note 16) 　　The method of any one of supplementary notes 9-15, further comprising: transmitting, to the UE, within a Physical Downlink Control Channel, PDCCH, order for triggering a PRACH, fourth information indicating availability of the second resource. 　　(Supplementary note 17) 　　A User Equipment, UE, comprising: means for receiving, from a network node, first information configuring a second resource for a physical random access channel, PRACH, in addition to a first resource for the PRACH; and receiving, from the network node, second information indicating availability of the second resource. 　　(Supplementary note 18) 　　A network node comprising: means for transmitting, to a User Equipment, UE, first information configuring a second resource for a physical random access channel, PRACH, in addition to a first resource for the PRACH; and means for transmitting, to the UE, second information indicating availability of the second resource.

[0299] This application is based upon and claims the benefit of priority from Great Britain Patent Application No. 2416486.5, filed on November 8, 2024, the disclosure of which is incorporated herein in its entirety by reference.

[0300] 1 COMMUNICATION SYSTEM 3 USER EQUIPMENT 5 BASE STATION 7 CORE NETWORK 9 CELL 10 CONTROL PLANE FUNCTIONS 11 USER PLANE FUNCTIONS 20 EXTERNAL DATA NETWORK 31 TRANSCEIVER CIRCUIT 33 ANTENNA 35 USER INTERFACE 37 CONTROLLER 39 MEMORY 41 OPERATING SYSTEM 43 COMMUNICATIONS CONTROL MODULE 51 TRANSCEIVER CIRCUIT 53 ANTENNA 55 CORE NETWORK INTERFACE 57 CONTROLLER 59 MEMORY 61 OPERATING SYSTEM 63 COMMUNICATIONS CONTROL MODULE

Claims

1. A method performed by a User Equipment, UE, the method comprising: Receiving, from a network node, first information configuring a second resource for a physical random access channel, PRACH, in addition to a first resource for the PRACH; and receiving, from the network node, second information indicating availability of the second resource.

2. The method of claim 1, wherein the second information is received in a Downlink Control Information, DCI, format 1_0.

3. The method of claim 2, wherein the DCI format is with paging radio network temporary identifier, P-RNTI.

4. The method of any one of claims 1-3, further comprising: receiving, from the network node, third information indicating a validity duration of the second resource.

5. The method of claim 4, wherein the third information is preconfigured to the UE.

6. The method of claim 4 or 5, wherein a reference point for the availability of the second resource is a timing corresponding to where the UE receives the second information.

7. The method of any one of claims 1-6, wherein one bit from bits within a short message field is used for the second information.

8. The method of any one of claims 1-7, further comprising: receiving, from the network node, within a Physical Downlink Control Channel, PDCCH, order for triggering a PRACH, fourth information indicating availability of the second resource.

9. A method performed by a network node, the method comprising: transmitting, to a User Equipment, UE, first information configuring a second resource for a physical random access channel, PRACH, in addition to a first resource for the PRACH; and transmitting, to the UE, second information indicating availability of the second resource.

10. The method of claim 9, wherein the second information is received in a Downlink Control Information, DCI, format 1_0.

11. The method of claim 10, wherein the DCI format is with paging radio network temporary identifier, P-RNTI.

12. The method of any one of claims 9-11, further comprising: transmitting, to the UE, third information indicating a validity duration of the second resource.

13. The method of claim 12, wherein the third information is preconfigured to the UE.

14. The method of claim 12 or 13, wherein a reference point for the availability of the second resource is a timing corresponding to where the UE receives the second information.

15. The method of any one of claims 9-14, wherein one bit from bits within a short message field is used for the second information.

16. The method of any one of claims 9-15, further comprising: transmitting, to the UE, within a Physical Downlink Control Channel, PDCCH, order for triggering a PRACH, fourth information indicating availability of the second resource.

17. A User Equipment, UE, comprising: means for receiving, from a network node, first information configuring a second resource for a physical random access channel, PRACH, in addition to a first resource for the PRACH; and receiving, from the network node, second information indicating availability of the second resource.

18. A network node comprising: means for transmitting, to a User Equipment, UE, first information configuring a second resource for a physical random access channel, PRACH, in addition to a first resource for the PRACH; and means for transmitting, to the UE, second information indicating availability of the second resource.

Images