CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to United States Provisional Patent Application Number 62/925,198 entitled “SECURITY INPUT FOR CIPHERING AND INTEGRITY PROTECTION IN V2X” and filed on October 23, 2019 for Prateek Basu Mallick, Joachim Loehr, Ravi Kuchibhotla, Karthikeyan Ganesan, and Andreas Kunz, which application is incorporated herein by reference.

FIELD

[0002] The subject matter disclosed herein relates generally to wireless communications and more particularly relates to receiving sidelink feedback for groupcast communication to a group of UEs.

BACKGROUND

[0003] The following abbreviations are herewith defined, at least some of which are referred to within the following description: Third Generation Partnership Project (“3GPP”), Fifth Generation Core Network (“5GC”), Fifth Generation System (“5GS”), 5G QoS Indicator (“5QI”), Authentication, Authorization and Accounting (“AAA”), Positive-Acknowledgment (“ACK”), Application Function (“AF”), Access and Mobility Management Function (“AMF”), Antenna Panel (“AP”), Application Programming Interface (“API”), Access Stratum (“AS”), Base Station (“BS”), Buffer Status Report (“BSR”), Code Block Group (“CBG”), Code Division Multiple Access (“CDMA”), Control Element (“CE”), Core Network (“CN”), Channel Quality Indicator (“CQI”), Channel State Information (“CSI”), CSI Reference Signal (“CSI-RS”), Dual Connectivity (“DC”), Downlink Control Information (“DCI”), Downlink (“DL”), Demodulation Reference Signal (“DM-RS”), Data Radio Bearer (“DRB”), Discontinuous Transmission (“DTX”), Enhanced Inter-cell Interference Coordination (“elCIC”), Evolved Node-B (“eNB”), Evolved Packet Core (‘EPC”), Evolved Packet System (“EPS”), Evolved UMTS Terrestrial Radio Access (“E-UTRA”), Evolved UMTS Terrestrial Radio Access Network (“E-UTRAN”), European Telecommunications Standards Institute (“ETSI”), Guaranteed Bit Rate (“GBR”), New Generation (i.e., 5G) Node-B (“gNB”), Global Navigation Satellite System (“GNSS”), General Packet Radio Service (“GPRS”), Global Positioning System (“GPS”), Generic Public Service Identifier (“GPSI”), Global System for Mobile Communications (“GSM”), Hybrid Automatic Repeat Request (“HARQ”), Home Subscriber Server (“HSS”), Inter-cell Interference Coordination (“ICIC”), Identifier (“ID”), Information Element (“IE”), Industrial IoT (“HOT”), Internet of Things (“IoT”), Key Performance Indicator (“KPI”), Layer-1 (“LI”, also known as the Physical Layer), Layer 1 Identifier (“LI ID”), Layer-2 (“L2”, also known as the Link Layer), Layer 2 Identifier (“L2 ID”), Layer-3 (“L3”, also known as the Network Layer), Logical Channel (“LCH”), LCH Prioritization (“LCP”), Long Term Evolution (“LTE”), Machine Learning (“ML”), Mobility Management (“MM”), Mobility Management Entity (“MME”), Negative- Acknowledgment (“NACK”) or (“NAK”), Non-Access Stratum (“NAS”), New Generation Radio Access Network (“NG-RAN”, a RAN used for 5GS networks), Neural Network (“NN”), Network Slice Selection Assistance Information (“NSSAI”, e.g., a vector value including one or more S- NSSAI values), New Radio (“NR”, a 5G radio access technology; also referred to as “5G NR”), Observed Time Difference Of Arrival (“OTDoA”), PC5 5QI (““PQI,” corresponds to QoS for NR V2X communication over the PC5 interface), Packet Data Network (“PDN”), Packet Data Unit (“PDU”, used in connection with ‘PDU Session’), PC5 QoS Plow Indicator (“PLI”), Packet Data Network Gateway (“P-GW”), PC5 Link Identifier (“PLI”), Public Land Mobile Network (“PLMN”), Precoding Matrix Indicator (“PMI”), Physical Random Access Channel (“PRACH”), Physical Sidelink Control Channel (“PSCCH”), Physical Sidelink feedback Channel (“PSLCH”), Physical Sidelink Shared Channel (“PSSCH”), QoS Plow Indicator (“QPI”), Quality of Experience (“QoE”), Quality of Service (“QoS”), Random Access Channel (“RACH”), Radio Access Network (“RAN”), Rank Indicator (“RI”), RAN Intelligent Controller (“RIC”), Radio Link Monitoring (“RLM”), Radio Network Information (“RNI”), RNI Service (“RNIS”), Radio Resource Management (“RRM”), Received Signal Received Power (“RSRP”), Received Signal Strength Indicator (“RSSI”), Receive (“RX”), Sidelink Control Information (“SCI”), Sidelink CSI RS (“S- CSI-RS”), Serving Gateway (“S-GW”), Signal-to-Interference-and-Noise Ratio (“SINR”), Sidelink (“SL”), Sidelink Reference Signal (“SL-RS”), Sidelink Synchronization Signal (“SLSS”), Sidelink Synchronization Signal Block (“SL-SSB”), Session Management (“SM”), Session Management Punction (“SMP”), Single Network Slice Selection Assistance Information (“S- NSSAI”), Service Provider (“SP”), Semi-Persistent Scheduling (“SPS”), Sounding Reference Signal (“SRS”), Sidelink Received Signal Received Power (“S-RSRP”), Synchronization Signal (“SS”), Synchronization Signal Block (“SSB”), Transport Block (“TB”), Transmission Configuration Indicator (“TCI”), Time Difference of Arrival (“TDoA”), Transmit (“TX”), Uplink Control Information (“UCI”), Unified Data Management (“UDM”), User Data Repository (“UDR”), User Entity/Equipment (Mobile Terminal) (“UE”), Uplink (“UL”), User Plane (“UP”), Universal Mobile Telecommunications System (“UMTS”), UL Time Difference of Arrival (“UTDoA” or “U-TDoA”), UMTS Terrestrial Radio Access (“UTRA”), UMTS Terrestrial Radio Access Network (“UTRAN”), Vehicle-to-everything (“V2X”, V2X communication encompasses both V2V and V2I), Vehicle -to-Infrastructure (“V2I”), Vehicle-to-Vehicle (“V2V”), a UE capable of vehicular communications using 3GPP protocols (“V2X UE”), and Worldwide Interoperability for Microwave Access (“WiMAX”). As used herein, “HARQ-ACK” refers to HARQ feedback may represent collectively the Positive Acknowledge (“ACK”) and the Negative Acknowledge (“NACK”) and Discontinuous Transmission (“DTX”). ACK means that a TB is correctly received while NACK (or NAK) means a TB is erroneously received. DTX means that no TB was detected.

[0004] In certain wireless communication systems, V2X communication allows vehicles to communicate with moving parts of the traffic system around them. Two resource allocation modes are used in LTE V2X communication which are also considered as a baseline for corresponding resource allocation modes in NR V2X communication. Mode-1 corresponds to a NR network-scheduled V2X communication mode. Mode-2 corresponds to a NR UE-scheduled V2X communication mode. Mode-3 corresponds to an LTE network-scheduled V2X communication mode. Mode-4 corresponds to an LTE UE-scheduled V2X communication mode.

BRIEF SUMMARY

[0005] Disclosed are procedures for receiving sidelink feedback from a group of UEs. Said procedures may be implemented by apparatus, systems, methods, or computer program products.

[0006] One method of a UE includes transmitting a first message to a group of UEs via groupcast communication and determining an expected number of positive acknowledgements corresponding to the first message based on a first set of at least one receiver UE belonging to the group of UEs. The first method includes receiving an actual number of positive acknowledgements from the group of UEs, where receiving the actual number of positive acknowledgements comprises receiving sidelink feedback during at least one sidelink feedback channel reception occasion. The first method includes retransmitting the first message if the actual number of positive acknowledgements is not equal to the expected number of positive acknowledgements.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A more particular description of the embodiments briefly described above will be rendered by reference to specific embodiments that are illustrated in the appended drawings. Understanding that these drawings depict only some embodiments and are not therefore to be considered to be limiting of scope, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0008] Figure 1 is a schematic block diagram illustrating one embodiment of a wireless communication system for receiving sidelink feedback from a group of UEs; [0009] Figure 2 is a diagram illustrating one embodiment of a V2X protocol stack;

[0010] Figure 3 is a diagram illustrating one embodiment of a procedure for indicating one or more available LCIDs;

[0011] Figure 4 is a diagram illustrating one embodiment of groupcast communication among a group of UEs;

[0012] Figure 5 is a diagram illustrating one embodiment of a table for tracking member ID and member location with respect to MCR;

[0013] Figure 6 is a diagram illustrating one embodiment of a user equipment apparatus that may be used for receiving sidelink feedback from a group of UEs;

[0014] Figure 7 is a diagram illustrating one embodiment of a network equipment apparatus that may be used for receiving sidelink feedback from a group of UEs; and

[0015] Figure 8 is a flowchart diagram illustrating one embodiment of a first method that may be used receiving sidelink feedback from a group of UEs.

DETAILED DESCRIPTION

[0016] As will be appreciated by one skilled in the art, aspects of the embodiments may be embodied as a system, apparatus, method, or program product. Accordingly, embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects.

[0017] For example, the disclosed embodiments may be implemented as a hardware circuit comprising custom very-large-scale integration (“VLSF’) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed embodiments may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code which may, for instance, be organized as an object, procedure, or function.

[0018] Furthermore, embodiments may take the form of a program product embodied in one or more computer readable storage devices storing machine readable code, computer readable code, and/or program code, referred hereafter as code. The storage devices may be tangible, non- transitory, and/or non-transmission. The storage devices may not embody signals. In a certain embodiment, the storage devices only employ signals for accessing code.

[0019] Any combination of one or more computer readable medium may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device storing the code. The storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

[0020] More specific examples (a non-exhaustive list) of the storage device would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random-access memory (“RAM”), a read-only memory (“ROM”), an erasable programmable read-only memory (“EPROM” or Flash memory), a portable compact disc read only memory (“CD-ROM”), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0021] Code for carrying out operations for embodiments may be any number of lines and may be written in any combination of one or more programming languages including an object- oriented programming language such as Python, Ruby, Java, Smalltalk, C++, or the like, and conventional procedural programming languages, such as the “C” programming language, or the like, and/or machine languages such as assembly languages. The code may execute entirely on the user’s computer, partly on the user’s computer, as a stand-alone software package, partly on the user’s computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user’s computer through any type of network, including a local area network (“LAN”) or a wide area network (“WAN”), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0022] Furthermore, the described features, structures, or characteristics of the embodiments may be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however, that embodiments may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of an embodiment.

[0023] Reference throughout this specification to “one embodiment,” “an embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, appearances of the phrases “in one embodiment,” “in an embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment, but mean “one or more but not all embodiments” unless expressly specified otherwise. The terms “including,” “comprising,” “having,” and variations thereof mean “including but not limited to,” unless expressly specified otherwise. An enumerated listing of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise. The terms “a,” “an,” and “the” also refer to “one or more” unless expressly specified otherwise.

[0024] As used herein, a list with a conjunction of “and/or” includes any single item in the list or a combination of items in the list. For example, a list of A, B and/or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C. As used herein, a list using the terminology “one or more of’ includes any single item in the list or a combination of items in the list. For example, one or more of A, B and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C. As used herein, a list using the terminology “one of’ includes one and only one of any single item in the list. For example, “one of A, B and C” includes only A, only B or only C and excludes combinations of A, B and C. As used herein, “a member selected from the group consisting of A, B, and C,” includes one and only one of A, B, or C, and excludes combinations of A, B, and C.” As used herein, “a member selected from the group consisting of A, B, and C and combinations thereof’ includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C.

[0025] Aspects of the embodiments are described below with reference to schematic flowchart diagrams and/or schematic block diagrams of methods, apparatuses, systems, and program products according to embodiments. It will be understood that each block of the schematic flowchart diagrams and/or schematic block diagrams, and combinations of blocks in the schematic flowchart diagrams and/or schematic block diagrams, can be implemented by code. This code may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart diagrams and/or block diagrams.

[0026] The code may also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the storage device produce an article of manufacture including instructions which implement the function/act specified in the flowchart diagrams and/or block diagrams.

[0027] The code may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the code which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart diagrams and/or block diagrams.

[0028] The flowchart diagrams and/or block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatuses, systems, methods, and program products according to various embodiments. In this regard, each block in the flowchart diagrams and/or block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions of the code for implementing the specified logical function(s).

[0029] It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more blocks, or portions thereof, of the illustrated Figures.

[0030] Although various arrow types and line types may be employed in the flowchart and/or block diagrams, they are understood not to limit the scope of the corresponding embodiments. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the depicted embodiment. For instance, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of the depicted embodiment. It will also be noted that each block of the block diagrams and/or flowchart diagrams, and combinations of blocks in the block diagrams and/or flowchart diagrams, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and code.

[0031] The description of elements in each figure may refer to elements of proceeding figures. Like numbers refer to like elements in all figures, including alternate embodiments of like elements.

[0032] Generally, the present disclosure describes systems, methods, and apparatus for security input for ciphering and integrity protection in V2X, e.g., of UEs engaged in V2X communication. While it has been proposed to avoid RLC mode mismatch in V2X communication by fixing the mapping between the LCID and the corresponding RCL mode, current industry standards do not address how to handle the situation of the LCID already being in user for the receiver UE (“Rx UE”).

[0033] In 5GNR, sidelink (“SL”) communication may support groupcast transmission and feedback for the groupcast message. In certain schemes, HARQ feedback for groupcast transmission comprises the receiver UE transmitting only HARQ NACK. It transmits no signal on PSFCH otherwise. Other schemes for HARQ feedback for groupcast transmission include the receiver UE transmitting both HARQ ACK and HARQ NACK feedback.

[0034] MCR or Minimum Communication Range is the distance (Range) in meters from the transmitter V2X UE (or a device) where the QoS fulfilment actually applies. MCR is assigned by the V2X layers/ application and will be signaled alongside the QoS (indicated using PQI) to the Access Stratum (AS). The QoS (indicated using PQI) applicable to a V2X message must be fulfilled in this Range. MCR is therefore important in seeking HARQ feedback from the Rx UEs. A NACK feedback from a UE within MCR limits may very likely trigger re-transmissions from a transmitter UE (“Tx UE”); or trigger re-transmissions from a Rx UE that successfully received and decoded the said transmission.

[0035] In some embodiments, the Tx UE solicits - and the Rx UEs provide - PC5 HARQ feedback for the PSSCH transmissions made by the Tx UE (i.e., source UE) to one or more Rx UE(s). For SL unicast and groupcast, HARQ feedback and HARQ combining in the physical layer may be supported. In various embodiments, HARQ-ACK feedback for a PSSCH is carried in SFCI format(s) via PSFCH, e.g., in resource allocation Mode-1 and Mode-2.

[0036] When SL HARQ feedback is enabled for unicast, the Rx UE generates HARQ- ACK if it successfully decodes the corresponding TB. It generates HARQ-NACK if it does not successfully decode the corresponding TB after decoding the associated PSCCH targeted to the Rx UE.

[0037] When SL HARQ feedback is enabled for groupcast, it is supported to use TX-RX distance and/or RSRP in deciding whether to send HARQ feedback. Two options are supported:

[0038] According to SL HARQ feedback Option 1, the Rx UE (i.e., target UE) transmits HARQ-NACK on PSFCH if it fails to decode the corresponding TB after decoding the associated PSCCH and transmits no signal on PSFCH otherwise (i.e., the Rx UE does not transmit HARQ- ACK on PSFCH if it successfully decodes the corresponding TB). Note that for Option 1, the Rx UEs may share common PSFCH resources.

[0039] According to SL HARQ feedback Option 2, the Rx UE transmits HARQ-ACK on PSFCH if it successfully decodes the corresponding TB. Additionally, the Rx UE transmits HARQ-NACK on PSFCH if it does not successfully decode the corresponding TB after decoding the associated PSCCH which targets the Rx UE. Note that for Option 2, the Rx UE(s) may use dedicated (i.e., individually assigned) PSFCH resources.

[0040] In order to support Option 2, it is proposed that the V2X application layer for each UE operating in the groupcast to provide a “member ID” parameter and a “group size” parameter to lower layers. Regarding delivery of group information from V2X layer to AS layer for groupcast control, in one embodiment the V2X layer provides these two parameters to the AS layer of the V2X UE. In this case, the AS layer can use HARQ-ACK operation by using these parameters provided by the V2X layer. Therefore, Option 2 can be supported. Note that which feedback option is used is up to the AS layer. In another embodiment, the V2X layer does not provide the group size and member ID parameters to the AS layer, therefore the Rx UE cannot support Option 2 (e.g., the Rx UE can only support transmitting HARQ NACK as feedback for groupcast.

[0041] The solutions described herein address at least the following problems with current V2X communication:

[0042] Problem 1: The security input parameters for ciphering as well as for integrity protection should be Synchronized between the receiver and the transmitter. This means that for certain inputs like COUNT and BEARER both the receiver and the transmitter must be using the same value. Further, a corresponding CR is to use the LCID as the 5 bit Bearer ID.

[0043] In some embodiments, the ciphering of data may be as described in 3 GPP TS 33.501 vl6.0.0 (see Section D.2 “Ciphering algorithms”). In certain embodiments, the input parameters to the ciphering algorithm are a 128-bit cipher key named KEY, a 32-bit COUNT, a 5- bit bearer identity BEARER, the 1-bit direction of the transmission i.e. DIRECTION, and the length of the keystream required i.e. LENGTH. The DIRECTION bit shall be 0 for uplink and 1 for downlink.

[0044] The ciphering algorithm NEA is used to encrypt plaintext by applying a keystream using a bit per bit binary addition of the plaintext and the keystream. The plaintext may be recovered by generating the same keystream using the same input parameters and applying a bit per bit binary addition with the ciphertext. Based on the input parameters the algorithm generates the output keystream block KEYSTREAM which is used to encrypt the input plaintext block PLAINTEXT to produce the output ciphertext block CIPHERTEXT. The input parameter LENGTH shall affect only the length of the KEYSTREAM BLOCK, not the actual bits in it.

[0045] In some embodiments, the derivation of MAC-I/NAS-MAC (or XMAC-I/XNAS- MAC) may be as described in 3GPP TS 33.501 vl6.0.0 (see Section D.3 “Integrity algorithms” and Figure D.3.1.1-1). The input parameters to the integrity algorithm are a 128-bit integrity key named KEY, a 32-bit COUNT, a 5 -bit bearer identity called BEARER, the 1-bit direction of the transmission, i.e., DIRECTION and the message itself, i.e., MESSAGE. The DIRECTION bit may use a value of ‘0’ to indicate the uplink direction and use a value of ‘ G to indicate the downlink direction. The bit length of the MESSAGE is LENGTH. The integrity algorithm NIA is used to authenticate the integrity of messages.

[0046] Based on these input parameters the sender computes a 32-bit message authentication code (MAC-I/NAS-MAC) using the integrity algorithm NIA. The message authentication code is then appended to the message when sent. For integrity protection algorithms, the receiver computes the expected message authentication code (XMAC-I/XNAS-MAC) on the message received in the same way as the sender computed its message authentication code on the message sent and verifies the data integrity of the message by comparing it to the received message authentication code, i.e. MAC-I/NAS-MAC.

[0047] In PC5 communication, one UE might be in communication with several other UEs. A transmitter (Tx) UE initiating the PC5-S and/or PC5-RRC and/or data connection with another UE on PC5 interface may choose an LCID that is not in use so far (with other PC5 peer UEs), or, may be configured an LCID from a radio network but the same LCID may not available (e.g., already in use) in the intended recipient (Receiver, Rx UE). In this case, it is unclear how the same security inputs at both Tx UE and Rx UE can be ensured.

[0048] To solve Problem 1, the following UE behavior may be implemented: In one embodiment, for each V2X communication, the LCID needs to be unique only inside the same security context. In another embodiment, for each V2X communication, the LCID needs to be unique with respect to the source ID. Source signals a list of available LCIDs, the receiver picks one of these and signals back to the source (Tx UE). In a third embodiment, the Tx UE will choose an LCID. Here, LCIDs are managed independently by Tx UE and Rx UE, e.g., no coordination of used LCID space among Tx UE and Rx UE. Additionally, forwarding to the correct RLC entity happens on the basis of internal mapping in the Rx UE. PDCP security happens on the basis of LCID received from the Tx UE. For example, the LCID may be received as part of PDCP header. As another example, the LCID may be received as part of logical channel/ SLRB configuration. These solutions are discussed in greater detail below.

[0049] Problem 2: UE behavior for reporting SL HARQ-ACK to the gNB may require that the “group size” and “member ID” are indicated by the upper layer to the Access Stratum for a groupcast communication. However, currently it is unclear whether these parameters refer to members within the minimum communication range (“MCR”) or to the total (number of) members irrespective of the MCR belonging to this group. Here, MCR is the minimum range of communication where the QoS needs to be fulfilled and therefore a transmitter UE may seek HARQ feedbacks as explained in US Provisional Application No. 62/877,802, which contents are incorporated by reference.

[0050] In doing so, for Feedback Option 2 (individual ACK/NACK resource for each group member UE), the Tx UE needs to know how many feedbacks are expected and from which all UEs (their corresponding member IDs). A Tx UE needs to be able to distinguish between situations: A) if the feedback is not received because receiver(s) has not sent it as it is outside MCR or B) if Receiver(s) inside of MCR failed to decode the packet. In the latter case, the Tx UE will re-transmit the packet if it is able to distinguish between these situations/cases.

[0051] To solve Problem 2, the following UE behavior may be implemented: In certain embodiments, upper layers may provide the number of UEs inside the MCR Range with their corresponding member IDs. In certain embodiments, upper layers may provide the total number of UEs in the group as well as the number of UEs inside the MCR Range with their corresponding member IDs. In certain embodiments, all UEs outside of MCR and receiving the SCI feedback Ack. The maximum number of re-transmissions are restricted to some specified/ (pre) configured value. These solutions are discussed in greater detail below.

[0052] Problem 3: The “group size” and “member ID” are indicated by the upper layer to the Access Stratum for a groupcast communication. If a real time information on these are to be used, and the radio fluctuations, traffic variability and mobility is high then this information may change very often. The information (at least the “group size”) may need to be signaled to the Radio Node along with the QoS information to enable it to decide on if the transmitter may seek HARQ feedback for transmission to the group or not. This may be done using LCH or SLRB configuration restricting only certain LCHs/bearers to seek the HARQ feedback from the receiver UEs.

[0053] If, however, there are many fluctuations then the Tx UE will send frequent signaling to the RAN node to inform about the new Real time situation (about the “group size” and/or “member ID”). This will not only be signaling inefficient but also be useless if the small changes may not alter the RAN nodes decision on Tx UE seeking HARQ feedback from the Rx UEs.

[0054] To solve Problem 3, the following UE behavior may be implemented: A minimum group size change is defined/(pre)configured and/or a prohibit timer is used to determine whether to update the group size value. Alternatively, and/or additionally, a threshold may be used to determine whether to update the group size value. Here, the UE is allowed to signal a change to the RAN node only if the threshold is exceeded (or crossed in the other direction) compared with the last report. These solutions are discussed in greater detail below.

[0055] Figure 1 depicts a wireless communication system 100 for receiving sidelink feedback from a group of UEs for wireless devices communicating V2X messages 115, according to embodiments of the disclosure. In one embodiment, the wireless communication system 100 includes at least one remote unit 105, a radio access network (“RAN”) 120, and a mobile core network 140. The RAN 120 and the mobile core network 140 form a mobile communication network. The RAN 120 may be composed of a base unit 121 with which the remote unit 105 communicates using wireless communication links 123. Even though a specific number of remote units 105, base units 121, wireless communication links 123, RANs 120, and mobile core networks 140 are depicted in Figure 1, one of skill in the art will recognize that any number of remote units 105, base units 121, wireless communication links 123, RANs 120, and mobile core networks 140 may be included in the wireless communication system 100.

[0056] In one implementation, the RAN 120 is compliant with the 5G system specified in the 3GPP specifications. In another implementation, the RAN 120 is compliant with the LTE system specified in the 3GPP specifications. More generally, however, the wireless communication system 100 may implement some other open or proprietary communication network, for example WiMAX, among other networks. The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol.

[0057] In one embodiment, the remote units 105 may include computing devices, such as desktop computers, laptop computers, personal digital assistants (“PDAs”), tablet computers, smart phones, smart televisions (e.g., televisions connected to the Internet), smart appliances (e.g., appliances connected to the Internet), set-top boxes, game consoles, security systems (including security cameras), vehicle on-board computers, network devices (e.g., routers, switches, modems), or the like. In some embodiments, the remote units 105 include wearable devices, such as smart watches, fitness bands, optical head-mounted displays, or the like. Moreover, the remote units 105 may be referred to as the UEs, subscriber units, mobiles, mobile stations, users, terminals, mobile terminals, fixed terminals, subscriber stations, user terminals, wireless transmit/receive unit (“WTRU”), a device, or by other terminology used in the art.

[0058] The remote units 105 may communicate directly with one or more of the base units 121 in the RAN 120 via uplink (“UL”) and downlink (“DL”) communication signals. Furthermore, the UL and DL communication signals may be carried over the wireless communication links 123. Here, the RAN 120 is an intermediate network that provides the remote units 105 with access to the mobile core network 140.

[0059] In some embodiments, the remote units 105 communicate with an application server 151 via a network connection with the mobile core network 140. For example, an application 107 (e.g., web browser, media client, telephone/VoIP application) in a remote unit 105 may trigger the remote unit 105 to establish a PDU session (or other data connection) with the mobile core network 140 via the RAN 120. The mobile core network 140 then relays traffic between the remote unit 105 and the application server 151 in the packet data network 150 using the PDU session. The PDU session represents a logical connection between the remote unit 105 and the UPF 141. In order to establish the PDU session, the remote unit 105 must be registered with the mobile core network. Note that the remote unit 105 may establish one or more PDU sessions (or other data connections) with the mobile core network 140. As such, the remote unit 105 may concurrently have at least one PDU session for communicating with the packet data network 150 and at least one PDU session for communicating with another data network (not shown).

[0060] The base units 121 may be distributed over a geographic region. In certain embodiments, a base unit 121 may also be referred to as an access terminal, an access point, a base, a base station, a Node-B, an eNB, a gNB, a Home Node-B, a relay node, a RAN node, or by any other terminology used in the art. The base units 121 are generally part of a radio access network (“RAN”), such as the RAN 120, that may include one or more controllers communicably coupled to one or more corresponding base units 121. These and other elements of radio access network are not illustrated but are well known generally by those having ordinary skill in the art. The base units 121 connect to the mobile core network 140 via the RAN 120.

[0061] The base units 121 may serve a number of remote units 105 within a serving area, for example, a cell or a cell sector, via a wireless communication link 123. The base units 121 may communicate directly with one or more of the remote units 105 via communication signals. Generally, the base units 121 transmit DU communication signals to serve the remote units 105 in the time, frequency, and/or spatial domain. Furthermore, the DU communication signals may be carried over the wireless communication links 123. The wireless communication links 123 may be any suitable carrier in licensed or unlicensed radio spectrum. The wireless communication links 123 facilitate communication between one or more of the remote units 105 and/or one or more of the base units 121.

[0062] In one embodiment, the mobile core network 140 is a 5G core (“5GC”) or the evolved packet core (“EPC”), which may be coupled to a packet data network 150, like the Internet and private data networks, among other data networks. A remote unit 105 may have a subscription or other account with the mobile core network 140. Each mobile core network 140 belongs to a single public land mobile network (“PLMN”). The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol.

[0063] The mobile core network 140 includes several network functions (“NFs”). As depicted, the mobile core network 140 includes one or more user plane functions (“UPFs”) 141. The mobile core network 140 also includes multiple control plane functions including, but not limited to, an Access and Mobility Management Function (“AMF”) 143 that serves the RAN 120, a Session Management Function (“SMF”) 145, a Policy Control Function (“PCF”) 147, and a Unified Data Management function (“UDM”) 149. In various embodiments, the mobile core network 140 may also include an Authentication Server Function (“AUSF”), a Network Repository Function (“NRF”) (used by the various NFs to discover and communicate with each other over APIs), a Network Exposure Function (“NEF”), or other NFs defined for the 5GC.

[0064] In various embodiments, the mobile core network 140 supports different types of mobile data connections and different types of network slices, wherein each mobile data connection utilizes a specific network slice. Here, a “network slice” refers to a portion of the mobile core network 140 optimized for a certain traffic type or communication service. Each network slice includes a set of CP and/or UP network functions. A network instance may be identified by a S-NSSAI, while a set of network slices for which the remote unit 105 is authorized to use is identified by NS SAI. In certain embodiments, the various network slices may include separate instances of network functions, such as the SMF 145 and UPF 141. In some embodiments, the different network slices may share some common network functions, such as the AMF 143. The different network slices are not shown in Figure 1 for ease of illustration, but their support is assumed.

[0065] Although specific numbers and types of network functions are depicted in Figure 1 , one of skill in the art will recognize that any number and type of network functions may be included in the mobile core network 140. Moreover, where the mobile core network 140 is an EPC, the depicted network functions may be replaced with appropriate EPC entities, such as an MME, S-GW, P-GW, HSS, and the like. In certain embodiments, the mobile core network 140 may include a AAA server.

[0066] In various embodiments, the remote units 105 may communicate directly with each other (e.g., device -to-de vice communication) using V2X communication signals 125. Here, V2X transmissions may occur on V2X resources. As discussed above, a remote unit 105 may be provided with different V2X communication resources for different V2X modes. Mode-1 corresponds to a NR network-scheduled V2X communication mode. Mode-2 corresponds to an NR UE-scheduled V2X communication mode.

[0067] In various embodiments, sidelink transmissions from a “transmitting” remote unit 105 (i.e., Tx UE) may be groupcast or unicast. Groupcast refers to group communications where the transmitting remote unit 105 in the group transits a multicast packet to its group members, where the members of the group belong to the same destination group identifier. Each UE (i.e., remote unit 105) in the group will have a member ID.

[0068] A “receiving” remote unit 105 may provide HARQ feedback to the transmitting remote unit 105. As noted above, sidelink HARQ feedback may be according to Option 1 - where all receiving remote units 105 (i.e., Rx UEs) can feedback on common resources and are only permitted to feedback a NACK response - or according to Option 2 - where each receiving remote units 105 (i.e., Rx UE) has dedicated feedback resources and is permitted to transmit an ACK or NACK response.

[0069] In various embodiments, SL communication signals 125 may be sent on frequencies in the Frequency Range 2 (“FR2”) band, e.g., 24.25 GHz to 52.6 GHz. In some embodiments, SL communication signals 125 may be sent on frequencies beyond the Frequency Range 2 (“FR2”) band, e.g., using the ITS band at 60 GHz to 70 GHz. The SL communication signals 125 may include data signals, control information, and/or reference signals.

[0070] In certain embodiments, the transmitting remote unit 105 groupcasts using an omnidirectional antenna. In other embodiments, the transmitting remote unit 105 groupcasts data using beam sweeping. As used herein, beam sweeping refers to the transmitting remote unit 105 transmitting the groupcast in predefined directions/beams in sequence, wherein the sequence is indexed and the sequence/index is transmitted as part of the sidelink control channel (e.g., in sidelink control information “SCI”). The transmitting remote unit 105 may dynamically signal (in SCI) information about transmission patterns and periodicity. For example, the transmitting remote unit 105 may transmit a signal (e.g., groupcast message) on a first beam during a first set of transmission symbol duration (e.g., first slot), transmit the signal on a second beam during a second set of transmission symbol duration (e.g., second slot), etc.

[0071] While Figure 1 depicts components of a 5G RAN and a 5G core network, the described embodiments for receiving sidelink feedback from a group of UEs apply to other types of communication networks and RATs, including IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA 2000, Bluetooth, ZigBee, Sigfoxx, and the like. For example, in an LTE variant involving an EPC, the AMF 143 may be mapped to an MME, the SMF 145 may be mapped to a control plane portion of a PGW and/or to an MME, the UPF 141 may be mapped to an SGW and a user plane portion of the PGW, the UDM/UDR 149 may be mapped to an HSS, etc.

[0072] In the following descriptions, the term eNB/ gNB is used for the base station but it is replaceable by any other radio access node, e.g., BS, eNB, gNB, AP, NR, etc. Further the operations are described mainly in the context of 5G NR. However, the proposed solutions/methods are also equally applicable to other mobile communication systems supporting serving cells/carriers being configured for Side link Communication over PC5 interface.

[0073] Figure 2 depicts a protocol stack 200, according to embodiments of the disclosure. While Figure 2 shows the UE-A 201 and the UE-B 203, these are representative of a set of V2X UEs and other embodiments may involve different V2X UEs. As depicted, the V2X protocol stack (i.e., PC5 protocol stack) includes a physical layer 205, a MAC sublayer 210, a RFC sublayer 215, a PDCP sublayer 220, and Radio Resource Control (“RRC”) and Service Data Adaptation Protocol (“SDAP”) layers (depicted as combined element “RRC/SDAP” 225), for the control plane and user plane, respectively. The AS protocol stack for the control plane in the PC5 interface consists of at least RRC, PDCP, RFC and MAC sublayers, and the physical layer. The AS protocol stack for the user plane in the PC5 interface consists of at least SDAP, PDCP, RFC and MAC sublayers, and the physical layer. The Fayer-2 (“F2”) is split into the SDAP, PDCP, RFC and MAC sublayers. The Fayer-3 (“F3”) includes the RRC sublayer and the NAS layer for the control plane and includes, e.g., an Internet Protocol (“IP”) layer for the user plane. FI and F2 are referred to as “lower layers”, while F3 and above (e.g., transport layer, V2X layer, application layer) are referred to as “higher layers” or “upper layers”.

[0074] The physical layer 205 offers transport channels to the MAC sublayer 210. The MAC sublayer 210 offers logical channels to the RFC sublayer 215. The RFC sublayer 215 offers RFC channels to the PDCP sublayer 220. The PDCP sublayer 220 offers radio bearers to the SDAP sublayer and/or RRC layer 225. In the control plane, the SDAP sublayer 225 offers QoS flows. In the user plane, the RRC layer 225 provides for the addition, modification, and release of Carrier Aggregation and/or Dual Connectivity. The RRC layer 225 also manages the establishment, configuration, maintenance, and release of Signaling Radio Bearers (“SRBs”) and Data Radio Bearers (“DRBs”).

[0075] Referring to solutions to problem 1, the security context is established between a Tx UE (e.g., the UE-A 201) and a Rx UE (e.g., the UE-B 203) in the scope of a source and destination F2 ID pair. This corresponds to one set of UE credentials, for example as defined in TR 33.836 (e.g., for ECCSI or SAKKE schemes and/or a security context for the Access Stratum at the PDCP layer). If the same Tx UE and Rx UE has more than one V2X application communication running (e.g., more than one source and destination L2 ID pairs exist between the same pair of physical Tx UE and Rx UEs on PC5), then as many security contexts as running V2X application communication are to be established.

[0076] According to a first alternative to the solution to problem 1, for each communication, the LCID needs to be unique only inside the same security context. The Tx UE will choose an LCID - this may be one LCID that is not in use at least with respect to the L2 destination ID that the transmitter prepares to communicate with. The chosen LCID is to be used as the 5 -bit bearer identity input parameter (called BEARER) for the ciphering algorithm and/or integrity algorithm, as discussed above, when the communication needs to be security protected (cipher and/ or integrity protected).

[0077] The Rx UE, upon receiving said communication, will also assign the same LCID for communication with the source transmitter UE. The chosen LCID is to be used as the 5 -bit bearer identity input parameter, e.g., for deciphering and / or generating XMAC-I.

[0078] Figure 3 depicts an example communication 300 for indicating one or more available LCIDs from the Tx UE (e.g., UE-A 201), according to a second alternative to the solution to problem 1. As depicted, the UE-A 201 sends a First PC5 communication 305 to the UE-B 203 (i.e., the Rx UE in this exchange). In some embodiments, the “First PC5 communication” 305 may be a message establishing a PC5-S connection, a message establishing a PC5-RRC connection, or, a message configuring one or more Sidelink Radio Bearer (“SLRB”) or it may be even the first user data. Additionally, the UE-B 203 sends a Response from the Rx UE message 310 to the UE-A 201. In some embodiments, the “Response from the Rx UE” message 310 is the response from the Rx UE (i.e., UE-B 203) for the corresponding transmission from the Tx UE (i.e., UE-A 201).

[0079] According to the second alternative, for each communication, the LCID needs to be unique and is used for only one PC5 bearer originating from the same Tx UE. The Tx UE (i.e., the UE-A 201) may choose an LCID. Alternatively, the Tx UE may signal a list to the Rx UE (i.e., to the UE-B 203). The chosen LCID (or list of LCIDs) may be LCID(s) that is(are) not in use in any of the active PC5 communication at the moment. The chosen LCID is to be used as the 5-bit bearer identity input parameter (i.e., BEARER) for the ciphering algorithm and/or integrity algorithm, as discussed above, when the communication needs to be security protected (cipher and/or integrity protected).

[0080] The Rx UE (i.e., UE-B 203), upon receiving the First PC5 Communication 305, will assign the same LCID (or one among the list that is not yet in use) for communication with the Tx UE (i.e., the UE-A 201). If the LCID was chosen among a list of LCIDs signaled by the Tx UE, the chosen LCID is signaled back to the Tx UE in the “Response from the Rx UE” message 310. For further communication, the chosen LCID is to be used as the 5-bit bearer identity input parameter (i.e., BEARER), e.g., for deciphering and/or generating XMAC-I.

[0081] According to a third alternative to the solution to problem 1, the UE-B 203 internally maps the LCID signaled by UE-A 201 with the “First PC5 Communication” 305 to some available LCID and forwards the RLC PDUs (i.e., the first and all subsequent RLC PDUs) to a corresponding (established) RLC entity (i.e., located in the RLC sublayer 215. PDCP entity (i.e., located in the PDCP layer 220) is established and is configured with a Bearer ID that is same as the LCID signaled by UE-A 201. Alternatively, the LCID signaled by UE-A 201 is included as part of the PDCP header. Both the transmitter and the receiver PDCP entities use the LCID value in the PDCP header as the 5 -bit bearer identity input parameter for the ciphering algorithm and/or integrity algorithm, as discussed above.

[0082] In other words, in this third alternative, the LCIDs are managed independently by the Tx UE and Rx UE, e.g., there is no coordination of used LCID space between the Tx UE and Rx UE. The Tx UE (i.e., UE-A 201) will choose a LCID(s) from the set of available/unused LCIDs. The chosen LCID is to be used as the 5-bit bearer identity input parameter (i.e., BEARER) for the ciphering algorithm and/or integrity algorithm, as discussed above, when the communication needs to be security protected (cipher and/ or integrity protected).

[0083] Upon receiving said communication, the Rx UE (i.e., UE-B 203) will assign an available/unused LCID and store the mapping between the received LCID from the Tx UE and the locally assigned LCID (at the Rx UE). For the purpose of forwarding MAC SDU(s) to the corresponding RLC entity, the Rx UE uses said mapping between a received LCID and the corresponding locally assigned LCID at the receiver. For the purpose of security, e.g., deciphering a PDU and/or generating XMAC-I, the Rx UE uses the received LCID.

[0084] The following example illustrates the above described behavior: the Tx UE sends a MAC PDU/TB to the Rx UE containing MAC SDU(s) of the LCH with <LCID = ‘X’>. The MAC SDU(s) are ciphered using <LCID = ‘X’> as input to the ciphering algorithm. The Rx UE upon decoding said MAC PDU will forward the MAC SDU(s) of <LCID = ‘X’> to the LCH/RLC entity with <LCID = ‘Y’>. The LCH/RLC entity stores the mapping between <LCID = ‘X’> from the Tx UE and the corresponding LCH at the receiver with <LCID = ‘Y’> for subsequent transmissions. For the purpose of deciphering (at the PDCP entity) PDUs of <LCID = ‘Y’> at the Rx UE, the Rx UE uses the <LCID = ‘X’> as input to the deciphering algorithm. The value of the 32-bit COUNT input parameter used in the ciphering and/or integrity algorithms is not affected by the LCID mapping in the Rx UE and is used “as is” e.g., as signaled by the Tx UE. [0085] Figure 4 depicts a scenario 400 for sidelink communication (e.g., V2X communication) according to solutions to problem 2. A Tx UE 405 sends a sidelink message (e.g., via groupcast transmission) to a group of Rx UEs. As depicted, the Rx UEs include the UE-1 410 (having member ID of ‘M_Id_l ’), the UE-2 415 (having member ID of ‘M_Id_2’), and the UE-3 420 (having member ID of ‘M_Id_3’). The sidelink message is associated with an MCR 425. As depicted, the UE-1 410 and UE-3 420 are located within the MCR 425, but the UE-2415 is located outside the MCR 425. Note that MCR for a sidelink message may be optional; in other words, an MCR is not required for all sidelink communications.

[0086] As described above, the Tx UE 405 has a responsibility to ensure that QoS is fulfdled inside the MCR. However, there may be a divide between the group size and the number of UEs within the MCR. The higher layers only know the group composition but do not know whether a particular group member is within the specific range. So, the problem occurs that the Tx UE 405 cannot be sure whether lack of feedback is due to failure to receive the TB by a Rx UE that is within the specific range or due to the Rx UE being outside the range.

[0087] In certain embodiments, the Tx UE 405 upper layers may provide the number of UEs inside the MCR 425 with their corresponding member IDs. In certain embodiments, the upper layers of the Tx UE 405 may provide the total number of UEs in the group (i.e., 3 in the depicted example) as well as the number of UEs inside the MCR 425 (i.e., 2 in the depicted example) with their corresponding member IDs. In certain embodiments, all UEs outside of MCR 425 (i.e., UE- 2 415 in the depicted example) and receiving the SCI, then feeds back ‘ACK.’ As noted above, the maximum number of re-transmissions are restricted to some specified (e.g., preconfigured) value.

[0088] According to a first solution to problem 2, the upper layers (e.g., the V2X layer or NAS layer to Access Stratum layer; and/ or the application layer to V2X layer) indicate two group size numbers. First, the total number of group members, ‘Group Size TotaT, (irrespective of whether inside or outside of the MCR) and their member IDs (e.g., a first member ID list). Second, the upper layers indicate the number of group members inside of the MCR, ‘Group Size MCR’, and their member IDs (e.g., a second member ID list). In some embodiments, the second member ID list may be indicated along with the first member ID list, by adding a Boolean flag to each list entry to indicated whether the group member (identified by “member ID”) is inside of the MCR.

[0089] Figure 5 depicts a table 500 storing tracking member ID and member location with respect to MCR, according to embodiments of the disclosure. As depicted in the scenario 400, the UE-1 410 (having member ID of ‘M_Id_l’) and the UE-3 420 (having member ID of ‘M_Id_3’) are located within the MCR 425, thus the Table 500 shows Boolean flags for ‘M_Id G and ‘M_Id_3’ set to values indicating that these group members are within the MCR 425.

[0090] In the first solution to problem 2, the Group Size Total will be used to distribute the HARQ feedback resources to all the member IDs and the Group Size MCR is to be used to track which UEs inside the MCR did or did not provide feedback. If there are one or more such UEs then the transmitter may decide to retransmit the corresponding PSSCH transmission.

[0091] According to a second solution to problem 2, the upper layers (V2X layer or NAS layer to Access Stratum layer; and/ or application layer to V2X layer) provide the “group size” and member ID(s) only for the UEs currently inside the MCR 425 for the corresponding group in the groupcast communication. Based on this the Tx UE 405 will know how many HARQ feedbacks are to be expected and from which UE. If one or more feedback is/ are missing, it will re-transmit the PSCCH/ PSSCH. If all expected feedbacks (equal to the indicated group size) are received, the Tx will assume the transmission was successful.

[0092] Note that the feedback may be received by the Tx UE 405 during for at least one PSFCH reception occasion from a number of PSFCH reception occasions in PSFCH resources. A Tx UE that transmitted a PSSCH scheduled by a SCI format 2-A or a SCI format 2-B that indicates HARQ feedback enabled, attempts to receive associated PSFCH transmissions. In some embodiments, the Tx UE determines an ACK or a NACK value for HARQ-ACK information provided in each PSFCH resource as described in 3GPP TS 38.133. Note that the Tx UE 405 does not determine both an ACK value and a NACK value at a same time for a PSFCH resource.

[0093] Note that there may be one or more PSFCH reception occasions. For each PSFCH reception occasion, from a number of PSFCH reception occasions, the Tx UE 405 may generate HARQ-ACK information to report to higher layers. According to Sidelink HARQ feedback Option 1, the Rx UE transmits HARQ-NACK on PSFCH if it fails to decode the corresponding TB after decoding the associated PSCCH. Also according to Option 1, the Rx UE transmits HARQ-ACK on PSFCH if it successfully decodes the corresponding TB. It transmits HARQ- NACK on PSFCH if it does not successfully decode the corresponding TB after decoding the associated PSCCH which targets the Rx UE.

[0094] For SF groupcast HARQ feedback signaling, the Physical Sidelink Feedback Channel (PSFCH) resource may be common to the Rx UEs. Alternatively, the PSFCH resource may be dedicated to each Rx UE. Dedicated resource for ACK and NACK transmissions increases the reliability of the groupcast transmission, but the feedback overhead is very high. However, using dedicated PSFCH resources allow the feedback information to cover all the NACK/ACK/DTX cases of all UEs in the group. [0095] In certain embodiments, multiple Rx UEs may share a common PSFCH resource by allowing the failed Rx UEs (i.e., failed to decode the corresponding TB) to transmit HARQ- NACK on PSFCH, i.e., Option 1. This implies that HARQ-NACK is transmitted in an SFN manner when multiple Rx UEs fail to decode a PSSCH which results in reduced overhead for feedback signaling. There could be a case where some of the Rx UE failed to decode PSCCH, e.g., due to interference, half duplex problem, etc.

[0096] For generating the HARQ-ACK information, the Tx UE can be indicated by a SCI format to perform one of the following: A) if the Tx UE receives a PSFCH associated with a SCI format 2-A with Cast type indicator field value of "01", then the Tx UE may report an ACK value to higher layers if the UE determines an ACK value from at least one PSFCH reception occasion from the number of PSFCH reception occasions in PSFCH resources corresponding to every group member identity M _ID of UEs that the UE expects to receive corresponding PSSCHs, and otherwise reports a NACK value to higher layers; B) if the UE receives a PSFCH associated with a SCI format 2-B or a SCI format 2-A with Cast type indicator field value of " 11 ", then the Tx UE may report to higher layers an ACK value if the UE determines absence of PSFCH reception for the PSFCH reception occasion, and otherwise reports a NACK value to higher layers.

[0097] The Cast type values of “01” and “11” are associated with Groupcast transmissions, as indicated in Table 1.

Table 1: Cast type indicator [0098] According to a third solution to problem 2, each Rx UE is one of the following three types of UEs: a Rx UE Type-A is inside MCR but did not send feedback because it missed SCI/ PSCCH from the Tx UE 405; a Rx UE Type-B is outside MCR and did not sending feedback because it missed SCI/ PSCCH from the Tx UE 405; a Rx UE Type-C is outside MCR and did not send feedback due to being outside MCR (but it received SCI). [0099] According to this third solution, a Type-C Rx UE sends an Ack (even if it fails to decode PSSCH). Note that the Tx UE 405 will be unable to distinguish between the Type-A Rx UEs and Type-B Rx UEs. In some embodiments, the Tx UE 405 restricts the number of re- transmissions that are made to address this ambiguity/ uncertainty. Restricting the number of re transmissions will minimize the interference (assuming Rx UE Type-B situation) and is still meaningful because a UE inside of MCR (Rx UE Type-A) may not miss to receive the SCI continuously. The maximum number of such restricted re-transmission may be specified and/or preconfigured.

[0100] In addition, the following Embodiments for addressing Problem 2 are disclosed for the case when the upper layers do not inform the Access Stratum on the total number of UEs inside of the MCR 425. The below embodiments are aimed for refining/ determining group size, usage of S-RSRP value for group size refinement, determine whether to re-transmit or not to member Rx UE in a group, Assign or remove dedicated feedback resource - This address problem when group member information is not provided within a MCR by higher layer.

[0101] In an alternate embodiment, the AS layer may ignore MCR value from higher layer and the Tx UE 405 may configure all group member UEs with feedback Option 2 groupcast feedback resource (i.e., a Rx UE transmits both HARQ ACK and HARQ NACK feedback). The AS layer may derive internal member ID from the parameter provided by higher layer and assign dedicated feedback resource to each internal member ID. The member size is updated based on the information from the higher layer and also from the lower layer with decoding status, L1/L2 identifiers and also from RSRP. If the number of member UEs is more than the configured threshold value for the resource pool, number of available feedback resource in a resource pool then the Tx UE 405 may choose to transmit with feedback Option 1 (e.g., a Rx UE transmits only HARQ NACK feedback and transmits nothing in a HARQ ACK situation).

[0102] The Tx UE 405 decodes SCI information and also data from nearby UEs as part of sensing procedure, the SCI and data contains LI/ L2 identifiers such as source ID and the destination group ID. In one method, the Tx UE 405 may compare the group size provided from higher layer with that of periodically decoding status of identifier from SCI, data and corresponding PSSCH, PSCCH, PSFCH-RSRP and/or RSSI values - consequently determining active member UEs in a group as part of group size refinement and/or to assign dedicated feedback resources, whether to (re)transmit data. The Tx UE 405 may use the UE assistance information to inform gNB about the active member UE from the L1/L2 decoding status of identifier, RSRP values etc. The RSRP threshold value is configured per MCR value per SL carrier or Resource pool.

[0103] Regarding the case of the Rx UE outside MCR (i.e., the UE-2 415 in the depicted Figure), the Tx UE 405 may remove dedicated feedback resource of a member UE or does not (re)-transmit to member UEs whose PSSCH RSRP or PSCCH RSRP threshold or PSFCH RSRP is above certain configured value. RSRP threshold may be mapped to certain range value. Even though the Rx UE transmits NACK feedback on the dedicated resource, but if the measured RSRP value is above certain configured threshold, then the Tx UE 405 may ignore corresponding NACK feedback and does not (re)-transmit to the UE-2 415.

[0104] Regarding the DTX case, if a Rx UE does not decode SCI, it does not provide HARQ ACK/NACK feedback. Therefore, the Tx UE 405 detects DTX from not receiving either ACK or NACK. Then in this case, Tx UE 405 may check from the previously decoded status of PSCCH, PSSCH and/or PSFCH from the Rx UE (such as RSRP value and associated identifier) and choose whether to (re)transmit or not to the Rx UE. To make sure that the previously decoded status from Rx UE is still valid or outdated, the Tx UE 405 may count slot number from the last measured RSRP value and check whether it is valid or outdated from a configured threshold value.

[0105] To solve Problem 3, the following UE behavior may be implemented: In a first alternative, a minimum group size change is defmed/(pre)configured. If the change in number of member UEs, compared with the last reported number of member UEs, is less than this value then the new group size (with/ without Member IDs) is not informed to the RAN node. In a second alternative, a prohibit timer is used to determine whether to update the group size value. The prohibit timer is (re)started each time the group size is communicated to the RAN node. A new value is not indicated if the prohibit timer is running. In a third alternative, combinations of Alternatives 1 and 2 are used.

[0106] In a fourth alternative, a threshold may be used to determine whether to update the group size value. Here, the UE is allowed to signal a change to the RAN node only if the threshold is exceeded/ crossed in the other direction compared with the last report. As an example, if the threshold is ten members and the last reported value was a Boolean (set to say TRUE for less than 10 members) then the report (Boolean set to FALSE) shall only be sent when the number of member UEs grows to at least 10; and after that the next report (Boolean set to TRUE) shall only be sent when the number of member UEs goes under 10. The said threshold could be specified or (pre)configured.

[0107] Figure 6 depicts a user equipment apparatus 600 that may be used for receiving sidelink feedback from a group of UEs, according to embodiments of the disclosure. In various embodiments, the user equipment apparatus 600 is used to implement one or more of the solutions described above. The user equipment apparatus 600 may be one embodiment of the remote unit 105 and/or any of the V2X UEs 201, 203, 405, 410, 415, and 420, described above. Furthermore, the user equipment apparatus 600 may include a processor 605, a memory 610, an input device 615, an output device 620, and a transceiver 625. [0108] In some embodiments, the input device 615 and the output device 620 are combined into a single device, such as a touchscreen. In certain embodiments, the user equipment apparatus 600 may not include any input device 615 and/or output device 620. In various embodiments, the user equipment apparatus 600 may include one or more of: the processor 605, the memory 610, and the transceiver 625, and may not include the input device 615 and/or the output device 620.

[0109] As depicted, the transceiver 625 includes at least one transmitter 630 and at least one receiver 635. Here, the transceiver 625 communicates with one or more cells supported by one or more base units 121. Additionally, the transceiver 625 may support at least one network interface 640 and/or application interface 645. The application interface(s) 645 may support one or more APIs. The network interface(s) 640 may support 3GPP reference points, such as Uu and PC5. Other network interfaces 640 may be supported, as understood by one of ordinary skill in the art.

[0110] The processor 605, in one embodiment, may include any known controller capable of executing computer-readable instructions and/or capable of performing logical operations. For example, the processor 605 may be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field programmable gate array (“FPGA”), or similar programmable controller. In some embodiments, the processor 605 executes instructions stored in the memory 610 to perform the methods and routines described herein. The processor 605 is communicatively coupled to the memory 610, the input device 615, the output device 620, and the transceiver 625.

[0111] In various embodiments, the processor 605 controls the user equipment apparatus 600 to implement the above described UE behaviors. For example, the processor 605 may control the transceiver 625 to transmit a first message to a group of UEs via groupcast communication. The processor 605 then determines an expected number of positive acknowledgements corresponding to the first message, e.g., based on a first set of at least one receiver UE belonging to the group of UEs.

[0112] In some embodiments, the first set contains a first number of receiver UEs. In one embodiment, the first set consists of each receiver UE belonging to the group of UEs that is within a MCR of the first message. In another embodiment, the first set consists of each receiver UE belonging to the group of UEs irrespective of the MCR.

[0113] Via the transceiver 625, the processor 605 receives an actual number of positive acknowledgements from the group of UEs. Here, receiving the actual number of positive acknowledgements includes the transceiver 625 receiving sidelink feedback during at least one sidelink feedback channel reception occasion. [0114] In certain embodiments, the transceiver 625 receives a feedback transmission from at least one second UE that is outside the MCR and the processor 605 restricts a maximum number of retransmissions for the first message. In certain embodiments, the transceiver 625 receives a signal from a particular receiver UE and the processor 605 identifies the particular receiver UE as being within the MCR if a received signal strength is within a threshold range.

[0115] If the actual number of positive acknowledgements is equal to the expected number of acknowledgements, then the processor 605 indicates successful transmission of the first message. Otherwise, the processor 605 controls the transceiver 625 retransmits the first message if the actual number of positive acknowledgements is not equal to the expected number of positive acknowledgements.

[0116] In some embodiments, the processor 605 supports a lower layer entity and an upper layer entity that provides the first number of receiver UEs to the lower layer entity. In some embodiments, the lower layer is an Access Stratum (“AS”) layer and the upper layer is one of: a V2X layer and a Non-Access Stratum (“NAS”) layer. In other embodiments, the lower layer is a V2X layer and the upper layer is an application layer.

[0117] In certain embodiments, each receiver UE in the first set has a member ID corresponding to the group, where the upper layer entity provides to the lower layer entity the member ID for each receiver UE in the first set. In some embodiments, each member ID is associated with a sidelink feedback resource. In such embodiments, the at least one sidelink feedback channel reception occasion comprises a PSFCH reception occasion from multiple (i.e., a number of) PSFCH reception occasions corresponding to the sidelink feedback resources.

[0118] In some embodiments, the upper layer entity further provides to the lower layer entity a total number of group members and a member ID for each receiver UE in the group. In certain embodiments, the upper layer entity provides the first number of receiver UEs to the lower layer entity by providing a first list of member IDs, where a total number of list entries is equal to the total number of group members, and where each entry in the list is associated with an indicator of whether the corresponding group member is inside the MCR of the first message.

[0119] In some embodiments, the processor 605 distributes feedback resources based on the total number of group members. In certain embodiments, the processor 605 distributes the feedback resources by allocating resources for both positive feedback and negative feedback if the total number of group members is less than or equal to a threshold amount. In certain embodiments, the processor 605 distributes the feedback resources by allocating resource only for negative feedback if the total number of group members is greater than the threshold amount. [0120] The memory 610, in one embodiment, is a computer readable storage medium. In some embodiments, the memory 610 includes volatile computer storage media. For example, the memory 610 may include a RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and/or static RAM (“SRAM”). In some embodiments, the memory 610 includes non-volatile computer storage media. For example, the memory 610 may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. In some embodiments, the memory 610 includes both volatile and non-volatile computer storage media.

[0121] In some embodiments, the memory 610 stores data related to V2X communication. For example, the memory 610 may store LCH data, MAC PDUs, TBs, group size, member IDs, MCR, and the like. In certain embodiments, the memory 610 also stores program code and related data, such as an operating system or other controller algorithms operating on the apparatus 600.

[0122] The input device 615, in one embodiment, may include any known computer input device including a touch panel, a button, a keyboard, a stylus, a microphone, or the like. In some embodiments, the input device 615 may be integrated with the output device 620, for example, as a touchscreen or similar touch-sensitive display. In some embodiments, the input device 615 includes a touchscreen such that text may be input using a virtual keyboard displayed on the touchscreen and/or by handwriting on the touchscreen. In some embodiments, the input device 615 includes two or more different devices, such as a keyboard and a touch panel.

[0123] The output device 620, in one embodiment, is designed to output visual, audible, and/or haptic signals. In some embodiments, the output device 620 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 620 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or similar display device capable of outputting images, text, or the like to a user. As another, non-limiting, example, the output device 620 may include a wearable display separate from, but communicatively coupled to, the rest of the user equipment apparatus 600, such as a smart watch, smart glasses, a heads-up display, or the like. Further, the output device 620 may be a component of a smart phone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like.

[0124] In certain embodiments, the output device 620 includes one or more speakers for producing sound. For example, the output device 620 may produce an audible alert or notification (e.g., a beep or chime). In some embodiments, the output device 620 includes one or more haptic devices for producing vibrations, motion, or other haptic feedback. In some embodiments, all or portions of the output device 620 may be integrated with the input device 615. For example, the input device 615 and output device 620 may form atouchscreen or similar touch-sensitive display. In other embodiments, the output device 620 may be located near the input device 615.

[0125] The transceiver 625 includes at least transmitter 630 and at least one receiver 635. One or more transmitters 630 may be used to provide UL communication signals to a base unit 121, such as the UL transmissions described herein. Similarly, one or more receivers 635 may be used to receive DL communication signals from the base unit 121, as described herein. Although only one transmitter 630 and one receiver 635 are illustrated, the user equipment apparatus 600 may have any suitable number of transmitters 630 and receivers 635. Further, the transmitter(s) 630 and the receiver(s) 635 may be any suitable type of transmitters and receivers. In one embodiment, the transceiver 625 includes a first transmitter/receiver pair used to communicate with a mobile communication network over licensed radio spectrum and a second transmitter/receiver pair used to communicate with a mobile communication network over unlicensed radio spectrum.

[0126] In certain embodiments, the first transmitter/receiver pair used to communicate with a mobile communication network over licensed radio spectrum and the second transmitter/receiver pair used to communicate with a mobile communication network over unlicensed radio spectrum may be combined into a single transceiver unit, for example a single chip performing functions for use with both licensed and unlicensed radio spectrum. In some embodiments, the first transmitter/receiver pair and the second transmitter/receiver pair may share one or more hardware components. For example, certain transceivers 625, transmitters 630, and receivers 635 may be implemented as physically separate components that access a shared hardware resource and/or software resource, such as for example, the network interface 640.

[0127] In various embodiments, one or more transmitters 630 and/or one or more receivers 635 may be implemented and/or integrated into a single hardware component, such as a multi transceiver chip, a system -on-a-chip, an ASIC, or other type of hardware component. In certain embodiments, one or more transmitters 630 and/or one or more receivers 635 may be implemented and/or integrated into a multi-chip module. In some embodiments, other components such as the network interface 640 or other hardware components/circuits may be integrated with any number of transmitters 630 and/or receivers 635 into a single chip. In such embodiment, the transmitters 630 and receivers 635 may be logically configured as a transceiver 625 that uses one more common control signals or as modular transmitters 630 and receivers 635 implemented in the same hardware chip or in a multi -chip module.

[0128] Figure 7 depicts one embodiment of a network equipment apparatus 700 that may be used for receiving sidelink feedback from a group of UEs, according to embodiments of the disclosure. In some embodiments, the network apparatus 700 may be one embodiment of a RAN node and its supporting hardware, such as the base unit 121, RAN node and/or gNB, described above. Furthermore, network equipment apparatus 700 may include a processor 705, a memory 710, an input device 715, an output device 720, and a transceiver 725. In certain embodiments, the network equipment apparatus 700 does not include any input device 715 and/or output device 720.

[0129] As depicted, the transceiver 725 includes at least one transmitter 730 and at least one receiver 735. Here, the transceiver 725 communicates with one or more remote units 105. Additionally, the transceiver 725 may support at least one network interface 740 and/or application interface 745. The application interface(s) 745 may support one or more APIs. The network interface(s) 740 may support 3GPP reference points, such as Uu, Nl, N2 and N3. Other network interfaces 740 may be supported, as understood by one of ordinary skill in the art.

[0130] The processor 705, in one embodiment, may include any known controller capable of executing computer-readable instructions and/or capable of performing logical operations. For example, the processor 705 may be a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or similar programmable controller. In some embodiments, the processor 705 executes instructions stored in the memory 710 to perform the methods and routines described herein. The processor 705 is communicatively coupled to the memory 710, the input device 715, the output device 720, and the transceiver 725.

[0131] In various embodiments, the processor 705 controls the network equipment apparatus 700 to implement the above described RAN node behaviors. For example, the processor 705 may allocate SU resources to a UE, as described herein.

[0132] The memory 710, in one embodiment, is a computer readable storage medium. In some embodiments, the memory 710 includes volatile computer storage media. For example, the memory 710 may include a RAM, including DRAM, SDRAM, and/or SRAM. In some embodiments, the memory 710 includes non-volatile computer storage media. For example, the memory 710 may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. In some embodiments, the memory 710 includes both volatile and non volatile computer storage media.

[0133] In some embodiments, the memory 710 stores data relating to receiving sidelink feedback from a group of UEs, for example storing UE identities, SL resource allocations, and the like. In certain embodiments, the memory 710 also stores program code and related data, such as an OS or other controller algorithms operating on the network equipment apparatus 700 and one or more software applications. [0134] The input device 715, in one embodiment, may be substantially as described above with reference to the input device 615. Similarly, the output device 720 may be substantially as described above with reference to the output device 620. In some embodiments, the input device 715 may be integrated with the output device 720, for example, as a touchscreen or similar touch- sensitive display. In other embodiments, all or portions of the output device 720 may be located near the input device 715.

[0135] As discussed above, the transceiver 725 may communicate with one ormore remote units and/or with one or more network functions that provide access to one or more PLMNs. The transceiver 725 operates under the control of the processor 705 to transmit messages, data, and other signals and also to receive messages, data, and other signals. For example, the processor 705 may selectively activate the transceiver 725 (or portions thereof) at particular times in order to send and receive messages.

[0136] The transceiver 725 may include one or more transmitters 730 and one or more receivers 735. In certain embodiments, the one or more transmitters 730 and/or the one or more receivers 735 may share transceiver hardware and/or circuitry. For example, the one or more transmitters 730 and/or the one or more receivers 735 may share antenna(s), antenna tuner(s), amplifier(s), filter(s), oscillator(s), mixer(s), modulator/demodulator(s), power supply, and the like. In one embodiment, the transceiver 725 implements multiple logical transceivers using different communication protocols or protocol stacks, while using common physical hardware.

[0137] Figure 8 depicts one embodiment of a method 800 for receiving sidelink feedback from a group of UEs, according to embodiments of the disclosure. In various embodiments, the method 800 is performed by a UE, such as the remote unit 105, the UE-A 201, the Tx UE 405 and/or the user equipment apparatus 600, described above. In some embodiments, the method 800 is performed by a processor, such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

[0138] The method 800 begins and transmits 805 a first message to a group of UEs via groupcast communication. The method 800 includes determining 810 an expected number of positive acknowledgements corresponding to the first message based on a first set of at least one receiver UE belonging to the group of UEs. The method 800 includes receiving 815 an actual number of positive acknowledgements from the group of UEs, where receiving the actual number of positive acknowledgements comprises receiving sidelink feedback during at least one sidelink feedback channel reception occasion. The method 800 includes retransmitting 820 the first message if the actual number of positive acknowledgements is not equal to the expected number of positive acknowledgements. The method 800 ends. [0139] Disclosed herein is a first apparatus for receiving sidelink feedback from a group of UEs, according to embodiments of the disclosure. The first apparatus may be implemented by a UE, such as the remote unit 105, the UE-A 201, the Tx UE 405 and/or the user equipment apparatus 600, described above. The first apparatus includes a transceiver that transmits a first message to a group of UEs via groupcast communication. The first apparatus also includes a processor that determines an expected number of positive acknowledgements corresponding to the first message based on a first set of at least one receiver UE belonging to the group of UEs and receives an actual number of positive acknowledgements from the group of UEs. Here, receiving the actual number of positive acknowledgements includes the transceiver receiving sidelink feedback during at least one sidelink feedback channel reception occasion. The transceiver retransmits the first message if the actual number of positive acknowledgements is not equal to the expected number of positive acknowledgements.

[0140] In various embodiments, the processor indicates successful transmission of the first message in response to the actual number of positive acknowledgements being equal to the expected number of acknowledgements. In some embodiments, the first set contains a first number of receiver UEs. In one embodiment, the first set consists of each receiver UE belonging to the group of UEs that is within a MCR of the first message. In another embodiment, the first set consists of each receiver UE belonging to the group of UEs irrespective of the MCR.

[0141] In certain embodiments, the transceiver receives a feedback transmission from at least one second UE that is outside the MCR and the processor restricts a maximum number of retransmissions for the first message. In certain embodiments, the transceiver receives a signal from a particular receiver UE and the processor identifies the particular receiver UE as being within the MCR if a received signal strength is within a threshold range.

[0142] In some embodiments, the first apparatus includes a lower layer entity and an upper layer entity that provides the first number of receiver UEs to the lower layer entity. In some embodiments, the lower layer is an Access Stratum layer and the upper layer is one of: a V2X layer and a Non-Access Stratum layer. In other embodiments, the lower layer is a V2X layer and the upper layer is an application layer.

[0143] In certain embodiments, each receiver UE in the first set has a member ID corresponding to the group, where the upper layer entity provides to the lower layer entity the member ID for each receiver UE in the first set. In some embodiments, each member ID is associated with a sidelink feedback resource. In such embodiments, the at least one sidelink feedback channel reception occasion comprises a PSFCH reception occasion from multiple (i.e., a number of) PSFCH reception occasions corresponding to the sidelink feedback resources. [0144] In some embodiments, the upper layer entity further provides to the lower layer entity a total number of group members and a member ID for each receiver UE in the group. In certain embodiments, the upper layer entity providing the first number of receiver UEs to the lower layer entity comprises the upper layer entity providing a first list of member IDs, where a total number of list entries is equal to the total number of group members, and where each entry in the list is associated with an indicator of whether the corresponding group member is inside the MCR of the first message.

[0145] In some embodiments, the processor distributes feedback resources based on the total number of group members. In certain embodiments, the processor distributes the feedback resources by allocating resources for both positive feedback and negative feedback if the total number of group members is less than or equal to a threshold amount, and allocating resource only for negative feedback if the total number of group members is greater than the threshold amount.

[0146] Disclosed herein is a first method for receiving sidelink feedback from a group of UEs, according to embodiments of the disclosure. The first method may be performed by a Tx UE, such as the remote unit 105, the UE-A 201, the TxUE405 and/orthe user equipment apparatus 600, described above. The first method includes transmitting a first message to a group of UEs via groupcast communication and determining an expected number of positive acknowledgements corresponding to the first message based on a first set of at least one receiver UE belonging to the group of UEs. The first method includes receiving an actual number of positive acknowledgements from the group of UEs, where receiving the actual number of positive acknowledgements comprises receiving sidelink feedback during at least one sidelink feedback channel reception occasion. The first method includes retransmitting the first message if the actual number of positive acknowledgements is not equal to the expected number of positive acknowledgements.

[0147] In various embodiments, the first method includes indicating successful transmission of the first message in response to the actual number of positive acknowledgements being equal to the expected number of acknowledgements. In some embodiments, the first set containing a first number of receiver UEs. In one embodiment, the first set consists of each receiver UE belonging to the group of UEs that is within a MCR of the first message. In another embodiment, the first set consists of each receiver UE belonging to the group of UEs irrespective of the MCR.

[0148] In certain embodiments, the first method includes receiving a feedback transmission from at least one second UE that is outside the MCR and restricting a maximum number of retransmissions for the first message. In certain embodiments, the first method includes receiving a signal from a particular receiver UE. Here, the particular receiver UE is identified as within the MCR if a received signal strength is within a threshold range.

[0149] In some embodiments, an upper layer entity of the remote unit provides the first number of receiver UEs to a lower layer entity of the remote unit. In some embodiments, the lower layer comprises an Access Stratum layer and the upper layer comprises one of: a V2X layer and a Non-Access Stratum layer. In other embodiments, the lower layer comprises a V2X layer and the upper layer comprises an application layer.

[0150] In certain embodiments, each receiver UE in the first set has a member ID corresponding to the group. Here, the upper layer entity provides to the lower layer the member ID for each receiver UE in the first set. In certain embodiments, each member ID is associated with a sidelink feedback resource. Here, the at least one si delink feedback channel reception occasion comprises a PSFCH reception occasion from multiple (i.e., a number of) PSFCH reception occasions corresponding to the sidelink feedback resources.

[0151] In some embodiments, the upper layer entity further provides to the lower layer a total number of group members and a member ID for each receiver UE in the group. In certain embodiments, the upper layer provides the first number of receiver UEs to the lower layer entity by the upper layer providing a first list of member IDs. In such embodiments, the total number of list entries is equal to the total number of group members, and where each entry in the list is associated with an indicator of whether the corresponding group member is inside the MCR of the first message.

[0152] In some embodiments, the first method includes distributing feedback resources based on the total number of group members. In certain embodiments, distributing feedback resources includes allocating resources for both positive feedback and negative feedback if the total number of group members is less than or equal to a threshold amount, and allocating resource only for negative feedback if the total number of group members is greater than the threshold amount.

[0153] Embodiments may be practiced in other specific forms. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.