Terminal device, network node for random access and methods thereof

Abstract

Embodiments of the present disclosure relate to methods, apparatus for validation of SBFD RACH Occasions in order for random access. A method implemented by an SBFD- aware UE receives a RACH configuration including SBFD ROs, and then, the UE validates a set of ROs of a certain RO type according to a RO validation requirement, based on the RACH configuration.

Description

[0001] P111907W001

[0002] TERMINAL DEVICE, NETWORK NODE FOR RANDOM ACCESS AND METHODS

[0003] THEREOF

[0004] This application claims the benefit of provisional application serial number US63 / 681304, filed on August 9th, 2024, the disclosure of which is hereby incorporated herein by reference in its entirety.

[0005] TECHNICAL FIELD

[0006] The non-limiting and exemplary embodiments of the present disclosure generally relate to the technical field of telecommunications, and specifically to methods and apparatuses for random accessing relevant to SBFD.

[0007] BACKGROUND

[0008] FDD and TDD systems

[0009] Transmission and reception from a node, e.g. a terminal in a cellular system, can be multiplexed in the frequency domain or in the time domain (or combinations thereof). Figure 1 illustrates frequency- and time-division duplex. Specifically, Frequency Division Duplex (FDD) as illustrated to the left in Figure 1 implies that downlink and uplink transmission take place in different, sufficiently separated, frequency bands. Time Division Duplex (TDD), as illustrated to the right in Figure 1 implies that downlink and uplink transmission take place in different, non-overlapping time slots. Thus, TDD can operate in unpaired spectrum, whereas FDD requires paired spectrum.

[0010] Typically, the structure of the transmitted signal in a communication system is organized in the form of a frame structure.

[0011] In more details, the following two information elements (IES) are defined in current 3 GPP specifications. The TDD pattern is typically configured with at least the first IE and optionally the 2ndIE:

[0012] • TDD-DL-UL-ConfigCommon (cell-specific)

[0013] • TDD-DL-UL-ConfigDedicated (UE-specific)

[0014] The first IE is cell specific (common to all UEs) and is provided by broadcast signaling. It provides the number of slots in the TDD pattern via a reference subcarrier spacing and a periodicity such that the S-slot pattern repeats every S slots. This IE allows for very flexible configuration of the pattern characterized as follows: P111907W001

[0015] • A number of full downlink slots at the beginning of the pattern configured by the parameter nDownlinkSlots

[0016] • A number of full uplink slots at the end of the pattern configured by the parameter nUplinkSlots

[0017] • A number of downlink ('D') symbols following the full downlink slots configured by the parameter nDownlinkSymbols

[0018] • A number of uplink ('U') symbols preceding the full downlink slots configured by the parameter nUplinkSlots

[0019] • If there is a gap between the last downlink symbol and the first uplink symbol, then all symbols in the gap are characterized as flexible ('F'). A symbol classified as 'F' can be used for downlink or uplink. A UE determines the direction in one of the following two ways: o Detecting a DCI that schedules / triggers a downlink (DL) signal / channel, e.g., PDSCH, CSI-RS or schedules / triggers an uplink (UL) signal / channel, e.g. PUSCH, SRS, etc. o By dedicated (UE-specific) signaling of the IE TDD-DL-UL- ConfigDedicated. This parameter overrides some or all of the 'F' symbols in the pattern, thus providing a semi-static indication of whether a symbol is classified as 'D' or 'U'.

[0020] • Optionally, a 2ndpattern that is concatenated to the first pattern can be configured as above. If a 2ndpattern is configured, the constraint is that the sum of the periodicities of the two patterns must evenly divide 20 ms.

[0021] Figure 2 illustrates an exemplary TDD DL / UL pattern configured by TDD-DL-UL- ConfigCommon and consisting of S = 5 slots. The example pattern consists of 3 full 'D' slots, 1 full 'U' slot, with a mixed slot in between consisting of 4 'D' symbols and 3 'U' symbols. The remaining 7 symbols in the mixed slot are classified as 'F.'

[0022] If a UE is not configured with TDD-DL-UL-ConfigDedicated, then the pattern at the top of the diagram is what it assumes. As stated above, the network can make use of the 'F' symbols flexibly, by scheduling / triggering either an uplink or a downlink signal / channel in a UE specific manner. This allows for very dynamic behavior: the direction is not known to the UE a priori; rather, the direction becomes known once the UE detects a DCI scheduling / triggering a particular DL or UL signal / channel. P111907W001

[0023] In contrast, the DL / UL direction for some or all of the 'F' symbols in a particular slot can be provided to the UE in a semi-static manner by RRC configuring the UE with TDD- DL-UL-ConfigDedicated. The lower part of Figure 2 shows 3 exemplary configurations for overriding 'F' symbols in Slot 3. If the IE indicates 'allDownlink' or 'allUplink' for a particular slot or slots, then all 'F' symbols in the slot are converted to either 'D' or U,' respectively. If the IE indicates 'explicit', then a number of symbols at the beginning of the slot and / or a number of symbols at the end of the slot are indicated as 'D' and U,' respectively. In the example below, the first 7 and the last 5 are indicated as 'D' and U', which converts some of the 'F' symbols (but not all in this example) to 'D' and U.'

[0024] The key behavior in the above is that the UE-specific IE TDD-DL-UL- ConfigDedicated can only override (i.e., specify 'D' or U') for symbols that are configured as 'F' by the cell-specific IE TDD-DL-UL-ConfigCommon. In other words, a UE does not expect to have a 'D' symbol converted to U' or vice versa.

[0025] Subband Full Duplex (SBFD)

[0026] As described above, in a conventional TDD system, entire carrier BW or all carriers in the same frequency band need to be utilizing the same DL transmission or UL reception directions. This is further illustrated in Figure 3, which depicts conventional TDD carrier or carrier systems.

[0027] For the Rel-18 evolution of the NR system, 3GPP has decided to study the technical feasibilities and potential benefits of subband full duplex (SBFD) systems. Figure 4 illustrates SBFD systems.

[0028] • In such a system, a portion of a wide bandwidth carrier may be used for a different direction than that of the rest of the carrier. This is illustrated in the left-hand side of Figure 4. That is, unlike a conventional TDD system as shown on the left-hand side of Figure 3 where the entire bandwidth is used for DL transmission in the first three slots, the center portion of the SBFD carrier is used for UL reception while the rest of the carrier continues to be used for DL transmission as shown in the left-hand side of Figure 4.

[0029] • Similarly, instead of utilizing all carriers for the same DL or UL directions in a conventional TDD system as shown in the right-hand side of Figure 3, some carrier(s) in the SBFD system can be used for a different direction than that of the other carriers as shown in the right-hand side of Figure 4.

[0030] In the 3GPP Rel-18 study, the scope has been limited such that in SBFD operation, P111907W001 only gNBs transmit DL and receive UL simultaneously. An individual UE is scheduled in only one direction (DL or UL) at a time.

[0031] Rel-18 PRACH Configuration

[0032] An exemplary PRACH configuration according to existing 3GPP Release 17 specifications is described here. The example is for frequency range 1 (FR1) for unpaired spectrum, and uses PRACH configuration index 118 from the existing 3GPP 38.211 Release 17 specification as follows:

[0033] Table 6.3.3.2-3: Random Access configurations for FR1 and unpaired spectrum

[0034] Figure 5 illustrates the example PRACH configuration from existing 3 GPP Release 17 specification. The example PRACH configuration assumes the PRACH SCS is 30 kHz. The value x = 2 in Table 6.3.3.2-3 above means that the PRACH configuration period is 2 radio frames (20 ms), and the value y = 1 means that the RACH occasions (ROs) occur in the 2ndframe of this period. Within this frame, the ROs occur in subframes 2, 3, 4, 7, 8, and 9. With 30 kHz SCS, there are two slots per subframe. Since the number of PRACH slots within a subframe is equal to 1 for this example, the 2ndslot of the subframe contains the ROs according to current 3 GPP Release 17 specifications. This means that the ROs are contained in slots 5,6,9, 14, 17, and 19. In this example PRACH format A3 (6 symbol duration) is used, hence there are two back-to-back ROs per slot starting at symbol 0 of the slot.

[0035] For this example, we assume that the cell-specific (common) TDD UL / DL pattern is D-D-D-D-U, which is also shown in Figure 5. In the existing 38.213 spec, the UE assumes that a RACH occasion is valid if it is within UL symbols according to the following text extract:

[0036] [38.213 Section 8.1]

[0037] For unpaired spectrum, if a UE is not provided tdd-UL-DL-ConfigurationCommon, a PRACH occasion in a PRACH slot is valid if it does not precede a SS / PBCH block in the PRACH slot and P111907W001 starts at least Wgapsymbols after a last SS / PBCH block reception symbol, where Wgapis provided in Table 8.1-2 and, if channelAccessMode = " semiStatic" is provided, does not overlap with a set of consecutive symbols before the start of a next channel occupancy time where the UE does not transmit [15, TS 37.213],

[0038] - the candidate SS / PBCH block index of the SS / PBCH block corresponds to the SS / PBCH block index provided by ssb-PositionsInBurst in SIB1 or in ServingCellConfigCommon , as described in clause 4.1

[0039] - If a UE is provided tdd-UL-DL-ConfigurationCommon, a PRACH occasion in a PRACH slot is valid if

[0040] - it is within UL symbols, or

[0041] - it does not precede a SS / PBCH block in the PRACH slot and starts at least Wgapsymbols after a last downlink symbol and at least (Vgapsymbols after a last SS / PBCH block symbol, where Wgapis provided in Table 8.1-2, and if channelAccessMode = "semiStatic" is provided, does not overlap with a set of consecutive symbols before the start of a next channel occupancy time where there shall not be any transmissions, as described in [15, TS 37.213]

[0042] - the candidate SS / PBCH block index of the SS / PBCH block corresponds to the SS / PBCH block index provided by ssb-PositionsInBurst in SIB1 or in ServingCellConfigCommon, as described in clause 4.1.

[0043] With the D-D-D-D-U pattern, it turns out that only slots 9 and 19 contain valid ROs.

[0044] The ROs in slots in 5, 7, 15, and 17 are invalid, as indicated by the four ”X” in Figure 5.

[0045] In the current 3GPP Release 17 38.331 specification, ROs are configured in the frequency domain via two parameters: msgl-FDM which indicates the number of ROs in the frequency domain (1, 2, 4, or 8) within an OFDM symbol, and msgl -Frequency Start which indicates the lowest indexed RB in the active BWP of the first RO in the frequency domain.

[0046] RACH-ConfigGeneric information element

[0047] RACH-ConfigGeneric : : = SEQUENCE { prach-Conf igurationlndex INTEGER ( 0 . . 255 ) , msgl-FDM ENUMERATED { one , two , four, eight } , msgl -Frequency Start INTEGER ( 0 . . maxNrofPhysicalResourceBlocks-1 ) , zeroCor relat ionZoneConf ig INTEGER ( 0 . . 15 ) , preambleReceivedTarget Power INTEGER ( -202 . . -60 ) ,

[0048] It is however unclear how to introduce SBFD functionality into the random access procedure, for the SBFD-aware UEs and SBFD capable network nodes, along with the P111907W001 current random access procedure.

[0049] SUMMARY

[0050] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0051] It is unclear how SBFD functionality is introduced to facilitate resource efficiency while limiting interference in the system. Further, there exist certain challenge(s) even if SBFD functionality is added as a complementary in a TDD system. For example, previous solutions only configure one kind of RO in one kind of resource. In order to allow for such flexibility, there is a need for a method and apparatus allowing the network and its devices to configure different RO types and / or different resources.

[0052] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. For example, methods and systems are provided for performing RO validation for SBFD ROs.

[0053] In a first aspect of the present disclosure, a method performed at a SBFD-aware terminal device is provided. The terminal device supporting SBFD functionality receives a RACH configuration which comprises configuration for SBFD random access. The terminal device then validates a set of RACH occasions which fulfills a RO validation requirement based on the received RACH configuration.

[0054] In an example, the RO validation requirement relates to a RO type. In a further example, the RO type would be a conventional uplink RO or a SBFD RO, which is entirely comprised within SBFD symbols or SBFD downlink symbols, and / or spanning both a SBFD symbol and an uplink symbol or a flexible symbol. In yet a further example, the terminal device is required to use SBFD RO, then, it validates a set of SBFD ROs whose location, as configured by the RACH configuration, is entirely comprised within SBFD symbols or SBFD downlink symbols, and / or spanning both a SBFD symbol and an uplink symbol or a flexible symbol.

[0055] In an example, the RO validation requirement further relates to relative location of a RO to a subband, and / or RRC mode of the terminal device. In a further example, a valid RO is restricted from a subband edge, so as to mitigate interference and better the RACH performance. In another example, terminal devices in RRC IDLE or RRC INACTIVE are P111907W001 restricted to use ROs with certain locations, e.g., close to downlink subband, to avoid generation of cross link interference (CLI) to downlink receptions.

[0056] In a second aspect of the present disclosure, a method performed at a SBFD-capable network node is provided. The network node is configured to communicate with an SBFD- aware terminal device. It transmits a RACH configuration to the terminal device, which comprises configuration for SBFD random access. After the terminal device’s processing, it receives a preamble from the terminal device in a valid RO determined by the terminal device based on the RACH configuration.

[0057] In a further example, the SBFD-capable network node configures the SBFD-aware terminal device with TDD pattern and also sends an indication to enable the terminal device to validate a set of RO based on a RO validation requirement.

[0058] In yet a further example, the terminal device is indicated to validate ROs with the type of SBFD. The locations of the set of SBFD ROs being entirely comprised within SBFD symbols and / or spanning both an SBFD symbol and an uplink / flexible symbol enable the terminal device to validate this set. And then, the network node receives a preamble in one of SBFD RO in the valid set.

[0059] BRIEF DESCRIPTION OF THE DRAWINGS

[0060] The above and other aspects, features, and benefits of various embodiments of the present disclosure will become more fully apparent, by way of example, from the following detailed description with reference to the accompanying drawings, in which reference numerals or letters are used to designate like or equivalent elements. The drawings are illustrated for facilitating better understanding of the embodiments of the disclosure and not necessarily drawn to scale, in which:

[0061] Figure 1 illustrates uplink and downlink resources configured / scheduled in traditional FDD and TDD systems;

[0062] Figure 2 illustrates examples when TDD dedicated configuration overriding a TDD common configuration, according to current schemes;

[0063] Figure 3 illustrates how uplink and downlink resources are configured for TDD carrier or carrier system in a conventional TDD system;

[0064] Figure 4 illustrates a subband, in SBFD operation, can be configured / scheduled for uplink while other subband(s) in a same carrier or carrier system is configured / scheduled for downlink according to the current 3GPP Release 18 study; P111907W001

[0065] Figure 5 illustrates how a UE determines which conventional ROs to validate based on PRACH configuration and TDD UL / DL pattern, according to the conventional scheme;

[0066] Figure 6 depicts a flowchart implemented by an SBFD-aware UE to facilitate a random access procedure to an SBFD-capable by validating a set of RACH Occasions with a certain RO type, according to some embodiments of the present disclosure;

[0067] Figure 7 illustrates a RO validation requirement that the relative RO location to a subband edge according to some embodiments of the present disclosure;

[0068] Figure 8 illustrates a flowchart implemented by an SBFD-capable network node to facilitate a random access procedure with an SBFD-aware UE which validates a set of ROs with a certain RO type, according to some embodiments of the present disclosure;

[0069] Figure 9 depicts a structure of a communication system including a user equipment and a network node as an example to perform the methods according to the embodiments of the present disclosure;

[0070] Figure 10 depicts a structure of a user equipment as an example to perform the methods according to the embodiments of the present disclosure;

[0071] Figure 11 depicts a structure of a network node as an example to perform the methods according to the embodiments of the present disclosure.

[0072] DETAILED DESCRIPTION

[0073] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0074] As used herein, ‘node’ can be a network node or a UE. Examples of network nodes are NodeB, base station (BS), multi -standard radio (MSR) radio node such as MSR BS, eNodeB (eNB), gNodeB (gNB), Master eNB (MeNB), Secondary eNB (SeNB), integrated access backhaul (IAB) node, network controller, radio network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), Central Unit (e.g. in a gNB), Distributed Unit (e.g. in a gNB), Baseband Unit, Centralized Baseband, C-RAN, access point (AP), transmission points, transmission nodes, Remote Radio Unit (RRU), Remote Radio Head (RRH), nodes in distributed antenna system (DAS), core network node (e.g. Mobile Switching Center (MSC), Mobility Management Entity (MME), etc.), Operations & Maintenance (O&M), Operations Support System (OSS), Self Organizing P111907W001

[0075] Network (SON), positioning node (e.g. E-SMLC), etc. The terms network node and radio network node are used interchangeably herein.

[0076] Another example of a node is user equipment (UE), which is a non-limiting term and refers to any type of wireless device communicating with a network node and / or with another UE in a cellular or mobile communication system. Examples of UE are target device, device to device (D2D) UE, vehicular to vehicular (V2V), machine type UE, MTC UE or UE capable of machine to machine (M2M) communication, Personal Digital Assistant (PDA), Tablet, mobile terminals, smart phone, laptop embedded equipment (LEE), laptop mounted equipment (LME), Unified Serial Bus (USB) dongles, etc.

[0077] The term radio access technology (RAT), may refer to any RAT such as, for example, Universal Terrestrial Radio Access Network (UTRA), Evolved Universal Terrestrial Radio Access Network (E-UTRA), narrow band internet of things (NB-IoT), WiFi, Bluetooth, next generation RAT, NR, 4G, 5G, etc. Any of the equipment denoted by the terms node, network node or radio network node may be capable of supporting a single or multiple RATs.

[0078] The term signal or radio signal used herein can be any physical signal or physical channel. Examples of downlink (DL) physical signals are reference signal (RS) such as Primary Synchronization Signal (PSS), Secondary Synchronization Signal (SSS), Channel State Information-Reference Signal (CSLRS), Demodulation Reference Signal (DMRS) signals in SS / PBCH block (SSB), discovery reference signal (DRS), Cell Specific Reference Signal (CRS), Positioning Reference Signal (PRS), etc. RS may be periodic. For example, RS occasions carrying one or more RSs may occur with certain periodicity (e.g., 20 ms, 40 ms, etc.). The RS may also be aperiodic.

[0079] Each SSB carries New Radio-Primary Synchronization Signal (NR-PSS), New RadioSecondary Synchronization Signal (NR-SSS) and New Radio-Physical Broadcast Channel (NR-PBCH) in four successive symbols. One or multiple Synchronization Signal Blocks (SSBs) are transmitted in one SSB burst which is repeated with certain periodicity such as, for example, 5 ms, 10 ms, 20 ms, 40 ms, 80 ms, and 160 ms. The UE is configured with information about SSB on cells of certain carrier frequency by one or more SS / PBCH block measurement timing configuration (SMTC) configurations. The SMTC configuration comprising parameters such as SMTC periodicity, SMTC occasion length in time or duration, SMTC time offset with regard to reference time (e.g., serving cell’s SFN) etc. Therefore, SMTC occasion may also occur with certain periodicity (e.g., 5 ms, 10 ms, 20 ms, 40 ms, 80 ms, and 160 ms). Examples of uplink (UL) physical signals are reference signals such as P111907W001

[0080] Sounding Reference Signals (SRS), Demodulation Reference Signals (DMRS), etc. The term physical channel refers to any channel carrying higher layer information e.g. data, control etc. Examples of physical channels are Physical Broadcast Channel (PBCH), Physical Downlink Control Channel (PDCCH), Physical Downlink Shared Channel (PDSCH), Physical Uplink Shared Channel (PUSCH), Physical Uplink Control Channel (PUCCH), Physical Uplink Shared Channel (PUSCH), Short PUSCH (sPUCCH), Short PDSCH (sPDSCH), Short PUCCH (sPUCCH), Short PUSCH (sPUSCH), MTC PDCCH (MPDCCH), Narrowband PBCH (NPBCH), Narrowband PDCCH (NPDCCH), Narrowband PDSCH (NPDSCH), Narrowband PUSCH (NPUSCH), Enhanced PDCCH (E-PDCCH), etc.

[0081] The term time resource used herein may correspond to any type of physical resource or radio resource expressed in terms of length of time. Examples of time resources are symbol, time slot, subframe, radio frame, transmission time interval (TTI), interleaving time, slot, sub-slot, mini-slot, system frame number (SFN) cycle, hyper-SFN (H-SFN) cycle, etc.

[0082] According to certain embodiments, methods and systems are provided for performing RO validation for SBFD ROs. For example, according to certain embodiments, a method in a wireless device for configuring or validating SBFD ROs in a network supporting SBFD operation includes: a. Receiving a RACH configuration b. Determining an RO validation requirement based on the RACH configuration c. Validating an RO based on the determined RO validation requirement

[0083] Certain embodiments of the present disclosure may provide one or more technical advantages. For example, certain embodiments may enable configurable RO validation while still maintaining same or similar properties within a configuration. Configuring ROs with different reception properties is undesirable since it will cause network properties, e.g., coverage, to depend on the RO. For example, an RO in SBFD symbols may experience significantly higher interference levels compared to an RO in UL symbols. For that reason, it is desirable to configure one of the two types of ROs (SBFD and UL), and to configure that type of RO with, e.g., a power configuration that is suitable for the expected conditions of the type of RO. Hence, there is a need for a configurable RO validation allowing a proper selection and consistent configuration of the configured ROs.

[0084] As another example, certain embodiments may provide a technical advantage of advantageously restricting ROs immediately at the subband edge, due to a more challenging P111907W001 interference at those locations. As a result, a more coherent RACH performance among different ROs can be achieved.

[0085] As still another example, certain embodiments may provide a technical advantage of allowing for separation of ROs between devices of different RRC states. For example, devices in RRC CONNECTED may be restricted to use one set of ROs whereas devices in RRC IDLE or RRC INACTIVE are restricted to use another set. The reason is that certain ROs (e.g., close to DL subband) if used by UEs (e.g., using high power) in RRC CONNECTED may likely generate CLI to DL reception, while those ROs may be ok / doable to be used by some UEs in RRC IDLE or RRC INACTIVE not generating high CLI (e.g., NW only schedules those ROs (such as contention free RA or PDCCH order) to UEs which are not generating CLI). Therefore, the network can control ROs for different RRC states separately. Or in other words, the network would only enable / activate certain ROs for UEs in RRC IDLE or RRC INACTIVE when the CLI is likely low generated by RACH initiated by UEs in RRC IDLE or RRC INACTIVE.

[0086] In a particular embodiment, following validation, the method further includes a. Determining an SSB-to-RO mapping based on the RO configuration b. Selecting an RO from the validated ROs and determined SSB-to-RO mapping c. Transmitting a preamble at the selected RO

[0087] In a particular embodiment, the RACH configuration is received from SIB1 or RRC signaling.

[0088] In a particular embodiment, the RO validation requirement is determined to be one of, or combinations of a. ‘SBFD symbols only’ b. ‘SBFD and UL / F symbols overlapping’ c. ‘Non-SBFD symbols only’

[0089] In a particular embodiment, a default RO validation requirement is provided implicitly (through lack of signaling).

[0090] In a particular embodiment, an optional RO configuration is provided explicitly by configuration.

[0091] In a particular embodiment, ‘SBFD symbols only’ further implies that the RO is entirely comprised within SBFD symbols or SBFD DL symbols.

[0092] In a particular embodiment, ‘SBFD and UL / F symbols’ further implies that the RO is starting in SBFD symbols and ending in non-SBFD UL and / or flexible symbols. P111907W001

[0093] In a particular embodiment, ‘UL / F symbols only’ further implies that the RO is entirely comprised within non-SBFD UL and / or flexible symbols.

[0094] In a particular embodiment, a further validation requirement is that the RO is located at least a distance from the edge of a subband. In a further particular embodiment, the subband edge relates to one or more of: an UL subband edge and a DL subband edge.

[0095] In a particular embodiment, the RO validation rule related to the device mode is based on: a specification, or the RACH configuration. In a further particular embodiment, the RO validation rule and / or RO validation is based on RRC mode.

[0096] In a particular embodiment, determination of the RO validation requirement is based on whether the device is in RRC CONNECTED, RRC IDLE, or RRC INACTIVE mode.

[0097] In a particular embodiment, the RO validation rule related to the device mode is based on: a specification, or the PRACH configuration.

[0098] All above where what is applied to SBFD ROs, SBFD-aware UEs and SBFD capable network nodes equally applies to other ROs, devices and network nodes.

[0099] Figure 6 depicts a flowchart illustrating a method in an SBFD-aware device (UE) for validating ROs in order to perform random access towards an SBFD-capable network node, according to certain embodiments.

[0100] In a first step (110), the device (UE) receives a RACH configuration from a network node (e.g., gNB). The RACH configuration may be derived via multiple messages and signaling types but will in aggregate inform the device about how to perform random access in the cell to which it is (or will be) associated. For example, the RACH configuration includes configurations for conventional uplink RACH occasions and SBFD RACH occasions which are received via respective signaling. Alternatively, they are comprised in a single message.

[0101] In a second step (120), the device validates a set of ROs (at least one RO) based on the determined RO validation requirement. The set of ROs are validated due to they fulfill a RO validation requirement based on the RACH configuration. Alternatively, or additionally, the validation requirement may be based on a specification.

[0102] In an optional fourth step (130), the device determines an SSB-to-RO mapping based on the configuration and the validated set of ROs.

[0103] In an optional fifth step (140), the device selects an RO from the validated set of ROs and determined SSB-to-RO mapping. P111907W001

[0104] In an optional sixth step (150), the device transmits a PRACH preamble on the selected RO.

[0105] According to various particular embodiments, the second step (120) of Figure 6 may be performed as follows:

[0106] Validation Based on RO Type

[0107] In a particular embodiment, the RO validation requirement relates to which type of RO is to be validated. Only ROs with configured location fulfilling one or more but not all of the below are validated:

[0108] • ‘SBFD symbols only’, i.e., only ROs that are entirely comprised within SBFD symbols may be validated. Alternatively, or additionally, a further restriction may be made such that only ROs in SBFD symbols configured as DL in TDD- UL-DL-ConfigCommon may be validated.

[0109] • ‘SBFD and UL / F symbols’, i.e., only ROs spanning both SBFD symbols and UL / flexible symbols may be validated. Alternatively, and / or additionally, only ROs starting in SBFD symbols and ending in UL / flexible symbols may be validated.

[0110] • ‘Non-SBFD symbols’, i.e., only ROs that are entirely comprised within non- SBFD symbols may be validated. Additionally, and / or alternatively, only ROs comprised in UL and / or flexible symbols may be validated.

[0111] In a particular embodiment, a default validation requirement is defined in a specification and may be determined implicitly whereas the other validation requirements are provided by configuration signaling. Such signaling may be either cell-specific or UE- specific signaling and may be provided in either system information (e.g., SIB1) or RRC signaling.

[0112] Validation based on RO frequency location vs subband edge

[0113] In a particular embodiment, the validation requirement is that the RO needs to be located a minimum distance from a subband edge. FIGURE 7 illustrates validation in relation to UL subband edge.

[0114] The subband edge may relate to either the nearest UL subband edge or the nearest DL subband edge. For example, an RO located immediately at the UL subband edge may be determined to be invalid (i.e., is invalidated) whereas an RO located X (e.g., 2) PRBs or more from the UL subband edge may be determined as valid (i.e., is validated), as shown in Figure 7. Which subband edge is concerned and the necessary distance from the subband edge may P111907W001 be provided by a specification or provided as a part of the RACH configuration, or a combination thereof.

[0115] Validation based on RRC mode

[0116] In a particular embodiment, the validation requirement related to the RRC state that the device is presently in. That is, the validated ROs depends on whether the device is in RRC CONNECTED, RRC IDLE or RRC INACTIVE. Also here, the requirement and associated configuration may be provided by a specification or provided as a part of the RACH configuration, or a combination thereof. The ROs associated with RRC CONNECTED may be more frequent than ROs associated with RRC IDLE or RRC INACTIVE in order to allow for low latency and high-capacity industrial networks.

[0117] What is described above for SBFD ROs, SBFD-aware devices and SBFD-capable network nodes may apply equally to other ROs, devices and network nodes.

[0118] Validation based on signaling indication on whether the RO is active or inactive

[0119] In a particular embodiment, the network node (e.g., the gNB) may signal one or more of the below

[0120] 1. Which ROs are active or inactive

[0121] 2. Which ROs are active or inactive for UEs in RRC CONNECTED

[0122] 3. Which ROs are active or inactive for UEs in RRC IDLE or RRC INACTIVE

[0123] Via the signaling alternatives including system information, RRC signaling, MAC CE or LI signaling.

[0124] In an example, the gNB signals UEs what ROs (e.g., overlapping with SBFD symbols, for instance, ROs entirely comprised within SBFD symbols, or spanning both SBFD symbols and UL / flexible symbols) are active or inactive from mitigating / avoiding CLI (e.g., CLI between UL transmission and DL reception) perspective.

[0125] In an example, the gNB signals active / inactive ROs to UEs in RRC CONNECTED, RRC IDLE or RRC INACTIVE separately.

[0126] Validation based on UE location

[0127] In a particular embodiment, the validation requirement is related to UE location.

[0128] In an example, ROs (e.g., e.g., overlapping with SBFD symbols, for instance, ROs entirely comprised within SBFD symbols, or spanning both SBFD symbols and UL / flexible symbols) are valid only for UEs in cell center since e.g., the UE’s UL transmission (using UL subband in SBFD symbols) may generate low CLI to DL reception of other UEs. P111907W001

[0129] In an example, ROs (e.g., e.g., overlapping with SBFD symbols, for instance, ROs entirely comprised within SBFD symbols, or spanning both SBFD symbols and UL / flexible symbols) are invalid for UEs in cell edge since e.g., the UE’s UL transmission (using UL subband in SBFD symbols) may generate high CLI to DL reception of other UEs.

[0130] In an example, the UE’s location is determined based on GPS location or any other navigation system (e.g., Galileo or Baidu).

[0131] In an example, the UE’s location is determined based on positioning methods (e.g., Multi-RTT or TDOA).

[0132] In an example, the UE’s location is determined based on DL measurements performed by UE itself. For instance, the UE’s location is determined as at the cell edge if the UE’s measured DL measurement is below a configured threshold (e.g., RSRP threshold). The UE’s location is determined as close to the cell center (or far away from the cell edge) if the UE’s measured DL measurement is above a configured threshold (e.g., RSRP threshold).

[0133] In a variant of this embodiment, the UE’s location is determined based on the UL power the UE is using. For instance, UE’s location is determined as at the cell edge if the UE’s transmission power is above a configured threshold. The UE’s location is determined as close to the cell center (or far away from the cell edge) if the UE’s transmission power is below a configured threshold. In one variant the power used for the determination is including the power ramping and in another variant it is not. Whether power ramping should be included or not can either be fixed in the specification or signaled to the UE, e.g. using RRC signaling.

[0134] Below are some more detailed thoughts on how to specify SBFD operation to support random access in SBFD symbols by UEs.

[0135] When considering frequency domain RO location, in order to combine legacy ROs, advantageously located at the carrier edge to make better use of the remaining UL resources, with new SBFD ROs, assumed to be located in the center of the carrier, a new interpretation of msgl -Frequency Start, that for legacy RACH currently indicates an offset for the 1st RO to PRB 0 of the active BWP. A simple solution would be to reinterpret msgl -Frequency Start to instead indicate an offset of the 1st RO to the UL subband. However, that implies that legacy ROs are always allocated towards the lower end of the carrier and not the upper end in which case the ROs may even fall outside the UL subband. A more flexible solution would be to introduce a modulus operation such that ROs are wrapped around the UL subband bandwidth. This solution is a reasonable trade-off between keeping legacy RO configurations and P111907W001 allowing SBFD ROs to reliably end up within the UL subband. Mathematically, this can be expressed as cyStart start of the 1st RO and the start of the UL subband, respectively. The start of the nth RB, , would then be determined as a modulus operation in relation to the number of RBs of the UL subband, less the RO bandwidth, where the start of the nth RO before and after adjustment respectively, and the UL subband bandwidth is and the RO size isWR™, such that all

[0136] ROs are always fully comprised within the UL subband.

[0137] When considering time domain RO location, it is proposed to adopt the same SSB-to- RO Ngap margins as are valid for legacy operation. In the context, it is worth noting that there are also general transition gaps in NR from Rx to Tx and vice versa. These gaps are approximately 13 ps and 7 ps for FR1 and FR2, respectively. That implies that Rx and Tx are separated by at least one or two symbols, depending on numerology, disregarding channel propagation and TA settings. However, it does not necessarily mean that DL and UL symbols need to be separated with the same amount. A UE performing RA will not be scheduled to receive in the one or two symbols immediately preceding the RO. Hence, there is no need to take the general gap into account as a criterium for RO validation.

[0138] When considering power control, the interference levels in an SBFD symbol and an UL symbol may significantly differ. Furthermore, interference levels will differ among SBFD symbols, predominantly depending on DL traffic load for the particular SBFD symbol. Fortunately, the load is known by the gNB since the gNB itself is responsible for it, provided self-interference is the dominant factor. However, that may not always be the case, for which reason a separate power control is sensible. That would allow the network to configure approximately the same detection performance between legacy ROs and SBFD ROs for a base load scenario for the single configuration. Additionally, it allows adjusting detection sensitivity vs range for the additional RACH configuration in the dual RACH configuration option. It is proposed to support separate power control for SBFD ROs for both single and dual RACH configurations. P111907W001

[0139] When considering single RACH configuration, somewhat related to the SSB-to-RO gap, but with a different order of magnitude, is the question about time locations for SBFD ROs in relation to legacy ROs. The benefit would be that more evenly distributed ROs would reduce initial access latency. This is an issue that is only valid for the single RACH configuration and does not affect he additional RACH configuration where latency is not a prioritized KPI. Introducing functionality for more evenly distributed ROs would also affect the SSB-to-RO distance. It is understood that the absolute majority of Msgl transmissions takes place subsequent to SSB measurements, often with some averaging over multiple SSBs. For that reason, for latency reasons, there is an advantage in maintain ROs close to the SSBs to which they are associated, and not swapping it to be nearby another SSB. It is proposed that PRACH is intimately related to SSB measurements. To reduce latency, it is desirable to limit the duration between the RO and its associated SSB and not introduce shifts in the SSB- to-RO mapping.

[0140] When considering additional RACH configuration, 3GPP RANI #117 meeting resulted in the following two agreements regarding the additional RACH configuration: Agreement 1: Update the following agreement made in RANl#116-bis meeting:

[0141] For RACH configuration Option 2 (i.e., Use two separate RACH configurations, including one legacy RACH configuration and one additional RACH configuration) to support random access operation for SBFD-aware UEs in RRC CONNECTED state, and for interpretation of the parameter prach-Configurationlndex provided by the additional RACH configuration,

[0142] -For FR2, adopt the following: o Alt 1: use existing random access configurations table for unpaired spectrum (i.e., Table 6.33.2-4 in TS38.211)

[0143] ■ FFS whether to introduce new parameter(s) to determine the slot number for ROs in SBFD symbols.

[0144] -For FR1, consider from the following alternatives: o Alt 1: Use existing random access configurations table for unpaired spectrum (i.e., Table 6.3.3.23 in TS38.211)

[0145] ■ FFS whether to introduce new parameter(s) to determine the subframe number for ROs in SBFD symbols. o Alt 2: Use existing random access configurations table for paired spectrum / supplementary uplink (i.e., Table 6.33.2-2 in TS38.211)

[0146] Agreement 2:

[0147] A RO across SBFD symbols and non-SBFD symbols in the same slot or across slots is invalid by default. P111907W001

[0148] A configured RO starting from SBFD symbol and ending in non-SBFD symbol either in the same slot or across different slots can be valid based on network configuration. This is only supported for RACH configuration option 2 and only supported for the ROs configured by the additional RACH configuration. If network configures such RO as a valid RO, UE should treat the RO as an additional-RO in SBFD symbols, and the followings are assumed by network and UE:

[0149] - The same frequency resources are used for both the SBFD segment and non-SBFD segment of the PRACH.

[0150] - The same UL transmit power is used for both the SBFD segment and non-SBFD segment of the PRACH.

[0151] - The same UL spatial domain filter is used for both the SBFD segment and non-SBFD segment of the PRACH.

[0152] - UE doesn't stop PRACH transmission in the transition period / gap (if any) between SBFD and non-SBFD symbols

[0153] - There are no phase coherency requirements on the UE between the SBFD segment and non-SBFD segment of the PRACH.

[0154] -Other assumptions are not precluded.

[0155] NOTE: For FR2, network may need to ensure that the additional-RO and the legacy RO, which overlap with each other in time domain, are mapped to the same SSB.

[0156] The remaining issue relating to the additional RACH configuration is what configuration tables to use. According to previous agreements, either the existing table for unpaired spectrum is used, or new entries may be introduced on top of the existing ones. Additionally, for FR1, the configuration tables for paired spectrum may be used. In our view, the existing tables provide sufficient flexibility for both FR1 and FR2, why Alt. 1 is preferred for both cases. As is evident from Table 6.3.3.2-2 and Table 6.3.3.2-3 in TS 38.211, e.g., for preamble formats 0 and 3, the same number of entries exist in both tables, providing the same amount of flexibility. Any exception from the already specified behavior should be properly justified. It is proposed that the additional RACH configuration uses the existing PRACH configurations tables for unpaired spectrum for both FR1 and FR2, i.e., Table 6.3.3.2-4 and Table 6.3.3.2-3, respectively (Alt. 1).

[0157] Closely related to the PRACH configuration tables and left as an FFS in the agreement, is whether any additional functionality is needed to control RO density, considering the PRACH tables have not been designed with the intention of using more than one table at a time. Hence, introducing a second PRACH configuration, or even including additional ROs in a single PRACH configuration, may result in unnecessarily large PRACH overhead. For that reason, it would be sensible to include a mechanism to further restrict the number of ROs such that not all SBFD ROs contained in SBFD symbols and the UL subband P111907W001 are validated. This may be achieved, e.g., by invalidating certain subframes among the set of valid subframes in the PRACH configuration. It is proposed that for the additional RACH configuration, support further RO validation restrictions, e.g., by an RO puncturing bitmap.

[0158] Also discussed in RANl #116-bis is the RO validation rules, where the two alternatives were whether ROs (entirely located) in non-SBFD symbols should be valid or not. Our view is that they should not, for a few reasons. First, there may be collisions with legacy ROs that would need resolution. Second, the need is doubtful, since the additional RACH configuration would already imply more PRACH resources than for legacy, and capacity is not the primary reason for introducing the additional RACH configuration and it would reduce UL capacity. Fourth, UL scheduling would be more complicated since contiguous Type 1 scheduling would not be applicable around the additional ROs in UL symbols, affecting scheduling efficiency. It is proposed that additional ROs entirely located in non-SBFD symbols configured by additional RACH configuration are invalid for SBFD- aware UEs (Alt. 2-3).

[0159] If it is agreed to also validate ROs entirely in non-SBFD symbols (Alt. 2-4), this should be done with care to not jeopardize consistency of preamble detection. Considering the highly varying interference conditions that will be found in SBFD and non-SBFD symbols, it is not desirable to mix ROs from the two symbol types since that would result in unpredictable preamble detection performance and correspondingly unpredictable cell coverage. For this reason, we propose to clearly indicate the valid RO based on three fundamental types, two of which have already been agreed:

[0160] ROs located entirely in SBFD symbols (the default RO validation type),

[0161] ROs starting in SBFD symbols and ending in non-SBFD symbols, and

[0162] ROs located entirely in non-SBFD symbols.

[0163] This leads us to the following observation and proposal:

[0164] Allowing ROs to be located in a mix of only SBFD symbols, SBFD / UL / F symbols or only UL / F symbols will result in widely differing preamble detection performance among different ROs.

[0165] Unless Alt. 2-3 is agreed, support configuration of RO locations into:

[0166] • SBFD symbols only (default configuration)

[0167] • SBFD and UL / F symbols (per previous agreement)

[0168] • UL / F symbols only (new agreement) P111907W001

[0169] Considering what other RACH configuration parameters that need to be supported by the additional RACH configuration, the below may serve as a starting point for a discussion. Naturally, a new prach-Configrationlndex is needed, considering the main objective with the additional RACH configuration is to extend cell range for RA. As a consequence, a new msgl-SubcarrierSpacing is also needed considering the long RACH formats are operating on different SCS compared to the short formats that are presently used. Another consequence of including the long formats is that a new msgl-FDM needs to be specified, to align the timefrequency resource of the additional preamble. Closely related, it is also justifiable to specify a new msgl-FrequencyStart.

[0170] It is also reasonable to be able to separately configure the SSB-to-RO as well as the number of preambles (both total and contention based), since the requirements for SBFD RACH may differ significantly from legacy RACH. For this reason, ssb-perRACH- OccasionAndCB-PreamblesPerSSB and totalNumberOfRA-Preambles should be provided separately. Finally, since the additional configuration format (long vs short) may differ from the legacy configuration, the prach-RootSequencelndex should also be separately provided.

[0171] It is proposed to support the following additional parameters for the additional RACH configuration (in addition to power control that is discussed elsewhere):

[0172] • prach-Configurationlndex

[0173] • msgl-SubcarrierSpacing

[0174] • msgl -Frequency Start

[0175] • msgl-FDM

[0176] • ssb-perRACH-OccasionAndCB-PreamblesPerSSB

[0177] • totalNumberOfRA-Preambles

[0178] • prach-RootSequencelndex

[0179] When considering the indication of support for SBFD RA, even though the network supports SBFD, it may not want to enable SBFD RA. One reason for that may be that SBFD RA may result in additional overhead or maybe the UL subbands are only needed in RRC CONNECTED mode for less mobility sensitive devices. Particularly because IDLE mode RA is supported, the UE needs to know already from reading SIB1 whether SBFD RA is supported, to be able to benefit from it. For the double PRACH configuration, the inclusion of the second configuration in RRC would implicitly also indicate a support for SBFD RA, however for the single RACH configuration case, there would not necessarily be such an P111907W001 indication, not even for RRC CONNECTED. For that reason, we propose to explicitly indicate whether SBFD RA is supported for the single PRACH configuration. Therefore, even if the network supports SBFD, the additional overhead associated with the introduction of more ROs should not be mandated. Network enabling of SBFD RACH can be indicated in RRC for the single RACH configuration.

[0180] Getting back to some embodiments implemented by a network node, Figure 8 illustrates an example method by an SBFD-capable network node. In the illustrated embodiment, the method includes a transmitting step at 810. For example, at step 810, the network node may transmit, to a UE, a RACH configuration, including configuration for conventional uplink RACH occasions and SBFD RACH occasions. At step 840, it receives a preamble in one RACH occasion of a valid RO set with a certain RO type.

[0181] In a further example, at step 820 (normally ahead of step 810 for TDD configuration is transmitted prior to RACH configurations while also possibly later), the SBFD-capable network node transmits a TDD configuration to the SBFD-aware UE, so that the UE knows which symbols are uplink symbols, downlink symbols, flexible symbols, or SBFD symbols, or SBFD downlink symbols, etc,. In some cases, the TDD configuration can be received by the SBFD-aware UE from another network node. Therefore, this step is optional to the SBFD-capable network node.

[0182] In a further example, at step 830, the SBFD-capable network node transmits an indication to the UE, related to at least one RO validation requirement for validating at least one RO. It can be an indication related to at least one of: a RO type to be validated, relative location of a RO to a subband, RRC mode of the terminal device and location of the terminal device. Alternatively, a default RO validation requirement may also preconfigured in the UE so that the indication may not necessarily received by the UE.

[0183] Figure 9 shows an example of a communication system QQ100 in accordance with some embodiments. In the example, the communication system QQ100 includes a telecommunication network QQ102 that includes an access network QQ104, such as a radio access network (RAN), and a core network QQ106, which includes one or more core network nodes QQ108. The access network QQ104 includes one or more access network nodes, such as network nodes QQl lOa and QQl lOb (one or more of which may be generally referred to as network nodes QQ110), or any other similar 3rd Generation Partnership Project (3GPP) access node or non-3GPP access point. The network nodes QQ110 facilitate direct or indirect P111907W001 connection of user equipment (UE), such as by connecting UEs QQ112a, QQ112b, QQ112c, and QQ112d (one or more of which may be generally referred to as UEs QQ112) to the core network QQ106 over one or more wireless connections.

[0184] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system QQ100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system QQ100 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0185] The UEs QQ112 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes QQ110 and other communication devices. Similarly, the network nodes QQ110 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs QQ112 and / or with other network nodes or equipment in the telecommunication network QQ102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network QQ102.

[0186] In the depicted example, the core network QQ106 connects the network nodes QQ110 to one or more hosts, such as host QQ116. The host QQ116 may be under the ownership or control of a service provider other than an operator or provider of the access network QQ104 and / or the telecommunication network QQ102, and may be operated by the service provider or on behalf of the service provider. The host QQ116 may host a variety of applications to provide one or more service.

[0187] As a whole, the communication system QQ100 of Figure 9 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures.

[0188] In some examples, the telecommunication network QQ102 is a cellular network that implements 3 GPP standardized features. Accordingly, the telecommunications network QQ102 may support network slicing to provide different logical networks to different devices P111907W001 that are connected to the telecommunication network QQ102. For example, the telecommunications network QQ102 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive loT services to yet further UEs.

[0189] In some examples, the UEs QQ112 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network QQ104 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network QQ104. Additionally, a UE may be configured for operating in single- or multi-RAT or multistandard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[0190] In the example, the hub QQ114 communicates with the access network QQ104 to facilitate indirect communication between one or more UEs (e.g., UE QQ112c and / or QQ112d) and network nodes (e.g., network node QQl lOb). In some examples, the hub QQ114 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub QQ114 may be a broadband router enabling access to the core network QQ106 for the UEs. As another example, the hub QQ114 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes QQ110, or by executable code, script, process, or other instructions in the hub QQ114. The hub QQ114 may have a constant / persistent or intermittent connection to the network node QQl lOb. The hub QQ114 may also allow for a different communication scheme and / or schedule between the hub QQ114 and UEs (e.g., UE QQ112c and / or QQ112d), and between the hub QQ114 and the core network QQ106.

[0191] Figure 10 shows a UE QQ200, which may be an embodiment of the UE 112 of Figure 9, in accordance with some embodiments.

[0192] As used herein, a UE refers to a terminal device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), P111907W001 wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop -embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customerpremise equipment (CPE), vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0193] A UE may support device-to-device (D2D) communication, for example by implementing a 3 GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).

[0194] The UE QQ200 includes processing circuitry QQ202 that is operatively coupled via a bus QQ204 to an input / output interface QQ206, a power source QQ208, a memory QQ210, a communication interface QQ212, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Figure 10. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0195] The processing circuitry QQ202 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory QQ210. The processing circuitry QQ202 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any P111907W001 combination of the above. For example, the processing circuitry QQ202 may include multiple central processing units (CPUs).

[0196] In the example, the input / output interface QQ206 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. An input device may allow a user to capture information into the UE QQ200. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0197] In some embodiments, the power source QQ208 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source QQ208 may further include power circuitry for delivering power from the power source QQ208 itself, and / or an external power source, to the various parts of the UE QQ200 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source QQ208. Power circuitry may perform any formatting, converting, or other modification to the power from the power source QQ208 to make the power suitable for the respective components of the UE QQ200 to which power is supplied.

[0198] The memory QQ210 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory QQ210 includes one or more application programs QQ214, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data QQ216. The memory QQ210 may store, for use by the UE QQ200, any of a variety of various operating systems or combinations of operating systems.

[0199] The processing circuitry QQ202 may be configured to communicate with an access network or other network using the communication interface QQ212. The communication interface QQ212 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna QQ222. The communication interface QQ212 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a P111907W001 transmitter QQ218 and / or a receiver QQ220 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter QQ218 and receiver QQ220 may be coupled to one or more antennas (e.g., antenna QQ222) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0200] In the illustrated embodiment, communication functions of the communication interface QQ212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof.

[0201] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0202] A UE, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an loT device comprises circuitry and / or software in dependence of the P111907W001 intended application of the loT device in addition to other components as described in relation to the UE QQ200 shown in Figure 10.

[0203] As yet another specific example, in an loT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another UE and / or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0204] Figure 11 shows a network node QQ300, which may be an embodiment of the network node 110 of Figure 9, in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)).

[0205] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0206] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi -standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs). P111907W001

[0207] The network node QQ300 includes a processing circuitry QQ302, a memory QQ304, a communication interface QQ306, and a power source QQ308. The network node QQ300 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node QQ300 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeB s. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node QQ300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory QQ304 for different RATs) and some components may be reused (e.g., a same antenna QQ310 may be shared by different RATs). The network node QQ300 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node QQ300, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node QQ300.

[0208] The processing circuitry QQ302 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node QQ300 components, such as the memory QQ304, to provide network node QQ300 functionality.

[0209] In some embodiments, the processing circuitry QQ302 includes a system on a chip (SOC). In some embodiments, the processing circuitry QQ302 includes one or more of radio frequency (RF) transceiver circuitry QQ312 and baseband processing circuitry QQ314. In some embodiments, the radio frequency (RF) transceiver circuitry QQ312 and the baseband processing circuitry QQ314 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry QQ312 and baseband processing circuitry QQ314 may be on the same chip or set of chips, boards, or units. P111907W001

[0210] The memory QQ304 may comprise any form of volatile or non-volatile computer- readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computerexecutable memory devices that store information, data, and / or instructions that may be used by the processing circuitry QQ302. The memory QQ304 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry QQ302 and utilized by the network node QQ300. The memory QQ304 may be used to store any calculations made by the processing circuitry QQ302 and / or any data received via the communication interface QQ306. In some embodiments, the processing circuitry QQ302 and memory QQ304 is integrated.

[0211] The communication interface QQ306 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, the communication interface QQ306 comprises port(s) / terminal(s) QQ316 to send and receive data, for example to and from a network over a wired connection. The communication interface QQ306 also includes radio front-end circuitry QQ318 that may be coupled to, or in certain embodiments a part of, the antenna QQ310. Radio front-end circuitry QQ318 comprises filters QQ320 and amplifiers QQ322. The radio front-end circuitry QQ318 may be connected to an antenna QQ310 and processing circuitry QQ302. The radio front-end circuitry may be configured to condition signals communicated between antenna QQ310 and processing circuitry QQ302. The radio front-end circuitry QQ318 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry QQ318 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters QQ320 and / or amplifiers QQ322. The radio signal may then be transmitted via the antenna QQ310. Similarly, when receiving data, the antenna QQ310 may collect radio signals which are then converted into digital data by the radio front-end circuitry QQ318. The digital data may be passed to the processing circuitry QQ302. In other embodiments, the communication interface may comprise different components and / or different combinations of components. P111907W001

[0212] In certain alternative embodiments, the network node QQ300 does not include separate radio front-end circuitry QQ318, instead, the processing circuitry QQ302 includes radio front-end circuitry and is connected to the antenna QQ310. Similarly, in some embodiments, all or some of the RF transceiver circuitry QQ312 is part of the communication interface QQ306. In still other embodiments, the communication interface QQ306 includes one or more ports or terminals QQ316, the radio front-end circuitry QQ318, and the RF transceiver circuitry QQ312, as part of a radio unit (not shown), and the communication interface QQ306 communicates with the baseband processing circuitry QQ314, which is part of a digital unit (not shown).

[0213] The antenna QQ310 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna QQ310 may be coupled to the radio front-end circuitry QQ318 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna QQ310 is separate from the network node QQ300 and connectable to the network node QQ300 through an interface or port.

[0214] The antenna QQ310, communication interface QQ306, and / or the processing circuitry QQ302 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna QQ310, the communication interface QQ306, and / or the processing circuitry QQ302 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0215] The power source QQ308 provides power to the various components of network node QQ300 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source QQ308 may further comprise, or be coupled to, power management circuitry to supply the components of the network node QQ300 with power for performing the functionality described herein. For example, the network node QQ300 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source QQ308. As a further example, the power source QQ308 may comprise a source of power in the form of a P111907W001 battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0216] Embodiments of the network node QQ300 may include additional components beyond those shown in Figure 11 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node QQ300 may include user interface equipment to allow input of information into the network node QQ300 and to allow output of information from the network node QQ300. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node QQ300.

[0217] Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0218] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer- P111907W001 readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0219] EXAMPLE EMBODIMENTS

[0220] Group A Example Embodiments

[0221] 1. A method performed by a user equipment (UE) for SBFD, the method comprising at least one of: receiving, from a network node, a configuration for validating at least one RO based on at least one RO validation requirement; based on the configuration, determining the at least one RO validation requirement; and validating the at least one RO based on the RO validation requirement.

[0222] 2. The method of Example Embodiment 1, wherein the at least one RO comprises at least one SBFD RO, and wherein the method is for configuring and / or validating SBFD ROs in a network supporting SBFD operation.

[0223] 3. The method of any one of Example Embodiments 1 to 2, comprising at least one of: determining an SSB-to-RO mapping based on the configuration; based on the SSB-to-RO mapping, selecting a particular RO from the at least one validated RO; and transmitting a preamble at the particular RO selected from the at least one validated RO.

[0224] 4. The method of any one of Example Embodiments 1 to 3, wherein the configuration comprises a RACH configuration.

[0225] 5. The method of Example Embodiment 4, wherein the RACH configuration is received via SIB1 and / or RRC signaling.

[0226] 6. The method of any one of Example Embodiments 1 to 4, wherein the at least one validation requirement is determined to be at least one of:

[0227] ‘SBFD symbols only’; P111907W001

[0228] ‘SBFD and UL / F symbols overlapping’; and

[0229] ‘Non-SBFD symbols only’.

[0230] 7. The method of Example Embodiment 6, wherein determining the at least one RO validation requirement comprises determining a default RO validation requirement based on a lack of received signaling.

[0231] 8. The method of Example Embodiment 6, wherein receiving the configuration comprises receiving an optional RO configuration.

[0232] 9. The method of Example Embodiment 6, comprising: based on ‘SBFD symbols only’, determining that the RO is entirely comprised within SBFD symbols or SBFD DL symbols.

[0233] 10. The method of Example Embodiment 6, comprising: based on ‘SBFD and UL / F symbols’, determining that the RO is starting in SBFD symbols and ending in non-SBFD UL and / or flexible symbols.

[0234] 11. The method of Example Embodiment 6, comprising: based on ‘UL / F symbols only’, determining that the RO is entirely comprises within non-SBFD UL and / or flexible symbols.

[0235] 12. The method of any one of Example Embodiments 1 to 11, wherein the at least one RO validation requirement comprises the RO being entirely comprised within a non-SBFD UL and / or at least one flexible symbol.

[0236] 13. The method of any one of Example Embodiments 1 to 12, wherein at least one of: at least one frequency location is relative to a subband edge, and the method further comprises determining at least one frequency location relative to a subband edge.

[0237] 14. The method of any one of Example Embodiments 1 to 13, wherein the at least one RO validation requirement is that the at least one RO is located at least a distance from at least one edge of a subband.

[0238] 15. The method of Example Embodiment 14, wherein the at least one edge of the subband comprises one or more of: an UL subband edge, and a DL subband edge.

[0239] 16. The method of any one of Example Embodiments 14 to 15, wherein the distance is based on at least one of: a specification and / or the configuration.

[0240] 17. The method of any one of Example Embodiments 1 to 16, wherein validating the at least one RO based on the RO validation requirement comprises validating the at least one RO based on an RRC mode.

[0241] 18. The method of any one of Example Embodiments 1 to 17, wherein determining the at least one RO validation requirement comprises determining the at least one RO validation requirement based on whether the UE is in RRC CONNECTED, RRC IDLE, or RRC INACTIVE mode. P111907W001

[0242] 19. The method of Example Embodiment 18, wherein a rule for determining the at least one RO validation requirement based on whether the UE is in RRC CONNECTED, RRC IDLE, or RRC INACTIVE mode is determined on at least one of a specification and / or a PRACH configuration.

[0243] Group B Example Embodiments

[0244] 20. A method performed by a network node for SBFD, the method comprising at least one of: transmitting, to a UE, a configuration for determining, by the UE, at least one RO validation requirement for validating at least one RO.

[0245] 21. The method of Example Embodiment 20, wherein the at least one RO comprises at least one SBFD RO and a network supports SBFD operation.

[0246] 22. The method of any one of Example Embodiments 20 to 21, comprising configuring the UE to perform at least one of: determine an SSB-to-RO mapping based on the configuration; based on the SSB-to-RO mapping, select a particular RO from the at least one validated RO; and transmit a preamble at the particular RO selected from the at least one validated RO.

[0247] 23. The method of any one of Example Embodiments 20 to 22, wherein the configuration comprises a RACH configuration.

[0248] 24. The method of Example Embodiment 23, wherein the RACH configuration is transmitted via SIB1 and / or RRC signaling.

[0249] 25. The method of any one of Example Embodiments 20 to 24, wherein the configuration indicates at least one of: ‘SBFD symbols only’; ‘SBFD and UL / F symbols overlapping’; and ‘Non-SBFD symbols only’, and wherein the UE is configured to determine the at least one RO based on whether the configuration indicates ‘SBFD symbols only’; ‘SBFD and UL / F symbols overlapping’; and ‘Non-SBFD symbols only’.

[0250] 26. The method of Example Embodiment 25, comprising configuring the UE to determine a default RO validation requirement based on a lack of received signaling.

[0251] 27. The method of Example Embodiment 25, wherein transmitting the configuration comprises transmitting an optional RO configuration.

[0252] 28. The method of Example Embodiment 25, wherein the configuration indicates ‘SBFD symbols only’, and / or wherein the method comprises configuring the UE to determine, based on ‘SBFD symbols only’, that the RO is entirely comprised within SBFD symbols or SBFD DL symbols. P111907W001

[0253] 29. The method of Example Embodiment 28, wherein the configuration indicates ‘SBFD and UL / F symbols’, and / or wherein the method comprises configuring the UE to determine, based on ‘SBFD and UL / F symbols’, that the RO is starting in SBFD symbols and ending in non-SBFD UL and / or flexible symbols.

[0254] 30. The method of Example Embodiment 29, wherein the configuration indicates ‘ UL / F symbols only’, and / or wherein the method comprises configuring the UE to determine, based on ‘UL / F symbols only’, that the RO is entirely comprises within non-SBFD UL and / or flexible symbols.

[0255] 31. The method of any one of Example Embodiments 20 to 30, wherein the at least one RO validation requirement comprises the RO being entirely comprised within a non-SBFD UL and / or at least one flexible symbol.

[0256] 23. The method of any one of Example Embodiments 11 to 22, wherein at least one frequency location is relative to a subband edge.

[0257] 32. The method of any one of Example Embodiments 20 to 31, wherein the at least one RO validation requirement is that the at least one RO is located at least a distance from at least one edge of a subband.

[0258] 33. The method of Example Embodiment 32, wherein the at least one edge of the subband comprises one or more of: an UL subband edge, and a DL subband edge.

[0259] 34. The method of any one of Example Embodiments 32 to 33, wherein the distance is based on at least one of: a specification and / or the configuration.

[0260] 35. The method of any one of Example Embodiments 20 to 34, comprising configuring the UE to validate the at least one RO based on an RRC mode.

[0261] 36. The method of any one of Example Embodiments 20 to 35, comprising configuring the UE to determine the at least one RO validation requirement based on whether the UE is in RRC CONNECTED, RRC IDLE, or RRC INACTIVE mode.

[0262] 37. The method of Example Embodiment 36, wherein the configuration comprises a rule for determining the at least one RO validation requirement based on whether the UE is in RRC CONNECTED, RRC IDLE, or RRC INACTIVE mode is determined on at least one of a specification and / or a PRACH configuration.

[0263] Group C Example Embodiments

[0264] 38. A user equipment comprising processing circuitry configured to perform any of the steps of any of the Group A Example Embodiments.

[0265] 39. A user equipment configured to perform any of the steps of any of the Group A Example Embodiments. P111907W001

[0266] 40. A wireless device comprising processing circuitry configured to perform any of the steps of any of the Group A Example Embodiments.

[0267] 41. A network node comprising processing circuitry configured to perform any of the steps of any of the Group B Example Embodiments.

[0268] 42. A network node configured to perform any of the steps of any of the Group B Example Embodiments.

[0269] 43. A computer program comprising instructions which when executed on a computer perform any of the steps of any of the Group A and / or Group B Example Embodiments.

[0270] 44. A computer program product comprising computer program, the computer program comprising instructions which when executed on a computer perform any of the steps of any of the Group A and / or Group B Example Embodiments.

[0271] 45. A non-transitory computer readable medium storing instructions which when executed by a computer perform any of the steps of any of the Group A and / or Group B Example Embodiments.

Claims

P111907W001CLAIMS1. A method for random accessing implemented in a subband full duplex, SBFD, aware terminal device, comprising: receiving a random access channel, RACH, configuration, comprising configuration for SBFD random access; and validating a set of RACH occasions, ROs, which fulfills a RO validation requirement based on the received RACH configuration.

2. The method according to Claim 1, wherein the RO validation requirement relates to one or more of: a RO type to validate; relative location of a RO to a subband;RRC mode of the terminal device; and location of the terminal device.

3. The method according to Claim 2, wherein the RO type comprises uplink RO being comprised within uplink symbols only, and / or flexible symbols only.

4. The method according to Claims 2 or 3, wherein the RO type comprises SBFD RO which: comprises a SBFD symbol or an SBFD downlink symbol; and / or starts in an SBFD symbol / SBFD downlink symbol and ends in an uplink symbol or a flexible symbol.

5. The method according to Claim 3 or 4, wherein the validating a set of ROs fulfilling a RO validation requirement based on the received RACH configuration comprises: when the RO type that the terminal device is required to validate is UL RO, validating a set of UL ROs whose configured resource according to an UL RACH configuration satisfies an UL RO requirement; or37P111907W001 when the RO type that the terminal device is required to validate is SBFD RO, validating a set of SBFD ROs whose configured resource according to the RACH configuration satisfies an SBFD RO requirement.

6. The method according to any of preceding Claims, further comprising: receiving a Time Division Duplex, TDD, configuration based on which the terminal device validates the set of ROs, wherein the TDD configuration indicates TDD patterns comprising: uplink symbols, downlink symbols, flexible symbols, and / or SBFD symbols.

7. The method according to any of preceding Claims, further comprising: receiving an indication on the RO validation requirement, by a system information, MAC CE signaling or an RRC signaling.

8. The method according to any of preceding Claims, further comprising: determining SSB-to-RO mapping based on the configuration and the set of validated ROs; determining a RO among the set of validated ROs; and transmitting a preamble in the determined RO.

9. The method according to any of preceding Claims, further comprising: receiving a power configuration for SBFD ROs; and when the set of validated ROs is an SBFD RO set, conducting power control during a RACH procedure according to the power configuration for SBFD ROs.

10. A method for random accessing implemented in an SBFD-capable network node to be communicated with an SBFD-aware terminal device, comprising: transmitting, to the terminal device, a RACH configuration comprising configuration for SBFD random access; receiving, from the terminal device, a preamble in a valid RO determined on which the RACH configuration is based.

11. The method according to Claim 10, further comprising: transmitting, to the terminal device, an indication on a RO validation requirement, based on which the terminal device validate a set of ROs of a RO type.

12. The method according to Claim 11, wherein a RO type comprises:38P111907W001 an uplink RO; or an SBFD RO which: comprises a SBFD symbol or a SBFD downlink symbol; and / or starts in an SBFD symbol / SBFD downlink symbol and ends in an uplink symbol or a flexible symbol.

13. The method according to any of Claims 10 to 12, further comprising: transmitting a TDD configuration based on which the terminal device validates the set of ROs, wherein the TDD configuration indicates TDD patterns comprising: uplink symbols, downlink symbols, flexible symbols, and / or SBFD symbols.

14. The method according to any of Claims 10 to 13, further comprising: transmitting, to the terminal device, a power configuration for SBFD ROs to enable the terminal device to conduct power control during a RACH procedure.

15. A terminal device (QQ200) capable of SBFD functionality, being configured to perform a random access procedure, comprising: a processing circuitry (QQ202), and a memory (QQ210) including instructions which, when executed by the processing circuitry(QQ202), cause the terminal device(QQ200) to perform any of the method according to Claims 1 to 9.

16. A SBFD-capable network node (QQ300) configured for communicate with an SBFD- aware terminal device, comprising: a processing circuitry (QQ302), and a memory (QQ304) including instructions which, when executed by the processing circuitry (QQ302), cause the network node (QQ300) to perform any of the method according to Claims 10 to 14.

Images