Multi-trp power headroom reporting

Abstract

This disclosure relates to a method for implementing a Power Headroom Report (PHR) for multiple Transmit and Receive Points (TRPs) in a Wireless Transmit / Receive Unit (WTRU). The method includes transmitting capability information indicating that the WTRU is configured to support simultaneous multi-panel (SMP) transmission. The method further includes determining that a Power Headroom Report (PHR) has been triggered and receiving Downlink Control Information (DCI) including uplink grant information, the DCI indicating a multi-panel operating mode. The method further includes determining one or more pH values ​​of the PHR, wherein the one or more pH values ​​are determined at least based on the multi-panel operating mode indicated in the DCI and whether the PHR is triggered based on an SMP PL determination. The method also includes transmitting the PHR containing the one or more pH values.

Description

Technical Field

[0001] [Cross-reference to related applications]

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 228,882, filed August 3, 2021, and U.S. Provisional Patent Application No. 63 / 249,230, filed September 28, 2021, the contents of which are incorporated herein by reference in their entirety.

[0003] This disclosure generally relates to wireless communications. For example, methods and apparatus for power headroom reporting (PHR) at multiple transmit and receive points (TRPs) are disclosed. Prior Technology

[0004] Wireless communication systems are widely deployed to provide a variety of telecommunications services, such as telephone, video, data, messaging, and broadcasting. Representative wireless communication systems may employ multiple access technologies (MADs) that enable communication with multiple users by sharing available system resources (e.g., bandwidth, transmission power). Examples of such MADs include Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single Carrier Frequency Division Multiple Access (SC-FDMA), Time Division Synchronous Code Division Multiple Access (TD-SCDMA), and Long Term Evolution (LTE). LTE / LTE-Advanced is a set of enhancements to the Universal Mobile Telecommunications System (UMTS) mobile standard issued by the 3rd Generation Partnership Project (3GPP).

[0005] A wireless communication network may contain several base stations (BSs) capable of supporting communication for several user equipments (UEs). UEs can communicate with the BS via downlinks and uplinks. A downlink (or forward link) refers to the communication link from the BS to the UE, and an uplink (or reverse link) refers to the communication link from the UE to the BS. A BS may be referred to as a Node B, gNB, Access Point (AP), Radio Headend Equipment, Transmitter-Receiver Point (TRP), New Radio (NR) BS, 5G Node B, and / or similar.

[0006] Multiple access technology has been adopted in various telecommunications standards to provide a common protocol enabling different UEs to communicate at the city, country, region, and / or global levels. New Radio (NR), also known as 5G, is a set of enhancements to the LTE mobile standard issued by the 3rd Generation Partnership Project (3GPP). NR is designed to improve spectrum efficiency, reduce costs, improve service, utilize new spectrum, and improve integration with other open standards by using OFDM with a cyclic prefix (CP-OFDM) on the downlink (DL) and CP-OFDM and / or SC-FDM (e.g., also known as Discrete Fourier Transform Extended ODFM (DFT-s-OFDM)) on the uplink (UL), and supporting beamforming, multiple-input multiple-output (MIMO) antenna technology, and carrier aggregation for better mobile broadband internet access. However, as the demand for mobile broadband access continues to increase, improvements are needed on LTE and NR technologies. Summary of the Invention

[0007] The proposal outlines communication technologies and procedures for supporting PHR scheduling decisions for multi-panel operation. For example, PHR scheduling decisions for multi-panel operation can be achieved by providing multiple antenna panels to a Transmit / Receive Unit (WTRU) to deliver good signal quality to one or more TRPs regardless of UE orientation. In one embodiment, simultaneous multi-panel uplink transmissions can facilitate higher throughput and diversity without increasing latency. This operating mode allows the WTRU to schedule transmissions directed toward more than one TRP using more than one panel simultaneously. Furthermore, to assist the gNB in ​​scheduling decisions, the WTRU can, for example, send a Power Headroom Report (PHR).

[0008] In one embodiment, the WTRU may include a processor and memory. The processor and memory may be configured to implement any of the functionalities described herein as being performed or executed by the WTRU. The WTRU may send capability information instructing it to be configured to support simultaneous multi-panel (SMP) transmission. The WTRU may determine that a Power Headroom Report (PHR) has been triggered and may receive Downlink Control Information (DCI) including uplink grant information indicating a multi-panel operating mode. The WTRU may also determine one or more pH values ​​of the PHR. The determination of one or more pH values ​​may be based at least on the multi-panel operating mode indicated in the DCI and whether the PHR is triggered based on an SMP PL determination. The WTRU may further send the PHR containing the one or more pH values. Simple Explanation of the Diagram

[0009] A more detailed understanding is provided by way of examples in conjunction with the accompanying drawings, which are given in the following embodiments. As with the embodiments, the figures in such figures are illustrative. Thus, the figures and embodiments are not to be considered limiting, and other equally valid examples are feasible and possible. Furthermore, similar element symbols ("ref.") in the figures ("FIG.") indicate similar elements, and wherein: [Figure 1A] is a system diagram illustrating one or more example communication systems that can be implemented therein, according to the disclosed embodiments; [Figure 1B] is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that can be used in the communication system illustrated in Figure 1A according to an embodiment; [Figure 1C] is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that can be used in the communication system illustrated in Figure 1A according to an embodiment; [Figure 1D] is a system diagram illustrating further examples RAN and CN that can be used in the communication system illustrated in Figure 1A according to an embodiment; [Figure 2] is a diagram illustrating an example of a single downlink control information (DCI) multiple transmit receive point (Multi-TRP) entity uplink shared channel (PUSCH) being repeated; [Figure 3] is a diagram illustrating an example of power headroom report (PHR) triggered using two reference signal (RS) groups; [Figure 4] is a diagram illustrating an instance of transmission to multiple TRPs and multiple cells; and [Figure 5] is a diagram illustrating an example of the reception of a control signal, which includes a mapping configuration indicating that a first service request indicator (SRI) and a second SRI are mapped to a first repeat and a second repeat, respectively. Implementation

[0010] In the following embodiments, numerous specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it should be understood that such embodiments and examples may be practiced without using some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may replace or be incorporated into the embodiments and other exemplary practices described, disclosed, or otherwise expressly, implicitly, and / or inherently provided herein (collectively, the “provided”).

[0011] Figure 1A illustrates one or more example communication systems 100 that can be implemented according to the disclosed embodiments. Communication system 100 may be a multiple access system that provides content (such as voice, data, video, communications, broadcasts, etc.) to multiple wireless users. Communication system 100 enables multiple wireless users to access such content through the sharing of system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform Spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtering OFDM, filter bank multicarrier (FBMC), and similar methods.

[0012] As shown in Figure 1A, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, an internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be configured to operate and / or communicate in a wireless environment of any type. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a station (STA)) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile radios, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, laptops, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, and the like. Any of WTRU 102a, 102b, 102c, and 102d may be referred to as UE interchangeably.

[0013] The communication system 100 may also include base stations 114a and / or 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), NodeBs, eNodeBs (eNBs), local NodeBs, local eNodeBs, next-generation NodeBs (such as gNodeBs (gNBs), new radio (NR) NodeBs), station controllers, access points (APs), wireless routers, and the like. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0014] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, and the like. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, and these base stations may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a specific geographic area that may be relatively fixed or may vary over time. 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, i.e., one transceiver for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology, and multiple transceivers may be used for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0015] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via an air interface 116. This air interface can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 can be established using any suitable radio access technology (RAT).

[0016] More specifically, as mentioned above, communication system 100 may be a multiple access system and may employ one or more access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and similar schemes. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 may implement radio technologies, such as using wideband CDMA (WCDMA) to establish Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA) on air interface 116. 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).

[0017] In one embodiment, base stations 114a and WTRUs 102a, 102b, 102c may implement radio technologies, such as Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro), to establish Evolved UMTS Terrestrial Radio Access (E-UTRA) on the air interface 116.

[0018] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement radio technology, such as using NR to establish NR radio access to space interface 116.

[0019] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c may implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or transmissions to / from various types of base stations (e.g., eNBs and gNBs).

[0020] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity, WiFi), IEEE 802.16 (i.e., Global Interoperability Microwave Access (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), GSM Evolution Enhanced Data Rate (EDGE), GSM EDGE (GERAN), and the like.

[0021] Base station 114b in Figure 1A can be a wireless router, local node B, local eNode-B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas such as business premises, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, and the like. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown in FIG1A, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106.

[0022] RAN 104 can communicate with CN 106, 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. Data can have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. CN 106 can provide call control, billing services, location-based services, prepaid telephone, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs using the same RAT as RAN 104 or using a different RAT. For example, in addition to connecting to RAN 104 (which can utilize NR radio technology), CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0023] CN 106 may also function as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing plain old 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 protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 or a different RAT.

[0024] 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, and 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a, which may employ cellular-based radio technology, and with base station 114b, which may employ IEEE 802 radio technology.

[0025] Figure 1B is a system diagram illustrating example WTRU 102. As shown in Figure 1B, WTRU 102 may include, in particular, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 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, etc. It will be understood that WTRU 102 may include any combination of the above-mentioned elements while remaining consistent with one embodiment.

[0026] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of 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), any other type of integrated circuit (IC), a state machine, and the like. Processor 118 may perform signal encoding / decoding, data processing, power control, input / output processing, and / or any other functionality that enables WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, which may be coupled to transmitting / receiving element 122. Although Figure 1B depicts processor 118 and transceiver 120 as separate components, it will be understood that processor 118 and transceiver 120 may be integrated together in an electronic package or on a chip.

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

[0028] Although the transmit / receive element 122 is depicted as a single element in FIG1B, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals through the air interface 116.

[0029] Transceiver 120 can be configured to modulate signals to be transmitted via transmit / receive element 122 and demodulate signals received via transmit / receive element 122. As mentioned above, WTRU 102 may have multi-mode capability. Therefore, for example, transceiver 120 may include multiple transceivers for enabling WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).

[0030] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from them. The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Additionally, 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, and the like. In other embodiments, processor 118 may access information from memory not physically located on WTRU 102 (such as on a server or home computer (not shown)) and store data in that memory.

[0031] 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 battery packs (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0032] 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) regarding the current location of the WTRU 102. In addition to (or alternatively) information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116, and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may obtain location information using any suitable location determination method while remaining consistent with one embodiment.

[0033] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functionality, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), universal serial bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, frequency modulated (FM) radio units, digital music players, media players, video game console modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, and the like. Peripheral devices 138 may include one or more sensors. The sensor may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor; geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, humidity sensor, and the like.

[0034] WTRU 102 may include some or all of the signals (e.g., associated with a specific subframe for both UL (e.g., for transmission) and DL (e.g., for reception)) for which transmission and reception may be parallel and / or simultaneous full-duplex radio. The full-duplex radio may include an interference management unit to reduce and / or substantially eliminate self-interference via either hardware (e.g., a choke) or via signal processing (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU 102 may include some or all of the signals (e.g., associated with a specific subframe for either UL (e.g., for transmission) or DL ​​(e.g., for reception) for which transmission and reception may be half-duplex radio.

[0035] Figure 1C is a system diagram illustrating RAN 104 and CN 106 according to one embodiment. As mentioned above, RAN 104 can use E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with CN 106.

[0036] RAN 104 may include eNode-Bs 160a, 160b, and 160c, although it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with one embodiment. Each of eNode-Bs 160a, 160b, and 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, eNode-B 160a, for example, may use multiple antennas to transmit radio signals to and / or receive radio signals from the WTRU 102a.

[0037] Each of the eNode-B 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, user scheduling in UL and / or DL, and the like. As shown in Figure 1C, the eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0038] The CN 106 shown in Figure 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. Although the above elements are depicted as components of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0039] The MME 162 can connect to each of the eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can function as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, enabling / disabling bearers, and selecting specific service gateways during the initial attachment of WTRUs 102a, 102b, 102c, and similar devices. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0040] The SGW 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can generally route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can also perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering calls when DL data is available to WTRUs 102a, 102b, and 102c, managing and storing background information for WTRUs 102a, 102b, and 102c, and similar functions.

[0041] SGW 164 can be connected to PGW 166, which provides access to packet switching networks (such as Internet 110) to WTRU 102a, 102b, 102c to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0042] CN 106 can facilitate communication with other networks. For example, CN 106 can provide access to circuit-switched networks (such as PSTN 108) to WTRUs 102a, 102b, and 102c to facilitate communication between WTRUs 102a, 102b, and 102c and conventional terrestrial line communication devices. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) or be able to communicate with such IP gateway, which acts as an interface between CN 106 and PSTN 108. Additionally, CN 106 can provide access to other networks 112 to WTRUs 102a, 102b, and 102c, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0043] Although the WTRU is described as a wireless terminal in Figures 1A to 1D, it is envisioned that in some representative embodiments, this terminal may be used with a communication network (e.g., temporarily or permanently) with a wired communication interface.

[0044] In a representative embodiment, other network 112 may be a WLAN.

[0045] In Basic Service Set (BSS) mode, a WLAN may have access points (APs) for the BSS and one or more stations (STAs) associated with the APs. APs may have access or interfaces to a Distribution System (DS) or another type of wired / wireless network that loads and / or loads traffic into and / or out of the BSS. Traffic originating outside the BSS and destined for STAs can reach and be delivered to those STAs via the AP. Traffic originating from STAs and destined for destinations outside the BSS can be sent to the AP for delivery to individual destinations. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP and the AP can deliver traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer traffic. Peer traffic can be sent between a source STA and a destination STA (e.g., directly between them) using a direct link setup (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

[0046] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz bandwidth) or dynamically set width. The primary channel can be the operating channel of the BSS and can be used by STAs to establish connections with the AP. In some representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, STAs including the AP (e.g., each STA) can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that particular STA can go offline. A STA (e.g., only one station) can transmit at any given time within a given BSS.

[0047] High-throughput (HT) STAs can use 40 MHz wide channels for communication, for example, by combining a 20 MHz main channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0048] The Very High Throughput (VHT) STA supports channels of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz width. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels (referred to as an 80+80 configuration). For the 80+80 configuration, after channel encoding, data can be transmitted through a segment parser that can divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately on each stream. Streams can be mapped to two 80 MHz channels, and data can be transmitted via the transport STA. At the receiver receiving the STA, the above operation for the 80+80 configuration can be reversed, and the combined data can be sent to the Medium Access Control (MAC).

[0049] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support Meter Type Control / Machine-Type Communications (MTC), such as MTC devices in large coverage areas. MTC devices may have certain capabilities, including limited capabilities such as supporting (e.g., only supporting) certain and / or limited bandwidths. MTC devices may include battery packs with a battery pack life exceeding the critical limit (e.g., to maintain a very long battery pack life).

[0050] WLAN systems supporting multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA supporting the minimum bandwidth operating mode among all STAs operating in the BSS. In the 802.11ah example, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes, the primary channel can be 1 MHz wide for STAs supporting (e.g., only supporting) the 1 MHz mode (e.g., MTC type devices). Carrier sensing and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. For example, if the main channel is busy, for example because the STA (which only supports 1 MHz operating mode) transmits to the AP, all available frequency bands can be considered busy even if most of the available frequency bands remain idle.

[0051] In the United States, the available frequency band (which can be used by 802.11ah) ranges from 902 MHz to 928 MHz. In South Korea, the available frequency band ranges from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band ranges from 916.5 MHz to 927.5 MHz. Depending on the country code, the total bandwidth available for 802.11ah ranges from 6 MHz to 26 MHz.

[0052] Figure 1D is a system diagram illustrating RAN 104 and CN 106 according to one embodiment. As mentioned above, RAN 104 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 may also communicate with CN 106.

[0053] RAN 104 may include gNBs 180a, 180b, and 180c, but it will be understood that RAN 104 may include any number of gNBs while remaining consistent with one embodiment. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a, for example, may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0054] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable set of parameters (numerology). For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various lengths or scalable lengths (e.g., containing a varying number of OFDM symbols and / or a continuously varying absolute time length).

[0055] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more gNBs 180a, 180b, and 180c as operational anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can use signals in unlicensed frequency bands to communicate with gNBs 180a, 180b, and 180c. In a non-independent configuration, WTRUs 102a, 102b, and 102c can communicate with / connect to gNBs 180a, 180b, and 180c, while also communicating with / connecting to another RAN (such as eNode-Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to substantially simultaneously communicate with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c. In a non-independent configuration, eNode-B 160a, 160b, and 160c can act as action anchors for WTRU 102a, 102b, and 102c, and gNB 180a, 180b, and 180c can provide additional coverage and / or throughput for servicing WTRU 102a, 102b, and 102c.

[0056] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, interaction between DC, NR, and E-UTRA, routing of user plane data to User Plane Function (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Function (AMF) 182a and 182b, and similar functions. As shown in Figure 1D, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0057] The CN 106 shown in Figure 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and may include Data Network (DN) 185a, 185b. Although the above elements are depicted as components of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0058] AMF 182a and 182b can connect to one or more gNBs 180a, 180b, and 180c in RAN 104 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) conversations with different requirements), selecting specific SMF 183a and 183b, managing login zones, terminating non-access-stratum (NAS) communications, managing mobility, and similar functions. Network slices can be used by AMF 182a and 182b to customize CN support for WTRU 102a, 102b, and 102c based on the type of service being used by the WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like. AMF 182a and 182b can provide control plane functions for switching between RAN 104 and other RANs (not shown) that use other radio technologies (such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies (such as WiFi)).

[0059] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b and configure traffic routes through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU conversations, controlling policy enforcement and QoS, providing DL data notifications, and similar functions. PDU conversation types can be IP-based, non-IP-based, Ethernet-based, and similar.

[0060] UPF 184a and 184b can be connected via an N3 interface to one or more gNBs 180a, 180b, and 180c in RAN 104. This interface provides access to packet-switched networks (such as Internet 110) to WTRU 102a, 102b, and 102c to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

[0061] CN 106 can facilitate communication with other networks. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and PSTN 108, or be able to communicate with such an IP gateway. Additionally, CN 106 may provide access to other networks 112 to WTRUs 102a, 102b, 102c, such other networks may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, 102c may be connected to area DN 185a, 185b via UPF 184a, 184b through an N3 interface to UPF 184a, 184b and an N6 interface between UPF 184a, 184b and DN 185a, 185b.

[0062] Based on the corresponding descriptions in Figures 1A to 1D, one or more of the following functions described herein can be performed by one or more emulation devices (not shown): WTRU 102a to 102d, base stations 114a to 114b, eNode-B 160a to 160c, MME 162, SGW 164, PGW 166, gNB 180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b, and / or any other device(s) described herein. Emulation devices can be configured to emulate one or more of the functions described herein. For example, emulation devices can be used to test other devices and / or simulate network and / or WTRU functions.

[0063] Simulation devices can be designed to perform one or more tests on other devices in a laboratory environment and / or an operator network environment. For example, one or more simulation devices can perform one or more or all of their functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices can perform one or more or all of their functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices can be directly coupled to another device and / or use over-the-air wireless communication to perform tests for testing purposes.

[0064] One or more simulation devices can perform one or more (including all) functions while not being implemented / deployed as a wired and / or wireless communication network. For example, simulation devices can be used in test scenarios in test laboratories and / or non-deployed (e.g., test) wired and / or wireless communication networks to perform tests on one or more components. One or more simulation devices can be test instruments. Wireless communication via direct RF coupling and / or through an RF circuit system (e.g., which may include one or more antennas) can be used by the simulation devices to transmit and / or receive data.

[0065] Figure 2 is a diagram illustrating an example of a single DCI with multiple TRP PUSCH repetition. New Radio (NR) supports uplink transmissions from the WTRU to a Transmitting Receiver Point (TRP) (e.g., Physical Uplink Shared Channel (PUSCH) transmission). For example, to assist network scheduling, the WTRU can send periodically triggered Power Header Spatial Reports (PHRs). For example, the WTRU can send a Power Headroom Report (PHR) when it determines that triggering conditions are met (e.g., path loss or a change in Power Management Maximum Power Reduction (P-MPR) exceeding a threshold). In one example, additional enhancements can allow the WTRU to send PUSCH repetitions to multiple TRPs, as shown in Figure 2. In one example, multiple TRPs can provide diversity even when one link suffers from poor channel conditions (e.g., congestion, deep attenuation, etc.). In one example, the DCI can be enhanced to reuse transmissions using different spatial filters corresponding to different TRPs. In one example, the WTRU can maintain a power control loop (i.e., TPC commands and open-loop parameters) for each TRP. For example, WTRU can use explicit bit fields in DCI to dynamically switch from a single TRP transport to a multi-TRP transport.

[0066] In one embodiment illustrated in Figure 2, a second Service Request Indicator (SRI) can be introduced into the DCI to determine the spatial filter per TRP. In one example, the second TPC field in the DCI can optionally be configured as an RRC (depending on WTRU capability) for closed-loop adjustment per TRP. In one example, P0 can be configured per TRP. For example, if the OLPC is set to indicator 0, P0 can be mapped to SRI-PUSCH-PowerControl. In one example, separate PHRs may be possible if separate SRIs are available. In one embodiment, if the OLPC is set to indicator 1, P0 can be mapped to the second configured p0-PUSCH-SetList-r16. In one example, dynamic single TRP / multiple TRP (sTRP / mTRP) switching can be introduced into the DCI. For example, two bits can facilitate selection between sTRP TRP1, sTRP TRP2, mTRPs starting with TRP1, and / or mTRPs starting with TRP2.

[0067] In one embodiment, the WTRU can determine the power headroom (PH). In one example, the WTRU can determine the PH of the cell and / or (e.g., the cell's or cell-associated) TRP. In one example, the WTRU can determine the PH as the difference between the calculated power and the maximum power. In one example, the WTRU can determine the calculated power based on parameters of the license and / or format (e.g., DCI format), such as, for example, frequency allocation (e.g., resource block (RB) allocation)). In one example, the license can be a dynamic license, a configured license, or a reference license. In one example, the format can include a license or a reference format. In one example, a reference license or reference format can correspond to a specific number of RBs, such as 1 RB.

[0068] In one embodiment, the WTRU can determine that the calculated power is based on path loss (PL). In one example, PL may be a measurement of the reference signal (RS) of the PL reference RS. In one example, the PL reference RS may be identified by an RS (such as SSBRI (SSB Resource Indicator) or CRI (CSI-RS Resource Indicator)). In one example, the indicator (e.g., SRS Resource Indicator (SRI)) may be configured to have a PL reference RS as part of an SRS-Configie. In one example, the indicator (e.g., SRI) may be provided or have authorization in an authorization (e.g., UL authorization). In one example, the indicator (e.g., SRI) may be provided in a PDCCH, DCI, or DCI format received by the WTRU in which the authorization is located. In one example, authorization may be used for PUSCH transmission.

[0069] In one embodiment, the WTRU can determine the calculated power based on one or more (e.g., accumulated) Transmit Power Control (TPC) commands. In one example, the WTRU can receive, use, and / or accumulate (e.g., separately) TPC commands for each cell, TRP, and / or SRI group. In one example, the cell, TRP, and / or SRI group may have or be configured to have one or more power control loops (e.g., adjustment states). In one example, the WTRU can receive, use, and / or accumulate (e.g., separately) TPC commands for each power control loop for each cell, TRP, and / or SRI group. In one example, the power control loop used (e.g., for a cell, TRP, or SRI group) may be provided through authorization (e.g., through SRI).

[0070] In one embodiment, there may be one or more types of PHs, such as PHs for PUSCH transmissions (e.g., type 1), PHs for SRS transmissions (e.g., type 3), and / or PHs for simultaneous PUSCH and PUCCH transmissions (e.g., type 2). In one instance, the WTRU may include one or more types of PH information for one or more cells and / or (e.g., the TRP of the one or more cells) in the PHR. In one instance, power backoff may be an applied power backoff (e.g., applied by the WTRU). In one instance, power backoff may result from power management (e.g., power management maximum) power reduction (P-MPR) or be permitted by such power management power reduction. In one instance, power backoff may be applied to meet maximum permissible exposure (MPE) requirements. Power backoff and power reduction are used interchangeably herein.

[0071] In one embodiment, a Power Headroom Report (PHR) may include PH information for one or more cells. In one instance, the PH information may include, for example,: (i) PH (e.g., PH value), (ii) maximum power (e.g., Pcmax, c or PCmax, f, c), (iii) whether the PH value is an actual or virtual indication (e.g., V flag / indicator), (iv) a flag or indicator (e.g., P or other flag / indicator) indicating whether power backoff (e.g., power management power backoff or power reduction) affects maximum power, and / or (v) a flag or indicator (e.g., P or other flag / indicator), and / or at least one of the like. For example, a flag or indicator may indicate that the applied power backoff (such as, for example, P-MPR) is less than (or greater than or equal to) a configured value, a specified value, or other known value (e.g., a value that meets the Maximum Tolerable Exposure (MPE) requirement).

[0072] In one embodiment, the actual PH (e.g., PH value) may be a PH (e.g., PH value) determined based on the actual authorization (e.g., actual UL authorization) that the WTRU can receive. The actual authorization may be a dynamic authorization (e.g., DCI-based authorization) or a configured authorization (e.g., RRC-configured or RRC-configured and DCI-activated). The virtual PH (e.g., PH value) may be a PH (e.g., PH value). For example, the PH may be determined based on a reference authorization and / or format (e.g., based on a single RB allocation).

[0073] In one embodiment, the WTRU may trigger a PHR based on the satisfaction of one or more conditions. In one instance, such conditions may include at least one of the following: (i) the expiration of a timer (e.g., a periodic timer), (ii) a change in the PL value (e.g., for a cell or TRP) exceeding a threshold (e.g., since the last PHR transmission), (iii) power back-off, and / or (iv) a P-MPR (e.g., a measured P-MPR), and / or the like. In one instance, power back-off may be attributable to power management (e.g., as permitted by the P-MPR), and the change in power back-off may, in one instance, exceed a threshold. In one instance, the P-MPR may be a P-MPR applied to meet MPE requirements, and in one instance, the P-MPR may have changed to or has changed to be equal to or greater than a threshold (e.g., since the last PHR transmission). In one instance, the triggering condition based on the expiration of a timer may be referred to herein as periodic timer triggering. In one instance, a triggering condition based on a PL change may be referred to herein as a PL trigger. In one instance, a triggering condition relating to backoff and / or P-MPR may be referred to herein as a P-MPR trigger. In one instance, a triggering condition relating to MPE may be referred to herein as an MPE trigger. In one instance, the thresholds for PL changes and / or power backoff changes may be the same or different and may be configured (e.g., received by the WTRU from the gNB). In one instance, the thresholds may be configured separately for each cell and / or TRP. The terms power backoff (e.g., as permitted by P-MPR), P-MPR backoff, and / or P-MPR may be used interchangeably herein. In one instance, the WTRU may transmit a PHR when or after the WTRU triggers a PHR.

[0074] In one embodiment, a PHR transmission may include a multi-TRP transmission. In one example, the WTRU may transmit the PHR in a MAC CE and / or in a Transport Block (TB). In one example, the WTRU may include a PHR MAC CE in a TB. In one example, the WTRU may transmit a TB or PHR in a PUSCH. In one example, the WTRU may include a MAC CE or TB that may include a PHR in a PUSCH transmission. In one example, a PUSCH transmission may include data, UL Control Information (UCI), and / or one or more MAC CEs, and / or one or more of the like. In one example, a TB may include data, one or more MAC CEs, and / or the like. In one example, when the WTRU transmits a TB to multiple TRPs (e.g., based on an authorization for multi-TRP transmission) and the TB includes a PHR or a MAC CE that includes a PHR, the PHR (e.g., the same PHR) may be transmitted to multiple TRPs. In one instance, when the WTRU transmits a TB in multiple PUSCH transports (e.g., based on individual SRI groups (e.g., based on authorizations for each of the multiple SRI groups including SRIs)) and the TB includes a PHR or a MAC CE including the PHR, the PHR (e.g., the same PHR) may be transmitted in multiple PUSCH transports. In one instance, the PH information included in the PHR by the WTRU may depend on when the PHR is triggered and / or which resources(s) are available to transmit the PHR.

[0075] In one embodiment, in a deployment scenario with multiple TRPs and / or cells, each WTRU-TRP link may have its own path loss. In one instance, a WTRU-TRP link may include WTRUs that may require different transmission power toward different TRPs. In one instance, separate PHRs may need to be triggered for each TRP. In one instance, a WTRU may need to report one or more PHRs. In one instance, multiple PHRs may be triggered for different TRPs, for example, to determine how to calculate (e.g., actual or virtual) multi-TRP PH levels. In one instance, multiple PHRs may be triggered for different TRPs, for example, to determine how to report multiple PHRs. In one instance, simultaneous multi-panel uplink transmission may be enabled, for example, in the PHR procedure. In one instance, the PHR triggering and / or reporting procedure may need to be enhanced.

[0076] In one embodiment, the PHR pattern considered in multi-TRP and / or multi-cell deployments may be used for triggering rules of each reference signal (RS) group in the multi-TRP (e.g., path loss, P-MPR, and path loss between RS groups). In one embodiment, the PHR pattern considered in multi-TRP and / or multi-cell deployments may be used for PHR reporting rules in intra-cell or inter-cell scenarios (e.g., mTRP mode determination, single-to-multiple PH level reporting, Media Access Control – Control Element (MAC-CE) enhancement). In one embodiment, the PHR pattern considered in multi-TRP and / or multi-cell deployments may be the PHR in simultaneous UL multi-panel (STxMP) transmission to the mTRP (e.g., STxMP mode determination, STxMP PHR calculation).

[0077] In one embodiment, triggering rules can be defined for multiple TRPs. For example, a triggering rule may be that the WTRU can be configured to have one or more Transmission Receive Points (TRPs) to which the WTRU can transmit and / or from which the WTRU can receive (or to which one or more Transmission Control Points can be received). In one instance, the WTRU can be configured to have one or more TRPs for one or more cells. For example, a cell may be a serving cell. In one embodiment, a triggering rule may be that the WTRU can be configured to have one or more Path Loss (PL) Reference Groups (e.g., groups) and / or one or more SRS groups, SRS Resource Indicators (SRIs), SRS Resource Groups, and / or similar configurations (or to receive them). In one embodiment, a triggering rule may be that the PL Reference Group may correspond to or be associated with a TRP. In one instance, a PL reference group may include, identify, correspond to, or be associated with one or more TCI states, SRIs, reference signal groups (e.g., CSI-RS groups, SRI groups), CORESET indexes, reference signals (e.g., CSI-RS, SSB), and / or similar entities, and / or be associated with one or more TCI states, SRIs, reference signal groups, CORESET indexes, reference signals, and / or similar entities. In one embodiment, a triggering rule may be that the WTRU can receive configurations (e.g., any configuration described herein). In one instance, the configuration may be received from a gNB or TRP. For example, the WTRU may receive configurations of one or more TRPs, one or more PL reference groups, and / or one or more SRI groups. In one instance, the WTRU may implicitly determine the association between an RS group / group and a TRP. As an example, if the WTRU is configured to have two SRS resource groups, the WTRU may determine to use the SRS in the first resource group to transmit to TRP1 and to use the SRS in the second resource group to transmit to TRP2. In one instance, configuration can be communicated via RRC. In the examples and embodiments described herein, TRP, PL reference group, SRI group, and SRI group are used interchangeably. Terminology groups and groups are used interchangeably herein.

[0078] In one embodiment, the nature of the authorization or assignment may consist of at least one of the following: frequency allocation; time configuration pattern, such as duration; priority order; modulation and encoding / decoding scheme; transmission block size; number of spatial layers; number of transmission blocks; TCI status, CRI, or SRI, wherein if multiple panels are used for UL transmission, the TCI status, CRI, or SRI may be available for each WTRU panel; number of repetitions; wherein the repetition scheme is type A or type B; authorization is configured as type 1, type 2, or dynamic authorization; assignment is dynamic assignment or semi-persistent scheduling (configured) assignment; configured authorization index or semi-persistent assignment index; periodicity of configured authorization or assignment; Channel Access Priority Class (CAPC); and / or any parameters for scheduling authorization or assignment provided in the DCI by MAC or by RRC. Authorization or assignment may indicate that the authorization is for a single TRP transmission or multiple TRP transmissions; and / or that the authorization is for a UL transmission from a single WTRU panel (TxSP) or for a simultaneous UL transmission from multiple WTRU panels (STxMP).

[0079] In one embodiment, the WTRU may receive or be configured with an authorization (e.g., UL authorization) for at least one transmission (e.g., PUSCH). In one example, the transmission may be associated with one or more TRPs. In one example, the WTRU may determine that a spatial filter is used for the PUSCH transmission, which may be based on an authorization that may include one or more indicators (e.g., SRIs). In one example, the authorization may include indications of one or more TRPs, for example, via SRIs for each of the one or more TRPs. In one example, the WTRU may determine the association between SRIs and TRPs, for example, by the order of SRIs in the authorization (e.g., the first SRI is for TRP1 and the second SRI is for TRP2). In one example, the WTRU may, for example, transmit a PUSCH for each of the indicated SRIs or TRPs in response to the authorization. In one example, the WTRU may transmit or include TBs (e.g., the same TB) in each of the transmissions, for example, (e.g., for each of the SRIs or for each of the TRPs). In one example, the SRI may be associated with or correspond to a reference signal (RS). In one example, the RS may be associated with or correspond to a CSI-RS or an SSB (e.g., an SSS of an SSB). In one example, the WTRU may use (e.g., each) an SRI to determine the transmission spatial filter (i.e., the direction of the beam of the WTRU's antenna), for example, for individual transmissions. In one example, a license may be used for a single transmission via an indicated SRI or a TRP, or for multiple (e.g., repeated) transmissions via indicated SRIs or TRPs. In one example, the same TB may be transmitted in multiple transmissions.

[0080] In one embodiment, the WTRU may receive, for example, a first SRI (e.g., a first SRI index) and a second SRI (e.g., an SRI index) in the authorization. In one instance, the first SRI may be an SRI from a first SRS resource group, and the second SRI may be from a second SRS resource group. In one instance, the first SRI group may correspond to a first TRP, and the second SRI group may correspond to a second TRP. In one instance, the WTRU may transmit a first PUSCH based on the first SRI and / or transmit the first PUSCH to the first TRP. In one instance, the WTRU may transmit a second PUSCH based on the second SRI and / or transmit the second PUSCH to the second TRP. In one instance, the SRI may be used herein as a non-limiting instance of an indicator. In one instance, another indicator may be used, still consistent with the embodiments and examples described herein.

[0081] In one embodiment, the nature of data included in a transport block (TB) may refer to any parameters configured therefor that may be included in the logical channels or radio bearers within the TB. For example, the parameters configured for a logical channel or radio bearer may include logical channel priority, priority bit rate, logical channel group, RLC mode, and / or the like. In one instance, the nature of authorization or assignment may also refer to the nature of data that may be included in the corresponding TB.

[0082] In one embodiment, the indication via DCI may include: explicit indication via DCI field or via RNTI used to mask the CRC of PDCCH; or implicit indication via properties (such as DCI format received via DCI, DCI size, Coreset or search space, aggregation level, first resource element (e.g., index of first control channel element)), wherein the mapping between properties and values ​​may be via RRC or MAC communication.

[0083] In one embodiment, the WTRU can transmit or receive physical channels or reference signals based on at least one spatial domain filter (or "spatial filter"). For example, the term "beam" can be used to refer to a spatial domain filter.

[0084] In one instance, the WTRU may transmit a physical channel or signal using the same spatial domain filter used for receiving RS (such as CSI-RS) or SS blocks. In one instance, the WTRU transmission may be referred to as the "target," and the received RS or SS block may be referred to as the "reference" or "source." In such cases, for example, the WTRU may transmit a target physical channel or signal based on spatial relationships, such as referencing an RS or SS block.

[0085] In one example, the WTRU may transmit the first physical channel or signal according to the same spatial domain filter used for transmitting the second physical channel or signal. In one example, the first and second transmissions may be referred to as the "target" and the "reference" (or "source"), respectively. In such cases, for example, it can be said that the WTRU transmits the first (target) physical channel or signal according to the spatial relationship of the reference second (reference) physical channel or signal.

[0086] In one instance, spatial relations can be implicit, configured via MAC CE, or communicated via MAC CE or DCI. For example, a WTRU can implicitly transmit PUSCH and PUSCH DM-RS based on the same spatial domain filter as the SRS indicated by the SRI in the DCI or configured via RRC. In one instance, spatial relations can be communicated via RRC configuration for the SRS Resource Indicator (SRI) or via MAC CE for the PUCCH. In one instance, spatial relations can also be referred to as "beam indication".

[0087] In one instance, spatial relationships can be configured with parameters such as the resources used as a path loss reference, at least one power offset (P0), and an index for closed-loop adjustments. In another instance, these parameters can be used to set the transmission power of physical channels or signals when transmitting according to spatial relationships.

[0088] In one example, the WTRU can receive a first (target) downlink channel or signal based on the same spatial domain filter or spatial reception parameters as the second (reference) downlink channel or signal. For example, an association can exist between a physical channel (such as PDCCH or PDSCH) and its respective DM-RS. In one example, when both the first and second signals are reference signals, an association can exist between a physical channel (such as PDCCH or PDSCH) and its respective DM-RS when the WTRU is configured with a Quasi-Co-location (QCL) assumption type D between corresponding antenna ports. In one example, the association between a physical channel (such as PDCCH or PDSCH) and its respective DM-RS can be configured as a TCI (Transmission Configuration Indicator) state. In one example, the association between a physical channel (such as PDCCH or PDSCH) and its respective DM-RS can be indicated to the WTRU by indexing a set of TCI states transmitted via RRC configuration and / or MAC CE. In one example, such an indication can also be referred to as a "beam indication".

[0089] In one embodiment, path loss-based triggering can be performed per RS ​​group (i.e., TRP). In one embodiment, the WTRU can trigger a PHR based on a path loss difference exceeding a threshold, wherein, for example, the path loss difference can be measured on path loss reference RSs that can be associated with the same RS group. In one instance, the WTRU can be configured to have multiple path loss reference RSs, and the WTRU can measure the path loss of each path loss reference RS. In one instance, a set of path loss reference RSs can be associated with an RS group. In one instance, the WTRU can measure the path loss difference of path loss reference RSs belonging to the same group, and if, for example, the path loss difference measured between RSs within the same group goes above a threshold, a PHR can be triggered. In one instance, the WTRU can be enabled to track path loss changes per TRP (i.e., RS group), and the WTRU can independently determine when to trigger a PHR for each TRP (i.e., RS group).

[0090] In one embodiment, a multi-TRP PHR can be triggered if the phr-ProhibitTimer expires or has expired, and the path loss of at least one active RS group via the serving cell for any MAC entity has changed by more than phr-Tx-PowerFactorChange dB. In one instance, when a MAC entity may have UL resources for a new transmission, because the PHR is the last transmission in this MAC entity, at least one active DL BWP via the serving cell for any MAC entity may be a non-dormant BWP, which in one instance can be used as a path loss reference. In one embodiment, a multi-TRP PHR can be triggered if the path loss change of an RS group of a cell evaluated above is between the path loss now measured on the current path loss reference of that RS group and the path loss measured on the path loss reference of the RS group used at the time of the last transmission in the PHR, regardless of whether the path loss has changed in between. In one instance, the current path loss reference used for this purpose may not include any path loss reference configured using pathlossReferenceRS-Pos.

[0091] In one embodiment, path loss thresholds can be configured per RS ​​group (e.g., a threshold configured per TRP as part of the PHR-Config IE). In another embodiment, path loss thresholds can be configured for more than one RS group (e.g., a threshold for all TRPs within the cell).

[0092] In one embodiment, the WTRU can determine or configure the presence of RS groups based on the configuration of a set of reference signals or spatial filters (e.g., SRS, CSI-RS, SSB, TCI states). For example, the WTRU can be configured to have a first SRS resource group consisting of SRI1 and SRI2 to TRP1, and a second SRS resource group consisting of SRI3 and SRI4 to TRP2. RS group 1 can consist of SRS resource group 1, while RS group 2 can consist of SRS resource group 2. In one embodiment, the WTRU can implicitly determine or configure the presence of RS groups based on the position of SRIs in a multi-TRP DCI. In one example, when a DCI is configured to have two SRIs, the WTRU can determine that the first indicated SRI in the DCI belongs to RS group 1, and the second indicated SRI belongs to RS group 2. In one embodiment, the WTRU can determine, or be configured to have an RS group, based on the determination that the CORESET ID or CORESETpoolindex of the PDCCH received by the WTRU from the DCI is associated with it, and the WTRU can determine that RSs associated with the same CORESET ID or CORESETpoolindex correspond to RSs in the same RS group. In one embodiment, the WTRU can determine, or be configured to have an RS group, based on the determination that RSs configured for or associated with the panel are associated with an RS group. For example, the WTRU can use panel 1 to send to TRP1 and to TRP2 to send to panel 2. Then, for example, the WTRU can determine that any SRI sent from panel 1 is associated with RS group 1, and any SRI sent from panel 2 is associated with RS group 2.

[0093] Figure 3 illustrates an example of PHR triggering with two RS groups. In one embodiment, the WTRU can be configured to have two RS groups, each RS group consisting of two SRIs. In one example, each SRI can be configured as part of an SRS-Config with PathlossReferenceRS. In one example, the TRP can send PathlossReferenceRS 1 to 4 and the WTRU can receive them, wherein the WTRU can perform path loss measurements 1 to 4 at time t1 and similarly at a later time t2. In one example, the WTRU can determine that the DCI uses SRI1 from RS group1 and SRI3 from RS group2 to schedule the WTRU. In one example, on the next transmission, the WTRU can determine that the DCI uses SRI2 from RS group1 and SRI3 from RS group2 to schedule the WTRU. In one instance, the WTRU can measure the path loss difference between RSs (pathloss1(t1) and pathloss2(t2)) in group1 and between RSs (pathloss3(t1) and pathloss3(t2)) in group2. In one instance, if the difference exceeds a threshold, the WTRU can trigger a PHR. In one instance, the WTRU can include the PHR in the PUSCH resource on the next scheduled transfer.

[0094] In one embodiment, if a PHR is triggered by path loss difference, the WTRU can calculate the PHR associated with the TRP in the RS group. In one instance, the WTRU can determine the resource allocation from multiple TRP grants to the PUSCH transport that triggered the TRP. In one instance, the WTRU can calculate the actual PHR of the triggered TRP and may include the PHR in the PUSCH transport. In one instance, if no grant is available, but the PHR is still triggered for the TRP, the WTRU can calculate a virtual PHR based on a reference resource allocation (e.g., 1 RB). In one instance, the WTRU may transport the PHR on the next available PUSCH transport to the triggered TRP.

[0095] In one embodiment, an RS group can be pre-configured to have a set of RSs. In one instance, a subset of RSs can be dynamically activated via a MAC-CE, where the MAC-CE may contain an index of the RS for activation / deactivation (e.g., an RS index and a flag indicating 1 or 0). In one instance, more than one RS group can be associated with a TRP. In one instance, an RS group can be active at any given time. In one instance, an RS group can be activated via a MAC-CE while other RS ​​groups are inactive.

[0096] In one embodiment, P-MPR triggering can be configured, monitored, or acquired per RS ​​group. In one instance, multiple TRP PHRs can be triggered if the phr-ProhibitTimer expires or has expired. In one instance, multiple TRP PHRs can be triggered if the phr-ProhibitTimer expires or has expired when a MAC entity has UL resources for a new transmission. In one instance, multiple TRP PHRs can be triggered if the phr-ProhibitTimer expires or has expired when a MAC entity has UL resources for a new transmission, and the following is true for any activated serving cell of any MAC entity with a configured uplink: there are UL resources allocated for transmission or there is a PUCCH transmission on this cell. In one instance, when a MAC entity has UL resources for a new transmission, a multi-TRP PHR can be triggered if the phr-ProhibitTimer expires or has expired, and the following is true for any activated serving cell of any MAC entity with a configured uplink: when the MAC entity transmits the actual PH of the cell's RS group, the required power backoff due to the last transmission of the PHR is caused by the power management of the cell's RS group (as permitted by the P-MPR specified in TS 38.101-1, TS 38.101-2, and TS 38.101-3) having changed more than phr-Tx-PowerFactorChange dB. In one instance, when a MAC entity has UL resources for a new transmission, a multi-TRP PHR can be triggered if the phr-ProhibitTimer expires or has expired, and the following is true for any activated serving cell of any MAC entity with a configured uplink: the MAC entity previously had UL resources allocated for transmissions on RS groups or PUCCH transmissions in this cell. In one instance, when a MAC entity has UL resources for a new transmission, a multi-TRP PHR can be triggered if the phr-ProhibitTimer expires or has expired, provided that the following are true for any activated serving cell of any MAC entity with a configured uplink: there are UL resources allocated for transmission or there is a PUCCH transmission on this cell; when the MAC entity transmits the actual PH of the RS group of the cell, the required power backoff due to the last transmission of the PHR is caused by the power management of the RS group of this cell (as permitted by the P-MPR specified in TS 38.101-1, TS 38.101-2, and TS 38.101-3) has changed more than phr-Tx-PowerFactorChange dB; and the MAC entity previously had UL resources allocated for transmission or PUCCH transmission on the RS group of this cell.

[0097] In one embodiment, the WTRU may trigger a PHR when one or more of the following are true: (i) there is an actual transmission (e.g., PUSCH or PUCCH) on the TRP, there is an actual transmission to or for the TRP, and / or (ii) when an actual PH for (e.g., of the cell) the TRP is included, the power back-off of the TRP (e.g., due to power management) has changed more than the threshold amount because of the last transmission of the PHR.

[0098] In one embodiment, the WTRU may trigger a PHR when one or more of the following are true: (i) there is an actual transmission on the TRP that could result in an actual PH transmission for that TRP (e.g., PUSCH or PUCCH), there is such actual transmission to or for the TRP, and / or (ii) when the actual PH of the TRP is transmitted (e.g., for the cell), the power back-off of the TRP (e.g., due to power management) has changed more than the threshold amount because of the last transmission of the PHR.

[0099] In one embodiment, the WTRU may trigger a PHR when one or more of the following are true: (i) there are resources allocated for a UL transmission or PUCCH transmission of the TRP (e.g., for a cell), such resources may result in an actual PH transmission of the TRP, and / or (ii) when an actual PH for the TRP (e.g., for a cell) is included, the power back-off of the TRP (e.g., due to power management) has changed more than the threshold amount because of the final transmission of the PHR.

[0100] In one embodiment, the cell may be a serving cell, an activated cell, or an activated serving cell. In one example, the cell may be a cell with a configured UL. In one example, power backoff may be a required power backoff or an applied power backoff. In one example, power backoff may be due to, for example, power management permitted by P-MPR. In one example, P-MPR may be used for the cell and / or for the TRP. In one example, power backoff and / or P-MPR (e.g., permitted PMPR or maximum P-PMR) may be cell-specific or TRP-specific. In one example, a threshold may be received from the TRP or gNB. In one example, the WTRU may, for example, receive the threshold configuration from the TRP or gNB. In one example, the threshold may be in dB. In one example, the threshold may, for example, be referred to as phr-Tx-PowerFactorChange. The terms "on a TRP", "to a TRP", and "for a TRP" are used interchangeably in this document.

[0101] For example, when a MAC entity has UL resources for a new transport, the WTRU may or may only trigger a PHR when a timer (e.g., phr-ProhibitTimer) expires or has expired. In one instance, an actual transport to the TRP may occur when there are UL resources allocated for a transport to the TRP (e.g., via dynamic or configured authorization) or when there is a PUCCH transport to or for the TRP. In one instance, resources allocated for UL transports may be allocated via a single TRP authorization or multiple TRP authorizations.

[0102] In one instance, the WTRU may or may only trigger the PHR when its power backoff changes more than the threshold TRP system allocates resources for a TRP used for UL transmission (e.g., when the allocation system is based on a single TRP grant).

[0103] In one instance, the WTRU may or may only trigger the PHR of the first TRP in a multi-TRP grant. In one instance, the WTRU may or may only trigger the PHR when the first TRP, for which its power backoff changes more than the threshold, is allocated resources for UL transmission (e.g., when the allocation is based on a multi-TRP grant). In one instance, the first TRP may be the TRP with the earliest allocated resources. The terms P-MPR and PMPRC are used interchangeably herein.

[0104] In one instance, a power backoff change can be a change in power backoff exceeding a threshold. In one instance, the WTRU can or can only trigger a PHR for the cell, for example, when there are UL resources for a new transmission and / or UL resources for a first transmission of a TB on the cell, for example, a power backoff change for the cell's TRP. For example, this can ensure that the WTRU sends the PHR on the cell. In one instance, the WTRU can send the PHR to at least one of the cell's TRPs (e.g., all TRPs).

[0105] In one instance, the WTRU may or may only trigger a PHR of the cell, for example, when there are UL resources for a new transmission and / or UL resources for a first transmission of TB on the cell, for example, when the WTRU has UL resources allocated to the cell and uses multiple TRP grants to allocate resources, for example, for a power backoff change of the cell's TRP. In one instance, a new trigger may be based on the difference between the PHRs or path losses of two different RS groups.

[0106] In one embodiment, the WTRU can trigger a PHR when the path loss difference or path loss difference between RS groups exceeds a threshold. For example, the WTRU can determine that RS group 1 can use path loss reference RS1 to measure path loss 1, and RS group 2 can use path loss reference RS2 to measure path loss 2. Then, for example, if the WTRU determines that the path loss difference Δ between path loss 1 and path loss 2 is higher than a threshold, the WTRU can trigger a PHR. In one example, the RS groups may be located in the same cell, in which case the path loss difference is measured within the cell. In one example, the two RS groups may be associated with different cells, in which case the path loss difference is measured between cells. In one example, the WTRU may be configured with different thresholds for intra-cell and inter-cell use. In one example, a PHR can be triggered if the path loss difference between either intra-cell or inter-cell use exceeds a threshold.

[0107] In one embodiment, the WTRU may determine to trigger a PHR when the change in path loss difference between RS groups exceeds a threshold. For example, the WTRU may measure the path loss difference Δ1 at time t1. For example, the WTRU may measure the path loss difference Δ2 at a later time t2>t1. For example, if Δ1 - Δ2 is greater than the threshold, the WTRU may trigger a PHR. In one embodiment, the WTRU may determine to trigger a PHR when the difference in RSs is greater than a threshold. For example, the WTRU may calculate two PH levels based on the grant, PHR1, and PHR2. For example, if PHR1 - PHR2 is greater than the threshold, the WTRU may be triggered to report two PHRs. In one embodiment, the WTRU may determine to trigger a PHR if one of the calculated PHRs is greater than a threshold (e.g., if the PHR is negative). In one instance, the network may receive a PHR triggered by one of these embodiments. In one instance, the network may determine that one of the RS groups may no longer be suitable for multi-TRP transmission (e.g., due to large path loss or PHR difference). In one instance, the network can switch between using an RS group or a TRP in a secondary TRP authorization.

[0108] In one embodiment, PHR reporting rules can be specified for intra-cell and inter-cell mTRPs. In one embodiment, the WTRU can dynamically switch between single and multiple TRP transmissions. In one instance, dynamic indication can be provided by authorization. In one instance, authorization can instruct that PUSCH be transmitted only to TRP1, only to TRP2, to TRP1 followed by TRP2, or to TRP2 followed by PRP1. In one instance, enhancements to PHR can take into account different indicated sTRP / mTRP scenarios depending on whether a single or multiple TRPs trigger PHR, whether a single or multiple PHRs are reported, how PHRs are reported, whether the TPR is intra-cell or inter-cell, and / or similar. The terms WTRU and MAC entity are used interchangeably herein.

[0109] In one embodiment, the WTRU may trigger a PHR (e.g., based on one of the triggering conditions described herein). In one instance, the WTRU may transmit a PHR when the WTRU has UL resources for the new transmission (e.g., capable of accommodating a PHR MAC CE). In one instance or (e.g., each) cell (e.g., serving cell or activated serving cell), the WTRU may determine whether to include an actual PH value (e.g., based on actual license or transmission) or a virtual PH value (e.g., based on a reference format).

[0110] In one embodiment, when the WTRU has authorization information available for the cell, the WTRU may include the actual PH value of the cell (e.g., the serving cell or the activated serving cell). In one instance, for example, the WTRU may consider or determine that authorization information is available after (or at the time of) a PHR trigger and before or at the time the WTRU receives authorization or DCI information for the PUSCH in which the WTRU can transmit (or transmit) the PHR. In one instance, when the actual authorization is not considered available for the cell or TRP, the WTRU may include a virtual PH or no PH in the PHR of the TRP.

[0111] In one instance, the WTRU or MAC entity may determine, by considering multiple configured authorizations (e.g., multiple configured higher-layer communications) and / or downlink control information, whether the PH value of the activated serving cell is based on actual transmission or reference format. This configured authorization and / or downlink control information may be received before and including the timing of the first UL authorization PDCCH for a new transmission that can accommodate a MAC CE (e.g., due to Logical Channel Prioritization (LCP)) that has been received because the PHR has been triggered, for example, if the PHR MAC CE is reported on an uplink authorization received on the PDCCH or before the first uplink symbol of the PUSCH transmission minus the PUSCH preparation time (e.g., if the PHR MAC CE is reported on a configured authorization).

[0112] In one instance, the WTRU may consider authorization valid when it occurs between the PHR triggering and, for example, when the WTRU monitors or receives authorization (e.g., UL authorization) of the PUSCH in which the WTRU transmits or can transmit the PHR (e.g., the PHR associated with the PHR triggering) (e.g., PDCCH monitoring timing). In one instance, the time between triggering and monitoring may include at the time of triggering and / or at the time of monitoring.

[0113] For example, when the WTRU receives authorizations (e.g., UL authorizations) for N (e.g., 2) TRPs, the WTRU may include the actual PH of at least one of the N TRPs (e.g., each of them), for example, when the multiple TRP authorizations are received at or after the PHR trigger occurs (e.g., since the PHR trigger occurred) and before or at the time when the WTRU monitors or receives authorizations (e.g., UL authorizations) for the PUSCH in which the WTRU can transmit the PHR (e.g., the PHR associated with the PHR trigger) (or PDCCH timing).

[0114] In one instance, the WTRU may include virtual authorization of at least one of N TRPs (e.g., each of them), for example, when multiple TRP authorizations are received before a PHR trigger occurs or after the WTRU detects or receives authorization (e.g., UL authorization) of a PUSCH in which the WTRU can transmit the PHR (e.g., the PHR associated with the PHR trigger) (or PDCCH timing).

[0115] In one instance, the time between two events or timings can include the time of one or more of the events or timings. In one instance, an event may be triggered by a PHR. In one instance, an event may be monitoring or receiving authorization. In one instance, a time may be a timing event. In one instance, a timing event may be, for example, a PDCCH timing event used to monitor or receive authorization.

[0116] Figure 4 illustrates an example transmission to multiple TRPs and multiple cells. In one example shown in Figure 4, transmissions may be sent to two TRPs. In one example, the WTRU may communicate with a first cell and a second cell (e.g., transmit to and / or receive from the first cell and the second cell). In the examples and embodiments described herein, the use of two TRPs and two cells is a non-limiting example. Any number of TRPs and cells may be used and remain consistent with this disclosure. In one example, Cell1 TRP1 PUSCH1 and Cell1 TRP2 PUSCH1 may be transmitted by the WTRU based on a received 2-TRP grant for Cell1 or two single TRP grants (one grant for TRP1 and the other for TRP2). In one example, Cell1 TRP1 PUSCH1, Cell1 TRP2 PUSCH1, Cell1 TRP PUSCH2, and Cell1 TRP PUSCH2 may be transmitted by the WTRU based on repeated 2-TRP grants. In one instance, TRP1 PUSCH1 and TRP2 PUSCH1 can carry the same TB or different TBs. In one instance, PUSCH1 and PUSCH2 can carry the same or different TBs.

[0117] In one embodiment, the mode determination rule can be specified as, for example, a single report or a per-TRP PHR report rule. In one instance, a WTRU configured for mTRP transmission can indicate its capability to report more than one PH level. For example, the WTRU can report one PH level per TRP. In one instance, if configured for mTRP transmission, a WTRU capable of reporting more than one PH level can receive a configuration to send a single or multiple PH levels. In one instance, if configured for mTRP, a WTRU capable of reporting more than one PH level can determine the PHR reporting operating mode based on other system parameters or operating modes, characteristics, and / or similar factors. For example, the operating mode can be determined based on at least one of the following: path loss difference, PHR difference, frequency mapping, intra-slot or inter-slot repetition, PUSCH / PUCCH multiplexing, phr-ProhibitTimer, phr-PeriodicTimer, mpe-ProhibitTimer, and / or initial or retransmission.

[0118] In one embodiment, the operating mode can be determined based on the path loss difference. In one example, the WTRU can be configured with more than one path loss RS group, where each RS group can be used for path loss measurement of different TRP links (e.g., PL1 and PL2). In one embodiment, the WTRU can determine the operating mode based on whether the difference between the measured path losses of each RS group is greater than a fixed or configured threshold. In one example embodiment, if the difference between the measured path losses of PL1 and PL2 is less than the threshold, the WTRU can determine a single PHR report; otherwise, it can determine a per-TRP PHR report.

[0119] In one embodiment, the operating mode can be determined based on the difference in PHRs. In one instance, the WTRU can be configured to calculate more than one pH level. In one instance, the WTRU can determine to report one or more pH levels. In one instance, the WTRU can determine to report only one of the multiple pH levels. In one embodiment, the WTRU can determine the operating mode based on whether the difference between the calculated PHRs of each RS group is greater than a fixed or configured threshold. In one example embodiment, if the difference between the calculated PHR1 and PHR2 is less than the threshold, the WTRU can determine a single PHR report; otherwise, it can determine a PHR report per TRP.

[0120] In one embodiment, the operating mode can be determined based on frequency mapping. In one example, a WTRU configured for uplink mTRP transmission can determine the operating mode based on the frequency mapping of each transmission. In one example, if the frequency separation between scheduled transmission mappings is less than a threshold, the WTRU can determine a single PHR reporting mode, where the threshold can be fixed, configured, and / or derived from other system parameters or operating modes. In one example, if the frequency separation between scheduled transmission mappings is greater than a threshold, the WTRU can determine a per-TRP PHR reporting mode.

[0121] In one embodiment, the operating mode can be determined based on intra-slot or inter-slot repetition. In one example, a WTRU configured for uplink mTRP transmission can determine the operating mode based on whether the configured repetition module is intra-slot or inter-slot. In one example embodiment, if inter-slot repetition is used, the WTRU can determine a single PHR report mode. In another embodiment, if the configured repetition mode is inter-slot, the WTRU can determine a single PHR report.

[0122] In one embodiment, the operating mode can be determined based on PUSCH / PUCCH multiplexing. In one example, the WTRU can determine the PHR reporting mode based on whether the PUCCH payload is multiplexed with scheduled PUSCH transmission. In one example embodiment, if the PUCCH payload is multiplexed with scheduled PUSCH transmission, the WTRU can determine a single PHR reporting mode. In one example, if the PUCCH payload is multiplexed with scheduled PUSCH transmission, the WTRU can determine the per-TRP PHR reporting mode.

[0123] In one embodiment, the operating mode can be determined based on phr-ProhibitTimer. In one embodiment, the WTRU can be configured with more than one phr-ProhibitTimer, for example, phr-ProhibitTimer1 and phr-ProhibitTimer2, wherein each timer can be assigned to transmissions to different TRPs (e.g., TRP1 and TRP2). In one instance, the WTRU can determine per-TRP PHR reporting if two phr-ProhibitTimers have expired or are expired and / or the path loss of each link has changed more than a fixed or configured threshold. In one instance, the WTRU can determine per-TRP PHR reporting if two phr-ProhibitTimers have expired or are expired and / or when the MAC entity has sufficient UL resources for new transmissions including two PHR reports. In one instance, if the MAC entity does not have sufficient UL resources, the WTRU can determine a single PHR reporting mode.

[0124] In one embodiment, the operating mode can be determined based on the phr-PeriodicTimer. In one instance, the WTRU can be configured to have more than one phr-PeriodicTimer, such as phr-PeriodicTimer 1 and phr-PeriodicTimer 2, wherein, for example, each timer can be assigned to transmissions to different TRPs (e.g., TRP1 and TRP2). In one instance, if both phr-PeriodicTimers have expired or have expired, the WTRU can determine the PHR reporting mode for each TRP.

[0125] In one embodiment, the operating mode can be determined based on the mpe-ProhibitTimer. In one embodiment, a WTRU (e.g., a multi-panel WTRU) can be configured to have more than one mpe-ProhibitTimer, such as mpe-ProhibitTimer1 and mpe-ProhibitTimer2, wherein each timer can be assigned to transmissions to different TRPs (e.g., TRP1 and TRP2). In one instance, when mpe-Reporting-FR2 is configured, if neither of the mpe-ProhibitTimers is running, the WTRU can determine a per-TRP "MPE P-MPR" reporting mode. In one instance, if only one of the mpe-ProhibitTimers is not running, the WTRU can determine a single "MPE P-MPR" reporting mode. In one instance, if the WTRU is configured with mpe-Threshold, the measured P-MPR may be equal to or greater than mpe-Threshold because the last transmission corresponds to the TRP link, and / or the change in the measured P-MPR may be greater than the configured threshold because the PHR is caused by the measured P-MPR corresponding to the last transmission of the TRP link.

[0126] In one embodiment, the operating mode can be determined based on the initial transmission or retransmission. In one example, the WTRU can be configured to perform simultaneous PUSCH transmission operations with mTRP, where, for example, each PUSCH payload may correspond to a different MAC entity. In one embodiment, the WTRU can determine the PHR reporting mode based on whether the PUSCH transmission for each TRP link corresponds to the initial transmission. In one embodiment, if only one PUSCH transmission is related to the initial transmission, the WTRU can determine a single PHR report. In one embodiment, if both PUSCH transmissions are related to two new initial transmissions, the WTRU can determine multiple PHR reports.

[0127] In one embodiment, multiple transmission / TRP grants may be received prior to PHR triggering for use in subsequent transmissions(s) after triggering. In one embodiment, when the WTRU receives DL control information (e.g., UL grants) for multiple transmissions (e.g., multiple TRP transmissions or repeated transmissions) on a cell (e.g., a serving cell after activation) before a PHR triggering that results in one or more PUSCH transmissions and / or after receiving grants for PUSCHs capable of carrying PHRs (e.g., after the PDCCH monitoring timing of the grant), the WTRU may consider the DL control information and / or may report at least one actual PH associated with the DL control information.

[0128] Referring to Figure 3, in one example, the WTRU may receive multiple TRP grants for Cell 1 at time 1, such as a 2-TRP grant. A PHR may be triggered at time 2. In one example, the WTRU may receive a grant for Cell 2 at time t2a, such as a single TRP grant, where resources for the TRPA PUSCH are available for the new transport. In one example, the WTRU may include the PHR in the TB, such as in a TRPA PUSCH transport. In one example, the PHR may include PH information for both Cell 1 and Cell 2. In one example, the WTRU may include the actual PH for Cell 2 (e.g., since the TRPA PUSCH is carrying the PHR or when the TRPA PUSCH is carrying the PHR). In one example, the WTRU may include the actual PH for Cell 1 (e.g., for Cell 1 TRP1 and / or Cell 1 TRP2). In one instance, the WTRU may consider multiple TRP grants (e.g., when available) because such multiple TRP grants are received before the PHR trigger for one or more transmissions following the PHR trigger and / or after a grant for a PUSCH (e.g., TRPA PUSCH) that can carry the PHR.

[0129] In one embodiment, when the WTRU receives DL control information (e.g., UL authorization) for multiple transmissions (e.g., multiple TRP transmissions or repeated transmissions) on a cell (e.g., a serving cell after activation), the WTRU may consider authorization for transmissions (e.g., actual PH) that occur (or begin) at or after the PHR trigger until the first symbol of the PUSCH transmission carrying the PHR.

[0130] In one instance, the WTRU may include the actual PH in the PHR for a PUSCH transmission corresponding to (e.g., related to, arising from, and / or responding to) an authorization of (multiple) TRPs, an authorization of repeated transmissions, and / or an authorization of multiple transmissions, when one or more of the following conditions occur or are met: at least one PUSCH transmission corresponding to the authorization begins (or ends) at or after the start (e.g., the first symbol) of the PUSCH carrying the PHR (e.g., the first PUSCH); at least one PUSCH transmission corresponding to the authorization ends (or begins) at or after the end (e.g., the last symbol) of the PUSCH carrying the PHR (e.g., the first PUSCH). The last PUSCH transmission of the authorization (e.g., the latest in time) begins (or ends) at or after the start of the PUSCH (e.g., the first PUSCH) carrying the PHR; the last PUSCH transmission of the authorization (e.g., the latest in time) ends (or begins) at or after the end of the PUSCH (e.g., the first PUSCH) carrying the PHR; and / or, at least one PUSCH transmission system (e.g., partially or completely) of the authorization begins or ends in the same slot as the PUSCH (e.g., the first PUSCH) or in at least a portion of the same slot as the PUSCH (e.g., the first PUSCH).

[0131] In one embodiment, at least one PUSCH transmission corresponding to an authorization may correspond to the first authorized PUSCH transmission (e.g., the first PUSCH transmission for a first TRP). In one instance, the first TRP may be the one with the earliest resource in time. In one instance, the first PUSCH transmission may be the earliest transmission in time. In one instance, at least one PUSCH transmission corresponding to an authorization may be the first PUSCH transmission for the Nth TRP corresponding to an authorization of N-TRPs.

[0132] In one embodiment, one or more PUSCH times (e.g., start, end, symbol time) can be adjusted to include or account for processing time (e.g., amount of processing time) before or after that time. For example, the start (or end) of a PUSCH can be modified to include the amount of time (e.g., processing time) before or after the start (or end) of a PUSCH.

[0133] In one instance, PUSCH may be a PUSCH transport. In one instance, if one or more (e.g., all) conditions, including the actual PH in the cell or the TRP in the PHR, are not met, the WTRU may include a virtual PH or a PHR without a cell or a TRP without a PHR.

[0134] In one instance, for an N-TRP grant (e.g., a 2-TRP grant), the WTRU may include the actual PH in the PHR for a PUSCH transmission corresponding to (e.g., related to, arising from, and / or responding to) that grant, when one or more of the following conditions occur or are met: the PUSCH transmission corresponding to or for the first transmission of the Nth TRP begins (or ends) at or after the start (e.g., the first symbol) of the PUSCH carrying the PHR (e.g., the first PUSCH); the PUSCH transmission corresponding to or for the first transmission of the Nth TRP ends (or begins) at or after the end (e.g., the last symbol) of the PUSCH carrying the PHR (e.g., the first PUSCH); the PUSCH transmission corresponding to or for the first transmission of the Nth TRP is (e.g., partially or completely) in the same slot as the PUSCH (e.g., the first PUSCH) or in at least part of the same slot as the PUSCH carrying the PHR or in the same slot. In one instance, the first transmission may be the earliest transmission (e.g., in time).

[0135] In, for example, an embodiment shown in Figure 3, Cell1 TRP2 PUSCH1 may be a PUSCH transmission corresponding to a first transmission to a second TRP. In one instance, which TRP is the first TRP and which is the second TRP can be determined based on the order in which transmissions are sent to the TRPs. In one instance, the second TRP may be the one to which the WTRU is authorized to transmit to the second (e.g., a later TRP transmission). In one instance, the WTRU may include an actual PH for one or more TRPs (e.g., each) corresponding to multiple TRPs authorized, for example, when one or more of the conditions described herein occur or are satisfied. In one instance, the PUSCH carrying the PHR may be at least one of the following: a first PUSCH carrying the PHR, a PUSCH of the initial transmission carrying the PHR, a PUSCH of the initial transmission carrying the TB and the PHR, and / or a PUSCH of the initial transmission carrying the TB and the initial transmission carrying the PHR.

[0136] In one embodiment, a PUSCH may be at least one of the following: a first PUSCH, a PUSCH carrying the initial transmission, and / or a PUSCH carrying the initial transmission of a TB and / or a PHR. In one example, when the WTRU includes the actual PH in a PHR for authorized PUSCH transmissions corresponding to (e.g., associated with, arising from, and / or responding to) multiple TRPs (e.g., N TRPs, where N may be 2), the WTRU may include the actual PH for at least one of the following: each of the N TRPs; the first TRP (e.g., the one with the earliest authorized resource); the TRP with the authorized resource on which the PUSCH with the closest PHR can be transmitted; and / or, the TRP for which the PUSCH transmission (e.g., any PUSCH transmission or the first or earliest) satisfies a PUSCH transmission condition event (e.g., any) TRP. In one instance, a PUSCH transmission may satisfy a PUSCH transmission condition event when one or more of the following occur or are satisfied: the PUSCH transmission begins (or ends) at or after the start (e.g., the first symbol) of the PUSCH carrying the PHR; the PUSCH transmission ends (or begins) at or after the end (e.g., the last symbol) of the PUSCH carrying the PHR; and / or the PUSCH transmission system (e.g., partially or completely) begins or ends in the same slot as the PUSCH (e.g., the first PUSCH) or in at least a portion of the same slot as the PUSCH carrying the PHR or in that same slot.

[0137] In one embodiment, the WTRU may include a virtual PH in a PHR for a TRP associated with or available for a multi-TRP grant when one or more of the following are applied: the TRP is not the first TRP associated with the grant; the TRP is not the first TRP associated with the grant and the PHR is triggered by a P-MPR that is not (or does not include) the TRP; and / or the P-MPR of the TRP has not changed more than a threshold (e.g., a threshold that has been received or configured), for example, since the last PHR transmission, where the PHR may have included the actual PH of the TRP. In one instance, a PUSCH transmission (e.g., a first PUSCH transmission) for a TRP corresponding to a multi-TRP grant may not satisfy a PUSCH transmission condition event.

[0138] In one embodiment, the MAC-CE enhancement can be performed on multiple TPR PHRs. In one instance, a single PHR MAC-CE may include: two octets with a reserved bit; and a 6-bit PH level field, wherein, for example, the 6 bits may be mapped to one of 64 PH levels. In one instance, the WTRU may report a single PH level. In one instance, if the PHR is triggered by two TRPs and / or both TRPs are scheduled for authorization, an enhancement may be added such that the WTRU can report two actual PHRs based on authorization calculations. In one instance, the WTRU may report one or two PHRs.

[0139] In one embodiment, a single PHR MAC-CE can report the PHRs of two TRPs, and in one instance, the network can interpret it as a multi-TRP MAC-CE. In one instance, a single PH level can be reinterpreted as a field representing two independent values. For example, the 6 bits of a PH can be split into two, where, for example, the first 3 bits can correspond to TRP1 and map to a set of 32 PH levels, and the other 3 bits can correspond to TRP2 and map to a set of 32 PH levels. In one instance, if, for example, the WTRU determines to send a multi-TRP MAC-CE, the WTRU can set a reserved bit to 1, and the network can interpret the reserved bit of 1 to indicate, for example, that the 6 bits of the PH value can be mapped to two sets of 32 PH levels. In one instance, a single PH level can be reinterpreted as a field representing a combination of two PH levels. For example, the WTRU can use a single PH level field to report a weighted average of the PH levels of two TRPs.

[0140] In one embodiment, a separate multi-TRP MAC-CE PHR can be defined using its own Logical Channel Identifier (LCID), where, for example, multiple PH level fields of 6 bits can be configured according to the number of RS groups (i.e., TRPs) configured in the WTRU. In one instance, PH levels can be ordered according to RS groups configured (i.e., in a fixed order mapped one-to-one to the group of TRPs) and / or based on, for example, the order of RSs in the DCI implicitly derived from them. For example, a DCI indicating that SRI1 is first and SRI2 is later can indicate that SRI1 is used for the first TRP and SRI2 is used for the second TRP; thus, in one instance, the WTRU can first order the PH to TRP1 in the PHR, and then to the PH to TRP2. In one instance, there can be a fixed number (e.g., 2) of PH level fields, or one per RS ​​group, in which case the variable-sized MAC-CE PHR can be configured with different LCIDs. In one instance, TRP indicator fields may be included in each TRP in the MAC-CE to identify which TRPs' PH level fields are reportable. In one instance, each indicator field may be associated with a PH level field. For example, if the WTRU is configured with two TRPs, the MAC-CE may include two TRP indicator fields that can take values ​​of 1 or 0. In one instance, if the indicator field value is 1, the associated TRP's PH level field may be reported; otherwise, the value may not be reported. In one instance, the WTRU may report the actual PH of a TRP with associated authorization; otherwise, the WTRU may report a dummy PH (e.g., the PH for a TRP that can trigger a PHR but may not be in authorization).

[0141] In one embodiment, if more than one PHR triggers multiple TRPs, the WTRU may determine to include a subset of the PHRs in the MAC-CE. For example, the WTRU may determine that there are not enough PUSCH resources to send more than one PHR. In one instance, the WTRU may use a single PHR to receive a single TRP grant. In one instance, the WTRU may select a subset of PHRs based on one or more of the following: the lowest RS group (or, i.e., TRP ID); the first SRI in the authorization; the first TRP available for transmission, for example, if the WTRU receives a multi-TRU authorization where the WTRU first sends a PUSCH to TRP1 and then to TRP2, the WTRU may determine to send the PHR for TRP1; the first trigger, for example, if the PHR to TRP1 is triggered before the PHR to TRP2, the WTRU may send the PHR associated with TRP1; LCP priority, for example, different LCPs may define single PHR and multi-PHR MAC-CE, where, for example, a single PHR MAC-CE may have a higher priority than multi-PHR; the TRP in the authorization, for example, if the WTRU is configured to have 3 TRPs that trigger all PHRs, but the authorization is scheduled on TRP1 and TRP2, the WTRU may prioritize sending the PHRs of TRP1 and TRP2 and omit the PHR of TRP3.

[0142] In one embodiment, if the WTRU receives a single TRP grant that triggers a PHR for a TRP not in the grant, the WTRU may include the PHR in the PUSCH transmission for the non-triggering TRP. In one instance, an identifier (e.g., an RS group index) may be included in the PHR MAC-CE. In one instance, when the PHR in the MAC-CE corresponds to a triggering TRP not in the grant, it may be bi-state triggered via reserved bit fields. In one instance, the WTRU may TDM the PHR report. In one instance, the WTRU may send the PHR for a triggering TRP not in the grant on the next available multi-TRP grant. In one instance, the WTRU may send the PHR for a triggering TRP not in the grant to the triggering TRP on the next grant.

[0143] In one instance, PHR reporting in a multi-PUSCH scheduling scenario can be considered. In one scenario, the WTRU can transmit multiple transport blocks (TBs) to multiple TRPs, where multiple TBs can be scheduled via a single control instruction (e.g., via dynamic authorization, such as DCI or configured authorization). In one instance, this scheduling type can be called multi-PUSCH scheduling, where each PUSCH can contain one TB. In one instance, PUSCHs can be transmitted time-domain multisite. In one instance, the WTRU can receive a dynamic indication of the number of TBs scheduled via fields in the control instruction, such as, for example, via an extended TDRA table, where a column of the TDRA table can indicate timing offsets, such as the start and length indicator values ​​(SLIV) for each TB.

[0144] In one example, each TB can be repeated, with each repeat being transmitted to a different TRP. For example, the WTRU can receive control instructions for two TBs scheduled with two repeats. In one example, the WTRU can transmit TB1 with two repeats, where repeat 1 can be sent to TRP1 with spatial filter SRI1, and repeat 2 can be sent to TRP2 with spatial filter SRI2. In another example, the WTRU can transmit TB2, where repeat 1 is sent to TRP1 with spatial filter SRI1, and / or repeat 2 is sent to TRP2 with spatial filter SRI2.

[0145] In one example, the WTRU can receive a configuration with two sets of power control parameters, where, for example, each set can be associated with an SRS calibrating a TRP, and / or each TB sent by the WTRU to the TRP can use the individual power control parameters of the TRP. In one example, the WTRU can determine the power control parameters of each TRP associated with the SRI. For example, the power control parameters can be configured in the SRS-Config of each SRS resource group or SRS resource ID. In one example, the indication of the power control parameters can be dynamically indicated, for example, by a DCI with one or more TPC commands, or by pre-configured parameters including open-loop power control parameters (such as P0, α, or a combination of both).

[0146] In one embodiment, the WTRU may trigger a multi-TRP multi-PUSCH PHR report when it receives a multi-PUSCH scheduling grant that may include multiple SRIs, and / or when one of the PHR triggering conditions (e.g., path loss difference) is met. In one instance, the multiple SRIs may be pre-configured or dynamically indicated (e.g., in a DCI). In one instance, the WTRU may measure the path loss on reference signals associated with SRIs in the same group, where, for example, the group may be associated with TBs. For example, TB1 may be associated with SRI1 and SRI2. In one instance, in a first grant, the WTRU may use SRI1 to transmit TB1, and / or in a second grant, the WTRU may use SRI2 to transmit TB1. In one instance, the WTRU may then measure the path loss difference between the path losses RS associated with SRI1 and SRI2, and / or trigger a PHR if the path loss difference is higher than a threshold. In one instance, the WTRU may use one SRI for multiple TBs for transmission. For example, SRI1 can be used for TB1 and TB2, where TB1 and TB2 can be transmitted in different time instances. In one instance, if the WTRU receives a single grant that indicates the same resource allocation (e.g., frequency resources, such as the number of PRBs) for TB1 and TB2, the WTRU can then calculate and report an actual PHR for both TBs. In another instance, if the single grant indicates different resource allocations for TB1 and TB2, the WTRU can calculate and report two different PHRs, where, for example, each PHR can be used for one TB.

[0147] In one solution, the WTRU can use the mapping between SRI and TB to determine the power control and space filter parameters for each TB and each reuse. In one instance, the mapping can be a dynamic indication in the DCI or configuration (e.g., as part of the PUSCH-ConfigIE). In one instance, the mapping can indicate the association between a TB index and an SRI, or between a repeat of a TB index and an SRI. In one instance, the WTRU can determine that the mapping between TB and SRI is one-to-one. In one instance, the WTRU can use different SRIs for each TB. For example, the WTRU can use SRI1 to send repeats 1 and 2, where SRI1 can be sent to TRP1. In one instance, the WTRU can use a mapping similar to that used for repeats of TB2 with SRI2. For example, the WTRU can transmit TB2, where repeats 1 and 2 can be sent using SRI2.

[0148] Figure 5 illustrates an example of receiving control signals with a mapping configuration. In one example, the mapping configuration may indicate that a first SRI and a second SRI can be mapped to a first repeat and a second repeat, respectively. In one example, the WTRU may determine that a TB can use multiple SRIs. In one example, the same mapping may be applied to all authorized TBs. For example, as shown in Figure 5, the WTRU may receive a control signal containing mapping1. In one example, the WTRU may determine that SRI1 and SRI2 can be mapped to repeat 1 and repeat 2 of the TB, respectively. In one embodiment, the WTRU may receive individual mappings (e.g., mapping1 and mapping2) for each TB. For example, the WTRU may use SRI1 to transmit repeat 1 and repeat 2 of TB1, and repeat 1 of TB2 may be mapped to SRI1 and repeat 2 of TB2 may be mapped to SRI2.

[0149] In one embodiment, the WTRU can determine that the resource groups used for the SRIs of each TB may be different. For example, TB1 may use a first resource group (SRI1, SRI2) and TB2 may use a second resource group (SRI3, SRI4). In one instance, resource groups of different TBs may share some SRIs or may be different.

[0150] In one embodiment, the WTRU can calculate the PHR for each SRI for each TB. In one example, the WTRU can report the PHR values ​​of the same TB associated with the same PHR MAC-CE. In one example, as shown in FIG. 5, the WTRU can calculate the PHR and may include the PHR in a first instance associated with the SRI. In one example, the WTRU may include the PHRs of TB1 and TB2 in a repetition 1 of TB1, which can be calculated using power control parameters associated with SRI1. In one embodiment, in a second repetition, the WTRU may report the PHRs of TB1 and TB2 using SRI2. In one example, the WTRU may transmit TB2 without the burden of the MAC-CE.

[0151] In one embodiment, if multiple SRIs are associated with / configured to a TRP, the WTRU may preferentially include PHRs in the MAC-CE. In one instance, the WTRU may calculate and report a subset of PHR values, which may correspond to, for example, a subset of triggered SRIs and / or TBs. In one instance, the MAC-CE may be of variable length. In one instance, the MAC-CE may include a header, for example, indicating a subset of reported PHR values. For example, the WTRU may determine to include PHRs based on the earliest trigger, based on an SRI index, based on a TB index, and / or a combination of criteria. For example, if the WTRU is configured with three SRIs to TRP1, and SRI1 and SRI2 are triggered before SRI3, then the WTRU may include PHRs for SRI1 and SRI2. Alternatively or in combination, as an example, if, for example, SRI3 is of higher priority (e.g., a TB using SRI3 is a TB for URLLC or high priority traffic), WTRU may include a PHR for SRI3, and / or if TB1 is of higher priority, the PHR may be associated with TB1.

[0152] In one embodiment, the WTRU may determine to send one PHR report per TB. In one instance, the WTRU may include one or more PHR values ​​in the PHR report, wherein, for example, the number of PHR values ​​per TB may be determined based on the number of SRIs mapped to the TB. In one instance, the WTRU may determine to send the PHR in repetition index i (i.e., the WTRU sends the PHR in repetition i of the TB), in one of the first or last repetitions, or using a repetition associated with an SRI (i.e., TRP) (e.g., the WTRU sends the PHR in a transmission with a repetition using SRI1). For example, if the WTRU sends TB1 using two repetitions, and both repetitions use SRI1, then the WTRU may calculate and report one PHR value. In one instance, if one repetition uses SRI1 and the others use SRI2, then the WTRU may calculate and report two PHR values, wherein each PHR value may be associated with an SRI. In one instance, the WTRU may report two values ​​in a PHR MAC-CE in the first repetition of TB1.

[0153] In one instance, if the PHR is triggered for two SRIs, the WTRU can, for example, calculate and report two actual PHR values ​​per TB based on the authorization information received in the control signal. In one instance, if only one SRI is triggered, the WTRU can calculate and report the actual PHR value per TB for the triggered SRI, and can also report the virtual PHR value for the non-triggered SRI. In one instance, the WTRU can calculate and report a single PHR for both the triggered and / or non-triggered SRIs. In one instance, the WTRU can calculate and report a single PHR only for the triggered SRI.

[0154] In one embodiment, the WTRU may determine to send a report to the TRP, wherein, for example, the report may include one or more PHR values ​​corresponding to one or more TBs. For example, the WTRU may send TB1 using SRI1 and send TB2 using SRI2, wherein TB1 and TB2 may use a single authorized schedule (i.e., a multi-PUSCH schedule). In one instance, if a PHR is triggered before authorization or triggers a transmission up to a PUSCH, the WTRU may include the PHR values ​​for SRI1 and SRI2 in a single PHR.

[0155] In one instance, the WTRU may determine whether to include a PHR in a transmission timing, for example, a PUSCH with a specific SRI may be used (e.g., the PHR may be included in the first transmission of a TB using SRI1). In another instance, the WTRU may determine a subsequent timing that can be used for the SRI1 schedule and may include multiple PHRs in the corresponding TB that can be sent using SRI1.

[0156] In one instance, the WTRU may include PHRs in a transport that can be associated with a TB index (e.g., PHRs may be included in a first transport with an SRI for sending TB1). In another instance, the WTRU may determine the next opportunity when the TB1 schedule can be used and may include multiple PHRs of SRI1 in TB1.

[0157] In one embodiment, PHR reporting rules and UL behavior for STxMP can be specified. In one instance, one or more antenna panels can be used to implement and / or determine whether to be used for WTRU. In one instance, each antenna panel can be associated with an RS group (e.g., RS group ID, WTRU panel ID, PL RS group (per TRP), SRS resource group, and / or CORESET group ID, etc.). In this document, antenna panels can be used interchangeably with panel, WTRU antenna panel, WTRU panel, RS group, RS group ID, WTRU panel ID, PL RS group, SRS resource group, and CORESET group ID, while still being consistent with this disclosure.

[0158] In one example, the WTRU panel may correspond to a transmission entity to which independent power control and / or timing control can be applied. In one example, the WTRU panel may include one or more antennas (e.g., antenna array, antenna port, antenna element). In one example, the WTRU panel may be (e.g., specifically) used for either transmission or reception. In one example, the WTRU panel may be used for both transmission and reception purposes (e.g., selectively for one purpose at a time).

[0159] In one instance, when the WTRU employs, supports, or is equipped with multiple panels, the WTRU can use multiple antenna panels to perform transmission / reception. In one embodiment, the WTRU can use multiple antenna panels to perform transmission / reception based on one or more operating modes. In one instance, the WTRU can use multiple antenna panels to perform transmission / reception based on a first operating mode. For example, in the first operating mode, a single WTRU panel can be used each time it is started. In one instance, other WTRU panels can be deactivated, which can reduce WTRU power consumption. In one instance, a certain amount of time may be required to start a deactivated WTRU panel. In one instance, the first operating mode may be referred to as "UL Transmission from a Single WTRU Panel" (TxSP) mode 1.

[0160] In one embodiment, the WTRU can perform transmit / receive using multiple antenna panels based on a second operating mode. For example, in the second operating mode, multiple WTRU panels can be activated (and remain activated), but UL transmission can be performed from a single panel each time. In one instance, the WTRU panel used for UL transmission can be dynamically selected or determined. For example, the WTRU panel index or beam associated with any WTRU panel can be indicated in the DCI of the scheduled uplink transmission. In one instance, fast beam switching across WTRU panels can be achieved; however, for example, moderate WTRU power consumption is required. In one instance, the second operating mode can be referred to as "UL Transmission from a Single WTRU Panel" (TxSP) mode 2.

[0161] In one embodiment, the WTRU can perform transmission / reception using multiple antenna panels based on a third operating mode. For example, in the third operating mode, multiple WTRU panels can be activated (and remain activated), and one or more WTRU panels can be used simultaneously for UL transmission. In one instance, simultaneous Tx transmissions from multiple WTRU panels (to multiple receiving points, e.g., TRPs) are possible to improve UL performance and / or reliability. In one instance, higher UL Tx performance and efficiency can be achieved; however, for example, higher complexity and / or higher WTRU power consumption are required. In one instance, the third operating mode may be referred to as the "Simultaneous UL Transmission from Multiple WTRU Panels" (STxMP) mode. In one instance, when the WTRU enters a power-limited mode, for example due to power category limitations, the third operating mode can be disabled by the gNB. In one instance, this power-limited situation can be indicated by at least a TRP-related PHR = 0 signal, or by a global PH level indicating simultaneous UL transmissions. In one embodiment, the WTRU may perform transmission / reception using multiple antenna panels based on, but not limited to, one or more of the above operating modes.

[0162] In one embodiment, the operating mode for UL transmission using multiple WTRU panels can be determined based on one or more of the following: WTRU capability; higher-level configuration; dynamic indication; and implicit determination. In one embodiment, the operating mode for UL transmission using multiple WTRU panels can be determined based on WTRU capability. For example, the WTRU can indicate the operating modes it supports. In one instance, if the supported operating modes include a single operating mode, the indicated operating mode can be used. In one instance, if the supported operating modes include more than one operating mode, the WTRU can be indicated which operating mode to use. In one embodiment, the operating mode for UL transmission using multiple WTRU panels can be determined based on higher-level configuration. For example, the WTRU can be configured to have operating modes via RRC or MAC-CE (e.g., TxSP mode 1, TxSP mode 2, STxMP mode). In one embodiment, the operating mode for UL transmission using multiple WTRU panels can be determined based on dynamic indication. In one instance, the WTRU can be indicated to use which operating mode for UL transmission by scheduling DCI. In one example, the number of beams indicated in the DCI (e.g., SRI, CRI, or TCI status) can be determined based on the determined operating mode. For example, when TxSP mode 1 or TxSP mode 2 is used for UL transmission, a single beam (e.g., SRI, CRI, or TCI status) can be indicated. For example, when TxSP mode 1 or TxSP mode 2 is not used for UL transmission, more than one beam information can be provided in the scheduled DCI. For example, when TxSP mode 1 or TxSP mode 2 is used for UL transmission, a single beam (e.g., SRI, CRI, or TCI status) can be indicated, and this indication can be a specific bit field in the DCI. In one example, the indication can be an RNTI using the CRC checksum of the DCI. In one example, if a first operating mode is used, a first RNTI can be used; if a second operating mode is used, a second RNTI can be used; and so on. In one example, the operating mode can be associated with the DCI format. For example, a WTRU can monitor one or more DCI formats. In one instance, if the WTRU receives uplink authorization via a first DCI format, it can use the first operating mode; if the WTRU receives uplink authorization via a second DCI format, it can use the second operating mode; and so on.

[0163] In one embodiment, the operating mode for UL transmission using multiple WTRU panels can be determined based on implicit decision. In one example, the WTRU may be configured with a set of beams for UL transmission (e.g., TCI status group, SRI group, CRI group), wherein, for example, the WTRU can be indicated using beams within this set of beams via a DCI. In one example, if the set of beams includes beams associated with a single panel, the WTRU may execute or determine a first operating mode (e.g., TxSP mode 1). In one example, if the set of beams includes beams associated with multiple panels, the WTRU may execute or determine a second operating mode (e.g., TxSP mode 2 or STxMP mode). In one example, if the WTRU is configured with a priority indicator in a DCI (e.g., for URLLC traffic support), the WTRU may execute or determine a first operating mode (e.g., TxSP mode 2 or STxMP mode). In one instance, if the WTRU is not configured with a priority indicator in the DCI (e.g., for URLLC traffic support), the WTRU may execute or determine a second operating mode (e.g., TxSP mode 1).

[0164] In one embodiment, if the UL transmission calibrates multiple TRPs, the PH can be calculated, derived, evaluated, or determined for each TRP. In one embodiment, one or more of the following scenario scenarios may be applied: the PH can be determined independently / separately for each TRP; the PH of a TRP can be reported periodically or based on event-based triggering; and one or more PH types can be used. In one scenario scenario, the PH can be determined independently / separately for each TRP. For example, a first PH can be determined for a first TRP based on a measurement of a reference signal associated with the first TRP, and a second PH can be determined for a second TRP based on a measurement of a reference signal associated with the second TRP. In another scenario scenario, the PH of a TRP can be reported periodically or based on event-based triggering. In another scenario scenario, one or more PH types can be used. In one instance, using a first PH type, the PH can be determined for each TRP (e.g., for the TxSP mode); hereinafter, for example, it may be referred to as PH_TxSP. In one instance, a second PH type is used, where PH can determine multiple TRPs (e.g., for STxMP mode); in the following text, for example, it may be referred to as PH_STxMP.

[0165] In one embodiment, when the STxMP mode is used, determined, or enabled, the WTRU can be configured to determine PH_STxMP based on the transmission power allocated to all beams. For example, PH_STxMP can be determined based on the following equation: P_max – f (P_PUSCH#1, P_PUSCH#2, …), where, for example, P_max (e.g., Pc_max) can be the maximum (allowable) transmission power for the WTRU, P_PUSCH#1 can be the first power value of the scheduled PUSCH to be transmitted (e.g., to the first TRP) from the first WTRU panel or WTRU Panel 1 (based on power control determination), P_PUSCH#2 can be the first power value of the scheduled PUSCH to be transmitted (e.g., to the second TRP) from the second WTRU panel or WTRU Panel 2 (based on power control determination), and so on. In one instance, f(.) can be a function that can be configured (or predefined, or predetermined) for the WTRU.

[0166] In one embodiment, f(.) can be determined based on one or more of the following scenario scenarios. In one scenario scenario, for example, when STxMP-PUSCH is scheduled to WTRU, f(.) can be the sum of the power values ​​of all simultaneously transmitted PUSCHs. In one instance, STxMP-PUSCH can be scheduled to be transmitted from one or more WTRU panels, for example, from both WTRU Panel1 and WTRU Panel2. In one instance, PHR_STxMP can be P_max – (P_PUSCH#1 + P_PUSCH#2). In one instance, P_max can correspond to the sum of the maximum (allowable) transmission power values ​​of all (multiple) (activated) WTRU panels.

[0167] In one instance scenario, for example, when an STxMP-PUSCH is scheduled to a WTRU, f(.) can be a function of the average power value of all simultaneously transmitted PUSCHs, for example, f(.) = avg(.). In one instance, an STxMP-PUSCH can be scheduled to be transmitted from one or more WTRU panels, for example, from both WTRU Panel1 and WTRU Panel2. In one instance, PHR_STxMP can be P_max – avg(P_PUSCH#1, P_PUSCH#2). In one instance, avg(P_PUSCH#1, P_PUSCH#2) can be (P_PUSCH#1 + P_PUSCH#2) / 2. In one instance, P_max can correspond to the average of the maximum (allowable) transmission power value of all (multiple) (activated) WTRU panels.

[0168] In one instance scenario, for example, when an STxMP-PUSCH is scheduled to a WTRU, f(.) can be a weighted average function of the power values ​​of all simultaneously transmitted PUSCHs. In one instance, an STxMP-PUSCH can be scheduled to be transmitted from one or more WTRU panels, for example, from both WTRU Panel1 and WTRU Panel2. In one instance, PHR_STxMP can be P_max – (a*P_PUSCH#1 + b*P_PUSCH#2) / 2, where gNB can configure / indicate a first coefficient value (to be weighted on PUSCH#1) and a second coefficient value (to be weighted on PUSCH#2), etc. In one instance, P_max can correspond to, for example, a weighted average of the maximum (allowable) transmission power values ​​of one or more (activated) WTRU panels (e.g., using the same configured / indicated weighting coefficients for a and b). In one instance, P_max may correspond to, for example, a weighted average of the maximum (allowable) transmission power values ​​of all (multiple) (enabled) WTRU panels (e.g., using the same configured / indicated weighting coefficients for a and b). In one instance, the weighting coefficients for a and b may be, for example, based on an indication update from the gNB, such as via MAC-CE messages or DCI, based on the gNB's efficient network operation policy for WTRU power management across multiple WTRU panels.

[0169] In one embodiment, a PHR that can perform STxMP is used. In one embodiment, one or more PHR types can be used, wherein each PHR type can be associated with a PH type. For example, a first PHR type can correspond to a first PH report type; a second PHR type can correspond to a second PH report type, and so on. In one instance, one or more of the following instance scenarios can be applied.

[0170] In one instance scenario, the PH type can be determined based on one or more of the following: the number of TRPs used or assumed for PH determination; the number of UE panels used or assumed for PH determination; the number of beams used or assumed for PH determination; the number of carrier / bandwidth portions (BWPs) used or assumed for PH determination; and the number of PL values ​​used or assumed for PH determination. In one instance, the PH type can be determined based on the number of TRPs used or assumed for PH determination. For example, a first PH type can be associated with a single TRP to determine the PH, and a second PH type can be associated with more than one TRP. The PH type can be determined based on the number of WTRU panels used or assumed for PH determination. For example, a first PH type can be associated with UL transmissions using a single UL panel each time (e.g., TxSP mode), and a second PH type can be associated with UL transmissions using multiple UL panels each time (e.g., STxMP). In one instance, the PH type can be determined based on the number of beams used or assumed for PH determination. In one instance, the PH type can be determined based on the number of carrier / bandwidth portions (BWPs) used or assumed for PH determination. In another instance, the PH type can be determined based on the number of PL values ​​used or assumed for PH determination. For example, a first PH type can determine PH using a single PL value, while a second PH type can determine PH using more than one PL value.

[0171] In one instance scenario, the WTRU can trigger a PHR based on one or more conditions, and these conditions can be determined based on the PHR type. In one instance, a first set of conditions can be configured, used, or determined for a first PHR type, and a second set of conditions can be configured, used, or determined for a second PHR type. In one instance, a set of conditions may include one or more of the following, and each condition / parameter can be configured or determined independently for a set of conditions: periodicity (e.g., timer expiration); PL gap threshold (e.g., PL value changing since the last PHR transmission); threshold as the PL difference between two UL beams (PL difference); power backoff threshold; P-MPR threshold. In one instance, a set of conditions can be used together regardless of the PHR type. In one instance, one or more conditions / parameters can be configured independently for the PHR type.

[0172] In one embodiment, the gNB may, for example, configure an independent threshold parameter (Thres_PH_STxMP) for the PHR report of the STxMP, separate from the threshold parameter (Thres_PH_TxSP) of the PHR report of the TxSP. In one example, if a first evaluated path loss value (for a TxSP from WTRU panel1) changes by more than Thres_PHR_TxSP, the WTRU may transmit PHR1 (e.g., from WTRU panel1). In one example, if a second evaluated path loss value (for a TxSP from WTRU panel2) changes by more than Thres_PHR_TxSP, the WTRU may transmit PHR2 (e.g., from WTRU panel2), and so on. In one example, if a third evaluated path loss value (for STxMPs from both WTRU panel1 and WTRU panel2) changes by more than Thres_PHR_STxMP, the WTRU may transmit PHR_STxMP (e.g., from both WTRU panel1 and WTRU panel2), and so on. In one instance, the third evaluated path loss value can be determined based on f(first evaluated path loss value, second evaluated path loss value, ...), where f(.) can be a function configured (or predefined, or predetermined) for the WTRU, which can be an additive, averaging, weighted average, and / or similar function.

[0173] In one embodiment, the gNB can be configured with an independent threshold parameter for the PL difference (Delta_Thres_PH_STxMP) used in PHR reporting. In one instance, if the path loss assessment between two beams is poor, the WTRU can trigger a PHR report following the rules for the PHR type (e.g., real, virtual, or composite) as explained herein.

[0174] In one embodiment, the gNB can be configured / indicated a time window value (e.g., a time duration value) within which a third evaluated path loss value can be calculated based on f (the first evaluated path loss value, the second evaluated path loss value, etc.). In one example, the maximum time difference used by the WTRU to obtain one or more of the first evaluated path loss values, the second evaluated path loss values, etc., may not be greater than the time window value, such that, for example, the third evaluated path loss value may not be obtained due to aging. In one example, the maximum time difference used by the WTRU to obtain all the first evaluated path loss values, the second evaluated path loss values, etc., may not be greater than the time window value, such that the third evaluated path loss value may not be obtained due to aging. In one example, the time window value may be predefined or predetermined.

[0175] In one embodiment, the triggering of the PHR for STxMP can be performed. In one instance, the WTRU can trigger one or more PHR types each time. In one instance, the PHR type may include one or more of the following: a first PHR type (e.g., PHR for STxMP mode, PHR_STxMP); a second PHR type (e.g., PHR for TxSP mode, PHR1, PHR2); a third PHR type (e.g., PHR for a WTRU with a single antenna board, PHR), and / or similar.

[0176] In one embodiment, the WTRU may be instructed to report a set of PHR types if one or more of the following conditions are met: the trigger condition meets at least one of the PHR types in the set of PHR types; one or more of the predetermined conditions are met; or the dynamic indication is met.

[0177] In one instance, if the triggering conditions are met, the WTRU can trigger a set of PHR types. For example, if the set of PHR types includes a first PHR type and a second PHR type, and the triggering conditions for the first PHR type are met, even if the second PHR type does not meet the triggering conditions, the WTRU can still trigger PHRs of both the first and second PHR types. In one instance, this set can be configured via higher-level communication. In another instance, this set can be determined based on the WTRU panel configuration (e.g., the number of panels, operating mode, etc.).

[0178] In one instance, the WTRU can trigger a set of PHR types based on one or more predetermined conditions, wherein the predetermined conditions may include at least one of the following: the operating mode used within a time window; the worst (or best) case of the PHR; and the better operating mode. In one instance, the WTRU can trigger a set of PHR types based on one or more predetermined conditions, wherein the predetermined conditions may include operating modes that can be used within a time window. For example, if the WTRU can schedule in a first operating mode (e.g., TxSP mode) and a second operating mode (e.g., STxMP) within a time window (e.g., for X milliseconds), the WTRU can trigger PHRs of both the first and second PHR types. In one instance, if the WTRU can schedule in the first operating mode within a time window, the WTRU can trigger PHRs of the first PHR type. In this document, for example, triggering a PHR may be periodic (e.g., timer expiration).

[0179] In one instance, the WTRU can trigger a set of PHR types based on one or more predetermined conditions, where the predetermined conditions may include the worst (best) case of the PHR. For example, if the WTRU triggers a PHR and multiple PHR types are triggered simultaneously, the WTRU can execute the PHR of a single PHR type (e.g., the best case or the worst case), where the best case may be that the power margin is at its maximum value, and the worst case may be that the power margin is at its minimum value, or vice versa. In one instance, the WTRU can trigger a set of PHR types based on one or more predetermined conditions, where the predetermined conditions may include a preferred operating mode. For example, if the WTRU prefers the STxMP mode based on measurement, the WTRU can trigger the PHR of the PHR type associated with the STxMP mode. For example, if the WTRU prefers the TxSP mode based on measurement, the WTRU can trigger the PHR of the PHR type associated with the TxSP mode. In one instance, the PHR may include information related to the PHR type associated with the triggered PHR. In one instance, the preferred operating mode may be determined based on channel quality, PL, PH level, WTRU power saving level, traffic type, and / or required QoS.

[0180] WTRU can trigger a set of PHR types based on dynamic indications. For example, gNB can instruct (e.g., via DCI) to report one or more PHR types, where the indication includes which PHR types were reported and their associated uplink resource information.

[0181] In one embodiment, the gNB may instruct (or configure) the WTRU to report a combination of {PHR1, PHR_STxMP} in a UL time instance (e.g., UL slot, UL symbol). For example, the gNB may selectively compare the WTRU's remaining power budget between PHR1 and PHR_STxMP (but may not need to compare with PHR2 for various reasons, such as low channel quality from WTRU panel 2 and / or high evaluated Rx interference on the UL signal from WTRU panel 2).

[0182] In one embodiment, the WTRU may be permitted (e.g., configured) to determine the combination, for example, to determine it as a WTRU guidance / initiation scheme. In one instance, the WTRU may compare two or more PH levels (or configured / indicated groups of PH levels) of {PHR_STxMP, PHR1, PHR2, and the like} and determine the combination of {PHR1, PHR_STxMP} reported in the UL time instance, for example, based on pre-configured (or predefined) conditions / rules. In one instance, the WTRU may compare all PH levels (or configured / indicated groups of PH levels) of {PHR_STxMP, PHR1, PHR2, and the like} and determine the combination of {PHR1, PHR_STxMP} reported in the UL time instance, for example, based on pre-configured (or predefined) conditions / rules. In one instance, WTRU may determine, for example, that one or more of the evaluated path loss values ​​of PHR1 and PHR_STxMP have changed more than Thres_PHR_TxSP and Thres_PHR_STxMP, respectively. In one instance, the change in the evaluated path loss value of PHR2 may not exceed Thres_PHR_TxSP. In one instance, WTRU may determine that the changes in both the evaluated path loss values ​​of PHR1 and PHR_STxMP have exceeded Thres_PHR_TxSP and Thres_PHR_STxMP, respectively, but the change in the evaluated path loss value of PHR2 may not exceed Thres_PHR_TxSP.

[0183] In one instance, the gNB can instruct (or configure) the WTRU to report a combination of {PHR1, PHR2, PHR_STxMP} in a UL time instance (e.g., UL slot, UL symbol). In another instance, for example, regarding the gNB's efficiency network operation strategy considering various factors (e.g., radio channel quality, UL interference assessed by the gNB, and the like), the gNB may selectively compare the WTRU's remaining power budget, for example, between PHR1, PHR2, and PHR_STxMP, to determine which UL transmission from the WTRU is of the best benefit.

[0184] In one instance, the WTRU can be permitted (e.g., configured) to determine the combination, for example, to determine it as a WTRU-guided / initiated scheme. In one instance, the WTRU can compare two or more PH levels (or configured / indicated groups of PH levels) of {PHR_STxMP, PHR1, PHR2, and the like) and determine the combination of {PHR1, PH2, PHR_STxMP} reported in the UL time instance, for example, based on pre-configured (or predefined) conditions / rules. In one instance, the WTRU can compare all PH levels (or configured / indicated groups of PH levels) of {PHR_STxMP, PHR1, PHR2, and the like) and determine the combination of {PHR1, PHR2, PHR_STxMP} reported in the UL time instance, for example, based on pre-configured (or predefined) conditions / rules. In one instance, WTRU can determine that the changes in the evaluated path loss values ​​of PHR1, PHR2, and PHR_STxMP exceed Thres_PHR_TxSP, Thres_PHR_TxSP, and Thres_PHR_STxMP, respectively.

[0185] In one instance, independent / separate Thres_PHR_TxSPs can be configured (or predetermined) per WTRU panel (e.g., per RS ​​group, per RS ​​group ID, per WTRU panel ID, per PL RS group (per TRP), per SRS resource group, and / or per CORESET group ID). In one instance, PHR1 can be calculated based on Thres_PHR_TxSP1, and PHR2 can be calculated based on Thres_PHR_TxSP2.

[0186] The following describes examples of UL behavior related to PHR reports on STxMP. In one embodiment, the PHR report type (e.g., in PHR1, PHR2, or PHR_STxMP) may be implicitly determined based on the UL transmission (e.g., PUSCH transmission, most recent PUSCH transmission).

[0187] In one instance, the gNB can schedule the first PUSCH for the WTRU to be transmitted from WTRU Panel1. In one instance, the WTRU can transmit the first PUSCH in the first time instance. In one instance, the WTRU can determine the PHR report type as PHR1 after the first time instance (e.g., where the WTRU only determines PHR1 and not PHR2 / PHR_STxMP) until the type can be further changed. In one instance, the PHR report type (e.g., for PHR1) can be determined based on the most recent PUSCH transmission (e.g., the first PUSCH). In one instance, the benefit of determining the PHR report type may be, for example, reducing the burden and latency of control communications indicating the PHR report type.

[0188] In one instance, the gNB can schedule a second PUSCH for the WTRU to be transmitted as STxMP (e.g., from both WTRU Panel1 and WTRU Panel2). In one instance, the WTRU can transmit the second PUSCH in a second time instance. In one instance, the WTRU can determine the PHR report type after the second time instance whether it can report PHR_STxMP (e.g., where the WTRU only calculates PHR_STxMP and not PHR1 / PHR2) until the type can be further changed. In one instance, the PHR report type (e.g., for PHR_STxMP) can be determined based on the most recent PUSCH transmission (e.g., the second PUSCH). In one instance, the benefit of determining the PHR report type may be, for example, reducing the burden and latency of control communications indicating the PHR report type.

[0189] In one embodiment, the BS can be independently configured (e.g., initiated, indicated) to periodically or irregularly trigger a combination of PHR report types (e.g., among PHR_STxMP, PHR1, PHR2, and the like), while the PHR report type can remain active (e.g., based on implicit PHR report type determination). In one instance, the benefit of the gNB may be to calculate other PH levels when needed, for example, in addition to the PHR report type currently used in the WTRU (e.g., to determine a next UL schedule for the WTRU from (multiple) different UL panels, e.g., using WTRU panel switching).

[0190] In one embodiment, the DCI (e.g., for scheduling PUSCH) may not include a UL panel selection indication. In one example, UL panel selection may be determined based on the latest (or current) PHR report type of the WTRU (e.g., in PRH_STxMP, PHR1, PHR2, ...). In one example, if the current PHR report type is PHR1, the DCI for scheduling the first PUSCH may implicitly indicate that the first PUSCH will be transmitted from UL panel1. In one example, if the current PHR report type is PHR_STxMP, the second DCI for scheduling the second PUSCH may implicitly indicate that the second PUSCH can be transmitted from UL panel2. In one example, the benefit may be to reduce the control burden on (explicitly) indicating which UL panel is used for UL signal transmission, where, for example, UL panel selection may depend on the PHR report type. In one example, the gNB may (explicitly) indicate / update the PHR report type (e.g., in PHR_STxMP, PHR1, PHR2, ...).

[0191] While the features and elements described above are in a specific combination, those skilled in the art will understand that each feature or element can be used alone or in combination with other features and elements. Additionally, the methods described herein can be incorporated into computer-readable media for implementation in computer programs, software, or firmware executed by a computer or processor. Examples of non-transitory computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-RAM discs and digital versatile disks, DVDs). A processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU 102, WTRU, terminal, base station, RNC, or any host computer.

[0192] Furthermore, in the embodiments described above, the terms processing platform, computing system, controller, and other devices containing a processor are mentioned. These devices may contain at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, references to symbolic representations of actions and operations or instructions can be executed by various CPUs and memory. Such actions and operations or instructions may be referred to as “executed,” “computer-executed,” or “CPU-executed.”

[0193] Those skilled in the art will understand that actions and symbolically represented operations or instructions include manipulating electrical signals by the CPU. An electrical system represents the result of which can cause changes or degradation of electrical signals and the maintenance of data bits at memory locations in the memory system, thereby reconfiguring or otherwise altering the operation of the CPU and other signal processing. The memory location maintaining the data bits is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that exemplary embodiments are not limited to the platforms or CPUs mentioned above, and other platforms and CPUs may support the provided methods.

[0194] Data bits may also be stored on computer-readable media, including magnetic disks, optical disks, and any other volatile (e.g., random access memory (“RAM”)) or non-volatile (e.g., read-only memory (“ROM”)) mass storage system readable by the CPU. Computer-readable media may include cooperative or interconnected computer-readable media that exist exclusively on the processing system or are distributed among multiple interconnected processing systems that may be local to or remote from the processing system. It should be understood that representative embodiments are not limited to the memory mentioned above, and other platforms and memories may support the methods described.

[0195] In one illustrative embodiment, any of the operations, procedures, etc., described herein may be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions may be executed by a processor of an action unit, network element, and / or any other computing device.

[0196] There is very little distinction between hardware and software implementations of the system. The purpose of hardware or software is often (but not always; in certain contexts, the choice between hardware and software can become significant) a design choice representing a trade-off between cost and efficiency. Various carriers (e.g., hardware, software, and / or firmware) may exist by which the programs and / or systems and / or other technologies described herein are implemented, and a preferred carrier may vary depending on the context in which the programs and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are paramount, the implementer may choose a carrier that is primarily hardware and / or firmware. If flexibility is paramount, the implementer may choose a primarily software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0197] The foregoing embodiments have been illustrated with various examples of the apparatus and / or program using block diagrams, flowcharts, and / or examples.

[0198] In cases where such block diagrams, flowcharts, and / or examples contain one or more functions and / or operations, those skilled in the art will understand that the functions and / or operations within such block diagrams, flowcharts, or examples can be implemented individually or jointly by various hardware, software, firmware, or any combination thereof. For example, suitable processors include general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application-specific integrated circuits (ASICs), application-specific standard products (ASSPs); field-programmable gate array (FPGA) circuits, any other type of integrated circuit (IC), and / or state machines.

[0199] While features and elements in specific combinations are provided above, those skilled in the art will understand that each feature or element can be used alone or in combination with other features and elements. This disclosure is not intended to be limited to specific embodiments of various forms described in this application. Many modifications and variations can be made without departing from its spirit and scope, which will be apparent to those skilled in the art. Thus, unless explicitly stated otherwise, elements, actions, or instructions used in the description of this application should not be construed as essential or necessary to the invention. In addition to those enumerated herein, functionally equivalent methods and apparatus within the scope of this disclosure will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only to the language of the appended claims, together with the full scope of their equivalents. It should be understood that this disclosure is not limited to any particular method or system.

[0200] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, when referred to herein, the terms "station" and its abbreviation "STA", "user equipment" and its abbreviation "UE" may mean (i) a wireless transmitting and / or receiving unit (WTRU) (as described below); (ii) any of several embodiments of a WTRU (as described below); (iii) a device with wireless and / or wired capabilities (e.g., wired) configured in some or all of the structure and functionality of a WTRU (as described below); (iii) a device with wireless and / or wired capabilities configured in less than all the structure and functionality of a WTRU (as described below); or (iv) similar.

[0201] Details of any WTRU instance that may be represented by this document are provided below in relation to Figures 1A through 1D.

[0202] In some representative embodiments, several portions of the subject matter described herein may be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein may be implemented, in whole or in part, equivalently in integrated circuits as one or more computer programs running on one or more computers (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware, or virtually any combination thereof, and will recognize that designing the circuit system and / or writing the code for the software and / or firmware will be entirely within the skill of those skilled in the art to which this disclosure pertains. Additionally, those skilled in the art will understand that the mechanisms of the subject matter disclosed herein can be distributed as program products in various forms, and will understand that the illustrative embodiments of the subject matter disclosed herein are applied independently of the specific type of signal-bearing media used for actual implementation. Examples of signal-carrying media include, but are not limited to, the following: recordable media (such as floppy disks, hard disk drives, CDs, DVDs, digital magnetic tapes, computer memory, etc.) and transmission media (such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.)).

[0203] The objects described herein sometimes refer to different components contained within or connected to such other components. It should be understood that the architectures depicted are merely examples, and in fact, many other architectures can be implemented to achieve the same functionality. Conceptually, any configuration of components achieving the same functionality is effectively "associated" so that the desired functionality can be achieved. Therefore, any two components in this document that are combined to achieve a particular functionality can be considered "associated with" each other, so that the desired functionality can be achieved regardless of the architecture or intermediate components. Similarly, any two such associated components can be considered "operably connected" or "operably coupled" with each other to achieve the desired functionality, and any two components that can be suchly associated can be considered "operably coupled" with each other to achieve the desired functionality. Specific examples of operable coupling include, but are not limited to, components that can be physically paired and / or physically interact and / or wirelessly interact and / or logically interact and / or logically interact.

[0204] Regarding the use of any substantial plural and / or singular terms in this document, those skilled in the art can appropriately convert from plural to singular and / or from singular to plural forms depending on the context and / or application. For clarity, various singular / plural arrangements are explicitly described herein.

[0205] Those skilled in the art will understand that the terms used herein and particularly in the appended claims (e.g., the subject of the appended claims) are generally intended to be "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "include" should be interpreted as "includes but not limited to," etc.). Those skilled in the art will further understand that if a specific number described in the introduced claim is intentional, this intention will be explicitly stated in the claim, and the absence of such a statement indicates the absence of such intention. For example, the term "single" or similar language may be used when a single item is anticipated. For further understanding, the appended claims and / or the description herein may contain the introductory phrases "at least one" and "one or more" to introduce the claim description. However, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles (such as "a" or "an" (e.g., "a" or "an" should be interpreted as meaning "at least one" or "one or more")), the use of such phrases should not be interpreted as meaning that the claim statement introduced by the indefinite article "a" or "an" limits any particular claim containing such an introductory claim statement to an embodiment containing only one such statement. This is also true for the use of definite articles used to introduce claim statements. Furthermore, even if a specific number of claim statements is explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as meaning at least that number of statements (e.g., a bare recitation of "two statements" without other modifiers means at least two statements, or two or more statements).

[0206] Furthermore, in cases where a convention similar to "at least one of A, B, and C, etc." is used, this construction is generally intended to make the convention understandable to those with ordinary knowledge in the art (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having A and B together, having A and C together, having B and C together, and / or having A, B, and C together). In cases where conventions such as "at least one of A, B, or C" are used, this construction is generally intended to be understood to a degree that a person skilled in the art would grasp the convention (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having A and B together, having A and C together, having B and C together, and / or having A, B, and C together). A person skilled in the art will further understand that any transitional word or phrase presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to imply the possibility of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" would be understood to include the possibility of "A" or "B" or "A and B". Furthermore, as used herein, the term "any of" following a list of multiple items and / or multiple categories of items is intended to individually or in combination with other items or categories of items to include "any of," "any combination of," "any multiple of," and / or "any combination of multiples of." Additionally, as used herein, the terms "set" or "group" are intended to include any number (including zero) of items. Furthermore, as used herein, the term "number" is intended to include any number (including zero).

[0207] Furthermore, since the features or characteristics of this disclosure are described in accordance with the Markush group, those skilled in the art will recognize that this disclosure is also described in accordance with any individual member or subgroup of the Markush group.

[0208] As will be understood by one of ordinary skill in the art, for any and all purposes, such as providing a written description, all scopes disclosed herein also encompass any and all possible subscopes and combinations thereof. Any listed scope can be readily considered sufficient to describe and enable the decomposition of the same scope into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, the scopes discussed herein can be readily decomposed into the lower third, middle third, and upper third, etc. Also, as will be understood by one of ordinary skill in the art, all language such as "up to," "at least," "greater than," "less than," and the like includes the stated numbers and can refer to a scope that can subsequently be decomposed into subscopes as discussed above. Finally, as will be understood by one of ordinary skill in the art, a scope includes individual members. Thus, for example, a group having 1 to 3 subscopes refers to multiple groups having 1, 2, or 3 subscopes. Similarly, a group having 1 to 5 cells refers to multiple groups having 1, 2, 3, 4, or 5 cells, and so on.

[0209] Furthermore, unless the effect is stated, the scope of the patent application should not be interpreted as limited to the order or elements provided. Additionally, the use of the phrase "means for" in any claim is intended to invoke 35 USC §112, ¶ 6 or the means-plus-function claim format, and any claim without the phrase "means for" is not intended to do so.

[0210] Although the invention has been described and illustrated herein with reference to specific embodiments, it is not intended to be limited to the details shown. Rather, various modifications to the details may be made within the scope and within the equivalents of the claims and without departing from the invention.

[0211] Throughout this disclosure, those skilled in the art will understand that certain representative embodiments may be used in alternative embodiments or in combination with other representative embodiments.

[0212] While the features and elements described above are in a specific combination, those skilled in the art will understand that each feature or element can be used alone or in combination with other features and elements. Additionally, the methods described herein can be incorporated into computer-readable media for implementation in computer programs, software, or firmware executed by a computer or processor. Examples of non-transitory computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-RAM discs and digital versatile disks, DVDs). A processor associated with the software can be used to implement radio frequency transceivers for use in UEs, WTRUs, terminals, base stations, RNCs, or any host computer.

[0213] Furthermore, in the embodiments described above, the terms processing platform, computing system, controller, and other devices containing a processor are mentioned. These devices may contain at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, references to symbolic representations of actions and operations or instructions can be executed by various CPUs and memory. Such actions and operations or instructions may be referred to as “executed,” “computer-executed,” or “CPU-executed.”

[0214] Those skilled in the art will understand that actions and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. An electrical system represents the maintenance of data bits at memory locations within a memory system, which can result in changes or degradation of electrical signals, thereby reconfiguring or otherwise altering CPU operations and other signal processing. The memory locations that maintain data bits are physical locations having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits.

[0215] Data bits may also be stored on computer-readable media, including magnetic disks, optical disks, and any other volatile (e.g., random access memory (“RAM”)) or non-volatile (e.g., read-only memory (“ROM”)) mass storage systems readable by a CPU. Computer-readable media may include collaborative or interconnected computer-readable media that exist exclusively on a processing system or are distributed across multiple interconnected processing systems, either locally or remotely. It should be understood that representative embodiments are not limited to the memory mentioned above, and other platforms and memories may support the methods described.

[0216] Therefore, unless explicitly described, elements, actions, or instructions used in the description of this application should not be construed as critical or necessary to the invention. Furthermore, as used herein, the article "a" is intended to include one or more items. The term "one" or similar language may be used to refer to only one item. Further, as used herein, the term "any of," followed by a list of multiple items and / or multiple categories of items, is intended to individually or in combination with other items or categories of items to include "any of," "any combination of," "any multiple of," and / or "any combination of multiples of" of such items and / or categories of items.

[0217] Furthermore, as used herein, the term "set" is intended to include any number of items (including zero). Furthermore, as used herein, the term "number" is intended to include any number (including zero).

[0218] Furthermore, unless such effect is stated, the scope of the patent application should not be construed as limited to the order or elements described. Additionally, the use of the term "means" in any claim is intended to invoke 35 USC §112, ¶ 6, and any claim that does not use the term "means" is not intended to do so.

[0219] For example, suitable processors include general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), field-programmable gate arrays (FPGAs), any other type of integrated circuit (IC), and / or state machines.

[0220] The processor associated with the software can be used to implement a Wireless Transmitter Receiver Unit (WTRU), User Equipment (UE), terminal, base station, Mobile Management Entity (MME), or Evolved Packet Core (EPC), or any radio frequency transceiver used in a host computer. The WTRU can be used in conjunction with modules and other components implemented in hardware and / or software (including Software Defined Radio (SDR)), such as cameras, video cameras, video phones, speakerphones, vibration devices, speakers, microphones, television transceivers, hands-free headsets, keyboards, Bluetooth® modules, FM radio units, Near Field Communication (NFC) modules, Liquid Crystal Display (LCD) units, Organic Light Emitting Diode (OLED) units, digital music players, media players, video game player modules, Internet browsers, and / or any Wireless Local Area Network (WLAN) or Ultra Wideband (UWB) modules.

[0221] Although the present invention has been described in relation to a communication system, it is envisioned that the system can be implemented in software on a microprocessor / general-purpose computer (not shown). In some embodiments, the functions of one or more of the various components can control the software implementation on the general-purpose computer.

[0222] Furthermore, although the invention has been described and illustrated herein with reference to specific embodiments, it is not intended to be limited to the details shown. Rather, various modifications to the details may be made within the scope and equivalents of the claims and without departing from the invention.

[0223] 100: Communication System 102:WTRU 102a: Wireless Transmit / Receive Unit (WTRU) 102b: Wireless Transmit / Receive Unit (WTRU) 102c: Wireless Transmit / Receive Unit (WTRU) 102d: Wireless Transmit / Receive Unit (WTRU) 104: Radio Access Network (RAN) 106: Core Network (CN) 108: Public Switched Telephone Network (PSTN) 110: Internet 112: Internet 114a: Base Station 114b: Base Station 116: Empty Intermediate Surface 118: Processor 120: Transceiver 122: Transmit / receive element 124: Speaker / Microphone 126: Numeric keypad 128: Monitor / Touchpad 130: Non-removable memory 132: Removable Memory 134: Power Supply 136: Global Positioning System (GPS) Chipset 138: Peripheral Equipment 160a:eNode-B 160b:eNode-B 160c:eNode-B 162: Management Mobility Interface (MME) 164: Service Gateway (SGW) 166: Packet Data Network Gateway 180a:gNB 180b:gNB 180c:gNB 182a: Access and Mobility Management Function (AMF) 182b: Access and Mobility Management Function (AMF) 183a: Conversation Management Function (SMF) 183b: Conversation Management Function (SMF) 184a: User Plane Function (UPF) 184b: User Plane Function (UPF) 185a: Data Network (DN) 185b: Data Network (DN) N2: Interface N3: Interface N4: Interface N6: Interface N11: Interface S1: Interface X2: Interface Xn: Interface

Claims

1. A wireless transmit / receive unit (WTRU) including a processor configured to: transmit capability information indicating that the WTRU is configured to support simultaneous multi-panel (SMP) transmission; determine that a power headroom report (PHR) has been triggered; receive downlink control information (DCI) including uplink grant information, the DCI indicating a multi-panel (MP) operating mode; determine one or more power headroom (PH) values ​​of the PHR, wherein the one or more PH values ​​are determined at least based on the multi-panel operating mode indicated in the DCI and whether the PHR is triggered based on an SMP path loss (PL) determination; and transmit the PHR including the one or more PH values.

2. As in Request 1's WTRU, one of the SMP PL values ​​is determined based on a weighted average of the PLs associated with the SMP transmission.

3. WTRU as in request item 1 or 2, wherein the PHR trigger is based at least on a single panel PHR trigger, and the one or more PH values ​​include a first PH value for a panel associated with the single panel PHR trigger and a second PH value associated with SMP operation.

4. WTRU as in request item 1, wherein the PHR is triggered based on a difference between a current SMP PL value and a last SMP PL value that is higher than a threshold.

5. WTRU as requested in item 1, wherein the MP operation mode includes single active panel, dynamic panel selection, and SMP.

6. WTRU as requested in item 5, wherein the one or more pH values ​​include a first pH value for a first panel and a second pH value for a second panel, based on the multi-panel operation mode being dynamically selected.

7. The WTRU of Request 1 is further configured to indicate the MP operating mode for each PHR value in the Uplink Shared Channel (PUSCH) of an authorized entity.

8. The WTRU of request item 1, wherein the PHR containing one or more PH values ​​further includes an SRS Resource Indicator (SRI) mapped to a Transport Block (TB) and a joint report of multiple PHRs or SRIs.

9. The WTRU of request item 1 is further configured to trigger rules for each RS group used for multiple TRPs based on at least one of PL, P-MPR, and the PL difference between reference signal (RS) groups.

10. The WTRU of request item 1, wherein the PHR is sent based on intra-cell and inter-cell conditions, wherein the intra-cell and inter-cell conditions include: a multiple transmit and receive point (mTRP) mode determination, a single-to-multiple PH level report, and enhanced Media Access Control – Control Element (MAC-CE).

11. The WTRU of request item 1, wherein the PHR is in a simultaneous UL multi-panel (STxMP) transmission to a multi-transmit and receive point (mTRP).

12. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: transmitting capability information indicating that the WTRU is configured to support simultaneous multi-panel (SMP) transmission; determining that a power headroom report (PHR) has been triggered; receiving downlink control information (DCI) including uplink grant information, the DCI indicating a multi-panel (MP) operating mode; determining one or more pH values ​​of the PHR, wherein the one or more pH values ​​are determined at least based on the multi-panel operating mode indicated in the DCI and whether the PHR is triggered based on an SMP path loss (PL) determination; and transmitting the PHR including the one or more pH values.

13. The method of request 12, wherein an SMP PL value is determined based on a weighted average of PLs associated with the SMP transmission.

14. The method of request item 12, wherein the PHR trigger is based at least on a single panel PHR trigger, and the one or more PH values ​​include a first PH value for a panel associated with the single panel PHR trigger and a second PH value associated with SMP operation.

15. The method of request item 12, wherein the PHR is triggered based on a difference between a current SMP PL value and a last SMP PL value that is higher than a threshold.

16. The method of request item 12, wherein the MP operation mode includes a single active panel, dynamic panel selection, and SMP.

17. The method of claim 12, wherein the one or more pH values ​​include a first pH value for a first panel and a second pH value for a second panel based on the multi-panel operation mode being dynamically selected.

18. The method of request item 12, wherein the PHR includes an indication of the MP operating mode for each PHR value in an authorized entity uplink shared channel (PUSCH).

19. The method of request item 12, which includes the PHR of one or more PH values, further includes an SRS resource indicator (SRI) mapped to a transport block (TB) and a joint report of multiple PHRs or SRIs.

20. The method of claim 12, further comprising triggering one or more rules for each RS group used for multiple TRP based on at least one of the PL, P-MPR, and PL difference between reference signal (RS) groups.

21. The method of request item 12, wherein the transmission of the PHR is based on intra-cell and inter-cell conditions, wherein the intra-cell and inter-cell conditions include: a multiple transmit and receive point (mTRP) mode determination, a single-to-multiple PH level report, and Media Access Control – Control Element (MAC-CE) enhancement.

22. The method of claim 12, wherein the PHR is transmitted in a simultaneous UL multi-panel (STxMP) transmission to a multi-transmit and receive point (mTRP).

Images