Method performed by mobile device, method performed by access network node, mobile device, and access network node

Abstract

A method performed by a mobile device is disclosed. The method includes configuring at least one of a legacy random access channel (RACH) resource or an additional RACH resource for a specific service; and selecting either the legacy RACH resource or the additional RACH resource for the mobile device to use for the specific service.

Description

METHOD PERFORMED BY MOBILE DEVICE, METHOD PERFORMED BY ACCESS NETWORK NODE, MOBILE DEVICE, AND ACCESS NETWORK NODE

[0001] The present disclosure relates to a communication system and to parts thereof. 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 configuration and / or selection of resources for random-access channel (RACH) procedures in the context of full duplex (FD) communication in time division duplex (TDD) communication bands (e.g., subband non-overlapping FD (SBFD)) and / or network energy saving (NES).

[0002] Earlier developments of the 3GPP standards were referred to as the Long-Term Evolution (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 (NPL 1) 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.

[0003] 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.

[0004] 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.

[0005] 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.

[0006] 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).

[0007] 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.

[0008] 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.

[0009] 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.

[0010] 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.

[0011] 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.

[0012] 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.

[0013] 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 / physical broadcast channel (PBCH) 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.

[0014] 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').

[0015] 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.

[0016] 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.

[0017] 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 RACH will be used herein) for initiating a random-access procedure (also referred to as a RACH procedure, or simply 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.

[0018] 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.

[0019] Initial access from an idle mode is not the only time a RACH procedure may be initiated by a UE. Typically, for example, a UE may perform a 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 transmission (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 transmission (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 transmission (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).

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

[0021] 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 RACH slot in which the RO falls).

[0022] The time domain locations of the slots in which the ROs are provided (referred to as PRACH slots or RACH slots) are determined based on a RACH (or PRACH) 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).

[0023] The mapping between the SSBs (and hence the beams), and the specific ROs (within the 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).

[0024] Given the significantly higher carrier frequencies supported by 5G, and that will be supported by future communication generations (6G and beyond) as compared to earlier communication generations, improved techniques for providing efficient use of unpaired spectrum are being, and will continue to be, developed.

[0025] However, allocation of too limited a time duration for the UL in TDD carriers has the potential to result in reduced coverage, increased latency, and reduced capacity.

[0026] Full duplex (FD) operation, involving sharing both frequency domain and time domain resources between the UL and the DL, within the bandwidth of a conventional TDD carrier, represents one way in which improvements may be achievable over conventional TDD performance. Accordingly, enhancements to implement full duplex operation at the base station, within TDD carriers, are currently being developed - currently with no restriction on the possible frequency ranges used for such FD operation. At present half duplex operation within TDD carriers is still envisaged for the UE, although full duplex UE operation remains an option for the future. The use of FD has, however, the potential to cause serious interference issues, both at the base station and at the UE, which are difficult to address.

[0027] There are a number of possible FD implementations that can be implemented on TDD carriers including, for example, subband non-overlapping, subband overlapping, full overlapping.

[0028] In subband non-overlapping FD ('SBFD', also referred to as cross division duplex (XDD)), non-overlapping UL and DL subbands may be configured in the TDD carrier. Each subband comprises a respective relatively 'narrow' frequency band having a bandwidth that extends only part of the full available bandwidth within the current TDD carrier that is configured for communication in the associated cell. A RAN node can thus perform simultaneous (full duplex) transmission and reception at the same time, in different respective non-overlapping subbands, for different UEs.

[0029] In some proposed SBFD implementations, a single dedicated DL subband and a single dedicated UL subband may be configured in the TDD carrier.

[0030] Nevertheless, in other proposed SBFD implementations, full duplex operation may be active in a configured subset of one or more of the available TDD time resources (slots and / or symbols) and, in the configured subset, an UL (or DL) subband may be configured to be present in the centre of frequency band configured for a DL (or UL) time resource. Effectively therefore, in the configured subset of time resources, two DL (or UL) subbands may be present at either side (in frequency) of a configured UL (or DL) subband. In one or more other time resources (that are not part of the configured) subset, legacy TDD operation may be used (i.e. in which the entire frequency band is used only for UL (or DL)). It will be appreciated that, in a first subset of one or more time resources, an UL subband may be configured to be present in a frequency band that is otherwise configured for DL communication and hence two UL subbands may be present at either side of a DL subband. Similarly, in a second subset of one or more time resources, a complementary UL / DL configuration may be configured compared to the first four slots e.g., a configuration in which a DL subband is configured to be present in a frequency band that is otherwise configured for UL communication and hence two DL subbands may be present at either side of an UL subband.

[0031] In subband overlapping FD, UL and DL may be configured in a similar way to subband non-overlapping FD, but the different subbands are allowed to overlap in frequency.

[0032] In full overlapping FD, the entire available bandwidth may be used for UL or DL transmissions.

[0033] One of the key benefits of SBFD is increased UL coverage because SBFD makes it easier to take advantage of multi-slot UL repetitions due to an increased number of consecutive UL occasions in SBFD. Currently, therefore, focus is on the development of techniques for implementing subband non-overlapping FD operation and potential related enhancements for dynamic or flexible TDD. It will be appreciated, however, that other FD implementations remain an option for the future and enhancements envisaged for sub-band non-overlapping FD may have benefits in other FD schemes.

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] 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).

[0041] 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.

[0042] 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.

[0043] 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.

[0044] 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.

[0045] There are various issues that have been identified for RACH resource allocation using conventional RACH configuration techniques. For example, the selection of RACH resources (e.g., ROs) may result in high latency and / or reduced UL coverage due to a relatively limited number of UL symbols being available for ROs in a TDD pattern period. Whilst, to increase RACH capacity and / or reduce latency, the number of available RACH resources (e.g., ROs) could, hypothetically, be increased, doing so results in relatively frequent RACH resource repetition which risks a reduction (or elimination) of opportunities for a RAN node to switch to a low power mode for NES purposes even when no user is connected in an associated cell.

[0046] To address the above issues, different mechanisms have and continue to be investigated. However, further work is required to develop flexible and efficient RACH configuration mechanisms especially in (but not limited to) the context of SBFD and / or NES.

[0047] For SBFD, for example, it may be beneficial to find ways to increase the number of RACH resources (e.g., ROs) by allocating RACH resources for SBFD-aware UEs in symbols / slots configured for SBFD. For Network Energy Savings (NES), on the other hand, it may be beneficial for different RACH resources (e.g., ROs) to be configurable, at NES capable UEs, that allow for power saving optimisations to be enabled. In either case, and for other new enhancements as they are developed, it may be beneficial to mitigate the issues associated with a more conventional (e.g., legacy) RACH configuration by configuring additional / different RACH resources (e.g., ROs) to UEs supporting SBFD, NES, and / or other new features.

[0048] 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 issues and / or that at least partially contributes achieving one or more of the above benefits.

[0049] In this context, for random-access operation in the context of SBFD (e.g., operation for SBFD-aware UEs in an RRC connected state), the conceivers of the apparatus and / or methods disclosed herein have considered (amongst other things) techniques for supporting the use of an enhanced single common RACH configuration that provides both the configuration: of additional ROs for SBFD-aware UEs, for example in slots / symbols configured for SBFD operation; and of conventional (e.g., legacy) ROs for all (or other non-SBFD) UEs, for example in conventional / legacy UL symbols / slots. Hence, additional ROs provided within an UL subband of SBFD symbols can configured to be valid for SBFD-aware UEs but not other (e.g., legacy / non-SBFD aware) UEs.

[0050] For random-access operation in the context of SBFD (e.g., operation for SBFD-aware UEs in an RRC connected state), the conceivers of the apparatus and / or methods disclosed herein have also considered (amongst other things) techniques for supporting the use two separate RACH configurations, including a conventional (e.g., legacy) common RACH configuration together with an additional feature / feature-combination specific (e.g., SBFD specific) common RACH configuration. In this case the additional feature / feature-combination specific RACH configuration provides the configuration of additional ROs for SBFD-aware UEs, for example in slots / symbols configured for SBFD operation. The conventional (e.g., legacy) common RACH configuration, on the other hand, provides the configuration of ROs for all (or other non-SBFD) UEs, for example in conventional / legacy UL symbols / slots.

[0051] For random-access operation in the context of NES, the conceivers of the apparatus and / or methods disclosed herein have also considered (amongst other things) adaptation mechanisms for supporting the adaptation of RO provision in the time domain. The considered adaptation mechanisms include, for example, adaptation based on configuration (e.g., via an additional RACH configuration) of additional (and / or different) ROs in UL symbols / slots for NES-capable UEs in addition to (and / or instead of) ROs for other (e.g., non-NES supporting / legacy UEs, if any) - here it will be appreciated that NES-capable UEs may be configured to use both / either additional RACH resources (ROs) and / or RACH resources for other (non-NES capable / legacy UEs). The considered adaptation mechanisms include, for example, adaptation of an additional (separate) RACH configuration based on: possible adaptation of RACH resource periodicity / ROs; possible adaptation of RACH configuration, association period, association pattern period level, and / or SSB to RO mapping cycle; possible adaptation based on extending cell DRX operation appropriately for RACH procedures; and / or possible concentration of ROs in the time domain.

[0052] NPL 1: NGMN 5G White Paper' V1.0

[0053] One or more apparatus and / or one or more associated methods are disclosed that aim to at least partially contribute to meeting one or more of above needs.

[0054] In one aspect there is provided a method performed by a mobile device, the method comprising: 　　configuring at least one of a legacy random access channel (RACH) resource or an additional RACH resource for a specific service; and 　　selecting either the legacy RACH resource or the additional RACH resource for the mobile device to use for the specific service.

[0055] In one aspect there is provided a method performed by an access network node, the method comprising: 　　transmitting, to a mobile device, information for configuring at least one of a legacy random access channel (RACH) resource or an additional RACH resource for a specific service; and 　　transmitting, to the mobile device, information for selecting either the legacy RACH resource or the additional RACH resource for the mobile device to use for the specific service.

[0056] In one aspect there is provided a mobile device comprising: 　　means for configuring at least one of a legacy random access channel (RACH) resource or an additional RACH resource for a specific service; and 　　means for selecting either the legacy RACH resource or the additional RACH resource for the mobile device to use for the specific service.

[0057] In one aspect there is provided an access network node comprising: 　　means for transmitting, to a mobile device, information for configuring at least one of a legacy random access channel (RACH) resource or an additional RACH resource for a specific service; and 　　means for transmitting, to the mobile device, information for selecting either the legacy RACH resource or the additional RACH resource for the mobile device to use for the specific service.

[0058] 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.

[0059] 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 the any of the methods described below. The computer implementable instructions may be provided as a signal or on a tangible computer readable medium.

[0060] According to the present disclosure, it is possible to provide a method performed by a mobile device, a method performed by an access network node, a mobile device, and an access network node.

[0061] Various disclosures will now be described, by way of example, with reference to the accompanying drawings in which:

[0062] 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 is a simplified sequence diagram illustrating different slot configuration procedures that can be employed in the communication system of Fig. 1;Fig. 4 shows illustrative examples of slot configurations configured by the procedures of Fig. 3;Fig. 5 is a simplified time frequency diagram showing an illustrative example of a full duplex configuration that may be used in the communication system of Fig. 1;Fig. 6 is a simplified sequence diagram illustrating a number of different potential mechanisms for RACH resource selection, for the purposes of a RACH transmission initiated by a PDCCH order, that may be used in the communication system of Fig. 1;Fig. 7A is a simplified illustration of how the mechanisms for RACH resource selection shown in Fig. 6 operate;Fig. 7B is a simplified illustration of how the mechanisms for RACH resource selection shown in Fig. 6 operate;Fig. 7C is a simplified illustration of how the mechanisms for RACH resource selection shown in Fig. 6 operate;Fig. 7D is a simplified illustration of how the mechanisms for RACH resource selection shown in Fig. 6 operate;Fig. 7E is a simplified illustration of how the mechanisms for RACH resource selection shown in Fig. 6 operate;Fig. 8 is a simplified sequence diagram illustrating a procedure for RACH resource selection, for the purposes of an initial random-access attempt initiated by a UE, that may be used in the communication system of Fig. 1;Fig. 9 is a simplified sequence diagram illustrating another procedure for RACH resource selection, for the purposes of an initial random-access attempt initiated by a UE, that may be used in the communication system of Fig. 1;Fig. 10 is a simplified sequence diagram illustrating another procedure for RACH resource selection, for the purposes of an initial random-access attempt initiated by a UE, that may be used in the communication system of Fig. 1;Fig. 11 is a simplified sequence diagram illustrating another procedure for RACH resource selection, for the purposes of an initial random-access attempt initiated by a UE, that may be used in the communication system of Fig. 1;Fig. 12 is a simplified illustration of a number of mechanisms for SSB to RO mapping that may be used in the communication system of Fig. 1;Fig. 13 is a simplified illustration of further mechanisms for SSB to RO mapping that may be used in the communication system of Fig. 1;Fig. 14 is a simplified illustration of another mechanism for SSB to RO mapping that may be used in the communication system of Fig. 1;Fig. 15 is a schematic block diagram illustrating the main components of a UE that may be used in the communication system of Fig. 1; andFig. 16 is a schematic block diagram illustrating the main components of a RAN node that may be used in the communication system of Fig. 1.

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

[0064] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system (e.g., communication system 1) to which the examples described herein are applicable.

[0065] In the communication system 1, user equipments (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 5 or 'gNB' that respectively operates one or more associated cells 9 (9-1, 9-2). In the illustrated communication system 1, the coverage provided by each RAN node 5 may be by means of a plurality of beams B (B1, B2… Br, Br+1… BN). It will be appreciated that while, for clarity of illustration, only a selection of possible beams B 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.

[0066] Communication via each RAN node 5 is typically routed through a core network 7 (e.g. a 5G / 6G or later generations core network or evolved packet core network (EPC)).

[0067] 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 one or more other RAN nodes 5 and UEs 3.

[0068] Each RAN node 5 controls one or more associated cells 9 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 4G, 5G, 6G, and / or later generations and / or any other 3GPP or non-3GPP communication protocols.

[0069] 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).

[0070] 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 one or more 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 the UE 3 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.

[0071] 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. At least the non-IoT UEs 3 are each connected to the AMF 10-1 via a non-access stratum (NAS) connection over an appropriate interface (e.g. an 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.

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

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

[0074] The SMF 10-2 is connected to the AMF 10-1 via an appropriate interface (e.g. an 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 10-1 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.

[0075] 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.

[0076] 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, the UE 3 may receive a Synchronization Signal / Physical Broadcast Channel (PBCH) 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.

[0077] 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).

[0078] 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 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.

[0079] < 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.

[0080] 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.

[0081] Table 1: Numerology

[0082] < 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 the 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).

[0083] 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.

[0084] Table 2: DCI Format Summary

[0085] Different DCI formats may or may not have the same DCI size. Moreover, DCI may be addressed (scrambled) using different radio network temporary identifiers (RNTIs) that the UE 3 may monitor for. Typically, the UE 3 is capable of monitoring up to three different DCI sizes for DCI formats using a cell RNTI (C-RNTI) - typically used as an identifier for scheduling purposes. Additionally, the 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), 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.

[0086] 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.

[0087] The 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 the UE 3 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 the UE 3 may be 44 BDs.

[0088] < General Slot Configuration > 　　Referring to Figs. 3 and 4 the RAN node 5 configures the slot usage within each cell 9 operated on a TDD carrier appropriately.

[0089] As seen in Fig. 3, which is a simplified sequence diagram illustrating different slot configuration procedures (S310, S314, S318) that can be employed in the communication system 1, the RAN node 5 is capable of employing a number of different procedures for configuring slot usage in each cell 9 operated on the TDD carrier.

[0090] As seen in procedure S310, for example, the RAN node 5 of the communication system 1 is configured for providing a respective common (or 'cell specific') slot configuration, for each cell 9 operated on a TDD carrier. This common slot configuration can be provided using system information (as illustrated at S310a) to all UEs 3 within the cell (for example in a tdd-UL-DL-ConfigurationCommon information element (IE) of a system information block 1 (SIB1)). This common slot configuration can also be provided using dedicated (e.g., radio resource control (RRC)) signalling (as illustrated at S310b) to specific UEs 3 within the cell (for example in a tdd-UL-DL-ConfigurationCommon IE of an RRC message such as an RRC reconfiguration message or the like). On receipt of the common slot configuration, a UE 3 can thus set a common slot format configuration per slot over a number of slots (as seen at S312).

[0091] As seen in Fig. 4, which shows illustrative examples of slot configurations configured by the procedures of Fig. 3, the slots may be configured as downlink only slots, as uplink only slots, or as unallocated or 'flexible' slots (that may be downlink or uplink).

[0092] The common slot configuration is defined by a number of parameters provided by the RAN node 5 as part of a common UL / DL slot configuration. These parameters include: a slot configuration period (e.g., configured by a dl-UL-TransmissionPeriodicity IE); a number of slots with only downlink symbols (e.g., configured by a nrofDownlinkSlots IE); a number of downlink symbols (e.g., configured by a nrofDownlinkSymbols IE); a number of slots with only uplink symbols (e.g., configured by a nrofUplinkSlots IE); and a number of uplink symbols (e.g., configured by a nrofUplinkSymbols IE). As seen in Fig. 4, these effectively configure a repeating pattern of slot types (repeating at the slot configuration period), which in this example comprises DL only slots and symbols, followed by flexible slots and symbols, followed by UL only slots and symbols. The repeating pattern starts with a DL group comprising the defined number of DL only slots followed by the defined number of DL only symbols in the next slot. The repeating pattern ends with a UL group comprising the defined number of UL only slots preceded by the defined number of UL only symbols in the preceding slot. The flexible symbols and slots are those, between the DL group of DL only slots and symbols and the UL group of UL only slots and symbols.

[0093] As seen in procedure S314, the RAN node 5 of the communication system 1 is also configured for providing, if required, a dedicated (or 'UE specific') slot configuration for a specific UE 3. This dedicated slot configuration can be provided using dedicated (e.g., radio resource control (RRC)) signalling (as illustrated at S315) to the specific UE 3 within the cell (for example in a tdd-UL-DL-ConfigurationDedicated IE of an RRC message such as an RRC reconfiguration message or the like).

[0094] If the UE 3 is provided with the dedicated slot configuration in addition to the common slot configuration, then the dedicated slot configuration overrides only the symbols and slots configured as flexible symbols and slots, per slot, over the number of slots configured by the common slot configuration (as seen in the example of Fig. 3).

[0095] The dedicated configuration, if provided, includes one or more individual slot specific configurations (e.g., using a slotSpecificConfigurationsToAddModList IE) in which each slot configuration contains information (e.g., a slotindex IE) identifying a specific slot within the slot configuration period defined by the common slot configuration, and information defining a symbol structure (e.g., a symbols IE). The information defining the symbol structure provides the direction (downlink or uplink) for the symbols within the specific slot that is being configured. The information defining the symbols structure may, for example: indicate that all symbols in the specific slot are used for the downlink (e.g., by setting the symbols IE to 'allDownlink'); indicate that all symbols in the specific slot are used for the uplink (e.g., by setting the symbols IE to 'allUplink'); or explicitly indicate how many symbols at the beginning and the end of the specific slot are allocated to downlink and uplink, respectively (e.g., a nrofDownlinkSymbols IE may indicate the number of consecutive downlink symbols in the beginning of the slot identified by the slot index, and a nrofUplinkSymbols IE may indicate the number of consecutive uplink symbols at the end of the slot identified by the slot index).

[0096] The UE 3 can thus set a dedicated slot format configuration per slot over a number of slots (as seen at S316).

[0097] The UE 3 thus treats symbols in a slot indicated as downlink by the common slot configuration, or by the dedicated slot configuration, as being available for receptions. Similarly, the UE 3 treats symbols in a slot indicated as uplink by the common slot configuration, or by the dedicated slot configuration, as being available for transmissions.

[0098] Even after the slot configurations in a cell-specific and UE-specific manner described above, the slot configuration may have some more flexible slots / symbols left unallocated. By making use of layer 1 signalling, the remaining (if any) flexible symbols can be reconfigured dynamically.

[0099] As seen in procedure S318, for example, the RAN node 5 of the communication system 1 is also configured for providing one or more dynamic slot configurations to a group of one or more UEs 3 by means of a physical downlink control channel (PDCCH). One or more dynamic slot configurations can be provided using downlink control information (DCI) using an appropriate DCI format (e.g., DCI format 2_0), as illustrated at S319, to a specific group of one or more UEs 3 within the cell 9.

[0100] Indexes of one or more slot format indicators (SFIs) are provided within the payload of the DCI for the group of one or more UEs 3. To allow the DCI to be addressed to and decoded by each UEs 3 of the group, cyclic redundancy check (CRC) bits of the DCI are scrambled with an associated radio network temporary identifier (RNTI), for example a slot format indicator RNTI ('SFI-RNTI') or the like. Each UE 3 in the group is allocated with the same RNTI. Each UE 3 of the group is configured to extract its own SFI-index based on the position of the SFI-index within the DCI payload (this position may, for example, be configured by UE specific RRC signalling). The RRC configuration may, for example, be by means of an RRC message carrying a PDCCH serving cell configuration IE having a slot format indicator (SFI) IE that, for a specific serving cell (identified by a serving cell ID (e.g., by a servingCellId IE)): provides an SFI-RNTI; defines one or more slot format combinations (e.g., by a slotFormatCombinations IE); and specifies the starting position (bit), in the DCI, of the SFI index that is applicable for the configured UE 3 (e.g., by a positionInDCI IE).

[0101] Each SFI-index provided by the DCI acts as a pointer to a combination of slot formats (where each slot format corresponds to a respective combination of downlink, uplink, and / or flexible symbols) for defining a slot format for each slot in a number of slots starting from a slot where the UE 3 detects the dynamic slot configuration DCI format.

[0102] Thus, for any slot indicated to the UE 3 as flexible by both a common slot configuration and a dedicated slot configuration, the DCI can be used to dynamically configure downlink, uplink, and / or flexible symbols within that slot (as seen in the example of Fig. 4).

[0103] The UE 3 can thus set a dynamic slot format configuration per slot over a number of slots (as seen at S320).

[0104] < Provision of Full Duplex > 　　The UEs 3 and RAN node 5 of the communication system 1 may be mutually configured for providing full duplex (FD) communication on a TDD carrier. Specifically, the UEs 3 and RAN node 5 of the communication system 1 may be configured to facilitate subband non-overlapping FD (SBFD) communication. It will be appreciated that the UEs 3 may include UEs 3 that support SBFD and UEs 3 that do not.

[0105] For example, as seen in Fig. 5, which is a simplified time frequency diagram showing an illustrative example of a full duplex configuration that may be used in the communication system 1, the different UE-specific slot configurations allow a slot within the cell bandwidth to effectively be configured as an FD slot by configuring that slot for one UE 3 as an uplink slot, while the same slot is configured as a downlink slot for another UE 3 (or vice versa). Thus, UL communication from one UE 3 in the cell bandwidth may occur in parallel with DL communication to another UE 3. It will be appreciated that while not specifically illustrated the parallel UL / DL communication may be configured at a symbol level as well as at the slot level.

[0106] It will be appreciated that the RAN node 5 is configured to schedule frequency resources of any slot configured as an FD slot, to ensure that the frequency resources scheduled for UL communication by one UE 3 are part of a different subband than the frequency resources scheduled for DL communication to another UE 3. Accordingly, subband non-overlapping FD communication can thus take place at the RAN node 5 while half-duplex communication takes place at the UEs 3.

[0107] The RAN node 5 is thus able to configure one or more of the slots (and / or symbols) of the TDD carrier as FD slots (and / or symbols) or more specifically, in a case where, subband non-overlapping full duplex (SBFD) is used for full duplex operation, SBFD slots (and / or symbols). For convenience, slots / symbols which contain both UL and DL subbands, from the RAN node's perspective, will be referred to generally as 'SBFD' slots / symbols, or slots / symbols with a configured UL subband / DL subband. Other slots / symbols, which only contain communication in a single transmission direction (UL or DL) will generally be referred to as legacy (UL or DL) slots / symbols or non-SBFD (UL or DL) slots / symbols.

[0108] It will be appreciated that, from UE perspective, an SBFD slot or symbol may appear to be a legacy UL, DL, or flexible symbol because the UE 3 is operating using half duplex on the TDD carrier. Nevertheless, the UE 3 may be informed of the FD / SBFD slots / symbols, either implicitly or explicitly, to allow the UE 3 to assist with interference avoidance / alleviation. For example, if the UE 3 can identify the FD / SBFD slots / symbols then the UE 3 may: contribute to the implementation of an appropriate frequency gap between the frequency resources used by that UE 3 (e.g., for UL or DL) and the frequency resources used by another UE 3 (e.g., for DL or UL); avoid, reconfigure, and / or apply updated resources, in respect of certain transmissions / receptions (e.g., for semi-static transmission such as SPS).

[0109] For example, the RAN node 5 may explicitly indicate which slots / symbols are configured as FD / SBFD type slots / symbols, for example, dynamically using DCI with an appropriate DCI format and / or using a Medium Access Control (MAC) Control Element (CE). The RAN node 5 may, alternatively or additionally explicitly indicate which slots / symbols are configured as FD / SBFD type slots / symbols via system information or dedicated (RRC) signalling (for example, by means of frame structure signalling similar to that used for the cell specific and / or dedicated TDD UL / DL slot configuration). The UE 3 may implicitly determine whether a slot / symbol is configured as an FD / SBFD type slots / symbol based on other information received from the network (RAN node 5). For example, the UE 3 may assume that an SBFD slot occurs when the RAN node 5 indicates that an UL transmission is to take place during a DL configured slot or that a DL transmission is to take place during a UL configured slot.

[0110] It will be appreciated that there are different variations which exist for implementation of SBFD, and the communication system 1 may be configured to provide support for any suitable SBFD schemes.

[0111] Notwithstanding that an UL (or DL) subband may be configured in a slot / symbol configured (e.g., by a TDD configuration) as a DL (or UL) slot / symbol, it will be appreciated that it would be particularly beneficial for the RAN node 5 to be able to schedule DL (or UL) transmission within a configured UL (or DL) subband dynamically (for example, when there is no UL (or DL) transmission required) to improve radio resource utilisation.

[0112] Slots / symbols which contain both an UL and a DL subband may be referred to as SBFD slots / symbols or more generally to slots / symbols with configured UL subband / DL subband. Other slots / symbols for a single transmission direction (UL or DL) may be referred to as non-SBFD slots / symbols.

[0113] < 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 9, and / or the provision of one remaining minimum system information (SIB1) transmissions on-demand in one or more cells 9. It will be appreciated that the UEs 3 may include UEs 3 that support one or more of the NES techniques and UEs 3 that do not support one or more of the NES techniques.

[0114] 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 9 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 9. A cell in which the 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. The 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).

[0115] 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 3 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.

[0116] The triggering of an on-demand SSB / SIB1 may, for example, be facilitated by the transmission, by the 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 the RAN node 5 (e.g., via system information and / or DCI).

[0117] 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.

[0118] 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 3 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.

[0119] 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 5 (or one or more cells operated by that RAN node 5) 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 5 is respectively 'on' for communication in the uplink direction only, or for communication in the downlink direction only.

[0120] 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.

[0121] < 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 RACH procedure, for example when the UE 3 initially accesses the network or at other times when necessary.

[0122] For example, for initial access, on detection and selection of a beam the UE 3 is able to attempt access to the cell 9 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 RACH procedure. The UE 3 then sends the selected preamble (e.g., in 'Msg1') to the RAN node 5 over a RACH for initiating the process to obtain synchronization in the uplink (UL).

[0123] 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 3 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 3 is to transmit on the PUSCH with or without frequency; a modulation and coding scheme (MCS) field from which the UE 3 can determine the MCS for the PUSCH transmission; and a transmit power control (TPC) command value for setting the power of the PUSCH transmission.

[0124] 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.

[0125] 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).

[0126] 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 3 in this step, and the content of the message, depends on the context in which the 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 3 using the same preamble sequence. When successful, Msg4 also transfers the UE 3 to a connected state.

[0127] While a four-step RACH procedure is described it will be appreciated that, each UE 3 and RAN node 5 may be configured for performing a two-step RACH procedure (e.g., as mentioned in the introduction). Effectively, the two-step RACH procedure is achieved by combining the UE's 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 5 to UE 3 and the contention resolution message (Msg4) are combined in the two-step random-access procedure (and referred to as 'MsgB').

[0128] 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 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 the RAN node 5 when handover is required (e.g., using a handover command message).

[0129] The UE 3 may be configured to perform a 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 3 is an RRC connected mode / state (or in an RRC inactive mode / state) while a small data transmission (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 3 is an RRC connected mode / state (or in an RRC inactive mode / state) while a small data transmission (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 3 is an RRC connected mode / state or during an RRC inactive mode / state while a small data transmission (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).

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

[0131] A 'common' 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 the RAN node 5). It will, nevertheless, be appreciated that a single UE 3 may nevertheless be provided with the common RACH configuration. The common RACH configuration typically provides information that the UE 3 can use to identify the available RACH preambles, and RACH occasions, to enable the UE 3 to initiate a CBRA procedure.

[0132] The RAN node 5 may provide the common 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.

[0133] For example, a common 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). Where the RAN node 5 / UE 3 supports the use of an additional (supplementary) uplink carrier, a (potentially different) common 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 9. Moreover, where reduced capability UEs 3 may be present in the cell 9 another (potentially different) common 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 3.

[0134] A common RACH configuration may, nevertheless, be provided in an RRC message for (re)configuring / modifying an RRC connection at the UE 3 (e.g., an RRCReconfiguration message or the like). The common 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 information element (e.g., a ServingCellConfigCommon IE or the like) forming part of the cell group configuration information. Each configured serving cell may be a cell 9 of a master cell group (MCG), associated with a master RAN node 5 (for dual connectivity), or of a secondary cell group (SCG), associated with a secondary RAN node 5 (for dual connectivity).

[0135] A common 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 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 9 that provides additional radio resources on top of an SpCell, e.g., as part of carrier aggregation). The common 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 RACH related information carried by the information element for configuring reconfiguration with synchronisation information effectively defines the set of ROs for reconfiguration with synchronisation.

[0136] Where the RAN node 5 / UE 3 supports the use of an additional (supplementary) uplink carrier in a given cell 9 (e.g., an SpCell or an SCell), a (potentially different) common 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 9.

[0137] A 'dedicated' 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 9 operated by the RAN node 5). The dedicated RACH configuration typically provides information that the UE 3 can use to identify one or more dedicated RACH preambles, and / or one or more dedicated RACH occasions, to enable the UE 3 to initiate a CFRA procedure.

[0138] The RAN node 5 may provide the dedicated 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 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 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 9. The dedicated 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).

[0139] Both a common RACH configuration and a dedicated RACH configuration may include a set of 'generic' random-access parameters that may be used to specify the random-access parameters both for regular RACH procedures (e.g., for initial access) and for 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.

[0140] The generic set of parameters may, for example, be included in an appropriate IE (e.g., a 'RACH-ConfigGeneric' IE or the like) in the common / dedicated RACH configuration. The set of parameters may typically include (amongst other parameters), for example: -　　a RACH (or PRACH) configuration index (e.g., a 'prach-ConfigurationIndex' IE or the like) that points to a row, in a RACH configuration table, that includes a set of parameters for defining the timing of RACH radio frames, and 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 5 / UE 3 with different capabilities); -　　an indication of a number of ROs that are multiplexed in frequency (e.g., a 'msg1-FDM' IE 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 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 RACH frequency resource is entirely within a bandwidth of a configure UL bandwidth part (BWP) (e.g., a 'msg1-FrequencyStart' IE or the like). By way of example only, this may typically have a value from 0 to 274; -　　an indication of a target power level at the network receiver side (e.g., a 'preambleReceivedTargetPower' IE 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 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 RACH preamble (re)transmission (e.g., a 'powerRampingStep' IE 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 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 the RAN node 5 / UE 3 supporting higher SCS (Δf) - e.g., an SCS of 480 kHz or SCS 960 kHz).

[0141] The RACH (or PRACH) 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 RACH configuration table. The indicated row defines the RACH radio frames within which ROs are present by means of two parameters 'x' and 'y' where the radio frames containing a RACH occasion is given by the system frame number (nSFN) which satisfies the equation: 　　nSFNmod x = y

[0142] 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 RACH radio frame (and hence the associated set of ROs) occurs. Effectively, therefore, the parameter 'x' represents a periodicity at which the RACH radio frames (and hence the associated set of ROs) are repeated. This period may be referred to as the RACH (or 'PRACH') configuration period. For example, a value of x=2 and y=1 defines that 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 RACH radio frames occur every second radio frame - but in this case in every even numbered radio frame. In both these examples the 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 RACH configuration period was 16 radio frames (160ms) with the RACH radio frames occurring in the second radio frame of each 16 radio frame RACH configuration period.

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

[0144] It can be seen that there is a minimum number of 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 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 RACH configuration. The length of the association period in time will depend on the length of each RACH configuration period (i.e., the number of (10ms) radio frames within each 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 RACH configuration periods; {1, 2, 4, or 8} 20ms RACH configuration periods; {1, 2, or 4} 40ms RACH configuration periods; {1, or 2} 80ms RACH configuration periods; or a single 160ms RACH configuration period).

[0145] Both a common RACH configuration, and a dedicated RACH configuration, include parameters for assisting in the mapping between the SSBs (and hence the beams), and the specific ROs (within the 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 or the like) provided as part of the generic 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 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 or the like). Nevertheless, in the case of the dedicated 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). 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.

[0146] A common RACH 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 (and hence associated beam) for a RACH procedure - i.e., the UE 3 may select an SSB (and corresponding 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 or the like) may be defined for the selection of an SUL carrier on which to perform a RACH procedure.

[0147] A dedicated RACH configuration may also include information which allocates one or more dedicated 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 RACH procedure, a respective dedicated preamble may be allocated for each candidate beam.

[0148] The information, in the dedicated 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 RACH preamble may also be provided together with that list (e.g., using a 'ra-ssb-OccasionMaskIndex' IE or the like).

[0149] The information, in the dedicated 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 the 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 RACH procedure. Hence, the UE 3 may select a CSI-RS resource (and corresponding PRACH resource) from CSI-RSs for which a measured RSRP exceeds (or is not less than) the RSRP threshold.

[0150] It will be appreciated that the common and dedicated RACH configurations defined above only cover a subset of scenarios for which a CBRA or CFRA based RACH procedure may be performed by the UE 3. For example, as indicated above, a 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 RACH procedure may be used for the purposes of recovery following a beam failure.

[0151] < RACH configuration for SI Request > 　　As indicated above, a 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 RACH resources for the purposes of a SI request. Specifically, an SI request configuration may be provided by the RAN node 5 to the UE 3 (e.g., using a 'SI-RequestConfig' IE or the like) to configure the UE 3 with appropriate RACH resources (e.g., preamble associated with specific SI requests) and associated ROs.

[0152] 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).

[0153] The SI request configuration may include information indicating a configuration of dedicated 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 RACH configuration (e.g., a 'rach-ConfigSI' configuration). This SI request specific 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 RACH configuration.

[0154] 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.

[0155] 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.

[0156] 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 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 3 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.

[0157] 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.

[0158] < RACH configuration for Beam Failure Recovery > 　　As indicated above, a 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 RACH resources for beam failure recovery. Specifically, a beam failure recovery configuration may be provided by the RAN node 5 to the UE 3 (e.g., using a 'BeamFailureRecoveryConfig' IE or the like) to configure the UE 3 with RACH resources and candidate beams for beam failure recovery in case of beam failure detection.

[0159] 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 3 (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 9 of a master cell group (MCG), associated with a master RAN node 5 (for dual connectivity), or of a secondary cell group (SCG), associated with a secondary RAN node 5 (for dual connectivity).

[0160] 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.

[0161] In more detail, a beam failure specific 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 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 RACH configuration.

[0162] 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.

[0163] 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.

[0164] 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 RACH preamble (e.g., using a 'ra-ssb-OccasionMaskIndex' IE or the like) may also be provided in the beam failure recovery configuration.

[0165] 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).

[0166] The list of information for the set of reference signals may include information which effectively allocates one or more dedicated 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.

[0167] 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.

[0168] 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 RA occasions (e.g., an 'ra-OccasionList' IE or the like) that the 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 RA occasions associated with the CSI-RS ID.

[0169] < Additional, Feature Specific, RACH Configuration > 　　The communication system 1 also supports the possibility of the RAN node 5 providing one or more 'additional' RACH configurations (e.g., using a list of one of more 'AdditionalRACH-Config' IEs or the like) along with the common RACH configuration 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 3 (e.g., an RRCReconfiguration message or the like)).

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

[0171] The features (or feature-combinations) that may be provided with a corresponding feature (or feature-combination) specific common 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.

[0172] The feature (or feature-combination) specific common RACH configuration may include a similar (or the same) set of random-access parameters as the standard or common 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 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). 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 RACH parameters. The feature (or feature-combination) specific 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).

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

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

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

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

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

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

[0179] Where appropriate, the UE 3 may identify / select an appropriate beam (SSB based and / or CSI-RS based) and corresponding RACH preamble for initiating a RACH procedure. For example, if the 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 a rsrp-ThresholdSSB IE / rsrp-ThresholdCSI-RS IE) as described above.

[0180] 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).

[0181] For example, when a 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)).

[0182] 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.

[0183] For a RACH transmission triggered by a PDCCH order, however, a PRACH 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 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 PRACH Mask Index values and associated meaning is provided in Table 3 below.

[0184] Table 3: PRACH Mask Index values

[0185] < SSB to RO mapping > 　　The mapping between the SSBs (and hence the beams), and the specific ROs (within the RACH slots) to be used by the UE 3, is defined by the parameters that are configured to the UE 3 as described above (e.g., by a common / dedicated RACH configuration provided system information and / or by RRC signalling as described above).

[0186] Depending on how the RACH is configured at the UE 3, the set of preambles, from which the preamble used by the UE 3 is selected for a given RO, may be divided into a number of subsets, each subset being respectively associated with a beam (and hence SSB) that of a plurality of beams / SSBs. Specifically, the preambles in the set of preambles available for the RO are sequentially numbered with associated preamble indexes. The SSBs may, initially, be sequentially mapped (i.e., in index order) to an associated subset of those preambles when arranged (and divided into subsets) in the order of their preamble indexes, where each subset associated with an SSB comprises the configured total number of different preambles for SSBs (e.g., by the parameter known as ssb-perRACH-OccasionAndCB-PreamblesPerSSB or the like).

[0187] For example, as mentioned above, the UE 3 may be provided with a number, N, of SSBs associated a single RO, where N may be 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 be an integer, e.g., 1, 2, 4, 8, or 16, to indicate that more than one SSB is associated with a single RO. The UE 3 may also be configured with a number, 'R', of contention-based preambles (for CBFD). Where N is less than 1 one SSB is mapped to 1 / N 'consecutive' valid ROs in frequency (if frequency multiplexed ROs are used) and time. Where N is greater than (or equal to) 1, N SSB / SSBs are mapped to single valid RO, where each SSB is associated with a different set of R contention-based preambles.

[0188] Specifically, the SSBs may be sequentially mapped (i.e., in index order) to a set of one or more preambles, and valid ROs in the following order: -　　in order of increasing preamble index within a single RO; -　　then in order of increasing frequency domain resource index / indices associated with the ROs (if more than one RO is provided in frequency for the same time domain resource); -　　then in order of increasing time domain resource index / indices associated with the ROs within a RACH slot; and / or -　　then, if necessary, in order of increasing RACH slot index / indices in which the associated ROs are provided.

[0189] < Additional RACH Resources / Enhanced RACH Resource Selection > 　　Each UE 3 and RAN node 5 of the communication system 1 are mutually configured to implement one or more enhancements to the RACH resource configuration and / or selection methods described above for supporting flexible and efficient RACH configuration and selection, in the context of SBFD and / or NES in particular.

[0190] < Additional RACH Resource Configuration > 　　Specifically, for UEs 3 that support SBFD operation and / or NES operation, the RAN node 5 is able to configure an additional (or different) set of RACH resources, and in particular, an additional (or different) set of feature specific (e.g., SBFD and / or NES specific) ROs, in addition to a set of non-feature specific RACH resources (i.e., ROs) for non-SBFD / non-NES capable UEs. It will, nevertheless, be appreciated that non-feature specific RACH resources (i.e., ROs) may, potentially, still be used by the UEs 3 that support SBFD operation and / or NES operation.

[0191] The RAN node 5 may, for example, be configured for indicating the additional (or different) set of ROs for SBFD and / or NES using an associated feature (or feature-combination) specific additional RACH configuration, as described above (e.g., using an appropriately configured 'AdditionalRACH-Config' IE or the like).

[0192] Alternatively (or additionally) the RAN node 5 may, nevertheless, be configured for indicating an additional (or different) set of ROs for SBFD and / or NES by extending a non-feature specific RACH configuration. For example, the RAN node 5 may be configured to use an extended common RACH configuration and / or extended dedicated RACH configuration described above (e.g., using the 'RACH-ConfigCommon' IE or the like in system information / RRC signalling and / or the 'RACH-ConfigDedicated' IE or the like in RRC signalling). Effectively, therefore, both the additional RACH resources (ROs) and non-feature specific RACH resources may be configurable using a single RACH configuration.

[0193] It will be appreciated that the non-feature specific set of ROs for use by the UE 3 may still be configured using a common RACH configuration and / or dedicated RACH configuration as described above (e.g., using a 'RACH-ConfigCommon' IE or the like in system information / RRC signalling and / or a 'RACH-ConfigDedicated' IE or the like in RRC signalling).

[0194] Beneficially, for UEs 3 that are both SBFD aware and NES capable, the RAN node 5 is able to configure different sets of additional RACH resources respectively based on SBFD considerations, and based on NES considerations. For example, an SBFD-aware UE 3 which supports NES, may be configured with one set of additional RACH resources (ROs) which occur in SBFD symbols / slots and another set of RACH resources (ROs) which are adaptable to take account of NES requirements (e.g., to take account of when a RAN node 5 is operating a cell 9 in a cell DRX ON state or a cell DRX OFF state).

[0195] < Considerations for RACH Resource Selection > 　　It will be appreciated that, in a case where the RAN node 5 configures a feature (or feature-combination) specific RACH resource set (in the manner described above) and the UE 3 selects an appropriate RACH resource set corresponding to the feature applicable to the type of random-access procedure it is initiating, the UE 3 would normally only be able to use the associated feature (or feature-combination) specific RACH resources (i.e., ROs). This implies that if the UE 3 is configured with additional RACH resources for SBFD and / or NES in this way, the UE 3 would always select the RACH resources configured for SBFD or NES - i.e., the UE 3 would not be able to use non-feature specific RACH resources (i.e., ROs). Whilst this is not a particular issue for at least some of the features for which a feature (or feature-combination) specific RACH resource set may be defined (e.g., associated with RedCap UEs 3, or the like, mentioned above), this may not be ideal in the context of SBFD and / or NES.

[0196] For SBFD, for example, one of the intended benefits of introducing additional RACH resources is to reduce RACH latency. This benefit may not always be realised if the UE 3 has to select an SBFD related feature (or feature-combination) specific set of ROs rather than, for example, being able to select the earliest RO among both the SBFD related feature (or feature-combination) specific set of ROs, and a non-feature specific set of non-feature specific ROs.

[0197] Moreover, for SBFD, in certain scenarios it may not be optimal for the UE 3 to select SBFD based RACH resources (e.g., ROs in SBFD specific slots / symbols) as they may have a lower coverage than non-feature specific RACH resources (e.g., ROs in dedicated UL slots / symbols). It might be beneficial, therefore, if the UE 3 were able to select RACH resources based on radio conditions experienced at the UE 3 (e.g., to select a in an SBFD specific slot / symbol, or a non-feature specific RO in a dedicated UL slot / symbol, taking account of the radio conditions).

[0198] Even though for NES, latency may not be as critical, if additional feature (or feature-combination) specific RACH resources (e.g., NES specific ROs) are relatively sparse (e.g., as compared to non-feature specific RACH resources), then it may still be beneficial for the UEs 3 to be able to select the non-feature specific RACH resources where the earliest RO configured by the additional feature (or feature-combination) specific RACH configuration may lead to an undesirably high latency (e.g., when the UE 3 needs to gain synchronisation). Moreover, the possibility that the additional RACH resources (e.g., NES specific ROs) may be deactivated for the UE 3 at certain times (e.g., for NES reasons) makes selection of an appropriate RO more complex.

[0199] Referring to the case where the RAN node 5 does not configure a feature (or feature-combination) specific RACH resource set, but instead uses an extended non-feature specific RACH configuration, the configured ROs may span both normal UL and SBFD symbols / slots and hence thus all ROs are selectable by the UE 3. However, in this scenario, RO selection based on feature specific RACH resource selection criteria is not possible and hence some RO selection flexibility may be lost.

[0200] Beneficially, therefore, as described in more detail later each UE 3 and RAN node 5 of the communication system 1 are mutually configured to support one or more enhanced RACH resource selection criteria / mechanisms that take one or more of the above considerations into account. The enhanced RACH resource selection criteria / mechanisms include, for example, RACH resource selection for the purposes of: -　　RACH transmission initiated by a PDCCH order (e.g., where the UE 3 receives, from the RAN node 5, an SSB index value and associated PRACH mask index indicating one or more ROs for the RACH preamble transmission); -　　RACH transmission for an initial random-access attempt initiated by the UE 3 where the UE 3 selects the SSB resource on its own (i.e., there is no RAN node signalling of a RACH resource to be used); and -　　RACH transmission initiated by the UE 3 as part of reattempted random-access (e.g., following a failed earlier random-access attempt).

[0201] Beneficially, the enhanced RACH resource selection criteria / mechanisms are able to take account of NES related requirements and SBFD related requirements separately, considering that different sets of additional RACH resources may be configured at the same UE 3, based on SBFD considerations, and for NES considerations, respectively.

[0202] Beneficially, the NES related RACH resource selection criteria / mechanisms are configured to have a minimal impact on the power savings achievable at the RAN node 5 as a result of any NES enhancements implemented at the RAN node 5.

[0203] Beneficially, the SBFD related RACH resource selection criteria / mechanisms are configured to minimise latency arising from RACH resource selection whilst, at the same time, supporting the potential requirement for a RACH transmission from the UE 3 to be made using a higher transmission power in SBFD symbols / slots than in non-SBFD symbols / slots (e.g., conventional uplink symbols / slots).

[0204] It will be appreciated that the RACH resource selection criteria / mechanisms described are not mutually exclusive and all, or a subset of the enhancements, may be incorporated into a communication system to provide a commensurate benefit. Nevertheless, the RACH resource selection criteria / mechanisms are also not reliant on one another and so may be implemented in the communication system individually to provide a commensurate benefit.

[0205] < SSB to RO Mapping in the context of RO Adaptation > 　　As described in more detail later, RO adaptation may be supported in which one or more additional feature / feature-combination (e.g. NES) specific ROs may be activated (enabled) and / or deactivated (removed) by the network (e.g., to support local NES requirements). Moreover, as described in more detail later, RO adaptation may be supported in which different RO periodicities (or frequencies of occurrence) may be applicable at different timings (e.g., to support local NES requirements). Similarly, as described in more detail later, RO adaptation may be supported in which an entire set of additional feature / feature-combination (e.g. NES) specific ROs may be activated (enabled) and / or deactivated (removed) by the network (e.g., to support local NES requirements).

[0206] As explained above each RO may be associated with one or more SSBs and each SSB may be associated with one or more ROs. In the absence of RO adaptation, the UE 3 determines a set of ROs which can be used by determining the ROs that are mapped to a specific SSB / CSI-RS. However, it will be appreciated that, if additional feature / feature-combination (e.g. NES) specific ROs configured at the UE 3 are adapted over time (e.g., based on NES requirements), then the adaptation may affect the SSB to RO mapping.

[0207] By way of example only, consider a hypothetical scenario in which: the number of SSBs per RO is configured to be 1 by network for the additional feature / feature-combination specific RACH resources; and there are two SSBs transmitted by the cell (e.g., SSB0, and SSB1).

[0208] Assume that, in this hypothetical scenario, a configuration of additional feature / feature-combination specific RACH resources is provided to the UE 3 that indicates a set of available ROs (without adaption) comprising RO0, RO1, RO2, and RO3 within a given radio frame.

[0209] In this case, the conventional SSB to RACH occasion mapping implies the following mapping: -　　RO0 mapped to SSB0; -　　RO1 mapped to SSB1; -　　RO2 mapped to SSB0; and -　　RO3 mapped to SSB1.

[0210] However, if the RAN node 5 indicates that RO1 is deactivated or removed (e.g., the RO should not be used for preamble transmission), as a result of RO adaptation, then it is not clear as to how the deactivated / removed RO (RO1) should be treated.

[0211] Beneficially, therefore, in order to cater for such RO adaptability, 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 mechanisms for SSB to RO mapping.

[0212] < RAR Reception > 　　As explained above, an RA-RNTI may be used by the UE 3 to receive a random access response (RAR) following a random-access transmission of a preamble (Msg1) and different ROs within a system frame may be associated with different RA-RNTI values to ensure that an RAR for a given random-access preamble transmission can be properly addressed to only the UE 3 that has used that given RO. It will be appreciated that if the RA-RNTI values are the same for two ROs, then there is a risk of confusion where two UEs 3 which have used different ROs act on the same RAR message.

[0213] In conventional systems, to ensure this uniqueness, the RA-RNTI is computed, as described above (i.e., RA-RNTI = 1 + s_id + 14 × t_id + 14 × 80 × f_id + 14 × 80 × 8 × ul_carrier_id).

[0214] However, when additional feature / feature-combination specific RACH resources are configured to the UE 3 (especially when frequency division modulated with non-feature specific RACH resources) then there is a risk that RA-RNTI confusion may still occur as one non-feature specific RO and an additional feature / feature-combination specific RO may have the same RA-RNTI value.

[0215] Beneficially, therefore, in order to cater for such RA-RNTI confusion risk, 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 mechanisms for avoiding / reducing the risk of RA-RNTI confusion.

[0216] < SBFD / NES Related RO Selection for PDCCH Order > 　　As mentioned above each UE 3 and RAN node 5 of the communication system 1 may be mutually configured to support one or more enhanced RACH resource selection criteria / mechanisms including, for example, RACH resource selection for the purposes of RACH transmission initiated by a PDCCH order.

[0217] Possible mechanisms for RACH resource selection, for the purposes of a RACH transmission initiated by a PDCCH order, will now be described in more detail with reference to Figs. 6, 7A, 7B, 7C, 7D and 7E.

[0218] Fig. 6 is a simplified sequence diagram illustrating a number of different potential mechanisms for RACH resource selection, for the purposes of a RACH transmission initiated by a PDCCH order, that may be used in the communication system 1. Figs. 7A, 7B, 7C, 7D and 7E are simplified illustrations of how each of the mechanisms for RACH resource selection shown in Fig. 6 operate.

[0219] Referring to Fig. 6, the mechanisms for RACH resource selection occur in the context of a scenario in which the UE 3 has been configured, at S610, with at least one set of RACH resources including both non-feature specific ROs and additional feature / feature-combination (e.g., SBFD / NES) specific ROs. It will be appreciated that the configuration of the one or more sets of RACH resources may comprise configuring a non-feature specific set of ROs and one or more additional sets of feature / feature-combination (e.g., SBFD / NES) specific ROs separately.

[0220] For example, a non-feature specific set of ROs may be configured, as shown in Fig. 6, using a common RACH configuration as described above (e.g., using a 'RACH-ConfigCommon' IE or the like in system information / RRC signalling). The one or more feature / feature-combination (e.g., SBFD / NES) specific set of ROs may be configured, as shown in Fig. 6, using an associated feature (or feature-combination) specific additional common RACH configuration, as described above (e.g., using an appropriately configured 'AdditionalRACH-Config' IE or the like). It will be appreciated that the non-feature specific set of ROs and one or more feature / feature-combination (e.g., SBFD / NES) specific set of ROs may be configured at the same time by the same message, or at different times in different messages.

[0221] Nevertheless, the non-feature specific ROs and additional feature / feature-combination (e.g., SBFD / NES) specific ROs may be configured by an extended conventional (non-feature specific) RACH configuration as described above.

[0222] When a decision is made by the RAN node 5 to trigger a RACH procedure at the UE 3, at S612, the RAN node 5 selects an appropriate RO for the UE 3 to use. It will be appreciated here that it is assumed that, when PDCCH order is initiated, the RAN node 5 is aware of UE radio conditions and hence can select an appropriate RO for the UE 3 (between non-feature specific and additional feature / feature-combination specific RACH resources).

[0223] The RAN node 5 then sends an appropriate PDCCH order to the UE 3 (e.g., using a DCI based on DCI format 1_0) to indicate the selected RO (e.g., explicitly, or implicitly by indicating an SSB with which the RO is associated) along with any other appropriate information as needed (e.g., information indicating a preamble to be used). Different options for sending the PDCCH orders are shown at S614a to S614e. It will be appreciated that the different options for sending the PDCCH orders are not mutually exclusive. For example, different options may be used at different times depending on one or more factors including for example: the prevailing radio conditions; whether the additional ROs are SBFD related, or NES related; the reason that the RACH procedure is required; and / or the like. Nevertheless, any one (or subset) of the different options for sending the PDCCH orders may be implemented in the communication system 1.

[0224] Referring to Fig. 7A, for example, the RAN node 5 may be configured for, in at least some situations, selecting an RO only from the non-feature specific ROs (despite the fact that additional feature / feature-combination specific ROs have been configured). The RAN node 5 then sends to the UE 3, at S614a in Fig. 6, a PDCCH order indicating the selected RO corresponding to the non-feature specific RACH resources (i.e. RACH resources which are available for all UE types in the cell 9). It will be appreciated that this option is particularly beneficial for a scenario in which it is particularly desirable to ensure the RACH procedure reliability necessary (e.g., for SBFD) in the context of RACH procedure triggered by PDCCH order. This option may also be appropriate for a less complex, stand-alone, PDCCH order mechanism that does not cater for additional feature / feature-combination specific RO selection (albeit that these may still be configured by the RAN node 5 and beneficially used for UE-side RO selection).

[0225] Referring to Fig. 7B, the RAN node 5 may alternatively or additionally be configured for, in at least some situations, selecting an RO from the additional feature / feature-combination specific ROs (and not from the non-feature specific ROs that have been configured). The RAN node 5 then sends to the UE 3, at S614b in Fig. 6, a PDCCH order indicating the selected additional feature / feature-combination specific RO. Nevertheless, it will be appreciated that if additional feature / feature-combination specific ROs have not been configured, then the RAN node 5 may still select (and the PDCCH order may still indicate) one or more non-feature specific ROs (e.g., corresponding to the associated common RACH resource configuration). It will be appreciated that this option is particularly beneficial for a scenario in which the set of additional feature / feature-combination specific ROs and the set of non-feature specific ROs each represent a subset of the same ('common') set of ROs configured by the same RACH configuration (e.g., by a single extended version of the common RACH configuration or the like). This is because where a single RACH configuration is used to define both the additional feature / feature-combination specific ROs and the set of non-feature specific ROs discriminating between feature / feature-combination specific ROs at the UE 3 (e.g., for UE-side RO selection) would require additional UE complexity that not every UE 3 may possess.

[0226] Referring to Fig. 7C, the RAN node 5 may alternatively or additionally be configured for, in at least some situations, selecting any RO from the additional feature / feature-combination specific ROs, and the non-feature specific ROs (which may be configured separately as distinct RO sets or via a single extended configuration as a single combined RO set). The RAN node 5 then sends to the UE 3, at S614c in Fig. 6, a PDCCH order indicating the selected RO from among the additional feature / feature-combination specific ROs, and the non-feature specific ROs. In this case, the UE 3 may thus count all the available ROs (e.g., both non-feature specific ROs and additional ROs) and PDCCH order may indicate a specific RO from among all the available ROs as if they form a single set of ROs (even configured separately as distinct RO sets).

[0227] Referring to Fig. 7D, like Fig. 7C, the RAN node 5 of this example is configured for, in at least some situations, selecting any RO from the additional feature / feature-combination specific ROs, and the non-feature specific ROs. In this example, however, when the RAN node 5 sends to the UE 3, at S614d in Fig. 6, a PDCCH order, in addition to providing an indication of the selected RO, the RAN node 5 also provides an additional indication (explicitly or implicitly) of whether the selected RO corresponds to the non-feature specific RACH resources or to the additional feature / feature-combination specific RACH resources. The additional indication may, for example, be provided explicitly in the PDCCH order, for example, by using a DCI based on a modified version of the conventional DCI format 1_0 for a PDCCH order, in which a field is included that indicates which RACH resources / resource set / configuration (i.e., between additional RACH resources and non-feature specific RACH resources) the indicated RO is based on. It will be appreciated that one or more of the reserved bits of a conventional PDCCH order may be adapted for this purpose.

[0228] Nevertheless, the RAN node 5 may indicate the type of RO implicitly by using a first set of one or more radio resources for sending a PDCCH order indicating a selected RO corresponding to the non-feature specific RACH resources and a second (different) set of one or more radio resources for sending a PDCCH order indicating a selected RO corresponding to the additional feature / feature-combination specific RACH resources. Similarly, the UE 3 may be configured to determine whether the RO indicated in the PDCCH order corresponds to the non-feature specific RACH, or to the additional feature / feature-combination specific RACH resources, based on the radio resources via which the PDCCH order is received. By way of example only, the RAN node 5 may be configured to use SBFD symbols / slots to send a PDCCH order indicating a selected SBFD specific RO. Similarly, the UE 3 may be configured to assume that a PDCCH order received in an SBFD symbol / slot indicates one or more additional SBFD specific ROs (i.e., that overlap / coincide with an SBFD symbol / slot) that may be used.

[0229] It will also be appreciated a different message may be used for a PDCCH order indicating a selected RO corresponding to non-feature specific RACH resources than for a PDCCH order corresponding to additional feature / feature-specific ROs. The different messages may, for example, comprise different DCIs that that use different DCI formats, or different DCIs that use the same format but that have a CRC scrambled using different RNTIs. Hence, based on the type of message received, the UE 3 can determine the type of RO that has been indicated (i.e., whether the RO is from a non-feature specific RACH resource set or from an additional feature / feature-combination specific RACH resource set).

[0230] Referring to Fig. 7E, the RAN node 5 of this example is configured for, when selecting an RO from a set of additional feature / feature-combination specific RACH resources, to send a PDCCH order to the UE 3 (at S614e in Fig. 6) that, in addition to providing an indication of the selected RO, also activates the corresponding set of additional feature / feature-combination specific RACH resources. In this case, for example, RRC signalling (or the like) may be used to configure one or more sets of additional feature / feature-combination specific RACH resources to the UE 3 (e.g., as described previously). However, the additional feature / feature-combination specific RACH resources may not be activated at the UE 3 by default but may, instead, be activated at the UE 3 by a network command such as a PDCCH order. The activation may, for example, be indicated explicitly using the PDCCH order, for example, by using a DCI based on a modified version of the conventional DCI format 1_0 for a PDCCH order, in which a field is included that indicates which RACH resources / configuration are activated. It will be appreciated that this option is particularly beneficial in the context of NES as it effectively allows adaption of the available ROs to take account of NES considerations (e.g., an ON / OFF DRX cycle at the RAN node 5).

[0231] It will be appreciated that the RAN node 5 may be configured to be able to use one or more of the different options described with reference to Figs. 6, 7A, 7B, 7C, 7D, and 7E. The RAN node 5 may, for example, be configured to be able to use different options for different UEs 3 and / or scenarios. For example, on or more options may be applicable for SBFD / and SBFD-aware UE 3, while another one or more options may be applicable for NES / an NES capable UE 3. Moreover, one or more options may be applicable for combined SBFD and NES / an SBFD-aware and NES capable UE 3.

[0232] It will also be appreciated that while the above options are described from the perspective of a RAN node-based implementation, they could (alternatively or additionally) each be realised based on a UE side implementation of RO counting. For example, the first option (i.e., as illustrated in Fig. 7A) could be realised by configuring the UE 3 to count only non-feature specific based ROs when determining an indicated RO in a PDCCH order. Each other options can also be similarly implemented at the UE 3 by configuring the UE 3 to count appropriate ROs.

[0233] < UE-side RO Selection for an Initial Random-Access Attempt > 　　As mentioned above each UE 3 and RAN node 5 of the communication system 1 may be mutually configured to support one or more enhanced RACH resource selection criteria / mechanisms including, for example, RACH resource selection at the UE 3 for the purposes of RACH transmission initiated by the UE 3 for an initial random access attempt.

[0234] Possible mechanisms for RACH resource selection, for the purposes of a RACH transmission initiated by a PDCCH order, will now be described in more detail with reference to Figs. 8 to 11.

[0235] Fig. 8 is a simplified sequence diagram illustrating a procedure for RACH resource selection, for the purposes of an initial random-access attempt initiated by a UE 3, that may be used in the communication system 1.

[0236] In the example of Fig. 8, as described in more detail below, for an initial random-access attempt of a random access procedure, the UE 3 may select the first RO among all of the RACH resources available to the UE 3 (including both non-feature specific RACH resources and additional, feature / feature-combination specific, RACH resources). This example may be particularly applicable for a scenario in which an RSRP threshold for SSB / CSI-RS selection configured by the RAN node 5 is the same for both the non-feature specific RACH resources and for the additional, feature / feature-combination specific, RACH resources.

[0237] Referring to Fig. 8, the mechanism for RACH resource selection in this example occurs in the context of a scenario in which the UE 3 has been configured, at S810, with at least one set of RACH resources including both non-feature specific ROs and additional feature / feature-combination (e.g., SBFD / NES) specific ROs. It will be appreciated that the configuration of the one or more sets of RACH resources may comprise configuring a non-feature specific set of ROs and one or more additional sets of feature / feature-combination (e.g., SBFD / NES) specific ROs separately.

[0238] For example, a non-feature specific set of ROs may be configured using a common RACH configuration as described above (e.g., using a 'RACH-ConfigCommon' IE or the like in system information / RRC signalling). The one or more feature / feature-combination (e.g., SBFD / NES) specific set of ROs may be configured using an associated feature (or feature-combination) specific additional common RACH configuration, as described above (e.g., using an appropriately configured 'AdditionalRACH-Config' IE or the like). It will be appreciated that the non-feature specific set of ROs and one or more feature / feature-combination (e.g., SBFD / NES) specific set of ROs may be configured at the same time by the same message, or at different times in different messages.

[0239] Nevertheless, the non-feature specific ROs and additional feature / feature-combination (e.g., SBFD / NES) specific ROs may be configured by an extended conventional (non-feature specific) RACH configuration as described above.

[0240] When configuring the non-feature specific RACH resources and the additional, feature / feature-combination specific, RACH resources, the RAN node 5 may also configure one or more associated RSRP thresholds for SSB / CSI-RS selection. For example, one or more RSRP thresholds for SSB / CSI-RS selection may be configured that are common to the non-feature specific RACH resources and to the additional, feature / feature-combination specific, RACH resources. Nevertheless, one or more RSRP thresholds for SSB / CSI-RS selection may be configured separately for the non-feature specific RACH resources and for the additional, feature / feature-combination specific, RACH resources.

[0241] When a decision is made by the UE 3 to trigger random-access, at S812, the UE 3 needs to select / identify an appropriate valid RO that maps to a corresponding SSB beam and select / identify an appropriate preamble. To facilitate this the UE 3 may perform, at S814, associated measurements on SSBs (and / or possibly CSI-RS depending on the reason for the random-access) transmitted by the RAN node 5 and make a corresponding SSB (and / or possibly CSI-RS) selection to allow appropriate RO and preamble selection.

[0242] When selecting / identifying the RO, in the example of Fig. 8, the UE 3 is configured to select / identify, at S816, the first available valid RO (e.g., that maps to a selected SSB / beam) from among all available ROs, including both non-feature specific and additional feature / feature-combination specific ROs configured by the RAN node 5. It will be appreciated that the ability to select / identify the first available RO from among all available ROs may (optionally), for example, be conditional on one or more RSRP thresholds for SSB / CSI-RS selection configured by the RAN node 5 for the non-feature specific RACH resources being the same as one or more corresponding RSRP thresholds for SSB / CSI-RS selection configured by the RAN node 5 for the additional, feature / feature-combination specific, RACH resources.

[0243] Alternatively, the UE 3 may be configured to select / identify, at S816, the first available valid RO (e.g., that maps to a selected SSB / beam) from among all available ROs, including both non-feature specific and additional feature / feature-combination specific ROs configured by the RAN node 5 if the time difference between the first available valid non-feature specific RO and the first available valid additional feature / feature-combination specific RO is greater than a threshold time period. Otherwise, if the time difference between the first available valid non-feature specific RO and the first available valid additional feature / feature-combination specific RO is less than the threshold time, then the UE 3 may be configured to always select the first available valid additional feature / feature-combination specific RO. This approach would beneficially help to reduce the load on the non-feature specific ROs and to improve system performance.

[0244] The UE 3 will also select / identify the appropriate preamble based on the configuration of the one or more sets of RACH resources provided by the RAN node 5 and will make an initial access attempt, at S818, using the selected / identified RO to send the selected / identified preamble.

[0245] Fig. 9 is a simplified sequence diagram illustrating another procedure for RACH resource selection, for the purposes of an initial random-access attempt initiated by a UE 3, that may be used in the communication system 1.

[0246] In the example of Fig. 9, as described in more detail below, for an initial random-access attempt of a random access procedure, the UE 3 is allowed to select a valid RO that occurs in an SBFD symbol / slot (e.g., an additional feature / feature-combination (e.g., SBFD) specific RO) if a signal strength / pathloss measured for an SSB / CSI-RS meets a threshold specifically defined for selecting between RACH resource sets - e.g., for allowing selection of feature / feature-combination specific ROs (e.g., SBFD specific ROs) from an associated feature / feature-combination specific set of ROs.

[0247] Referring to Fig. 9, the mechanism for RACH resource selection in this example occurs in the context of a scenario in which the UE 3 has been configured, at S910, with at least one set of RACH resources including both non-feature specific ROs and additional feature / feature-combination (e.g., SBFD / NES) specific ROs. It will be appreciated that the configuration of the one or more sets of RACH resources may comprise configuring a non-feature specific set of ROs and one or more additional sets of feature / feature-combination (e.g., SBFD / NES) specific ROs separately.

[0248] For example, a non-feature specific set of ROs may be configured using a common RACH configuration as described above (e.g., using a 'RACH-ConfigCommon' IE or the like in system information / RRC signalling). The one or more feature / feature-combination (e.g., SBFD / NES) specific set of ROs may be configured using an associated feature (or feature-combination) specific additional common RACH configuration, as described above (e.g., using an appropriately configured 'AdditionalRACH-Config' IE or the like). It will be appreciated that the non-feature specific set of ROs and one or more feature / feature-combination (e.g., SBFD / NES) specific set of ROs may be configured at the same time by the same message, or at different times in different messages.

[0249] Nevertheless, the non-feature specific ROs and additional feature / feature-combination (e.g., SBFD / NES) specific ROs may be configured by an extended conventional (non-feature specific) RACH configuration as described above.

[0250] When configuring the non-feature specific RACH resources and the additional, feature / feature-combination specific, RACH resources, the RAN node 5 also configures one or more thresholds for the purposes of RACH resource set selection. The one or more thresholds may, for example, include one or more SSB / CSI-RS signal strength (e.g. RSRP) thresholds and / or one or more thresholds for path loss that the UE 3 experiences for SSB / CSI-RS.

[0251] One or more thresholds for the purposes of RACH resource set selection may, for example, be configured in a similar manner to the threshold used for selection of SSB / CSI-RS resources during a random-access procedure (e.g., using an 'rsrp-ThresholdSSB' IE and / or 'rsrp-ThresholdCSI-RS' IE as described previously). However, in this case, different values of the threshold are defined for SBFD specific ROs occurring during SBFD symbols / slots and non-feature specific ROs occurring during non-SBFD (e.g., UL only) symbols / slots.

[0252] Alternatively (or additionally) one or more dedicated thresholds may, for example, be configured specifically for the purposes of RACH resource set selection. In this case, once a RACH resource set is selected, then the UE 3 may still use one or more other configured thresholds (e.g., an 'rsrp-ThresholdSSB' IE and / or 'rsrp-ThresholdCSI-RS' IE as described previously) to select the SSB / CSI-RS for the purposes of RO selection within the selected RACH resource set. For example, one or more RSRP thresholds for SSB / CSI-RS selection may be configured that are common to the non-feature specific RACH resources and to the additional, feature / feature-combination specific, RACH resources. Nevertheless, one or more RSRP thresholds for SSB / CSI-RS selection may be configured separately for the non-feature specific RACH resources and for the additional, feature / feature-combination specific, RACH resources.

[0253] Accordingly, in this example, when a decision is made by the UE 3 to trigger random-access, at S912, the UE 3 not only selects / identifies an appropriate valid RO that maps to a corresponding SSB beam (and an appropriate preamble) but also selects / identifies an appropriate RACH resource set.

[0254] Specifically, the UE 3 may perform, at S914, associated measurements on SSBs (and / or possibly CSI-RS depending on the reason for the random-access) transmitted by the RAN node 5 and make an appropriate RACH resource set selection and a corresponding SSB (and / or possibly CSI-RS) selection to allow appropriate RO and preamble selection.

[0255] When a signal strength / pathloss measured for an SSB / CSI-RS meets a corresponding configured threshold for the purposes of resource set selection the UE 3 may be allowed to select / identify an appropriate valid RO (e.g., that maps to a selected SSB / beam) from among all available ROs configured by the RAN node 5, for example including both non-feature specific ROs (e.g., that occur in UL only symbols / slots) and additional feature / feature-combination (e.g., SBFD) specific ROs (e.g., that occur in SBFD symbols / slots), as seen at S916a.

[0256] Nevertheless, when a signal strength / pathloss measured for an SSB / CSI-RS meets a corresponding configured threshold for the purposes of resource set selection the UE 3 may, alternatively, be allowed to select / identify an appropriate valid RO (e.g., that maps to a selected SSB / beam) configured by the RAN node 5 from among ROs that occur in SBFD symbols / slots (e.g., additional feature / feature-combination (e.g., SBFD) specific ROs), as seen at S916b.

[0257] Otherwise, when a signal strength / pathloss measured for an SSB / CSI-RS does not meet the corresponding configured threshold for the purposes of resource set selection the UE 3 may only be allowed to select / identify an appropriate valid RO (e.g., that maps to a selected SSB / beam) configured by the RAN node 5 from among ROs that occur in UL-only symbols / slots (e.g., non-feature specific ROs), as seen at S916c.

[0258] The UE 3 will also select / identify the appropriate preamble based on the configuration of the one or more sets of RACH resources provided by the RAN node 5 and will make an initial access attempt, at S918, using the selected / identified RO to send the selected / identified preamble.

[0259] It will be appreciated that, beneficially, it is possible to reuse existing information structures for configuring the UE 3 with a threshold for the purposes of resource set selection. For example, where additional ROs for SBFD symbols are configured using the existing AdditionalRACH-Config IE, the threshold for the purposes of resource set selection may be configured using the separate RSRP threshold IE defined as part of the AdditionalRACH-Config IE. Nevertheless, for this to work efficiently, a new restriction may need to be defined to restrict ROs configured by such an AdditionalRACH-Config IE such that an RO is only treated as valid by the UE 3 if it occurs in an SBFD symbol / slot.

[0260] Fig. 10 is a simplified sequence diagram illustrating another procedure for RACH resource selection, for the purposes of an initial random-access attempt initiated by a UE, that may be used in the communication system 1.

[0261] In the example of Fig. 10, as described in more detail below, the UE 3 selects an RO belonging to additional feature / feature-combination specific ROs if those additional ROs are specifically activated / enabled by the RAN node 5. It will be appreciated that this particularly applicable, in the context of NES, where some of the ROs may need to be inactive at the time when the UE 3 needs to initiate a random-access attempt and hence the UE 3 may need to initiate the random-access attempt using non-feature specific ROs. Nevertheless, when the additional feature / feature-combination specific ROs are active, it may be beneficial for the UE 3 to be able to initiate random-access using the additional feature / feature-combination specific ROs. For example, if additional feature / feature-combination specific ROs (which can be activated / enabled or deactivated / removed) are configured for NES (e.g., using an AdditionalRACH-Config IE or the like), the UE 3 may be configured to select a RACH resource set from which to select an RO for initiating random-access only if at least one RO is activated / enabled within that RACH resource set.

[0262] Referring to Fig. 10, the mechanism for RACH resource selection in this example occurs in the context of a scenario in which the UE 3 has been configured, at S1010, with at least one set of RACH resources including both non-feature specific ROs and additional feature / feature-combination (e.g., SBFD / NES) specific ROs. It will be appreciated that the configuration of the one or more sets of RACH resources may comprise configuring a non-feature specific set of ROs and one or more additional sets of feature / feature-combination (e.g., SBFD / NES) specific ROs separately.

[0263] For example, a non-feature specific set of ROs may be configured using a common RACH configuration as described above (e.g., using a 'RACH-ConfigCommon' IE or the like in system information / RRC signalling). The one or more feature / feature-combination (e.g., SBFD / NES) specific set of ROs may be configured using an associated feature (or feature-combination) specific additional common RACH configuration, as described above (e.g., using an appropriately configured 'AdditionalRACH-Config' IE or the like). It will be appreciated that the non-feature specific set of ROs and one or more feature / feature-combination (e.g., SBFD / NES) specific set of ROs may be configured at the same time by the same message, or at different times in different messages.

[0264] Nevertheless, the non-feature specific ROs and additional feature / feature-combination (e.g., SBFD / NES) specific ROs may be configured by an extended conventional (non-feature specific) RACH configuration as described above.

[0265] In this example, when configuring the additional feature / feature-combination specific ROs, the RAN node 5 may also configure all (or a subset) of them to be initially deactivated / removed (or activated / enabled) for possible subsequent activation / enablement and / or deactivation / removal by the RAN node 5, as seen at S1011. It will be appreciated that the initially configured feature / feature-combination specific, RACH resources, may be treated as deactivated (or activated) by default or may be explicitly activated / deactivated (e.g., by an appropriate IE in system information and / or an RRC message used for configuring the RACH resources). It will also be appreciated that the timing of the activation / deactivation indication from the RAN node 5 shown at S1011 is purely illustrative, such activation / deactivation may occur at any suitable time.

[0266] It will be appreciated for example that, all (or a subset) of the additional feature / feature-combination specific ROs, may be activated / enabled and / or deactivated / removed semi-statically by the RAN node 5, e.g., using layer 3 (L3) signalling (e.g. an appropriate RRC message). It will also be appreciated that, alternatively or additionally, all (or a subset) of the additional feature / feature-combination specific ROs, may be activated / enabled and / or deactivated / removed dynamically by the RAN node 5, e.g., using layer 1 (L1) / layer 2 (L2) signalling (e.g. via a MAC CE and / or DCI).

[0267] When a decision is made by the UE 3 to trigger random-access, at S1012, the UE 3 needs to select / identify an appropriate valid RO that maps to a corresponding SSB beam and select / identify an appropriate preamble. To facilitate this the UE 3 may perform, at S1014, associated measurements on SSBs (and / or possibly CSI-RS depending on the reason for the random-access) transmitted by the RAN node 5 and make a corresponding SSB (and / or possibly CSI-RS) selection to allow appropriate RO and preamble selection.

[0268] When selecting / identifying the RO to use, in the example of Fig. 10, the UE 3 is configured to select / identify, at S1016, the RACH resource set from which to select ROs based on whether or not one or more valid additional feature / feature-combination specific ROs configured by the RAN node 5 are activated / enabled.

[0269] When one or more valid additional feature / feature-combination specific ROs configured by the RAN node 5 are activated / enabled the UE 3 may be configured to select the corresponding additional feature / feature-combination specific RACH resource set for RO selection. Hence, the UE 3 may select / identify an appropriate valid RO (e.g., that maps to a selected SSB / beam) from among the activated / enabled additional feature / feature-combination (e.g., NES) specific ROs, as seen at S1016a. Nevertheless, it will be appreciated that, in some cases, the UE 3 may still be allowed to select / identify an appropriate valid RO from among valid non-feature specific ROs.

[0270] Otherwise, when no valid additional feature / feature-combination specific ROs configured by the RAN node 5 are activated / enabled, the UE 3 may be configured to select the corresponding non-feature specific RACH resource set for RO selection. Hence, the UE 3 may select / identify an appropriate valid RO (e.g., that maps to a selected SSB / beam) only from among non-feature specific ROs, as seen at S1016b.

[0271] The UE 3 will also select / identify the appropriate preamble based on the configuration of the one or more sets of RACH resources provided by the RAN node 5 and will make an initial access attempt, at S1018, using the selected / identified RO to send the selected / identified preamble.

[0272] Fig. 11 is a simplified sequence diagram illustrating another procedure for RACH resource selection, for the purposes of an initial random-access attempt initiated by a UE 3, that may be used in the communication system 1.

[0273] In the example of Fig. 11, as described in more detail below, the RAN node 5 indicates (e.g., within a configuration of additional feature / feature-specific RACH resources) whether the UE 3 should select valid ROs, only from an additional feature / feature-specific RACH resource set, for the purposes of an initial random-access attempt or may select any valid RO from among any of the configured RACH resources available at the UE 3.

[0274] Referring to Fig. 11, the mechanism for RACH resource selection in this example occurs in the context of a scenario in which the UE 3 has been configured, at S1110, with at least one set of RACH resources including both non-feature specific ROs and additional feature / feature-combination (e.g., SBFD / NES) specific ROs. It will be appreciated that the configuration of the one or more sets of RACH resources may comprise configuring a non-feature specific set of ROs and one or more additional sets of feature / feature-combination (e.g., SBFD / NES) specific ROs separately.

[0275] For example, a non-feature specific set of ROs may be configured using a common RACH configuration as described above (e.g., using a 'RACH-ConfigCommon' IE or the like in system information / RRC signalling). The one or more feature / feature-combination (e.g., SBFD / NES) specific set of ROs may be configured using an associated feature (or feature-combination) specific additional common RACH configuration, as described above (e.g., using an appropriately configured 'AdditionalRACH-Config' IE or the like). It will be appreciated that the non-feature specific set of ROs and one or more feature / feature-combination (e.g., SBFD / NES) specific set of ROs may be configured at the same time by the same message, or at different times in different messages.

[0276] Nevertheless, the non-feature specific ROs and additional feature / feature-combination (e.g., SBFD / NES) specific ROs may be configured by an extended conventional (non-feature specific) RACH configuration as described above.

[0277] In this example, when configuring the feature / feature-combination specific, RACH resources, the RAN node 5 also provides an indication (e.g., within a configuration of additional feature / feature-specific RACH resources) that the UE 3 should select valid ROs only from an additional feature / feature-specific RACH resource set, for the purposes of the initial random-access attempt, or that the UE 3 may select any valid RO from among any of the configured RACH resources available at the UE 3.

[0278] The indication that the UE 3 should select valid ROs only from an additional feature / feature-specific RACH resource set, or that the UE 3 may select any valid RO from among any of the configured RACH resources available at the UE 3, may be provided in any suitable manner. For example, the indication may be configured to indicate that the UE 3 should select valid ROs only from an additional feature / feature-specific RACH resource set based on the content of, and / or the presence (or absence) of, a corresponding indication field / IE. Alternatively (or additionally), the indication may be configured to indicate that the UE 3 may select any valid RO from among any of the configured RACH resources available at the UE 3 based on the content of, and / or the presence (or absence) of, a corresponding indication field / IE.

[0279] The indication may, for example, be provided as an indication field / IE that is specified (or present) to indicate that the UE 3 shall select an RO only from an additional feature / feature-specific RACH resource set.

[0280] Nevertheless, the indication may, for example, be provided as an indication field / IE that is specified (or present) to indicate that the UE 3 may select any valid RO from among any of the configured RACH resources available at the UE 3 (i.e., from among both non-feature specific ROs and additional feature / feature-combination (e.g., SBFD / NES) specific ROs).

[0281] It will be appreciated that the indication may be included in any suitable new or existing IE and may be provided, for example, in the system information (e.g., SIB1) and / or a dedicated RRC message (e.g., an RRC reconfiguration message) used to configure the RACH resources. Either indication may be included, for example, in any of the following existing IEs that will be familiar to those skilled in the art: 'BWP-UplinkCommon' IE; an 'AdditionalRACH-Config' IE; a 'RACH-ConfigCommon' IE; a 'RACH-ConfigGeneric' IE; a 'FeatureCombinationPreambles' IE; and / or the like. It will be appreciated that some of the indicated IEs may form part of other indicated IEs (e.g., the 'RACH-ConfigGeneric' IE may form part of a 'RACH-ConfigCommon' IE as explained earlier) in which case the indication may be present in a plurality of the indicated IEs (e.g., in a nested manner).

[0282] When a decision is made by the UE 3 to trigger random-access, at S1112, the UE 3 needs to select / identify an appropriate valid RO that maps to a corresponding SSB beam and select / identify an appropriate preamble. To facilitate this the UE 3 may perform, at S1114, associated measurements on SSBs (and / or possibly CSI-RS depending on the reason for the random-access) transmitted by the RAN node 5 and make a corresponding SSB (and / or possibly CSI-RS) selection to allow appropriate RO and preamble selection.

[0283] When selecting / identifying the RO to use, in the example of Fig. 11, the UE 3 is configured to select / identify, at S1116, the RACH resource set from which to select ROs based on the indication that the UE 3 should select valid ROs only from an additional feature / feature-specific RACH resource set, or that the UE 3 may select any valid RO from among any of the configured RACH resources available at the UE 3.

[0284] In a case where the RAN node 5 indicates (e.g., by the content and / or presence / absence of the indication) that the UE 3 should select valid ROs only from an additional feature / feature-specific RACH resource set, the UE 3 may select / identify an appropriate valid RO (e.g., that maps to a selected SSB / beam) from among the additional feature / feature-combination (e.g., NES) specific ROs, as seen at S1116a.

[0285] Otherwise, in a case where the RAN node 5 indicates (e.g., by the content and / or presence / absence of the indication) that the UE 3 may select any valid RO from among any of the configured RACH resources available at the UE 3, the UE 3 may select / identify any appropriate valid RO (i.e., from among both non-feature specific ROs and additional feature / feature-combination (e.g., SBFD / NES) specific ROs), as seen at S1116b.

[0286] The UE 3 will also select / identify the appropriate preamble based on the configuration of the one or more sets of RACH resources provided by the RAN node 5 and will make an initial access attempt, at S1118, using the selected / identified RO to send the selected / identified preamble.

[0287] It will be appreciated that that various different mechanisms described with reference to Figs. 8 to 11 are not mutually exclusive and may each be applicable for a different respective scenario, e.g., for a different respective type of random-access procedure and / or associated feature / feature combination to which the additional RACH resource configuration relates. For example, for initial connection establishment, the RAN node 5 / UE 3 may use the mechanism described with reference to Fig. 9, whereas the mechanism described with reference to Fig. 8 may be used in a case where the UE 3 is performing random-access for beam recovery in the context of SBFD. Nevertheless, it will be appreciated the communication system 1 need not support all the various different mechanisms described with reference to Figs. 8 to 11 and may only implement a subset of one or more of those mechanisms.

[0288] < UE-side RO Selection for Random-Access Reattempt > 　　As mentioned above each UE 3 and RAN node 5 of the communication system 1 may be mutually configured to support one or more enhanced RACH resource selection criteria / mechanisms including, for example, RACH resource selection at the UE 3 for the purposes of RACH transmission initiated by the UE 3 as part of reattempted random-access (e.g., following a failed earlier random-access attempt).

[0289] Specifically, for conventional random-access procedures, when an attempted random-access by the UE 3 fails (e.g. as a result of Msg2, or Msg4, reception failure), then the UE 3 may reattempt random-access (e.g., using an increased transmission power (also known as power ramping) for transmitting Msg1). However, when two different set of RACH resources are available to the UE 3 (e.g., a non-feature specific set of RACH resources and an additional feature / feature combination specific set of RACH resources) the question of whether the UE 3 is allowed to switch between the different RACH resource sets for consecutive random-access attempts.

[0290] In a first mechanism for performing a random-access reattempt that may be supported in the communication system 1, when random-access is reattempted, the UE 3 uses a selected RO from the same RACH resource set (e.g., from the non-feature specific set of RACH resources or the additional feature / feature combination specific set of RACH resources) that was used in the earlier (e.g., initial, or subsequent failed) random-access attempt. This mechanism may be particularly beneficial in the context of SBFD, in which optimum RACH transmission parameters may vary significantly between the two RACH resource sets, and hence having the UE 3 select the same RACH resource set for the entire random access procedure can help to minimise implementation complexity.

[0291] In a first mechanism for performing a random-access reattempt that may be supported in the communication system 1, when random-access is reattempted, the UE 3 may be allowed to switch between the different configured RACH resource sets between RACH attempts under certain set of conditions. Specifically, the UE 3 may be able to perform a reattempted random-access transmission (e.g., of a random-access preamble / Msg1) in any available valid RO (i.e., irrespective of whether that RO belongs to the non-feature specific set of RACH resources or the additional feature / feature combination specific set of RACH resources).

[0292] This mechanism may, for example, be made applicable in the context of NES. Specifically, in this case, the UE 3 may be allowed to switch from an RO of a non-feature specific set of RACH resources, to an RO of an additional feature / feature combination specific (i.e., NES) set of RACH resources, if at least one valid RO belonging to the additional feature / feature combination specific (i.e., NES) set of RACH resources is active / enabled (e.g., as described with reference Fig. 10 above). It will be appreciated the UE 3 may be allowed to switch from an RO of an additional feature / feature combination (i.e., NES) specific set of RACH resources, to an RO of a non-feature specific set of RACH resources either unconditionally, or conditionally (e.g, if all valid ROs belonging to the additional feature / feature combination specific (i.e., NES) set of RACH resources have been deactivated / removed).

[0293] This mechanism may, for example, also be made applicable in the context of SBFD. Specifically, in this case, the UE 3 may be allowed to switch from an RO of an additional feature / feature combination (i.e., SBFD) specific set of RACH resources, to an RO of a non-feature specific set of RACH resources, but may be restricted from switching in the other direction - i.e., the UE 3 may not be allowed to switch from an RO of a non-feature specific set of RACH resources, to an RO of an additional feature / feature combination (i.e., SBFD) specific set of RACH resources.

[0294] Nevertheless, this mechanism may, for example, also be made more widely applicable in the context of SBFD, where the network expressly allows it. For example, in this case, the UE 3 may be allowed to switch from an RO of an additional feature / feature combination (i.e., SBFD) specific set of RACH resources, to an RO of a non-feature specific set of RACH resources, or vice versa, based on one or more indications provided by the RAN node 5. Specifically, the RAN node 5 may be configured to explicitly indicate, e.g., via an appropriate field / IE, whether or not the UE 3 is allowed to switch between the RACH resource sets. Such an IE / field may, for example, be provided as part of, or separately to, the configuration of the additional feature / feature combination (i.e., SBFD) specific set of RACH resources. Such an IE / field may, for example, be provided as part of any of the IEs mentioned in the description of Fig. 11 - e.g., the indication may be included, for example, in any of the following existing IEs that will be familiar to those skilled in the art: 'BWP-UplinkCommon' IE; an 'AdditionalRACH-Config' IE; a 'RACH-ConfigCommon' IE; a 'RACH-ConfigGeneric' IE; a 'FeatureCombinationPreambles' IE; and / or the like.

[0295] < SSB to RO Mapping in the Context of RO Adaptation > 　　As mentioned above each UE 3 and RAN node 5 of the communication system 1 may be mutually configured to implement one or more enhanced mechanisms for SSB to RO mapping in the context RO adaptation.

[0296] Possible mechanisms SSB to RO mapping, will now be described in more detail with reference to Figs. 12 to 14.

[0297] < SSB to RO mapping - RO Activation / Deactivation based RO Adaptation > 　　Fig. 12 is a simplified illustration of a number of mechanisms for SSB to RO mapping that may be used in the communication system 1 in the context of RO adaptation in which one or more additional feature / feature-combination (e.g. NES) specific ROs may be activated (enabled) and / or deactivated (removed) by the network (e.g., to support local NES requirements).

[0298] In the examples of Fig. 12, the mechanisms for SSB to RO mapping occur in the context of a scenario in which the UE 3 has been configured with a set of non-feature specific RACH resources and a set of additional feature / feature-combination (e.g., NES) specific RACH resources, e.g., using an RRC message to provide an associated feature / feature-combination (e.g., NES) specific additional common RACH configuration (e.g., using an appropriately configured 'AdditionalRACH-Config' IE or the like as described above).

[0299] In the examples of Fig. 12, when configuring the additional feature / feature-combination specific ROs, the RAN node 5 may also configure all (or a subset) of the ROs to be initially activated (or deactivated) for possible subsequent deactivation / removal and / or activation / enablement by the RAN node 5. It will be appreciated that the initially configured feature / feature-combination specific, RACH resources, may be treated as activated (or deactivated) by default or may be explicitly deactivated / removed or activated / enabled (e.g., by an appropriate IE in system information and / or an RRC message used for configuring the RACH resources).

[0300] In the examples of Fig. 12, all (or a subset) of the ROs of the set of additional feature / feature-combination (e.g., NES) RACH resources may, if activated / enabled, be semi-statically removed / deactivated by the RAN node 5 using L3 signalling (e.g. an RRC message), for example as described with reference to Fig. 10 above. The message used to remove / deactivate the ROs may, for example, indicate a (sub)set of ROs to deactivate / remove. The message used to remove / deactivate the ROs may indicate a time duration for which the deactivation / removal is applicable (and / or an appropriate periodicity value indicating a periodic time period during which the ROs are deactivated). For example, this can be indicated by means of information indicating, or corresponding to, a configuration of a cell DRX cycle, or the like, used by the RAN node 5. Specifically, within a cell DRX 'on' duration (i.e., when the RAN node 5 is in an active state), the RAN node 5 may activate / enable all ROs. Contrastingly, and within a cell DRX 'off' duration (when the RAN node 5 is in a low power / sleep state), the RAN node 5 may configure the corresponding (sub)set of one or more ROs to be deactivated / removed.

[0301] In the examples of Fig. 12, all (or a subset) of the ROs of the set of additional feature / feature-combination (e.g., NES) RACH resources may, if activated / enabled, also be dynamically removed / deactivated by the RAN node 5 using L1 / L2 signalling (e.g. a MAC CE / DCI), for example as described with reference to Fig. 10 above. The message used to dynamically remove / deactivate the ROs may, for example, indicate a (sub)set of ROs to deactivate / remove. The message used to dynamically remove / deactivate the ROs may indicate a (different) time duration for which the deactivation / removal is applicable (and / or an appropriate (different) periodicity value indicating aperiodic time period during which the ROs are deactivated).

[0302] Fig. 12 illustrates respectively at (a), (b), and (c) a different possible mechanism for defining SSB to RO mapping.

[0303] The possible mechanisms shown in Fig. 12 are all illustrated for a hypothetical scenario in which: the number of SSBs per RO is configured by the RAN node 5 to be 1 for the additional feature / feature-combination specific RACH resources; and there are two SSBs transmitted by the cell (e.g., SSB0, and SSB1). Moreover, in the illustrated hypothetical scenario, a configuration of additional feature / feature-combination specific RACH resources is provided to the UE 3 that indicates a set of five ROs (RO0, RO1, RO2, RO3, and RO4). However, one of the ROs (RO1) has been deactivated / removed by L3 signalling and an additional two ROs (RO2 and RO3) have been deactivated / removed by L1 / L2 signalling.

[0304] In a first exemplary SSB to RO mapping mechanism, illustrated at Fig. 12(a), the UE 3 simply includes (counts) all the ROs of the set of additional feature / feature-combination (e.g., NES) RACH resources when performing the SSB to RO mapping (even if some of those ROs are removed / deactivated due to RO adaptation).

[0305] Accordingly, in this example: -　　RO0 is mapped to SSB0; -　　RO1 is mapped to SSB1; -　　RO2 is mapped to SSB0; -　　RO3 is mapped to SSB1; and -　　RO4 is mapped to SSB0.

[0306] This can also be understood as the UE 3 counting all ROs defined by the RRC configuration for SSB to RO mapping.

[0307] In a second exemplary SSB to RO mapping mechanism, illustrated at Fig. 12(b), the UE 3 does not include (count) any ROs which have been semi-statically removed / deactivated (e.g. by L3 / RRC signalling), when performing the SSB to RO mapping.

[0308] Accordingly, in this example: -　　RO0 is mapped to SSB0; -　　RO1 is not mapped to an SSB; -　　RO2 is mapped to SSB1; -　　RO3 is mapped to SSB0; and -　　RO4 is mapped to SSB1.

[0309] Accordingly, in this case, the ROs that are deactivated using L3 signalling, are not counted for SSB to RO mapping but the ROs that are deactivated using L1 / L2 signalling are counted for SSB to RO mapping.

[0310] In a third exemplary SSB to RO mapping mechanism, illustrated at Fig. 12(c), the UE 3 only includes (counts) activated ROs, of the set of additional feature / feature-combination (e.g., NES) RACH resources, when performing the SSB to RO mapping.

[0311] Accordingly, in this example: -　　RO0 is mapped to SSB0; -　　RO1 is not mapped to an SSB; -　　RO2 is not mapped to an SSB; -　　RO3 is not mapped to an SSB; and -　　RO4 is mapped to SSB1.

[0312] Accordingly, in this case, the ROs that are deactivated using L1 / L2 / L3 signalling, are not counted for SSB to RO mapping.

[0313] In a fourth exemplary SSB to RO mapping mechanism in which the ROs may be deactivated / removed using L1 / L2 / L3 signalling as described for the above mechanisms illustrated in Fig. 12 (but in this case not illustrated in Fig. 12), the RAN node 5 may be restricted, when deactivating / removing the ROs (for RO adaptation purposes), to deactivating / removing a set of ROs that includes all ROs associated with an association period (or with an SSB to RO mapping cycle). Accordingly, a situation in which only a subset of ROs belonging to an association period (or SSB to RO mapping cycle) are removed / deactivated. It will be appreciated by removing all ROs in an association period (or SSB to RACH occasion mapping cycle) the ambiguity that might otherwise occur can be avoided.

[0314] It will be appreciated deactivation / removal of ROs by L1 / L2 based signalling has a higher chance of resulting in SSB to RO ambiguity between the UE 3 and the RAN node 5. Accordingly, whilst this restriction on the ability of the RAN node 5 to deactivate / remove ROs may apply to deactivation / removal of ROs by L1 / L2 and L3 based signalling, the restriction may, beneficially, only apply to deactivation / removal of ROs by L1 / L2 based signalling.

[0315] < SSB to RO mapping - RO Frequency of Occurrence based RO adaptation > 　　Fig. 13 is a simplified illustration of further mechanisms for SSB to RO mapping that may be used in the communication system 1 in the context of RO adaptation in which different RO periodicities (or frequencies of occurrence) may be applicable at different timings (e.g., to support local NES requirements).

[0316] In the examples of Fig. 13, the mechanisms for SSB to RO mapping occur in the context of a scenario in which the UE 3 has been configured with a set of non-feature specific RACH resources and a set of additional feature / feature-combination (e.g., NES) specific RACH resources, e.g., using an RRC message to provide an associated feature / feature-combination (e.g., NES) specific additional common RACH configuration (e.g., using an appropriately configured 'AdditionalRACH-Config' IE or the like as described above).

[0317] In the examples of Fig. 13, however, a different form of RO adaptation is employed than in Fig. 12. Specifically, in the examples of Fig. 13, the UE 3 may be configured (e.g., by L3 / RRC signalling) with one or more values indicating a frequency of occurrence for the additional feature / feature-combination specific ROs. This may be achieved, for example, by configuring a respective (different) PRACH configuration index value corresponding to each frequency of occurrence, or by configuring a respective (different) periodicity value for the ROs corresponding to each frequency of occurrence. It will be appreciated that the one or more values indicating a frequency of occurrence for the additional feature / feature-combination specific ROs may be provided as part of, or separately to, the feature / feature-combination (e.g., NES) specific additional RACH configuration used to configure the additional feature / feature-combination specific ROs.

[0318] Among the set of one or more configured periodicity / frequency values, at any given time instance only one of the values is applicable for valid RO determination. The value of periodicity / frequency to be used for valid RO determination at any given time instance may, for example, be determined by the UE 3 autonomously. Nevertheless, the RAN node 5 may (alternatively or additionally) be configured to be able to indicate a value of periodicity / frequency to be used at the UE 3, for valid RO determination at a given time instance, using semi-static signalling / L3 signalling (e.g., via an RRC message). For example, the RAN node 5 may configure different respective values RO periodicity to be used at a timing corresponding a cell DRX 'on' duration and at a timing corresponding to a cell DRX 'off' duration.

[0319] The RAN node 5 may (alternatively or additionally) be configured to be able to indicate a value of periodicity / frequency to be used at the UE 3, for valid RO determination at a given time instance, using dynamic signalling (L1 / L2 signalling). The signalling may also indicate a time duration for which the periodicity / frequency value is applicable for, after which the timing of the ROs may be determined based on a previously used periodicity / frequency value and / or a default value.

[0320] Fig. 13 illustrates respectively at (a) and (b) different possible mechanisms for defining SSB to RO mapping for ROs adapted based on different RO periodicities / frequencies of occurrence.

[0321] The possible mechanisms shown in Fig. 13 are both illustrated for a hypothetical scenario in which: the number of SSBs per RO is configured to by the RAN node 5 to be 1 for the additional feature / feature-combination specific RACH resources; and there are four SSBs transmitted by the cell 9 (e.g., SSB0, SSB1, SSB2, and SSB3). Moreover, in the illustrated hypothetical scenario, a configuration of additional feature / feature-combination specific RACH resources is provided to the UE 3 that has (at least) two different periodicity values (10ms and 30ms) or corresponding frequency of occurrence values (100 per second and 33.33 per second).

[0322] In a first exemplary SSB to RO mapping mechanism, illustrated at Fig. 13(a), the UE 3 is configured to determine the SSB to RO mapping based on a lowest (or reference) periodicity (or highest (or reference) frequency of occurrence) for the ROs. Specifically, for the purposes of SSB to RO mapping it is assumed that the ROs always occur based on the lowest periodicity value (or a reference periodicity value) indicated by the RAN node 5. Even if the actual RO periodicity value is different, at a given time, than the lowest periodicity value (or reference periodicity value), then the UE 3 does not change the SSB to RO mapping. Nevertheless, for the purposes of random-access, the UE 3 still selects from among the actual ROs, which occur with the actual periodicity value that is applicable at a given time.

[0323] In a second exemplary SSB to RO mapping mechanism, illustrated at Fig. 13(b), the UE 3 is configured to determine the SSB to RO mapping based on an actual periodicity (or frequency of occurrence) for the ROs (which may, for example, be determined by the UE 3 autonomously or provided to the UE 3 by the RAN node 5 using semi-static / L3 / RRC signalling). In this case, the UE 3 is configured not to use any dynamically configured periodicity value (e.g., indicated by L1 / L2 signalling / MAC CE / DCI) for SSB to RO mapping even if such dynamically indicated periodicity (or frequency of occurrence) is in use. Nevertheless, for the purposes of random-access, the UE 3 still selects from among the actual ROs, which occur with the actual periodicity value that is applicable at a given time (even if dynamically signalled).

[0324] < SSB to RO mapping - RO Set Activation / Deactivation based RO adaptation > 　　Fig. 14 is a simplified illustration of another mechanism for SSB to RO mapping that may be used in the communication system 1 in the context of RO adaptation in which an entire set of additional feature / feature-combination (e.g. NES) specific ROs may be activated (enabled) and / or deactivated (removed) by the network (e.g., to support local NES requirements).

[0325] In the example of Fig. 14, the mechanism for SSB to RO mapping occurs in the context of a scenario in which the UE 3 has been configured with a set of non-feature specific RACH resources and a set of additional feature / feature-combination (e.g., NES) RACH resources, e.g., using an RRC message to provide an associated feature / feature-combination (e.g., NES) specific additional common RACH configuration (e.g., using an appropriately configured 'AdditionalRACH-Config' IE or the like as described above).

[0326] In the example of Fig. 14, however, a different form of RO adaptation is employed than in Figs. 12 and 13. Specifically, in the example of Fig. 14, adaption of the RACH resources is achieved by activating / deactivating the entire set of additional RACH resources collectively. Specifically, in this case, the entire set of additional feature / feature-combination (e.g., NES) RACH resources can be activated or deactivated by the RAN node 5 using appropriate signalling (e.g. L1, L2 and / or L3). However, in this example, individual activation / deactivation of individual ROs is not possible.

[0327] Fig. 14 illustrates a possible mechanism for defining SSB to RO mapping for RO adaption based on activating / deactivating the entire set of additional ROs collectively.

[0328] The possible mechanism shown in Fig. 14 is illustrated for a hypothetical scenario in which: the number of SSBs per RO is configured by the RAN node 5 to be two for the set of non-feature specific set of RACH resources, and to be one for the additional feature / feature-combination specific RACH resources; and there are four SSBs transmitted by the cell (e.g., SSB0, SSB1, SSB2, and SSB3).

[0329] As seen in Fig. 14, for SSB to RO mapping, the UE 3 includes (counts) the ROs, and determines the SSB to RO mapping, assuming that the additional feature / feature-combination specific ROs are always available (i.e., the UE 3 counts all ROs of the additional feature / feature-combination specific RACH resource set irrespective of whether the feature / feature-combination specific RACH resource set is activated or deactivated).

[0330] It will be appreciated that here, UE RO counting, and the SSB to RO mapping, occurs independently for the additional feature / feature-combination specific ROs and for non-feature specific ROs. Hence no ambiguity results between the RAN node 5 and the UE 3. Accordingly, it is also possible that additional feature / feature-combination specific RACH resources configured for NES can have different SSB to RO mapping parameters (e.g., a "number of SSBs per RO" parameter as illustrated in Fig. 14)

[0331] < Avoiding RA-RNTI Confusion > 　　As mentioned above each UE 3 and RAN node 5 of the communication system 1 may be mutually configured to implement one or more enhanced mechanisms for avoiding / reducing the risk of RA-RNTI confusion. Possible mechanisms for avoiding / reducing the risk of RA-RNTI confusion will now be described in more detail.

[0332] It will be appreciated that when an additional feature / feature-combination specific RO does not share the same time domain resource as a non-feature specific RO the risk of RA-RNTI is minimised (or eliminated). Hence, the RAN node 5 and the UE 3 may be mutually configured to implement a relatively simple mechanism solution in which it is ensured that feature / feature-combination specific ROs are always time division multiplexed with non-feature specific ROs. Nevertheless, it will be appreciated that this may be restricted by UE side behaviour in which a given UE 3 may not expect to receive a configuration of additional feature / feature-combination specific where a starting symbol of the RO of the additional feature / feature-combination specific RACH resources is not the same as a starting symbol of any RO of a non-feature specific RACH resource set.

[0333] Moreover, in some scenarios (e.g. for NES), it may be beneficial to perform frequency division multiplexing between the additional feature / feature-combination specific RACH resources and the non-feature specific RACH resources to allow the RO occurrences to be compressed in the time domain. To resolve, RA-RNTI confusion for such a case, a number of exemplary mechanisms are possible.

[0334] In a first exemplary mechanism, the RA-RNTI calculation is modified to take account of whether a particular RO belongs to additional feature / feature-combination specific RACH resources or to non-feature specific RACH resources. For example, RA-RNTI may be calculated as follows: 　　RA-RNTI = 1 + s_id + 14 × t_id + 14 × 80 × f_id + 14 × 80 × 8 × ul_carrier_id + 14 × 80 × 8 x 2 x RACH_config 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); 　　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); and 　　RACH_config is set to zero for non-feature specific ROs (e.g. zero) and a non-zero value for additional feature / feature-combination specific ROs.

[0335] In a variation on this, the possible ul_carrier_id field values may (alternatively or additionally) be extended so that the value of ul_carrier_id may also differentiate between the RACH configuration (i.e., non-feature specific or additional feature / feature-combination specific) used for random-access.

[0336] In a second exemplary mechanism, the radio resources for receiving an RAR for a random-access attempt made via an RO of an additional feature / feature-combination specific RACH resource set may be different than the radio resources for receiving an RAR for a random-access attempt made via an RO of a non-feature specific RACH resource set. This may be facilitated, for example, by a different PDCCH search space being used for receiving an RAR corresponding to an additional feature / feature-combination specific RACH resource set than for receiving an RAR corresponding to a non-feature specific RACH resource set.

[0337] In a third exemplary mechanism, the RAR message (or DCI scheduling the RAR) itself may indicate whether the associated random-access preamble was transmitted using non-feature specific RACH resources or additional feature / feature-combination specific RACH resources. This may involve, for example, using: a different message format for the RAR (or DCI scheduling RAR) for additional feature / feature-combination specific RACH resources; or a MAC RAR (or RAR subheader) containing information indicating the RACH resource set (e.g., non-feature specific or additional feature / feature-combination specific) corresponding to the random-access preamble transmission.

[0338] Alternatively, or additionally, in the case of random access initiated by a PDCCH order, when the RAN node 5 sends the PDCCH order to the UE 3, information indicating one or more alternative identities (e.g., corresponding to s_id, t_id, and / or f_id described above) may be carried within the PDCCH order (e.g. using the currently reserved bits of the PDCCH order). The one or more alternative identities may then be used by the UE 3 to calculate the RA-RNTI when an additional feature / feature-combination specific RO is used for a random-access attempt. Hence, the RA-RNTI calculated in this manner may be included along with the preamble within the random-access message sent to the RAN node 5. The RAN node 5 can thus identify the UE 3 that chose the additional feature / feature-combination specific RACH resource based on the received RA-RNTI.

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

[0340] 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.

[0341] 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.

[0342] 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.

[0343] 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.

[0344] 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.

[0345] < RAN node > 　　Fig. 16 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.

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

[0347] The communication control module 63 is operable to control the communication between the RAN node 5 and the 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.

[0348] 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.

[0349] 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.

[0350] < 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.

[0351] 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.

[0352] 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.

[0353] 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 RAN node, 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 RAN node or the UE in order to update their functionalities.

[0354] 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.

[0355] The RAN node may comprise a 'distributed' RAN node having a central unit 'CU' and one or more separate distributed units (DUs).

[0356] 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.

[0357] 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.

[0358] 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.

[0359] 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.).

[0360] 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.).

[0361] 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.).

[0362] 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.).

[0363] 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.).

[0364] 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.

[0365] 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)).

[0366] 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.

[0367] 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.

[0368] 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.

[0369] 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 (Table 4). This list is not exhaustive and is intended to be indicative of some examples of machine type communication applications.

[0370] Table 4: Some examples of MTC applications

[0371] 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.

[0372] 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.

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

[0374] Although the present disclosure has been described with reference to the example embodiments, the present disclosure is not limited to the above. Various changes that can be understood by those skilled in the art can be made to the configuration and details of the present disclosure within the scope of the disclosure.

[0375] This application is based upon and claims the benefit of priority from UK patent application No. 2404936.3, filed on April 5, 2024, the disclosure of which is incorporated herein in its entirety by reference.

[0376] The program can be stored and provided to the computer device using any type of non-transitory computer readable media. Non-transitory computer readable media include any type of tangible storage media. Examples of non-transitory computer readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), CD-ROM (Read Only Memory), CD-R, CD-R / W, and semiconductor memories (such as mask ROM, PROM (Programmable ROM), EPROM (Erasable PROM), flash ROM, RAM (Random Access Memory), etc.). The program may be provided to the computer device using any type of transitory computer readable media. Examples of transitory computer readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer readable media can provide the program to the computer device via a wired communication line, such as electric wires and optical fibers, or a wireless communication line.

[0377] For example, the whole or part of the example embodiments disclosed above can be described as, but not limited to, the following supplementary notes. (Supplementary note 1) 　　A method performed by a mobile device, the method comprising: 　　configuring at least one of a legacy random access channel (RACH) resource or an additional RACH resource for a specific service; and 　　selecting either the legacy RACH resource or the additional RACH resource for the mobile device to use for the specific service. (Supplementary note 2) 　　The method according to supplementary note 1, further comprising: 　　receiving, from an access network node, a physical downlink control channel (PDCCH) order for indicating the either the legacy RACH resource or the additional RACH resource for the mobile device to use for the specific service, and wherein 　　the selecting is performed based on the PDCCH order. (Supplementary note 3) 　　The method according to supplementary note 1 or 2, wherein 　　the PDCCH order indicates that the legacy RACH resource is to be used, and 　　the selecting is performed by selecting the legacy RACH resource in a case where the UE uses for the specific service. (Supplementary note 4) 　　The method according to supplementary note 1 or 2, wherein 　　the PDCCH order indicates that the additional RACH resource is to be used, and 　　the selecting is performed by selecting the legacy RACH resource in a case where the additional RACH resource is configured for the specific service. (Supplementary note 5) 　　The method according to supplementary note 1 or 2, wherein 　　the PDCCH order indicates a RACH resource which is configured to the mobilie device, and 　　the selecting is performed by selecting the RACH resource which is configured to the mobile device. (Supplementary note 6) 　　The method according to supplementary note 1 or 2, wherein 　　the selecting is performed based on a resource which was used for the receiving the PDCCH order. (Supplementary note 7) 　　The method according to supplementary note 1 or 2, wherein 　　the PDCCH order activates the additional RACH resource, and 　　the selecting is performed by selecting the activated additional RACH resource. (Supplementary note 8) 　　The method according to any one of supplementary notes 1 to 7, wherein 　　the receiving the PDCCH order is performed using at least one of: 　　　　a downlink control information (DCI) format, 　　　　a radio network temporary identifier (RNTI), or 　　　　configuration information of the additional RACH resource. (Supplementary note 9) 　　The method according to any one of supplementary notes 1 to 8, further comprising: 　　receiving, from the access network node, a condition for the selecting the either the legacy RACH resource or the additional RACH resource for the mobile device to use for the specific service, and wherein 　　the selecting is performed based on whether the condition is met for each of the legacy RACH resource and the additional RACH resource. (Supplementary note 10) 　　The method according to supplementary note 9, wherein 　　the condition includes at least one of: 　　　　an earliest RACH resource, 　　　　a best radio condition on a RACH resource, or 　　　　a lowest latency on a RACH resource. (Supplementary note 11) 　　The method according to supplementary note 9 or 10, wherein 　　the condition includes a reference signal received power (RSRP) threshold. (Supplementary note 12) 　　The method according to supplementary note 11, wherein 　　the specific service includes a subband full duplex service, and 　　the RSRP threshold has different values for RACH resources occurring during subband full duplex (SBFD) symbols and for RACH resources occurring during non-SBFD symbols. (Supplementary note 13) 　　The method according to any one of supplementary notes 9 to 12, wherein 　　the condition is configured so as to be different among services which the mobile device uses. (Supplementary note 14) 　　The method according to any one of supplementary notes 1 to 13, further comprising: 　　using a same RACH resource for reattempting a random access procedure as the either legacy RACH resource or the additional RACH resource for the mobile device to use for the specific service. (Supplementary note 15) 　　The method according to any one of supplementary notes 1 to 13, further comprising: 　　using another RACH resource for reattempting a random access procedure than the either legacy RACH resource or the additional RACH resource for the mobile device to use for the specific service. (Supplementary note 16) 　　The method according to supplementary note 15, wherein 　　the using the another RACH resource is performed in a case where a specific condition is met. (Supplementary note 17) 　　The method according to supplementary note 15 or 16, wherein 　　the using the another RACH resource is performed in a case where the another RACH resource is activated. (Supplementary note 18) 　　The method according to any one of supplementary notes 15 to 17, wherein 　　the using the another RACH resource is performed based on a type of the specific service the mobile device uses. (Supplementary note 19) 　　The method according to any one of supplementary notes 15 to 18, wherein 　　the specific service includes a network energy saving service, and 　　the using the another RACH resource is performed by switching using from the legacy RACH resource to using the additional RACH resource, in a case where the additional RACH resource is activated. (Supplementary note 20) 　　The method according to any one of supplementary notes 15 to 18, wherein 　　the specific service includes a subband full duplex service, and 　　the using the another RACH resource is performed by switching using from the additional RACH resource to using the legacy RACH resource. (Supplementary note 21) 　　The method according to supplementary note 20, further comprising: 　　deactivating the additional RACH resource upon the switching to using the legacy RACH resource. (Supplementary note 22) 　　The method according to any one of supplementary notes 1 to 21, wherein 　　the additional RACH resource is configured per specific services. (Supplementary note 23) 　　The method according to any one of supplementary notes 1 to 22, wherein 　　the specific service includes at least one of: 　　　　a network energy saving service, or 　　　　a subband full duplex service. (Supplementary note 24) 　　The method according to any one of supplementary notes 1 to 23, wherein 　　the specific service includes a subband full duplex service, and 　　the selecting the either the legacy RACH resource or the additional RACH resource is performed by selecting a RACH resource occurring during at least one subband full duplex (SBFD) symbol. (Supplementary note 25) 　　The method according to any one of supplementary notes 1 to 24, wherein 　　the specific service includes a subband full duplex service, and 　　the selecting the either the legacy RACH resource or the additional RACH resource is performed by selecting a RACH resource occurring during at least one subband full duplex (SBFD) uplink-only symbol. (Supplementary note 26) 　　The method according to any one of supplementary notes 1 to 25, further comprising: 　　receiving, from the access network node, information indicating at least one additional RACH resource; 　　receiving, from the access network node, information for deactivating, removing, activating, or configuring at least a part of the at least one additional RACH resource; 　　adapting a matching between at least one synchronization signal / physical broadcast channel (PBCH) block (SSB) and the at least one additional RACH resource based on the information for deactivating, removing, activating, or configuring the at least the part of the at least one additional RACH resource. (Supplementary note 27) 　　The method according to supplementary note 26, wherein 　　the receiving the information indicating the at least one additional RACH resource is performed via a Radio Resource Control (RRC) message. (Supplementary note 28) 　　The method according to supplementary note 26 or 27, wherein 　　the receiving the information for deactivating, removing, activating, or configuring the at least the part of the at least one additional RACH resource is performed via at least one of: 　　　　a Radio Resource Control (RRC) message, 　　　　a Medium Access Control (MAC) control element (CE), or 　　　　Downlink Control Information (DCI). (Supplementary note 29) 　　The method according to any one of supplementary notes 26 to 28, wherein 　　the information for deactivating, removing, activating, or configuring the at least the part of the at least one additional RACH resource indicates at least one of: 　　　　at least one time duration or periodicity for which the deactivating, removing, activating, or configuring is applicable, or 　　　　at least one index, each of which indicates a respective one of the at least the part of the at least one additional RACH resource. (Supplementary note 30) 　　The method according to supplementary note 29, wherein 　　one of the at least one time duration or periodicity or index is applicable for the adapting. (Supplementary note 31) 　　The method according to supplementary note 29 or 30, wherein 　　a smallest time duration or periodicity is applicable for the adapting. (Supplementary note 32) 　　The method according to any one of supplementary notes 29 to 31, wherein 　　one of the at least one time duration or periodicity or index which is applicable for the adapting is configured by the access network node or determined by the mobile device. (Supplementary note 33) 　　The method according to any one of supplementary notes 26 to 32, wherein 　　the adapting is performed by at least one of: 　　　　counting all of the at least one additional RACH resource even if the at least the part of the at least one additional RACH resource are deactivated or removed, 　　　　not counting the at least the part of the at least one additional RACH resource in a case where the at least the part of the at least one additional RACH resource are deactivated or removed, 　　　　counting the at least the part of the at least one additional RACH resource in a case where the at least the part of the at least one additional RACH resource are activated or configured, 　　　　only counting at least one activated additional RACH resource in the at least one additional RACH resource, or 　　　　not counting all of additional RACH resources which correspond to the matching between the at least one SSB and the at least one additional RACH resource. (Supplementary note 34) 　　The method according to any one of supplementary notes 26 to 33, wherein 　　the deactivating, removing, activating, or configuring is applied to all of the at least one additional RACH resource. (Supplementary note 35) 　　The method according to any one of supplementary notes 1 to 34, wherein 　　the legacy RACH resource and the additional RACH resource are not overlapped each other in at least one of time domain or frequency domain. (Supplementary note 36) 　　The method according to any one of supplementary notes 1 to 34, wherein 　　a Radio Network Temporary Identifier (RNTI) used for a random access procedure has a parameter for indicating either the legacy RACH resource or the additional RACH resource. (Supplementary note 37) 　　The method according to any one of supplementary notes 1 to 34, wherein 　　a message used in a random access procedure has a parameter for indicating either the legacy RACH resource or the additional RACH resource. (Supplementary note 38) 　　The method according to supplementary note 2, wherein 　　the PDCCH order includes a parameter for calculating a Radio Network Temporary Identifier (RNTI) for a random access procedure. (Supplementary note 39) 　　A method performed by an access network node, the method comprising: 　　transmitting, to a mobile device, information for configuring at least one of a legacy random access channel (RACH) resource or an additional RACH resource for a specific service; and 　　transmitting, to the mobile device, information for selecting either the legacy RACH resource or the additional RACH resource for the mobile device to use for the specific service. (Supplementary note 40) 　　A mobile device comprising: 　　means for configuring at least one of a legacy random access channel (RACH) resource or an additional RACH resource for a specific service; and 　　means for selecting either the legacy RACH resource or the additional RACH resource for the mobile device to use for the specific service. (Supplementary note 41) 　　An access network node comprising: 　　means for transmitting, to a mobile device, information for configuring at least one of a legacy random access channel (RACH) resource or an additional RACH resource for a specific service; and 　　means for transmitting, to the mobile device, information for selecting either the legacy RACH resource or the additional RACH resource for the mobile device to use for the specific service.

[0378] 1　　communication system 3, 3-1, 3-2, 3-3　　UEs 5, 5-1, 5-2　　radio access network (RAN) node 7　　core network 9　　cells 10　　control plane functions (CPFs) 10-1　　Access and Mobility Management Functions (AMFs) 10-2　　session management function (SMF) 11　　user plane functions (UPFs) 20　　external data network 31, 51　　transceiver circuit 33, 53　　antenna 35　　user interface 37, 57　　controller 39, 59　　memory 41, 61　　operating system 43, 63　　communications control module 55　　core network interface

Claims

1. A method performed by a mobile device, the method comprising: 　　configuring at least one of a legacy random access channel (RACH) resource or an additional RACH resource for a specific service; and 　　selecting either the legacy RACH resource or the additional RACH resource for the mobile device to use for the specific service.

2. The method according to claim 1, further comprising: 　　receiving, from an access network node, a physical downlink control channel (PDCCH) order for indicating the either the legacy RACH resource or the additional RACH resource for the mobile device to use for the specific service, and wherein 　　the selecting is performed based on the PDCCH order.

3. The method according to claim 1 or 2, wherein 　　the PDCCH order indicates that the legacy RACH resource is to be used, and 　　the selecting is performed by selecting the legacy RACH resource in a case where the UE uses for the specific service.

4. The method according to claim 1 or 2, wherein 　　the PDCCH order indicates that the additional RACH resource is to be used, and 　　the selecting is performed by selecting the legacy RACH resource in a case where the additional RACH resource is configured for the specific service.

5. The method according to claim 1 or 2, wherein 　　the PDCCH order indicates a RACH resource which is configured to the mobilie device, and 　　the selecting is performed by selecting the RACH resource which is configured to the mobile device.

6. The method according to claim 1 or 2, wherein 　　the selecting is performed based on a resource which was used for the receiving the PDCCH order.

7. The method according to claim 1 or 2, wherein 　　the PDCCH order activates the additional RACH resource, and 　　the selecting is performed by selecting the activated additional RACH resource.

8. The method according to any one of claims 1 to 7, wherein 　　the receiving the PDCCH order is performed using at least one of: 　　　　a downlink control information (DCI) format, 　　　　a radio network temporary identifier (RNTI), or 　　　　configuration information of the additional RACH resource.

9. The method according to any one of claims 1 to 8, further comprising: 　　receiving, from the access network node, a condition for the selecting the either the legacy RACH resource or the additional RACH resource for the mobile device to use for the specific service, and wherein 　　the selecting is performed based on whether the condition is met for each of the legacy RACH resource and the additional RACH resource.

10. The method according to claim 9, wherein 　　the condition includes at least one of: 　　　　an earliest RACH resource, 　　　　a best radio condition on a RACH resource, or 　　　　a lowest latency on a RACH resource.

11. The method according to claim 9 or 10, wherein 　　the condition includes a reference signal received power (RSRP) threshold.

12. The method according to claim 11, wherein 　　the specific service includes a subband full duplex service, and 　　the RSRP threshold has different values for RACH resources occurring during subband full duplex (SBFD) symbols and for RACH resources occurring during non-SBFD symbols.

13. The method according to any one of claims 9 to 12, wherein 　　the condition is configured so as to be different among services which the mobile device uses.

14. The method according to any one of claims 1 to 13, further comprising: 　　using a same RACH resource for reattempting a random access procedure as the either legacy RACH resource or the additional RACH resource for the mobile device to use for the specific service.

15. The method according to any one of claims 1 to 13, further comprising: 　　using another RACH resource for reattempting a random access procedure than the either legacy RACH resource or the additional RACH resource for the mobile device to use for the specific service.

16. The method according to claim 15, wherein 　　the using the another RACH resource is performed in a case where a specific condition is met.

17. The method according to claim 15 or 16, wherein 　　the using the another RACH resource is performed in a case where the another RACH resource is activated.

18. The method according to any one of claims 15 to 17, wherein 　　the using the another RACH resource is performed based on a type of the specific service the mobile device uses.

19. The method according to any one of claims 15 to 18, wherein 　　the specific service includes a network energy saving service, and 　　the using the another RACH resource is performed by switching using from the legacy RACH resource to using the additional RACH resource, in a case where the additional RACH resource is activated.

20. The method according to any one of claims 15 to 18, wherein 　　the specific service includes a subband full duplex service, and 　　the using the another RACH resource is performed by switching using from the additional RACH resource to using the legacy RACH resource.

21. The method according to claim 20, further comprising: 　　deactivating the additional RACH resource upon the switching to using the legacy RACH resource.

22. The method according to any one of claims 1 to 21, wherein 　　the additional RACH resource is configured per specific services.

23. The method according to any one of claims 1 to 22, wherein 　　the specific service includes at least one of: 　　　　a network energy saving service, or 　　　　a subband full duplex service.

24. The method according to any one of claims 1 to 23, wherein 　　the specific service includes a subband full duplex service, and 　　the selecting the either the legacy RACH resource or the additional RACH resource is performed by selecting a RACH resource occurring during at least one subband full duplex (SBFD) symbol.

25. The method according to any one of claims 1 to 24, wherein 　　the specific service includes a subband full duplex service, and 　　the selecting the either the legacy RACH resource or the additional RACH resource is performed by selecting a RACH resource occurring during at least one subband full duplex (SBFD) uplink-only symbol.

26. The method according to any one of claims 1 to 25, further comprising: 　　receiving, from the access network node, information indicating at least one additional RACH resource; 　　receiving, from the access network node, information for deactivating, removing, activating, or configuring at least a part of the at least one additional RACH resource; 　　adapting a matching between at least one synchronization signal / physical broadcast channel (PBCH) block (SSB) and the at least one additional RACH resource based on the information for deactivating, removing, activating, or configuring the at least the part of the at least one additional RACH resource.

27. The method according to claim 26, wherein 　　the receiving the information indicating the at least one additional RACH resource is performed via a Radio Resource Control (RRC) message.

28. The method according to claim 26 or 27, wherein 　　the receiving the information for deactivating, removing, activating, or configuring the at least the part of the at least one additional RACH resource is performed via at least one of: 　　　　a Radio Resource Control (RRC) message, 　　　　a Medium Access Control (MAC) control element (CE), or 　　　　Downlink Control Information (DCI).

29. The method according to any one of claims 26 to 28, wherein 　　the information for deactivating, removing, activating, or configuring the at least the part of the at least one additional RACH resource indicates at least one of: 　　　　at least one time duration or periodicity for which the deactivating, removing, activating, or configuring is applicable, or 　　　　at least one index, each of which indicates a respective one of the at least the part of the at least one additional RACH resource.

30. The method according to claim 29, wherein 　　one of the at least one time duration or periodicity or index is applicable for the adapting.

31. The method according to claim 29 or 30, wherein 　　a smallest time duration or periodicity is applicable for the adapting.

32. The method according to any one of claims 29 to 31, wherein 　　one of the at least one time duration or periodicity or index which is applicable for the adapting is configured by the access network node or determined by the mobile device.

33. The method according to any one of claims 26 to 32, wherein 　　the adapting is performed by at least one of: 　　　　counting all of the at least one additional RACH resource even if the at least the part of the at least one additional RACH resource are deactivated or removed, 　　　　not counting the at least the part of the at least one additional RACH resource in a case where the at least the part of the at least one additional RACH resource are deactivated or removed, 　　　　counting the at least the part of the at least one additional RACH resource in a case where the at least the part of the at least one additional RACH resource are activated or configured, 　　　　only counting at least one activated additional RACH resource in the at least one additional RACH resource, or 　　　　not counting all of additional RACH resources which correspond to the matching between the at least one SSB and the at least one additional RACH resource.

34. The method according to any one of claims 26 to 33, wherein 　　the deactivating, removing, activating, or configuring is applied to all of the at least one additional RACH resource.

35. The method according to any one of claims 1 to 34, wherein 　　the legacy RACH resource and the additional RACH resource are not overlapped each other in at least one of time domain or frequency domain.

36. The method according to any one of claims 1 to 34, wherein 　　a Radio Network Temporary Identifier (RNTI) used for a random access procedure has a parameter for indicating either the legacy RACH resource or the additional RACH resource.

37. The method according to any one of claims 1 to 34, wherein 　　a message used in a random access procedure has a parameter for indicating either the legacy RACH resource or the additional RACH resource.

38. The method according to claim 2, wherein 　　the PDCCH order includes a parameter for calculating a Radio Network Temporary Identifier (RNTI) for a random access procedure.

39. A method performed by an access network node, the method comprising: 　　transmitting, to a mobile device, information for configuring at least one of a legacy random access channel (RACH) resource or an additional RACH resource for a specific service; and 　　transmitting, to the mobile device, information for selecting either the legacy RACH resource or the additional RACH resource for the mobile device to use for the specific service.

40. A mobile device comprising: 　　means for configuring at least one of a legacy random access channel (RACH) resource or an additional RACH resource for a specific service; and 　　means for selecting either the legacy RACH resource or the additional RACH resource for the mobile device to use for the specific service.

41. An access network node comprising: 　　means for transmitting, to a mobile device, information for configuring at least one of a legacy random access channel (RACH) resource or an additional RACH resource for a specific service; and 　　means for transmitting, to the mobile device, information for selecting either the legacy RACH resource or the additional RACH resource for the mobile device to use for the specific service.

Images