Method, apparatus and system for enhanced control signaling for ultra-reliable transmission
By adopting enhanced control signaling method based on service type in wireless communication, the problem of difficulty in realizing super reliable transmission in the prior art is solved, and effective control signaling management for different service types is realized, and transmission reliability and delay performance are improved.
Patent Information
- Application Number
- CN202510092129.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2019-11-06
- Filing Date
- 2020-01-06
- Publication Date
- 2025-04-04
AI Technical Summary
Existing wireless communication technologies are difficult to effectively achieve ultra-reliable transmission, especially when it is necessary to meet the delay and reliability requirements of different service types (such as eMBB and URLLC).
By implementing a service-type enhanced control signaling method in a wireless transmit/receive unit (WTRU), including receiving a physical downlink shared channel (PDSCH) associated with different types of services in different time slots or micro-time slots, and determining a HARQ codebook acknowledge index (HCAI) based on the properties of the PDSCH to generate and transmit corresponding HARQ-ACK information.
This method can effectively manage control signaling of different service types, improve transmission reliability and delay performance, and meet the needs of ultra-reliable transmission.
Smart Images

Figure CN119766402A_ABST
Abstract
Description
This application is a divisional application of Chinese patent application No. 202080008380.7, filed on July 16, 2020, entitled “Methods, Devices, and Systems for Enhanced Control Signaling for Ultra-Reliable Transmission”, the contents of which are incorporated herein by reference as if fully set forth herein. CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority to U.S. patent application serial number 62 / 790,428 filed on January 9, 2019, U.S. patent application serial number 62 / 875,227 filed on July 17, 2019, U.S. patent application serial number 62 / 886,035 filed on August 13, 2019, and U.S. patent application serial number 62 / 931,389 filed on November 6, 2019, the contents of each of the above patent applications are incorporated herein by reference as if fully set forth herein. Technical Field
[0002] Embodiments disclosed herein generally relate to wireless communications and, for example, to methods, apparatus, and systems for enhanced control signaling, such as based on service type (eg, ultra-reliable transmission). Related fields
[0003] The principle of network slicing can be exploited to implement ad hoc networks, which can allow ultra-reliable transmission. Summary of the invention
[0004] Methods and apparatus for operation by a wireless transmit / receive unit (WTRU) in a network are provided. In one embodiment, a method may include the WTRU receiving a first physical downlink shared channel (PDSCH) associated with a first type of service or a first priority level in a first time slot or a first mini-time slot, and receiving a second PDSCH associated with a second type of service or a second priority level in a second time slot or a second mini-time slot, and determining a first HARQ codebook acknowledgement index (HCAI) based on an attribute of the first PDSCH or control information associated with the first PDSCH, and determining a second HCAI based on an attribute of the second PDSCH or control information associated with the second PDSCH. The method may also include: for a subsequent time slot or a subsequent mini-time slot, generating a first physical uplink control channel (PUCCH) including first HARQ-ACK information according to the first HCAI and a second PUCCH including second HARQ-ACK information according to the second HCAI; and sending the first PUCCH and the second PUCCH. BRIEF DESCRIPTION OF THE DRAWINGS
[0005] A more detailed understanding can be obtained from the following detailed description given by way of example in conjunction with the accompanying drawings. The drawings in the specification are examples. Therefore, the drawings and detailed description should not be considered limiting, and other equivalent examples are feasible and possible. In addition, the same reference numerals in the drawings indicate the same elements, and among them: Figure 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented; Figure 1B is a diagram showing that according to an embodiment, Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) for use within a communication system is shown; Figure 1C is a diagram showing that according to an embodiment, Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system shown; Figure 1D is a diagram showing that according to an embodiment, Figure 1A A system diagram of another exemplary RAN and another exemplary CN used within the communication system shown; Figure 2 is a diagram showing time-frequency resources used to carry control signaling for ultra-reliable low-latency communication (URLS) / enhanced URLLC (eURLLC) services and enhanced mobile broadband (eMBB) services; Figure 3 is a diagram showing a representative bit field set for an eMBB service or a URLLC / eURLLC service; Figure 4 is a diagram showing other representative bit field sets for eMBB service or URLLC / eURLLC service; Figure 5 is a diagram showing different HARQ feedback timings; Figure 6 is a diagram showing a representative process of using feedback information (e.g., HARQ codebook acknowledgement index (HCAI)); Figure 7 is a diagram showing a representative transmission process after conflict determination; Figure 8 is a diagram showing a representative WTRU intra-prioritization process; Fig. 9 is a diagram showing a representative process for using overflow resources; Fig.10 is a flow chart illustrating a representative process for using feedback information (eg, HCAI); Fig.11 is a flow chart illustrating another representative process of using feedback information (eg, HCAI); Fig.12 is a flow chart illustrating a representative process for time domain overlap (e.g., time domain overlap of eMBB and URLLC or enhanced URLLC information / control signaling); Fig.13 is a flow chart illustrating a representative process for using overflow resources for deprioritized information / control signaling (e.g., HARQ acknowledgment (HARQ-ACK)); Fig.14 is a flow chart illustrating a representative process for using bit field interpretation (e.g., based on service type); Fig.15 is a flow chart illustrating a representative process for HARQ feedback (eg, based on service type); Fig.16 is a flowchart showing a representative overwrite process; Fig.17 is a flow chart illustrating a representative process for avoiding anticipated conflicts; Fig.18 is a flow chart showing a representative multiplexing process; and Fig.19 is a flow chart illustrating a representative process, eg, for transmission of uplink control information (UCI). DETAILED DESCRIPTION Example network for implementation of embodiments
[0006] Figure 1A 1 is a diagram showing an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources including wireless bandwidth. For example, the communication system 100 may use one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word DFT-spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filter bank multi-carrier (FBMC), etc.
[0007] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112, although it should be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network components. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, any of the WTRUs 102a, 102b, 102c, 102d may be referred to as a “station” and / or “STA”, which may be configured to transmit and / or receive wireless signals, and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices working in an industrial and / or automated process chain environment), consumer electronic devices, and devices working on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, 102d may be interchangeably referred to as a UE.
[0008] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to facilitate access to one or more communication networks (e.g., CN 106 / 115, Internet 110, and / or other networks 112) by wirelessly interfacing with at least one of the WTRUs 102a, 102b, 102c, 102d. For example, the base stations 114a, 114b may be base transceiver stations (BTS), Node Bs, eNode Bs (terminals), home node Bs (HNBs), home eNode Bs (HeNBs), gNBs, NR node Bs, site controllers, access points (APs), wireless routers, and the like. Although each of the base stations 114a, 114b is depicted as a single component, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network components.
[0009] The base station 114a may be part of the RAN 104 / 113, and the RAN may also include other base stations and / or network components (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, and the like. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies called cells (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a specific geographic area that is relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, that is, each transceiver corresponds to a sector of the cell. In an embodiment, the base station 114a may use multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, by using beamforming, signals may be transmitted and / or received in a desired spatial direction.
[0010] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).
[0011] More specifically, as described above, the communication system 100 may be a multiple access system and may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA, among others. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117. WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed Downlink (DL) Packet Access (HSDPA) and / or High Speed UL Packet Access (HSUPA).
[0012] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro).
[0013] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology that may use new radio (NR) to establish the air interface 116, such as NR radio access.
[0014] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may jointly implement LTE radio access and NR radio access (e.g., using dual connectivity (DC) principles). Thus, the air interface used by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., terminals and gNBs).
[0015] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), and GSM EDGE (GERAN), among others.
[0016] Figure 1AThe base station 114b in the example may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may use any appropriate RAT to facilitate wireless connectivity in a local area, such as a business location, a residence, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may establish a wireless local area network (WLAN) by implementing a radio technology such as IEEE 802.11. In an embodiment, the base station 114b and the WTRUs 102c, 102d may establish a wireless personal area network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, and the like). As Figure 1A As shown, the base station 114b may be directly connected to the Internet 110. Thus, the base station 114b does not need to access the Internet 110 via the CN 106 / 115.
[0017] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, Internet connectivity, video distribution, etc., and / or may perform advanced security functions such as user authentication. Although in Figure 1A Although not shown, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT or a different RAT as the RAN 104 / 113. For example, in addition to being connected to the RAN 104 / 113 employing NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.
[0018] The CN 106 / 115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer network devices that use common communication protocols, such as TCP, User Datagram Protocol (UDP), and / or IP in the Transmission Control Protocol / Internet Protocol (TCP / IP) Internet protocol suite. The networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, where the one or more RANs may use the same RAT or a different RAT as the RAN 104 / 113.
[0019] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.
[0020] Figure 1B is a system diagram showing an exemplary WTRU 102. Figure 1B As shown, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a numeric keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or peripherals 138. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.
[0021] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, however it should be appreciated that the processor 118 and the transceiver 120 may also be integrated together in an electronic package or chip.
[0022] The transmit / receive component 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive component 122 may be an antenna configured to transmit and / or receive RF signals. As an example, in another embodiment, the transmit / receive component 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, the transmit / receive component 122 may be configured to transmit and / or receive RF and light signals. It should be appreciated that the transmit / receive component 122 may be configured to transmit and / or receive any combination of wireless signals.
[0023] Although in Figure 1B 102 as a single component, the WTRU 102 may include any number of transmit / receive components 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive components 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.
[0024] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive component 122 and to demodulate signals received by the transmit / receive component 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers that allow the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.
[0025] The processor 118 of the WTRU 102 may be coupled to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data from these components. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store information in any suitable memory such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from and store data in memories that are not physically located in the WTRU 102, such as, for example, a server or a home computer (not shown).
[0026] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control power for use by other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (Ni-Cd), nickel-zinc (Ni-Zn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
[0027] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) related to the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be appreciated that the WTRU 102 may acquire location information via any suitable positioning method while remaining consistent with an embodiment.
[0028] The processor 118 may also be coupled to other peripheral devices 138, wherein the peripheral devices may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Modules, frequency modulation (FM) radio units, digital music players, media players, video game console modules, Internet browsers, virtual reality and / or augmented reality (VR / AR) devices, and activity trackers, etc. The peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geographic location sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors, etc.
[0029] The processor 118 of the WTRU 102 may be operable to communicate with various peripheral devices 138, including, for example, any of: the one or more accelerometers, the one or more gyroscopes, the USB port, other communication interfaces / ports, the display and / or other video / audio indicators, to implement representative embodiments disclosed herein.
[0030] The WTRU 102 may include a full-duplex radio in which reception or transmission of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous for the radio. A full-duplex radio may include an interference management unit that reduces and / or substantially eliminates self-interference by means of hardware (e.g., chokes) or by signal processing by a processor (e.g., a separate processor (not shown) or by the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio that transmits and receives some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)).
[0031] Figure 1C 1 is a system diagram showing the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c using an E-UTRA radio technology over the air interface 116. The RAN 104 may also be in communication with the CN 106.
[0032] The RAN 104 may include eNode-Bs 160a, 160b, 160c, however it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.
[0033] Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in the UL and / or DL, etc. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.
[0034] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the aforementioned components is described as being part of the CN 106, it should be appreciated that any of these components may be owned and / or operated by an entity other than the CN operator.
[0035] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, performing bearer activation / deactivation processing, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.
[0036] The SGW 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may also perform other functions, such as anchoring the user plane during an inter-eNB handover, triggering paging processing when DL data is available for the WTRUs 102a, 102b, 102c, and managing and storing the contexts of the WTRUs 102a, 102b, 102c, and the like.
[0037] The SGW 164 may be connected to the PGW 146, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
[0038] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include or communicate with an IP gateway, such as an IP Multimedia Subsystem (IMS) server, and the IP gateway may serve as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.
[0039] Although in Figures 1A-1D Although the WTRU is described as a wireless terminal, it should be appreciated that in certain representative embodiments, such a terminal may use a (eg, temporary or permanent) wired communication interface with a communication network.
[0040] In a representative embodiment, the other network 112 may be a WLAN.
[0041] A WLAN using an infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may access or be connected to a distributed system (DS) or other types of wired / wireless networks that send traffic into and / or out of the BSS. Traffic originating from outside the BSS and destined for the STA may arrive through the AP and be delivered to the STA. Traffic originating from the STA and destined for a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Traffic between STAs within the BSS may be sent through the AP, for example, when the source STA may send traffic to the AP and the AP may deliver traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. The point-to-point traffic may be sent using a direct link establishment (DLS) between the source and destination STAs (e.g., directly therebetween). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z channelized DLS (TDLS)). For example, a WLAN using an independent BSS (IBSS) mode does not have an AP, and STAs (eg, all STAs) within or using the IBSS can communicate directly with each other. Here, the IBSS communication mode may sometimes be referred to as an "ad-hoc" communication mode.
[0042] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP may transmit a beacon on a fixed channel (e.g., a primary channel). The primary channel may have a fixed width (e.g., a bandwidth of 20 MHz) or a width that is dynamically set via signaling. The primary channel may be a working channel of the BSS and may be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access (CSMA / CA) with collision avoidance (e.g., in an 802.11 system) may be implemented. For CSMA / CA, STAs (e.g., each STA) including the AP may sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, the particular STA may back off. In a specified BSS, there is one STA (e.g., only one station) transmitting at any given time.
[0043] A high throughput (HT) STA may communicate using a 40 MHz wide channel (eg, by combining a 20 MHz wide primary channel with a 20 MHz wide adjacent or non-adjacent channel to form a 40 MHz wide channel).
[0044] Very high throughput (VHT) STA can support channels with widths of 20MHz, 40MHz, 80MHz and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. A 160MHz channel can be formed by combining 8 continuous 20MHz channels or by combining two discontinuous 80MHz channels (this combination can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data can be transmitted and passed through a segment parser, which can separate the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be performed separately on each stream. The stream can be mapped on two 80MHz channels, and the data can be transmitted by the STA performing the transmission. At the receiver of the STA performing the reception, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).
[0045] 802.11af and 802.11ah support working modes below 1 GHz. Compared with 802.11n and 802.11ac, the channel working bandwidth and carrier used in 802.11af and 802.11ah are reduced. 802.11af supports 5MHz, 10MHz and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support meter type control / machine type communication (MTC) (e.g., MTC devices in macro coverage areas). MTC devices can have certain capabilities, such as limited capabilities including support (e.g., only support) certain and / or limited bandwidths. MTC devices can include a battery, and the battery life of the battery is higher than a threshold (e.g., for maintaining a very long battery life).
[0046] For WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah), these systems include channels that can be designated as primary channels. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by a certain STA, where the STA originates from all STAs operating in the BSS that supports the minimum bandwidth operating mode. In the example of 802.11ah, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes, for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode, the width of the primary channel can be 1MHz. Carrier sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy (e.g., because a STA (which only supports the 1MHz operating mode) transmits to the AP), then even if most of the available frequency bands remain idle and available for use, the entire available frequency band can be considered busy.
[0047] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. Depending on the country code, the total bandwidth available for 802.11ah is 6MHz to 26MHz.
[0048] Figure 1D 1 is a system diagram showing the RAN 113 and the CN 115 according to an embodiment. As described above, the RAN 113 may communicate with the WTRUs 102a, 102b, 102c using NR radio technology over the air interface 116. The RAN 113 may also communicate with the CN 115.
[0049] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may use beamforming processing to transmit and / or receive signals to and / or from the gNBs 180a, 180b, 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to the WTRU 102a and receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on an unlicensed spectrum, while the remaining component carriers may be on a licensed spectrum. In an embodiment, gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).
[0050] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with a scalable digital configuration. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may be different for different transmissions, different cells, and / or different portions of the radio transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of different or scalable lengths (e.g., containing different numbers of OFDM symbols and / or lasting different absolute time lengths).
[0051] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing other RANs (e.g., the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRU 102a, 102b, 102c may communicate / connect to the gNB 180a, 180b, 180c while communicating / connecting to another RAN (e.g., the eNode-B 160a, 160b, 160c). For example, the WTRU 102a, 102b, 102c may communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c in a substantially simultaneous manner by implementing the DC principle. In a non-standalone configuration, the eNode-B 160a, 160b, 160c may act as a mobility anchor for the WTRU 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput to serve the WTRU 102a, 102b, 102c.
[0052] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support network slicing, dual connectivity, implement interworking between NR and E-UTRA, route user plane data to a user plane function (UPF) 184a, 184b, and route control plane information to an access and mobility management function (AMF) 182a, 182b, and the like. Figure 1D As shown, gNBs 180a, 180b, and 180c can communicate with each other through the Xn interface.
[0053] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and may include a data network (DN) 185a, 185b. Although each of the aforementioned components is described as part of the CN 115, it should be understood that any of these components may be owned and / or operated by an entity other than the CN operator. The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating non-access stratum (NAS) signaling, and mobility management, etc. The AMF 182a, 182b may use network slicing processing to customize the CN support provided to the WTRUs 102a, 102b, 102c based on the type of service used by the WTRUs 102a, 102b, 102c. As an example, different network slices may be established for different use cases, such as services relying on Ultra-Reliable Low Latency Communication (URLLC) access, services relying on enhanced mobile (e.g., massive mobile) broadband (eMBB) access, and / or services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) using other radio technologies (e.g., LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi).
[0054] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b, and may configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.
[0055] The UPF 184a, 184b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N3 interface, which can provide the WTRUs 102a, 102b, 102c with access to packet-switched networks (e.g., the Internet 110) to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b can perform other functions, such as routing and forwarding packets, implementing user plane policies, supporting multi-host PDU sessions, processing user plane QoS, buffering downlink packets, and providing mobility anchor processing, etc.
[0056] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to the local data network (DN) 185a, 185b via an N3 interface connected to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b and through the UPF 184a, 184b.
[0057] In view of Figures 1A-1D and about Figures 1A-1D , one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more simulation devices (not shown): WTRU 102a-d, base station 114a-b, eNodeB 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or one or more other devices described herein. These simulation devices may be one or more devices configured to simulate one or more or all of the functions described herein. For example, these simulation devices may be used to test other devices and / or simulate network and / or WTRU functions.
[0058] The simulation device can be designed to implement one or more tests about other devices in a laboratory environment and / or an operator network environment. For example, the one or more simulation devices can perform one or more or all functions while being implemented and / or deployed as part of a wired and / or wireless communication network in whole or in part to test other devices inside the communication network. The one or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can be directly coupled to other devices to perform the test, and / or can use over-the-air wireless communication to perform the test.
[0059] One or more simulation devices can perform one or more functions, including all functions, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test lab and / or a test scenario of a wired and / or wireless communication network that is not deployed (e.g., testing) to implement tests on one or more components. The one or more simulation devices can be test devices. The simulation device can transmit and / or receive data using direct RF coupling and / or wireless communication with the aid of RF circuits (e.g., which can include one or more antennas).
[0060] New Radio (NR) systems are expected to be deployed in 2020 and will include both eMBB and URLLC types of services. These systems should support a BLER target of 10 -5 3GPP has started to study the BLER target up to 10 -6 And the delay is 0.5ms eURLLC.
[0061] For data transmission (BLER up to 10 -6) and / or short latency (on the order of 0.5 ms) may impact the reliability requirements of control signaling in the downlink and / or uplink. Uplink control information messages with low reliability may impact the reliability of downlink and / or uplink data transmission. For example, unreliable HARQ-ACK feedback may result in a high probability of NACK-to-ACK or NACK / ACK loss detection. NR Release-15 control signaling is designed to support eMBB and URLLC types of services. The WTRU 102 may multiplex control signaling of different services (e.g., services such as eURLLC, URLLC, eMBB and / or massive machine type communications (mMTC)) with different latency and reliability requirements in the same control message, which may impact the latency and / or reliability of the transmission (e.g., the eURLLC transmission). For example, multiplexing URLLC HARQ feedback with eMMBB HARQ feedback in long format PUCCH may result in increased latency (e.g., instead of sending low latency related HARQ feedback on 2 symbols in PUCCH, it may be sent on a larger symbol set (e.g., 14 symbols) on PUCCH), which may make it difficult to meet the 0.5ms latency requirement.
[0062] In certain representative embodiments, apparatus, methods, processes and / or operations may be implemented to indicate to a WTRU 102 supporting different types of services the separation and / or how to separate control signaling for each type of service. The type of service generally refers to the requirements for a given transmission, including, for example, latency, reliability and / or priority.
[0063] In certain representative embodiments, the WTRU 102 may interpret the control signaling based on the service type.
[0064] In certain representative embodiments, apparatus, methods, processes and / or operations may be implemented to determine when and how to interpret the control signaling by the WTRU 102. For example, the WTRU 102 may be configured to interpret the downlink control information bit field based on a control channel configuration. The control channel configuration may include: (1) a search space monitoring pattern (e.g., within a time slot); (2) a search space periodicity; and / or (3) a search space duration, among other things.
[0065] In addition to or as an alternative to using control channel configuration, the WTRU 102 may be configured to interpret a set of downlink control information (DCI) bit fields based on one or more values in another set of DCI bit fields or other sets of DCI bit fields.
[0066] Figure 2FIG. 1 is a diagram showing time-frequency resources used to carry control signaling for URLLC / eURLLC services and eMBB services. Figure 2 , multiple time-frequency resources 200-1, 200-2...200-N can carry control signaling for multiple services (for example, control DCI scheduling 210 for eMBB, DCI scheduling 220 for URLLC service / eURLLC service, PDSCH 230 for eMBB, PDSCH 240 for URLLC service / eURLLC service, and PUCCH 250 carrying HARQ-ACK feedback, etc. The time-frequency resources 200 can carry DCI scheduling 210 for eMBB service and DCI scheduling 220 for eURLLC service, respectively, and can carry PDSCH 230 for eMBB service and PDSCH 240 for URLLC / eURLLC service, respectively. HARQ-ACK feedback 250 for eMBB service and for URLLC / eURLLC service can be multiplexed together and carried on the PUCCH. In some representative embodiments, HARQ-ACK feedback for eMBB service and eURLLC service can be carried separately on multiple PUCCHs.
[0067] Figure 3 and 4 is a diagram showing a set of representative bit fields (eg, 4 bit fields) for eMBB services or URLLC / eURLLC services. Figure 3 In the embodiment, the bit field (e.g., bit field 1-4) associated with the first service type (e.g., URLLC / eURLLC service) and the corresponding bit field (e.g., bit field 1-4) associated with the second service type (e.g., eMBB service) are the same size. Figure 4 In the embodiment, the sizes of the bit fields (e.g., bit fields 1-4) associated with the first service type (e.g., URLLC / eURLLC service) and the corresponding bit fields (e.g., bit fields 1-4) associated with the second service type (e.g., eMBB service) are different.
[0068] refer to Figure 3 and Figure 4, when the WTRU 102 determines a first service type (e.g., a URLLC / eURLLC service type), bit field 1 may be interpreted in a first manner, and when the WTRU 102 determines a second service type (e.g., an eMBB service type), bit field 1 may be interpreted in a second manner. Bit fields 2-4 may be interpreted in the same manner for the first and second types of services. For example, the WTRU 102 may be configured to interpret the control information bit field differently depending on the type of service being scheduled. Interpreting the DCI bit field differently may mean that for the same bit field value, the WTRU 102 may interpret the control information differently. For example, a value of "000" for the HARQ timing bit field may indicate a first time value t1 for a first service type (e.g., for a URLLC / eURLLC service type) and a second time value t2 for a second service type (e.g., an eMBB service type). The WTRU 102 may be configured to interpret a bit field, a subset of a bit field (e.g., only a subset of a bit field, such as Figure 3 and Figure 4 1) or all bit fields. Figure 3 and 4 As shown, bit field 1 (eg, only bit field 1) is interpreted differently. For example, it is disclosed herein when and / or how the WTRU 102 interprets control signaling based on service type.
[0069] Despite Figure 3 and Figure 4 Only bit field 1 is shown as being interpreted differently for different types of services, but any number of bit fields may be interpreted differently for different types of services.
[0070] Although bit field 1 is shown as being interpreted differently for different types of services, any bit field (bit field 1 or any other bit field) may be interpreted differently for different types of services. Representative triggers for different interpretations of control signaling fields
[0071] In certain representative embodiments, downlink and / or uplink control interpretation may be based on the control channel configuration.
[0072] In some embodiments, the WTRU 102 may be configured with one DCI size to monitor downlink control signaling for different types of services (e.g., the WTRU 102 may be configured to determine / interpret the DCI field based on the control channel configuration on which the DCI is received. For example, Figure 3 and Figure 4As shown, the WTRU 102 may be configured with one DCI size to monitor various services (e.g., two services eMBB and URLLC) and the services (e.g., each service) may have different bit field configurations. For example, the WTRU 102 may be configured to interpret the DCI field based on the control channel configuration on which the DCI is received. The WTRU 102 may be semi-statically pre-configured / configured (e.g., via network signaling and / or RRC signaling) to have a subset of fields that are interpreted differently. For example, the WTRU 102 may be pre-configured to interpret differently (e.g., only interpret) the HARQ-ACK feedback timing field (e.g., bit field), while the remaining fields may have the same interpretation, regardless of which control channel configuration is being used. The control channel configuration may include any of the following: (1) Search space configuration, which includes any of the following: (i) monitoring periodicity and / or offset, such that, for example, the WTRU 102 may be configured with a periodicity and / or offset threshold for which a bit field in the DCI may be interpreted differently (e.g., if the WTRU 102 is configured with a search space having a monitoring periodicity greater than or equal to the threshold, the WTRU 102 may interpret DCI fields received within the search space in a first manner, or if the WTRU 102 is configured with a search space having a monitoring periodicity less than the threshold, the WTRU 102 may interpret DCI fields received within the search space in a second, different manner); (ii) search space duration, such that, for example, DCI received by the WTRU 102 in a search space having a duration shorter than K slots may be interpreted differently than DCI received in a search space having a duration longer than K slots; (iii) monitoring patterns within a time slot, such that, for example, DCI received by the WTRU 102 within a search space configured with a pattern for each symbol may be interpreted differently (e.g., the WTRU 102 may be configured with a set of patterns, and DCI received within a search space configured with one of these patterns or a set of patterns may be interpreted differently than DCI received within a search space not configured with one of these patterns or a set of patterns); (iv) a search space index (e.g., the WTRU 102 may be configured with a search space index, and one or more DCIs received by the WTRU 102 on a search space corresponding to the search space index may be interpreted differently for the search space index); and / or (v) In the event that a PDCCH candidate belonging to more than one search space is successfully decoded, the WTRU 102 may select a candidate for the search space (e.g., each search space) based on the PDCCH candidate that was decoded by higher layers. Determining the search space based on a configured priority index and / or another parameter associated with the one or more search spaces (e.g., a search space with the lowest periodicity), etc.; (2) A CORESET configuration, which includes any of the following: (i) the duration of a CORESET (e.g., the number of symbols (e.g., consecutive symbols) of the CORESET); and / or (ii) Control resource collection indexing, etc.; (3) RNTI used to scramble the cyclic redundancy check (CRC); (4) CRC length, for example, the configuration may include, for example, a 16-bit CRC that may be used for eMBB type services, or a 24-bit CRC that may be used for URLLC type services; and / or (5) Bandwidth part (BWP) configuration, etc. Representative procedures for downlink / uplink control interpretation based on some DCI values
[0073] In certain representative embodiments, the WTRU 102 may be configured to interpret a set of DCI fields differently depending on the value of one or more other DCI fields. For example, the WTRU 102 may be configured to have one field of a DCI (e.g., a bit field), a subset of fields of the DCI, or all fields of the DCI interpreted differently based on one or more other DCI fields (e.g., one or more bit values in a particular DCI field). The WTRU 102 may be configured with a given bit field value (e.g., a PDSCH time domain allocation) such that upon decoding the value, the WTRU 102 is triggered to interpret the set of bit fields differently. For example, a PDSCH time domain value below a threshold or within a range of values may be interpreted by the WTRU 102 as indicating a particular type of service and / or may be used as an indication to interpret one or more other DCI fields in a particular manner (e.g., in a manner associated with a particular service type). Representative Transmission Profiles (TPs) in DCI
[0074] In certain representative embodiments, the WTRU 102 may be configured with one or more TPs. For example, a first TP value may indicate a first (e.g., eMBB) type of service, and a second TP value may indicate a second (e.g., URLLC) type of service. In this case, the WTRU 102 may receive a DCI and may determine a corresponding TP for the DCI. The WTRU 102 may interpret one or more fields of the DCI based on the TP values determined for the DCI (e.g., using a first value or set of values for a first particular TP value and a second value or set of values for a second particular TP value). Representative Logical Channel Prioritization (LCP) for the transport block (TB) corresponding to the DCI (e.g., which may require and / or may use eNB blind decoding)
[0075] In certain representative embodiments, the WTRU 102 may be configured with one or more logical channels (LCHs). For example, a first LCH may be associated with data corresponding to a service of a first (e.g., eMBB) type, and / or a second LCH may indicate a service of a second (e.g., URLLC) type. The WTRU 102 may determine how to interpret at least some of the contents of the DCI based on the data to be included in the corresponding transmission. For example, the WTRU 102 may determine a transport block (TB) size (TBS) for the transmission associated with the DCI. The WTRU 102 may determine what LCH to serve the TB service (e.g., based on a logical channel prioritization (LCP) function). The WTRU 102 may determine the type of service associated with the LCH of interest. The WTRU 102 may interpret one or more fields of the DCI based on the determined type of service associated with the LCH of interest (e.g., by using a first value or set of values for a first specific LCH configured for a first type of service, or by using a second value or set of values for a second specific LCH configured for a second type of service).
[0076] It will be appreciated by those skilled in the art that the processes / operations disclosed herein with respect to LCH may be applied to a logical channel group (LCG) instead of or in addition to LCH. For LCP, similar processes / operations may be applied using different mapping restriction sets or TPs. In this case, the WTRU 102 may determine that the DCI schedules a new transmission, such as a DCI switching new data indicator field (NDI). The WTRU 102 may determine that the interpretation of the HARQ PID corresponds to a first PID space for a first LCH, or to a second PID space for a second LCH (e.g., a different set of HARQ processes may be indicated based on the interpretation of the DCI). Correct reception of such a transmission may require and / or use blind decoding at a network node (e.g., an eNB or gNB, etc.). Representative HARQ process identifiers (PIDs) in DCI
[0077] In certain representative embodiments, the WTRU 102 may be configured with one or more HARQ process identification (PID) spaces. For example, a first PID value may indicate a first (e.g., eMBB) type of service and / or a second PID value may indicate a second (e.g., URLLC) type of service. In this case, the WTRU 102 may receive a DCI for a HARQ transmission and may determine a corresponding HARQ PID for the DCI. The WTRU 102 may interpret one or more fields of the DCI based on the determined HARQ PID value (e.g., by using a first value or set of values (and / or a corresponding first range of values) for a first specific HARQ PID value and a second value or set of values (and / or a corresponding second range of values) for a second specific HARQ PID value). Representative procedure for downlink / uplink control interpretation based on explicit indication in the DCI
[0078] In some embodiments, the WTRU 102 may be configured to interpret a set of DCI fields differently depending on the value of a bit in the DCI. For example, the WTRU 102 may be configured to use the "set" indication in the DCI to determine the PUCCH resources for HARQ A / N feedback from a set of PUCCH resources. In one example, the WTRU 102 may be configured to receive eMBB data transmission and URLLC / eURLLC data transmission simultaneously. The WTRU 102 may be configured to have at least two PUCCH resource sets, each corresponding to a service type (e.g., URLLC / eURLLC, eMBB, and / or mMTC). The WTRU 102 may determine the PUCCH resource set to which the acknowledgment (e.g., PUCCH) resource indicator (ARI) bit field points based on the set indication. Different interpretations of representative control signaling fields Representative HARQ-ACK feedback timing indication
[0079] Figure 5 is a diagram showing different HARQ feedback timings.
[0080] refer to Figure 5 , for example, the HARQ timing indication 510 may be signaled using system information. The HARQ timing indication 510 may indicate the HARQ timing associated with each of a plurality of HARQ feedback timing sets 520A, 520B, ... 520N (e.g., for DMRS mapping type A 520A and for DMRS mapping type B 520B, etc.). For example, the HARQ timing set 520A may include HARQ timings t1, t2, t3, and t4, and the HARQ timing set 520B may include HARQ timings t5, t6, t7, and t8. The HARQ timing indicator 510 may be a multi-bit indicator. For example, when the multi-bit indicator is set to code point "11", the HARQ feedback timing may be set to t4 for DMRS type A and t8 for DMRS type B.
[0081] The WTRU 102 may be semi-statically configured with more than one set of HARQ feedback timing values (e.g., by using RRC signaling or by receiving a system information block (SIB)), and each set may be configured with different timing (e.g., timing in different units). For example, the WTRU 102 may be configured with a first set of timing in units of time slots, a second set of timing in units of symbols, and a third set of timing in units of symbol groups. Each set of HARQ feedback timing values may correspond to an interpretation. For example, a first set of HARQ timing values may correspond to a specific PDSCH start symbol. In certain representative embodiments, apparatus, methods, operations, and / or processes may be implemented for the WTRU 102 to dynamically determine the units of HARQ feedback timing for a given transport block. Those skilled in the art will appreciate that these apparatus, methods, operations, and / or processes may be similarly applied to interpret other DCI fields, such as a PUCCH resource indicator (ARI).
[0082] The WTRU 102 may be configured to interpret the HARQ timing indication bit field differently based on the triggers described herein (e.g., based on the control channel configuration). The WTRU 102 may then determine the HARQ-ACK timing value based on the following bit field value: (1) PDSCH time domain allocation value (e.g., the WTRU 102 may interpret the HARQ feedback timing indication based on the PDSCH start time and / or PDSCH duration value. The PDSCH time domain field may include any of the following: (i) k0 value, which may indicate the time slot scheduled for data transmission (e.g., time slot number n in which the DCI is received and the data to be transmitted in time slot n+k0) (e.g., the WTRU The WTRU 102 may be configured with a k0 value for which the WTRU 102 may interpret the HARQ timing differently. In certain embodiments, the WTRU 102 may be configured with a k0 threshold for which the HARQ-ACK timing may be interpreted differently. For example, when the k0 value is below the k0 threshold, the HARQ-ACK timing may be interpreted in a first manner (e.g., based on symbol timing / symbol timing period), and when the k0 value is equal to or above the k0 threshold, the HARQ-ACK timing may be interpreted in a second manner (e.g., based on symbol timing / symbol timing period). Based on time slot timing / time slot timing period); (ii) DMRS mapping type (e.g., DMRS mapping type A or DMRS mapping type B) (e.g., the WTRU 102 may be configured with two HARQ feedback timing sets, and based on the DMRS mapping type indication in the DCI, the WTRU 102 may determine which HARQ timing set the HARQ timing indication refers to, such as Figure 5 As shown; (iii) the starting symbol and / or length of the PDSCH transmission (e.g., the WTRU 102 may be configured with a set of starting symbols (e.g., the last 3 symbols of a timeslot) such that if the WTRU 102 receives a PDSCH scheduling that starts at these symbols, the HARQ-ACK timing field may be interpreted differently, e.g., if the WTRU 102 receives a PDSCH scheduling that starts at one of these symbols, the HARQ-ACK timing field may be interpreted in a first manner, and if the WTRU 102 receives a PDSCH scheduling that does not start at any of these symbols, the HARQ-ACK timing field may be interpreted in a second manner); and / or (iv) an offset or delay in symbols between the reception of the PDCCH and the start symbol of the PDSCH; and / or (2) One or more HARQ process ID values (e.g., the WTRU 102 may be configured with a set of HARQ process IDs for which the timing indication bit field may be interpreted differently. For example, the WTRU 102 may be configured with HARQ IDs 0, 1, and 2. Upon receiving a PDSCH assignment with HARQ IDs {0, 1, 2}, the WTRU 102 may interpret the HARQ-ACK timing field differently. The WTRU 102 may be semi-statically configured with a mapping between HARQ process IDs and HARQ-ACK timing sets, etc. Representative process using HARQ process indication
[0083] The WTRU 102 may be configured to interpret the HARQ process ID indication in the DCI based on one or more triggers discussed herein (eg, based on the control channel configuration and / or some DCI bit fields). Representative procedures for HARQ-ACK using PUCCH resource indication
[0084] According to one of the representative embodiments (e.g., solutions) described herein, the WTRU 102 may be configured to interpret the PUCCH resource indicator (ARI) based on the scheduled service type and / or based on any indication associated with the service type. For example, the WTRU 102 may be configured to send HARQ-ACK information in more than one PUCCH resource in the same time slot, and one PUCCH resource may contain and / or include a HARQ-ACK associated with a first PDSCH transmission set, and a second PUCCH resource may contain and / or include another HARQ-ACK associated with a second PDSCH transmission set. According to one of the representative embodiments (e.g., solutions) described herein, the WTRU 102 may determine whether a given PDSCH transmission belongs to the first PDSCH transmission set or the second PDSCH transmission set based on the scheduled service type and / or based on any indication associated with the service type. For example, if the PDSCH duration is below a threshold, the WTRU 102 may determine that the PDSCH transmission belongs to the first PDSCH transmission set, otherwise it belongs to the second set. Representative process using PDSCH / PUSCH time domain allocation indication
[0085] The WTRU 102 may be configured to interpret the PDSCH and / or PUSCH time domain allocation indication based on one or more triggers described herein. For example, the WTRU 102 may be semi-statically configured with two sets of time domain allocations, each corresponding to a service type (e.g., URLLC / eURLLC and / or eMBB, etc.). The WTRU 102 may be configured to interpret the time domain allocation bit field in the DCI based on the control channel configuration on which the DCI scheduling downlink data or uplink data is received. The WTRU 102 may receive a semi-static mapping configuration between a control channel configuration and a time domain allocation set. Representative procedures for supporting multiple PUCCHs per slot
[0086] Figure 6 is a diagram showing a process of supporting multiple PUCCHs per slot.
[0087] refer to Figure 6 , the WTRU 102 may receive, in time slot 600-3, a first PDSCH 620 / DCI 625 associated with, for example, a first type of service (e.g., an eMBB service), and a second PDSCH 630 / DCI 635 associated with, for example, a second type of service (e.g., a URLLC / eURLLC service or an mMTC service). The WTRU 102 may determine, from the first PDSCH 620 / DCI 625, a first codebook index 0 for HARQ feedback timing of the PDSCH 625 on the uplink and a second codebook index 1 for HARQ feedback timing of the PDSCH 630 on the uplink. When HARQ feedback associated with different services (e.g., URLLC and eMBB) will appear in the same time slot 600N for the uplink, the WTRU 102 may generate a first PUCCH 640 (e.g., PUCCH1 associated with the URLLC service) and a second PUCCH 650 (e.g., PUCCH0 associated with the eMBB service) for the uplink. For example, the WTRU 102 may determine that codebook index 0 is indicated for HARQ feedback timing associated with PDSCH 620, and codebook index 1 is indicated for HARQ feedback timing associated with PDSCH 630. In this case, when different codebook indices (e.g., codebook indices 0 and 1) may be indicated, multiple PUCCHs 640 and 650 may be generated in the same time slot 600-N.
[0088] Although HARQ feedback for multiple services is shown to occur in one time slot, other scenarios are possible. For example, HARQ feedback for a given service may occur in one time slot without HARQ feedback from any other service (e.g., any other codebook) requested in the same time slot (e.g., a first HARQ feedback may correspond to a first time slot, and a second HARQ feedback may correspond to a different second time slot). In this case, two codebooks may be indicated in two different time slots.
[0089] In certain representative embodiments, the WTRU 102 may indicate more than one PUCCH resource for the same slot 600-N, the same sub-slot, or the same symbol from multiple DCIs (e.g., using DCI format 1_0 or 1_1) that may indicate a downlink assignment or SPS release. The WTRU 102 may determine to transmit a PUCCH 640 or 650 for at least one PUCCH resource in the slot 600-N, sub-slot, or symbol, wherein the at least one PUCCH resource is determined based on at least one index (codebook index 0 or 1). The index may be referred to herein as a codebook index. Each of the at least one PUCCH resource may correspond to a codebook index corresponding to at least one of the DCIs. For a received codebook index (e.g., each received codebook index (e.g., codebook index 0 or 1), the PUCCH resource may be determined from a PUCCH resource indicator field in a last DCI of all DCIs corresponding to the codebook index (e.g., codebook index 0 or 1), and wherein the DCIs may be sorted according to a legacy procedure / operation (e.g., the DCIs may be arranged in ascending order on a serving cell index and then arranged in ascending order on a PDCCH monitoring opportunity index).
[0090] The codebook index 0 or 1 corresponding to the DCI may be determined according to any of the following: (1) An additional field of DCI that explicitly indicates the codebook index; (2) corresponding PDCCH attributes, such as TP, search space periodicity and / or RNTI; and / or (3) Existing fields of DCI, such as a PUCCH resource indicator (e.g., a codebook index may be mapped to a value of the PUCCH resource indicator (e.g., each of 16 possible values of the PUCCH resource indicator), and the mapping may be predetermined, signaled, and / or configured by a higher layer, etc.
[0091] After determining the at least one PUCCH resource in the slot, subslot, or symbol, the WTRU 102 may determine that there is an overlap of at least two resources in the time domain and / or frequency domain. The WTRU 102 may prioritize one of the overlapping PUCCH resources and / or may discard the other overlapping PUCCH resource (at least one of the overlapping portions) based on any of the following: (1) properties of the PUCCH resources (e.g., the WTRU 102 may discard the PUCCH resource with the longest duration); (2) a PUCCH format of the PUCCH resource (e.g., each PUCCH resource), using a predefined priority order between PUCCH formats; (3) Codebook index (e.g., prioritization based on the lowest codebook index or the highest codebook index associated with the PUCCH resource) (4)TP; (5) properties of the PDSCH transmission associated with the PUCCH resource (e.g., each PUCCH resource) (e.g., the WTRU 102 may discard a PUCCH resource that carries a HARQ-ACK for a PDSCH of the longest duration); and / or (6) Attributes of the corresponding PDCCH (e.g., the WTRU 102 may discard PUCCH resources carrying HARQ-ACK for downlink assignments received from the PDCCH with the longest periodicity, or discard based on the RNTI, etc.).
[0092] Although two HARQ codebook indices (e.g., HARQ codebook indices 0 and 1) are shown, any number of HARQ codebook indices are possible. For example, the corresponding HARQ codebook indices may correspond to priority levels, priorities, service types, and / or application types, and / or may be based on a predetermined HARQ format and / or HARQ bundling, etc. Representative process for handling conflicts between data or UCI associated with different services
[0093] In certain representative embodiments, methods, apparatus, and systems may be implemented to handle conflicts between service-based priority levels and different types of UCI.
[0094] In certain representative embodiments, the WTRU 102 may handle various scenarios in which transmissions carrying data and / or uplink control information (UCI) associated with different services (e.g., for URLLC and / or for eMBB) may or will overlap in order to meet latency and / or reliability requirements for each service. Representative process for identifying service-related priorities
[0095] The WTRU 102 may determine a priority (e.g., a service-related priority and / or a transmission profile) associated with the data or uplink control information for at least one of: (1) for data, based on the logical channel (LCH) and / or logical channel group (LCG) from which the data is transmitted (e.g., the WTRU 102 may determine the priority of a given PUSCH transmission as the RRC configured LCH priority of the highest priority LCH mapped to the PDU carried by the PUSCH transmission); (2) For a scheduling request (SR), the logical channel and / or logical channel group of the data that triggered the SR may be used; (3) For the physical random access channel (PRACH), the random access procedure may be prioritized based on a predefined priority such as lowest priority and / or highest priority; the event that initiates the random access procedure (e.g., handover, reestablishment, beam failure recovery, scheduling request and / or PDCCH command, etc.); whether the random access procedure is contention-based or contention-free; whether the PRACH is sent on the PCell or the SCell; whether the random access procedure is a prioritized random access procedure; for example, the WTRU 102 may determine the highest priority level for PRACH in the case of a prioritized random access procedure, otherwise the lowest priority level; in the case of a random access procedure initiated by a scheduling request, the logical channel or logical channel group of data that triggered the SR; in the case of a random access procedure initiated when the SR counter exceeds a maximum value, the priority of the last SR resource sent; in the case of a random access procedure initiated when no valid PUCCH resources are configured for a pending SR, the priority may be the lowest priority; (4) For SRS, it may depend on whether the SRS is periodic or triggered by PDCCH; in the former case, the priority may be the lowest priority; in the latter case, the SRS may have a priority determined according to the PDCCH; (5) For HARQ-ACK, it can be determined whether to use a slot-based HARQ feedback process or a sub-slot-based HARQ feedback process; (6) for PUSCH, based on the processing capabilities of the WTRU 102 for PUSCH, e.g., where such capabilities may be associated with the PUSCH transmission and / or configured for the carrier in which the PUSCH is transmitted; (7) According to the attributes of the resources configured for (or associated with) the transmission of UCI and / or data. For example, The properties can include: (i) The duration and / or format of the PUCCH for transmitting SR or HARQ-ACK is configured and / or indicated, and / or the duration of the PUSCH for transmitting data or UCI is configured or indicated (for example, if the duration of the PUSCH and / or the PUCCH indicated by the configuration is higher than a threshold, the service-related priority may be a first value, and if the PUSCH or the PUCCH has a duration lower than a threshold, the service-related priority may be a second value). In another example, the service-related priority may be a first value; (ii) bandwidth part, digital configuration (e.g., subcarrier spacing, symbol duration), and / or transmission configuration indication (TCI) status; (iii) a modulation and coding scheme (MCS) and / or an MCS table to be used for the transmission; (iv) attributes for determining logical channel restrictions for logical channel prioritization; and / or (v) the serving cell and / or uplink carrier on which the transmission occurs, or whether the transmission occurs on a normal uplink carrier or a supplementary uplink (SUL) carrier, etc.; (8) According to the configuration from a higher layer (e.g., RRC layer and / or MAC layer, etc.), such as any of the following: (i) an information element (IE) that explicitly indicates the corresponding service-related priority; for example, the IE may be included as part of the SR resource configuration (for SR), as part of the resource configuration for a link recovery request (LRR), or as part of the configured grant configuration (for data scheduled using a configured grant); (ii) implicitly from configuration aspects, such as periodicity, offset and / or resource (e.g., if the periodicity is above a threshold, the service-related priority for SR and / or for data scheduled using the configured grant may be a first value, and if the periodicity is below a threshold, the service-related priority for SR and / or for data scheduled using the configured grant may be a second value). In another example, the service-related priority for CSI may be determined from the BLER target configured for the CSI reporting setup; (iii) A mapping table between LCH priorities and priority levels (e.g., the WTRU 102 may be configured by the RRC with an LCH priority quantization table that may map a set of LCH priorities to a given priority. For example, when an SR and / or PUSCH transmission collides with a HARQ-ACK, the priority of the SR and / or the PUSCH transmission may be determined differently. In some embodiments, the MAC layer may communicate information related to the SR and / or PUSCH transmission. or LCH priority associated with a PUSCH transmission. The LCH priority may then be converted to a priority comparable to a priority attached to and / or associated with a HARQ-ACK (e.g., with the same granularity); and / or (iv) the RRC may configure a set of LCHs for the WTRU 102, such as a set of LCHs applicable to intra-WTRU prioritization (e.g., if the conflicting transmission does not involve at least one LCH applicable to intra-WTRU prioritization, the WTRU 102 may ignore the resource conflict), etc.; (9) based on downlink control information (DCI) associated with the UCI and / or data and / or SRS, For example, any of the following: (i) For HARQ-ACK, DCI containing the corresponding PDSCH scheduling information (e.g., in dynamic assignment and / or semi-persistent scheduling (SPS) activation); (ii) for data, a DCI containing the corresponding PUSCH scheduling information; (iii) for CSI, the DCI that triggers the transmission of the CSI; and from the DCI, the service-related priority (which may also be applicable to the PDCCH carrying the DCI) can be determined by: (a) the DCI format and / or the DCI size; (b) a field that explicitly indicates the service-related priority, such as a priority indication; (c) implicitly determined from the value of a field, for example, the value of a radio network temporary identifier (RNTI) used to mask the CRC, and / or the size of the CRC; and / or (d) implicitly determined from the properties of the PDCCH carrying the DCI, such as CORESET, whether the PDCCH is monitored at the beginning of a timeslot, search space type, identity and / or monitoring period, for example, each search space can be explicitly configured with a service-related priority; serving cell (e.g., in which the PDCCH is decoded and / or indicated by the DCI), bandwidth part (e.g., in which the PDCCH is decoded) (e.g., the service-related priority index can be configured by RRC for CORESET, search space, bandwidth part and / or serving cell, etc.). (10) For HARQ-ACK and / or PDSCH associated with the HARQ_ACK, according to the attributes of the PDSCH, for example: (i) a serving cell in which the PDSCH is decoded; (ii) the duration of the PDSCH; (iii) a bandwidth portion in which the PDSCH is decoded; (iv) a WTRU processing capability associated with the PDSCH, and / or a carrier configured for the PDSCH to be decoded therein; (11) for data, based on the number of retransmissions of a transport block; and / or (12) The WTRU PHY may determine the priority associated with PUSCH and / or SR transmissions as a priority level indicated from one or more higher layers (eg, a MAC layer), among other things.
[0096] Service-related priority can be associated with at least one of the following parameters, (e.g., for transmission of UCI or data): (1) maximum latency; (2) maximum coding rate and / or MCS; (3) maximum duration of a single transmission; and / or (4) maximum payload, etc.
[0097] At least some of the parameters may be implicitly determined from configuration aspects. For example, the maximum delay of a SR for a particular service-related priority may correspond to the periodicity of the SR transmission, and / or the maximum duration for a single transmission may correspond to the duration of the corresponding PUCCH resource.
[0098] For the PUSCH, the WTRU 102 may determine and / or consider service-related priorities to determine whether data from a logical channel may be included in one or more transport blocks. For example, the RRC may configure a set of allowed service-related priorities for each logical channel.
[0099] The service-related priority may determine a set of parameters (eg, P0, α) and power control adjustment states for power control. For example, depending on the priority configured by higher layers, the set of parameters may be applied to PUCCH resources for SR and / or LRR. Representative process for identifying conflict situations
[0100] A conflict may occur when there is an overlap in the time domain only or in both the time domain and the frequency domain between at least two transmissions that are dynamically indicated and / or configured.
[0101] A collision may occur only when there is an overlap in the time domain when simultaneous transmissions are not allowed. For example, if PUCCH and PUSCH are not allowed to be sent in the same time slot (or overlap in the time domain is not allowed), a collision may occur between PUCCH and PUSCH transmissions in different serving cells in the same time slot (e.g., overlap in the time domain). For example, if two PUSCH transmissions in the same time slot and the same serving cell overlap in the time domain (e.g., only in the time domain), a collision may occur between them.
[0102] If there is not enough processing time to handle two transmissions (eg, colliding transmissions), a collision may occur even when there is no overlap in the time domain.
[0103] A conflict may occur if the WTRU 102 determines that one or more transmissions should be performed and the start of at least one transmission is less than a certain amount of time (e.g., time x), where time x may correspond to a configured value and / or to a processing time requirement from the time the WTRU 102 determines that the transmission should be performed. If the WTRU 102 has buffered data for a data transmission that may be mapped in the conflicting transmission set, and / or if the data has a higher priority than other transmissions in the overlapping resource set, the WTRU 102 may further consider the transmission. Before considering the transmission as a conflicting transmission, the WTRU 102 may further consider whether an LCH configured by the RRC is worthy of intra-WTRU prioritization (e.g., by satisfying a criterion or rule), whether the LCH may be or will be included in or associated with the transmission. For example, if the conflicting transmission does not involve such an LCH (e.g., a worthy LCH), the WTRU 102 may ignore the resource conflict.
[0104] For example, the WTRU 102 may be instructed to use first resources for transmitting a HARQ-ACK for a first service-related priority (e.g., for eMBB) and subsequently instructed to use second resources for transmitting a HARQ-ACK for a second service-related priority (e.g., for URLLC), wherein the first resources and the second resources overlap in the time domain.
[0105] In another example, the WTRU 102 may be instructed to use first resources for transmitting a PUSCH for a first service-related priority (e.g., for eMBB) and subsequently instructed to use second resources for transmitting a HARQ-ACK for a second service-related priority (e.g., for URLLC), wherein the first and second resources overlap in the time domain.
[0106] In another example, the WTRU 102 may be instructed to use first resources for transmitting a PUSCH for a first service-related priority (e.g., for eMBB) and subsequently instructed to use second resources for transmitting a PUSCH for a second service-related priority (e.g., for URLLC), wherein the second PUSCH resources precede the first PUSCH resources and there may not be sufficient processing time to process both PUSCHs.
[0107] Hereinafter, the at least two resources are referred to as "conflicting resources". Representative process for taking action when conflicts are identified
[0108] When a conflict for at least two conflicting resources is identified, at least one of the following actions may be taken:
[0109] The WTRU 102 may select at least one resource for transmitting a subset or all of the UCI and / or data that may be transmitted on the conflicting resources. In certain representative embodiments, resource selection may be implemented, for example, as follows. The WTRU 102 may then not transmit on the remaining conflicting resources (and may stop or suspend ongoing transmissions), at least on the overlapping portion in the time domain (or both the time domain and the frequency domain). If the WTRU 102 is on a different serving cell, the WTRU 102 may transmit on at least one of the remaining conflicting resources, unless restrictions are configured or defined based on the type of physical channel (e.g., where simultaneous PUCCH and PUSCH are not allowed).
[0110] The WTRU 102 may multiplex the UCI and / or data on at least one of the conflicting resources. When multiplexing the UCI and / or data on the selected resources, the WTRU 102 may follow a priority order. The priority of the UCI and / or data may be based on any of the following: (1) Based on the priority of the service (e.g., priority indication); for example, using a numerical value (where a higher value may indicate a higher priority, or, alternatively, a lower priority) or a label (e.g., URLLC and / or eMBB, etc.) with a relative priority (URLLC> eMBB); and / or (2) Type of UCI and / or data (HARQ-ACK, SR, CSI and / or data), which may include the type of CSI report; for example, SR and / or HARQ-ACK may have the highest priority, followed by data and CSI;
[0111] The service-based priority criteria may take precedence over other criteria (e.g., the priority is determined first by the service-based priority, and secondly (if equal) by the type of UCI / data). A formula may be used to determine the overall priority. For example, the WTRU 102 may prioritize in the following order: URLLC SR / HARQ-ACK, URLLC data, eMBB SR / HARQ-ACK, eMBB data, and CSI. An example multiplexing implementation of UCI and / or data multiplexing is described below.
[0112] The WTRU 102 may multiplex certain (e.g., only certain) combinations of UCI and / or data on the selected resources according to predefined or configured rules, or according to a dynamic indication. These combinations (e.g., allowed combinations) may depend on the service-based priority level of the UCI and / or data (e.g., each UCI or data), and on the type of resources (e.g., PUCCH and / or PUSCH) and / or PUCCH format. For example, the WTRU 102 may, for example, multiplex (e.g., only multiplex) UCI and / or data associated with the same priority level in the same resource. In another example, the WTRU 102 may multiplex (e.g., only multiplex) SR / HARQ-ACK of the same priority into PUCCH and / or PUSCH. For example, the WTRU 102 may multiplex data of a first priority level HARQ-ACK (e.g., for URLLC) and data of a second priority level (e.g., for eMBB) into the PUSCH, which may occur, for example, if such indication is made in the DCI for the DL assignment corresponding to the HARQ-ACK and / or for the UL grant corresponding to the PUSCH. In another example, the WTRU 102 may multiplex (e.g., only multiplex) the CSI with the HARQ-ACK and / or SR associated with the lowest priority level.
[0113] The WTRU 102 may discard at least a subset of the UCI, SR and / or data. For example, the WTRU 102 may discard UCI and / or data that cannot be multiplexed on the selected resources because the UCI and / or data are not allowed to be multiplexed with higher priority UCI and / or data. In another example, if the UCI cannot be multiplexed on the resources, for example due to payload and / or maximum code rate limitations, the WTRU 102 may discard the UCI. Discarding of lower priority transmissions may occur for any symbol starting after a first minimum time Tdrop1 after the last symbol of the PDCCH indicating a high priority UL transmission. In certain representative embodiments, discarding may be applied if the first symbol of the lower priority transmission is not before a second minimum time Tdrop2 after the last symbol of the PDCCH indicating a high priority UL transmission.
[0114] In some embodiments, the WTRU 102 may process a subset of the UCI to reduce the number of information bits. For example, if the HARQ-ACK is code block group based (CBG based), the WTRU 102 may report (e.g., only report) TB-level HARQ-ACK. For example, the HARQ-ACK information may be bundled in the time domain, frequency domain, and / or spatial domain (e.g., via an AND operation). The WTRU 102 may reduce the number of information bits for a priority level UCI (e.g., eMBB) based on any of the following: (1) when it is a combination of UCI and / or data with a higher priority on a resource; for example, if the HARQ-ACK of a first higher priority level (e.g., for URLLC) is combined with the HARQ-ACK of a second lower priority level (e.g., for eMBB) on PUCCH and / or PUSCH, the number of HARQ-ACK bits of the second priority level may be reduced; (2) if it is not possible to multiplex the UCI (multiplexed with other UCI or data of higher priority) due to payload or maximum code rate limitations.
[0115] In some embodiments, the WTRU 102 may include a UCI multiplexing indicator in the resource to facilitate decoding of different combinations of UCI (e.g., possible UCIs) at the network side. The UCI multiplexing indicator may consist of an N-bit field, where a value (e.g., each possible value) may indicate a combination (e.g., a specific combination) of UCIs of different types and / or priorities. For example, a first value may indicate that the UCI includes one or more HARQ-ACKs of a first priority level (e.g., only the first priority level), a second value may indicate that the UCI includes one or more HARQ-ACKs of a second priority level (e.g., only the second priority level), a third value may indicate that the UCI includes one or more HARQ-ACKs of a first and a second priority level, a fourth value may indicate that the UCI includes an SR of the first priority level and one or more HARQ-ACKs of the second priority level, and so on. The UCI multiplexing indicator may be encoded separately from other UCI and data and may be mapped to one or more resource elements (e.g., specific resource elements) of the resource.
[0116] In some embodiments, the WTRU 102 may determine resources for transmitting a subset of deprioritized UCI and / or data, for example at a later point in time, which resources are hereinafter referred to as "overflow" resources. Representative embodiments for determining overflow resources are described herein.
[0117] The WTRU's action after determining a collision may depend on whether a colliding PUSCH transmission has already begun, and / or whether a PDU for the colliding PUSCH resource has already been generated and delivered to the HARQ process. The WTRU 102 may not generate a PDU in the MAC (e.g., MAC layer) for a grant that collides with another resource, which may occur if the WTRU 102 determines that the PDU may or will be discarded at the physical layer. For example, if the WTRU 102 determines that a PUSCH transmission has a lower priority than a colliding SR and / or UCI transmission, and that the PUSCH transmission may or will be discarded (e.g., completely discarded at the physical layer), the WTRU 102 may ignore the grant at the MAC layer and may not generate a PDU for the PUSCH resource. The WTRU 102 may consider whether the SR and / or UCI may be multiplexed on a lower priority PUSCH. For example, if the SR and / or UCI cannot be multiplexed on the PUSCH transmission and the PDU may or will be discarded at the physical layer, the WTRU 102 may ignore the grant at the MAC layer and may not generate a PDU for the PUSCH resources. In another example, the MAC of the WTRU 102 may determine whether to instruct the physical layer to transmit an SR, which may occur, for example, when the WTRU 102 determines that the SR may not be discarded or is not discarded in the physical layer. For example, the WTRU 102 may determine to instruct the physical layer to transmit an SR with a lower priority (e.g., a lower priority level) than an overlapping PUSCH transmission, which may occur when the SR and / or UCI may be multiplexed on the PUSCH transmission. In certain representative embodiments, the WTRU MAC may not instruct the physical layer to generate an SR transmission, which may occur, for example, when a lower priority SR and / or UCI cannot be multiplexed on a higher priority PUSCH transmission.
[0118] For SR collisions versus PUSCH collisions, the WTRU 102 may consider whether the WTRU 102 has already sent (e.g., has already sent) the same pending SR to the physical layer before again instructing the physical layer to transmit the same pending SR during an overlapping PUSCH. For example, the MAC (e.g., MAC layer) of the WTRU 102 may not instruct the physical layer to transmit the SR during an overlapping PUSCH, which may occur if the WTRU 102 has already signaled (e.g., has already signaled) a pending SR to the physical layer and the SR has been multiplexed with the overlapping PUSCH. In certain representative embodiments, the WTRU 102 may discard the SR transmission at the physical layer, for example, if the SR has been multiplexed (e.g., has been multiplexed) on the overlapping PUSCH. In some examples, the MAC (e.g., MAC layer) of the WTRU 102 may not instruct the physical layer to transmit an SR during an overlapping PUSCH, which may occur when the WTRU 102 has already signaled (e.g., has already signaled) a pending SR and the WTRU 102 has already paused and / or punctured the PUSCH at the physical layer to transmit the SR. Representative process for resource selection (e.g., general process)
[0119] The WTRU 102 may select at least one of the conflicting resources for transmission. The resource may be referred to as a "prioritized resource". The WTRU 102 may select a prioritized resource based on any of the following criteria: (1) a service-based priority associated with the resource and / or associated with, for example, UCI and / or data configured to be transmitted on the resource; (2) whether the resource meets the latency and / or reliability requirements of the highest priority UCI and / or data to be carried by the conflicting resource; (3) whether the transmission of the UCI and / or data on the resource may or will result in an increase in latency by more than a certain amount, for example, for the highest priority UCI and / or data; (4) the type of: (1) physical channel (e.g., PUSCH and / or PUCCH); and / or (2) PUCCH format, etc.; (4) time-related attributes of the resource, such as duration and timing of the first and last symbols (e.g., WTRU 102 may select a resource with the shortest duration from a set of suitable conflicting resources); (5) whether transmission on the resource can use (e.g., may require) a transmission power exceeding the configured maximum power; (6) whether processing time is sufficient to multiplex the UCI and / or data on the prioritized resource; (7) the value of a certain UCI; for example, if (e.g., only if) the corresponding value of the SR is negative, the resource for the SR may be selected; (8) the number of bits of UCI and / or data that can be multiplexed and / or transmitted using the resource, for example, this may be conditional on following a priority order of different UCIs and / or data; and / or (9) the carrier, serving cell, frequency band, or whether the resource is on a normal uplink or a supplementary uplink. Representative procedure for resource selection (e.g., for PUCCH resource sets)
[0120] The WTRU 102 may be configured with more than one PUCCH resource set. The resource set (e.g., each resource set) and the maximum payload of the PUCCH resources within the resource set (e.g., each resource set) may be configured for service-based priorities (e.g., separately for each service-based priority).
[0121] In one example, a resource set for a PUCCH associated with a priority level may be selected across conflicting resources based on the number of UCI bits associated with the priority level (e.g., only the number of UCI bits associated with the priority level), or the number of UCI bits associated with a priority level equal to or lower than the priority level. For example, the number of UCI bits may include CSI regardless of the priority level.
[0122] In certain representative embodiments, a resource set for the PUCCH may be selected across conflicting resources based on the total number of UCI bits, without regard to priority level. Representative process for suitability-based resource selection
[0123] In some embodiments, based on the rules and / or conditions described herein, a resource may be selected if (e.g., only if) it is first determined that the resource is "suitable" for transmission of a combination of UCI and / or data. For example, a prioritized resource may be selected (e.g., only selected) from a subset of conflicting resources determined to be suitable.
[0124] For UCI and / or data (or one or more portions thereof) associated with certain service-based priorities, a resource may be suitable (e.g., only deemed suitable) if reuse of the UCI and / or data is possible under at least one condition. The suitability of a resource may be defined for a particular combination of UCI and / or data. For example, a resource may be suitable (e.g., deemed or determined to be suitable) for a first combination of UCI and / or data, but not suitable for a second combination of UCI and / or data. Representative process of suitability related to priorities
[0125] The applicability condition may be related to a priority associated with the resource. For example, a PUCCH resource for a HARQ-ACK indication for a certain priority level may be suitable for including UCI associated with the priority level (e.g., only UCI associated with the priority level), and / or including UCI associated with a priority level equal to or lower than the priority level. Representative process for latency-related fitness
[0126] The applicability condition may be related to a latency requirement. A resource may be considered or determined to be suitable if (e.g., only if) UCI and / or data (e.g., all UCI and / or data) can be mapped to a resource element in a time symbol that occurs before a certain threshold. The threshold may be determined from any of the following: (1) the duration, start time, and / or end time of the conflicting resource that may or will carry the UCI and / or data (e.g., if the HARQ-ACK and / or SR may or will be carried on a PUCCH resource, the threshold may correspond to the end of the last symbol of the PUCCH resource plus an offset; and / or (2) aspects of the configuration of the UCI and / or data; for example, a maximum time delay and / or offset may be explicitly configured by a higher layer for the UCI and / or data, or may be determined from aspects such as the periodicity of the SR configuration. Representative process of serviceability related to reliability
[0127] The suitability condition may be related to the reliability requirement. For example, if (e.g., only if) the number of coded modulation symbols per layer mapping the UCI (e.g., the HARQ-ACK and / or the SR) may be below or about to be below a threshold, then it may be determined that the resource is suitable. The threshold may be determined as a fraction of the total number of resource elements available for the UCI transmission. The fraction may be configured by a higher layer or dynamically indicated for the UCI type and / or based on the priority level of the service.
[0128] In another example, the applicability condition may be related to a maximum amount of puncturing applied to other UCI and / or data. For example, if HARQ-ACK and / or SR of a particular priority is mapped to PUSCH by replacing (e.g., puncturing) modulation symbols that may have been used for data and / or other UCI, the WTRU 102 may determine that the resources are suitable if (e.g., only if) the portion of modulation symbols available for data and / or other UCI that can be punctured or will be punctured is below a threshold. The threshold may be configured by higher layers or indicated for service-based priority, etc. and / or level UCI type that is subject to puncturing.
[0129] In another example, the applicability condition may be that after multiplexing, the coding rate applicable to a certain UCI may be less than or will be less than a threshold of the UCI type and / or priority level. For example, if (e.g., only if) the coding rate of the HARQ-ACK of the first priority level may not exceed the threshold or does not exceed the threshold, the resource may be suitable for multiplexing the HARQ-ACK of the first priority level and the second priority level. For example, the threshold or maximum coding rate may be configured separately for different priority levels. In another example, the applicability condition may be that the modulation order or spectral efficiency applicable to a particular UCI or data is lower than a threshold.
[0130] In another example, the applicability condition may be that the total number of UCI (and / or data) bits is less than the maximum payload configured for the resource. In another example, the applicability condition may be that the UCI is mapped to a certain subset of carriers, serving cells, frequency bands, or on a normal uplink or a supplementary uplink.
[0131] In a further example, the applicability condition may be that the transmission power (e.g., required transmission power) may be or will be below a threshold. In one example, the threshold may depend on a maximum power (Pcmax) applicable to the configuration of the carrier and / or WTRU 102. In another example, the threshold may be defined relative to the transmission power that will be used / required to send the UCI and / or data on the conflicting resources, for example, if multiplexing with UCI and / or data may or will not be performed. For example, in the case where a conflict occurs between a first resource for HARQ-ACK of a first priority and a second resource for HARQ-ACK of a second priority, such that the first priority may be higher than the second priority, for example, if the difference between the transmission power (e.g., required transmission power) for the resource with multiplexing and the transmission power (e.g., required transmission power) for the first resource for HARQ-ACK of the first priority (e.g., only HARQ-ACK of the first priority) may be less than or will be less than a threshold, then it may be determined that the resource is suitable for multiplexing the HARQ-ACK of the two priorities. The threshold may be configured by a higher layer and / or dynamically indicated for UCI type and / or priority level. Representative process of resource selection using identified prioritized resources
[0132] The WTRU 102 may determine the prioritized resources in the set of conflicting resources based on any of the following.
[0133] The WTRU 102 may determine the prioritized resources as those suitable for transmitting the largest number of highest priority UCI and / or data bits.
[0134] In the event that more than one resource meets the criteria, the WTRU 102 may determine among or between the more than one resource the resource that is suitable for transmitting the largest number of UCI and / or data bits for the next highest priority level, and so on. In certain representative embodiments, or in the event that more than one resource remains after determining / considering all priorities, the WTRU 102 may use other criteria to select a resource. For example, the WTRU 102 may select the resource that starts earliest in time, the resource with the shortest duration, the resource with the lowest transmission power requirement, and / or the resource with the lowest coding rate, modulation order, and / or spectral efficiency. In another example, the WTRU 102 may select a resource based on the carrier, the serving cell, whether the resource is in the normal uplink or the auxiliary uplink, or the frequency band. The priority order may be configured or predefined by a higher layer.
[0135] For example, there may be a conflict between a first resource (i.e., PUCCH) for HARQ-ACK based on a first priority level of a service (e.g., for URLLC) and a second resource (e.g., on PUSCH) for data based on a second priority level of a service (e.g., for eMBB), such that the first priority level may be higher than the second priority level. If the second resource starts later than the first resource and ends earlier than the first resource, or ends earlier than the last symbol of the first resource plus an offset, the WTRU 102 may select the second resource for multiplexing the HARQ-ACK of URLLC and the data of eMBB. For example, if the first resource is used on the PUCCH to transmit HARQ-ACK in a specific sub-slot, the WTRU 102 may select the second resource for multiplexing the HARQ-ACK of URLLC and the data of eMBB if the second resource is included in the sub-slot in the time domain. Otherwise, the WTRU 102 may select the first resource for transmitting the HARQ-ACK of URLLC (e.g., only selecting the first resource for transmitting the HARQ-ACK of URLLC).
[0136] For example, there may be a conflict between a first resource (e.g., PUCCH) for an SR based on a first priority level of a service (e.g., for URLLC) and a second resource (e.g., on PUSCH) for data based on a second priority level of a service (e.g., for eMBB), such that the first priority level may be higher than the second priority level. If the last symbol of the PUSCH or the last symbol of the PUSCH-mapped SR is no more than X symbols after the last symbol of the first resource, the WTRU 102 may select the second resource for multiplexing the SR for URLLC and the data for eMBB. The X may be a function of the periodicity of the SR configuration (e.g., X may be half of the periodicity). Otherwise, if the SR is positive, the WTRU 102 may select the first resource and if the SR is negative, the second resource. For example, if (e.g., only if) the above latency requirements are met, the SR may be multiplexed in the PUSCH.
[0137] Figure 7 is a diagram illustrating a representative transmission process 700 after a conflict determination.
[0138] refer to Figure 7 , the transmission process 700 may include: at block 710, the WTRU 102 determines that a collision is expected between two transmissions (e.g., before the actual transmission), and the WTRU 102 may follow a process including any of the following (e.g., to prevent the expected collision): (1) At block 720, the WTRU 102 may determine the priority of each conflicting transmission; (2) At block 730, the WTRU 102 may determine whether a lower priority transmission may be multiplexed with the prioritized transmission. After determining whether a lower priority transmission may be multiplexed with the prioritized transmission, the WTRU 102 may: (i) if the WTRU 102 determines that a lower priority transmission may be multiplexed with the prioritized transmission (e.g., if yes), then at block 740 the WTRU 102 may generate a multiplexed transmission, which may include a PDU, for example, if applicable; or (ii) If the WTRU 102 determines that the lower priority transmission cannot be multiplexed with the prioritized transmission (e.g., if No), then at block 750, the WTRU 102 may determine whether the deprioritized transmission may be partially transmitted (e.g., at least on a non-overlapping portion). After determining whether the deprioritized transmission may be partially transmitted, the WTRU 102 may: a) If the WTRU 102 determines that the deprioritized transmission can be partially transmitted (e.g., if yes), then at blocks 760 and 770, the MAC (e.g., MAC layer) A PDU for the deprioritized resources may be generated (e.g., if applicable and / or if not already generated), and a PHY (e.g., physical layer) of the WTRU 102 may transmit the deprioritized transmission in at least the non-overlapping portion; or b) If the WTRU 102 determines that the deprioritized transmission cannot be partially transmitted (e.g., if not), then at blocks 780 and 790, the WTRU 102 may discard the deprioritized transmission at the physical layer and / or may refrain from generating / constructing a PDU on the associated resources (e.g., if applicable), and the PHY of the WTRU 102 may The deprioritized transmissions may be transmitted (eg, at a physical layer) at least in the non-overlapping portions.
[0139] When the WTRU 102 determines a collision (and / or conflict) between more than two transmissions, the WTRU 102 may follow the same process pairwise based on sorting the conflicting transmissions according to priority. In certain representative embodiments, the WTRU 102 may sort the conflicting transmissions according to priority and may perform intra-WTRU prioritization on a subset of the conflicting transmissions (e.g., a subset of the highest-ranked conflicting transmissions, e.g., only the first x conflicting transmissions, where x is configured, signaled and / or predetermined). The WTRU 102 may discard the remaining transmissions. In certain examples, the WTRU 102 may sort each type of transmission (PUSCH, UCI, or SR) and may keep and / or maintain the highest priority transmission of each type (e.g., only the highest priority transmission of each type) before running / performing the prioritization process. The WTRU 102 may discard the remaining lower priority (e.g., non-highest priority) transmissions of each type. The WTRU 102 may multiplex the UCI (eg, HARQ-ACK) together using conventional rules before comparing its priority with other colliding transmissions.
[0140] In certain representative embodiments, methods, apparatus, and systems may be implemented to handle prioritization of PUSCH relative to UCI / SR, including interaction with the MAC layer.
[0141] Figure 8 is a schematic diagram illustrating a representative intra-WTRU prioritization process.
[0142] refer to Figure 8 , a representative intra-WTRU prioritization process 800 may include: the WTRU 102 determining whether a conflict is expected (e.g., a PUSCH versus an SR conflict) and whether to initiate actions to prevent / mitigate the conflict. For example, based on certain criteria, conditions, and / or rules, the WTRU 102 may: (1) send an SR (e.g., by, for example, dropping or suspending the PUSCH at the physical layer); (2) send an SR and a PUSCH (e.g., by multiplexing the SR on the PUSCH); (3) send an SR (e.g., by dropping or suspending the PUSCH, e.g., at the MAC layer by not generating corresponding one or more PDUs); (4) drop the SR (e.g., if the SR is signaled to the physical layer); and / or (5) do not generate an SR transmission (e.g., if the SR is not signaled to the physical layer).
[0143] For example, at block 805, the WTRU 102 may determine whether a collision between a PUSCH and an SR will occur. At block 810, the WTRU 102 may determine the priority of each transmission (e.g., the priority of the PUSCH and the priority of the SR). At block 815, the WTRU 102 may determine whether the priority of the PUSCH is lower than the priority of the SR. If the priority of the PUSCH is lower than the priority of the SR, then at block 820, the WTRU 102 may determine whether a PUSCH transmission has started and whether a transport block (TB) has been constructed, such as at the physical layer. If a PUSCH transmission has started and a TB has been constructed, then at block 825, the WTRU 102 may drop or suspend the PUSCH transmission, and at block 830, the WTRU 102 may transmit the SR. If a PUSCH transmission has not started and / or a TB has not been constructed, then at block 835, the WTRU 102 may determine whether the SR can be multiplexed on the PUSCH. If the SR can be multiplexed on the PUSCH, then at block 840, the WTRU 102 may multiplex the SR on the PUSCH, and at block 845, the WTRU 102 may transmit both the SR and the PUSCH. If the SR cannot be multiplexed on the PUSCH, then at block 850, the WTRU 102 may drop or suspend the PUSCH (e.g., by not generating a PDU) at the physical layer or at a higher layer (e.g., the MAC layer), and at block 830, the WTRU 102 may transmit the SR.
[0144] If the priority of the PUSCH is not less than the priority of the SR, then at block 855, the WTRU 102 may determine whether a PUSCH transmission has started and whether a TB has been constructed, such as at the physical layer. If the PUSCH transmission has started and the TB has been constructed, then at block 860, the WTRU 102 may determine whether the SR has been signaled to the WTRU's physical layer. If the SR has been signaled to the WTRU's 102 physical layer, then at block 865, the WTRU 102 may discard the SR. If the SR has not been signaled to the WTRU's 102 physical layer, then at block 870, the WTRU 102 may not or will not instruct the WTRU 102 physical layer to generate an SR transmission. If the PUSCH transmission has not started and / or the TB has not been constructed, then at block 875, the WTRU 102 may determine whether the reliability and / or latency of the PUSCH is compromised if the SR is multiplexed with the PUSCH. If the reliability and / or latency of the PUSCH is compromised by multiplexing the SR with the PUSCH, the WTRU may determine whether the SR has been signaled to the physical layer at block 880. After block 880, if the SR has been signaled to the physical layer, the WTRU 102 may discard the SR at block 865. After block 880, if the SR has not been signaled to the physical layer of the WTRU 102, the WTRU 102 may not or will not instruct the physical layer of the WTRU 102 to generate an SR transmission at block 870. After block 875, if the reliability and / or latency of the PUSCH is not compromised by multiplexing the SR with the PUSCH, the WTRU may multiplex the SR on the PUSCH at block 885, and the WTRU may transmit both the SR and the PUSCH at block 890.
[0145] Although Figure 8 Intra-WTRU prioritization is shown for one type of contention (PUSCH versus SR contention), but the same or substantially similar process may be used for other types of contention, including, for example, but not limited to, PUSCH versus UCI contention. Representative procedure for resource selection using multiple PUSCH transmissions
[0146] The WTRU 102 may be configured to transmit more than one PUSCH transmission in a time slot (e.g., the same time slot) and / or overlapping in the time domain, and the PUSCH transmissions may be on different serving cells and / or different carriers (e.g., each PUSCH transmission may be on a different serving cell and / or different carrier). The PUSCH transmissions may have different service-related priorities (e.g., each PUSCH transmission may have a different service-related priority). For example, the WTRU 102 may be transmitting a low priority PUSCH on a carrier (e.g., one carrier). For example, when the WTRU 102 may be transmitting a low priority PUSCH on a carrier, a new higher priority SR or UCI may be triggered. The carriers may be mapped to PUCCH resources on different carriers that may overlap in the time domain. In some examples, the WTRU 102 may be transmitting a low priority UCI and / or SR on one carrier, while new high priority data that may be configured and / or scheduled to be transmitted on a different carrier may arrive. The WTRU 102 may be configured and / or scheduled to have PUSCH resources on different carriers, which may carry data traffic of different priorities.
[0147] The WTRU 102 may select at least one PUSCH for multiplexing UCI based on any of the following criteria: (1) Whether PUSCH transmission is suitable for combined transmission of UCI and data; (2) one or more service level priorities associated with the PUSCH and UCI; and / or (3) Any criteria used in existing systems for selecting PUSCH transmission (e.g., NR Release 15, e.g., as specified in TS 38.213v15.6.0 including Part 9), such as whether PUSCH is scheduled by DCI, whether aperiodic CSI is to be multiplexed in PUSCH, the serving cell index of PUSCH, and / or whether timeline conditions related to processing time are met, etc.
[0148] The WTRU 102 may determine a subset of PUSCH transmissions as candidate PUSCH transmissions for multiplexing UCI of a given type and / or priority. The WTRU 102 may then determine the subset of candidate PUSCH transmissions. The subset of candidate PUSCH transmissions is determined by the WTRU 102 to be suitable for transmission of a combination of UCI and data. The determination may be performed based on one or more examples disclosed herein. The WTRU 102 may select a PUSCH from the subset based on, for example, one or more rules specified for an existing system. For example, the WTRU 102 may select a PUSCH with a minimum serving cell index within the subset. In the event that there is no suitable PUSCH transmission within the candidate PUSCH transmission, the WTRU 102 may determine a prioritized resource (e.g., according to one or more examples disclosed herein). For example, if the prioritized resource is a PUCCH transmission, and / or simultaneous PUCCH and PUSCH transmissions are not allowed within a serving cell or cell group, the WTRU 102 may discard one or more PUSCH transmissions in the same serving cell or in all serving cells of a cell group.
[0149] The subset of candidate PUSCH transmissions for UCI of a given type and / or priority may include, consist of, or be determined according to any of the following: (1) a set of PUSCH transmissions on which the WTRU 102 is configured to transmit (e.g., the entire set); (2) a subset of PUSCH transmissions that have the same service-related priority as the UCI, and, for example, in the case of periodic CSI, the service-related priority may be configured or defined to correspond to a particular priority, such as a lowest priority; (3) a subset of PUSCH transmissions in the set of PUSCH transmissions (e.g., the entire set) that have the highest service-related priority; (4) a subset of PUSCH transmissions that are scheduled by a dynamic grant, scheduled by a configured grant, are scheduled for semi-persistent PUSCH, and / or for which non-periodic CSI is requested; and / or (5) PUSCH transmissions determined according to rules for selecting PUSCH in an existing system (Release 15) (e.g., only PUSCH transmissions).
[0150] In the event of a collision for more than one type and / or priority of UCI, the subset of candidate PUSCH transmissions may be different for each UCI and / or each UCI may be multiplexed on a different PUSCH. For example, the WTRU 102 may multiplex a HARQ-ACK of a first priority in a PUSCH of a first priority and may multiplex a HARQ-ACK of a second priority in a PUSCH of a second priority. In certain representative embodiments, multiplexing of UCIs may be allowed only in a single PUSCH. In this case, for any UCI, the subset of candidate PUSCHs may be determined to be the subset applicable to the highest priority UCI.
[0151] For example, in one case, the WTRU 102 may transmit a first PUSCH of a first priority (e.g., associated with a URLLC service) in a first serving cell, a second PUSCH of a second priority (e.g., associated with an eMBB service) in a second serving cell, and a third PUSCH of a second priority (e.g., associated with an eMBB service) in a third serving cell in a given time slot. In the case where the WTRU 102 will or will transmit a HARQ-ACK of a second priority (e.g., associated with an eMBB service) in a PUCCH in the same time slot, the WTRU 102 may multiplex the HARQ-ACK of the second priority in the second PUSCH. In addition, if the WTRU 102 will or will transmit a HARQ-ACK of a first priority in a PUCCH in the same time slot, the WTRU 102 may multiplex the HARQ-ACK of the first priority in the first PUSCH. In the above scenario, the WTRU 102 may multiplex UCIs of different priorities in different PUSCH transmissions in the same time slot.
[0152] In the event that the subset of candidate PUSCH transmissions for UCI of a given type and / or priority is empty according to one set of criteria, the WTRU 102 may fall back to a second (e.g., less restrictive) set of criteria. For example, for UCI of a given service-related priority, the subset of candidate PUSCH transmissions may correspond to PUSCH transmissions of the same service-related priority (if there is at least one such PUSCH transmission), or may correspond to the set of PUSCH transmissions (e.g., the entire set) otherwise.
[0153] In some scenarios, the WTRU 102 may not be able to transmit both PUSCH and PUCCH simultaneously, or the WTRU 102 may not be able to: (1) transmit PUSCH and PUCCH simultaneously; (2) transmit the PUSCH and the PUSCH simultaneously; or (3) transmit PUCCH and PUCCH simultaneously while meeting the reliability requirements of the higher priority transmission. The WTRU 102 may discard the low priority transmission and may transmit the high priority transmission. The WTRU 102 may puncture the low priority transmission in a portion that overlaps in time with the higher priority transmission. If the reliability and / or latency metrics are met for the high priority transmission, the WTRU 102 may multiplex the SR or UCI on the PUSCH transmission. In another example, if the overlapping transmission has not yet started, the WTRU 102 may apply different transmission power and / or power control parameters. In some examples, the WTRU 102 may first allocate power to the higher priority transmission before allocating any power to the lower priority overlapping transmission (taking into account, according to and / or based on the power headroom of the WTRU 102). In other examples, the WTRU 102 may be configured by a higher layer with two sets of power control parameters; when a PUCCH transmission or a PUSCH transmission overlaps with another PUSCH transmission or another PUCCH transmission (e.g., only when a PUCCH transmission or a PUSCH transmission overlaps with another PUSCH transmission or another PUCCH transmission), the WTRU 102 may select a specific set of power control parameters for the PUCCH transmission or PUSCH transmission.
[0154] In certain representative embodiments, the WTRU 102 may discard a transport block (TB) generated for transmission on a given carrier if the TB overlaps with a higher priority transmission on a different carrier. The WTRU 102 may determine, set and / or consider a subset of resources to be inactive, and / or not generate PDUs applicable to the resources, which may occur, for example, when the subset of resources overlaps with another resource applicable to transmission of higher priority data on a different carrier. In certain examples, the WTRU 102 may be configured with two or more configured grants on different carriers that may overlap in the time domain. For example, a first configured grant CG1 may carry data of all priorities, while a second configured grant CG2 may carry data from a lower priority (e.g., only data). When the WTRU 102 has high priority and low priority buffered data, the WTRU 102 may multiplex data from the low and high priority LCHs onto the first configured grant CG1 (e.g., only the first configured grant CG1) and may not generate a TB for the second configured grant CG2, which may occur, for example, when the second configured grant CG2 overlaps in the time domain with the CG timing associated with the first configured grant CG1. Representative process for handling non-prioritized resources
[0155] For at least one conflicting resource, the WTRU 102 may transmit on at least a portion that does not overlap with the prioritized resource such that the overlap may be in the time domain (e.g., only in the time domain) or in both the time domain and the frequency domain. For example, a first resource may be a PUSCH transmission resource having a duration of 14 symbols, and a second (e.g., prioritized) resource may be a PUCCH transmission having a duration of 2 symbols that overlaps with the 3rd and 4th symbols of the first resource. The WTRU 102 may transmit the first 2 symbols of the first resource, skip the 3rd and 4th symbols of the first resource and transmit the second resource, and then transmit the first resource starting from the 5th symbol.
[0156] When at least a portion of a first resource overlaps with a second (e.g., prioritized) resource, the WTRU 102 may determine whether to transmit on at least the remaining, non-overlapping portion of the first resource based on any of the following conditions: (1) if code block group-based HARQ is configured for the transmission (e.g., at least for PUSCH transmission); (2) if at least a certain number (e.g., one) of the one or more code blocks and / or one or more code block groups are mapped on the non-overlapping portion; (3) if at most a certain number of the one or more code blocks and / or one or more code block groups are mapped on one or more skipped portions; (4) if the one or more non-overlapping portions are on a portion of the resources; (5) if a reference signal (e.g., DM-RS) is present in the non-overlapping portion; and / or (6) if the second transmission can be multiplexed on the first transmission. Representative process for reuse
[0157] In some examples, the WTRU 102 may multiplex UCI and / or data that may be associated with different service-based priority levels into a single resource. For example, the WTRU 102 may multiplex HARQ-ACK and / or SR and / or data associated with different service-based priority levels into a single PUCCH or a single PUSCH.
[0158] When UCI is multiplexed on PUSCH, the set of resource elements available for UCI may depend on the service-based priority level associated with the UCI. For example, for a particular priority, the number of resource elements available for HARQ-ACK and / or SR may be zero for the last N time symbols. The value of N may depend on the latency requirements applicable to the priority. For example, N may be such that the last N symbols may not overlap or not overlap with PUCCH resources that may carry HARQ-ACK and / or SR without collision.
[0159] The WTRU 102 may multiplex UCI and / or data associated with different service-based priority levels on the PUSCH or PUCCH. In some examples, the WTRU 102 may encode (e.g., jointly encode) UCI (e.g., HARQ-ACK and / or SR) associated with different priorities before multiplexing on the PUSCH or PUCCH. In the case of PUSCH, the WTRU 102 may determine the number of per-layer coded modulation symbols (Q') for the jointly coded UCI by using the parameter set (α, β) of the highest priority level in the jointly coded UCI configured for the UCI.
[0160] In certain representative embodiments, the WTRU 102 may encode (e.g., separately encode) UCI (e.g., HARQ-ACK / SR) associated with different priority levels before multiplexing on the PUCCH or PUSCH. In the case of the PUSCH, the WTRU 102 may determine the number of coded modulation symbols (Q') per layer for each priority level by using parameters (α, β) specific to the priority level (e.g., each priority level). The WTRU 102 may map the coded modulation symbols to different resource element sets for the PUSCH.
[0161] When multiplexing UCI associated with different priorities with data on the PUSCH, the WTRU 102 may first encode and multiplex a first subset of UCI and data on the PUSCH assuming a first set of available resource elements, and may then encode a second subset of UCI and replace (e.g., puncture or overwrite) the values of a subset of coded bits or modulation symbols previously determined for the first subset of UCI and / or data. Alternatively, the multiplexing may be performed by "rate matching", wherein the WTRU 102 may encode the first subset assuming a first set of available resource elements reduces the second set of resource elements required to map the modulation symbols of the second subset, and wherein the coded bits of the second subset are modulated and mapped on the second set of available resource elements and do not overwrite the coded bits of the first subset.
[0162] Whether joint coding or separate coding is adopted, and / or whether multiplexing of UCI subsets is performed by puncturing, may depend on: (1) the priority levels associated with the different UCIs; (2) the number of bits of the different UCIs; and (3) the available processing time, which may be determined, for example, by the time difference between a PDCCH transmission or a PDSCH transmission and the corresponding resources for reporting HARQ-ACK (e.g., in the case of HARQ-ACK).
[0163] For example, if the total number of HARQ-ACK bits is below a threshold, or if the number of HARQ-ACK bits for at least one priority level is below a threshold, HARQ-ACKs of different priority levels may be jointly encoded.
[0164] For example, UCI (eg, HARQ-ACK and / or SR) associated with a higher priority level may be multiplexed by puncturing UCI and / or data associated with a lower priority level.
[0165] For example, HARQ-ACK associated with a PDSCH transmission that ends less than X symbols before the start of the PUSCH resources may be multiplexed by puncturing UCI and / or data that may be associated with an earlier PDCCH transmission or an earlier PDSCH transmission.
[0166] In some examples, when HARQ-ACKs associated with multiple priority levels may be multiplexed on the same PUCCH resources or the same PUSCH resources, the WTRU 102 may encode a minimum of M HARQ-ACK bits for at least one priority level even if a PDSCH assignment for the corresponding priority level is not received. M may be set to any positive integer, such as 2. This example may ensure that decoding of the HARQ-ACK associated with the highest priority level does not fail due to a failure to detect a single or multiple PDSCH assignments for lower priority transmissions. This example may be used in situations (e.g., only in such situations) where PUCCH resources or PUSCH resources are allowed to carry HARQ-ACKs associated with lower priority levels. For example, if the PUSCH transmission satisfies the conditions for multiplexing (e.g., potentially multiplexing) HARQ-ACKs of higher priority and lower priority, and the WTRU 102 determines that N1 HARQ-ACK bits will or need to be multiplexed for the higher priority, but there is no HARQ-ACK for the lower priority, then the WTRU 102 may additionally multiplex M HARQ-ACK bits, which are set to 0 for the lower priority.
[0167] In some examples, the SR may be multiplexed with other UCI and / or data on the PUCCH or PUSCH. For example, the SR may be jointly encoded with the HARQ-ACK if (e.g., only if) the SR is associated with the same priority, or the SR may be encoded separately from another UCI. In the latter case, when multiplexed on the PUSCH, the WTRU 102 may determine the number of per-layer coded modulation symbols (Q') for the SR at a given priority level by using parameters (α, β) configured separately for the SR. In certain representative embodiments, the same parameters as for the HARQ-ACK for the same priority level may be reused.
[0168] The number of bits used for the SR may be determined based on the number of scheduling requests K, wherein the corresponding PUCCH resources of the scheduling requests may overlap or will overlap with the PUCCH or PUSCH for multiplexing. For example, in the case where the SR is multiplexed on the PUSCH, K' (e.g., only the K') scheduling requests associated with a higher priority than the PUSCH may be included. For example, a number of bits corresponding to the smallest integer greater than log2(K+1) or log2(K'+1) may be included. Representative process for determining overflow resources
[0169] Fig. 9 is a diagram showing a representative process of using overflow resources.
[0170] refer to Fig. 9 , the overflow resource process 900 may include: At block 910, the WTRU 102 is identified as having mixed traffic capability. At block 920, the WTRU 102 may receive a configuration for primary and overflow UCI. At block 930, the WTRU 102 may determine whether a UCI conflict is identified (e.g., whether it will occur). If a UCI conflict will occur, at block 940, the WTRU 102 may transmit high priority (e.g., first priority or multiplexed) traffic on the primary PUCCH. At block 950, the WTRU 102 may transmit overflow PUCCH usage signaling. At block 960, the WTRU 102 may transmit low priority UCI (e.g., second priority, lower priority and / or remaining UCI) on the overflow PUCCH. If no UCI conflict is identified (e.g., will not occur), then at block 970, the WTRU 102 may transmit on a 5G NR standalone and / or non-standalone PUCCH (e.g., 3GPP Release 15 and above PUCCH).
[0171] For example, the WTRU 102 may be configured with more than one set of PUCCH resources, such as a primary resource and one or more overflow or secondary resources. The number of resource sets selected by the WTRU 102 may be associated with the number of UCIs with different service-based priority levels that the WTRU 102 must transmit. It is contemplated that for latency-based service-based priorities, the primary resources may start earlier and be shorter than the secondary resources.
[0172] In one example, the primary resource and the overflow resource may be in separate time and frequency resources that do not overlap in time or frequency.
[0173] In one example, the primary resource and the overflow resource may be separated in time (e.g., only in time) or in frequency (only in frequency) (e.g., the primary resource and the overflow resource may be separated in time but not in frequency, or separated in frequency but not in time).
[0174] In one example, the WTRU 102 may be statically, semi-statically, and / or dynamically configured with one or more dedicated overflow resources. In certain representative embodiments, the WTRU 102 may be statically, semi-statically, and / or dynamically configured with one or more common overflow resources (e.g., multiple WTRUs 102 may be configured with one or more identical overflow resources). In certain representative embodiments, the WTRU 102 may be statically, semi-statically, and / or dynamically configured with a mix of dedicated overflow resources and common overflow resources.
[0175] In one example, the WTRU 102 may determine the timing and / or resource allocation of the overflow resource based on the resource allocation of the primary resource. The WTRU 102 may conditionally use the overflow resource when the primary resource is dropped, suspended and / or de-prioritized due to intra-WTRU or inter-WTRU prioritization. For example, the WTRU 102 may drop the transmission of the HARQ-ACK (e.g., due to intra-WTRU prioritization) and may use the overflow resource to transmit the de-prioritized HARQ-ACK. The WTRU 102 may determine the overflow PUCCH resource using the previously (or initially) indicated PUCCH resource and HARQ-ACK timing. For example, the WTRU 102 may use the previously signaled K1 (e.g., which is typically the delay between the PDSCH and the corresponding PUCCH) and the PRI associated with the PUCCH resource (e.g., which may be defined as a PUCCH resource indicator) to determine another PUCCH overflow resource that starts after K1 (or a function of the previously signaled K1) slots after the de-prioritized HARQ-ACK transmission.
[0176] The one or more primary resources and overflow resources may be used to transmit UCI for services of different priorities. In this case, higher priority services may be transmitted in the primary resources to satisfy service priority levels (e.g., latency), and / or lower priority services may be transmitted using overflow resources at the same time. In certain representative embodiments, the primary resources may be used to transmit multiplexed higher and lower priority UCIs, while the overflow resources may be used to transmit lower priority UCIs (e.g., only lower priority UCIs).
[0177] Explicit or implicit signaling from the WTRU to a network entity (e.g., a gNB or other access point) may be required to indicate the service (e.g., specific service) in which resource is transmitted. In one example, the WTRU 102 may transmit overflow utilization signaling to the network entity and / or gNB as a separate UCI and / or as part of the UCI on the primary PUCCH resources to indicate the WTRU's use of overflow resources (e.g., in the transmission of overflow utilization signaling). The overflow utilization signaling may be a flag or indicator (e.g., a single-bit indicator or a multi-bit indicator) indicating the use of overflow resources, and / or may include information about the specific PUCCH resources or resources used. In one example, the WTRU 102 may assume or determine that the network entity or gNB may implicitly identify the use of overflow resources due to the transmission of unexpected higher priority UCI on the primary resources.
[0178] In the case where the WTRU 102 is configured with non-dedicated overflow resources, conflicts between or among multiple WTRUs 102 are possible if the WTRUs 102 use the overflow resources simultaneously. The network entity or gNB may explicitly acknowledge receipt of information in the non-dedicated overflow resources. To mitigate the effects of possible conflicts, in one embodiment, the WTRU 102 may be configured to transmit information in the non-dedicated resources in a non-orthogonal manner (e.g., using a non-orthogonal multiple access (NOMA) waveform to allow multiple WTRUs 102 to access the resources), which is acceptable since the transmitted information is likely to be from lower priority traffic. In one example, the WTRU 102 may be configured to access the overflow resources using a listen-before-talk mechanism such as in NR-U or using a random access mechanism in which the WTRU 102 may randomly select a subset of the non-dedicated resources (e.g., select a code, frequency, and / or time). In certain representative examples, the overflow resources may be limited to a PUCCH format that allows data from multiple WTRUs 102 to be multiplexed within the same time-frequency resources (by using sequence-based PUCCH).
[0179] In one example, upon identifying a UCI conflict between traffic with different priority levels, the WTRU 102 may autonomously switch to the main and flooding UCI transmission configuration.
[0180] Some examples of conflict scenarios and possible exemplary solutions are described herein. Hereinafter, "eMBB" may refer to a first priority level based on service, and "URLLC" may refer to a second priority level based on service, such that, for example, URLLC may have a higher priority than eMBB. Representative process for conflict between HARQ-ACK for eMBB and HARQ-ACK for URLLC
[0181] The priority of HARQ-ACK may be indicated in the scheduling DCI (and / or the activation DCI command for DL SPS).
[0182] If the maximum code rate applicable to URLLC is not exceeded, the WTRU 102 may multiplex the HARQ-ACK for eMBB and the HARQ-ACK for URLLC on the PUCCH resources indicated for URLLC, otherwise the WTRU 102 may drop the HARQ-ACK for eMBB. When multiplexing the UCI for eMBB (e.g., only the eMBB UCI), the maximum code rate may be configured separately. The power control parameters for the HARQ-ACK for URLLC may be used. Representative process of collision between eMBB HARQ-ACK and URLLC PUSCH
[0183] The priority of PUSCH may be indicated by DCI and / or indicated through RRC signaling for configured grant type 1. The priority of the HARQ-ACK may be indicated in the scheduling DCI (and / or the activation DCI command for DL SPS). Representative procedure for multiplexing eMBB HARQ-ACK into URLLC PUSCH
[0184] The WTRU 102 may use an additional set of parameters (e.g., α and PUSCH offset ), for example to avoid using too many resources for HARQ-ACK for eMBB for the required reliability, and to ensure that sufficient resources are maintained for PUSCH for URLLC. Representative process of conflict between eMBB PUSCH and URLLC SR
[0185] The priority of PUSCH may be indicated by DCI and / or indicated through RRC signaling for configured grant type 1. The priority of SR may be indicated by RRC signaling for corresponding SR configuration.
[0186] If the conditions are met, the WTRU 102 may multiplex the SR on the PUSCH, otherwise, for example, when the SR is positive, the PUSCH may be dropped at least for the overlapped portion. For example, the conditions may include any of the following: (1) the PUSCH resources in the time domain are within the PUCCH resources used for the SR (e.g., to ensure that latency requirements are met); and / or (2) the number of coded modulation symbols per layer, Q' SR Less than a threshold (e.g., to ensure reliability requirements are met), etc.
[0187] When multiplexing URLLC SR SR on PUSCH for eMBB: At least if the number of HARQ-ACK bits is greater than 2, the WTRU 102 may jointly encode with the URLLC HARQ-ACK (e.g., if present). The WTRU 102 may use an additional parameter set (e.g., α and α) configured for the case where a high priority HARQ-ACK is multiplexed into a low priority PUSCH. PUSCH offset ). Representative process of collision between eMBB PUSCH and URLLC HARQ-ACK
[0188] The priority of PUSCH may be indicated by DCI and / or indicated through RRC signaling for configured grant type 1. The priority of HARQ-ACK may be indicated in the scheduling DCI (and / or the activation DCI command for DL SPS).
[0189] If the conditions are met, the WTRU 102 may multiplex the URLLC HARQ-ACK on the eMBB PUSCH, otherwise the WTRU 102 may drop the PUSCH at least for the overlapped portion. The conditions may include: (1) the PUSCH resource in the time domain is within the subslot in which the URLLC HARQ-ACK is reported, for example to ensure that the latency requirement is met; and / or (2) the number of coded modulation symbols per Q' ACK Less than a threshold, for example to ensure that reliability requirements are met.
[0190] Additional parameter sets (e.g., α and PUSCH offset And it is used in the case where high priority HARQ-ACK is multiplexed into low priority PUSCH.
[0191] In certain representative embodiments, the codebook index may indicate a resource within a slot, such as a subslot, a minislot, or a starting symbol. Representative process for prioritization of transmit power reduction
[0192] If the total WTRU transmit power on the serving cell within the frequency range during a transmission opportunity exceeds or will exceed a threshold (e.g., Pcmax), the WTRU 102 may allocate power according to a priority order. In some examples, the priority order may depend on a service-related priority associated with the transmission (e.g., each transmission). For example, in some embodiments, at least for certain types of transmissions, such as PUCCH and / or PUSCH, the service-related priority of a transmission may take precedence over a priority derived from the type of information carried by the transmission (e.g., whether the transmission carries HARQ-ACK, SR, CSI and / or data only). The prioritization may be set and / or defined by a composite priority index Poverall determined from the two types of priorities, for example as set forth in Equation 1 below: Poverall = Pserv x Nttype + Pttype (1) Where Pserv may be a service-related priority index (e.g., starting at 0 and having higher values indicating lower priority), Pttype may be a priority index derived from the information type, and Nttype may be the number of priority levels for the information type. For example, the value of Nttype may have 3 priority levels (e.g., a value of 2 for Pttype associated with PUSCH transmissions without UCI, a value of 1 for Pttype associated with PUSCH transmissions and / or PUCCH transmissions with CSI, and a value of 0 for Pttype associated with PUSCH transmissions or PUCCH transmissions with SR and / or HARQ_ACK). In some embodiments, PUCCH transmissions with CSI may be associated with the highest Pserv value (e.g., always associated with it).
[0193] For example, the priority order may be in descending order as follows: (1) PRACH transmission on PCell; (2) PUCCH transmission and / or PUSCH transmission, where the priority may be determined by Poverall; (3) non-periodic SRS; and (4) semi-persistent and / or periodic SRS and / or PRACH transmission on SCell.
[0194] Fig.10 is a flow chart illustrating a representative process for using feedback information (eg, HCAI).
[0195] refer to Fig.10, the representative process 1000 may include: at block 1010, the WTRU 102 receives a first physical downlink shared channel (PDSCH) associated with a first type of service, a first priority level, or a first priority in a first time slot or a first mini-time slot, and a second PDSCH associated with a second type of service / priority level / priority in a second time slot or a second mini-time slot. At block 1020, the WTRU 102 may determine a first HARQ codebook acknowledgement index (HCAI) based on an attribute of the first PDSCH or control information associated with the first PDSCH, and determine a second HCAI based on an attribute of the second PDSCH or control information associated with the second PDSCH. At block 1030, the WTRU 102 may generate a first physical uplink control channel (PUCCH) including first HARQ acknowledgement (HARQ-ACK) information according to the first HCAI and a second PUCCH including second HARQ-ACK information according to the second HCAI for any of the following: the second time slot, the second mini-time slot, a subsequent time slot, or a subsequent mini-time slot. At block 1040, the WTRU 102 may transmit the first and second PUCCHs to a network entity. For example, the attributes of the first and second PDSCHs may be any of the following: search space, transmission profile, and / or temporary identifier.
[0196] In certain representative embodiments, the WTRU 102 may multiplex a first set of HARQ-ACK bits as the first HARQ-ACK information and a second set of HARQ-ACK bits as the second HARQ-ACK information in a separate PUCCH resource.
[0197] In certain representative embodiments, the first type of service may be an ultra-reliable low-latency communication (URLLC) service or an enhanced URLLC service, and the second type of service may be another type of service and / or the second type of service may be an enhanced mobile broadband (eMBB) service or a massive machine type communication (mMTC) service.
[0198] In certain representative embodiments, the WTRU 102 may determine the priority of the PDSCH from the indicated HCAI associated with the PDSCH.
[0199] The DCI (e.g., control signaling) may, for example, indicate one or more delay periods associated with various service / priority levels. A respective delay period may indicate one of: (1) a time between a transmission of a respective PDSCH and a transmission of a respective PUCCH; (2) a number of time slots between the transmission of the respective PDSCH and the transmission of the respective PUCCH; and / or (3) a number of mini-time slots between the transmission of the respective PDSCH and the transmission of the respective PUCCH.
[0201] Fig.11 is a flow chart illustrating another representative process for using feedback information (eg, HCAI).
[0202] refer to Fig.11 , the representative process 1100 may include: at block 1110, the WTRU 102 may receive multiple physical downlink shared channels (PDSCHs) associated with different types of services, priority levels, or priorities in multiple time slots or mini-time slots. At block 1120, the WTRU 102 may determine a HARQ codebook acknowledgement index (HCAI) and any of the following: a service type for each of the multiple PDSCHs received, (2) a priority level for each of the multiple PDSCHs received, and / or (3) a priority for each of the multiple PDSCHs received. At block 1130, the WTRU 102 may determine a number of PUCCHs to be transmitted for a corresponding time slot or a corresponding mini-time slot based on the determined HCAI and the determined service type / priority level / priority. At block 1140, the WTRU 102 may multiplex the number of PUCCHs in corresponding different PUCCH resources of the corresponding time slot or corresponding mini-time slot. At block 1150, the WTRU 102 may transmit the determined number of PUCCHs in the corresponding time slot or the corresponding mini-time slot. For example, the determined (1) service type, (2) priority level, and / or (3) priority associated with the PDSCH may be indicated by one or more attributes of the PDSCH, including any of the following: a search space, a transmission profile, and / or a temporary identifier.
[0203] In certain representative embodiments, the WTRU 102 may multiplex a first set of HARQ-ACK bits as first HARQ-ACK information based on a first HCAI, and multiplex a second set of HARQ-ACK bits as second HARQ-ACK information based on a second HCAI in a separate PUCCH resource in a common time slot (e.g., provided that each HARQ codebook includes HARQ-ACK for one or more PDSCHs associated with a HARQ codebook index and / or priority).
[0204] In certain representative embodiments, conditions for separate PUCCH resources in a common time slot may include: a first type of service, a first priority level and / or a first priority being indicated as being associated with a first HCAI, and a different type of service, a different priority level and / or a different priority being indicated as being associated with a second HCAI.
[0205] In certain representative embodiments, the WTRU 102 may multiplex a first set of HARQ-ACK bits as first HARQ-ACK information associated with a first HCAI, and multiplex a second set of HARQ-ACK bits as second HARQ-ACK information associated with a second HCAI in separate PUCCH resources in different time slots (e.g., provided that each HARQ codebook includes HARQ-ACK for one or more PDSCHs associated with a HARQ codebook index and / or priority).
[0206] In certain representative embodiments, the conditions for separate PUCCH resources in different time slots may include: a first type of service, priority level and / or priority level is indicated as being associated with a first HCAI, and a different type of service, different priority level and / or different priority level is indicated as being associated with a second HCAI.
[0207] In certain representative embodiments, the WTRU 102 may multiplex a first group of HARQ-ACK bits associated with the first group of PDSCHs and a second group of HARQ-ACK bits associated with the second group of PDSCHs in a common PUCCH resource of the common time slot based on a multiplexing rule associated with the priority, priority level and / or service type associated with the first and second groups of PDSCHs.
[0208] In certain representative embodiments, the first type of service may be an ultra-reliable low-latency communication (URLLC) service or an enhanced URLLC service, and the second type of service may be another type of service, and / or for example, the second type of service may be an enhanced mobile broadband (eMBB) service or a massive machine type communication (mMTC) service.
[0209] In certain representative embodiments, the priority levels may be a highest priority, eg, associated with most important control signaling and / or data, and one or more lower priorities, eg, associated with less important control signaling and / or data.
[0210] In certain representative embodiments, the WTRU 102 may determine (or whether to) discard at least one PUCCH. For example, the discarding of one or more PUCCHs may be based on any of the following: (1) attributes of at least one PUCCH; (2) a PUCCH format of the at least one PUCCH; (3) the HCAI; (4) a transmission profile; (5) attributes of the PDSCH transmission associated with the at least one PUCCH; and / or (6) attributes of a corresponding physical downlink control channel (PDCCH).
[0211] In certain representative embodiments, the one or more types of services may include any of the following: (1) ultra-reliable low-latency communication (URLLC) service; (2) enhanced URLLC service; (3) enhanced mobile broadband (eMBB) service; and / or (4) massive machine type communication (mMTC) service.
[0212] In certain representative embodiments, each control signal of the HCAI may indicate a delay period associated with any of: (1) time; (2) the number of time slots; or (3) the number of mini-time slots between PDSCH transmission and PUCCH transmission.
[0213] In certain representative embodiments, the WTRU 102 may determine to discard at least one PUCCH or PUSCH. For example, the WTRU 102 may determine to discard the at least one PUCCH or PUSCH based on any of the following: (1) attributes of the at least one PUCCH; (2) a PUCCH format of the at least one PUCCH; (3) an HARQ codebook index; (4) a transmission profile; (5) attributes of the PDSCH transmission associated with the at least one PUCCH; (6) a priority level; (7) a relative priority level; and / or (8) attributes of a corresponding physical downlink control channel (PDCCH).
[0214] Fig.12 is a flow chart illustrating a representative process for time domain overlap (eg, time domain overlap of eMBB and URLLC information / control signaling).
[0215] refer to Fig.12, the representative process 1200 may include: at block 1210, the WTRU 102 determines that a scheduling request (SR) or HARQ information associated with a particular priority level (e.g., enhanced mobile broadband (eMBB) service) will overlap in the time domain with a physical uplink shared channel (PUSCH) associated with a higher priority level (e.g., ultra-reliable low latency communication (URLLC) service or enhanced URLLC (eURLLC) service). At block 1220, under the condition that the SR or HARQ information associated with the lower priority level (e.g., eMBB service) will overlap in the time domain with the PUSCH associated with the higher priority level (e.g., URLLC or eURLLC service), the WTRU 102 may multiplex the SR or HARQ information associated with the lower priority level on the PUSCH associated with the higher priority level. At block 1230, the WTRU 102 may transmit the PUSCH.
[0216] In certain representative embodiments, the WTRU 102 may determine a first priority level for the SR or the HARQ information (eg, associated with an eMBB service) and a second priority level for the PUSCH (eg, associated with a URLLC service or an eURLLC service).
[0217] In certain representative embodiments, multiplexing the SR or the HARQ information on the PUSCH may also be conditioned on a predetermined rule associated with the first and second priority levels.
[0218] Fig.13 is a flow chart illustrating a representative process for using overflow resources for deprioritized information / control signaling (eg, HARQ acknowledgement (HARQ-ACK)).
[0219] refer to Fig.13, the representative process 1300 may include: At block 1310, the WTRU 102 may configure primary uplink resources and at least one uplink overflow resource. At block 1320, the WTRU 102 may receive information or control signaling. At block 1330, the WTRU 102 may determine whether a HARQ acknowledgement (HARQ-ACK) of the information or control signaling is deprioritized. At block 1340, the WTRU 102 may transmit the HARQ-ACK on the uplink overflow resource if the HARQ-ACK is deprioritized. At block 1350, the WTRU 102 may transmit the HARQ-ACK on the primary uplink resource if the HARQ-ACK is not deprioritized. For example, the WTRU 102 may determine whether there is a conflict between the HARQ-ACK and any of the following: other information or other control signaling may occur, the WTRU 102 may determine whether the priority level of the HARQ-ACK exceeds the priority level of the other information or the other control signaling, and if the priority level of the HARQ-ACK does not exceed the priority level of the other information or the other control signaling, the WTRU 102 may deprioritize the HARQ-ACK.
[0220] The primary resource and overflow resource may be in separate time resources and frequency resources that may or may not overlap in time or frequency.
[0221] Fig.14 is a flow chart illustrating a representative process for using bit field interpretation (eg, based on service type).
[0222] refer to Fig.14 , the representative process 1400 may include: At block 1410, the WTRU 102 receives information including downlink control information (DCI). At block 1420, the WTRU 102 may determine or obtain a service type / priority level / priority provisioned for the WTRU from the received information. At block 1430, the WTRU 102 may perform an interpretation of a set of bit fields in the received DCI based on the determined service type, the determined priority level, and / or the determined priority. At block 1440, the WTRU 102 may configure the WTRU based on the interpretation of the set of bit fields. For example, for a first type of service, priority level, and / or priority, the interpretation of at least one bit field in the set of bit fields may be different from that of a second type of service, priority level, and / or priority.
[0223] In certain representative embodiments, the interpretation of at least one bit field in the set of bit fields may be associated with: (1) a first type of unit for a first type of service / priority level / priority, and (2) a second type of unit for a second type of service / priority level / priority. For example, the first type of unit is: (1) a symbol; (2) a group of symbols; (3) a mini-slot; (4) a time slot; or (5) a subframe, and / or the second type of unit is a different one of: (1) the symbol; (2) the group of symbols; (3) the mini-slot; (4) the time slot; or (5) the subframe. As another example, the first type of unit may be a symbol used in association with HARQ feedback timing for an ultra-reliable low-latency communication (URLLC) service or an enhanced URLLC service; and the second type of unit may be a time slot used in association with HARQ feedback timing for an enhanced mobile broadband (eMBB) service.
[0224] In certain representative embodiments, the WTRU 102 may determine or obtain one or more types of service / priority levels / priorities specified for the WTRU from any of: (1) the DCI; (2) radio resource control (RRC) signaling; and / or (3) one or more system information blocks (SIBs).
[0225] In certain representative embodiments, the service type may be any of: an ultra-reliable low-latency communication (URLLC) type service; an enhanced URLLC; an enhanced mobile broadband (eMBB) type service; or a massive machine type communication (mMTC) type service.
[0226] In certain representative embodiments, the received information may include any of the following: control channel configuration information and / or PDSCH time domain values. For example, the WTRU 102 may determine the type, priority level, and / or priority of the specified service based on the included control channel configuration information or the included PDSCH time domain value.
[0227] In certain representative embodiments, the control channel configuration information may include any of the following: (1) search space monitoring mode; (2) search space monitoring periodicity; (3) search space duration; (4) CORESET configuration; (5) RNTI for scrambling cyclic redundancy check (CRC); and / or (6) bandwidth portion configuration.
[0228] In certain representative embodiments, when the DCI received by the WTRU 102 is within a search space configured with a search space monitoring mode, the WTRU 102 may determine that the service type, priority level, or priority specified for the WTRU is a first service type, a first priority level, or a first priority, and when the DCI received by the WTRU is not within a search space configured with the search space monitoring mode, the WTRU 102 may determine that the service type specified for the WTRU is a second service type, a second priority level, or a second priority.
[0229] In certain representative embodiments, when the monitoring periodicity exceeds the periodicity threshold, the WTRU 102 may determine that the service type, priority level or priority specified for the WTRU is a first service type, a first priority level or a first priority, and when the monitoring periodicity does not exceed the periodicity threshold, the WTRU 102 may determine that the service type, priority level or priority specified for the WTRU is a second service type, a second priority level or a second priority.
[0230] In certain representative embodiments, under the condition that the DCI received by the WTRU 102 is in a search space with a duration shorter than K time slots, where K is an integer, the WTRU 102 may determine that the service type, priority level, or priority specified for the WTRU is a first service type, a first priority level, or a first priority, and under the condition that the duration is equal to or longer than K time slots, the WTRU 102 may determine that the service type, priority level, or priority specified for the WTRU is a second service type, a second priority level, or a second priority.
[0231] In certain representative embodiments, when the PDSCH time domain value is below a threshold or within a range between thresholds, the WTRU 102 may determine that the service type, priority level, or priority level specified for the WTRU is a first service type, a first priority level, or a first priority level, and when the PDSCH time domain value is not below the threshold or is not within a range between the thresholds, the WTRU 102 may determine that the service type, priority level, or priority level specified for the WTRU is a second service type, a second priority level, or a second priority level.
[0232] In certain representative embodiments, the set of bit fields in the received DCI may include a HARQ timing indication value in a HARQ timing indication bit field. For example, the interpretation of the HARQ timing indication value in the HARQ timing indication bit field may be based on any of the following: (1) one or more physical downlink shared channel (PDSCH) time domain allocation values; (2) DMRS mapping type; (3) the starting symbol of the PDSCH; (4) the length of the PDSCH transmission; (5) the offset or delay between the reception of the PDCCH and the starting symbol of the PDSCH; and / or (6) one or more HARQ process ID values.
[0233] In certain representative embodiments, if the PDSCH duration is below a threshold, the WTRU 102 may determine that the PDSCH transmission belongs to a first group of PDSCH transmissions associated with a first type of service, a first priority, or a first priority; otherwise, determine that the PDSCH transmission belongs to a second group of PDSCH transmissions associated with a second type of service, a second priority, or a second priority.
[0234] Fig.15 is a flow chart illustrating a representative process for HARQ feedback (eg, based on service type).
[0235] refer to Fig.15 , the representative process 1500 may include: at block 1510, the WTRU 102 may receive information via the WTRU. At block 1520, the WTRU 102 may determine from the received information that the WTRU is provisioned for a first type of service / priority level / priority. At block 1530, the WTRU 102 may generate coded bits for transmission associated with the first type of service / priority level / priority. At block 1540, the WTRU 102 may overwrite a subset of the generated coded bits as overwritten coded bits with coded bits associated with a second type of service / priority level / priority to generate a coded bit sequence associated with the first and second service / priority level / priority, the second type of service / priority level / priority having a higher priority level than the first type of service / priority level / priority. At block 1550, the WTRU 102 may generate a signal for transmission using the coded bit sequence associated with the first and second service / priority level / priority. At block 1550, the WTRU 102 may transmit the signal to a network entity.
[0236] In certain representative embodiments, the coded bits of the transmitted signal may include a set of coded bits associated with the first type of service / priority level / priority control function or data and a set of coded bits associated with the second type of service / priority level / priority control function.
[0237] In certain representative embodiments, the first type of service may be an enhanced mobile broadband (eMBB) service, and the second type of service may be an ultra-reliable low-latency communication (URLLC) or enhanced URLLC.
[0238] In certain representative embodiments, the control function or data of the first type of service / priority level / priority may be any of the following of the first type of service / priority level / priority: (1) scheduling request (SR); (2) HARQ-ACK; (3) CSI; or (4) data, and / or the control function of the second type of service / priority level / priority may be any of the following of the second type of service / priority level / priority: (1) SR; (2) HARQ-ACK; or (3) CSI.
[0239] In certain representative embodiments, the WTRU 102 may determine whether a number of coded bits of a first type of service / priority level / priority level to be overwritten has a corresponding relationship with a number of coded bits that replace the overwritten bits. For example, in the case where a number of bits of a first type of service, a first priority level, or a first priority level to be overwritten has a corresponding relationship with a number of coded bits that are used to replace the overwritten bits, the WTRU 102 may overwrite the number of coded bits of the first type of service, the first priority level, or the first priority level. As another example, in the case where a number of coded bits of a first type of service, a first priority level, or a first priority level to be overwritten has no corresponding relationship with a number of coded bits to replace the overwritten bits, the WTRU 102 may discard a portion of the coded bits of the first type of service, the first priority level, or the first priority level without overwriting them, and replace the discarded bits with a set of coded bits associated with a second type of service, a second priority level, or a second priority level.
[0240] The overwriting of the subset of the coded bits associated with the first service type, the first priority level, or the first priority may include: the WTRU determining a first coded bit sequence associated with the first service type, the first priority level, or the first priority; determining positions in the first coded bit sequence associated with the first type of service, the first priority level, or the first priority to be replaced with coded bits associated with the second type of service, the second priority level, or the second priority; and removing the coded bits at the determined positions of the first sequence; and / or inserting coded bits associated with the second type of service at the determined positions.
[0241] Fig.15 is a flow chart illustrating a representative process for HARQ feedback (eg, based on service type).
[0242] refer to Fig.15 , the representative process 1500 may include: At block 1510, the WTRU 102 receives information. At block 1520, the WTRU 102 may determine from the received information that the WTRU is provisioned for a first type of service or a first priority level and a second type of service or a second priority level. At block 1530, the WTRU 102 may configure the WTRU to transmit a first HARQ feedback associated with the first type of service or the first priority level and a second HARQ feedback associated with the second type of service or the second priority level.
[0243] In certain representative embodiments, the configuration of the WTRU for transmitting the first HARQ feedback associated with the first service type or the first priority level and the second HARQ feedback associated with the second service type or the second priority level may include setting a first portion of time-frequency resources to carry the first HARQ feedback and setting a second separate portion of the time-frequency resources to carry the second HARQ feedback.
[0244] In certain representative embodiments, the WTRU 102 may receive first data associated with a first type of service or a first priority level and second data associated with a second type of service or a second priority level, such that a first delay time between receiving the first data and transmitting a first HARQ feedback may be less than a second delay time between receiving the second data and transmitting a second HARQ feedback. For example, the first type of service or the first priority level may be or may correspond to an ultra-reliable low-latency communication (URLLC) service or an enhanced URLLC (eURLLC) service, and the second type of service or the second priority level may be or may correspond to an enhanced mobile broadband (eMBB) service. For example, the first priority level may be a priority level associated with a URLLC or eURLLC service, and the second priority level may be a priority level associated with eMBB.
[0245] In certain representative embodiments, the second HARQ feedback may be sent in a long format physical uplink control channel (PUCCH), and / or the first HARQ feedback may be sent in a format having a shorter latency than the second HARQ feedback.
[0246] Fig.16 is a flow chart showing a representative overwrite process.
[0247] refer to Fig.16 , the representative process 1600 may include: At block 1610, the WTRU 102 receives information. At block 1620, the WTRU 102 may determine from the received information that the WTRU 102 is specified for a first type of service or a first priority level. At block 1630, the WTRU 102 may generate coded bits for transmission associated with the first type of service / priority level. At block 1640, the WTRU 102 may overwrite a subset of the generated coded bits as overwritten coded bits with coded bits associated with a second type of service or a second priority level to generate a coded bit sequence associated with a first and a second service / priority level. In some embodiments, the second type of service may have a higher priority level than the priority level of the first type of service. At block 1650, the WTRU 102 may generate a signal for transmission using the coded bit sequence associated with the first and second service / priority levels. At block 1660, the WTRU 102 may transmit the generated signal to a network entity.
[0248] In certain representative embodiments, the coded bits of the transmitted signal may include a set of coded bits associated with a control function or data of a first type of service / priority level and a set of coded bits associated with a control function of a second type of service / priority level. For example, the first type of service / priority level may be or may correspond to an eMBB service, and the second type of service may be a URLLC service or an eURLLC service.
[0249] The control function or data of the first type of service / priority level may be any of the following for the first type of service / priority level: (1) scheduling request (SR); (2) HARQ-ACK; (3) CSI; and / or (4) data; and / or the control function of the second type of service / priority level may be any of the following for the second type of service / priority level: (1) SR; (2) HARQ-ACK; and / or (3) CSI.
[0250] In certain representative embodiments, the WTRU 102 may determine whether a number of coded bits of a first type of service / priority level to be overwritten correspond to a number of coded bits to replace the overwritten bits, and if the number of coded bits of the first type of service / priority level to be overwritten correspond to the number of coded bits to replace the overwritten bits, the WTRU 102 may overwrite the number of coded bits of the first type of service / priority level.
[0251] In certain representative embodiments, in the event that a number of coded bits of a first type of service / priority level to be overwritten do not correspond to a number of coded bits to replace the coded bits to be overwritten, the WTRU 102 may discard a portion of the coded bits of the first type of service / priority level and replace the discarded bits with a set of coded bits associated with a second type of service / priority level. For example, overwriting a subset of coded bits associated with a first type of service / priority level may include: the WTRU 102 determining a first coded bit sequence associated with a first type of service / priority level; determining a position in the first coded bit sequence associated with the first type of service / priority level to be replaced with a coded bit associated with the second type of service / priority level; removing the coded bit at the determined position of the first sequence; and / or inserting a coded bit associated with the second type of service / priority level at the determined position.
[0252] Fig.17 is a flow chart illustrating a representative process for avoiding anticipated conflicts.
[0253] refer to Fig.17 , the representative process 1700 may include: at block 1710, the WTRU 102 selects any of: (1) a multiplexing operation for multiplexing coded bits of a first type of service / priority level with coded bits of a second type of service / priority level; (2) an overwrite operation for overwriting coded bits of the first type of service / priority level with coded bits of the second type of service / priority level; and / or (3) a discard / insert operation for discarding coded bits of the first type of service / priority level and inserting coded bits of the second type of service / priority level in place of the discarded coded bits based on a suitability criterion. At block 1720, the WTRU 102 may generate a coded bit sequence associated with the first and second services using the selected operation. At block 1730, the WTRU 102 may generate a signal for transmission using the coded bit sequence. At block 1740, the WTRU 102 may transmit the signal to a network entity.
[0254] In certain representative embodiments, the suitability criteria may be based on any of the following: (1) a service-based priority level; (2) a delay requirement for the second type of service / priority level; (3) a duration of the conflicting resource; (4) an end time of the conflicting resource; (5) a maximum time delay and / or offset configured by a higher layer; (6) a periodicity of the conflicting resource; (7) a reliability requirement for the second type of service / priority level; (8) a number of coded modulation symbols per layer being lower than a first threshold; (9) a maximum overwrite amount; (10) a coding rate associated with the conflicting resource being less than a second threshold; and / or (11) a total number of coded bits associated with the first or second type of service / priority level being less than a maximum payload configured for the conflicting resource.
[0255] Fig.18 is a flow chart showing a representative multiplexing process.
[0256] refer to Fig.18, the representative process 1800 may include: at block 1810, the WTRU 102 determines whether one or more collisions between multiple transmissions are expected. At block 1820, the WTRU 102 may determine the timing or status of the expected collisions. At block 1830, in the event that at least one collision is expected, the WTRU 102 may determine whether to initiate an action (e.g., discard and / or not start certain expected subsequent actions) to mitigate the at least one collision at a first layer or a second layer based on the timing or status of the expected collision. At block 1840, the WTRU 102 may initiate the action at the determined layer to mitigate the at least one collision. For example, the expected collision may be between any of: (1) a physical uplink shared channel (PUSCH) and a scheduling request (SR); (2) a PUSCH and uplink control information (UCI); and / or (3) higher priority uplink control information and lower priority uplink control information.
[0257] In certain representative embodiments, the WTRU 102 may determine whether a scheduling request (SR) or uplink control information (UCI) transmitted in a first transmission has been signaled to a physical layer as the first layer, or whether construction of the PUSCH has started at the physical layer.
[0258] In certain representative embodiments, the WTRU 102 may determine to initiate the action at the physical layer if the SR or UCI has been signaled to the physical layer or the construction of the PUSCH has been started at the physical layer; or (2) determine to initiate the action at the MAC layer if the SR or the UCI has not been signaled to the physical layer or the construction of the PUSCH has not been started at the physical layer. For example, if the WTRU 102 has already signaled a higher priority SR that overlaps with the PUSCH, the WTRU 102 may not construct a MAC PDU.
[0259] For example, the initiation of the action at the determined layer may include any of the following: (1) discarding the SR or the UCI at the physical layer after the SR or the UCI has been signaled; (2) stopping the signaling of the SR or the UCI at the MAC layer; (3) discarding or suspending the PUSCH at the physical layer; and / or (4) stopping the signaling of the PUSCH at the MAC layer.
[0260] Fig.19 is a flow chart illustrating a representative process, eg, for transmission of uplink control information (UCI).
[0261] refer to Fig.19, the representative process 1900 may include: At block 1910, the WTRU 102 may configure the WTRU to transmit multiple PUSCH transmissions overlapping in a time slot and / or in the time domain. At block 1920, the WTRU 102 may select at least one PUSCH to multiplex uplink control information (UCI) based on one or more criteria, including one or more service level priorities associated with each of the PUSCH transmissions. At block 1930, the WTRU 102 may multiplex the UCI on the selected PUSCH. At block 1940, the WTRU 102 may transmit the PUSCH carrying the multiplexed UCI. For example, the one or more criteria may include whether the PUSCH transmission is suitable for transmission of a combination of UCI and data.
[0262] In certain representative embodiments, the PUSCH transmissions in the time slots or overlaps may be on different serving cells and / or different carriers, and / or each PUSCH transmission may have a different service-related priority.
[0263] In certain representative embodiments, the WTRU 102 may select a PUSCH for multiplexing UCI based on the service level priority of the PUSCH and / or the service level priority of the UCI.
[0264] The system and method for processing data according to a representative embodiment can be executed by one or more processors executing a sequence of instructions contained in a storage device. These instructions can be read into the storage device from other computer-readable media such as auxiliary data storage devices (one or more). The execution of the sequence of instructions contained in the storage device causes the processor to operate, for example, as described above. In an alternative embodiment, hard-wired circuits can be used to replace software instructions or in combination with software instructions to implement the present invention. Such software can be run on a processor that is remotely contained in a robot assistance / device (RAA) and / or another mobile device. In the latter case, data can be transmitted between the RAA or other mobile devices containing sensors and a remote device containing the processor via a wired or wireless manner, and the processor runs software that performs the scale estimation and compensation as described above. According to other representative embodiments, some of the processing described above with respect to positioning can be performed in a device containing a sensor / camera, and the remaining processing can be performed in a second device after receiving partially processed data from the device containing the sensor / camera.
[0265] Although the features and elements are described above in specific combinations, it will be understood by those skilled in the art that each feature or element may be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware embedded in a computer-readable medium and executed by a computer or processor. Examples of non-transitory computer-readable media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, buffer memory, semiconductor storage devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM discs and digital versatile discs (DVDs). A processor associated with the software may be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any host computer.
[0266] In addition, in the above-mentioned embodiments, processing platforms, computing systems, controllers and other devices including processors are mentioned. These devices may include at least one central processing unit ("CPU") and memory. According to the practice of those skilled in the art of computer programming, references to symbolic descriptions of actions and operations or instructions may be performed by various CPUs and memories. These actions and operations or instructions may be referred to as "being executed", "computer execution" or "CPU execution".
[0267] Those skilled in the art will appreciate that the operations or instructions described by the actions and symbols include the manipulation of electrical signals by the CPU. The electrical system representation can identify data bits, which cause the electrical signals to be transformed or restored and the maintenance of the storage location of the data bits in the storage system to thereby reconfigure or otherwise change the operation of the CPU and other processing of the signal. The storage location of the data bits is maintained to have specific electrical, magnetic, optical or organic properties corresponding to or representing the data bits. It should be understood that the representative embodiments are not limited to the above-mentioned platforms or CPUs and other platforms and CPUs can support the provided methods.
[0268] The data bits may also be maintained on a computer-readable medium, including a magnetic disk, an optical disk, and any other volatile (e.g., random access memory ("RAM")) or non-volatile (e.g., read-only memory ("ROM")) CPU-readable mass storage system. The computer-readable medium may include cooperating or interconnected computer-readable media that reside exclusively on a processor system or distributed among multiple interconnected processing systems that may be local or remote to the processing system. It will be appreciated that the representative embodiments are not limited to the above-described memories and that other platforms and memories may support the described methods. It should be appreciated that the representative embodiments are not limited to the above-described platforms or CPUs and that other platforms and CPUs may also support the provided methods.
[0269] In the illustrated embodiment, any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and / or any other computing device.
[0270] There is a slight distinction between hardware and software implementations of systems. The use of hardware or software is generally (but not always, as the choice between hardware and software can be important in certain environments) a design choice that considers a trade-off between cost and efficiency. There can be various tools (e.g., hardware, software, and / or firmware) that affect the processes and / or systems and / or other technologies described herein, and the preferred tools can change with the context of the deployed processes and / or systems and / or other technologies. For example, if the implementer determines that speed and accuracy are most important, the implementer may choose to use primarily hardware and / or firmware tools. If flexibility is most important, the implementer may choose to use primarily software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.
[0271] The above detailed description has presented various embodiments of the device and / or process through the use of block diagrams, flow charts and / or examples. To the extent that these block diagrams, flow charts and / or examples include one or more functions and / or operations, those skilled in the art will understand that each function and / or operation within these block diagrams, flow charts or examples can be implemented separately and / or together by a wide range of hardware, software or firmware or substantially any combination thereof. Suitable processors include, for example, general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application-specific integrated circuits (ASICs), application-specific standard products (ASSPs); field-programmable gate array (FPGA) circuits, any other type of integrated circuit (IC) and / or state machines.
[0272] The present disclosure is not limited to the specific embodiments described in this application, which are intended to be examples of various aspects. Many modifications and variations can be made without departing from its essence and scope, which are known to the art at any time. The elements, actions or instructions used in the description of this application should not be understood as being key or necessary to the present invention unless explicitly stated. In addition to these methods and devices listed herein, those skilled in the art can also know functionally equivalent methods and devices within the scope of the present disclosure based on the above description. These modifications and variations should also fall within the scope of the appended claims. The present disclosure is limited only by the appended claims, including the comprehensive scope of its equivalent. It should be understood that the present disclosure is not limited to a specific method or system.
[0273] It should also be understood that the terminology used herein is for the purpose of describing specific embodiments only and is not intended to be limiting. As used herein, when referring to the term "station" and its abbreviation "STA", "user equipment" and its abbreviation "UE" may mean: (i) a wireless transmit and / or receive unit (WTRU), such as described below; (ii) any of multiple embodiments of the WTRU, such as described below; (iii) a wireless and / or wired (e.g., wirelessly communicable) device configured with some or all of the structure and functionality of the WTRU, such as described below; (iii) a device with wireless capabilities and / or wired capabilities that is configured with less than all of the structure and functionality of the WTRU, such as described below; or (iv) the like. Reference is made below to Figures 1A-1D Details are provided for an example WTRU which may represent any of the UEs described herein.
[0274] In certain representative embodiments, some parts of the subject matter described herein may be implemented via application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, those skilled in the art will appreciate that some aspects of the embodiments disclosed herein, in whole or in part, may equally be implemented by integrated circuits, as one or more computer programs running on one or more computers (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware, or substantially any combination of these, and that designing circuits and / or writing codes for the software and / or firmware according to the present disclosure is known to those skilled in the art. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be distributed as program products in various forms, and that the exemplary embodiments of the subject matter described herein are applicable, regardless of the specific type of signal-bearing medium used to actually perform the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media, such as floppy disks, hard disks, CDs, DVDs, digital tapes, computer memories, etc., and transmission media, such as digital and / or analog communication media (e.g., optical cables, waveguides, wired communication links, wireless communication links, etc.).
[0275] The subject matter described here sometimes shows different components, which are contained in or connected to different other components. It can be understood that these depicted architectures are only examples, and many other architectures that implement the same function in practice can be implemented. Conceptually, any arrangement of components that implement the same function more effectively "associated" can implement the desired function. Therefore, any two components combined here to implement a specific function can be regarded as "associated" to each other to implement the desired function, regardless of the architecture or intermediate components. Similarly, any two components associated can also be regarded as "operationally connected" or "operationally coupled" to implement the desired function, and any two components that can be associated in this way can also be regarded as "operationally couplable" to each other to implement the desired function. Specific examples of operational coupling include but are not limited to physically pairable and / or physically interactive components and / or wirelessly interactive and / or wirelessly interactive components and / or logically interactive and / or logically interactive components.
[0276] With respect to the use of substantially any plural and / or singular terms herein, those skilled in the art may translate from the plural to the singular and / or from the singular to the plural as is appropriate to the context and / or application. For purposes of clarity, various singular / plural permutations may be explicitly set forth herein.
[0277] Those skilled in the art will appreciate that the terms used herein in general and in particular in the claims (e.g., the body of the claims) are generally "open" terms (e.g., the term "including" should be understood as "including but not limited to", the term "having" should be understood as "having at least", the term "including" should be understood as "including but not limited to", etc.). Those skilled in the art will also appreciate that if a claim is to describe a specific number, it will be explicitly described in the claim, and there is no such meaning in the absence of such description. For example, if only one item is to be indicated, the term "single" or similar language may be used. To aid understanding, the following claims and / or the description herein may include the use of the preposition phrases "at least one" or "one or more" to introduce a claim description. However, the use of these phrases should not be understood to imply that a claim description introduced by the indefinite article "a" will limit any particular claim containing such an introduced claim description to an embodiment containing only one such description, even if the same claim includes the preposition phrases "one or more" or "at least one" and an indefinite article (e.g., "a") (e.g., "a" should be understood to mean "at least one" or "one or more"). The same is true for the use of definite articles used to introduce claim descriptions. In addition, even if a specific number of claims described in the claims is explicitly described, it can be understood by those skilled in the art that such description should be understood to mean at least the number described (e.g., the description of "two descriptions" alone without other modifiers means at least two descriptions, or two or more descriptions). In addition, in these instances where a convention similar to "at least one of A, B, and C, etc." is used, generally speaking, such a convention is a convention understood by those skilled in the art (e.g., "the system has at least one of A, B, and C" can include but is not limited to the system having only A, only B, only C, A and B, A and C, B and C, and / or A, B and C, etc.). In these instances where a convention similar to "at least one of A, B, or C, etc." is used, generally speaking, such a convention is a convention understood by those skilled in the art (e.g., "the system has at least one of A, B, or C" can include but is not limited to the system having only A, only B, only C, A and B, A and C, B and C, and / or A, B and C, etc.). Those skilled in the art will also appreciate that substantially any separated word and / or phrase representing two or more alternatives, whether in the specification, claims or drawings, should be understood to include the possibility of including one of the two items, any one or both items. For example, the phrase "A or B" is understood to include the possibility of "A" or "B" or "A" and "B". In addition, the term "arbitrary" used herein followed by multiple items and / or multiple items listed is intended to include "arbitrary", "arbitrary combination", "arbitrary multiple" and / or "any combination of multiple" of the multiple items and / or multiple items, either alone or in combination with other items and / or other items.Furthermore, the terms "set" or "group" as used herein are intended to include any number of items, including zero. Furthermore, the term "number" as used herein is intended to include any number, including zero.
[0278] In addition, if features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also described in terms of any individual member or subgroup of members of the Markush group.
[0279] Those skilled in the art will appreciate that, for any and all purposes, such as to provide a written description, all ranges disclosed herein also include any and all possible sub-ranges and combinations of sub-ranges thereof. Any listed range can be easily understood to be sufficient to describe and implement the same range that is divided into at least equal halves, three parts, four parts, five parts, ten parts, etc. As a non-limiting example, each range described here can be easily divided into the lower third, the middle third, and the upper third, etc. Those skilled in the art can also understand that all languages such as "up to", "at least", "greater than", "less than", etc. include the described numbers and can be divided into the above-mentioned sub-ranges accordingly. Finally, those skilled in the art can appreciate that the range includes each individual member. Therefore, for example, a group and / or set with 1-3 cells refers to a group / set with 1, 2, or 3 cells. Similarly, a group / set with 1-5 cells refers to a group / set with 1, 2, 3, 4, or 5 cells, etc.
[0280] Furthermore, the claims should not be read as limited to the order or elements provided unless described to that effect. Furthermore, the use of the term "means for..." in any claim is intended to invoke 35 U.S.C. § 112, 6 or means-plus-function claim format, any claim without the term “means for…” does not have such an intent.
[0281] A processor in association with software may be used to implement a radio frequency transceiver for use in a wireless transmit / receive unit (WTRU), user equipment (UE), terminal, base station, mobility management entity (MME) or evolved packet core (EPC), or any host computer. The WTRU may incorporate modules implemented in hardware and / or software, including software defined radio (SDR), and other components such as a camera, a video camera module, a video phone, an intercom phone, a vibration device, a speaker, a microphone, a television transceiver, a hands-free headset, a keyboard, module, a frequency modulation (FM) radio unit, a near field communication (NFC) module, a liquid crystal display (LCD) display unit, an organic light emitting diode (OLED) display unit, a digital music player, a media player, a video game console module, an Internet browser and / or any wireless local area network (WLAN) or ultra-wideband (UWB) module.
[0282] Throughout the disclosure, a skilled artisan will appreciate that certain representative embodiments may be used instead of or in combination with other representative embodiments.
[0283] Additionally, the methods described herein may be implemented as instructions in a computer program, software, or firmware incorporated in a computer-readable storage medium to be executed by a computer or processor to perform the above-described actions. Examples of non-transitory computer-readable media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, buffer memory, semiconductor storage devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, and any host computer.
Claims
1. A wireless transmit / receive unit (WTRU), the WTRU comprising: A receiver and a transmitter, wherein the receiver is configured to: receiving a first physical downlink shared channel (PDSCH) transmission; receiving a second PDSCH transmission; as well as A processor configured to: determining a first physical uplink control channel (PUCCH) resource for transmission of first hybrid automatic repeat request (HARQ) information associated with the first PDSCH transmission; determining a second PUCCH resource for transmission of second HARQ information associated with the second PDSCH transmission; determining a priority of each of the first HARQ information and the second HARQ information; as well as In a case where the first PUCCH resource overlaps with the second PUCCH resource in time and a priority of the first HARQ information is different from a priority of the second HARQ information, determining whether to allow lower priority HARQ information to be multiplexed with higher priority HARQ information; The transmitter is configured to multiplex the first HARQ information and the second HARQ information and send the multiplexed first HARQ information and the second HARQ information in a single PUCCH transmission, and the multiplexing is conditional on allowing the lower priority HARQ information to be multiplexed with the higher priority HARQ information.
2. The WTRU of claim 1, wherein the receiver is configured to receive configuration information indicating a plurality of PUCCH resource sets to be used for transmission of HARQ information, wherein each of the plurality of PUCCH resource sets comprises a plurality of PUCCH resources.
3. The WTRU of claim 1 , wherein the receiver is configured to receive information in a first downlink control information (DCI), the information comprising (1) a first PUCCH set indication and (2) a first resource indicator, and wherein the first PUCCH set indication and the first resource indicator are separate fields in the first DCI.
4. The WTRU of claim 1 , wherein the receiver is configured to receive information in a second DCI, the information comprising (1) a second PUCCH set indication and (2) a second resource indicator, and wherein the second PUCCH set indication and the second resource indicator are separate fields in the second DCI.
5. The WTRU of claim 2, wherein the receiver is configured to receive information in a first downlink control information (DCI), the information comprising (1) a first PUCCH set indication and (2) a first resource indicator, and wherein the processor is configured to select a first PUCCH resource set from the multiple PUCCH resource sets based at least on the first PUCCH set indication.
6. The WTRU of claim 5 wherein the processor is configured to determine a first PUCCH resource for transmitting the first HARQ information comprises: The processor is configured to select the first PUCCH resource from among the plurality of PUCCH resources of the selected first set of PUCCH resources based at least on the first resource indicator.
7. A WTRU according to claim 2, wherein the receiver is configured to receive information including (1) a second PUCCH set indication and (2) a second resource indicator in a second DCI, and wherein the processor is configured to select a second PUCCH resource set from the multiple PUCCH resource sets based at least on the second PUCCH set indication.
8. The WTRU of claim 7 wherein the processor is configured to determine a second PUCCH resource for transmitting the second HARQ information comprises: The processor is configured to select the second PUCCH resource from the plurality of PUCCH resources of the selected second set of PUCCH resources based at least on the second resource indicator.
9. The WTRU of claim 1 , wherein the single PUCCH transmission includes the higher priority HARQ information and does not include the lower priority HARQ information if multiplexing of the lower priority HARQ information with the higher priority HARQ information is not allowed.
10. The WTRU of claim 1, wherein the lower priority HARQ information and the higher priority HARQ information are separately encoded prior to the multiplexing.
11. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: receiving a first physical downlink shared channel (PDSCH) transmission; determining a first physical uplink control channel (PUCCH) resource for transmission of first hybrid automatic repeat request (HARQ) information associated with the first PDSCH transmission; receiving a second PDSCH transmission; determining a second PUCCH resource for transmission of second HARQ information associated with the second PDSCH transmission; determining a priority of each of the first HARQ information and the second HARQ information; In a case where the first PUCCH resource overlaps with the second PUCCH resource in time and a priority of the first HARQ information is different from a priority of the second HARQ information, determining whether to allow lower priority HARQ information to be multiplexed with higher priority HARQ information; as well as In case the lower priority HARQ information is allowed to be multiplexed with the higher priority HARQ information, the first HARQ information and the second HARQ information are multiplexed, and the multiplexed first HARQ information and the second HARQ information are sent in a single PUCCH transmission.
12. The method according to claim 11, further comprising: Configuration information is received, the configuration information indicating a plurality of PUCCH resource sets to be used for transmission of HARQ information, wherein each of the plurality of PUCCH resource sets includes a plurality of PUCCH resources.
13. The method according to claim 11, further comprising: Information including (1) a first PUCCH set indication and (2) a first resource indicator is received in first downlink control information (DCI), wherein the first PUCCH set indication and the first resource indicator are separate fields in the first DCI.
14. The method according to claim 11, further comprising receiving information including (1) a second PUCCH set indication and (2) a second resource indicator in a second DCI, wherein: The second PUCCH set indication and the second resource indicator are separate fields in the second DCI.
15. The method according to claim 12, further comprising: receiving information including (1) a first PUCCH set indication and (2) a first resource indicator in a first downlink control information (DCI); as well as A first PUCCH resource set is selected from the multiple PUCCH resource sets based at least on the first PUCCH set indication.
16. The method of claim 15, wherein determining the first PUCCH resource for transmitting the first HARQ information comprises: The first PUCCH resource is selected from the plurality of PUCCH resources of the selected first set of PUCCH resources based at least on the first resource indicator.
17. The method according to claim 12, further comprising: receiving, in a second DCI, information including (1) a second PUCCH set indication and (2) a second resource indicator; as well as A second PUCCH resource set is selected from the plurality of PUCCH resource sets based at least on the second PUCCH set indication.
18. The method of claim 17, wherein determining the second PUCCH resource for transmitting the second HARQ information comprises: The second PUCCH resource is selected from the plurality of PUCCH resources of the selected second set of PUCCH resources based at least on the second resource indicator.
19. The method of claim 11, wherein the single PUCCH transmission includes the higher priority HARQ information and does not include the lower priority HARQ information under the condition that the lower priority HARQ information is not allowed to be multiplexed with the higher priority HARQ information.
20. The method according to claim 11, wherein: The lower priority HARQ information and the higher priority HARQ information are separately encoded before the multiplexing.