Default spatial relationship for uplink transmission

Abstract

Systems, devices, and methods are described that enable multi-TRP operation with single DCI and multiple DCIs. A single DCI or multiple DCIs are used for PUCCH, PUSCH, and SRS transmissions for a TRP. A spatial relationship is provided between CORESET reception and PUCCH / PUSCH transmission or SRS repetition. Associations are defined at various levels, with default spatial relationships indicated by RRC signaling.

Description

Technical Field

[0001] [Priority Claim] This application claims the benefit of priority to PCT Patent Application No. PCT / CN2020 / 101015, filed on July 9, 2020; PCT Patent Application No. PCT / CN2020 / 101784, filed on July 14, 2020; PCT Patent Application No. PCT / CN2020 / 102957, filed on July 20, 2020; and PCT Patent Application No. PCT / CN2020 / 102993, filed on July 20, 2020, the entire contents of each of which are incorporated by reference herein.

[0002] [Technical Field] Embodiments relate to wireless communication in a 5th Generation (5G) / New Radio (NR) system. Some examples relate to multi-Transmission / Reception Point (TRP) operation in a 5G system.

Background Art

[0003] The use and complexity of 3GPP LTE systems (including LTE and LTE-Advanced systems) have increased due to both an increase in the types of user equipment (UE) devices using network resources and an increase in the amount of data and bandwidth used by various applications such as video streaming operating on these UEs. With a significant increase in the number and diversity of communication devices, especially with the emergence of 5G systems, the corresponding network environment, including routers, switches, bridges, gateways, firewalls, and load balancers, is becoming increasingly complex. As expected, with the emergence of new technologies, many problems have piled up.

Brief Description of the Drawings

[0004] In the drawings, although not necessarily drawn to scale, like reference numerals in different drawings may describe like components. Like reference numerals with different suffixes may represent different instances of like components. These drawings generally illustrate, by way of example and not limitation, the various embodiments discussed in this document.

Figure 1A

Figure 1B

Figure 1C

Figure 2

Figure 3A

Figure 3B

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Figure 25

[0005] The following description and drawings fully disclose specific embodiments so that those skilled in the art can implement them. Other embodiments may incorporate structural, logical, electrical, process, and other changes. Parts and features of some embodiments may be included in or substituted for parts and features of other embodiments. The embodiments recited in the claims include all available equivalents of the claims.

[0006] FIG. 1A shows the architecture of a network according to some aspects. Network 140A includes 3GPP LTE / 4G and NG network functions. The network functions can be implemented as individual network elements on dedicated hardware, software instances running on dedicated hardware, and / or virtualized functions instantiated on a suitable platform, such as dedicated hardware or cloud infrastructure.

[0007] Network 140A is shown as including user equipment (UE) 101 and UE 102. UE 101 and 102 are shown as smartphones (e.g., handheld touch screen mobile computing devices connectable to one or more cellular networks), but may include any mobile or non-mobile computing device such as a portable (laptop) or desktop computer, a wireless handset, a drone, or other computing devices including wired and / or wireless communication interfaces. UE 101 and 102 may here be collectively referred to as UE 101, and UE 101 can be used to execute one or more of the technologies disclosed herein.

[0008] Any of the wireless links described herein (e.g., used in Network 140A or other illustrated networks) may operate according to any exemplary wireless communication technology and / or standard. Any spectrum management scheme may include, for example, dedicated licensed spectrum, unlicensed spectrum, (licensed) shared spectrum (licensed shared access (LSA) at 2.3 - 2.4 GHz, 3.4 - 3.6 GHz, 3.6 - 3.8 GHz and other frequencies, and spectrum access system (SAS) at 3.55 - 3.7 GHz and other frequencies, etc.). Different single carrier or orthogonal frequency division multiplexing (OFDM) modes (CP - OFDM, SC - FDMA, SC - OFDM, filter bank - based multicarrier (FBMC), OFDMA, etc.), particularly 3GPP NR, may be used by allocating OFDM carrier data bit vectors to corresponding symbol resources.

[0009] In some aspects, either UE101 or UE102 can include an Internet-of-Things (IoT) UE or a Cellular IoT (CIoT) UE, which can include a network access layer designed for low-power IoT applications that utilize short-term UE connections. In some aspects, either UE101 or UE102 can include a narrowband (NB) IoT UE (e.g., an eNB-IoT (Enhanced NB-IoT) UE and a FeNB-IoT (Further Enhanced) UE, etc.). The IoT UE can utilize technologies such as machine-to-machine (M2M) or machine-type communications (MTC) to exchange data with an MTC server or device via a public land mobile network (PLMN), proximity-based service (ProSe), or device-to-device (D2D) communication, a sensor network, or an IoT network. The M2M or MTC data exchange can also be a data exchange initiated by a machine. The IoT network includes interconnecting IoT UEs that may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-term connections. The IoT UE may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate the connection to the IoT network. In some aspects, either UE101 or UE102 can include an enhanced MTC (eMTC) UE or a further enhanced MTC (FeMTC) UE.

[0010] UEs 101 and 102 may be configured to be communicatively coupled, for example, to connect to a radio access network (RAN) 110. The RAN 110 may be, for example, an E-UTRAN (Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network), an NG RAN (NextGen RAN), or some other type of RAN.

[0011] UEs 101 and 102 each utilize connections 103 and 104, each of connections 103 and 104 including a physical communication interface or layer (described in more detail below). In this example, connections 103 and 104 are shown as air interfaces to enable a communication coupling and may be compliant with cellular communication protocols such as the GSM (Global System for Mobile Communications) protocol, the CDMA (code-division multiple access) network protocol, the PTT (Push-to-Talk) protocol, the POC (PTT over Cellular) protocol, the UMTS (Universal Mobile Telecommunications System) protocol, the 3GPP LTE (Long Term Evolution) protocol, the fifth-generation (5G) protocol, the NR (New Radio) protocol, and the like.

[0012] In one aspect, UE101 and UE102 may further directly exchange communication data via the ProSe interface 105. The ProSe interface 105 may alternatively be referred to as a sidelink (SL) interface including one or more logical channels including, but not limited to, a Physical Sidelink Control Channel (PSCCH), a Physical Sidelink Shared Channel (PSSCH), a Physical Sidelink Discovery Channel (PSDCH), a Physical Sidelink Broadcast Channel (PSBCH), and a Physical Sidelink Feedback Channel (PSFCH).

[0013] UE102 is shown to be configured to access an access point (AP) 106 via a connection 107. The connection 107 can include a local wireless connection, such as a connection compliant with any IEEE802.11 protocol, and accordingly, the AP106 can include a wireless fidelity (WiFi) router. In this example, the AP106 is shown to be connected to the Internet without being connected to the core network of the wireless system (to be described in more detail below).

[0014] RAN 110 can include one or more access nodes enabling connections 103 and 104. These access nodes (AN) can be called base stations (BS), NodeB, evolved NodeBs (eNB), Next Generation NodeBs (gNB), RAN nodes, etc., and can include terrestrial stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographical area (e.g., a cell). In some aspects, communication nodes 111 and 112 can be transmission / reception points (TRP). In an example where communication nodes 111 and 112 are NodeB (e.g., eNB or gNB), one or more TRP can function within the communication cell of the NodeB. RAN 110 can include one or more RAN nodes for providing macro cells, such as macro RAN node 111, and one or more RAN nodes for providing femto cells or pico cells (e.g., cells having a smaller coverage area, smaller user capacity or higher bandwidth compared to macro cells), such as low power (LP) RAN node 112.

[0015] Either of RAN nodes 111 and 112 can terminate the air interface protocol and can be the first contact for UEs 101 and 102. In some aspects, either of RAN nodes 111 and 112 can implement various logical functions of RAN 110 including, but not limited to, radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management, like radio network controller (RNC) functions. In one example, either of nodes 111 and / or 112 can be a gNB, eNB or other type of RAN node.

[0016] RAN 110 is shown to be communicatively coupled to a core network (CN) 120 via an S1 interface 113. In an aspect, CN 120 may be an evolved packet core (EPC) network, a NextGen Packet Core (NPC) network, or another type of CN (e.g., as shown with reference to FIGS. 1B - 1C). In this aspect, S1 interface 113 is split into two parts: an S1-U interface 114 that carries traffic data between RAN nodes 111 and 112 and a serving gateway (S-GW) 122, and an S1 mobility management entity (MME) interface 115 that is a signaling interface between RAN nodes 111 and 112 and an MME 121.

[0017] In this aspect, CN 120 includes an MME 121, an S-GW 122, a Packet Data Network (PDN) gateway (P-GW) 123, and a Home Subscriber Server (HSS) 124. MME 121 may perform functions similar to the control plane of a conventional Serving General Packet Radio Service (GPRS) Support Node (SGSN). MME 121 may manage aspects of mobility in access, such as gateway selection and tracking area list management. HSS 124 may include a database for network users that contains subscription-related information to support the processing of network entities for communication sessions. CN 120 may include one or more HSSs 124 depending on the number of mobile subscribers, device capacity, network configuration, etc. For example, HSS 124 can provide support for routing / roaming, authentication, authorization, name / address resolution, location dependencies, etc.

[0018] The S-GW 122 may terminate the S1 interface 113 to the RAN 110 and route data packets between the RAN 110 and the CN 120. Further, the S-GW 122 may be a local mobility anchor point for handover between RAN nodes and may also provide an anchor for mobility between 3GPPs. Other roles of the S-GW 122 may include lawful interception, charging, and some policy enforcement.

[0019] The P-GW 123 may terminate the SGi interface to the PDN. The P-GW 123 may route data packets between the EPC network 120 and an external network such as a network including an application server 184 (or referred to as an application function (AF)) via an Internet Protocol (IP) interface 125. The P-GW 123 may also communicate data to another external network 131A that may include the Internet, an IP multimedia subsystem (IMS) network, and other networks. Generally, the application server 184 may be an element that provides an application using IP bearer resources with a core network (e.g., a UMTS packet service (PS) domain, an LTE PS data service, etc.). In this aspect, the P-GW 123 is shown to be communicatively coupled to the application server 184 via the IP interface 125. The application server 184 may also be configured to support one or more communication services (e.g., a Voice-over-Internet Protocol (VoIP) session, a Push-to-Talk (PTT) session, a group communication session, a social networking service, etc.) for the UEs 101 and 102 via the CN 120.

[0020] P-GW 123 may further be a node for policy enforcement and charging data collection. The Policy and Charging Rules Function (PCRF) 126 is a policy and charging control element of the CN 120. In some aspects, in a non-roaming scenario, there may be a single PCRF in the Home Public Land Mobile Network (HPLMN) associated with the Internet Protocol Connectivity Access Network (IP-CAN) session of the UE. In a roaming scenario with local breakout of traffic, there may be two PCRFs associated with the IP-CAN session of the UE, namely, a Home PCRF (H-PCRF) in the HPLMN and a Visited PCRF (V-PCRF) in the Visited Public Land Mobile Network (VPLMN). The PCRF 126 may be communicatively coupled to the application server 184 via the P-GW 123.

[0021] In some aspects, the communication network 140A can be an IoT network or a 5G network, including a 5G New Radio network that uses communication in licensed (5G NR) spectrum and unlicensed (5G NR-U) spectrum. One of the things enabling IoT currently is Narrowband-IoT (NB-IoT). Operation in unlicensed spectrum may include dual connectivity (DC) operation and a stand-alone LTE system in unlicensed spectrum. According to this, LTE-based technology operates only in unlicensed spectrum without using an "anchor" in licensed spectrum called MulteFire. Further extended operation of LTE systems in licensed and unlicensed spectrum is expected in future releases and 5G systems. Such extended operation can include techniques for sidelink resource allocation and UE processing operations for NR sidelink V2X communication.

[0022] The NG system architecture can include a RAN 110 and a 5G network core (5GC) 120. The NG-RAN 110 can include multiple nodes such as gNBs and NG-eNBs. The core network 120 (e.g., 5G core network or 5GC) can include an access and mobility function (AMF) and / or a user plane function (UPF). The AMF and UPF can be communicatively coupled to gNBs and NG-eNBs via the NG interface. More specifically, in some aspects, gNBs and NG-eNBs can be connected to the AMF via the NG-C interface and to the UPF via the NG-U interface. gNBs and NG-eNBs can be coupled to each other via the Xn interface.

[0023] In some aspects, the NG system architecture can use the reference points between various nodes provided by 3GPP TS (Technical Specification) 23.501 (e.g., V15.4.0, December 2018). In some aspects, each of the gNB and the NG-eNB can be implemented as a base station, a mobile edge server, a small cell, a home eNB, etc. In some aspects, in the 5G architecture, the gNB can be a master node (MN), and the NG-eNB can be a secondary node (SN).

[0024] Figure 1B shows a non-roaming 5G system architecture according to some aspects. In particular, Figure 1B shows the 5G system architecture 140B in a reference point representation. More specifically, the UE 102 can communicate with the RAN 110 and one or more other 5GC network entities. The 5G system architecture 140B includes a plurality of network functions (NFs), such as the AMF 132, the session management function (SMF) 136, the policy control function (PCF) 148, the application function (AF) 150, the UPF 134, the network slice selection function (NSSF) 142, the authentication server function (AUSF) 144, and the unified data management (UDM) / home subscriber server (HSS) 146.

[0025] UPF134 can provide a connection to a data network (DN) 152, which can include, for example, operator services, Internet access, or third - party services. AMF132 can be used to manage access control and mobility and can include a network slice selection function. AMF132 may provide UE - based authentication, authorization, mobility management, etc., and may be independent of the access technology. SMF136 can be configured to set up and manage various sessions according to network policies. Thus, SMF136 may be responsible for session management and the allocation of IP addresses to the UE. SMF136 may also select and control UPF134 for data transfer. SMF136 may be associated with a single session of UE101 or multiple sessions of UE101. This means that UE101 may have multiple 5G sessions. Different SMFs may be assigned to each session. The use of different SMFs may allow each session to be managed individually. As a result, the functions of each session may be independent of each other.

[0026] UPF134 can be deployed in one or more configurations according to the desired service type and may be connected to the data network. PCF148 can be configured to provide a policy framework using network slicing, mobility management, and roaming (similar to PCRF in a 4G communication system). UDM can be configured to store subscriber profiles and data (similar to HSS in a 4G communication system).

[0027] AF150 may provide information regarding the packet flow to PCF148, which is responsible for policy control, to support the desired QoS. PCF148 may set the mobility and session management policies of UE101. For this purpose, PCF148 may use the packet flow information to determine appropriate policies for the proper operation of AMF132 and SMF136. AUSF144 may store data for UE authentication.

[0028] In some embodiments, the 5G system architecture 140B may include a plurality of IP multimedia core network subsystem entities such as an IP multimedia subsystem (IMS) 168B and a call session control function (CSCF). More specifically, the IMS 168B includes a CSCF, and the CSCF can function as a proxy CSCF (P-CSCF) 162BE, a serving CSCF (S-CSCF) 164B, an emergency CSCF (E-CSCF) (not shown in FIG. 1B), or an interrogating CSCF (I-CSCF) 166B. The P-CSCF 102B can be configured to be the first contact of the UE within the IP multimedia subsystem (IMS) 168B. The S-CSCF 164B can be configured to handle the session state within the network, and the E-CSCF can be configured to handle certain aspects of an emergency session to route an emergency request to the correct emergency center or PSAP. The I-CSCF 166B can be configured to function as a contact within the operator's network for all IMS connections destined for subscribers of that network operator or roaming subscribers currently located within the service area of that network operator. In some embodiments, the I-CSCF 166B can be connected to other IP multimedia networks 170E, such as an IMS operated by another network operator.

[0029] In some embodiments, the UDM / HSS 146 can be coupled to an application server 160E that can include a telephony application server (TAS) or other application server (AS). The AS 160B can be coupled to the IMS 168B via the S-CSCF 164B or the I-CSCF 166B.

[0030] The reference point representation indicates that there can be interactions between the corresponding NF services. For example, FIG. 1B shows the reference points of N1 (between UE102 and AMF132), N2 (between RAN110 and AMF132), N3 (between RAN110 and UPF134), N4 (between SMF136 and UPF134), N5 (between PCF148 and AF150, not shown), N6 (between UPF134 and DN152), N7 (between SMF136 and PCF148, not shown), N8 (between UDM146 and AMF132, not shown), N9 (between two UPF134s, not shown), N10 (between UDM and SMF136, not shown), N11 (between AMF132 and SMF136, not shown), N12 (between AUSF144 and AMF132, not shown), N13 (between AUSF144 and UDM146, not shown), N14 (between two AMF132s, not shown), N15 (between PCF148 and AMF132 in a non-roaming scenario or between PCF148, visited network and AMF132 in a roaming scenario, not shown), N16 (between two SMFs, not shown) and N22 (between AMF132 and NSSF142, not shown). Other reference point representations not shown in FIG. 1B can also be used.

[0031] FIG. 1C shows the 5G system architecture 140C and service-based representation. In addition to the network entities shown in FIG. 1B, the system architecture 140C can also include a network exposure function (NEF) 154 and a network repository function (NRF) 156. In some aspects, the 5G system architecture can be service-based, and the interactions between network functions can be represented as the corresponding point-to-point reference points Ni or service-based interfaces.

[0032] As shown in FIG. 1C, in some embodiments, service-based representations can be used to represent network functions within a control plane that enable other permitted network functions to access these services. In this regard, the 5G system architecture 140C can include service-based interfaces of Namf158H (service-based interface exposed by AMF132), Nsmf158I (service-based interface exposed by SMF136), Nnef158B (service-based interface exposed by NEF154), Npcf158D (service-based interface exposed by PCF148), Nudm158E (service-based interface exposed by UDM146), Naf158F (service-based interface exposed by AF150), Nnrf158C (service-based interface exposed by NRF156), Nnssf158A (service-based interface exposed by NSSF142), Nausf158G (service-based interface exposed by AUSF144). Other service-based interfaces not illustrated in FIG. 1C (e.g., Nudr, N5g-eir, and Nudsf) can also be used.

[0033] The NR-V2X architecture may support high-reliability low-latency sidelink communication with various traffic patterns, including periodic and aperiodic communications with random packet arrival times and sizes. The techniques disclosed herein can be used to support high reliability in a distributed communication system having a dynamic topology, including a sidelink NR V2X communication system.

[0034] FIG. 2 is a block diagram of a communication device according to some embodiments. The communication device 200 may be any machine capable of executing instructions (sequential or otherwise) that specify actions to be executed by a dedicated computer, a personal or laptop computer (PC), a tablet PC, a UE such as a smartphone, a dedicated network device such as an eNB, a server executing software to configure the server to operate as a network device, a virtual device, or a machine. For example, the communication device 200 may be implemented as one or more of the devices shown in FIGS. 1A-1C. Note that the communication described herein may be encoded prior to transmission by a transmitting entity (e.g., UE, gNB) for reception by a receiving entity (e.g., gNB, UE) and decoded after reception by the receiving entity.

[0035] The examples described herein may include, or may operate on, logic or multiple components, modules, or mechanisms. A module and a component are tangible entities (e.g., hardware) capable of performing specified operations and may be configured or arranged in a particular manner. In one example, a circuit may be arranged as a module in a specified manner (e.g., internally or with respect to an external entity such as another circuit). In one example, one or more computer systems (e.g., a stand-alone, client, or server computer system) or portions of one or more hardware processors may be configured as a module that operates to perform specified operations by firmware or software (e.g., instructions, an application portion, or an application). In one example, the software may reside on a machine-readable medium. In one example, the software, when executed by the hardware underlying the module, causes the hardware to perform the specified operations.

[0036] Accordingly, the terms “module” (and “component”) are understood to include a tangible entity, which is physically constructed to operate in a specified manner, or to perform some or all of the operations described herein, a specifically configured entity (e.g., a wiring), or an entity temporarily (e.g., transiently) configured (e.g., programmed). Considering an example where a module is temporarily configured, each of the modules need not be instantiated at any one point in time. For example, if a module includes a general-purpose hardware processor configured using software, the general-purpose hardware processor may be configured as different modules at different times. The software may accordingly configure the hardware processor, for example, to configure a particular module at one point in time and a different module at a different point in time.

[0037] The communication device 200 includes a hardware processor (or equivalent processing circuitry) 202 (e.g., a central processing unit (CPU), a GPU, a hardware processor core, or any combination thereof), a main memory 204, and a static memory 206, and some or all of these may communicate with each other via an interlink (e.g., a bus) 208. The main memory 204 may include any or all of removable storage and non-removable storage, volatile memory, or non-volatile memory. The communication device 200 may further include a display unit 210 such as a video display, an alphanumeric input device 212 (e.g., a keyboard), and a user interface (UI) navigation device 214 (e.g., a mouse). In one example, the display unit 210, the input device 212, and the UI navigation device 214 may be a touch screen display. The communication device 200 may further include a storage device (e.g., a drive unit) 216, a signal generation device 218 (e.g., a speaker), a network interface device 220, and one or more sensors such as a global positioning system (GPS) sensor, a compass, an accelerometer, or other sensors. The communication device 200 may further include an output controller such as a serial (e.g., a universal serial bus (USB)), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate with or control one or more peripheral devices (e.g., a printer, a card reader, etc.).

[0038] The memory device 216 may include a non-transitory machine-readable medium 222 (hereinafter simply referred to as the machine-readable medium) that stores one or more sets of data structures or instructions 224 (e.g., software) that are implemented or utilized by any one or more of the techniques or functions described herein. The instructions 224 may also be present, in whole or at least in part, within the main memory 204, within the static memory 206, and / or within the hardware processor 202 during execution by the communication device 200. Although the machine-readable medium 222 is shown as a single medium, the term "machine-readable medium" may include a single medium or a plurality of media (e.g., a centralized or distributed database, and / or associated caches and servers) configured to store one or more instructions 224.

[0039] The term "machine-readable medium" may include any medium that can store, encode, or carry instructions for execution by the communication device 200 and that can cause the communication device 200 to perform any one or more of the techniques of this disclosure, or any medium that can store, encode, or carry data structures used by or associated with such instructions. Non-limiting examples of machine-readable media may include solid-state memory, optical media, and magnetic media. Specific examples of machine-readable media may include non-volatile memory such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)), and flash memory devices, magnetic disks such as internal hard disks and removable disks, magneto-optical disks, radio access memory (RAM), CD-ROM disks, and DVD-ROM disks.

[0040] Command 224 may be further transmitted or received over a communication network using transmission medium 226 via a network interface device 220 that utilizes any one of a plurality of wireless local area network (WLAN) transfer protocols (e.g., frame relay, internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Examples of communication networks may include local area networks (LANs), wide area networks (WANs), packet data networks (e.g., the Internet), cellular phone networks (e.g., cellular networks), plain old telephone (POTS) networks, and wireless data networks. Communication over the network may include one or more different protocols, such as the IEEE 802.11 family of standards known as Wi-Fi, the IEEE 802.16 family of standards known as WiMax, the IEEE 802.15.4 family of standards, the Long Term Evolution (LTE) family of standards, the Universal Mobile Telecommunications System (UMTS) family of standards, peer-to-peer (P2P) networks, next generation / 5th generation (5G) standards. In one example, network interface device 220 may include one or more physical jacks (e.g., Ethernet, coaxial, or telephone jacks) or one or more antennas for connecting to transmission medium 226.

[0041] As used herein, the term "circuit" refers to a hardware component configured to provide the described functionality, such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or grouped) and / or a memory (shared, dedicated, or grouped), an application specific integrated circuit (ASIC), a field-programmable device (FPD) (e.g., a field-programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high-capacity PLD (HCPLD), a structured ASIC, or a programmable system on a chip (SoC)), a digital signal processor (DSP), etc., or a part thereof, or includes these. In some embodiments, the circuit may execute one or more software or firmware programs to provide at least a portion of the described functionality. The term "circuit" may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) and program code used to execute the functionality of that program code. In these embodiments, the combination of the hardware element and the program code may be referred to as a particular type of circuit.

[0042] Accordingly, the term "processor circuit" or "processor" as used herein refers to, is part of, or includes a circuit capable of continuously and automatically performing a series of arithmetic or logical operations, or capable of recording, storing, and / or transferring digital data. The term "processor circuit" or "processor" may refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a single-core or multi-core processor, and / or any other device capable of executing or otherwise operating on computer-executable instructions such as program code, software modules, and / or functional processes.

[0043] In 5G NR Rel-16, multi-TRP operation was introduced. In 5G NR Rel-16, multi-TRP operation is used for the physical downlink shared channel (PDSCH). Depending on different backhaul assumptions (ideal backhaul and non-ideal backhaul), multi-TRP operation includes single-DCI operation and multi-DCI operation. FIG. 3A shows single downlink control information (DCI) TRP operation according to some embodiments. FIG. 3B shows multi-DCI TRP operation according to some embodiments. Note that for convenience, only some elements are shown and others may exist. As shown in FIGS. 3A and 3B, system 300 includes a plurality of TRPs (TRP#A302a, TRP#B302b) that communicate with UE304. TRP#A302a and TRP#B302b may each transmit the PDSCH using different beams. One of the PDSCHs from each of TRP#A302a and TRP#B302b may be received by UE304.

[0044] The single DCI operation as shown in Fig. 3A can be used assuming an ideal backhaul. In the single DCI operation, a single physical downlink control channel (PDCCH) transmission may schedule PDSCH transmissions from multiple TRPs. This is shown in Fig. 3A as the scheduling of PDSCH#1 from TRP#A302a following the PDCCH from TRP#A302a. The multi-DCI operation as shown in Fig. 3B can be used assuming a non-ideal backhaul. In the multi-DCI operation, each TRP may use one PDCCH to schedule the corresponding PDSCH transmission. This is shown in Fig. 3B as the scheduling of PDSCH#1 from TRP#A302a following PDCCH#1 from TRP#A302a, and the scheduling of PDSCH#2 from TRP#B302b following PDCCH#2 from TRP#B302b.

[0045] In the multi-DCI multi-TRP operation, there may be multiple control resource set (CORESET) pools. Each CORESET is a set of physical resources and a set of parameters used to carry PDCCH / DCI. One CORESET may be configured with the parameter CORESETPoolIndex, which can distinguish TRPs. For example, a value of 0 for CORESETPoolIndex corresponds to TRP#A, and a value of 1 corresponds to TRP#B.

[0046] In the single DCI multi-TRP operation, the code point of the transmission configuration indication (TCI) field in the DCI can be associated with one or two TCI states. Fig. 4 shows the MAC-CE according to some embodiments. The MAC-CE may be used to construct TCI code points having multiple TCI states. The fields of the MAC-CE are defined as follows.

[0047] Serving Cell ID: This field indicates the identification of the serving cell to which the MAC CE is applied. The length of the field is 5 bits.

[0048] Bandwidth Part Indicator (BWP) ID: This indicates the DL BWP to which the MAC CE is applied as the code point of the DCI bandwidth part indicator field specified in TS38.212. The length of the BWP ID field is 2 bits.

[0049] C i : This field indicates whether there is an octet containing the TCI state ID i,2 . If this field is set to "1", there is an octet containing the TCI state ID i,2 . If this field is set to "0", there is no octet containing the TCI state ID i,2 .

[0050] TCI state ID i,j : This indicates the TCI state identified by the TCI-StateId specified in TS38.331. Here, i is the index of the code point of the DCI transmission configuration indication field specified in TS38.212, and the TCI state ID i,j indicates the j-th TCI state shown for the i-th code point of the DCI transmission configuration indication field. The TCI code point to which the TCI state is mapped is determined by its order position among all the TCI code points having the set of the TCI state ID i,j field. That is, the first TCI code point having TCI state ID 0,1 and TCI state ID 0,2 is mapped to the code point value 0, the second TCI code point having TCI state ID 1,1 and TCI state ID 1,2 is mapped to the code point value 1, and so on. The TCI state ID i,2 is, C iIt is optional based on the indication of the field. The maximum number of activated TCI code points is 8, and the maximum number of TCI states mapped to the TCI code points is 2.

[0051] R: It is a reserved bit set to "0".

[0052] In NR Rel-15, the MAC-CE is defined to update the spatial relationship of semi-persistent SRS. In Rel-16, other MAC-CEs are defined to update the spatial relationship of aperiodic SRS. Figure 5 shows the MAC-CE for updating the spatial relationship of semi-persistent SRS according to some embodiments. The MAC-CE in Figure 5 is for semi-persistent (SP, semi-persistent) SRS activation / deactivation. The fields of the MAC-CE in Figure 5 are defined as follows.

[0053] A / D: This field indicates whether to activate or deactivate the indicated SP SRS resource set. This field is set to 1 to indicate activation and otherwise indicates deactivation.

[0054] SRS Resource Set’s Cell ID: This field indicates the identification information of the serving cell containing the activated / deactivated SP SRS resource set. When the C field is set to 0, this field also indicates the identification information of the serving cell containing all the resources indicated by the Resource ID i field. The length of the field is 5 bits.

[0055] SRS Resource Set’s BWP ID: This field indicates the UL BWP as the code point of the DCI bandwidth part indicator field specified in TS38.212. This includes the activated / deactivated SP SRS resource set. When the C field is set to 0, this field also indicates the identification information of the BWP including all the resources indicated by the Resource ID i field. The length of the field is 2 bits.

[0056] C: This field indicates whether there is an octet including the Resource Serving Cell ID field and the Resource BWP ID field. When this field is set to 1, there is an octet including the Resource Serving Cell ID field and the Resource BWP ID field, and otherwise there is not.

[0057] Supplementary Uplink(SUL): This field indicates whether the MAC CE is applied to the normal uplink (NUL) carrier configuration or the SUL carrier configuration. This field is set to 1 to indicate application to the SUL carrier configuration and set to 0 to indicate application to the NUL carrier configuration.

[0058] SP SRS Resource Set ID: This field indicates the SP SRS Resource Set ID identified by the SRS-ResourceSetId specified in TS38.331 to be activated or deactivated. The length of the field is 4 bits.

[0059] F i: This field indicates the type of resource used as the spatial relationship of the SRS resource within the SP resource set indicated by the SP SRS Resource Set ID field. F0 indicates the first SRS resource within the resource set, F1 indicates the second one, and so on. The field is set to 1 to indicate that a non-zero power (NZP) channel state information (CSI)-RS resource index is used, and set to 0 to indicate that a synchronization signal block (SSB) index or an SRS resource index is used. The length of the field is 1 bit. This field exists only when MAC CE is used for activation, i.e., when the A / D field is set to 1.

[0060] Resource ID i : It contains the identifier of the resource used to derive the spatial relationship of SRS resource i. Resource ID0 indicates the first SRS resource within the resource set, Resource ID1 indicates the second one, and so on. When F i is set to 0 and the first bit of this field is set to 1, the remaining part of this field contains the SSB-Index specified in TS38.331. When F i is set to 0 and the first bit of this field is set to 0, the remaining part of this field contains the SRS-ResourceId specified in TS38.331. The length of the field is 7 bits. This field exists only when MAC CE is used for activation, i.e., when the A / D field is set to 1.

[0061] Resource Serving Cell ID i : It indicates the identification information of the serving cell where the resource used to derive the spatial relationship of SRS resource i is located. The length of the field is 5 bits.

[0062] Resource BWP ID i : Indicates the UL BWP as the code point of the DCI bandwidth part indicator field defined in TS38.212 where the resource used for deriving the spatial relationship of SRS resource i is located. The length of the field is 2 bits.

[0063] R: Reserved bit set to 0.

[0064] Figure 6 shows a MAC-CE for updating the spatial relationship of aperiodic SRS according to some embodiments. The fields of the MAC-CE are defined as follows.

[0065] SRS Resource Set’s Cell ID: This field indicates the identification information of the serving cell containing the indicated access point (AP) SRS resource set. When the C field is set to 0, this field also indicates the identification information of the serving cell containing all the resources indicated by the Resource ID i field. The length of the field is 5 bits.

[0066] SRS Resource Set’s BWP ID: This field indicates the UL BWP as the code point of the DCI bandwidth part indicator field specified in TS38.212. This includes the indicated AP SRS resource set. When the C field is set to 0, this field also indicates the identification information of the BWP containing all the resources indicated by the Resource ID i field. The length of the field is 2 bits.

[0067] C: This field indicates whether there are octets including the Resource Serving Cell ID field and the Resource BWP ID field. If this field is set to 1, there are octets including the Resource Serving Cell ID field and the Resource BWP ID field; otherwise, there are none.

[0068] SUL: This field indicates whether the MAC CE is applied to the NUL carrier configuration or the SUL carrier configuration. This field is set to 1 to indicate application to the SUL carrier configuration and set to 0 to indicate application to the NUL carrier configuration.

[0069] AP SRS Resource Set ID: This field indicates the AP SRS Resource Set ID identified by the SRS-ResourceSetId specified in TS38.331. The length of the field is 4 bits.

[0070] F i : This field indicates the type of resource used as the spatial relationship of the SRS resources within the AP resource set indicated by the AP SRS Resource Set ID field. F0 indicates the first SRS resource within the resource set, F1 indicates the second one, and so on. The field is set to 1 to indicate that the NZP CSI-RS resource index is used and set to 0 to indicate that the SSB index or the SRS resource index is used. The length of the field is 1 bit. This field exists only when the MAC CE is used for activation, that is, when the A / D field is set to 1.

[0071] Resource ID i:It contains the identifier of the resource used for deriving the spatial relationship of SRS resource i. Resource ID0 indicates the first SRS resource in the resource set, Resource ID1 indicates the second one, and so on. F i is set to 0. When the first bit of this field is set to 1, the remaining part of this field contains the SSB-Index specified in TS38.331. F i is set to 0. When the first bit of this field is set to 0, the remaining part of this field contains the SRS-ResourceId specified in TS38.331. The length of the field is 7 bits.

[0072] Resource Serving Cell ID i :It indicates the identification information of the serving cell where the resource used for deriving the spatial relationship of SRS resource i is located. The length of the field is 5 bits.

[0073] Resource BWP ID i :It indicates the UL BWP as the code point of the DCI bandwidth part indicator field defined in TS38.212 where the resource used for deriving the spatial relationship of SRS resource i is located. The length of the field is 2 bits.

[0074] R: Reserved bits set to 0.

[0075] In NR Rel-16, other MAC-CEs are defined to update the spatial relationship of PUCCH. Details are in TS38.321.

[0076] In NR Rel-15, for the PUSCH scheduled by DCI format 0_0, the default spatial relation may be applied. This default spatial relation may be the spatial relation of the PUCCH resource having the lowest resource ID on a component carrier (CC). If the PUCCH resource is not configured on the CC, or if the PUCCH resource is configured but has no spatial relation, the UE is assumed not to be scheduled by DCI 0_0.

[0077] In NR Rel-16, to reduce overhead, default beam operations are defined for the SRS, PUCCH, and PUSCH scheduled by DCI 0_0. If the default beam for the SRS / PUCCH is active, the SRS / PUCCH may be configured without spatial relation information so that the MAC-CE overhead is reduced, and the MAC-CE for updating the spatial relation of the SRS / PUCCH may not be transmitted. If the default beam for the PUSCH is active, the PUSCH may be scheduled by DCI format 0_0 even if the PUCCH resource is not configured on the CC, or if the PUCCH resource is configured but has no spatial relation.

[0078] When the parameter enableDefaultBeamPlForSRS is set to "enabled", the default spatial relation / path loss reference signal of the SRS is the TCI state / QCL assumption of the CORESET having the lowest ID if the CORESET is configured on the CC, or the activated TCI state having the lowest ID of the PDSCH if the CORESET is not configured on the CC.

[0079] When the parameter enableDefaultBeamPlForPUCCH is set to "enabled", the default spatial relation / path loss reference signal of PUCCH is the TCI state / QCL assumption of the CORESET with the lowest ID when the CORESET is configured for the CC.

[0080] When the parameter enableDefaultBeamPlForPUSCH0_0 is set to "enabled", the default spatial relation / path loss reference signal of the PUSCH scheduled by DCI 0_0 is as follows. If the PUCCH resource is not configured for the active BWP within the CC, the default spatial relation / path loss reference signal is the TCI state / QCL assumption of the CORESET with the lowest ID. Alternatively, if the PUCCH resource is configured but has no spatial relation, the default spatial relation / path loss reference signal follows the default spatial relation / path loss reference signal of these PUCCH resources.

[0081] However, the existing default spatial relation design for SRS / PUCCH / PUSCH is applicable to the case of a single TRP. To support multi-TRP operation, the default spatial relation design is further extended.

[0082] Default Uplink Spatial Relations in Multi-TRP Using Multi-DCI 1. SRS In an embodiment, in multi-DCI multi-TRP, one SRS resource is associated with one spatial relation. To reduce overhead, the default beam / spatial relation may be applied to SRS transmission. Existing parameters, such as enableDefaultBeamPlForSRS, can be reused to indicate whether the default spatial relation / beam for SRS transmission is enabled. If this parameter is enabled, the spatial relation and path loss reference signal are not configured for SRS. Therefore, additional MAC-CE for updating the spatial relation of SRS transmission may be avoided, and the overhead can be reduced.

[0083] In multi-DCI multi-TRP, the SRS may be associated with one TRP. The association may be defined at the SRS resource level or SRS resource set level by a new RRC parameter associatedCORESETPool-SRS. The parameter associatedCORESETPool-SRS indicates which CORESET pool is associated with the SRS resource / SRS resource set. The value of associatedCORESETPool-SRS may be the same as the CORESETPoolIndex of the CORESET pool. For example, when the SRS is associated with the CORESET pool with CORESETPoolIndex = 1, the value of associatedCORESETPool-SRS may be set to "1". The association defined by associatedCORESETPool-SRS may be applied to periodic, semi-persistent, and aperiodic SRSs (in other examples, the association between the SRS and the CORESET pool may be updated by a new MAC-CE). Alternatively, for aperiodic SRS, the association may be implicitly indicated by the scheduling PDCCH. For example, when an aperiodic SRS is triggered by a CORESET configured with CORESETPoolIndex#A, the triggered SRS is associated with CORESETPoolIndex#A. The default spatial relationship / default path loss reference signal of the SRS may be determined according to the associated TRP.

[0084] Note that the application of the association between the SRS and the TRP in this embodiment is not limited to the default beam operation of the SRS. In other embodiments, codebook-based transmission, non-codebook-based transmission, etc. may be used.

[0085] An example of the radio resource control (RRC) configuration of the SRS by the associated CORESET pool is as follows.

[0086]

Table 1

[0087] Option 1: The default spatial relation / path loss reference signal of the SRS follows the TCI state / QCL assumption of the CORESET with the lowest index among the CORESETS with the configured CORESETPoolindex the same as the CORESET pool associated with the SRS in the latest slot in which one or more CORESETS with the configured CORESETPoolindex the same as the CORESET pool associated with the SRS are monitored by the UE. The "latest slot" is before the SRS transmission. If there is no SRS transmission at all, i.e., only for the derivation of the spatial relation of the PUSCH, the "latest slot" is before the corresponding PUSCH transmission.

[0088] The CORESET pool associated with the SRS is indicated by associatedCORESETPool-SRS. Alternatively, when the SRS is indicated by DCI, i.e., an aperiodic SRS, the associated CORESET pool is the same as the scheduling CORESET. For an aperiodic SRS triggered by DCI, alternatively, the default spatial relation / path loss reference signal may follow the TCI state / QCL assumption of the scheduling CORESET.

[0089] If the CORESET is not configured in the active BWP within the CORESET pool associated with the SRS resource, the default spatial relation / path loss reference signal follows the activated TCI state with the lowest ID of the PDSCH within the same CORESET pool.

[0090] FIG. 7 shows the determination of the default spatial relationship of the SRS according to some embodiments. As described above, the determination of the default spatial relationship of the SRS is for multi-DCI multi-TRP.

[0091] PUCCH In an embodiment, in multi-DCI multi-TRP, one PUCCH resource is associated with only one spatial relationship. To reduce overhead, the default beam / spatial relationship may be applied to PUCCH transmission. Existing parameters, such as enableDefaultBeamPlForPUCCH, can be reused to indicate whether the default spatial relationship / beam for PUCCH transmission is effective. If this parameter is effective, the spatial relationship and path loss reference signal are not configured for PUCCH. Therefore, additional MAC-CE transmission for updating the spatial relationship of PUCCH transmission may be avoided, and the overhead can be reduced.

[0092] In multi-DCI multi-TRP, the PUCCH may be associated with one TRP. The association may be defined at the PUCCH resource set level / PUCCH resource group level / PUCCH resource level by the new RRC parameter associatedCORESETPool-PUCCH. In other examples, the associated TRP for the PUCCH may be implicitly represented by the PUCCH resource group ID or the PUCCH resource set ID. The parameter associatedCORESETPool-PUCCH indicates which CORESET pool is associated with the PUCCH resource / PUCCH resource set / PUCCH resource group. In other examples, the association between the PUCCH and the CORESET pool may be updated by a new MAC-CE. The value of associatedCORESETPool-PUCCH should be the same as the CORESETPoolIndex of the CORESET pool. For example, if the PUCCH is associated with the CORESET pool with CORESETPoolIndex = 1, the value of associatedCORESETPool-PUCCH should be set to "1". Alternatively, if the PUCCH resource is indicated by DCI, the PUCCH resource may be implicitly associated with the CORESET pool of the scheduling CORESET. The default spatial relationship / default path loss reference signal of the PUCCH may be determined according to the associated TRP.

[0093] Note that the application of the association between the PUCCH and the TRP in this embodiment is not limited to the default beam operation of the PUCCH. An example of the RRC configuration of the PUCCH by the associated CORESET pool is as follows.

[0094] [Table 2] For a PUCCH having a single spatial relation in multi-DCI multi-TRP, when enableDefaultBeamPlForPUCCH is enabled and neither the spatial relation nor the path loss reference signal is configured for the PUCCH, the default spatial relation / path loss reference signal of the PUCCH is applied and determined as follows.

[0095] Option 1: The default spatial relation / path loss reference signal of the PUCCH follows the TCI state / QCL assumption of the CORESET with the lowest index among the CORESETS with the configured CORESETPoolindex being the same as the CORESET pool related to the PUCCH in the latest slot in which one or more CORESETS with the configured CORESETPoolindex being the same as the CORESET pool related to the PUCCH are monitored by the UE. The "latest slot" is before PUCCH transmission. The related CORESET pool for the PUCCH is indicated by associatedCORESETPool-PUCCH. Alternatively, when the PUCCH is indicated by DCI, the related CORESET pool is the same as the scheduling CORESET.

[0096] For a PUCCH indicated by DCI, alternatively, the default spatial relation / path loss reference signal may follow the TCI state / QCL assumption of the scheduling CORESET.

[0097] When the CORESET is not configured in the active BWP within the CORESET pool related to the PUCCH resource, the default spatial relation / path loss reference signal follows the activated TCI state having the lowest ID of the PDSCH within the same CORESET pool.

[0098] Figure 8 shows the determination of the default spatial relation of the PUCCH according to some embodiments. As described above, the determination of the default spatial relation of the PUCCH is for multi-DCI multi-TRP.

[0099] PUSCH In an embodiment, in multi-DCI multi-TRP, when the parameter enableDefaultBeamPlForPUSCH0_0 is set to "invalid", it is not assumed that the UE is scheduled by DCI format 0_0 from one TRP (indicated by CORESETPoolIndex) where there is no PUCCH resource configured in a spatial relationship. When there is at least one PUCCH resource configured in a spatial relationship on the TRP, the spatial relationship / path loss reference signal of the PUSCH scheduled by DCI format 0_0 should follow the spatial relationship of the PUCCH resource having the lowest resource ID on the TRP (indicated by CORESETPoolIndex and associatedCORESETPool-PUCCH).

[0100] Alternatively, in multi-DCI multi-TRP, when the parameter enableDefaultBeamPlForPUSCH0_0 is set to "invalid", regardless of whether there is a PUCCH resource configured on the scheduling TRP, and regardless of whether the PUCCH resource is configured with or without a spatial relationship, the default spatial relationship / path loss reference signal of the PUSCH scheduled by DCI format 0_0 should be determined as follows.

[0101] Option 1: The default spatial relationship / path loss reference signal of the PUSCH scheduled by DCI0_0 should follow the TCI state / QCL assumption of the CORESET having the lowest ID within the CORESET pool that is the same as the CORESET pool of the scheduling CORESET in the latest slot before the PUSCH transmission for which such a CORESET is monitored.

[0102] Option 2: The default spatial relationship / path loss reference signal of the PUSCH scheduled by DCI 0_0 should follow the TCI state / QCL assumption of the scheduling CORESET.

[0103] Option 3: If the PUCCH resource is not configured for the TRP transmitting the scheduling CORESET, the default spatial relation / path loss reference signal shall follow the TCI state / QCL assumption of the CORESET with the lowest ID within the same CORESET pool as the CORESET pool of the scheduling CORESET in the latest slot before the PUSCH transmission in which such CORESET is monitored. If the PUCCH resource is configured but has no spatial relation to the TRP transmitting the scheduling CORESET, the default spatial relation / path loss reference signal shall follow the default spatial relation / path loss reference signal of these PUCCH resources on the TRP transmitting the scheduling CORESET.

[0104] Figure 9 shows the determination of the default spatial relation of PUSCH according to some embodiments. As described above, the determination of the default spatial relation of PUSCH scheduled by DCI 0_0 is for multi-DCI multi-TRP.

[0105] In other embodiments, for PUSCH scheduled by a DCI format other than 0_0, the spatial relation of the PUSCH shall follow the spatial relation of the SRS resource indicated by the SRS resource index (SRI) or the SRS resource configured by RRC if only one SRS resource is configured. When the parameter enableDefaultBeamPlForSRS is set to "enabled", the PUSCH transmission shall follow the default spatial relation of the corresponding SRS resource. If there is no SRS transmission, the default SRS spatial relation shall be derived assuming that the SRS is transmitted in the first slot of the PUSCH transmission.

[0106] In other embodiments, for PUSCHs scheduled by all DCI formats, the default beam operation may be enabled. A new parameter enableDefaultBeamPlForPUSCH may be introduced. When set to "enabled", the default spatial relation for PUSCH transmission is determined as follows.

[0107] Option 1: The default spatial relation / path loss reference signal for PUSCH should follow the spatial relation of the SRS resource indicated by the SRI or the SRS resource configured by the RRC if only one SRS resource is configured.

[0108] Option 2: The default spatial relation / path loss reference signal for PUSCH should follow the spatial relation of the PUCCH resource having the lowest ID associated with the same CORESET pool as the scheduling CORESET.

[0109] Option 3: The default spatial relation / path loss reference signal for PUSCH should follow the TCI state / QCL assumption of the CORESET having the lowest ID within the same CORESET pool as the CORESET pool of the scheduling CORESET in the latest slot before the PUSCH transmission in which such CORESET is monitored.

[0110] Option 4: The default spatial relation / path loss reference signal for PUSCH should follow the TCI state / QCL assumption of the scheduling CORESET.

[0111] As described above, in the Rel-15 specification, different types of SRS resource sets are supported. The SRS resource set is configured with a "usage" parameter, which can be set to "beamManagement", "codebook", "nonCodebook", or "antennaSwitching". The SRS resource set configured with "beamManagement" is used for beam acquisition using SRS and uplink beam indication. The SRS resource sets configured with "codebook" and "nonCodebook" are used to determine UL precoding by explicit indication by the Transmission Precoding Matrix Indicator (TPMI) or implicit indication by SRI. Finally, the SRS resource set configured with "antennaSwitching" is used to obtain DL channel state information using SRS measurements at the UE by leveraging channel reciprocity in a TDD system. For SRS transmission, the operation in the time domain may be periodic, semi-persistent, or aperiodic. The RRC configuration of the SRS resource set is as follows.

[0112]

Table 3

[0113]

Table 4

[0114] The slot offset is defined at the SRS resource set level. That is, the slot offset is common to all SRS resources within the SRS resource set. When the aperiodic SRS is triggered, the UE should transmit the aperiodic SRS after receiving the DCI according to the slotOffset defined by the RRC.

[0115] However, in the scenario of multi-DCI multi-TRP operation, there may be some problems in SRS configuration and transmission. For example, if both TRPs trigger different SRS resource sets transmitted in the same SRS resource set / the same slot, a collision may occur. Therefore, rules defined to reduce collisions or handle them when they occur are desired.

[0116] Scenario A: SRS Transmission in Multi-DCI Multi-TRP SRS Trigger and Configuration In an embodiment, for the SRS trigger in multi-DCI multi-TRP, the SRS trigger state indicated by the code point of the SRS Request field in the DCI may be TRP-specific. The same code point of the SRS Request field may be used to trigger different SRS resource sets by different TRPs. FIG. 10 shows the TRP-specific SRS trigger according to some embodiments.

[0117] In other embodiments, for SRS triggering in multi-DCI multi-TRP, the same code point of the SRS Request field in DCI from different TRPs may trigger the same SRS resource set with different slot offsets. FIG. 10 shows TRP-specific SRS triggering according to some embodiments.

[0118] In other embodiments, for multi-DCI multi-TRP, multiple SRS resource sets may be configured with the same usage (codebook-based transmission, non-codebook-based transmission, antenna switching, and beam management). Multiple SRS resource sets using the same usage may be configured with the same / different trigger states and the same / different slot offsets.

[0119] SRS may be associated with different TRPs, e.g., different CORESETPoolIndex. The association between SRS and TRP may be defined by a new RRC parameter, e.g., associatedCORESETPool-SRS, at the SRS resource set level / SRS resource level, or SRS spatial relationship information. SRS resource sets with the same usage setting should be associated with different TRPs. For example, in multi-TRP operation using two TRPs, two SRS resource sets may be defined for codebook-based transmission, and each SRS resource set is associated with one TRP. When transmitting an SRS request in DCI from one TRP, only the SRS resource set associated with the TRP may be triggered. FIG. 12 shows TRP-specific SRS triggering using the same usage according to some embodiments.

[0120] For codebook-based transmission, when scheduling PUSCH transmission, the SRI field indicates one SRS resource within the SRS resource set associated with the scheduling TRP. Alternatively, a new field may be introduced into DCI to indicate the SRS resource set.

[0121] For non-codebook-based transmission, different CSI-RS resource transmissions by different TRPs may be associated with different SRS resource sets among a plurality of SRS resource sets. The UE can calculate different precoders for SRS transmission to different TRPs based on measurements on CSI-RS. When scheduling PUSCH transmission, the SRI field indicates one or more SRS resources within the SRS resource set associated with the scheduling TRP. Alternatively, a new field may be introduced into the DCI to indicate the SRS resource set.

[0122] SRS Transmission Delay and Duplicate Handling In an embodiment, in multi-DCI multi-TRP, deferred SRS transmission may be applied. For example, if there is no available uplink resource / slot for SRS transmission, the triggered SRS should be deferred until the next available uplink slot. Deferred SRS transmission should be performed independently among TRPs. There should be some coordination among TRPs.

[0123] FIG. 13 shows independent deferred SRS transmission in multi-TRP according to some embodiments. In FIG. 13, TRP #A triggers SRS resource set #A with a slot offset of 2 in slot #N, and the transmission of SRS resource set #A is deferred to slot #N+6. Between slot #N and slot #N+6, TRP #B triggers another SRS resource set, i.e., SRS resource set #B. In this case, SRS resource set #B is not transmitted in slot #N+6 and is further deferred to slot #N+10, which is the next available uplink slot.

[0124] In another example, assuming that the uplink slot available for SRS transmission is slot M, a window, e.g., X slots, may be defined for the deferred transmission. During the period from slot M-X to slot M, if the first triggered SRS is from TRP#A, slot M should be used to transmit the SRS triggered by TRP#A. The SRS triggered by TRP#B, which is another TRP, during the period from slot M-X to slot M may be further deferred after slot M. Further, if multiple SRSs are triggered by TRP#A between slot M-X and slot M, the latest SRS triggered by TRP#A between slot M-X and slot M may be transmitted in slot M.

[0125] In other embodiments, in multi-DCI multi-TRP, for examples where multiple TRPs trigger the same SRS resource set to be transmitted in the same slot, where multiple TRPs trigger different SRS resource sets to be transmitted in the same slot, and where the SRS resource sets triggered by different TRPs are deferred to the same slot, collisions may occur for the SRSs triggered by different TRPs.

[0126] In this case, a drop rule may be provided to handle the duplication. In one example, when a collision occurs, one of the following options may be applied to determine which SRS should be transmitted. The SRS triggered by the TRP with the lowest or highest TRP ID (CORESETPoolIndex) is transmitted, and the others are dropped. The SRS with the lowest or highest SRS Resource Set ID should be transmitted, and the others should be dropped. The SRS using a specific usage method should be transmitted. In this case, there is a priority for the usage method of the SRS. For example, codebook / non-codebook-based transmission may be prioritized. The latest triggered SRS may be transmitted, and the others may be dropped. Alternatively, assuming that the uplink slot available for SRS transmission is slot M, a window, for example, X slots, may be defined. In the last case, during the period from slot M - X to slot M, if the first triggered SRS is from TRP#A, slot M may be used to transmit the SRS triggered by TRP#A. Further, if multiple SRSs are triggered by TRP#A between slot M - X and slot M, the latest SRS triggered by TRP#A between slot M - X and slot M may be transmitted in slot M. Other SRSs triggered between slot M - X and slot M may be dropped.

[0127] In other examples, when a collision occurs, the SRS triggered by the TRP whose CORESETPoolIndex is equal to (slotNumber mod 2) may be transmitted. FIG. 14 shows the collision handling of SRSs triggered by multiple TRPs according to some embodiments. As shown in FIG. 14, the SRS triggered by the TRP with the lowest TRP ID may be transmitted.

[0128] Scenario B: SRS Transmission in Carrier Aggregation SRS Trigger and Configuration In an embodiment, for carrier aggregation, multiple SRS resource sets may be configured with the same usage method (codebook-based transmission, non-codebook-based transmission, antenna switching, and beam management). Multiple SRS resource sets using the same usage method may be configured with the same / different trigger states and the same / different slot offsets.

[0129] SRS may be related to different CCs. The association between SRS and CC may be defined by a new RRC parameter, such as associatedCC-SRS, at the SRS resource set level / SRS resource level, or by SRS spatial relation information. SRS resource sets having the same usage method settings may be related to different CCs. When transmitting an SRS request in DCI from one CC, only the SRS resource set related to the CC may be triggered. FIG. 15 shows multiple SRS resource sets using the same usage method in carrier aggregation according to some embodiments.

[0130] For codebook-based transmission, when scheduling PUSCH transmission, the SRI field indicates one SRS resource within the SRS resource set related to the scheduling CC. Alternatively, a new field may be introduced into DCI to indicate the SRS resource set.

[0131] For non-codebook-based transmission, different CSI-RS resource transmissions by different CCs may be related to different SRS resource sets by multiple SRS resource sets. The UE can calculate different precoders for SRS transmission based on measurements on CSI-RS. When scheduling PUSCH transmission, the SRI field indicates one or more SRS resources within the SRS resource set related to the scheduling CC. Alternatively, a new field may be introduced into DCI to indicate the SRS resource set.

[0132] SRS Transmission Delay and Duplication Handling In an embodiment, in carrier aggregation, deferred SRS transmission may be applied. For example, when there is no uplink resource / slot available for SRS transmission, the triggered SRS may be deferred until the next available uplink slot. The deferred SRS transmission may be performed independently among TRPs. FIG. 16 shows independent deferred SRS transmission according to some embodiments. In particular, the independent deferred SRS transmission occurs between different CCs. As shown in the figure, CCE1 triggers SRS resource set #A with a slot offset of 2 within slot #N, and the transmission of SRS resource set #A is deferred to slot #N+6. Between slot #N and slot #N+6, CC#2 triggers SRS resource set #B, which is another SRS resource set. In this case, SRS resource set #B is not transmitted in slot #N+6 and is further deferred to slot #N+10, which is the next available uplink slot. In another example, assuming that the uplink slot available for SRS transmission is slot M, a window, for example, X slots, may be defined for the deferred transmission. During the period from slot M-X to slot M, if the first triggered SRS is from CC#A, slot M is used to transmit the SRS triggered by CC#A. The SRS triggered by CC#B, which is another CC during the period from slot M-X to slot M, may be further deferred after slot M. Further, if multiple SRSs are triggered by CC#A between slot M-X and slot M, the latest SRS triggered by CC#A between slot M-X and slot M may be transmitted in slot M.

[0133] In other embodiments, in carrier aggregation, for examples where multiple CCs trigger the same SRS resource set to be transmitted in the same slot, where multiple CCs trigger different SRS resource sets to be transmitted in the same slot, and where SRS resource sets triggered by different ones are deferred to the same slot, collisions may occur for SRSs triggered by different CCs.

[0134] In this case, a drop rule may be formulated to handle the duplication. In one example, when a collision occurs, one of the following options may be applied to determine which SRS should be transmitted. The SRS triggered by the CC with the lowest or highest CC ID is transmitted and the others are dropped. The SRS with the lowest or highest SRS Resource Set ID is transmitted and the others are dropped. The SRS using a predetermined usage method is transmitted (the usage methods of SRSs have different priorities, for example, codebook / non-codebook-based transmission is prioritized). The latest triggered SRS is transmitted and the others are dropped. Alternatively, assuming that the uplink slot available for SRS transmission is slot M, a window, for example, X slots, may be defined. In the last case, during the period from slot M-X to slot M, if the first triggered SRS is from CC#A, slot M is used to transmit the SRS triggered by CC#A. Further, if multiple SRSs are triggered by CC#A between slot M-X and slot M, the latest SRS triggered by CC#A between slot M-X and slot M is transmitted in slot M. Other SRSs triggered between slot M-X and slot M are dropped.

[0135] In other examples, when a collision occurs, the SRS triggered by the CC whose ID is equal to (slotNumber mod 2) is transmitted. FIG. 17 shows SRS collision handling according to some embodiments. In particular, the SRS shown in FIG. 17 is triggered by multiple CCs. As shown in the figure, the SRS triggered by the CC with the lowest TRP ID is transmitted.

[0136] For PUSCH transmission, as shown below, the information bits are scrambled before modulation.

[0137] 6.3.1 Physical Uplink Shared Channel 6.3.1.1 Scrambling For a single codeword q, a block of bits b (q) (0),…b (q) (M bit (q) -1)(M bit (q) is the number of bits transmitted by the codeword q transmitted on the physical channel) is assumed to be scrambled before modulation, and as a result, a block of bits scrambled according to the following pseudocode

[0138] [Number] is generated.

[0139] [Table 5] Here, x and y are the tags defined in 3GPP TS38.212, and the scrambling sequence c (q) (i) is given in Section 5.2.1.

[0140] The scrambling sequence generator is

[0141] [Number] is assumed to be initialized with. Here, n ID ∈{0,1,...,1023} is configured, and when the RNTI is equal to C-RNTI, MCS-C-RNTI, SP-CSI-RNTI or CS-RNTI and transmission is not scheduled using DCI format 0_0 in the common search space, it is equal to the upper layer parameter dataScramblingIdentityPUSCH.

[0142] n ID∈{0, 1, ..., 1023} is configured and is equal to the upper layer parameter msgA-dataScramblingIdentityPUSCH when PUSCH transmission is triggered by a type 2 random access procedure as described in section 8.1A of [TS38.213].

[0143] Otherwise, n ID = N ID cell is.

[0144] n RAPID is the index of the random access preamble transmitted for msgA as described in section 5.1.3A of [TS38.321].

[0145] The scrambling code is provided by dataScramblingIdentityPUSCH. However, in multi-TRP operation, PUSCH transmission may be targeted at different TRPs, and thus, in the scenario of multi-TRP operation, multiple scrambling codes are configured for the UE. The current PUSCH scrambling operation does not consider multi-TRP operation. Therefore, in particular, embodiments are directed to PUSCH scrambling in the scenario of multi-TRP operation.

[0146] PUSCH Scrambling Sequence Configuration in Multi-DCI Multi-TRP In an embodiment, for PUSCH transmission, additional scrambling sequences can be applied in multi-DCI multi-TRP (including multi-TRP operation with the same physical cell ID or different physical cell IDs). As shown below, a new parameter additionaldataScramblingIdentityPUSCH may be added to PUSCH-Config.

[0147]

Table 6

[0148] PUSCH Scrambling Sequence Configuration in Single DCI Multi-TRP In an embodiment, for PUSCH transmission, additional scrambling sequences can be applied in single DCI multi-TRP (including multi-TRP operation with the same physical cell ID or different physical cell IDs). The new parameter additionaldataScramblingIdentityPUSCH may be added to PUSCH-Config.

[0149] When PUSCH is transmitted by TDM repetition in single DCI multi-TRP, PUSCH repetitions for different TRPs are scrambled with different sequences. FIG. 18 shows PUSCH scrambling according to some embodiments. FIG. 19 shows other PUSCH scrambling according to some embodiments. In each of FIG. 18 and FIG. 19, the scrambling is for PUSCH with repetition in single DCI multi-TRP.

[0150] In single DCI multi-TRP, a CORESET may also be associated with one TRP. A CORESET pool may also be defined for single DCI multi-TRP. The association between a CORESET and a TRP may be defined by an RRC parameter, such as singleDCI-CORESETPoolIndex. When the RRC parameter singleDCI-CORESETPoolIndex is set to 0, the CORESET is transmitted from TRP#A. When the RRC parameter singleDCI-CORESETPoolIndex is set to 1, the CORESET is transmitted from TRP#B.

[0151] For example, when PUSCH transmission is targeted at TRP#A, the existing parameter dataScramblingIdentityPUSCH is applied to PUSCH scrambling. When PUSCH transmission is targeted at TRP#B, the new parameter additionaldataScramblingIdentityPUSCH is applied to PUSCH scrambling. Further, which TRP the PUSCH transmission is targeted at may be identified by the association between the spatial relation of the PUSCH transmission and the TRP (singleDCI-CORESETPoolIndex). In one example, when the spatial relation of the PUSCH transmission is indicated by an SRI, the association between the SRS and the TRP may be defined. For example, a parameter associatedTRP-SRS may be introduced and may be defined by an SRS resource (SRS-Resource) or SRS spatial relation information (SRS-SpatialRelationInfo). In another example, for repeated PUSCH, as shown in FIGS. 18 and 19, which TRP the PUSCH repetition is targeted at and which scrambling sequence is applied to the PUSCH repetition may be predefined or implicitly determined. For example, the first repetition is transmitted to TRP#A, the second repetition is transmitted to TRP#B, and so on.

[0152] In other embodiments, which scrambling sequence is applied to PUSCH transmission is identified by the scheduling CORESET. For PUSCH scheduled by a CORESET with a singleDCI-CORESETPoolIndex equal to 0, the existing dataScramblingIdentityPUSCH is applied to PUSCH scrambling. For PUSCH scheduled by a CORESET with a singleDCI-CORESETPoolIndex equal to 1, the new parameter additionaldataScramblingIdentityPUSCH is applied to PUSCH scrambling.

[0153] The current default beam operation for SRS / PUCCH / PUSCH does not consider multi-TRP operation. In particular, embodiments also provide a default beam operation for PUSCH transmission in a multi-TRP operation scenario.

[0154] Default PUSCH spatial relation in multi-TRP using single DCI 1. Non-repetitive PUSCH In an embodiment, in single DCI multi-TRP, PUSCH may not be constituted by repetition. When the parameter enableDefaultBeamPlForPUSCH0_0 is set to "invalid", it is not assumed that the UE is scheduled by DCI format 0_0 from one TRP where there is no PUCCH resource configured with a spatial relation. If there is at least one PUCCH resource configured with a spatial relation related to the TRP, the spatial relation / path loss reference signal of the PUSCH scheduled by DCI format 0_0 follows the spatial relation of the PUCCH resource having the lowest resource ID related to the TRP.

[0155] When the parameter enableDefaultBeamPlForPUSCH0_0 is set to "enabled", the default spatial relationship of PUSCH may be determined as described below.

[0156] For PUSCH scheduled by DCI formats other than DCI 0_0, another parameter, namely enableDefaultBeamForPUSCH, indicating whether the default beam operation is enabled may be introduced. When enableDefaultBeamForPUSCH is set to "disabled", the PUSCH scheduled by non-DCI format 0_0 follows the (default) spatial relationship of the indicated SRS resource. When enableDefaultBeamForPUSCH is set to "enabled", the PUSCH spatial relationship may be determined as described in the following section. In other examples, when enableDefaultBeamForPUSCH is set to enabled, the spatial relationship of PUSCH may follow the (default) spatial relationship of the SRS to which the SRS resource is related by one (default) spatial relationship, or the PUSCH spatial relationship may follow the (default) spatial relationship of one specific PUCCH resource to which the PUCCH resource is related by a plurality of (default) spatial relationships.

[0157] 1.1 Single TCT state per CORESET In an embodiment, in a single DCI multi-TRP, when the CORESET is composed of only one active TCI state, and the parameter enableDefaultBeamPlForPUSCH0_0 is set to "enabled", or the parameter "enableDefaultBeamForPUSCH" is set to "enabled", the default spatial relationship / path loss reference signal of PUSCH is determined as follows.

[0158] Option 1: Follow the scheduling CORESET. The default spatial relation / path loss reference signal for PUSCH follows the TCI state / QCL assumption of the scheduling CORESET.

[0159] Option 2: Follow one specific CORESET. The default spatial relation / path loss reference signal for PUSCH follows the TCI state / QCL assumption of the CORESET with the lowest ID within the latest slot before the PUSCH transmission in which such CORESET is monitored.

[0160] FIG. 20 shows the default spatial relation of PUSCH without repetition according to some embodiments. In particular, FIG. 20 shows an example of Option 1, where a single TCI is provided per CORESET.

[0161] 1.2 Multiple TCI states per CORESET In an embodiment, in a single DCI multi-TRP, a CORESET may be configured with multiple active TCI states. In this case, the CORESET is related to one TRP. For example, the CORESET may be configured with singleDCI-CORESETPoolIndex. The TCI state is also related to one TRP. For example, the TCI state may be configured with associatedTRP-TCI.

[0162] When the parameter enableDefaultBeamPlForPUSCH0_0 is set to "enabled", or when the parameter "enableDefaultBeamForPUSCH" is set to "enabled", the default spatial relation / path loss reference signal for PUSCH is determined as follows.

[0163] Option 1: Follow one TCI state of the scheduling CORESET. The default spatial relation / path loss reference signal for PUSCH follows the TCI state / QCL assumption of the scheduling CORESET, and the TCI state is related to the same TRP as the scheduling CORESET.

[0164] Option 2: Follow one TCI state of one specific CORESET that has multiple TCI states. The default spatial relation / path loss reference signal for PUSCH follows the TCI state / QCL assumption of the CORESET with the lowest ID among the CORESETS having multiple active TCI states within the latest slot before the PUSCH transmission for which such CORESET is monitored.

[0165] Option 3: Follow the TCI state of one specific CORESET that has only one TCI state. The default spatial relation / path loss reference signal for PUSCH follows the TCI state / QCL assumption of the CORESET with the lowest ID among the CORESETS having only one active TCI state within the latest slot before the PUSCH transmission for which such CORESET is monitored.

[0166] Figure 21 shows other default spatial relations of non-repetitive PUSCH according to some embodiments. In particular, Figure 21 shows an example of Option 1, where multiple TCIs are provided per CORESET.

[0167] 2. Repetitive PUSCH In an embodiment, in single DCI multi-TRP, PUSCH may be constituted by repetition. Another parameter indicating whether a plurality of default beams are valid for PUSCH with repetition, that is, enableMultipleDefaultBeamsForPUSCH, may be introduced. In this case, when the parameter enableDefaultBeamPlForPUSCH0_0 is set to "valid", or when the parameter enableMultipleDefaultBeamsForPUSCH is set to "valid", the default spatial relationship of PUSCH may be determined as described in the following section. In other examples, when enableMultipleDefaultBeamsForPUSCH is set to valid, the PUSCH spatial relationship may follow the (default) spatial relationship of the SRS whose SRS resource is related to a plurality of (default) spatial relationships, or may follow the (default) spatial relationship of one specific PUCCH resource whose PUCCH resource is related to a plurality of (default) spatial relationships.

[0168] 2.1 Single TCT state per CORESET In an embodiment, in single DCI multi-TRP, when the CORESET is constituted by only one active TCI state, the CORESET is related to one TRP. For example, the CORESET may be constituted by singleDCI-CORESETPoolIndex. For PUSCH transmission with repetition, when the parameter enableDefaultBeamPlForPUSCH0_0 is set to "valid", or when the parameter "enableMultipleDefaultBeamsForPUSCH" is set to "valid", a plurality of default spatial relationships / path loss reference signals are applied. The default spatial relationship / path loss reference signal of PUSCH is determined as follows.

[0169] Option 1: Multiple spatial relations of PUSCH dynamically and independently follow one CORESET. The first default spatial relation / path loss reference signal of PUSCH follows the TCI state / QCL assumption of the CORESET with the lowest ID among the CORESETs where singleDCI-CORESETPoolIndex is set to 0. The second default spatial relation / path loss reference signal of PUSCH follows the TCI state / QCL assumption of the CORESET with the lowest ID among the CORESETs where singleDCI-CORESETPoolIndex is set to 1.

[0170] Option 2: Multiple spatial relations of PUSCH semi-statically follow multiple TCI states indicated by one TCI state code point. The default spatial relation / path loss reference signal of PUSCH sequentially follows the TCI state corresponding to the lowest code point among the TCI code points including two different TCI states activated for PDSCH.

[0171] FIG. 22 shows the default spatial relations of iterative PUSCH according to some embodiments. FIG. 22 shows an example of Option 1, where a single TCI is provided per CORESET.

[0172] FIG. 23 shows other default spatial relations of iterative PUSCH according to some embodiments. In particular, FIG. 23 shows an example of Option 2, where a single TCI is provided per CORESET.

[0173] 2.2 Multiple TCI States per CORESET In an embodiment, in a single DCI multi-TRP, a CORESET may be composed of multiple active TCI states. In this case, the CORESET is related to one TRP. For example, the CORESET may be composed of singleDCI-CORESETPoolIndex. The TCI state is also related to one TRP. For example, the TCI state may be composed of associatedTRP-TCI.

[0174] For repeated PUSCH transmissions, if the parameter enableDefaultBeamPlForPUSCH0_0 is set to "enabled" or the parameter "enableMultipleDefaultBeamsForPUSCH" is set to "enabled", multiple default spatial relations / path loss reference signals are applied. The default spatial relation / path loss reference signal for PUSCH is determined as follows.

[0175] Option 1: Multiple spatial relations of PUSCH dynamically follow one CORESET. The default spatial relation / path loss reference signal for PUSCH sequentially follows the TCI state / QCL assumption of the CORESET with the lowest ID among the CORESETs having multiple active TCI states in the latest slot before the PUSCH transmission in which such CORESET is monitored.

[0176] Option 2: Multiple spatial relations of PUSCH semi-statically follow multiple TCI states indicated by one TCI state code point. The default spatial relation / path loss reference signal for PUSCH sequentially follows the TCI state corresponding to the lowest code point among the TCI code points including two different TCI states activated for PDSCH.

[0177] Option 3: Multiple spatial relations of PUSCH follow the scheduling CORESET. If the scheduling CORESET is composed of multiple active TCI states, the default spatial relation / path loss reference signal for PUSCH sequentially follows the TCI state of the scheduling CORESET.

[0178] FIG. 24 shows the default spatial relations of repeated PUSCH according to some embodiments. FIG. 24 shows an example of Option 1, where multiple TCIs are provided per CORESET.

[0179] FIG. 25 shows other default spatial relationships of the repeated PUSCH according to some embodiments. In particular, FIG. 25 shows an example of Option 2, where multiple TCIs are provided per CORESET.

[0180] While the embodiments have been described with reference to specific example embodiments, it will be apparent that various changes and modifications can be made to these embodiments without departing from the broader scope of the disclosure. Accordingly, the specification and drawings are to be considered in an illustrative rather than a limiting sense. The accompanying drawings, which form a part of this specification, illustrate, by way of example, without limitation, specific embodiments in which the subject matter may be practiced. The example embodiments are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived without departing from the scope of the disclosure, such that structural and logical substitutions and changes may be made. Accordingly, this detailed description is not to be taken in a limiting sense, and the scope of the various embodiments is defined only by the appended claims, along with the full scope of equivalents to which such claims are entitled.

[0181] The subject matter is here referred to individually or collectively as "embodiments" merely for convenience and without intention of limiting the scope of the application to any single inventive concept, where in fact more than one inventive concept may be disclosed. Accordingly, while specific embodiments are illustrated and described herein, it should be recognized that any configuration calculated to achieve the same purpose may be substituted for the specific embodiments shown. The disclosure is intended to cover any adaptations or variations of the various embodiments. Combinations of the above-described embodiments with other embodiments not specifically described herein will be apparent to those skilled in the art upon review of the above description.

[0182] In this document, the singular is used to include more than one, independent of any other examples or usages of "at least one" or "one or more", as is common in patent documents. In this document, the term "or" is used to denote a non-exclusive disjunction such that "A or B" includes "not B but A", "not A but B", and "A and B", unless otherwise specified. In this document, the terms "including" and "in which" are used as the plain English equivalents of the terms "comprising" and "wherein", respectively. Also, in the following claims, the terms "including" and "comprising" are open-ended, i.e., a system, UE, article, composition, formulation, or process that includes elements in addition to those recited after such terms in a claim is still considered to fall within the scope of that claim. Further, in the following claims, the terms "first", "second", "third", etc. are used as mere labels and are not intended to impose numerical requirements on their subjects.

[0183] The abstract of the disclosure is provided to comply with 37 C.F.R. § 1.72(b), which requires an abstract that enables the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Further, in the foregoing detailed description, it can be seen that various features are grouped together in one embodiment for purposes of streamlining the disclosure. This method of disclosure should not be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as reflected in the following claims, the subject matter of the invention lies in less than all of the features of a single disclosed embodiment. Accordingly, the following claims are incorporated into the detailed description, with each claim standing on its own as a separate embodiment.

Claims

1. An apparatus for a transmit-receive point (TRP), comprising: determining that a plurality of downlink control information (DCI) is to be used for multi-TRP operation with a user equipment (UE) for a plurality of TRPs including the TRP; indicating to the UE the number of spatial relationships used for uplink (UL) transmission, wherein the UL transmission is selected from a set of UL transmissions including a physical uplink control channel (PUCCH), a physical uplink shared channel (PUSCH), and a sounding reference signal (SRS) from the UE; indicating to the UE a spatial relationship between reception of a control resource set (CORESET) and the UL transmission, wherein the spatial relationship depends on the number of spatial relationships used, and the spatial relationship is based on an association depending on whether a single spatial relationship or a plurality of spatial relationships is used, and the association is a default association, an explicit association, and an implicit association between each TRP and at least one of a CORESET or a transmission configuration indication (TCI) state; receiving the UL transmission from the UE based on the spatial relationship; a processing circuit configured to perform the above; a memory configured to store the spatial relationship; and an apparatus including the above.

2. The processing circuit is configured to avoid transmitting an update of the spatial relationship to the UE for the PUCCH or SRS in response to a determination that a default beam operation is effective for the UL transmission, and schedule the PUSCH via a DCI format even when a PUCCH resource is unavailable or when the PUCCH resource is configured but has no configured spatial relationship, according to the apparatus of claim 1.

3. For SRS transmission, each SRS resource is associated with a different spatial relationship, and the association of each periodic, semi-persistent, or aperiodic SRS transmission with a different TRP is defined at the SRS resource level or SRS resource set level by at least one of a radio resource control (RRC) parameter associatedCORESETPool-SRS, a medium access control (MAC) control element (MAC-CE), or an implicit association by a scheduling PDCCH indicating which CORESET pool is associated with the SRS resource or SRS resource set, or ​ Regarding PUCCH transmission, each PUCCH is associated with a different spatial relation, the association of each PUCCH with a different TRP is defined at the PUCCH resource level, PUCCH resource set level or PUCCH resource group level by at least one of the RRC parameter associatedCORESETPool-PUCCH, PUCCH resource group identifier (ID) or PUCCH resource set ID, media access control (MAC) control element (MAC-CE), which indicates which CORESET pool is related to the PUCCH resource level, PUCCH resource set level or PUCCH resource group level, or, when the PUCCH resource is indicated by one of the DCIs, by the implicit association by the CORESET pool of the scheduling PDCCH. The apparatus according to claim 1, wherein the apparatus is at least one of them.

4. Regarding SRS transmission the radio resource control (RRC) parameter enableDefaultBeamPlForSRS is valid, and when the spatial relation is not configured for SRS, the default spatial relation of SRS transmission is applied, the default spatial relation is in accordance with the TCI state of the CORESET with the lowest index among the CORESETs in which the configured CORESETPoolindex is the same as the CORESET pool related to SRS in the latest slot monitored by the UE, and when there is no SRS transmission, the latest slot is before the corresponding PUSCH transmission. The CORESET pool related to SRS is indicated by the RRC parameter associatedCORESETPool-SRS, or is the same as the scheduling CORESET when SRS is indicated by one of the DCIs. For the aperiodic SRS triggered by one of the DCIs, When the default spatial relation is that no CORESET is configured in the active bandwidth part (BWP) within the CORESET pool associated with the SRS resource according to the TCI state of the scheduling CORESET, the default spatial relation follows the active TCI state having the lowest TCI identifier (ID) of the physical downlink shared channel (PDSCH) within the CORESET pool associated with the SRS resource, or For PUCCH transmission, when the RRC parameter enableDefaultBeamPlForPUCCH is valid and the spatial relation is not configured for the PUCCH, the default spatial relation for PUCCH transmission is applied, the default spatial relation follows the TCI state of the CORESET with the lowest index among the CORESETs having the same configured CORESETPoolindex as the CORESET pool associated with the PUCCH in the latest slot monitored by the UE where one or more CORESETs with the configured CORESETPoolindex being the same as the CORESET pool associated with the PUCCH are monitored, the CORESET pool associated with the PUCCH is indicated by the RRC parameter associatedCORESETPool - PUCCH, or is the same as the scheduling CORESET if the PUCCH is indicated by one of the DCIs, when the default spatial relation is that no CORESET is configured in the active bandwidth part (BWP) within the CORESET pool associated with the SRS resource according to the TCI state of the scheduling CORESET, the default spatial relation follows the activated TCI state having the lowest TCI ID of the PDSCH within the CORESET pool associated with the PUCCH The apparatus according to claim 1, wherein at least one of the above is satisfied.

5. Regarding the radio resource control (RRC) parameter enableDefaultBeamPlForPUSCH0_0 set to invalid, The processing circuit is configured to avoid scheduling of the UE caused by DCI format 0_0 from one of the TRPs indicated by the RRC parameter CORESETPoolIndex for which the PUCCH resource is not configured in a spatial relationship. When there is at least one PUCCH resource configured in a spatial relationship with respect to the one of the TRPs, the spatial relationship of the PUSCH scheduled by DCI format 0_0 shall follow the spatial relationship of the PUCCH resource having the lowest resource identification information (ID) with respect to the one of the TRPs indicated by the RRC parameters CORESETPoolIndex and associatedCORESETPool-PUCCH. Regardless of whether the PUCCH resource is configured on the scheduling TRP and regardless of whether the PUCCH resource configured on the scheduling TRP is configured in a specific spatial relationship, the default spatial relationship of the PUSCH scheduled by DCI format 0_0 shall follow one of the TCI states of the CORESET having the lowest ID within the same CORESET pool as the CORESET pool of the scheduling CORESET, or the TCI state of the scheduling CORESET, within the latest slot before the PUSCH transmission for which the CORESET having the lowest ID is monitored. One of them is Regarding the effectively set RRC parameter enableDefaultBeamPlForPUSCH0_0 The default spatial relationship of the PUSCH scheduled by DCI format 0_0 shall follow the TCI state of the CORESET having the lowest ID within the same CORESET pool as the CORESET pool of the scheduling CORESET within the latest slot before the PUSCH transmission for which the CORESET having the lowest ID is monitored. The default spatial relationship of the PUSCH scheduled by DCI 0_0 shall follow the TCI state of the scheduling CORESET, or When there is no PUCCH resource configured for the scheduling TRP that transmits the scheduling CORESET, the default spatial relationship is within the latest slot before the PUSCH transmission in which the CORESET with the lowest ID is monitored, according to the TCI state of the CORESET with the lowest ID in the same CORESET pool as the CORESET pool of the scheduling CORESET. When there is a PUCCH resource configured but no spatial relationship at the scheduling TRP, the default spatial relationship follows the default spatial relationship of the PUCCH resource on the scheduling TRP. The apparatus according to claim 1, which is one of the above.

6. For a PUSCH scheduled by a DCI format other than 0_0, the spatial relationship of the PUSCH follows the spatial relationship of the SRS resource indicated by the SRS resource indicator (SRI) or the SRS resource configured by the radio resource control (RRC) parameter when only one SRS resource is configured. When the RRC parameter enableDefaultBeamPlForSRS is set to "enabled", the PUSCH transmission follows the default spatial relationship of the corresponding SRS resource. When there is no SRS transmission, assuming that the SRS is transmitted in the first slot of the PUSCH transmission, the default SRS spatial relationship is derived. The apparatus according to claim 1.

7. For all PUSCH transmissions scheduled by all DCI formats, the default beam operation is indicated by the radio resource control (RRC) enableDefaultBeamPlForPUSCH. When the RRC enableDefaultBeamPlForPUSCH is set to enabled, the default spatial relationship of the PUSCH transmission is When only one SRS resource is configured, the SRS resource indicated by the SRS resource indicator (SRI) or the SRS resource configured by the RRC parameter. The spatial relationship of the PUCCH resource with the lowest resource identification information (ID) related to the same CORESET pool as the scheduling CORESET. In the latest slot before PUSCH transmission in which the CORESET with the lowest ID is monitored, the TCI state of the CORESET with the lowest ID in the same CORESET pool as the CORESET pool of the scheduling CORESET, or the TCI state of the scheduling CORESET The apparatus according to claim 1, wherein it is one of the above.

8. The SRS trigger state indicated by the code point of the SRS request field in the DCI is specific to the TRP such that different SRS resource sets are triggered for each TRP with different code points of the SRS request field, or triggers the same SRS resource set but has different slot offsets for different TRPs The apparatus according to claim 1, wherein it is one of the above.

9. The association between each SRS and the TRP is defined at the SRS resource set level or the SRS resource level or by the radio resource control (RRC) parameter associatedCORESETPool-SRS, multiple SRS resource sets are configured for the same usage, and the same usage is selected from a set including codebook-based transmission, non-codebook-based transmission, antenna switching, and beam management, the SRS resource sets using the same usage are associated with different TRPs, for codebook-based transmission, when scheduling PUSCH transmission, the SRS resource indicator (SRI) field indicates a specific SRS resource within the SRS resource set associated with the scheduling TRP, or one of the DCIs indicates the SRS resource set, or for non-codebook-based transmission, different channel state information resource (CSI-RS) resource transmissions by different TRPs are associated with different SRS resource sets, and the SRI field or one of the fields of the DCI indicates one or more SRS resources within the SRS resource set associated with the scheduling TRP The apparatus according to claim 1, wherein it is as above.

10. For PUSCH transmission, The processing circuit is configured to apply a scrambling sequence and indicate the scrambling sequence to the UE in the radio resource control (RRC) parameter additionaldataScramblingIdentityPUSCH within the PUSCH-Config message. When PUSCH transmission is scheduled by a CORESET having a CORESETPoolIndex equal to 0, the processing circuit is configured to apply the RRC parameter dataScramblingIdentityPUSCH to PUSCH scrambling. When PUSCH transmission is scheduled by a CORESET having a CORESETPoolIndex equal to 1, the processing circuit is configured to apply the RRC parameter additionaldataScramblingIdentityPUSCH to PUSCH scrambling. Time-domain modulated PUSCH transmission repetitions targeting different TRPs are scrambled with different sequences. Each CORESET is associated with a different TRP, the association between the CORESET and the TRP is indicated by the radio resource control (RRC) parameter singleDCI-CORESETPoolIndex, and PUCCH scrambling depends on the TRP targeted by the PUSCH transmission indicated by the RRC parameter singleDCI-CORESETPoolIndex. The spatial relationship of the PUSCH transmission is indicated by the sounding reference signal (SRS) resource indicator (SRI), the association between the SRS and the TRP is indicated by the RRC parameter associatedTRP-SRS or SRS spatial relationship information within the SRS resource, or for repeated PUSCH transmissions, which TRP a specific PUSCH repetition targets and which scrambling sequence is applied to the specific PUSCH repetition is predefined or implicit, or Which scrambling sequence is applied to PUSCH transmission is identified by the scheduling CORESET. For PUSCH scheduled by a CORESET with a singleDCI-CORESETPoolIndex equal to 0, the existing dataScramblingIdentityPUSCH should be applied to PUSCH scrambling. For PUSCH scheduled by a CORESET with a singleDCI-CORESETPoolIndex equal to 1, the new parameter additionaldataScramblingIdentityPUSCH should be applied to PUSCH scrambling The apparatus according to claim 1, which is at least one of them

11. An apparatus of a transmission and reception point (TRP), Determining that a single downlink control information (DCI) is used for multi-TRP operation with a user equipment (UE) for a plurality of TRPs including the TRP; A processing circuit configured to instruct the UE for non-repetitive physical uplink shared channel (PUSCH) transmission; Regarding the radio resource control (RRC) parameter enableDefaultBeamPlForPUSCH0_0 set to invalid, Assuming no scheduling by DCI format 0_0 from one of the TRPs where the PUCCH resource is not configured in a spatial relationship, When there is at least one PUCCH resource configured in a spatial relationship for the one of the TRPs, the spatial relationship of the PUSCH transmission scheduled by DCI format 0_0 follows the spatial relationship of the PUCCH resource having the lowest resource identification information (ID) for the one of the TRPs; The RRC parameter enableDefaultBeamForPUSCH indicates whether the default beam operation is enabled for PUSCH transmission scheduled by a DCI format other than DCI 0_0, or For the case where the radio resource control (RRC) parameter enableDefaultBeamPlForPUSCH0_0 or the RRC parameter enableDefaultBeamForPUSCH is effectively set, and the control resource set (CORESET) is configured with only one active transmission configuration indication (TCI) state, the default spatial relation for PUSCH transmission follows one of the scheduling TCI states of the scheduling CORESET, or another TCI state of the CORESET with the lowest ID within the latest slot before the PUSCH transmission for which the CORESET with the lowest ID is monitored. Receiving an uplink (UL) transmission from the UE based on the spatial relation A processing circuit configured to perform A memory configured to store the default spatial relation An apparatus including.

12. For a CORESET associated with one TRP and configured with multiple active TCI states by the RRC parameter singleDCI-CORESETPoolIndex, the active TCI state of the TCI is associated with the one TRP and configured by the RRC parameter associatedTRP-TCI. The apparatus according to claim 11.

13. When the RRC parameter enableDefaultBeamPlForPUSCH0_0 or enableDefaultBeamForPUSCH is effectively set, the default spatial relation that the UE should follow is The scheduling TCI state associated with the same TRP as the scheduling CORESET, Within the latest slot before the PUSCH transmission for which the CORESET is monitored, among the CORESETs each having multiple active TCI states, it is another TCI state of the CORESET with the lowest ID, another TCI state associated with the same TRP as the scheduling CORESET, or Within the latest slot before the PUSCH transmission for which the CORESET is monitored, among the CORESETs each having a single active TCI state, it is another TCI state of the CORESET with the lowest ID, another TCI state associated with the same TRP as the scheduling CORESET The apparatus according to claim 12.

14. For PUSCH transmission constituted by repetition, the processing circuit is configured to indicate whether a plurality of default beams are enabled via the RRC parameter enableMultipleDefaultBeamsForPUSCH, the apparatus according to claim 11.

15. For a CORESET associated with one TRP and configured with one active TCI state by the RRC parameter singleDCI-CORESETPoolIndex, the single active TCI state is associated with the one TRP and configured by the RRC parameter associatedTRP-TCI, For PUSCH transmission with repetition, when the RRC parameter enableDefaultBeamPlForPUSCH0_0 or enableMultipleDefaultBeamsForPUSCH is set to be effective, the default spatial relationship of the UE is to follow the first default spatial relationship using the TCI state of the CORESET having the lowest ID among the CORESETs where singleDCI-CORESETPoolIndex is set to 0, and to follow the second default spatial relationship using the TCI state of the CORESET having the lowest ID among the CORESETs where singleDCI-CORESETPoolIndex is set to 1, or to sequentially follow the TCI state corresponding to the lowest code point among the TCI code points including two different TCI states activated for PDSCH transmission is the apparatus according to claim 14.

16. For a CORESET associated with one TRP and configured with a plurality of active TCI states by the RRC parameter singleDCI-CORESETPoolIndex, the active TCI states are associated with the one TRP and configured by the RRC parameter associatedTRP-TCI, the apparatus according to claim 14.

17. For PUSCH transmission with repetition, when the RRC parameter enableDefaultBeamPlForPUSCH0_0 or enableMultipleDefaultBeamsForPUSCH is set to be effective, the default spatial relationship of the UE is In the latest slot before PUSCH transmission in which the CORESET with the lowest ID is monitored, the TCI state of the CORESET with the lowest ID among the CORESETs having multiple active TCI states, or Among the TCI code points including two different TCI states activated for PDSCH transmission, the TCI state corresponding to the lowest code point, or When the scheduling CORESET is composed of multiple active TCI states, the TCI state of the scheduling CORESET The apparatus according to claim 16, which follows in order.

18. A computer program including instructions executed by one or more processors of a transmitting and receiving point (TRP), When the instructions are executed, the one or more processors Determine that a plurality of downlink control information (DCI) is used for multi-TRP operation with a user equipment (UE) for a plurality of TRPs including the TRP, Indicate to the UE the number of spatial relationships used for uplink (UL) transmission, the UL transmission being selected from a set of UL transmissions including a physical uplink control channel (PUCCH), a physical uplink shared channel (PUSCH), and a sounding reference signal (SRS) from the UE, Indicate to the UE the spatial relationship between reception of a control resource set (CORESET) and the UL transmission, the spatial relationship depending on the number of spatial relationships used, the spatial relationship being based on an association depending on whether a single spatial relationship or a plurality of spatial relationships is used, the association being a default association, an explicit association, and an implicit association between each TRP and at least one of a CORESET or a transmission configuration indication (TCI) state, Receive the UL transmission from the UE based on the spatial relationship A computer program that configures the TRP to perform.

19. In response to a determination that a default beam operation is effective for the UL transmission, when the instructions are executed, the one or more processors Avoid transmitting an update of the spatial relationship to the UE for the PUCCH or SRS, The computer program according to claim 18, further configuring the TRP to schedule PUSCH via a DCI format even when a PUCCH resource is unavailable or when the configured PUCCH resource has no configured spatial relationship.

20. For a PUSCH scheduled by a DCI format other than 0_0, the spatial relationship of the PUSCH follows the spatial relationship of the SRS resource indicated by an SRS resource indicator (SRI) or the SRS resource configured by a radio resource control (RRC) parameter when only one SRS resource is configured. The computer program according to claim 19, wherein when the RRC parameter enableDefaultBeamPlForSRS is set to "enabled", PUSCH transmission follows the default spatial relationship of the corresponding SRS resource, and when there is no SRS transmission, the default SRS spatial relationship is derived assuming that SRS is transmitted in the first slot of PUSCH transmission.

21. A computer-readable storage medium storing the computer program according to any one of claims 18 to 20.

Images