Frame-based and payload-based equipment mode switching in unregulated new radios

Abstract

This invention provides a wireless device, such as a user equipment (UE) or other device, which, through configuration for both frame-based equipment (FBE) and load-based equipment (LBE) operating modes, can use a transparent operating mode in which the device is unaware of the operating mode of the base station (such as a gNB or other transmit and receive point (TRP)). The base station can initiate a channel occupancy time (COT), which is either an FBE COT or an LBE COT, in which the wireless device accordingly follows an FBE procedure or an LBE procedure. Various criteria can be applied to determine whether to use an FBE procedure or an LBE procedure, and whether to switch between them. The network can be used to indicate the intention to switch operating modes, and can do so via implicit or explicit indication. Similarly, the wireless device can autonomously switch operating modes and can indicate the selected mode to the network.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 910,677, filed on October 4, 2019, entitled “Frame Based Equipment and LoadBased Equipment Modes Switching in Unregulated New Radio,” the contents of which are incorporated herein by reference. Background Technology

[0003] Machine-to-machine (M2M), Internet of Things (IoT), and World Wide Internet of Things (WoT) network deployments may include vehicle-to-everything (V2X) communication, as described, for example, in the following: 3GPP TS 36.213, Physical layer procedures for control (Release 13), V13.9; 3GPP TS 36.213, Physical layer procedures for control (Release 14), V14.6; 3GPP TS 36.213, Physical layer procedures for control (Release 15), V15.1.0; 3GPP TR 38.889, Study on NR-based access to unlicensed spectrum (Release 15), V16.00; ETSI EN 301 893, 5GHz RLAN; Harmonised Standard Covering the Essential Requirement of Article 3.2 of Directive 2014 / 53 / EU, V2.1.1, May 2017; and 3GPP TS 38.211, Physical layer procedures for control (Release 15), V15.1.0 Summary of the Invention

[0004] By configuring for both Frame-Based Equipment (FBE) and Load-Based Equipment (LBE) operating modes, radio devices (such as User Equipment (UE) or other devices) can use a transparent operating mode in which the device is unaware of the operating mode of the base station (such as a gNB or other Transmit and Receive Point (TRP)). The base station can initiate a Channel Occupancy Time (COT), which can be either an FBE COT or an LBE COT, in which the radio device follows either the FBE procedure or the LBE procedure accordingly. Various criteria can be applied to determine whether to use the FBE procedure or the LBE procedure, and whether to switch between them.

[0005] The network can indicate its intention to switch operating modes, and can do so either implicitly or explicitly. Similarly, wireless devices can autonomously switch operating modes and can indicate the selected mode to the network.

[0006] This invention is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to addressing any or all of the shortcomings pointed out in any part of this disclosure. Attached Figure Description

[0007] A more detailed understanding can be obtained from the following description, which is given by way of example in conjunction with the accompanying drawings.

[0008] Figure 1 This is a timing diagram of an exemplary FBE timing mechanism.

[0009] Figure 2 This is an example call flow for broadcast FBE and LBE configurations in RMSI.

[0010] Figure 3 Here is an example timing diagram where CAIFB and CAILBE are transmitted to indicate the start of FBE / LBE COT.

[0011] Figure 4A This is a timing diagram of an exemplary FBE configuration for a UE, where it is assumed that FFP is equal to the radio frame period.

[0012] Figure 4B This is a timing diagram of an exemplary FBE configuration for a UE, where it is assumed that FFP is equal to half a frame period.

[0013] Figure 5 This is a timing diagram showing that exemplary COT sharing is enabled in the portion overlapping with the actual FBE COT obtained based on the FBE configuration at the gNB / TRP rather than the FBE configuration at the UE.

[0014] Figure 6This is an example timing diagram where the gNB / TRP acts as the LBE and the UE acts as the FBE, and COT sharing is only allowed if the gap between the DL (downlink) and the expected UL (uplink) is less than 25 μs.

[0015] Figure 7 Here is an example timing diagram where the LBE COT is shorter than the FBE COT.

[0016] Figure 8 Here is an example timing diagram showing a switch from FBE mode to LBE after three unsuccessful channel attempts.

[0017] Figure 9 This is a flowchart illustrating a counter-based example of switching from FBE to LBE.

[0018] Figure 10 This is a flowchart illustrating a timer-based example of switching from FBE to LBE.

[0019] Figure 11 This is a timing diagram of an exemplary process for switching from LBE to FBE.

[0020] Figure 12 This is a timing diagram of an example of switching from FBE to LBE immediately after the FBE COT ends.

[0021] Figure 13 This is a timing diagram of an example of switching from FBE to LBE, where LBE's LBT can start as FBE's CCA begins.

[0022] Figure 14 This is a timing diagram of an example of a switching indicator that carries a 1-bit field indicating the switching operation mode and the switching position.

[0023] Figure 15 This is an example call flow where the FBE UE acts as an LBE for channel access.

[0024] Figure 16A An exemplary communication system is shown, in which the methods and apparatus described and claimed herein are specifically embodied.

[0025] Figure 16B This is a block diagram of an exemplary device or apparatus configured for wireless communication.

[0026] Figure 16C This is a system diagram of an exemplary radio access network (RAN) and core network.

[0027] Figure 16D This is another exemplary system diagram of the RAN and core network.

[0028] Figure 16E This is another exemplary system diagram of the RAN and core network.

[0029] Figure 16F This is a block diagram of an exemplary computing system.

[0030] Figure 16G This is a block diagram of another exemplary communication system. Detailed Implementation

[0031] Many of the abbreviations used herein are described in Table 0 of the Appendix. As used herein, the term “process” generally refers to a method of performing operations to achieve a specific outcome. The term “process” is often used instead of “method” to avoid confusion with the specific meaning of the term “method” in the context of M2M and IoT applications. The steps described for a process are often optional and may be performed in multiple ways and in multiple sequences. Therefore, the term “process” as used herein should not be interpreted as referring to a hard set and sequence of steps, but rather as a general method for achieving a result that can be adapted in multiple ways.

[0032] Unlicensed spectrum in LTE

[0033] As specified in 3GPP TS 36.213, Physical layer procedures for control Release 13, V13.9 and Release 14, V14.6, Licensed Assisted Access (LAA) is aimed at carrier aggregation (CA) operation in which one or more low-power secondary cells (SCells) operate in unlicensed spectrum below 6 GHz.

[0034] Release 14 introduces several channel access procedures to be performed separately by the eNB and UE for both downlink (DL) and UL transmissions. The primary channel access procedures are described in Section 15 of TS 36.213, Release 14. See also 3GPP TS 36.213, Release 15, V15.1.0

[0035] Unlicensed spectrum in NR

[0036] In millimeter waves, a wide range of unlicensed spectrum exists, which can be further used to achieve higher data rates than those obtained by operating in sub-6 GHz bands. 3GPP TR 38.889, Study on NR-based access to unlicensed spectrum (Release 15), V16.00 discusses how the physical channels and processes in NR-U might need to be modified or introduced to address NR-U challenges, and takes into account characteristics of operating in millimeter waves, such as deploying narrow beams for transmission and reception in bands above 6 GHz, up to 52.6 GHz, or even higher. The study investigates processes to enhance the coexistence of NR-U with other technologies operating in unlicensed bands such as WiFi devices, LTE-based LAA devices, and other NR-U devices, while meeting regulatory requirements.

[0037] Frame-based Equipment (FBE)

[0038] Frame-based equipment (FBE) is an equipment in which the transmit / receive structure has a periodic timing that is equal to the fixed frame period (FFP). An "initiating" device is a device that initiates a series of one or more transmissions. Otherwise, the device is called a "responding device".

[0039] The device can implement a channel access mechanism using a fixed frame period (e.g., 1ms to 10ms), where transmission can only begin at the start of the fixed frame period, such as... Figure 1 As shown in the example. See ETSI EN 301 893, 5GHz RLAN; Harmonized Standard Covering the Essential Requirement of Article 3.2 of Directive 2014 / 53 / EU, V2.1.1, May 2017. For example, the initiating device cannot change the fixed frame period more than, for example, once every 200ms. The initiating device can perform an idle channel assessment (CCA) check during a single observation slot. If the initiating device finds the operating channel to be idle, it can immediately proceed with transmission. An observation slot can be used, which is a period during which the presence of other radio local area network (RLAN) transmissions on the operating channel is checked, and it will have a duration greater than, for example, 9μs.

[0040] If the operating channel is occupied, there will be no transmission on that channel during the next fixed frame period. The initiating device may have multiple transmissions during the channel occupancy period without performing additional CCA on that channel, provided that the interval between such transmissions does not exceed 16 μs. If the interval is >16 μs, the initiating device may continue transmitting, provided that no transmission is detected by the additional CCA. All intervals are counted as part of the channel occupancy period.

[0041] The channel occupied time (COT) should not exceed 95% of the fixed frame period, and there shall be an idle period before the start of the next fixed frame period, such that the idle period is at least 5% of the channel occupied time, with a minimum of 100 μs.

[0042] The initiating device is allowed to grant authorization to one or more associated responding devices to transmit on the currently operating channel during the current channel occupancy time.

[0043] If the interval between the transmission of the responding device and the last transmission performed by the initiating device that issued the authorization is less than 16 μs, the responding device can transmit without performing an idle channel assessment (CCA).

[0044] If the gap between the response device's transmission and the last transmission made by the initiating device that issued the authorization is greater than 16 μs, the response device must immediately perform CCA on the operational channel during a single observation slot within the 25 μs period before the granted transmission time, for example, CAT2 Listen Before Talk (LBT).

[0045] The responding device can perform transmissions on the currently operating channel for the remaining channel occupancy time of the current fixed frame period.

[0046] Load-based equipment (LBE)

[0047] Load-based equipment will implement a listen-before-talk (LBT) based channel mechanism to detect channel idleness. LBE is more proactive than FBE because it can attempt to access the channel whenever an expected transmission is expected, rather than being limited to a specific periodic frame structure as in FBE. See ETSI EN 301893, 5GHz RLAN; Harmonized Standard Covering the Essential Requirement of Article 3.2 of Directive 2014 / 53 / EU, V2.1.1, May 2017.

[0048] Exemplary challenge: Identification of FBE or LBE and FBE-LBE handover

[0049] Operation in FBE mode may outperform LBE mode in some situations, while the opposite is true in others. For example, under light to moderate traffic loads, FBE operation may be advantageous due to reduced channel access overhead. On the other hand, under high traffic loads, LBE operation may be advantageous due to better channel utilization. Therefore, we need to define a standard for gNB / TRP / UE to select / switch between FBE and LBE modes. We also need to develop a procedure for gNB / TRP / UE to switch between FBE and LBE modes. A procedure is needed to indicate the selected operating mode if both modes are to be used.

[0050] Transparent operation

[0051] In transparent operating mode, the UE does not need to know the gNB / TRP's LBE / FBE operating mode. The gNB / TRP can switch between FBE and LBE modes, or between different FBE configurations, without transmitting a "handover instruction" to the UE. A handover instruction is an instruction from the network guiding the UE to switch to a specific operating mode (such as LBE or FBE). Regardless of whether the UE operates as an FBE or an LBE, transparent operating mode allows the gNB / TRP to serve the UE. Therefore, the network can multiplex LBE and FBE UEs without the significant costs associated with configuring or indicating operating modes.

[0052] The UE can autonomously select its operating mode based on certain standards (such as its own capabilities, use cases, etc.). (Alternatively, in non-transparent operating mode, the gNB / TRP can indicate at specific times the operating mode and associated configuration that the UE should use.) In transparent mode, the gNB / TRP can switch between different operating modes / configurations without transmitting a handover instruction.

[0053] Regardless of whether the gNB / TRP selects the FBE or LBE operating mode, the gNB / TRP can multicast / broadcast all the configurations required for the UE to operate as an FBE or LBE without the gNB / TRP indicating the selected operating mode.

[0054] For example, different Channel Access Indicators (CAIs) can be used in different operating modes. Channel Access Indicators (CAIs) for FBE FBE This may differ from the Channel Access Indicator (CAI) used for LBE. LBE For example, the former could be a preamble, while the latter could be a Group Common Physical Downlink Control Channel (GC-PDCCH). Additionally, CAI... FBE and CAI LBEIt can carry different information. For example, CAI LBE It can carry information about the duration of COT, while CAI FBE A COT can indicate only that the channel is occupied without indicating the FBE status.

[0055] These configurations may also include information about FBE operation, such as FFP, FBE COT, and / or idle window. This information is broadcast / multicast to the UE operating as FBE and / or LBE. However, in transparent operation mode, no indication of which operation mode has been selected by the gNB / TRP is sent.

[0056] If the UE operates in LBE mode, it can use the LBE-related configuration and ignore the configuration related to FBE mode, and vice versa for FBE mode.

[0057] Higher-level messages (e.g., RRC IE) can be used to indicate the configuration required to act as an FBE UE or LBE UE, for example, FBE_configCommon RRC IE and LBE_configCommon RRC IE, respectively.

[0058] If CAI LBE If transmitted via downlink control information (DCI), then LBE_configCommon IE can contain information about CAI. LBE PDCCH provides information about the search space through higher-level parameters, such as the CAI-LBE-SearchSpaceId RRC parameter, which can be used to configure the search space for CAI. LBE The search space ID of the PDCCH. Furthermore, the CAI-LBE-ControlResourceSetId RRC parameter can be used, for example, to override the initial control resource set (CORESET) associated with CAI-LBE-SearchSpaceId, because CAI... LBE CORESET may differ from the initial CORESET associated with CAI-LBE-SearchSpaceId. For example, compared to the initial CORESET associated with CAI-LBE-SearchSpaceId, CAI... LBE CORESET can have a smaller bandwidth to enhance power savings. If CAI-LBE-ControlResourceSetId does not exist, the initial CORESET associated with CAI-LBE-SearchSpaceId is used. Monitor CAI LBE This could be beneficial for LBE UE, because CAI LBEIt can indicate whether the gNB / TRP has acquired the LBE COT. This allows the LBE UE to adjust its monitoring behavior for DL ​​transmissions, resulting in greater power savings by avoiding monitoring DL transmissions when the gNB / TRP has not acquired the LBE COT. Additionally, in broadband operation, CAI... LBE It can also indicate which subband (SB) within the active BWP is acquired by the gNB / TRP, allowing the LBEUE to adjust its receiver bandwidth to the SB actually acquired by the gNB / TRP.

[0059] On the other hand, FBE_configCommon can indicate the method used to receive CAI. FBE Configuration. If CAI FBE If it is a preamble and / or sequence and / or reference signal and / or signal and / or channel, then their configuration can be part of FBE_configCommon. For example, CAI FBE It can be a wideband demodulation reference signal (DMRS) associated with a specific CORESET, and its ID can be indicated by higher-level parameters (e.g., the CAI-FBE-ControlResourceSetId RRC parameter).

[0060] In addition, CAI FBE This can be a Channel State Information Reference Signal (CSI-RS) and / or a Synchronization Signal Block (SSB). Higher-layer parameters can then indicate the IDs of the CSI-RS and / or SSBs. For example, the RRC parameter csi-RS-CAI-FBE can be used to indicate the ID of an NZP-CSI-RS-Resource, which is configured to be periodic, with its periodicity aligned with the start of the FFP. Similarly, the RRC parameter SSB-CAI-FBE can be used to indicate the ID of an SSB, which can be periodic, with its periodicity aligned with the start of the FFP.

[0061] Additionally, other FBE parameters, such as FFP and / or COT and / or idle window, can be indicated by higher-layer signaling (e.g., RRC parameters such as FFP_duration, FFP_start / FFP_end, COT_duration, idle_window). The RRC parameter FFP_duration can be used to indicate the duration of a deployed fixed frame period. The RRC parameters FFP_start / FFP_end can be used to indicate the start / end of an FFP, and can be presented in granularity as slots and / or subframes and / or a specific offset from a particular SFN. For example, FFP_start / FFP_end can indicate the number of slots and offset in units of Orthogonal Frequency Division Multiplexing (OFDM) symbols at the start / end of the FFP. By knowing the FFP duration and its start / end, the UE will know how the FFP maps to NR radio frames. The RRC parameter COT_duration can be used to indicate the duration of the COT within each FFP, which should meet regulatory requirements, for example, less than or equal to 95% of the FFP duration. It can be expressed in OFDM symbol / slot granularity, and it can begin immediately after the start of each FFP. The RRC parameter Idle_window can be used to indicate the duration of the idle window, which should meet regulatory requirements, for example, greater than or equal to 5% of the FFP duration. It can be expressed in OFDM symbol / slot granularity, and it can begin immediately after the end of the COT. In addition, higher-level parameters (such as FFP_start and FFP_period) can be used, for example, to indicate the start of the FFP and its periodicity.

[0062] The aforementioned parameters can be used to provide information about the FFP of the gNB or the FFP of the UE. Specifically, the gNB and the UE may have their own FFP configurations, some of which are common to both. For example, the FFP of the gNB and the FFP of the UE may have a duration (period) of the FFP that can be indicated by FFP_duration, while there is a time offset (time migration) between the FFP of the gNB and the FFP of the UE that can be indicated by FFP_start / FFP_end. The time offset (time migration) may be between the start of the FFP of the gNB and the start of the FFP of the UE, or between the start of the FFP of the UE and a specific SFN, or between any reference point and a specific point of the FFP of the UE.

[0063] When a gNB / UE initiates a DL / UL transmission, the gNB / UE can use its own FFP configuration. In other words, if a UE initiates a UL transmission and intends to occupy the channel, the UE initiates COT based on its FFP configuration. When a gNB initiates COT, a similar process can be applied.

[0064] FBE_configCommon can contain RRC parameters such as FBE-configID. This can be beneficial because gNB / TRP can indicate multiple FBE configurations, each with its own FFP, COT duration, idle window, etc.

[0065] Receive FBE configuration and CAI in any FFP FBE In this case, the FBE UE can share the FBE COT acquired by the gNB / TRP for any initiated UL transmission (such as Random Access Channel (RACH), SR, or configured grant). If the gap between the last downlink / any other previous UL transmission and the expected new UL transmission is greater than a certain threshold (e.g., 16 μs), the FBE UE may not perform LBT or only perform CAT2 LBT. In LBE operating mode, if the gap is less than a certain threshold (e.g., 25 μs), then CAI... LBE COT sharing is allowed. If the gap is greater than this threshold, the LBE UE needs to initiate a new COT.

[0066] FBE configuration and LBE configuration can be broadcast by gNB / TRP as part of SSB and / or Residual Minimal System Information (RMSI) and / or other System Information (OSI). Figure 2 An example of using RMSI to provide FBE and LBE configurations (e.g., FBE_configCommon and LBE_configCommon) is shown. Specifically, the gNB / TRP acts as the FBE or LBE acquisition channel, which is transparent to the UE served by that gNB / TRP (step 1). Both the FBE UE and the LBE UE receive the configurations for the FBE and LBE operating modes (steps 2 and 3). The LBE UE can then use the configuration associated with the LBE operating mode and ignore the configuration associated with the FBE operating mode (step 3). Similarly, the FBE UE can use the configuration associated with the FBE operating mode and ignore the configuration associated with the LBE operating mode (step 4).

[0067] Alternatively, the FBE configuration and LBE configuration (e.g., FBE_configCommon and LBE_configCommon) can be multicast and scheduled by the GC-PDCCH. For this purpose, a new RNTI (FBE_LBE_RNTI) can be used to CRC scramble the GC-PDCCH. Multicasting the FBE and LBE configurations can update previously provided configurations. The configuration required to decode the GC-PDCCH can be indicated as part of the FBE configuration and / or LBE configuration (e.g., FBE_configCommon and / or LBE_configCommon). For example, the GC-PDCCH RNTI (e.g., FBE_LBE_RNTI) and / or its associated search space ID and / or coreset ID can be indicated in FBE_configCommon and / or LBE_configCommon via higher-level parameters (e.g., RRC parameters FBE_LBE_RNTI, ConfigUpdating_SearchSpaceId, and ConfigUpdating_CoresetID). If ConfigUpdating_CoresetID is not configured, the CORESET associated with ConfigUpdating_SearchSpaceId is used.

[0068] These configurations (e.g., FBE_config and LBE_config RRC IE) can signal notifications in a UE-specific manner. FBE_config and LBE_config can each have all the parameters from FBE_configCommon and LBE_configCommon, respectively. For example, a UE-specific PDCCH scrambled with C-RNTI (such as DCI format 1_0 and / or 1_1) can be used to schedule FBE_config and LBE_config.

[0069] The aforementioned signaling can indicate the FFP configuration of the gNB or the UE. For example, the RMSI can indicate the duration (period) of the gNB's FFP and the UE's FFP using RRC parameters (such as FFP_duration_gNB and FFP_duration_UE) or through dedicated RRC messages (one for the gNB's FFP and another for the UE's FFP, such as FBE_configCommon_gNB and FBE_configCommon_UE). The RRC configuration of the UE's FFP can be optional, and when it is not present, the UE can apply the same configuration as the gNB's FFP. For example, if the duration or period of the UE's FFP is not configured, the UE can assume that the duration of the UE's FFP is equal to the duration of the gNB's FFP.

[0070] Another method for transmitting the UE's FFP configuration and the gNB's FFP configuration is as follows: The gNB's FFP configuration can be broadcast, for example, in the RMSI. Alternatively, the UE's FFP configuration can be transmitted in a UE-specific RRC message. In this case, the UE can assume that the broadcast configuration is for the gNB's FFP, while the configuration transmitted in the UE-specific RRC is for the UE's FFP. The UE's FFP configuration not transmitted in the UE-specific RRC can be the same as the broadcast configuration of the gNB's FFP.

[0071] Some parameters between the UE's FFP and the gNB's FFP (such as time migration (time offset)) can be transmitted as part of the gNB's FFP configuration or as part of the UE's FFP configuration. If the time migration (time offset) does not exist, the UE can assume that the time migration (time offset) is equal to zero.

[0072] An example of LBE_configCommon IE is shown in the code example 1 in the appendix.

[0073] An example of FBE_configCommon IE is shown in Code Example 2 in the appendix.

[0074] gNB starts FBE COT

[0075] gNB / TRP can operate in FBE mode with a specific fixed frame period (FFP), where each period is divided into two or more parts for transmission during the following periods: channel occupancy time (COT); idle windows where no transmission occurs; and possible additional windows for additional channel sensing (such as second-stage channel sensing) if needed, which is used to support different channel access priorities for the FBE operating mode.

[0076] UE as LBE

[0077] The LBE UE expects to receive all the signals / channels required for LBE operation mode based on the provided configuration (e.g., LBE_configCommon).

[0078] Figure 3 The CAI transmitted at least at the beginning of the FBE COT is shown. FBE Example. The FBE UE is expected to receive the CAI indicating the start of FBECOT. FBE And not expect LBE UE decoding / detection CAI FBE In addition, CAI LBE It is transmitted and is expected to be decoded / detected by LBEUE to identify, for example, Figure 3 The start of LBE COT is shown, without expecting FBE UE decoding / detection CAI. LBE .

[0079] LBE-COT should be part of FBE-COT in both the frequency and time domains. Specifically, in the frequency domain, some sub-bands (SBs) can be used for the LBE UE, such as... Figure 3 As shown. In the time domain, LBE COT can overlap with FBE COT, but LBE COT should not start / end before / after FBE COT; for example, LBE COT should not overlap with an idle window. Both FBE UE and LBE UE can use the overlapping portion between FBE COT and FBE LBE.

[0080] For example, even if the time gap between the last transmission and the expected UL transmission is greater than a certain threshold (e.g., 25 μs), the LBE UE can share the acquired COT of the gNB, where only simplified channel sensing (such as CAT2 LBT) is performed. This may occur, for example, when the LBE UE knows that the LBE COT is part of the FBE COT.

[0081] For scheduled UL transmissions (e.g., PUSCH), the gNB / TRP can indicate the type of channel access procedure and the priority of the UL transmission in the DCI providing UL authorization, such as DCI 0_0-like or DCI 0_1-like. A new field can be used to indicate the channel access type, consisting of log2 (the number of channel access procedures). For example, if only two channel access procedure types are supported (e.g., CAT2 LBT and CAT4 LBT), a single field is sufficient to indicate the channel access type. Alternatively, another field can be used to indicate the channel access priority level, consisting of log2 (the number of channel access priority levels). The LBE UE should apply the indicated channel access type along with the indicated priority. If authorization within the COT obtained by the gNB is provided to the UE, UEs sharing the gNB's COT can perform only CAT2 sensing, even when the UE is acting as an LBE.

[0082] UE as FBE

[0083] For a UE acting as an FBE, it can be assumed that the configuration of the provided FBE operation mode is applied to the gNB's FFP or the UE's FFP. The configuration of the FBE operation mode includes CAI. FBE Configuration, FFP, COT duration, idle window, etc.

[0084] Furthermore, the gNB / TRP can provide various FBE configurations for different FBE UEs based on their capabilities, use cases, etc. For example, different UEs can have different FFP configurations, and the UE's FFP configuration may differ from the gNB's FFP. These configurations can be broadcast / multicast / unicast. UE capabilities can limit which configurations the UE can support, and the preferred configuration can be selected autonomously by the UE. Additionally, the gNB / TRP can indicate which configurations the FBE UE can use; this is considered a non-transparent operating mode because the gNB / TRP indicates the operating mode the UE should use, the process of implementing this operation will be described later. However, the gNB / TRP can later change the configuration so that it does not require transmitting instructions to the UE, thus making the operation transparent again.

[0085] Therefore, even if the FFP periods are different, the start of some FFPs in the UE's FBE configuration should be aligned. However, generally speaking, there may be a time shift (time offset) between the gNB's FFP and the UE's FFP. Figure 4 shows an example of two FBE configurations used by two different UEs or by a UE and its serving gNB. These two UEs are unaware of which FBE configurations are used at the gNB / TRP. However, generally speaking, the UE is aware of the gNB's FFP configuration, and the gNB's FFP configuration can be signaled using one of the procedures described above. Figure 4A In this context, we assume that FFP is a radio frame, while... Figure 4B The assumption is that FFP is half a radio frame.

[0086] If, for example, in Figure 4A If gNB / TRP uses FBE configuration, then for example in Figure 4B FBE UE2 configured using FBE can assume that no DL / UL transmissions may occur during its idle window, even if gNB / TRP is based on Figure 4A The FBE configuration in the example successfully acquires the FBE COT containing its free window. In other words, in this example, there are no DL / UL transmissions in the UE's free window, regardless of who initiates the COT. Furthermore, no UL / DL transmissions may occur in the gNB's FFP's free window.

[0087] Alternatively, if there is no UL transmission within the UE's FFP free window, but the gNB initiates COT according to its FFP configuration, the gNB may transmit DL within the UE's free window. However, if the gNB shares the UE-initiated COT within the UE's FFP, the absence of DL transmission within the UE's FFP free window may occur. Similarly, when the UE initiates COT according to its FFP, the UE may transmit UL within the gNB's FFP free window. However, when the UE shares the COT with the gNB, the UE may not transmit UL transmission within the gNB's FFP free window.

[0088] If, for example, in Figure 4A If gNB / TRP uses FBE configuration and successfully obtains its FBE COT, then gNB / TRP can target FBE UE2 (whose COT is, for example, in...) Figure 4B Completely or partially contained in, for example, in Figure 4A Cross-COT scheduling is performed within the larger COT obtained from gNB / TRP. In this case, Figure 4B In this case, FBE UE2 can ignore monitoring CAI before the start of the second COT. FBE Because Figure 4A This is part of a larger COT that has been successfully acquired, and only DL / UL scheduled in the previous COT are received / transmitted. In this scenario, the UE can determine if a UL transmission occurs when the UE does not share a gNB-initiated COT via a COT initiated by the UE according to the UE's FFP. To inform the UE whether it needs to initiate its COT according to the UE's FFP or share a gNB-initiated COT according to the gNB's FFP, this can be achieved by transmitting an explicit indication to the extent that the UL is within a gNB-initiated COT according to the gNB's FFP. Such an indication can be transmitted as part of a DCI that provides UL authorization; for example, fields in the DCI may indicate whether the UE will share the gNB's COT or must initiate its own COT. Alternatively, the DCI may indicate the type of LBT the UE should perform.

[0089] If, for example, in Figure 4B gNB / TRP uses FBE configuration and successfully obtains its FBE COT (which is less than...) Figure 4A If the FBE COT is used for FBE UE1, this could lead to ambiguity for FBE UE1. The reason is that if the FBE COT is successfully acquired by the gNB / TRP, the FBE UE with that FBE COT could share it for UL transmissions utilizing at most CAT2 LBTs or even without any LBTs. Here, this will not happen because the gNB / TRP can only claim... Figure 4B FBE COT in the middle and not advocate Figure 4AFBE COT in.

[0090] Therefore, FBE COT sharing can be enabled or disabled. COT sharing can be disabled if the FBE configuration used by the UE differs from the FBE configuration used by the serving gNB / TRP for acquiring its channel.

[0091] If CAI FBE For GC-PDCCH or UE-specific PDCCH, a single-bit field can be used to indicate whether COT sharing is enabled or disabled. FBE The GC-PDCCH needs to be scrambled by a new RNTI (e.g., CAI_FBE_RNTI), while CAI FBE UE-specific PDCCHs can be scrambled using C-RNTI.

[0092] If CAI FBE For DMRS, DMRS sequences and / or patterns can be used to indicate whether COT sharing is enabled or disabled. For example, two DMRS sequences can be used to indicate that the gNB / TRP has successfully acquired the channel. One DMRS sequence indicates that COT sharing is enabled, while the other indicates that COT sharing is disabled. For example, higher-layer parameters can be used to indicate which DMRS scrambling code initialization is used to indicate whether COT sharing is enabled or disabled, such as the RRC parameters COT-sharingEnabled-DMRS-scramblingID and COT-sharingDisabled-DMRS-scramblingID. If it is a PDCCH, the same approach can be applied to CAI. FBE DMRS.

[0093] Similarly, if CAI FBE For CSI-RS, CSI-RS sequences and / or patterns can be used to indicate whether COT sharing is enabled or disabled. For example, two CSI-RS sequences can be used to indicate that the gNB / TRP has successfully acquired the channel. One CSI-RS sequence indicates that COT sharing is enabled, while the other indicates that COT sharing is disabled. For example, higher-layer parameters can be used to indicate which CSI-RS scrambling code is initialized to indicate whether COT sharing is enabled or disabled, such as, for example, the RRC parameters COT-sharingEnabled-CSI-RS-scramblingID and COT-sharingDisabled-CSI-RS-scramblingID.

[0094] Instead of enabling / disabling COT sharing, gNB / TRP may indicate which part of the claimed COT the FBE UE can share the COT. Figure 5 An exemplary gNB / TRP configured using FBE is shown, where FFP is set to half a radio frame, and the FBE UE operating in FFP is set to one radio frame. Therefore, the FBE COT perceived by the gNB / TRP is less than the FBE COT perceived by the UE. Note that in transparent operating mode, the FBE UE is unaware of the operating mode and its configuration at the gNB / TRP. Therefore, COT sharing is only allowed in the portion of the UE's FBE COT that overlaps with the gNB / TRP's FBE COT, such as... Figure 5 As shown in the example. On the other hand, if the UE knows the gNB's FFP configuration, the UE can share the COT initiated by the gNB according to the gNB's FFP configuration.

[0095] In some situations, a shared COT may not provide sufficient time for the intended DL / UL transmissions. Therefore, the gNB / UE may initiate their own COT instead of sharing a COT initiated separately by the UE / gNB. For example, if the UE initiates a COT according to its FFP and the gNB shares the UE-initiated COT, the gNB must terminate the DL transmission according to the UE's FFP configuration. Therefore, the gNB may initiate its own COT according to its FFP configuration. Effectively, both the UE and gNB occupy the channel, but each occupies the channel according to its own FFP configuration.

[0096] Higher-layer signaling can indicate in which section FBE COT sharing is enabled. For example, RRC parameters (such as COT-sharing) can be used to indicate the last symbol / slot / subframe index of the section in which FBE COT sharing is allowed. Alternatively, higher-layer parameters (such as COT-sharing) can indicate, for example, the length of the section from the start of COT, in units of symbols / slots / subframes.

[0097] CAI FBE This can indicate the index of the last symbol / slot / subframe after COT sharing was enabled in the FBE COT. Additionally, CAI... FBE It can indicate the length of the portion within which COT sharing is permitted, in units of symbols / slots / subframes.

[0098] If CAI FBEFor GC-PDCCH or UE-specific PDCCH, the new field can indicate the index of the last symbol / slot / subframe in a portion where COT sharing is enabled, or the duration of that portion. This new field can be specified by higher-layer signaling to a particular value among several configured values. For example, higher-layer signaling can configure different durations / indices for the last symbol / slot / subframe in a table (such as Table 1 in the appendix) where COT sharing is enabled. In this case, CAI- FBE The new field of PDCCH consists of 3 bits, serving as an example to indicate which configurations are used.

[0099] CAI FBE This can be used to indicate the authorized ID of the configuration that the FBE UE can use in the COT initiated by gNB / TRP. For example, if CAI FBE For GC-PDCCH or UE-specific PDCCH, it may have a bitmap field indicating which configured license IDs can be used in the COT initiated by the gNB. The size of the bitmap may be equal to the number of configured license IDs. The most significant bit may indicate the activation / deactivation of the license with the highest ID, and the second most significant bit may indicate the activation / deactivation of the license ID of the second highest configured ID. Alternatively, CAI FBE It can indicate the authorized resources on which any configuration can be transmitted—this can be in the form of a start symbol / microslot / slot in COT, and optionally an offset from the start. If no offset is provided, the UE uses the FFP boundary to determine the end of the resource (before the IDLE period of the FFP configuration).

[0100] CAI FBE It has a field that indicates an index to the license ID of a single configuration that can be used in a COT that can be started with gNB / TRP. The size of this field is equal to log2 (the number of license IDs in the configuration), and the code point is mapped to the license ID of the single configuration.

[0101] gNB starts LBE COT

[0102] The gNB / TRP can operate in LBE mode, where it can access the channel at any time if it senses that the channel is idle using an applicable Listen-Before-Talk (LBT) procedure. The channel can be occupied for a variable duration depending on the expected transmission and the LBT procedure performed.

[0103] UE as LBE

[0104] No special consideration is required, and the standard LBE procedure can be applied, since both gNB / TRP and UE act as LBEs.

[0105] UE as FBE

[0106] The FBE UE expects to receive all the signals / channels required for FBE operation mode based on the provided configuration (e.g., FBE_configCommon).

[0107] Because LBE is more flexible and can acquire a channel at any time after a successful LBT, one possibility is that, for example, gNB / TRP might attempt to acquire a channel before or at the start of the FFP of the FBE UE, such as... Figure 6 As shown. Additionally, LBE COT can be equal to the FBE UE's FFP. In this case, gNB / TRP can transmit CAI based on the provided FBE configuration. FBE .

[0108] In transparent operating mode, the FBE UE is unaware of the operating mode at the gNB / TRP. Therefore, the FBE UE can assume that COT sharing is allowed without LBT or only with CAT2 LBT, regardless of the time gap between the last DL transmission and the expected UL transmission, as long as both DL and UL fall within the same COT. However, this may not be applicable because the gNB / TRP acquires the channel as an LBE and only allows DL COT sharing for UL transmission with CAT2 LBT if the time gap between the last DL transmission and the expected UL transmission is less than a certain threshold (e.g., 25 μs for FR1).

[0109] Therefore, the FBE UE does not need to assume that COT sharing is always enabled. If both the gNB / TRP and its associated UE act as FBEs, the gNB / TRP can schedule UL transmissions without indicating the LBT type for UL transmissions. Here, the FBE UE can only share DL COTs if it receives an indication that COT sharing is enabled. For this purpose, the DCI providing UL authorization can indicate the LBT type before UL transmissions. For example, a new field in the DCI can be used to indicate the LBT type.

[0110] For example, Figure 6 An example is shown where, when the gap between the last downlink and the expected UL is less than 25 μs, the UE can share the COT of the gNB / TRP for UL transmission. However, if there is a gap such as... Figure 6 Other anticipated UL transmissions falling within the gNB / TRP COT, such as configured authorizations, may not be transmitted by the FBE UE if the gap between the last downlink and the anticipated UL is greater than 25 μs. Note that if the gNB / TRP acts as the FBE, the FBE UE may perform... Figure 6 Other UL transmissions within.

[0111] FBE UEs may not expect to receive UL transmissions requiring CAT4 LBT indication, as CAT4 LBT is not supported in FBE operation.

[0112] Additionally, when both the gNB / TRP and the UE act as FBEs with different configurations, a procedure can be used to indicate whether COT sharing is enabled / disabled when the gNB / TRP acts as an LBE and the UE acts as an FBE.

[0113] Because the duration of LBE COT varies depending on the type of LBT performed, LBE COT can be much smaller than FBECOT, for example, as Figure 7 As shown. If both gNB / TRP and UE act as FBE, then CAI is not required. FBE The COT duration is indicated because it should be known once the channel is acquired via gNB / TRP, and it is part of the FBE configuration. Therefore, CAI... FBE It can carry information about the duration of COT obtained from LBE gNB / TRP.

[0114] If the LBE COT is shorter than the FBE COT, then no UL transmission may occur after the LBE COT ends, for example, Figure 7 As shown. The reason is that any UL transmission after the end of LBE COT should be considered a UE-initiated transmission, but FBE UEs are not allowed to initiate COT outside of the FFP start point.

[0115] FBE-LBE switching process

[0116] The gNB / TRP or UE can use various standards to determine whether to use FBE operation mode or LBE operation mode, or whether to switch between different FBE configurations. For example, the UE / gNB can switch between one FFP configuration and another FFP configuration with different configurations (such as different FFP periodicity (duration)).

[0117] Switching based on counter / timer

[0118] If the gNB / TRP or UE acts as an FBE and attempts to access the channel for an extended period of time without success, or after too many channel access attempts, the gNB / TRP or UE may switch from FBE mode to LBE mode or from one FFP configuration to another.

[0119] Figure 8This illustrates an example where a gNB / TRP or UE, acting as an FBE, fails to access the channel during three consecutive FFPs. It then switches from the FBE to the LBE and performs LBT based on the expected transmission.

[0120] The number of consecutive unsuccessful channel access attempts that an FBE (such as gNB / TRP or UE) may subsequently attempt to switch to an LBE or from one FFP configuration to another can be predefined, for example, as specified by the standard.

[0121] For a COT initiated by an FBE UE, the number of consecutive unsuccessful channel access attempts that the FBE UE subsequently makes to switch to LBE mode or switch from one FFP configuration to another can be signaled via the higher-layer signaling number-of-FBE-failed-attempts RRC parameter.

[0122] The number of consecutive unsuccessful channel access attempts that an FBE (such as gNB / TRP or UE) may subsequently attempt to switch to an LBE or from one FFP configuration to another can depend on the expected transmissions. For example, this number can depend on the channel access priority level. This number can be predefined for each channel access priority level, for example, as shown in Table 2.

[0123] Table 2 shows an exemplary number of consecutive unsuccessful channel access attempts after which the gNB / TRP or UE can switch to the LBE or switch from one FFP configuration to another.

[0124] For a COT initiated by an FBE UE, the number of consecutive unsuccessful channel access attempts that subsequently allow the FBE UE to switch to LBE mode or from one FFP configuration to another can be signaled via higher-layer signaling for different channel access priority levels. For example, if there are four channel access priority levels, then number-of-FBE-failed-attempts can be set to {N1, N2, N3, N4}, where N... i This refers to the number of consecutive unsuccessful channel access attempts made by the FBE UE after the i-th channel access priority level, allowing it to switch to LBE mode or from one FFP configuration to another.

[0125] Alternatively, instead of indicating the number of consecutive unsuccessful channel access attempts for each channel access priority level that the FBE UE can switch to LBE mode afterward, higher-layer signaling can indicate this number for a single channel access priority level. The FBE UE can then derive this number for other channel access priority levels. For example, number-of-FBE-failed-attempts can be set to N. A specific offset can then be applied to derive this number for other channel access priority levels, for example, as shown in Table 3 of the Appendix. In Table 3, offset values ​​are used for different channel access priority levels to derive the number of consecutive unsuccessful channel access attempts that the FBE UE can switch to LBE afterward.

[0126] Figure 9 The flowchart illustrates an example of using a counter of unsuccessful channel access attempts to determine whether to switch from FBE operating mode to LBE operating mode or from one FFP configuration to another.

[0127] First, the FBE checks whether a transmission is required. If no transmission is required, the physical layer of the FBE should not take any action (No in step 01). If the FBE has a transmission requirement (Yes in step 01), the FBE attempts to access the channel according to the FBE operating mode (step 02).

[0128] Next, if the channel is declared idle (Yes in step 03), the gNB / TRP or UE may claim FBE COT and transmit the intended transmission (step 04). However, if the channel is declared unavailable (No in step 03), the gNB / TRP or UE increments the counter for unsuccessful channel access attempts by one (step 05).

[0129] If the count of channel access attempts is less than the predefined / indicated threshold (No in step 06), then the gNB / TRP or UE continues to act as FBE to attempt channel access according to the FBE operation mode (step 02).

[0130] If the count of channel access attempts is less than the predefined / indicated threshold (Yes in step 06), then the gNB / TRP or UE switches to LBE operating mode and attempts to access the channel according to the LBE operating mode (step 07).

[0131] If the channel is declared idle (Yes in step 08), the gNB / TRP or UE may claim the LBE COT and transmit the intended transmission (step 09). However, if the channel is declared unavailable (No in step 08), the gNB / TRP or UE attempts to re-access the channel as an LBE (step 07).

[0132] The threshold can be set to a negative value. This means that the device can use an LBE instead of acting as an FBE and then switch to an LBE to begin the channel access attempt.

[0133] Step 01 is not limited to the presence of a signal / data to be transmitted; it can also include the presence of any signal / data to be received. For example, the gNB / TRP may attempt to acquire a channel to receive RACH, enable configured licensed transmissions, allow cross-COT transmissions, etc. In other words, the gNB / TRP attempts to acquire a channel so that its UE can perform UL transmissions. Therefore, it may be beneficial to apply the same operating mode handover procedure in this case.

[0134] Other metrics related to the number of unsuccessful channel access attempts during the switch from FBE to LBE can be used. Such metrics can relax the requirement that unsuccessful channel access be continuous.

[0135] The average number of failed channel access attempts is one possible measure of whether a switch from FBE to LBE will occur if it exceeds a certain threshold. Specifically, failed channel access attempts do not have to be consecutive. If too many failed attempts occur, causing the average number of failed channel access attempts to exceed a certain threshold, then the gNB / TRP or UE may switch from FBE to LBE.

[0136] Averaging can occur for a predefined duration (e.g., as specified by a standard), in units such as seconds, milliseconds, time slots, subframes, radio frames, FFPs, etc. Alternatively, it can be indicated by higher-layer signaling such as the averaging-window-duration RRC parameter.

[0137] The average number of failed channel access attempts compared to a threshold can be predefined, and this threshold can vary for different channel access priority levels for the number of consecutive unsuccessful channel access attempts that can subsequently change the operating mode from FBE to LBE.

[0138] In addition, the threshold for comparing the average number of failed channel access attempts with this threshold can be indicated by higher-layer signaling for the number of consecutive unsuccessful channel access attempts that could subsequently change the operating mode from FBE to LBE.

[0139] When using the average number of failed channel access attempts instead of the number of unsuccessful channel access attempts, then... Figure 9 Step 05 in the original text is modified to update the average number of failed channel access attempts. Figure 9 The remaining steps in the flowchart remain unchanged.

[0140] Another possible metric is the probability of channel access failures, which can be compared to a threshold. If this probability exceeds a certain threshold, the FBE operating mode can be changed to LBE operating mode or switched from one FFP configuration to another. The threshold can be predefined, for example, specified according to a standard, and can depend on a channel access priority level for the number of consecutive unsuccessful channel access attempts after which the operating mode can be changed from FBE to LBE or switched from one FFP configuration to another.

[0141] In addition, the threshold for comparing the probability of channel access failure can be indicated by higher-layer signaling for the number of consecutive unsuccessful channel access attempts after which the operating mode can be changed from FBE to LBE or from one FFP configuration to another.

[0142] When using the probability of channel access failure instead of the number of unsuccessful channel access attempts, then... Figure 9 Step 05 in the original text is modified to update the probability of channel access failure. Figure 9 The remaining steps in the flowchart remain unchanged.

[0143] Furthermore, timer-based standards can be used to switch from FBE operating mode to LBE operating mode or from one FFP configuration to another. A timer can be triggered when a signal / data intended for transmission is present. If the timer exceeds a specific threshold, the gNB / TRP or UE can switch from FBE to LBE. The threshold against which the timer is compared can be predefined and can vary based on a channel access priority level, which determines the number of unsuccessful channel access attempts that allow the operating mode to change from FBE to LBE afterward. Additionally, the threshold can be indicated by higher-layer signaling.

[0144] Figure 10 A flowchart of timer-based FBE-LBE switching is shown. Figure 10 Most of the steps are similar to Figure 9 The corresponding steps are as follows. There are two main differences. The first difference is that the FBE-LBE handover timer is triggered when there is data / signal to be transmitted (step 02). The second difference is that before attempting to access the channel again, the gNB / TRP or UE can verify whether the FBE-LBE handover timer value is greater than a predefined / indicated threshold (step 06).

[0145] After a certain number of failed channel access attempts or after a certain number of unsuccessful channel access attempts, attempt to decode / detect unexpected CAI. FBE and / or CAI LBEThe gNB / TRP / UE forms a surrounding node. Based on the acquired information, the gNB / TRP / UE can decide whether to switch between FBE and LBE. For example, if too many unexpected CAI signals are received... LBE This could be an indication that gNB / TRP / UE needs to switch to LBE operating mode in order to compete with surrounding LBE nodes.

[0146] Measurement-based switching

[0147] Measurements can be used to determine whether to switch between FBE and LBE operating modes or from one FFP configuration to another. For example, measurements can be used to assess the intensity of interference / noise in the surrounding environment. Under light to moderate traffic loads, FBE operating mode may be superior to LBE operating mode, and in this case, the measured interference / noise intensity is expected to be low; the opposite is true for high traffic load scenarios.

[0148] The gNB / TRP can perform L1 and / or L3 measurements to estimate ambient interference / noise. Metrics such as Reference Signal Received Power (RSRP), Received Signal Strength Indication (RSSI), and Signal-to-Interference-plus-Noise Ratio (SINR) can be used for this purpose. These metrics are compared to specific thresholds to determine which operating mode should be selected. Such thresholds can be predefined, for example, specified by standards. For instance, if the measured SINR is greater than a certain threshold, the gNB / TRP can operate with FBE, and vice versa if the SINR is less than the threshold.

[0149] The threshold may depend on the expected transmission. For example, the threshold may depend on the channel access priority level. The higher the channel access priority level, the more likely it is to choose LBE operating mode instead of FBE operating mode.

[0150] The gNB / TRP associated with the UE can assist in deciding whether to switch between FBE and LBE or from one FFP configuration to another. For example, the gNB / TRP can configure periodic / semi-persistent / aperiodic measurement reports for its associated UE into feedback metrics such as RSRP, RSSI, SINR, etc. The gNB / TRP can then make a decision based on the worst, average, or best measurement value and compare it with a predefined threshold.

[0151] To reduce reporting overhead, the UE associated with the gNB / TRP can locally determine whether FBE or LBE is the preferred operating mode. A one-bit feedback to the serving gNB / TRP can then indicate whether to select FBE or LBE. Based on this feedback, the gNB / TRP can decide which operating mode should be selected. For example, the decision can be made based on a majority vote principle.

[0152] To this end, existing channel state information measurement frameworks support configuring connected UEs to measure RSRP and / or RSSI and / or SINR. Here, the UE can be configured with thresholds that should be used to determine whether LBE or FBE is preferred. For example, higher-layer signaling can be used to indicate the applied thresholds. For instance, if SSB and / or CSI-RS are used for measurement, the RRC parameters RSRP-thresholdSSB and / or RSRP-thresholdCSIRS can respectively indicate the RSRP threshold. If the measured RSRP is greater than the indicated threshold, the UE can assume that FBE operation is the preferred operating mode, and vice versa if the measured RSRP is less than the indicated threshold. Similarly, if measured via SSB and / or CSI-RS, the RRC parameters RSSI-thresholdSSB and / or RSSI-thresholdCSIRS and / or SINR-thresholdSSB and / or SINR-thresholdCSIRS can respectively indicate the thresholds used for RSSI and SINR.

[0153] These RRC parameters with configured thresholds can be transmitted as part of an RRC IE scheduled by a UE-specific DCI or GC-PDCCH.

[0154] The locally selected operating mode can be reported as part of the CSI report. A new reporting quantity for reportQuantity, for example, is the RRC parameter in CSI-ReportConfi IE, and can be referred to as FBE-LBE. If report 1 is selected, the FBE operating mode is chosen, and vice versa if report 0 is selected.

[0155] As another metric for determining the handover between FBE and LBE, the gNB / TRP can use the received ACK-NACK to determine whether to handover between FBE and LBE. If so, a number of NACKs are received at the gNB / TRP, which can be considered an indication of strong interference / noise in the environment surrounding the UE, and thus the LBE operating mode is preferred.

[0156] The number of NACKs can be compared to a specific threshold. If the number of NACKs collected within a specific time window exceeds this threshold, then LBE is the preferred operating mode. The value of the threshold can be predefined, for example, as specified by a standard.

[0157] The NACK threshold can vary depending on the transmission. For example, a high-priority transmission level may have a smaller NACK threshold than a low-priority transmission level. Therefore, if this is the case, the gNB / TRP can switch from FBE to LBE more quickly if many NACKs are received for a high-priority transmission level.

[0158] Switch from LBE to FBE

[0159] If an LBE (e.g., gNB / TRP / UE) is intended to switch to an FBE with a specific configuration, this switch can occur at the beginning of the first FFP based on the FBE configuration intended for communication. This is beneficial for maintaining FFP alignment in cases where other nodes intend to use the same FBE configuration.

[0160] Figure 11 An example of an LBE intended to switch from LBE operating mode to FBE operating mode is shown, where FFP is equal to one radio frame starting from subframe 0. In this example, the LBE node acquires the LBE COT for 10ms across the boundary of the next radio frame, as shown. Figure 11 As shown. Therefore, a node cannot begin operation as an FBE in this radio frame, and the node should wait for the next radio frame aligned with the start of the FFP. The gap between the last LBE COT and the potential FBE COT can be used to start another LBE COT, but not an FBE COT. Additionally, a gap should be reserved for CCA before the start of the FFP.

[0161] Switch from FBE to LBE

[0162] One possibility for switching from FBE to LBE operating mode is that the FBE must operate with the currently used FBE configuration for a duration equal to the minimum time required to maintain the same FFP as specified in the regulatory requirements. For example, the regulatory requirements might stipulate that the FFP cannot be changed more than once every 200ms. Therefore, for example, a node switching from FBE to LBE should use the current FBE configuration for at least 200ms.

[0163] Alternatively, FBE can be switched immediately after the current FBE COT ends. This is in Figure 12 For example, the LBT used in the LBE operating mode starts immediately after the final FBE COT.

[0164] As another possible solution, for example, the LBT for LBE operation can start with the start of the CCA of FBE, such as... Figure 13 As shown. In Figure 13 In the example, for the switch from FBE to LBE, the LBT of LBE can start with the start of the CCA of FBE.

[0165] Please note that the procedure described for switching between FBE and LBE can be applied to switching between a specific FFP configuration and another FFP configuration. Additional constraints can be imposed, such as allowing switching between different FFP configurations to occur after a certain period of time (e.g., 200ms) of using the old configuration. A minimum time for switching between different FFP configurations can be specified, either provided in the specification or signaled via higher-level signaling (e.g., RRC parameters).

[0166] Network control switching with explicit indication

[0167] The gNB / TRP can explicitly indicate the switching between FBE and LBE. This indication can carry the following information: it can be a 1-bit field indicating the switching, where setting it to zero means the network intends to switch to LBE mode, and setting it to one means the network intends to switch to FBE mode. Alternatively, switching this 1-bit field indicates that the network intends to switch from the current operating mode to a new operating mode. If this 1-bit field is not switched, the current operating mode remains valid.

[0168] Because this explicit indication can be repeated several times, it can carry information about when a handover can occur. Each handover indication can carry the relative duration between the last symbol with the indication and the first symbol from which the network switches its operating mode.

[0169] Figure 14 An example of network handover from FBE operating mode to LBE operating mode is shown. Furthermore, the handover indication is designed to be transmitted at multiple times. Each handover indication carries a 1-bit field to indicate the operating mode switch and the relative position from that indication to the point where the handover occurred. The same method can be used to switch from LBE to FBE.

[0170] In addition, the handover indication can carry the absolute location of the point where the handover is intended to occur, rather than the relative location, so that the UE can combine these handover indications when operating in a low SINR scenario.

[0171] The handover indication carries either the absolute or relative position of the point where the handover is intended to occur. If the UE receives the indication and successfully decodes / detects it, the UE does not need to continue searching for the handover indication.

[0172] The handover indicator can be a carrier passing through multiple channels. The SSB can carry a 1-bit field to indicate the operating mode switch. It can be the carrier PBCH payload, not in the MIB, to avoid affecting the MIB's soft combining.

[0173] The RMSI PDCCH and / or RMSI Physical Downlink Shared Channel (PDSCH) may carry this indication. For example, the RMSIPDCCH may carry a 1-bit field indicating whether the operating mode is intended to be switched, while the RMSI PDSCH may carry the location of the expected operating mode switch. The RMSI PDSCH may carry both a 1-bit field indicating the intention to switch the operating mode and the location of the expected switch, while the RMSI PDCCH does not contain this indication.

[0174] The GC-PDCCH or UE-specific PDCCH may carry both a 1-bit field indicating the intention to switch operating modes and the location of the expected switch.

[0175] If CAI FBE or CAI LBE If it is a PDCCH, then they may carry a 1-bit field indicating the intention to switch operating modes and / or the position of the expected switch.

[0176] For UEs in RRC idle / inactive state, a 1-bit field indicating the intention to switch operating modes may be carried by the paging DCI or wake-up signal (WUS). Upon receiving such an indication, a UE in RRC idle / inactive state is expected to switch to RRC connected state to obtain information about the expected handover location.

[0177] For UEs in an RRC idle / inactive state, they may not transition to full RRC connected mode. For example, once they begin the RACH procedure, they can obtain information about the expected location of the operating mode switch in Msg2. Therefore, the remaining steps of the RACH, such as Msg3 and Msg4, are unnecessary. For this purpose, some preamble can be reserved so that the gNB / TRP can distinguish whether the preamble transmission is for initial access or for obtaining information about the expected location of the operating mode switch.

[0178] A UE in an RRC idle / inactive state can use a 2-step RACH to obtain information about the location of the expected operating mode switch. The purpose of this 2-step RACH can be indicated in the preamble portion of the MsgA or in the PUSCH of the MsgA.

[0179] Implicit indication

[0180] Here, in addition to its initial purpose, the DL reference signal can also be used to indicate to the network that it intends to switch operating modes.

[0181] For example, if CAI FBE or CAI LBEFor example, for DL ​​RS, such as wideband DMRS / CSI-RS, the DMRS / CSI-RS sequence can indicate whether the gNB / TRP is intended to switch operating modes. For example, two DMRS / CSI-RS scrambling initialization sequences can be indicated to the UE via, for example, higher-layer signaling (such as RRC parameters Operation-switching-scramblingID and No-Operation-switching-scramblingID).

[0182] Additionally, if CAI FBE or CAI LBE If it is a PDCCH, then the PDCCH DMRS sequence can indicate whether the network intends to switch operating modes. For example, two DMRS scrambling initialization sequences can be indicated to the UE via, for example, higher-layer signaling (such as RRC parameters Operation-switching-scramblingID and No-Operation-switching-scramblingID).

[0183] In addition, if CAI FBE or CAI LBE For PDCCH, the CRC scrambling RNTI indicates whether the network intends to switch operating modes. A UE can be configured with two RNTIs: one indicating that it is not intended to switch operating modes, and the other indicating that it is. For example, higher-layer parameters can be used to indicate these RNTI values, such as the RRC parameters Operation-switching-RNTI and No-Operation-switching-RNTI.

[0184] For UEs in RRC idle / inactive state, the CRC scrambling code RNTI of paging DCI or WUS can be used to indicate whether the network intends to switch operating modes.

[0185] Additionally, for UEs in the RRC idle / inactive state, the DMRS sequence paging PDCCH or WUSPDCCH can indicate whether the network intends to switch operating modes.

[0186] Due to the limited capabilities of implicit indications, information about when the network intends to switch operating modes cannot be conveyed with limited complexity. The UE can receive implicit indications of operating mode switching.

[0187] For example, receiving an implicit indication can trigger the UE to monitor a PDCCH with a specific configuration to obtain information about when the network intends to switch operating modes.

[0188] Suppose that gNB / TRP provides multiple FBE configurations, and each FBE configuration is associated with a specific ID, such as the FBE-configID RRC parameter described earlier. In this case, more bits are needed to indicate the selected operating mode and its configuration. For this purpose, more allocated bits can be used to apply explicit or implicit indications. Table 4 in the appendix shows examples of 3-bit indications for indicating the selected operating mode. For example, code point "000" can be reserved to indicate the LBE operating mode, while the remaining code points are used to indicate which FBE configuration, FBE-configID, was selected.

[0189] UE autonomous handover

[0190] The gNB / TRP serving the UE can then indicate the operating mode chosen autonomously by the UE. For example, the UE can autonomously switch operating modes or from one FFP configuration to another for UE-initiated UL transmissions. For instance, if the UE fails to access the channel for an extended period of time to transmit, for example, RACH or configured authorization, it can switch from FBE to LBE. Therefore, the gNB / TRP should be aware of this switch, as it may, for example, affect processes related to COT sharing.

[0191] RACH transmission

[0192] The RACH preamble / RACH timing indicates the selected operating mode. For example, gNB / TRP can configure non-overlapping RACH preamble / RACH timing for FBE and LBE operating modes. Therefore, when a UE transmits RACH, it should select the RACH preamble / RACH timing associated with the applied channel access procedure.

[0193] Additionally, in the 4-step RACH, Msg3 PUSCH can be used to indicate whether LBE or FBE operating mode has been selected. Furthermore, the DMRS sequence / type of Msg3 can be used to indicate the selected operating mode.

[0194] For a 2-step RACH, the selected operating mode can be indicated using the preamble of MsgA and the RACH timing. The PUSCH portion of MsgA can also indicate the selected operating mode. This can be achieved by explicitly carrying a 1-bit indicating the selected operating mode or by implicitly selecting the DMRS sequence / type of the PUSCH to transmit the selected operating mode.

[0195] In addition, in Msg3 of a 4-step RACH or in the PUSCH portion of MsgA of a 2-step RACH, the UE may transmit an onboard UCI that transmits a 1-bit field indicating the operating mode selected by the UE.

[0196] The FBE UE can perform initial access as an LBE to increase the opportunity to access the channel. Then, it can switch to the FBE after entering RRC connection mode and receiving RRC configuration.

[0197] Figure 15 An example is shown where the gNB / TRP can operate in FBE / LBE mode, which can be transparent to the FBE UE attempting initial access. Specifically, the gNB / TRP applies the channel access procedure (steps 1, 5, and 9) based on the FBE / LBE operating mode for SSB / RMSI transmission, Msg2 transmission, and Msg4 transmission (steps 2, 6, and 10), respectively. On the other hand, the UE can operate in LBE mode to access the channel (steps 3 and 7) for PRACH transmission and Msg3 transmission (steps 4 and 8), respectively, to increase the UE's chances of successfully accessing the channel. Once the UE is in RRC connection mode, it receives the FBE configuration and subsequently acts as the FBE for the next communication with the gNB / TRP.

[0198] Alternatively, the FBE UE can receive the FBE configuration before entering RRC connection mode, such as in Msg2. In this case, the UE should act as an LBE before receiving the FBE and then follow the provided FBE configuration.

[0199] The UE can instruct the serving gNB / TRP on how to obtain a channel.

[0200] Configured authorization

[0201] For UL transmissions configured in the COT initiated by the UE, the UE may transmit an embedded UCI, which transmits a 1-bit field indicating the operating mode selected by the UE.

[0202] Additionally, the PUSCH's UL DMRS can indicate the selected operating mode through two different sets of UL DMRS configurations (e.g., sequence and type), with each configuration associated with a specific operating mode. The UE should select the DMRS configuration associated with the selected operating mode.

[0203] In addition, different PUSCH scrambling codes RNTI can be used to indicate the selected operating mode.

[0204] Exemplary operating environment

[0205] The 3rd Generation Partnership Project (3GPP) has developed technical standards for cellular telecommunications network technologies, including radio access, core transport networks, and service capabilities (including operation on codecs, security, and quality of service). Recent Radio Access Technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), and LTE-Advanced. 3GPP has begun working on the standardization of next-generation cellular technologies, known as New Radio (NR), also referred to as "5G." The 3GPP NR standard development is expected to include the definition of next-generation radio access technologies (New RATs), which is expected to include new flexible radio access below 6 GHz and new ultra-mobile broadband radio access above 6 GHz. Flexible radio access is expected to consist of new non-backward-compatible radio access in the new spectrum below 6 GHz and is expected to include different operating modes that can be multiplexed in the same spectrum to address a wide range of 3GPP NR use cases with different requirements. Ultra-mobile broadband is expected to include centimeter-wave and millimeter-wave spectrum, which will provide opportunities for ultra-mobile broadband access for applications such as indoor spaces and hotspots. In particular, with specific design optimizations for centimeter and millimeter waves, ultra-mobile broadband is expected to share a common design framework with flexible radio access below 6 GHz.

[0206] 3GPP has identified a variety of use cases expected to be supported by NR, resulting in diverse user experience requirements regarding data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (e.g., broadband access in dense areas, ultra-high-bandwidth access indoors, broadband access in congested areas, 50+ Mbps everywhere, ultra-low-cost broadband access, mobile broadband in vehicles); critical communications; massive machine-type communications; network operations (e.g., network slicing, routing, migration and interworking, energy saving); and enhanced vehicle-to-everything (eV2X) communications, which may include any of vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-network (V2N), vehicle-to-pedestrian (V2P), and vehicle-to-other-entity communications. Specific services and applications within these categories include, to name just a few, monitoring and sensor networks, remote device control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first-responder connectivity, car ecalls, disaster alerts, real-time gaming, multi-user video calls, autonomous driving, augmented reality, haptic internet, and virtual reality. This article envisions all of these use cases and others.

[0207] Figure 16AAn embodiment of an exemplary communication system 100 is illustrated, in which the methods and apparatus described herein and protected by the claims may be specifically embodied. As shown, the exemplary communication system 100 may include: wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f and / or 102g (which may generally be referred to as or collectively referred to as WTRU 102); radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b; core networks 106 / 107 / 109; a public switched telephone network (PSTN) 108; the Internet 110; other networks 112; and a V2X server (or ProSe functionality and server) 113. However, it should be understood that any number of WTRUs, base stations, networks and / or network elements are contemplated in the disclosed embodiments. Each of WTRU 102a, 102b, 102c, 102d, 102e, 102f, and 102g can be any type of device or apparatus configured to operate and / or communicate in a wireless environment. While each of WTRU 102a, 102b, 102c, 102d, 102e, 102f, and 102g... Figures 16A to 16E While described as a handheld wireless communication device, it should be understood that each WTRU may include or be embodied as any type of device or apparatus configured to transmit and / or receive wireless signals in various use cases envisioned for 5G wireless communication, including by way of example only user equipment (UE), mobile station, fixed or mobile subscriber unit, pager, cellular phone, personal digital assistant (PDA), smartphone, laptop, tablet computer, netbook, notebook computer, personal computer, wireless sensor, consumer electronics, wearable devices (such as smartwatches or smart clothing), medical devices or electronic health devices, robots, industrial equipment, drones, vehicles (such as cars, trucks, trains or airplanes, etc.).

[0208] The communication system 100 may also include base stations 114a and 114b. Base station 114a can be any type of device and is configured to wirelessly interoperate with at least one of WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, and / or other networks 112. Base station 114b can be any type of device and is configured to wired and / or wirelessly interoperate with at least one of RRHs (Remote Radio Headers) 118a and 118b, TRPs (Transmit and Receive Points) 119a and 119b, and / or RSUs (Roadside Units) 120a and 120b to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, other networks 112, and / or a V2X server (or ProSe function and server) 113. RRH 118a and 118b can be any type of device, configured to wirelessly interoperate with at least one of WTRU 102c to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, Internet 110, and / or other networks 112. TRP 119a and 119b can be any type of device, configured to wirelessly interoperate with at least one of WTRU 102d to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, Internet 110, and / or other networks 112. RSU 120a and 120b can be any type of device, configured to wirelessly interoperate with at least one of WTRU 102e or 102f to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, Internet 110, other networks 112, and / or V2X server (or ProSe function and server) 113. By way of example, base stations 114a and 114b can be transceiver base stations (BTS), node B, eNode B, home node B, home eNode B, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b can include any number of interconnected base stations and / or network elements.

[0209] Base station 114a may be part of RAN 103 / 104 / 105, and may also include other base stations and / or network elements (not shown), such as a Base Station Controller (BSC), Radio Network Controller (RNC), relay nodes, etc. Base station 114b may be part of RAN 103b / 104b / 105b, and may also include other base stations and / or network elements (not shown), such as a Base Station Controller (BSC), Radio Network Controller (RNC), relay nodes, etc. Base station 114a may be configured to transmit and / or receive radio signals within a specific geographical area, which may be referred to as a cell (not shown). Base station 114b may be configured to transmit and / or receive wired and / or radio signals within a specific geographical area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, for example, one transceiver per sector of the cell. In one implementation, base station 114a may employ multiple-input multiple-output (MIMO) technology and thus may utilize multiple transceivers for each sector of the cell.

[0210] Base station 114a can communicate with one or more of WTRUs 102a, 102b, and 102c via air interfaces 115 / 116 / 117, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Any suitable radio access technology (RAT) can be used to establish air interfaces 115 / 116 / 117.

[0211] Base station 114b can communicate with one or more of RRH 118a, 118b, TRP 119a, 119b and / or RSU 120a and 120b via a wired interface or air interface 115b / 116b / 117b. This wired or air interface can be any suitable wired communication link (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 115b / 116b / 117b.

[0212] RRH 118a, 118b, TRP 119a, 119b and / or RSU 120a, 120b can communicate with one or more of WTRU 102c, 102d, 102e, 102f via air interface 115c / 116c / 117c, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 115c / 116c / 117c.

[0213] WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g can communicate with each other via air interface 115d / 116d / 117d (not shown in the figure), which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 115d / 116d / 117d.

[0214] More specifically, the communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base station 114a in RAN 103 / 104 / 105 and WTRU 102a, 102b, 102c, or RRH 118a, 118b, TRP 119a, 119b and RSU 120a, 120b in RAN 103b / 104b / 105b and WTRU 102c, 102d, 102e, 102f can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) and UTRA, which can establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

[0215] In one implementation, base station 114a can implement radio access technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA) with WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a, 120b with WTRUs 102c, 102d in RAN103b / 104b / 105b. Air interfaces 115 / 116 / 117 or 115c / 116c / 117c can be established using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A), respectively. In the future, air interfaces 115 / 116 / 117 can implement 3GPP NR technology. LTE and LTE-A technologies include LTE D2D and V2X technologies and interfaces (such as sidelink communication). 3GPP NR technology includes NR V2X technologies and interfaces (such as sidelink communication).

[0216] In one implementation, base station 114a in RAN 103 / 104 / 105 and WTRU 102a, 102b, 102c, or RRH 118a, 118b, TRP 119a, 119b and / or RSU 120a, 120b and WTRU 102c, 102d, 102e, 102f in RAN 103b / 104b / 105b can implement radio technologies such as IEEE 802.16 (e.g., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSMEDGE (GERAN), etc.

[0217] Figure 16ABase station 114c can be, for example, a wireless router, home node B, home eNode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas such as commercial locations, homes, vehicles, and campuses. In one embodiment, base station 114c and WTRU 102e can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114c and WTRU 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, base station 114c and WTRU 102e can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish picocells or femtocells. Figure 16A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114c may not need to access Internet 110 via core network 106 / 107 / 109.

[0218] RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b can communicate with core network 106 / 107 / 109, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. For example, core network 106 / 107 / 109 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication.

[0219] Although not in Figure 16A As shown, but it should be understood that RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b and / or core network 106 / 107 / 109 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b. For example, in addition to being connected to RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b which can utilize E-UTRA radio technology, core network 106 / 107 / 109 can also communicate with another RAN (not shown) using GSM radio technology.

[0220] Core networks 106 / 107 / 109 may also serve as gateways for WTRUs 102a, 102b, 102c, 102d, and 102e to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another core network connected to one or more RANs, which may use the same RAT as or a different RAT than RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b.

[0221] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multi-mode capabilities (e.g., WTRUs 102a, 102b, 102c, 102d, and 102e may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, Figure 16A The WTRU 102e shown can be configured to communicate with a base station 114a that can employ cellular-based radio technology and with a base station 114c that can employ IEEE 802 radio technology.

[0222] Figure 16B This is a block diagram of an exemplary apparatus or device (such as, for example, WTRU 102) configured for wireless communication according to the embodiments shown herein. Figure 16B As shown, the exemplary WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138. It should be understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the implementation. Additionally, the implementation envisions that base stations 114a and 114b and / or nodes that base stations 114a and 114b may represent (such as, but not limited to, transceiver stations (BTS), Node B, site controllers, access points (APs), home node B, evolved home node B (eNodeB), home evolved node B (HeNB), home evolved node B gateway, and proxy nodes, etc.) may include... Figure 16B The elements described herein, as well as some or all of the elements described herein.

[0223] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, which can be coupled to transmitting / receiving element 122. Although Figure 16B The processor 118 and transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0224] Transmitting / receiving element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 115 / 116 / 117. For example, in one embodiment, transmitting / receiving element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, transmitting / receiving element 122 may be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 may be configured to transmit and receive both RF and optical signals. It should be understood that transmitting / receiving element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0225] Furthermore, although the transmitting / receiving element 122 is in Figure 16B While depicted as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may employ MIMO technology. Thus, in one embodiment, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interfaces 115 / 116 / 117.

[0226] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. WTRU 102 may have multi-mode capability. Therefore, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate via various RATs (such as UTRA and IEEE 802.11).

[0227] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and can receive user input data therefrom. The processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad / indicator 128. Furthermore, the processor 118 can access information from any type of suitable memory (such as non-removable memory 130 and / or removable memory 132) and store data in any type of suitable memory. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a Subscriber Identity Module (SIM) card, a Memory Stick, a Secure Digital (SD) memory card, etc. In one implementation, the processor 118 may access memory information that is not physically located on the WTRU 102 (such as on a server or home computer (not shown)) and store the data in that memory.

[0228] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries, solar cells, fuel cells, etc.

[0229] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 115 / 116 / 117 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that, while remaining consistent with the implementation, the WTRU 102 may acquire location information using any suitable location determination method.

[0230] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral device 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), Universal Serial Bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, etc. Modules, FM radio units, digital music players, media players, video game player modules, internet browsers, etc.

[0231] WTRU 102 may be embodied in other devices or equipment, such as sensors, consumer electronics, wearable devices (such as smartwatches or smart clothing), medical devices or eHealth devices, robots, industrial equipment, drones, or vehicles (such as cars, trucks, trains, or airplanes). WTRU 102 may be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces, such as the interconnect interface of one of the peripheral devices in peripheral device 138.

[0232] Figure 16C This is a system diagram illustrating RAN 103 and core network 106 according to one implementation scheme. RAN 103 can communicate with WTRUs 102a, 102b, and 102c via air interface 115 using UTRA radio technology. RAN 103 can also communicate with core network 106. Figure 16C As shown, RAN 103 may include nodes B 140a, 140b, and 140c, each of which may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 115. Nodes B 140a, 140b, and 140c may each be associated with a specific cell (not shown) within RAN 103. RAN 103 may also include RNCs 142a and 142b. It should be understood that RAN 103 may include any number of nodes B and RNCs while remaining consistent with the implementation scheme.

[0233] like Figure 16C As shown, nodes B 140a and 140b can communicate with RNC 142a. Additionally, node B 140c can communicate with RNC 142b. Nodes B 140a, 140b, and 140c can communicate with their respective RNCs 142a and 142b via the Iub interface. RNCs 142a and 142b can communicate with each other via the Iur interface. Each of RNCs 142a and 142b can be configured to control the corresponding nodes B 140a, 140b, and 140c to which it is connected. Furthermore, each of RNCs 142a and 142b can be configured to implement or support other functions, such as outer-loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, and data encryption.

[0234] Figure 16CThe core network 106 shown may include a Media Gateway (MGW) 144, a Mobile Switching Center (MSC) 146, a Serving GPRS Support Node (SGSN) 148, and / or a Gateway GPRS Support Node (GGSN) 150. Although each of the foregoing elements is depicted as part of the core network 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0235] RNC 142a in RAN 103 can be connected to MSC 146 in core network 106 via IuCS interface. MSC 146 can be connected to MGW 144. MSC 146 and MGW 144 can provide WTRU 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRU 102a, 102b, and 102c and legacy landline communication equipment.

[0236] RNC 142a in RAN 103 can also be connected to SGSN 148 in core network 106 via IuPS interface. SGSN 148 can be connected to GGSN 150. SGSN 148 and GGSN 150 provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices.

[0237] The core network 106 can also be connected to network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0238] Figure 16D This is a system diagram of RAN 104 and core network 107 according to one implementation scheme. RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with core network 107.

[0239] RAN 104 may include evolved Nodes B 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of evolved Nodes B while remaining consistent with the implementation scheme. Evolved Nodes B 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, evolved Nodes B 160a, 160b, and 160c may implement MIMO technology. Therefore, evolved Node 160a may, for example, use multiple antennas to transmit and / or receive radio signals from WTRU 102a.

[0240] Each of evolved nodes 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, and user scheduling in the uplink and / or downlink, etc. Figure 16D As shown, evolution nodes 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0241] Figure 16D The core network 107 shown may include a mobility management gateway (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway 166. Although each of the foregoing elements is depicted as part of the core network 107, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0242] The MME 162 can connect to each of the evolved nodes 160a, 160b, and 160c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can also provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM or WCDMA.

[0243] Service Gateway 164 can connect to each of the evolved nodes 160a, 160b, and 160c in RAN 104 via the S1 interface. Service Gateway 164 typically routes and forwards user data packets to / from WTRUs 102a, 102b, and 102c. Service Gateway 164 may also perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering paging when downlink data is available to WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0244] Service gateway 164 can also be connected to PDN gateway 166, which provides WTRUs 102a, 102b, and 102c with access to packet-switched networks (such as the Internet 110) to facilitate communication between WTRUs 102a, 102b, and 102c and IP-enabled devices.

[0245] Core network 107 can facilitate communication with other networks. For example, core network 107 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, core network 107 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) or be able to communicate with such an IP gateway, serving as an interface between core network 107 and PSTN 108. Furthermore, core network 107 can provide WTRUs 102a, 102b, and 102c with access to network 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0246] Figure 16E This is a system diagram of RAN 105 and core network 109 according to one implementation scheme. RAN 105 can be an access service network (ASN) that uses IEEE 802.16 radio technology to communicate with WTRU102a, 102b, and 102c via air interface 117. The communication links between the different functional entities WTRU102a, 102b, 102c, RAN 105, and core network 109 can be defined as reference points.

[0247] like Figure 16E As shown, RAN 105 may include base stations 180a, 180b, 180c and ASN gateway 182; however, it should be understood that RAN 105 may include any number of base stations and ASN gateways while remaining consistent with the implementation scheme. Base stations 180a, 180b, and 180c may each be associated with a specific cell in RAN 105 and may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 117. In one implementation, base stations 180a, 180b, and 180c may implement MIMO technology. Therefore, base station 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. Base stations 180a, 180b, and 180c may also provide mobility management functions such as handover triggering, tunnel establishment, radio resource management, traffic classification, Quality of Service (QoS) policy enforcement, etc. The ASN gateway 182 can be used as a traffic aggregation point and can be responsible for paging, caching subscriber profiles, routing to the core network 109, etc.

[0248] The air interface 117 between WTRUs 102a, 102b, and 102c and RAN 105 can be defined as an R1 reference point implementing the IEEE 802.16 specification. Furthermore, each of WTRUs 102a, 102b, and 102c can establish a logical interface (not shown) with the core network 109. The logical interface between WTRUs 102a, 102b, and 102c and the core network 109 can be defined as an R2 reference point, which can be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0249] The communication link between each of base stations 180a, 180b, and 180c can be defined as an R8 reference point, which includes protocols for facilitating WTRU handover and data transfer between the base stations. The communication link between base stations 180a, 180b, and 180c and ASN gateway 182 can be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of WTRUs 102a, 102b, and 102c.

[0250] like Figure 16E As shown, RAN 105 can be connected to core network 109. The communication link between RAN 105 and core network 109 can be defined as an R3 reference point, which includes, for example, protocols for facilitating data transfer and mobility management capabilities. Core network 109 may include a Mobile IP Home Agent (MIP-HA) 184, an Authentication, Authorization, Accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements is depicted as part of core network 109, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0251] MIP-HA manages IP addresses and enables WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. MIP-HA 184 provides WTRUs 102a, 102b, and 102c with access to packet-switched networks (such as the Internet 110) to facilitate communication between WTRUs 102a, 102b, and 102c and IP-enabled devices. AAA Server 186 handles user authentication and supports user services. Gateway 188 facilitates interoperability with other networks. For example, Gateway 188 provides WTRUs 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and legacy terrestrial communication equipment. In addition, gateway 188 can provide WTRU 102a, 102b, 102c with access to network 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0252] although Figure 16E Although not shown, it should be understood that RAN 105 can connect to other ASNs, and core network 109 can connect to other core networks. The communication link between RAN 105 and other ASNs can be defined as an R4 reference point, which may include protocols for coordinating the mobility of WTRUs 102a, 102b, and 102c between RAN 105 and other ASNs. The communication link between core network 109 and other core networks can be defined as an R5 reference, which may include protocols for facilitating interoperability between home core networks and visited core networks.

[0253] The content described herein and in Figure 16A , Figure 16C , Figure 16D and Figure 16E The core network entities shown are identified by the names given to these entities in certain existing 3GPP specifications; however, it should be understood that these entities and functions may be identified by other names in the future, and some entities or functions may be combined in future specifications published by 3GPP (including future 3GPP NR specifications). Therefore, in Figure 16A , Figure 16B , Figure 16C , Figure 16D and Figure 16E The specific network entities and functions described and illustrated herein are provided by way of example only, and it should be understood that the subject matter disclosed herein and protected by the claims may be embodied or implemented in any similar communication system (whether currently defined or to be defined in the future).

[0254] Figure 16FThis is a block diagram of an exemplary computing system 90, which can be specifically illustrated Figure 16A , Figure 16C , Figure 16D and Figure 16E One or more devices in the communication network shown, such as certain nodes or functional entities in RAN103 / 104 / 105, core network 106 / 107 / 109, PSTN108, Internet 110, or other network 112. The computing system 90 may include a computer or server and may be primarily controlled by computer-readable instructions, which may be in the form of software and stored or accessed anywhere or by any means. Such computer-readable instructions may be executed within a processor 91 to cause the computing system 90 to perform operations. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable the computing system 90 to operate within the communication network. The coprocessor 81 is an optional processor, distinct from the main processor 91, which may perform additional functions or assist the processor 91. The processor 91 and / or the coprocessor 81 may receive, generate, and process data relating to the methods and apparatus disclosed herein.

[0255] In operation, processor 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computing system's main data transfer path, system bus 80. This system bus connects components within the computing system 90 and defines the medium for data exchange. System bus 80 typically includes: data lines for transmitting data; address lines for transmitting addresses; and control lines for transmitting interrupted data and for the operating system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[0256] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. This type of memory includes circuitry that allows for the storage and retrieval of information. ROM 93 typically contains stored data that is not easily modified. Data stored in RAM 82 can be read or modified by the processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by the memory controller 92. The memory controller 92 provides address translation functionality, converting virtual addresses to physical addresses when instructions are executed. The memory controller 92 also provides memory protection functionality that isolates processes within the system and separates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process's virtual address space; it cannot access memory in another process's virtual address space unless inter-process memory sharing has been configured.

[0257] In addition, the computing system 90 may include a peripheral device controller 83, which is responsible for transmitting instructions from the processor 91 to peripheral devices such as a printer 94, a keyboard 84, a mouse 95, and a disk drive 85.

[0258] A display 86, controlled by a display controller 96, is used to display visual output generated by a computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). The display 86 may be implemented using a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch panel. The display controller 96 includes the electronic components required to generate the video signals sent to the display 86.

[0259] Furthermore, the computing system 90 may include communication circuitry, such as, for example, a network adapter 97, which can be used to connect the computing system 90 to an external communication network, such as... Figure 16A , 16B The computing system 90 is equipped with RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, or other networks 112 of 16C, 16D, and 16E, enabling it to communicate with other nodes or functional entities in these networks. The communication circuitry may be used, alone or in combination with the processor 91, to perform the transmission and reception steps of certain means, nodes, or functional entities described herein.

[0260] Figure 16GAn embodiment of an exemplary communication system 111 is illustrated, which may specifically embody the methods and apparatus described herein and protected by the claims. As shown, the exemplary communication system 111 may include Wireless Transmit / Receive Units (WTRUs) A, B, C, D, E, F, a base station, a V2X server, and RSUs A and B; however, it should be understood that the disclosed embodiment contemplates any number of WTRUs, base stations, networks, and / or network elements. One or more or all WTRUs A, B, C, D, and E may extend beyond the network's reach (e.g., beyond the cell coverage boundary shown by dashed lines in the figure). WTRUs A, B, and C form a V2X group, with WTRU A as the group leader and WTRUs B and C as group members. WTRUs A, B, C, D, E, and F may communicate via a Uu interface or a sidelink (PC5) interface.

[0261] It should be understood that any or all of the apparatuses, systems, methods, and processes described herein may be embodied in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor (such as processor 118 or 91), causes the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any step, operation, or function described herein may be implemented in the form of such computer-executable instructions, which execute on a processor of an apparatus or computing system configured for wireless network communication and / or wired network communication. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical disc storage devices, magnetic cartridges, magnetic tapes, disk storage devices or other magnetic storage devices, or any other tangible or physical media that can be used to store desired information and is accessible by a computing system.

[0262] appendix

[0263] Table 0

[0264] abbreviation

[0265]

[0266]

[0267] Table 1

[0268] High-level signaling for FBE COT allows in it

[0269] The COT shared portion offers multiple configuration options.

[0270]

[0271] Table 2

[0272] After that, gNB / TRP or UE can switch to LBE.

[0273] Number of consecutive unsuccessful channel access attempts

[0274] Channel access priority level N 1 5 2 10 3 15 4 20

[0275] Table 3

[0276] Offset values ​​used for different channel access priority levels

[0277] To export the FBE UE that can be switched to LBE afterward.

[0278] Number of consecutive unsuccessful channel access attempts

[0279] Channel access priority level Offset value 1 N 2 N+10 3 N+15 4 N+20

[0280] Table 4 shows an example of a 3-digit indicator for specifying the selected operating mode.

[0281]

[0282]

[0283]

[0284]

Claims

1. A wireless transmit / receive unit (WTRU), the WTRU including a processor, the processor being configured to: Receive configuration information including frame-based equipment FBE configuration or load-based equipment LBE configuration; Determine if the timer has exceeded the threshold or if the WTRU has failed to access the channel for a period of time to transmit the Random Access Channel (RACH) message or the authorized access configured. Based on the determination that the timer has exceeded the threshold or based on the determination that the WTRU has failed to access the channel for a period of time to transmit the Random Access Channel (RACH) message or configuration authorization, it is determined to operate in the load-based equipment LBE operating mode instead of the FBE operating mode. and Operate in LBE operation mode according to the received LBE configuration.

2. The WTRU of claim 1, wherein operation in LBE mode is further determined based on one or more measurements, wherein the one or more measurements include one or more of the following: a reference signal received power (RSRP) measurement, a received signal strength indication (RSSI) measurement, or a signal-to-interference-plus-noise ratio (SINR) measurement.

3. The WTRU of claim 1, wherein the processor is further configured to send an indication to the base station, wherein, The instruction indicates that the operation is determined to be in LBE operation mode.

4. The WTRU of claim 1, wherein the processor is further configured to access the channel when operating in LBE operation mode, and wherein, The processor is further configured to send an indication of how the WTRU accesses the channel.

5. The WTRU of claim 1, wherein the processor is configured to operate in LBE operating mode, comprising: The processor is configured to access channels in unlicensed spectrum.

6. The WTRU of claim 1, wherein the processor is further configured to receive an indication from a base station, and wherein it is determined, based on the received indication, to operate in LBE operating mode.

7. The WTRU of claim 1, wherein the processor is configured to determine to operate in LBE operating mode instead of FBE operating mode, comprising: The processor is configured to switch from FBE operating mode to LBE operating mode.

8. The WTRU of claim 1, wherein operating in LBE mode is determined based on a counter-based determination, wherein, The counter-based determination includes: the processor being configured to switch from FBE operating mode to LBE operating mode based on the number of unsuccessful channel access attempts while operating in FBE operating mode.

9. The WTRU of claim 8, wherein the number of unsuccessful channel access attempts is the average number of failed channel access attempts, and wherein, The processor is configured to switch from FBE operating mode to LBE operating mode based on the average number of failed channel access attempts.

10. The WTRU of claim 1, wherein the processor is configured to switch from FBE operating mode to LBE operating mode.

11. The WTRU of claim 1, wherein the configuration information includes information for high priority levels and information for low priority levels, wherein, Further, based on information used for high priority levels, it is determined to operate in LBE mode.

12. The WTRU of claim 1, wherein the configuration information includes a probability threshold, wherein, The probability threshold indicates the probability of channel access failure, and the operation mode of LBE is determined based on the probability threshold.

13. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: Receive configuration information including frame-based equipment FBE configuration or load-based equipment LBE configuration; Determine if the timer has exceeded the threshold or if the WTRU has failed to access the channel for a period of time to transmit the Random Access Channel (RACH) message or the authorized access configured. Based on the determination that the timer has exceeded the threshold or based on the determination that the WTRU has failed to access the channel for a period of time to transmit the Random Access Channel (RACH) message or configuration authorization, it is determined to operate in the load-based equipment LBE operating mode instead of the FBE operating mode. and Operate in LBE operation mode according to the received LBE configuration.

14. The method of claim 13, wherein the determination of operation in LBE mode is further based on one or more measurements, wherein, The one or more measurements include one or more of the following: Reference Signal Received Power (RSRP) measurement, Received Signal Strength Indication (RSSI) measurement, or Signal-to-Interference-plus-Noise Ratio (SINR) measurement.

15. The method of claim 13, further comprising sending an indication to a base station, wherein, The instruction indicates that the operation is determined to be in LBE operation mode.

16. The method of claim 13, further comprising accessing a channel when operating in LBE operation mode, wherein, The method also includes sending an indication of how the WTRU should access the channel.

17. The method of claim 13, wherein operating in LBE mode includes accessing the channel in unlicensed spectrum.

18. The method of claim 13, further comprising receiving an indication from a base station, wherein it is determined, based on the received indication, to operate in LBE operation mode.

19. The method of claim 13, wherein determining to operate in LBE operating mode instead of FBE operating mode includes switching from FBE operating mode to LBE operating mode.

20. The method of claim 13, wherein the determination of operating in LBE mode is based on a counter-based determination, wherein, The counter-based determination includes switching from FBE operating mode to LBE operating mode based on the number of unsuccessful channel access attempts while operating in FBE operating mode.

21. The method of claim 20, wherein the number of unsuccessful channel access attempts is the average number of failed channel access attempts, and wherein, The method also includes switching from FBE operating mode to LBE operating mode based on the average number of failed channel access attempts.

22. The method of claim 13 further includes switching from FBE operating mode to LBE operating mode.

23. The method of claim 13, wherein the configuration information includes information for high priority levels and information for low priority levels, wherein, Further, based on information used for high priority levels, it is determined to operate in LBE mode.

24. The method of claim 13, wherein the configuration information includes a probability threshold, wherein, The probability threshold indicates the probability of channel access failure, and the operation mode of LBE is determined based on the probability threshold.

Images