Patent Description:
Examples of such multiple-access systems include 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) systems, LTE Advanced (LTE-A) systems, code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, single-carrier frequency division multiple access (SC FDMA) systems, and time division synchronous code division multiple access (TD-SCDMA) systems, to name a few.

<CIT> discloses: a communication technique for merging, with IoT technology, a <NUM> communication system for supporting a data transmission rate higher than that of a <NUM> system; and a system therefor. <CIT> discloses a method and apparatus for a first UE for resource allocation on relay channel in a wireless communication system. <CIT> discloses methods, systems, and apparatuses for integrating a first radio access technology and a second radio access technology in a wireless transmit/receive unit (WTRU).

After reading the section entitled "Detailed Description" one will understand how the features of this disclosure provide advantages that include improved communications between access points and stations in a wireless network.

Aspects of the present disclosure provide apparatus, methods, processing systems, and computer readable mediums for generating and processing sideline MAC-CEs.

For example, UEs <NUM> and/or BS <NUM> of <FIG> may be configured to perform operations described below with reference to FIGs. <NUM>-<NUM> to generate and/or process sidelink MAC-CEs.

As illustrated in <FIG>, the wireless communication network <NUM> may include a number of base stations (BSs) <NUM> and other network entities. A BS may be a station that communicates with user equipments (UEs). Each BS <NUM> may provide communication coverage for a particular geographic area. In NR systems, the term "cell" and next generation NodeB (gNB or gNodeB), NR BS, <NUM> NB, access point (AP), or transmission reception point (TRP) may be interchangeable. In some examples, the base stations may be interconnected to one another and/or to one or more other base stations or network nodes (not shown) in wireless communication network <NUM> through various types of backhaul interfaces, such as a direct physical connection, a wireless connection, a virtual network, or the like using any suitable transport network.

ANC <NUM> may include one or more TRPs <NUM> (e.g., cells, BSs, gNBs, etc.).

The Radio Resource Control (RRC) layer, Packet Data Convergence Protocol (PDCP) layer, Radio Link Control (RLC) layer, Medium Access Control (MAC) layer, and a Physical (PHY) layers may be adaptably placed at the DU (e.g., TRP <NUM>) or CU (e.g., ANC <NUM>).

<FIG> illustrates example components of BS <NUM> and UE <NUM> (as depicted in <FIG>), which may be used to implement aspects of the present disclosure. For example, antennas <NUM>, processors <NUM>, <NUM>, <NUM>, and/or controller/processor <NUM> of the UE <NUM> and/or antennas <NUM>, processors <NUM>, <NUM>, <NUM>, and/or controller/processor <NUM> of the BS <NUM> may be used to perform the various techniques and methods described herein with reference to <FIG>.

The controllers/processors <NUM> and <NUM> may direct the operation at the BS <NUM> and the UE <NUM>, respectively.

<FIG> show diagrammatic representations of example vehicle to everything (V2X) systems in accordance with some aspects of the present disclosure. For example, the vehicles shown in <FIG> may communicate via sidelink channels and may perform sidelink CSI reporting as described herein.

The V2X systems, provided in <FIG> provide two complementary transmission modes. A first transmission mode, shown by way of example in <FIG>, involves direct communications (for example, also referred to as side link communications) between participants in proximity to one another in a local area. A second transmission mode, shown by way of example in <FIG>, involves network communications through a network, which may be implemented over a Uu interface (for example, a wireless communication interface between a radio access network (RAN) and a UE).

Referring to <FIG>, a V2X system <NUM> (for example, including vehicle to vehicle (V2V) communications) is illustrated with two vehicles <NUM>, <NUM>. The first transmission mode allows for direct communication between different participants in a given geographic location. As illustrated, a vehicle can have a wireless communication link <NUM> with an individual (V2P) (for example, via a UE) through a PC5 interface. Communications between the vehicles <NUM> and <NUM> may also occur through a PC5 interface <NUM>. In a like manner, communication may occur from a vehicle <NUM> to other highway components (for example, highway component <NUM>), such as a traffic signal or sign (V2I) through a PC5 interface <NUM>. With respect to each communication link illustrated in <FIG>, two-way communication may take place between elements, therefore each element may be a transmitter and a receiver of information. The V2X system <NUM> may be a self-managed system implemented without assistance from a network entity. A self-managed system may enable improved spectral efficiency, reduced cost, and increased reliability as network service interruptions do not occur during handover operations for moving vehicles. The V2X system may be configured to operate in a licensed or unlicensed spectrum, thus any vehicle with an equipped system may access a common frequency and share information. Such harmonized/common spectrum operations allow for safe and reliable operation.

<FIG> shows a V2X system <NUM> for communication between a vehicle <NUM> and a vehicle <NUM> through a network entity <NUM>. These network communications may occur through discrete nodes, such as a base station (for example, an eNB or gNB), that sends and receives information to and from (for example, relays information between) vehicles <NUM>, <NUM>. The network communications through vehicle to network (V2N) links <NUM> and <NUM> may be used, for example, for long range communications between vehicles, such as for communicating the presence of a car accident a distance ahead along a road or highway. Other types of communications may be sent by the node to vehicles, such as traffic flow conditions, road hazard warnings, environmental/weather reports, and service station availability, among other examples. Such data can be obtained from cloud-based sharing services.

In some circumstances, two or more subordinate entities (for example, UEs) may communicate with each other using sidelink signals. As described above, V2V and V2X communications are examples of communications that may be transmitted via a sidelink. Other applications of sidelink communications may include public safety or service announcement communications, communications for proximity services, communications for UE-to-network relaying, device-to-device (D2D) communications, Internet of Everything (IoE) communications, Internet of Things (IoT) communications, mission-critical mesh communications, among other suitable applications. Generally, a sidelink may refer to a direct link between one subordinate entity (for example, UE1) and another subordinate entity (for example, UE2). As such, a sidelink may be used to transmit and receive a communication (also referred to herein as a "sidelink signal") without relaying the communication through a scheduling entity (for example, a BS), even though the scheduling entity may be utilized for scheduling or control purposes. In some examples, a sidelink signal may be communicated using a licensed spectrum (unlike wireless local area networks, which typically use an unlicensed spectrum).

Various sidelink channels may be used for sidelink communications, including a physical sidelink discovery channel (PSDCH), a physical sidelink control channel (PSCCH), a physical sidelink shared channel (PSSCH), and a physical sidelink feedback channel (PSFCH). The PSDCH may carry discovery expressions that enable proximal devices to discover each other. The PSCCH may carry control signaling such as sidelink resource configurations and other parameters used for data transmissions, and the PSSCH may carry the data transmissions.

For the operation regarding PSSCH, a UE performs either transmission or reception in a slot on a carrier. NR sidelink supports for a UE a case where all the symbols in a slot are available for sidelink, as well as another case where only a subset of consecutive symbols in a slot is available for sidelink.

PSFCH may carry feedback such as channel state information (CSI) related to a sidelink channel quality. A sequence-based PSFCH format with one symbol (not including AGC training period) may be supported. The following formats may be possible: a PSFCH format based on PUCCH format <NUM> and a PSFCH format spanning all available symbols for sidelink in a slot.

<FIG> provides an overview of sidelink communications (broadcast and groupcast device-to-device or D2D) between UEs. As noted above, with reference to <FIG>, sidelink generally refers to the link between two users or user-relays can be used in different scenarios and for different applications.

For example, for applications with in-coverage operation, both users are in a gNB's coverage, but directly communicate. This can be assumed for enabling some gaming applications. For applications with partial-coverage operation, one UE is in-coverage, and acts as a relay to extend the coverage for other users. For application with out-of-coverage operation, users are outside the gNB's coverage, but still need to communicate. This type of operation is important for mission critical applications, such as V2X and public safety.

As illustrated in <FIG>, the resource allocation for sidelink communications can be done in different ways. In a first mode, Mode <NUM>, the gNB "schedules" the sidelink resources to be used by the UE for SL transmission.

For a second mode, Mode <NUM>, the UE determines the sidelink resources (the gNB does not schedule SL transmission resources within SL resources configured by gNB/network). In this case, the UE autonomously selects SL resources for transmission. A UE can assist in SL resource selection for other UEs. A UE may configured with an NR configured grant for SL transmission and the UE may schedule SL transmissions for other UEs.

Certain aspects of the present disclosure provide techniques for conveying information via medium access control (MAC) control element (CEs). In some cases, the MAC-CEs may relate to sidelink communications between two user equipments (UEs).

MAC-CEs have advantages over other types of command messages, albeit at some cost. For example, MAC-CEs have increased reliability provided by hybrid automatic repeat request (HARQ), but with a correspondingly increased latency. HARQ acknowledgement (Ack) or negative-acknowledgement (Nack) respectively provides confirmation that a MAC-CE (e.g., a command) has been received or otherwise.

Alternative command messages (to MAC-CEs) include downlink control information (DCI) on DL, and uplink control information (UCI) on UL (e.g., via PUCCH or PUSCH). While these messages have no HARQ Ack/Nack, they are generally less reliable, but have a lower latency.

MAC-CEs are used in sidelink communications (e.g., per one of the modes described above with reference to <FIG>) for various reasons. For example, a sidelink buffer status report (SL-BSR) MAC-CE may be sent on the cellular link (Uu) but indicates buffer-status of sidelink traffic (e.g., a UE has sidelink traffic to send to another UE and requests resources of a gNB per Mode <NUM>).

Further, for NR V2X, a CSI report may be sent over a sidelink MAC-CE. This approach may avoid a UE having to implement receiver for UCI-multiplexing.

For advanced systems (e.g., in Rel-<NUM>), use cases may call for more (and different) types of sidelink-related MAC-CEs. Such MAC-CEs may include both MAC-CEs sent over Uu and MAC-CEs sent over sidelink (carrying sidelink-related information in both cases).

In the case of sidelink relaying, MAC-CEs may indicate relayed traffic or originating traffic. In the case of Uu-PC5 slot-aggregation (where both cellular and sidelinks may be used), special handling for MAC-CEs may be considered. For example, a MAC-CE may indicate which code block groups (CBGs of a transport block/TB) come from which link.

In some cases, a MAC-CE may indicate which CBGs carry other MAC-CEs. MAC-CEs may be placed at the beginning of a TB or at the end, for example, depending on urgency.

Aspects of the present disclosure provide sidelink related MAC-CE designs that may accommodate these various use cases. For example, in some cases, the MAC-CEs may including routing information that may help a recipient identify and process different types of traffic (e.g., relayed traffic/original traffic, traffic sent via sidelink/traffic sent via Uu).

<FIG> is a flow diagram illustrating example operations <NUM> that may be performed by a first node, in accordance with certain aspects of the present disclosure. For example, operations <NUM> may be performed by a UE or base station (e.g., either being the first node) shown in <FIG>. In some examples, the first node may be any of the BS <NUM>, vehicle <NUM>, vehicle <NUM>, vehicle <NUM>, or vehicle <NUM> of <FIG>.

Operations <NUM> begin, at <NUM>, by preparing at least a first medium access control (MAC) control element (CE) related to sidelink communications between two user equipments (UEs). For example, the preparation may include appending relaying or routing information to Uu MAC-CEs. When the MAC-CEs are for the use of sidelink, the preparation may include including sidelink related content (examples provided below).

At <NUM>, the first node sends the first MAC-CE on at least one of a sidelink (e.g., PC5) or a cellular link (e.g., Uu). At <NUM>, the first node provides routing information for the first MAC-CE. For example, the relaying or routing information may indicate one or more of source node, destination node, and transit route. In some cases, the relaying or routing information may be separately indicated, such as in RRC, DCI, or sidelink equivalents to the RRC and DCI. In some cases, when the sidelink related content is relayed, routing information may be padded or removed for sidelink-relayed MAC-CE.

<FIG> is a flow diagram illustrating example operations <NUM> that may be performed by a second node, in accordance with certain aspects of the present disclosure. For example, operations <NUM> may be performed by a UE or base station (e.g., either being the second node) shown in <FIG>. Operations <NUM> may be complementary to operations <NUM> of <FIG>, such as when the second node is configured to communicate with the first node of operations <NUM> in a sidelink channel. Likewise, in some examples, the second node may be another one of any of the BS <NUM>, vehicle <NUM>, vehicle <NUM>, vehicle <NUM>, or vehicle <NUM> of <FIG>.

Operations <NUM> begin, at <NUM>, by receiving from a first node, such as the first node of operations <NUM>, on at least one of a sidelink or a cellular link, at least a first medium access control (MAC) control element (CE) related to sidelink communications between two user equipments (UEs). At <NUM>, the second node obtains routing information for the first MAC-CE. At <NUM>, the second node processes first MAC-CE based, at least in part, on the routing information. Details of sidelink related MAC-CEs are provided below.

There are various types of sidelink related MAC-CEs. These include, for example, Uu MAC-CEs (DL or UL) relayed via sidelink, MAC-CEs sent on SL with SL-related content, and MAC-CEs sent on Uu with SL-related content (e.g., SL-BSR already in LTE).

For Uu MAC-CEs (DL or UL) relayed via sidelink, relaying/routing information may be appended. As an alternative, routing (and/or relaying) information may be provided separately (e.g., indicated via RRC/MAC-CE/DCI or their sidelink equivalents). As used herein, the term routing information includes relaying information and such information may indicate, for example, one or more of source-node, destination node, or a transit route). If the last leg of a relayed route is via cellular (Uu), then routing info may be removed at that point (or some/all may be kept, such as a source ID). In some cases, the last leg may be combined sidelink and cellular (Uu + PC5), in case of Uu+PC5 slot-aggregation. In such cases, the routing info indication may be different in this case as compared to Uu-only (e.g., routing information may indicate which link different MAC-CEs are sent on).

MAC-CEs sent on SL may convey various SL-related content. For example, a MAC-CE may include sidelink CSI (SL-CSI), sidelink timing advance (SL-TA), sidelink transmit power control (SL-TPC) command, sidelink scheduling requests (SL-SR), sidelink buffer status reports (SL-BSR), or sidelink power headroom reports (SL-PHR). In some cases, sidelink MAC-CEs may be used for activation/deactivation of resources or services, such as sidelink semi persistent scheduling (SL-SPS) or sidelink configured grants (SL-CG analogous to SPS UL) and/or aperiodic or semi-persistent CSI-RS or SRS (A/SP SL-CSIRS/SRS). In case such MAC-CEs are relayed over SL, routing info may be modified (e.g., added/removed) as noted in the above described case of SL-relayed Uu MAC-CE.

MAC-CEs may also be sent on Uu with SL-related content, such as the aforementioned SL-BSR to indicate a UE has sidelink traffic to send and requests a grant of resources from a base station. Other types of MAC-CEs sent on Uu may include SL-PHR, TPC, recommended bit-rate, CBR/CR, and the like. In some cases, the MAC-CEs may be sent as gNB-relayed versions of the types of MAC-CEs described above that might be sent on SL with SL-related content (e.g., rather than send directly to another UE, a UE may send via a base station).

In the case of MAC-CEs sent via Uu+PC5 slot-aggregation, a 'header' MAC-CE may be used to indicate which CBGs come from which link (Uu or PC5 or both). Such a MAC-CE may also indicate locations of other MAC-CEs (e.g., which CBGs have MAC-CEs) and/or on which link they are sent (Uu or PC5 or both).

In the case of MAC-CE commands, corresponding activation/deactivation of resources or services is often based on the timing of acknowledgment of the command. For example, some activation/deactivation of SPS resources may occur n subframes after a corresponding command is acknowledged (ACK'd), for example, via a HARQ Ack. In the case of relayed MAC-CEs, however, it may be difficult to determine timing due to the possible variable delay due to different routes (with different numbers of hops).

Aspects of the present disclosure, however, may help address this issue by considering routing/relaying information when determining MAC-CE activation time, thus providing sidelink related MAC-CE designs that may accommodate these various use cases. For example, in some cases, the MAC-CEs may including routing information that may help a recipient identify and process different types of traffic (e.g., relayed traffic/original traffic, traffic sent via sidelink/traffic sent via Uu).

<FIG> is a flow diagram illustrating example operations <NUM> that may be performed by a first node to determine MAC-CE activation timing, in accordance with certain aspects of the present disclosure. For example, operations <NUM> may be performed by a UE or base station shown in <FIG>.

Operations <NUM> begin, at <NUM>, by sending a medium access control (MAC) control element (CE) to activate or deactivate resources or a service related to sidelink communications between two user equipments (UEs). At <NUM>, the first node determines timing for the activation or deactivation based, at least in part, on routing information for the first MAC-CE.

<FIG> is a flow diagram illustrating example operations <NUM> that may be performed by a second node to determine MAC-CE activation timing, in accordance with certain aspects of the present disclosure. For example, operations <NUM> may be performed by a UE or base station shown in <FIG>.

Operations <NUM> begin, at <NUM>, by receiving a medium access control (MAC) control element (CE) to activate or deactivate resources or a service related to sidelink communications between two user equipments (UEs). At <NUM>, the second node determines timing for the activation or deactivation based, at least in part, on routing information for the first MAC-CE.

As noted above, activation time for a sidelink MAC-CE may be adjusted based on the link and/or route on which it is sent. In some cases, SL MAC-CEs sent on Uu may not have activation times (e.g., UL MAC-CEs, DL MAC-CEs carrying TA commands and recommended bit rates may not have activation times).

As noted above, however, many have activation time based on the time of Acknowledgment (ACK) transmission (e.g., <NUM> or N slots after Ack transmission). The counting of time in such cases either includes or excludes TA commands received during the counting. In some cases, for this purpose, the Ack transmission refers to acknowledgment of the whole TB (as opposed only to the CB/CBG carrying the MAC-CE). In general, UL MAC-CEs do not have activation times, because it is up to the gNB implementation how to respond to them.

SL MAC-CEs sent to gNB with SL-related content may be treated like Uu UL MAC-CEs (e.g., and left to gNB implementation). MAC-CEs sent to a UE over SL, or over DL (with SL-related content) may be treated like Uu DL MAC-CEs. In such cases, activation time may be based on Ack transmission. As noted above, the Ack transmissions (or delivery) time, and also the function mapping this delivery time to the activation time (eg, a delay parameter such as n milliseconds or m slots) may be different for MAC-CEs sent over SL vs over DL.

Thus, routing/relaying information may be considered when determining time for activating/deactivating MAC-CEs sent with or without relaying. In some cases, the timing may also depend on whether or not the Ack transmission is relayed.

For example, if the Ack transmission is not relayed (even though the MAC-CE itself may be relayed the Ack may be direct from final destination to original sender), activation timing may follow the (conventional) Ack transmission timing.

If the Ack is relayed, there are various options for determining the activation timing. For example, according to a first option, the timing of a first hop of the Ack route may be followed. Since the final recipient may not know the first hop, separate signaling may be used (e.g., as part of the Ack, or in DCI/MAC-CE/RRC). In some cases, the timing may be, for example, <NUM> from this timing (as in Uu).

In some cases, this type of fixed timing may not be sufficient time for the Ack to reach the final destination (depending on the number of hops). Therefore, a variable time X ms may be used instead, where the value of X depends on the number of hops. Because the number of actual hops may be dynamic (e.g., as each node may select its own preferred route), a preconfigured (or "expected") number of hops may be used instead.

According to a first option, the timing of a last hop of the Ack route may be used to determine the MAC-CE activation timing. In this case, the recipient knows the timing based on when it receives the Ack. But, in this case, the sender may not know this time. Therefore, rather than a fixed time, the activation timing may be based on a preconfigured/expected timing (based on a number of hops), which effectively becomes equivalent to the option described above with X ms.

If the Ack transmission could be relayed by multiple routes, the number of hops used to determine the X ms may be based on a rule. For example, X could be based on the shortest of the multiple routes or on the longest of the multiple routes (e.g., where length is measured in terms of the number of hops).

According to the claimed invention content of the routing information depends, at least in part, on whether the first MAC-CE is sent via the sidelink, the cellular link, or an aggregation of the sidelink and the cellular link; and timing for the activation or deactivation of the resources or the service is determined based, at least in part, on an acknowledgment of the first MAC-CE and the routing information.

Generally, where there are operations illustrated in figures, those operations may have corresponding counterpart means-plus-function components. For example, various operations shown in <FIG> may be performed by various processors shown in <FIG>, such as processors <NUM>, <NUM>, <NUM>, and/or controller/processor <NUM> of the UE <NUM>.

Claim 1:
A method of wireless communications by a first node, comprising:
preparing (<NUM>) at least a first medium access control, MAC, control element, CE, related to sidelink communications between two user equipments, UEs;
sending (<NUM>, <NUM>) the first MAC-CE on at least one of a sidelink or a cellular link, wherein the first MAC-CE is designed to activate or deactivate resources or a service;
providing (<NUM>) routing information for the first MAC-CE, wherein content of the routing information depends, at least in part, on whether the first MAC-CE is sent via the sidelink, the cellular link, or an aggregation of the sidelink and the cellular link; and
determining (<NUM>) timing for the activation or deactivation of the resources or the service based, at least in part, on an acknowledgment of the first MAC-CE and the routing information.