Patent Description:
The fifth generation mobile wireless communication system (<NUM>) or new radio (NR) has been specified in <NUM>rd Generation Partnership Project (3GPP). It includes two releases up to now, Release-<NUM> (R-<NUM>) and Release-<NUM> (R-<NUM>). Only unicast transmission is supported. Since multicast/broadcast transmission is very useful for some applications (such as NSPS (Network Security Public Safety), V2X (Vehicle to Anything) etc.), it has been agreed that broadcast/multicast transmission in Release-<NUM> (R-<NUM>) for NR should be studied.

Actually, multicast/broadcast has been supported in Long Term Evolution (LTE). There are two different ways to support multicast/broadcast: Single Cell-Point to Multipoint (SC-PTM) or Multimedia Broadcast Multicast Services (MBMS). Whatever which method is used, there is no feedback from the user equipment (UE) to the network. The advantage of this method is simple. The disadvantage is that the spectrum efficiency is very low. This is because the network does not know if the UE received a packet or not. In order to ensure reliability, it has to use very low coding rate and may also repeat transmissions several times.

To address this issue, it has been proposed to enable Hybrid Automatic Repeat Request (HARQ) feedback for multicast transmission in NR. With HARQ feedback for multicast, one issue is how to transmit HARQ feedback for multicast, especially when there are HARQ feedback for unicast and they need be transmitted in the same uplink (UL) slot.

In NR, an adaptive retransmission scheme called Hybrid Automatic Repeat reQuest (HARQ) is widely used. According to this scheme the receiver of a packet sends back a positive (ACK) or a negative (NACK) acknowledgement to the sender, depending on whether the receiver has decoded the transport block successfully or unsuccessfully, respectively. If it is an ACK the sender will transmit a new transport block and if it is a NACK the sender will retransmit either the same version or a different version of the initial transport block. There can be multiple retransmission attempts for a single data transport block. As used herein, the term multicast refers to transmissions in the downlink from a network node (such as a gNB) to a group of wireless devices (such as UEs). Herein, the terms multicast and Point-To-Multipoint (PTM) may be used interchangeably.

The Physical Downlink Shared Channel (PDSCH) can be scheduled over different number of Orthogonal Frequency Division Multiplex (OFDM) symbols in a slot, occupying consecutive symbols. The PDSCH configuration contains a so called Time Domain Resource Allocation (TDRA) list. <FIG> illustrates an example TDRA list. Specifically, <FIG> illustrates different entries of a PDSCH TDRA list with the respective allocation of symbols for PDSCH. As examples, TDRA entry <NUM> corresponds to the PDSCH allocation of symbols from <NUM> to <NUM>, and entry <NUM> corresponds to the PDSCH allocation of symbols from <NUM> to <NUM>, and so on.

Sometimes the TDRA list is called a set. Each entry in the TDRA list defines a consecutive sequence of symbols that the gNodeB (gNB) can choose. The gNB maps the PDSCH to the chosen sequence of symbols. Which entry the gNB has chosen for a particular slot is signalled by the gNB in the Physical Downlink Control Channel (PDCCH) to the UE.

The UE may miss the PDCCH in a slot and may therefore not know that the gNB transmits a PDSCH in a slot in which the PDSCH is scheduled. However, the UE has knowledge about in which slots the gNB can schedule a PDSCH. Therefore, if the UE does not receive a PDCCH in such a slot, the UE shall transmit as many HARQ NACK signals as the TDRA list contains entries where the symbol-sequences do not overlap (intersect). A NACK is signaled as a value of <NUM> bit in a so called HARQ codebook. We consider here Type-<NUM> or semi-static codebook. Type-<NUM> HARQ-ACK codebook construction is for example specified in 3GPP TS <NUM> Technical Specification Group Radio Access Network; NR; Multiplexing and channel coding; v <NUM>.

Certain problems exist. For example, a problem may be that there is no clear method for how to design the HARQ codebook when multicast need to send their HARQ feedback together with unicast traffic.

The <NPL>" discloses that for the case of shared PUCCH-Config for both unicast and multicast and for ACK/NACK based feedback if supported for multicast, Type-<NUM> HARQ-ACK feedback may be constructed based on the union of the PDSCH TDRA sets of the unicast service and the MBS service.

The United States Patent Application Publication <CIT> discloses methods and apparatus for using HARQ in wireless communications.

The <NPL>" discloses discussions on mechanisms to support group scheduling for Broadcast/Multicast service for RRC_CONNECTED UEs.

Certain aspects of the present disclosure and their embodiments may provide solutions to these or other challenges.

A first aspect provides embodiments of a method by a wireless device as defined in claim <NUM>.

A second aspect provides embodiments of a wireless device as defined in claim <NUM>.

A third aspect provides embodiments of a method by a network node as defined in claim <NUM>.

A fourth aspect provides embodiments of a network node as defined in claim <NUM>.

Certain embodiments may provide one or more of the following technical advantages. For example, one technical advantage may be that certain embodiments provide a joint HARQ codebook for unicast and multicast. Using a joint codebook can be more efficient. For example, using a joint codebook may reduce overall signaling overhead as compared to systems and techniques using separate codebooks for unicast and multicast.

Other advantages may be readily apparent to one having skill in the art. Certain embodiments may have none, some, or all of the recited advantages.

In some embodiments, a more general term "network node" may be used and may correspond to any type of radio network node or any network node, which communicates with a UE (directly or via another node) and/or with another network node. Examples of network nodes are NodeB, MeNB, ENB, a network node belonging to MCG or SCG, base station (BS), multi-standard radio (MSR) radio node such as MSR BS, eNodeB, gNodeB, network controller, radio network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), access point (AP), transmission points, transmission nodes, RRU, RRH, nodes in distributed antenna system (DAS), core network node (e.g. MSC, MME, etc.), O&M, OSS, SON, positioning node (e.g. E-SMLC), MDT, test equipment (physical node or software), etc..

In some embodiments, the non-limiting term user equipment (UE) or wireless device may be used and may refer to any type of wireless device communicating with a network node and/or with another UE in a cellular or mobile communication system. Examples of UE are target device, device to device (D2D) UE, machine type UE or UE capable of machine to machine (M2M) communication, PDA, PAD, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, UE category M1, UE category M2, ProSe UE, V2V UE, V2X UE, etc..

Additionally, terminologies such as base station/gNodeB and UE should be considered non-limiting and do in particular not imply a certain hierarchical relation between the two; in general, "gNodeB" could be considered as device <NUM> and "UE" could be considered as device <NUM> and these two devices communicate with each other over some radio channel. And in the following the transmitter or receiver could be either gNB, or UE.

As described above, multicast/broadcast transmission may be useful for some applications, such as NSPS, V2X etc. For these applications, there is requirement on QoS (quality of service). For example, a requirement may be that packet error rate be less than <NUM>% with a delay budget of X ms. Therefore it is necessary to support HARQ feedback for multicast service in NR. Otherwise, the spectrum efficiency to support multicast service could be very low.

As noted above, proposals have been made to enable Hybrid Automatic Repeat Request (HARQ) feedback for multicast transmission for NR. With HARQ feedback for multicast, one issue is how to transmit HARQ feedback for multicast, especially when there are HARQ feedback for unicast and they need be transmitted in the same uplink (UL) slot.

There has been a further proposal for the construction of a type-<NUM> HARQ codebook. However, the proposal assumes that there is just one PUCCH configuration for unicast service. However, it has also been agreed that multicast service can have its own PUCCH configuration, including a TDRA list that can be different from the unicast PUCCH configuration. As such, it is necessary to consider methods for constructing a HARQ codebook for this more general case.

According to certain embodiments, since multicast service can have its own PUCCH configuration with the downlink data to UL ACK timing configured, the HARQ-ACK codebook should be determined by downlink (DL) data to UL feedback timing in multicast PUCCH configuration and the downlink data to UL feedback timing in unicast PUCCH configuration. As an example, for DCI Format 1_1 (see for example 3GPP TS <NUM> Technical Specification Group Radio Access Network; NR; Multiplexing and channel coding; v16. <NUM>, for a description of this DCI format), this downlink data to UL feedback timing is the dl-DataToUL-ACK in PUCCH configuration. As another example, for DCI Format 1_0, this downlink data to UL feedback timing is fixed to {<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>}.

Certain embodiments discussed herein consider three cases.

According to a first case (Case <NUM>), there is no overlap between the downlink data to UL feedback timing in multicast PUCCH and unicast PUCCH. <FIG> illustrates construction of a type-<NUM> HARQ-ACK Codebook when there is no overlap between the configured sets of dl-DataToUL-ACK of unicast and multicast, according to certain embodiments. Specifically, <FIG> uses DCI Format 1_1 as an example.

In this case, the codebook needs to convey HARQ feedback for slots {n-<NUM>, n-<NUM>, n-<NUM>, n-<NUM>, n-<NUM>}. That is, the DL slots that requires UL HARQ feedback is the union of that from both unicast PUCCH configuration and multicast PUCCH configuration.

Since there is no overlap between the dl-DataToUL-ACK configuration, i.e. at each DL slot there is only either unicast traffic or multicast traffic, the number of HARQ feedback bits per DL slot is determined by the respective TDRA set of unicast or multicast configuration.

According to a second case (Case <NUM>), there is overlap between the dl-DataToUL-ACK configuration in multicast PUCCH and unicast PUCCH. <FIG> illustrates construction of a type-<NUM> HARQ-ACK Codebook when there is overlap <NUM> between the configured set of dl-DataToUL-ACK of unicast <NUM> and the configured set of dl-DataToUL-ACK of multicast <NUM>, according to certain embodiments. Specifically, <FIG> uses DCI Format 1_1 as an example.

In this case, the DL slots that requires UL HARQ feedback is still the union of that from both unicast PUCCH configuration <NUM> and multicast PUCCH configuration <NUM>. Since there is overlap <NUM> between the dl-DataToUL-ACK configurations, at slot N-<NUM>, both multicast and unicast require HARQ feedback, at this DL slot, the number of HARQ feedback bits <NUM> is determined by the union of TDRA set of unicast and multicast. As can be seen in <FIG>, the unicast PUCCH configuration <NUM> includes values <NUM> not included in the multicast PUCCH configuration <NUM>. Similarly, the multicast PUCCH configuration <NUM> includes values <NUM> not included in the unicast PUCCH configuration <NUM>.

According to a third case (Case <NUM>), the dl-DataToUL-ACK configuration in multicast PUCCH and unicast PUCCH is identical. In this case the DL slots that requires UL HARQ feedback is still the union of that from both unicast PUCCH configuration and multicast PUCCH configuration, and the number of HARQ feedback bits per DL slot is determined by the union of TDRA set of unicast and multicast.

To summarize, when multicast traffic is scheduled in a cell together with unicast traffic, and their HARQ feedback can be combined into one codebook, the solution is that the construction of the HARQ-ACK codebook for joint multicast and unicast service is determined by the union of two sets of downlink data to UL ACK timing from multicast configuration and unicast configuration/setting. The values in the union of the set of downlink data to UL feedback time determine the number of DL slots associated with the codebook while the redundant values in the intersection of the sets affect the number of HARQ feedback bits per DL slot.

<FIG> illustrates a wireless network, in accordance with some embodiments. Although the subject matter described herein may be implemented in any appropriate type of system using any suitable components, the embodiments disclosed herein are described in relation to a wireless network, such as the example wireless network illustrated in <FIG>. For simplicity, the wireless network of <FIG> only depicts network <NUM>, network nodes <NUM> and 160b, and wireless devices <NUM>, 110b, and 110c. In practice, a wireless network may further include any additional elements suitable to support communication between wireless devices or between a wireless device and another communication device, such as a landline telephone, a service provider, or any other network node or end device. Of the illustrated components, network node <NUM> and wireless device <NUM> are depicted with additional detail. The wireless network may provide communication and other types of services to one or more wireless devices to facilitate the wireless devices' access to and/or use of the services provided by, or via, the wireless network.

Network node <NUM> and wireless device <NUM> comprise various components described in more detail below.

<FIG> illustrates an example network node <NUM>, according to certain embodiments.

Interface <NUM> is used in the wired or wireless communication of signalling and/or data between network node <NUM>, network <NUM>, and/or wireless devices <NUM>. Radio front end circuitry <NUM> may receive digital data that is to be sent out to other network nodes or wireless devices via a wireless connection.

<FIG> illustrates an example wireless device <NUM>. According to certain embodiments. As used herein, wireless device refers to a device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other wireless devices. Unless otherwise noted, the term wireless device may be used interchangeably herein with user equipment (UE). Communicating wirelessly may involve transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information through air. In some embodiments, a wireless device may be configured to transmit and/or receive information without direct human interaction. For instance, a wireless device may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the network. Examples of a wireless device include, but are not limited to, a smart phone, a mobile phone, a cell phone, a voice over IP (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless cameras, a gaming console or device, a music storage device, a playback appliance, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop-embedded equipment (LEE), a laptop-mounted equipment (LME), a smart device, a wireless customer-premise equipment (CPE), a vehicle-mounted wireless terminal device, etc. A wireless device may support device-to-device (D2D) communication, for Example Embodiment By implementing a 3GPP standard for sidelink communication, vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-everything (V2X) and may in this case be referred to as a D2D communication device. As yet another specific example, in an Internet of Things (IoT) scenario, a wireless device may represent a machine or other device that performs monitoring and/or measurements and transmits the results of such monitoring and/or measurements to another wireless device and/or a network node. The wireless device may in this case be a machine-to-machine (M2M) device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the wireless device may be a UE implementing the 3GPP narrow band internet of things (NB-IoT) standard. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances (e.g. refrigerators, televisions, etc.) personal wearables (e.g., watches, fitness trackers, etc.). In other scenarios, a wireless device may represent a vehicle or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation. A wireless device as described above may represent the endpoint of a wireless connection, in which case the device may be referred to as a wireless terminal. Furthermore, a wireless device as described above may be mobile, in which case it may also be referred to as a mobile device or a mobile terminal.

Wireless device <NUM> may include multiple sets of one or more of the illustrated components for different wireless technologies supported by wireless device <NUM>, such as, for example, GSM, WCDMA, LTE, NR, WiFi, WiMAX, or Bluetooth wireless technologies, just to mention a few. These wireless technologies may be integrated into the same or different chips or set of chips as other components within wireless device <NUM>.

In certain alternative embodiments, antenna <NUM> may be separate from wireless device <NUM> and be connectable to wireless device <NUM> through an interface or port. Antenna <NUM>, interface <NUM>, and/or processing circuitry <NUM> may be configured to perform any receiving or transmitting operations described herein as being performed by a wireless device. Any information, data and/or signals may be received from a network node and/or another wireless device.

Radio front end circuitry <NUM> is connected to antenna <NUM> and processing circuitry <NUM> and is configured to condition signals communicated between antenna <NUM> and processing circuitry <NUM>. In some embodiments, wireless device <NUM> may not include separate radio front end circuitry <NUM>; rather, processing circuitry <NUM> may comprise radio front end circuitry and may be connected to antenna <NUM>. Radio front end circuitry <NUM> may receive digital data that is to be sent out to other network nodes or wireless devices via a wireless connection.

Processing circuitry <NUM> may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and/or encoded logic operable to provide, either alone or in conjunction with other wireless device <NUM> components, such as device readable medium <NUM>, wireless device <NUM> functionality.

In certain embodiments processing circuitry <NUM> of wireless device <NUM> may comprise a SOC.

In certain embodiments, some or all of the functionality described herein as being performed by a wireless device may be provided by processing circuitry <NUM> executing instructions stored on device readable medium <NUM>, which in certain embodiments may be a computer-readable storage medium. The benefits provided by such functionality are not limited to processing circuitry <NUM> alone or to other components of wireless device <NUM>, but are enjoyed by wireless device <NUM> as a whole, and/or by end users and the wireless network generally.

Processing circuitry <NUM> may be configured to perform any determining, calculating, or similar operations (e.g., certain obtaining operations) described herein as being performed by a wireless device. These operations, as performed by processing circuitry <NUM>, may include processing information obtained by processing circuitry <NUM> by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored by wireless device <NUM>, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination.

User interface equipment <NUM> may provide components that allow for a human user to interact with wireless device <NUM>. Such interaction may be of many forms, such as visual, audial, tactile, etc. User interface equipment <NUM> may be operable to produce output to the user and to allow the user to provide input to wireless device <NUM>. The type of interaction may vary depending on the type of user interface equipment <NUM> installed in wireless device <NUM>. For example, if wireless device <NUM> is a smart phone, the interaction may be via a touch screen; if wireless device <NUM> is a smart meter, the interaction may be through a screen that provides usage (e.g., the number of gallons used) or a speaker that provides an audible alert (e.g., if smoke is detected). User interface equipment <NUM> is configured to allow input of information into wireless device <NUM> and is connected to processing circuitry <NUM> to allow processing circuitry <NUM> to process the input information. User interface equipment <NUM> is also configured to allow output of information from wireless device <NUM>, and to allow processing circuitry <NUM> to output information from wireless device <NUM>. Using one or more input and output interfaces, devices, and circuits, of user interface equipment <NUM>, wireless device <NUM> may communicate with end users and/or the wireless network and allow them to benefit from the functionality described herein.

Auxiliary equipment <NUM> is operable to provide more specific functionality which may not be generally performed by wireless devices.

wireless device <NUM> may further comprise power circuitry <NUM> for delivering power from power source <NUM> to the various parts of wireless device <NUM> which need power from power source <NUM> to carry out any functionality described or indicated herein. Power circuitry <NUM> may additionally or alternatively be operable to receive power from an external power source; in which case wireless device <NUM> may be connectable to the external power source (such as an electricity outlet) via input circuitry or an interface such as an electrical power cable. Power circuitry <NUM> may perform any formatting, converting, or other modification to the power from power source <NUM> to make the power suitable for the respective components of wireless device <NUM> to which power is supplied.

UE <NUM>, as illustrated in <FIG>, is one example of a wireless device configured for communication in accordance with one or more communication standards promulgated by the <NUM>rd Generation Partnership Project (3GPP), such as 3GPP's GSM, UMTS, LTE, and/or <NUM> standards. As mentioned previously, the term wireless device and UE may be used interchangeable. Accordingly, although <FIG> is a UE, the components discussed herein are equally applicable to a wireless device, and vice-versa.

For example, communication subsystem <NUM> may be configured to include one or more transceivers used to communicate with one or more remote transceivers of another device capable of wireless communication such as another wireless device, UE, or base station of a radio access network (RAN) according to one or more communication protocols, such as IEEE <NUM>. QQ2, CDMA, WCDMA, GSM, LTE, UTRAN, WiMax, or the like.

In some embodiments, some signaling can be affected with the use of control system <NUM> which may alternatively be used for communication between the hardware nodes <NUM> and radio units <NUM>.

<FIG> illustrates a telecommunication network connected via an intermediate network to a host computer in accordance with some embodiments.

Host computer <NUM> may be under the ownership or control of a service provider or may be operated by the service provider or on behalf of the service provider.

<FIG> illustrates a host computer communicating via a base station with a user equipment over a partially wireless connection in accordance with some embodiments.

Wireless connection <NUM> between UE <NUM> and base station <NUM> is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to UE <NUM> using OTT connection <NUM>, in which wireless connection <NUM> forms the last segment. More precisely, the teachings of these embodiments may improve the data rate, latency, and/or power consumption and thereby provide benefits such as reduced user waiting time, relaxed restriction on file size, better responsiveness, and/or extended battery lifetime.

In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which OTT connection <NUM> passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above or supplying values of other physical quantities from which software <NUM>, <NUM> may compute or estimate the monitored quantities.

<FIG> depicts a method <NUM> by a wireless device, according to certain embodiments. At step <NUM>, the wireless device obtains a codebook that is constructed based on a multicast configuration and a unicast configuration. At step <NUM>, based on the codebook, the wireless device transmits, to a network node, feedback for a multicast transmission and unicast data.

In a particular embodiment, the multicast configuration comprises a first downlink data to uplink feedback timing set and the unicast configuration comprises a second downlink data to uplink feedback timing set.

In a particular embodiment, the first downlink to uplink feedback timing set comprises a first TDRA list indicating an allocation of symbols for a downlink shared channel for the multicast transmission and the second downlink to uplink feedback timing set comprises a second TDRA list indicating an allocation of symbols for the downlink shared channel for the unicast data.

In a particular embodiment, the codebook is constructed based on a union of the first downlink data to uplink feedback timing set and the second downlink data to uplink feedback timing set.

In a particular embodiment, a number of downlink slots associated with the codebook is determined based on at least one value in the union of the first downlink data to uplink feedback timing set and the second downlink data to uplink feedback timing set.

In a particular embodiment, a number of feedback bits per downlink slot is affected by a number of redundant values in an intersection of the first downlink data to uplink feedback timing set and the second downlink data to uplink feedback timing set.

In a particular embodiment, the intersection comprises at least one slot-sequence that overlaps within the first downlink data to uplink feedback timing set and the second downlink data to uplink feedback timing set.

In a particular embodiment, a number of downlink slots associated with the codebook is determined based on a number of values in the union.

In a particular embodiment, the union comprises no overlap between the multicast configuration and the unicast configuration, and in the codebook, a number of feedback bits per downlink slot is determined by the first downlink data to uplink feedback timing set and the second downlink data to uplink feedback timing set.

In a particular embodiment, there is no overlap between the multicast configuration and the unicast configuration when, at each downlink slot, there is only either unicast traffic or multicast traffic.

In a particular embodiment, the union comprises overlap between the multicast configuration and the unicast configuration, and in the codebook, a number of feedback bits per downlink slot is determined by an intersection of the first downlink data to uplink feedback timing set and the second downlink data to uplink feedback timing set.

In a particular embodiment, there is overlap between the multicast configuration and the unicast configuration when, at each downlink slot, there is both unicast traffic and multicast traffic.

In a particular embodiment, a number of bits per downlink slot for the feedback is determined based on at least one value in the intersection of the first downlink data to uplink feedback timing set and the second downlink data to uplink feedback timing set.

In a particular embodiment, the multicast configuration comprises a Physical Uplink Control Channel (PUCCH) configuration.

In a particular embodiment, the unicast configuration comprises a Physical Uplink Control Channel (PUCCH) configuration.

In a particular embodiment, obtaining the codebook comprises constructing the codebook.

In a particular embodiment, obtaining the codebook comprises receiving the codebook from the network node.

In a particular embodiment, the wireless device receives at least one message from the network node, the at least one message comprising the multicast configuration and the unicast configuration.

In a particular embodiment, the wireless device comprises a UE.

In various particular embodiments, the method may additionally or alternatively include one or more of the steps or features of the Group C Example Embodiments described below.

<FIG> illustrates a schematic block diagram of a virtual apparatus <NUM> in a wireless network (for example, the wireless network shown in <FIG>). The apparatus may be implemented in a wireless device or network node (e.g., wireless device <NUM> or network node <NUM> shown in <FIG>). Apparatus <NUM> is operable to carry out the example method described with reference to <FIG> and possibly any other processes or methods disclosed herein. It is also to be understood that the method of <FIG> is not necessarily carried out solely by apparatus <NUM>. At least some operations of the method can be performed by one or more other entities.

Virtual Apparatus <NUM> may comprise processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein, in several embodiments. In some implementations, the processing circuitry may be used to cause obtaining module <NUM>, transmitting module <NUM>, and any other suitable units of apparatus <NUM> to perform corresponding functions according one or more embodiments of the present disclosure.

According to certain embodiments, obtaining module <NUM> may perform certain of the obtaining functions of the apparatus <NUM>. For example, obtaining module <NUM> may obtain a codebook that is constructed based on a multicast configuration and a unicast configuration.

According to certain embodiments, transmitting module <NUM> may perform certain of the transmitting functions of the apparatus <NUM>. For example, transmitting module <NUM> may transmit, to a network node, based on the codebook, feedback for a multicast transmission and unicast data.

Optionally, in particular embodiments, virtual apparatus may additionally include one or more modules for performing any of the steps or providing any of the features in the Group C Example Embodiments described below.

As used herein, the term module or unit may have conventional meaning in the field of electronics, electrical devices and/or electronic devices and may include, for example, electrical and/or electronic circuitry, devices, modules, processors, memories, logic solid state and/or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and/or displaying functions, and so on, as such as those that are described herein.

<FIG> depicts a method by a network node, according to certain embodiments. At step <NUM>, the network node obtains a codebook constructed based on a multicast configuration and a unicast configuration. At step <NUM>, based on the codebook, the network node receives, from a wireless device, feedback for a multicast transmission and unicast data.

In a particular embodiment, the multicast configuration comprises a first downlink data to uplink feedback timing set, and the unicast configuration comprises a second downlink data to uplink feedback timing set.

In a particular embodiment, the first downlink to uplink feedback timing set comprises a first TDRA list indicating an allocation of symbols for a downlink shared channel for the multicast transmission, and the second downlink to uplink feedback timing set comprises a second TDRA list indicating an allocation of symbols for the downlink shared channel for the unicast data.

In a particular embodiment, he multicast configuration comprises a PUCCH configuration.

In a particular embodiment, the unicast configuration comprises a PUCCH configuration.

In a particular embodiment, the network node transmits the codebook to the wireless device.

In a particular embodiment, the network node transmits at least one message to the wireless device. The at least one message comprises the multicast configuration and the unicast configuration.

In a particular embodiment, the network node comprises a gNB.

In various particular embodiments, the method may include one or more of any of the steps or features of the Group C Example Embodiments described below.

Virtual Apparatus <NUM> may comprise processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein, in several embodiments. In some implementations, the processing circuitry may be used to cause obtaining module <NUM>, receiving module <NUM>, and any other suitable units of apparatus <NUM> to perform corresponding functions according one or more embodiments of the present disclosure.

According to certain embodiments, obtaining module <NUM> may perform certain of the obtaining functions of the apparatus <NUM>. For example, obtaining module <NUM> may obtain a codebook constructed based on a multicast configuration and a unicast configuration.

According to certain embodiments, receiving module <NUM> may perform certain of the receiving functions of the apparatus <NUM>. For example, receiving module <NUM> may receive, based on the codebook, from a wireless device, feedback for a multicast transmission and unicast data.

Claim 1:
A method (<NUM>) by a wireless device (<NUM>), the method comprising:
obtaining (<NUM>) a codebook that is based on a first downlink data to uplink feedback timing set (<NUM>) for feedback associated with multicast downlink data and a second downlink data to uplink feedback timing set (<NUM>) for feedback associated with unicast downlink data, wherein a number of downlink slots associated with the codebook is determined based on a union of the first downlink data to uplink feedback timing set and the second downlink data to uplink feedback timing set; and
transmitting (<NUM>) feedback to a network node (<NUM>) based on the codebook,
wherein a number of feedback bits (<NUM>) in the codebook for a downlink slot associated with the codebook is determined based on a union of a first Time Domain Resource Allocation, TDRA, list and a second TDRA list, wherein the first TDRA list indicates possible allocations of symbols for a downlink shared channel for multicast downlink data, and wherein the second TDRA list indicates possible allocations of symbols for a downlink shared channel for unicast downlink data,
wherein there is an overlap (<NUM>) between the first downlink data to uplink feedback timing set and the second downlink data to uplink feedback timing set, wherein the overlap corresponds to one or more of the downlink slots associated with the codebook, and wherein a number of feedback bits in the codebook per downlink slot from the overlap is determined based on a union of the first TDRA list and the second TDRA list,
characterized in that:
the first downlink data to uplink feedback timing set includes one or more first values (<NUM>) not included in the second downlink data to uplink feedback timing set, and, in the codebook, a number of feedback bits per downlink slot corresponding to the one or more first values is determined by the first TDRA list; and/or
the second downlink data to uplink feedback timing set includes one or more second values (<NUM>) not included in the first downlink data to uplink feedback timing set, and, in the codebook, a number of feedback bits per downlink slot corresponding to the one or more second values is determined by the second TDRA list.