Patent Description:
When a user equipment (UE) receives services, such as multicast and broadcast services (MBS) and unicast services, the UE, at a scheduled time instance, will analyze the received signals and generate hybrid automatic repeat request-acknowledgment (HARQ-ACK) feedback. This feedback is stored in a codebook and communicated to the communication node to which the UE is communicating. When more than one service is being analyzed for a scheduled time instance, the highest priority service is used for the codebook and the feedback for the other services is dropped. It would be beneficial to be able to provide the HARQ-ACK feedback for all received services that are scheduled for the same time instance.

R1-<NUM> (Mechanisms to Improve Reliability for RRC_CONNECTED UEs) and R1-<NUM> (FL summary#<NUM> on improving reliability for MBS for RRC_CONNECTED UEs) teach that regarding ACK/NACK feedback for NR MBS for UEs receiving both unicast and MBS service, the UES may generate sub-codebook for unicast and MBS service separately and concatenates the sub-codebooks together.

The invention relates to apparatuses and methods as set forth in the claims. It will be understood that aspects of the disclosures falling outside the scope of the claims may not be part of the invention but may be useful to understand the invention.

Reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:.

In the <NUM> 3GPP Release <NUM> proposed standard (3GPP), there is a work item (RP-<NUM>) for the support of multicast and broadcast services (MBS) for new Radio (NR). Point to multi-point (PTM) transmission is expected to efficiently provision MBS services to multiple users, e.g., user equipment (UE), by utilizing the same radio framework as unicast services. A primary focus is to achieve higher efficiency and reliability than is typical using previous 3GPP releases to enable new use cases for PTM. The application of hybrid automatic repeat request (HARQ) techniques can be used to achieve the higher efficiency. For the UEs in an RRC_CONNECTED state, HARQ-acknowledgement (ACK) feedback is supported for PTM transmissions and the detailed HARQ-ACK feedback solutions can utilize ACK/negative ACK (NACK) or NACK acknowledgments. For UEs in an RRC_CONNECTED state, at least frequency-division multiplexing (FDM) between a unicast physical downlink data channel (PDSCH) and a group-common multicast PDSCH can be supported. Various types of HARQ-ACK codebooks can be utilized, for example, type-<NUM>, e.g., semi-static, type-<NUM>, e.g., dynamic, enhanced type-<NUM>, or type-<NUM>, at least when ACK/NACK based HARQ-ACK feedback is supported.

The specific standard referenced for this disclosure is 3GPP TS <NUM> and TS <NUM>. UE, such as mobile phones, tablets, laptops, and other <NUM> devices whether movable, mobile, or stationary, can establish a communication link with one or more network devices, i.e., communication nodes. For example, various communication nodes can be a <NUM> base station (gNB), an evolved universal mobile telecommunications system (UMTS), terrestrial radio access (E-UTRA), an enhanced <NUM> eNodeB E-UTRA base station (eNB), e.g., an enhanced Node B, an enhanced gNB (en-gNB), or a next generation eNB (ng-eNB). For purposes of this disclosure, communication nodes can be referred herein as gNB and shall include eNB. The communications between the UE and the communication node can be transferred, e.g., following the cell change, to another communication node for various reasons, for example, as the UE is moving the second communication node may be able to provide a higher quality communication link or when communication load balancing is being performed between the communication nodes.

In wireless technologies, retransmission-based error recovery techniques can be widely exploited to ensure the reliable transmission of data over a lossy channel. Typically, automatic repeat requests (ARQ), which are implemented for radio link control (RLC) acknowledged mode, and HARQ, which can be implemented in the medium access control (MAC) or physical (PHY) radio sublayer, are used to tailor the retransmission of data for improving the reliability of radio links. These methods greatly improve the spectral efficiency of communication over radio fading channels.

3GPP studies have shown that HARQ can improve transmissions in the presence of errors, such as for point to point (PTP) service delivery. When there are a large number of UEs consuming the MBS service, there are many HARQ ACK/NACK feedback messages, leading to high signaling overhead and resource inefficiency. The enhanced outer loop link adaptation (eOLLA) technique, which can adjust the modulation and coding scheme (MCS) to an increasingly conservative setting based on the worst positioned UE, is typically used as an alternative technique to attain the desired reliability level. For the same number of UEs, where the eOLLA does not react, there might be bursty errors that randomly occur over time, due to fading and power degradations, leading to loss of protocol data units. As such, maintaining a reasonably efficient MCS along with data retransmission via HARQ, for lost/decode-fail data units, can be important to improve the reliability of the link. In the presence of relatively large number of UEs, the use of a slowly changing MCS while relying on adaptive retransmissions via HARQ to take care of fast fading variations can allow for much higher spectral efficiency than schemes like eOLLA that control reliability when HARQ is not used.

To achieve that benefit, the implementation with HARQ uses a HARQ-ACK codebook which is defined for the PTM transmissions. The relevant 3GPP committees on this topic have agreed that for ACK/NACK type of HARQ-ACK feedback, type-<NUM> and type-<NUM> HARQ-ACK codebooks should be supported for RRC_CONNECTED UEs receiving a multicast. The 3GPP committees have not agreed on the HARQ-ACK codebook design, such as the design when more than one MBS PDSCHs are FDM-ed within one slot, nor whether enhanced type-<NUM> or type-<NUM> HARQ-ACK codebooks are supported. The 3GPP committees have discussed that HARQ-ACK codebook determination should be from the UE perspective when HARQ-ACK feedback is available for unicast and MBS. The options can be to generate a joint codebook for both MBS and unicast services, to generate a codebook for MBS services separately from the codebook for unicast services, or a combination thereof.

As currently specified in 3GPP REL-<NUM>, one HARQ-ACK codebook, either type-<NUM> or type-<NUM> depending on the radio resource control (RRC) configuration, is constructed and sent by the UE in a slot on a physical uplink control channel (PUCCH) signal or a physical uplink shared channel (PUSCH) signal, even when there are multiple PTP services that the UE is interested in and the HARQ-ACK feedback for those services are scheduled to be transmitted in the same uplink (UL) slot. In 3GPP REL-<NUM>, a sub-slot concept is introduced to overcome the REL-<NUM> limitation that the UEs are not able to transmit more than one PUCCH or PUSCH with HARQ-ACK information in a slot, such as for the ultra-reliable and low latency case (URLLC) services with stringent requirements. Therefore, the slot-based concepts, such as a k1-indication in the downlink control information (DCI), are transformed into sub-slot configurations. In REL-<NUM>, one codebook per priority level, for example, high priority URLLC or low priority enhanced mobile broadband (eMBB), can be simultaneously constructed, where one of the constructed codebooks is sent in a (sub-)slot, i.e., if the low priority HARQ-ACK is scheduled to be transmitted in the same (sub-)slot with the high priority HARQ-ACK, the high priority HARQ-ACK codebook is transmitted and the low priority HARQ-ACK is dropped. Therefore, one codebook is sent by the UE at a scheduled time instance, even when there could be multiple services that are scheduled to provide HARQ-ACK feedback at that same scheduled time instance.

Since different MBS PDSCHs and unicast PDSCH may be FDM-ed using UE capability in 3GPP Rel-<NUM>, construction of one semi-static codebook for different services is not possible for the PDSCH occasions of the FDM-ed transmissions using the current specifications.

In cases where a type-<NUM> codebook is utilized, the gNB includes a downlink assignment index (DAI) field in the DCI that serves as a counter of the number of transmissions to be received by the UE in a specific slot, and for a specific time period. The UE and the gNB can have a common understanding on the size of the HARQ-ACK codebook to be produced in case there are no errors while the UE decodes the DCIs. In case of MBS transmissions, different UEs may be interested in different MBS and unicast services, therefore using the same DAI counter for different services may lead the UE and communication node to have a different understanding in the size and content of the dynamic HARQ-ACK codebook constructed by the UE. Thus, the current procedures on dynamic HARQ-ACK codebook construction may not be sufficient in cases where PTM transmissions occur.

Proposed solutions include simultaneously constructing two HARQ-ACK sub-codebooks for MBS and unicast services when their HARQ-ACK feedback is scheduled at the same later time instance and concatenate the constructed sub-codebooks to create one codebook. Other solutions include that the DAI field in PDCCH should be configured independently between unicast and MBS services, and between different MBS services, where the UE may construct one sub-codebook per MBS service when dynamic codebook is being used and concatenate the sub-codebooks.

Simultaneous construction of HARQ-ACK sub-codebooks for each of the MBS services and one sub-codebook for unicast services when their HARQ-ACK feedback is scheduled at the same time instance means that there is a concatenation of the constructed sub-codebooks in cases where services have the same priority. The concatenated codebook can be sent in one PUCCH or PUSCH resource.

In order to successfully perform the proposed solutions mentioned above for a proper HARQ-ACK feedback operation, the UE should be able to map the received PDSCH transmission to a specific sub-codebook and should follow a specific concatenation order of the sub-codebooks to have the same understanding with the communication node on the size and content of the HARQ-ACK codebook.

HARQ-ACK codebooks of type-<NUM> and type-<NUM> are specified in 3GPP Rel-<NUM>. HARQ-ACK codebooks of enhanced type-<NUM> and type-<NUM> are specified in 3GPP Rel-<NUM>. There are proposals made at the relevant 3GPP committees to construct separate HARQ-ACK codebooks for different MBS and unicast services, concatenating those codebooks, and sending them in the same PUCCH or PUSCH resource by the UE in case HARQ-ACK feedback is scheduled for the same time instance. Options for a PHY layer identification of simultaneously constructed two HARQ-ACK codebooks have been discussed at the relevant 3GPP committees, e.g., how to map a received PDSCH TB(s)'s HARQ-ACK to one of the high-priority (URLLC) or low-priority (eMBB) HARQ-ACK codebooks. The DCI field would contain a priority indicator that maps the HARQ-ACK to one of the simultaneously constructed codebooks. For semi-persistent scheduling (SPS) transmission, SPS PDSCH configuration is providing the priority indication for the mapping.

This disclosure presents methods and processes for the UEs in RRC_CONNECTED state to construct a HARQ-ACK codebook while receiving MBS transmission(s), especially in cases where there are multiple unicast or MBS services with the same priority level that are scheduled for the UE to provide HARQ-ACK feedback at the same time instance. The UE can construct separate HARQ-ACK sub-codebooks for each MBS service and one sub-codebook for unicast services, if present. The sub-codebooks can be concatenated and the UE can send the concatenated codebooks in the same PUCCH or PUSCH resource in case the respective HARQ-ACK feedback for the MBS services and unicast services are scheduled for the same time instance, e.g., slot or sub-slot. By applying the methods and processes described herein, the UEs can send one HARQ-ACK codebook while receiving different unicast and MBS services. The cost of implementation is a slightly higher amount of signaling related to the configuration of the various options.

The disclosure can utilize a process such as analyzing the feedback that should be sent from the UE to the communication node at a time when the HARQ-ACK feedback is being constructed for a scheduled time instance by the UE. If the HARQ-ACK feedback is for unicast services or for one MBS service, then the current HARQ-ACK feedback construction process can be utilized, e.g., the sub-codebook can be assigned as the codebook. If the UE is scheduled to provide HARQ-ACK feedback for two or more MBS services, or one or more MBS services along with at least one unicast service then the UE can construct one sub-codebook for each MBS service and one sub-codebook for the set of unicast services, where there is at least one unicast service.

The UE can map the received physical downlink channel signals, such as a PDSCH transport block (TB), to the corresponding sub-codebook based on the group-common radio network temporary identifier (G-RNTI) used to scramble the PDCCH and PDSCH transmissions. The G-RNTI is a unique identifier of each MBS service, i.e., the PHY identification of PDSCH HARQ-ACK to sub-codebook mapping can be the G-RNTI value. If the UE receives a physical downlink channel, such as PDSCH, including unicast services, whose PDCCH and PDSCH are expected to be scrambled by a radio network temporary identifier (RNTI) other than G-RNTI, PDSCH HARQ-ACK for the unicast service can be mapped to the separate sub-codebook that is constructed for unicast services.

After the construction of the separate HARQ-ACK sub-codebooks, the UE can proceed to concatenating the sub-codebooks. In some aspects, the concatenation order can be specified by the communication node. In some aspects, the concatenation order can be specified by the industry standard used by the communication node and UE. The UE should use the specified concatenation order, e.g., the indicated concatenation order, so that the communication node and the UE have the same understanding of the HARQ-ACK codebook.

The concatenation order used by the UE for the sub-codebooks can utilize one of the following options. Option <NUM>: The value of the RNTI can be utilized. The UE can concatenate the constructed HARQ-ACK sub-codebooks based on the PHY identification of the sub-codebook, i.e., the G-RNTI parameter that is a <NUM>-bit identification (ID). The concatenation can be made in one of an increasing order or a decreasing order of the corresponding G-RNTI parameters, e.g., the concatenation order parameters. In some aspects, for the unicast sub-codebook, the UE can use the corresponding RNTI parameter used for scrambling the PDCCH/PDSCH transmission to determine the correct place of the unicast HARQ-ACK sub-codebook inside the concatenated codebook. In some aspects, the unicast sub-codebook can be placed at the front position or the following position of the concatenated structure of the MBS sub-codebooks.

Option <NUM>: When the list of available MBS services is configured via a multicast control channel (MCCH), i.e., the multicast traffic channels (MTCHs) are configured in a list, for example, a list similar to sc-mtch-InfoList-r13 in LTE SC-PTM, the order of the HARQ-ACK sub-codebook concatenation can follow the order in which the MBS bearers and associated MTCHs are configured in the list. The sub-codebook constructed for unicast services can be concatenated to the front or the following position of the concatenated structure of the MBS sub-codebooks.

Option <NUM>: When the list of available MBS services is configured using UE specific signaling, such as dedicated RRC signaling, the <NUM>-bit DRB ID for a particular service can be utilized for the concatenation order. The concatenation can be in an increasing order or a decreasing order of concatenation parameters corresponding to the <NUM>-bit DRB ID, e.g., the concatenation order parameters.

Option <NUM>: The concatenation order of unicast and MBS HARQ-ACK sub-codebooks can be explicitly signaled by the communication node using UE specific signaling, such as a dedicated RRC signaling, to the UE with a list of RNTIs, for example using a MBS-concat-list-r17 field, whose order can be used to concatenate the corresponding sub-codebooks, e.g., a specified RNTI list.

An example, for demonstration purposes, of the messaging changes to the 3GPP standard are shown in Table <NUM>. Other messaging changes and different messaging changes can be utilized to implement this disclosure; Table <NUM> is for example.

Turning now to the figures, <FIG> is an illustration of a diagram of an example communication scenario <NUM> with a gNB and multiple UEs. Communication scenario <NUM> is a demonstration of one type of environment for this disclosure. The environment for communication scenario <NUM> includes a UE 110a, a UE 110b, a UE 110c (collectively, UEs <NUM>), and a gNB <NUM>. UEs <NUM> are in an RRC_CONNECTED state with gNB <NUM>. gNB <NUM> is communicating MBS and unicast services. There can be fewer or additional user equipment in UEs <NUM>.

An example set of messages are shown in communication scenario <NUM>. UE 110a is receiving a combination of one or more of MBS or unicast services through message 130a. Likewise, UE 110b is receiving a combination of one or more MBS or unicast services through message 130b and UE 110c is receiving a combination of one or more MBS or unicast services through message 130c, (collectively, services <NUM>). If there is more than one MBS service or if there is at least one MBS service and at least one unicast service, the UEs <NUM> would utilize the methods and processes disclosed herein to generate and concatenate a respective HARQ-ACK codebook.

UE 110a can communicate its HARQ-ACK codebook to gNB <NUM> using messaging 140a. Likewise, UE 110b can communicate its HARQ-ACK codebook to gNB <NUM> using messaging 140b, and UE 110c can communicate its HARQ-ACK codebook to gNB <NUM> using messaging 140c, (collectively, messages <NUM>).

<FIG> is an illustration of a diagram of an example signal flow <NUM> for the configuration of a HARQ-ACK codebook. Signal flow <NUM> demonstrates one aspect of the disclosure to generate the HARQ-ACK codebook. Signal flow <NUM> has an UE <NUM> and a gNB <NUM>.

A signal <NUM> is shown being communicated from gNB <NUM> to UE <NUM>. Signal <NUM> can be a connection reconfiguration message, such as a RRCReconfiguration or a RRCConnectionReconfiguration message, specifying the type of HARQ-ACK that the UE should utilize as well as the concatenation method to utilize. Dashed line <NUM> indicates that signal <NUM> can be sent at an earlier time than that for an MBS or unicast service, for example, at a time at which an RRC_CONNECTED state is established, at a time when signal <NUM> is transmitted, or at another time when the UE is in an RRC_CONNECTED state with the communication node. Signal <NUM> can be an MBS service, a unicast service, or a combination thereof. Signal <NUM> is shown with multiple communication arrows to indicate that signal <NUM> can be one or more MBS or unicast services.

A signal <NUM> is communicated from UE <NUM> and specifies the HARQ-ACK codebook for UE <NUM>, such as using a PUSCH or PUCCH signal. Signal <NUM> is generated by UE <NUM> according to the HARQ-ACK configuration as specified in signal <NUM>. In some aspects, an additional signaling <NUM> indicates that action can be taken by gNB <NUM>, such as a recommunication, e.g., retransmission, of signal <NUM> if the HARQ-ACK codebook indicates an error. In some aspects, additional signaling <NUM> can be other communications.

<FIG> is an illustration of a flow diagram of an example method <NUM> to generate a HARQ-ACK codebook. Method <NUM> can be implemented on a set of network devices and communication nodes, such as a gNB, an eNB, an en-gNB, a ng-eNB, and a UE. Method <NUM> can be encapsulated in software code or in hardware, for example, an application, a code library, a dynamic link library, a module, a function, a RAM, a ROM, and other software and hardware implementations. The software can be stored in a file, database, or other computing system storage mechanism. Method <NUM> can be partially implemented in software and partially in hardware.

Method <NUM> starts at a step <NUM> and proceeds to a step <NUM>. In step <NUM>, the UE can receive one or more services, such as one or more MBS services or zero or more unicast services. For each received service, there can be an analysis on the service to determine the HARQ-ACK feedback for each received service. Proceeding to a decision step <NUM>, a determination is made on whether a HARQ-ACK feedback is scheduled. The time instance used for determining the schedule can be provided by the communication node in a DCI message received at a prior time. In addition, the type of HARQ-ACK codebook to use as well as the concatenation order to use can be specified by the communication node in a connection reconfiguration message, such as a RRCReconfiguration or a RRCConnectionReconfiguration message. Method <NUM> is independent of the HARQ-ACK codebook type that the UE is configured by the communication node to construct, e.g., type-<NUM>, type-<NUM>, enhanced type-<NUM>, or type-<NUM> codebook can be configured individually for any service. If decision step <NUM> is 'Yes', method <NUM> proceeds to a decision step <NUM>. If decision step <NUM> is 'No', method <NUM> proceeds to a step <NUM>.

In decision step <NUM>, the UE can determine whether there is more than one MBS service that requires HARQ-ACK feedback at the scheduled time instance. The UE can also determine if there is at least one MBS and at least one unicast service that requires HARQ-ACK feedback at the scheduled time instance. If decision step <NUM> is 'Yes', method <NUM> proceeds to a step <NUM>. If decision step <NUM> is 'No', method <NUM> proceeds to a step <NUM>.

Proceeding to step <NUM>, in cases where there is not a need for a complex HARQ-ACK codebook containing feedback for more than one service, the UE can utilize existing industry standards to generate the HARQ-ACK codebook. Method <NUM> proceeds to step <NUM>.

Proceeding to step <NUM>, the UE can generate two or more HARQ-ACK sub-codebooks for the various MBS or unicast services that have a HARQ-ACK feedback scheduled at the time instance, e.g., map the HARQ-ACK feedback to the sub-codebook. The UE can construct the sub-codebooks based on the current codebook construction mechanisms, for example, as specified in 3GPP Rel-<NUM> or 3GPP Rel-<NUM>. The UE can map the HARQ-ACK feedback bit corresponding to the received physical downlink channel, such as PDSCH, transmissions to different HARQ-ACK sub-codebooks that the UE constructs. Method <NUM> proceeds to a step <NUM>.

In step <NUM>, the UE can concatenate the two or more sub-codebooks using the scheme as specified by the communication node to generate one concatenated HARQ-ACK codebook. In some aspects, in cases where the UE receives services that have different priorities, the lower priority sub-codebooks can be dropped. In some aspects, the RNTI value can be used to determine the concatenation order. In some aspects, the MTCH list order can be used to determine the concatenation order. In some aspects, the DRB-identity for a particular service can be used to determine the concatenation order. In some aspects, the communication node can specify the concatenation order, which can provide greater flexibility to the communication node for optimizations. In some aspects, a sub-codebook for unicast services can be concatenated at a front position or a following position of a concatenated structure of sub-codebooks for the MBS services. Method <NUM> proceeds to step <NUM>.

In step <NUM>, the concatenated codebook, which can be one codebook if one sub-codebook is generated, can be communicated to the communication node to which the UE is communicating, such as using a physical uplink channel, for example, PUCCH or PUSCH. In step <NUM>, method <NUM> ends.

<FIG> is an illustration of a flow diagram of an example method <NUM> to build a concatenated HARQ-ACK codebook. Method <NUM> can be implemented on a set of network devices and communication nodes, such as a gNB, an eNB, an en-gNB, a ng-eNB, and a UE. Method <NUM> can be encapsulated in software code or in hardware, for example, an application, a code library, a dynamic link library, a module, a function, a RAM, a ROM, and other software and hardware implementations. The software can be stored in a file, database, or other computing system storage mechanism. Method <NUM> can be partially implemented in software and partially in hardware.

Method <NUM> starts at step <NUM> and proceeds to a step <NUM> where the UE can receive configuration information from a communication node, such as an indicated concatenation order. The configuration information can include information on concatenation ordering, such as the method to use, whether to use increasing or decreasing order of an identifier such as RNTIs, or to provide an ordered list of RNTIs. This information can be received in a connection reconfiguration message, such as a RRCReconfiguration or a RRCConnectionReconfiguration message.

In a step <NUM>, the UE can receive one or more services during the course of operations, such as MBS services and unicast services. In a step <NUM>, each received service can be analyzed by the UE to generate HARQ-ACK feedback for each service. The services can be grouped by the scheduled time instance which is a time when the HARQ-ACK should be communicated to the communication node.

In a step <NUM>, the UE can construct one or more sub-codebooks using the results of the analyzing from step <NUM>. The mapping from the analyzing to the sub-codebooks can utilize the G-RNTI or RNTI parameters.

In a step <NUM>, the UE can concatenate the sub-codebooks into one concatenated HARQ-ACK codebook. If there is one sub-codebook, such as if there is one MBS service, or unicast services and no MBS services, then that sub-codebook becomes the concatenated HARQ-ACK codebook. When there is more than one sub-codebook, one type of concatenation order can be utilized, such as specified in the received configuration.

In some aspects, the identified concatenation order can utilize a G-RNTI for the MBS services, and an RNTI for the unicast services. In some aspects, the identified concatenation order can utilize a received list of available MBS services, such as configured by a MCCH. In some aspects, a sub-codebook for the unicast services can be concatenated at a front position or a following position of the concatenated structure of the sub-codebooks for the MBS services. In some aspects, the identified concatenation order can utilize a <NUM>-bit DRB identity when a list of available MBS services is configured, for example, by UE specific signaling. In some aspects, the concatenation order can utilize an order specified by the communication node using a UE specific signaling, such as RRC signaling, with a list of RNTIs. In some aspects, the concatenation order can utilize an increasing order of the concatenation parameters. In some aspects, the concatenation order can utilize a decreasing order of the concatenation parameters.

Proceeding to a step <NUM>, the concatenated codebook can be communicated to the communication node with which the UE is communicating, such as using a physical uplink channel, for example, PUCCH or PUSCH. Method <NUM> ends at a step <NUM>.

<FIG> is an illustration of a block diagram of a communication system <NUM> using HARQ-ACK codebooks. Communication system <NUM> is an example system and could have additional communication nodes and additional UEs. Communication system <NUM> has a UE <NUM> and a communication node <NUM>, shown as a gNB in this example.

UE <NUM> has a transceiver <NUM> capable of receiving communication signals and transmitting communication signals with communication node <NUM> using signal connection <NUM>. UE <NUM> has a HARQ-ACK codebook generator <NUM>, which can be a processor. HARQ-ACK codebook generator <NUM> is capable of communicating with transceiver <NUM>. HARQ-ACK codebook generator <NUM> is capable to mapping HARQ-ACK feedback for one or more MBS services or unicast services to their own respective sub-codebooks. HARQ-ACK codebook generator <NUM> is further capable of concatenating the respective sub-codebooks to generate a concatenated HARQ-ACK codebook that can be communicated to communication node <NUM>. HARQ-ACK codebook generator <NUM> can utilize a received concatenation order, such as a concatenation order received from communication node <NUM>. In some aspects, HARQ-ACK codebook generator <NUM> can utilize a different concatenation order when connected to a different communication node, such as a communication nodes from varying carriers.

Communication node <NUM> has a transceiver <NUM> capable of receiving communication signals and transmitting communication signals with UE <NUM> using signal connection <NUM>. Communication node <NUM> has a HARQ-ACK codebook analyzer <NUM> that is capable of analyzing the received concatenated HARQ-ACK codebook and providing information to other systems of communication node <NUM>. HARQ-ACK codebook analyzer <NUM> is operable to communicate with transceiver <NUM>. HARQ-ACK codebook analyzer <NUM> is operable to communicate a concatenation order. In some aspects, HARQ-ACK codebook analyzer <NUM> is a processor. HARQ-ACK codebook analyzer <NUM> is capable of initiating further actions utilizing the results of the analyzing, for example, to recommunicate an MBS service packet or a unicast service packet where an analyzation of the concatenated HARQ-ACK codebook indicates a retransmission request. The elements of UE <NUM> and communication node <NUM> are shown as a functional view, where the implementation can be by software, hardware, or a combination thereof. In some aspects, the functions shown can be combined with other functions of the respective UE <NUM> or communication node <NUM>.

A portion of the above-described apparatus, systems or methods may be embodied in or performed by various analog or digital data processors, wherein the processors are programmed or store executable programs of sequences of software instructions to perform one or more of the steps of the methods. A processor may be, for example, a programmable logic device such as a programmable array logic (PAL), a generic array logic (GAL), a field programmable gate arrays (FPGA), or another type of computer processing device (CPD). The software instructions of such programs may represent algorithms and be encoded in machine-executable form on non-transitory digital data storage media, e.g., magnetic or optical disks, random-access memory (RAM), magnetic hard disks, flash memories, and/or read-only memory (ROM), to enable various types of digital data processors or computers to perform one, multiple, or all of the steps of one or more of the above-described methods, or functions, systems or apparatuses described herein.

Portions of disclosed examples or aspects may relate to computer storage products with a non-transitory computer-readable medium that have program code thereon for performing various computer-implemented operations that embody a part of an apparatus, device or carry out the steps of a method set forth herein. Non-transitory used herein refers to all computer-readable media except for transitory, propagating signals. Examples of non-transitory computer-readable media include, but are not limited to: magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM disks; magnetooptical media such as floppy disks; and hardware devices that are specially configured to store and execute program code, such as ROM and RAM devices. Examples of program code include machine code, such as produced by a compiler, and files containing higher level code that may be executed by the computer using an interpreter.

In interpreting the disclosure, all terms should be interpreted in the broadest possible manner consistent with the context. In particular, the terms "comprises" and "comprising" should be interpreted as referring to elements, components, or steps in a non-exclusive manner, indicating that the referenced elements, components, or steps may be present, or utilized, or combined with other elements, components, or steps that are not expressly referenced.

Claim 1:
An apparatus, comprising:
means configured for receiving (<NUM>) multicast and broadcast services, MBS, and unicast services;
means configured for mapping (<NUM>) hybrid automatic repeat request-acknowledgement, HARQ-ACK, feedback for each MBS service in MBS services to a respective multicast and broadcast HARQ-ACK sub-codebook;
means configured for mapping (<NUM>) a HARQ-ACK feedback for the unicast services to a unicast HARQ-ACK sub-codebook;
means configured for concatenating (<NUM>) the respective multicast and broadcast HARQ-ACK sub-codebooks and unicast HARQ-ACK sub-codebook to a concatenated HARQ-ACK codebook using a concatenation order, wherein the concatenation order is an increasing order or a decreasing order of group-common radio network temporary identifier, G-RNTI, parameters for the MBS services and a radio network temporary identifier, R-NTI, parameter for the unicast services, and
means configured for communicating (<NUM>) the concatenated HARQ-ACK codebook.