WO2023010277A1

WO2023010277A1 - Method and apparatus to transmit messages for bit rate query and recommendation over ue-to-network relay

Info

Publication number: WO2023010277A1
Application number: PCT/CN2021/110298
Authority: WO
Inventors: Guan-Yu Lin; Xuelong Wang; Nathan Edward Tenny; Chia-Chun Hsu
Original assignee: Mediatek Inc.
Priority date: 2021-08-03
Filing date: 2021-08-03
Publication date: 2023-02-09
Also published as: CN115915286A

Abstract

Apparatus and methods are provided to support transmission of recommended bit rate query from remote UE to the base station via L2 or L3 UE-to-NW relay, and transmission of recommended bit rate from the base station to a remote UE via L2 or L3 UE-to-NW relay. In one novel aspect, the message for recommended bit rate or recommended bit rate query is carried by a RLC SDU, e.g. through a DL-DCCH or UL-DCCH message respectively. In one aspect, the message for recommended bit rate query is transmitted via a new SL MAC CE over sidelink (when forwarded from remote UE to relay UE), and a new UL MAC CE over Uu interface (when forwarded from relay UE to the base station). In one aspect, the message for recommended bit rate is transmitted via a new DL MAC CE over Uu interface (when sent from the base station to the relay UE), and a new SL MAC CE over sidelink (when forwarded from the remote UE to the relay UE). In one aspect, in case the recommended bit rate query or the recommended bit rate is carried by MAC CE, additional adaption layer header is added to help route the MAC CE to the correct destination (i.e. the base station or remote UE respectively).

Description

METHOD AND APPARATUS TO TRANSMIT MESSAGES FOR BIT RATE QUERY AND RECOMMENDATION OVER UE-TO-NETWORK RELAY

FIELD OF THE INVENTION

The disclosed embodiments relate generally to wireless communication, and, more particularly, to enable a remote UE to report the desired bit rate to the network, and to enable the network to send the recommended bit rate to a remote UE via UE-to-Network relay.

BACKGROUND OF THE INVENTION

L2 Relay and L3 relay

To support sidelink relay, there are two kinds of UE-to-Network Relay architecture, i.e. Layer 2 relay (L2 relay) and Layer 3 relay (L3 relay) .

L3 based Sidelink Relay UE forwards data packet flow of the Remote UE as IP traffic as a general Router in data communication network. The IP traffic based forwarding is conducted in a best efforts way. For L3 UE-to-Network Relay, there exist both SLRBs over PC5 and Uu Radio Bearers to carry the QoS flows established between Remote UE and 5GC. L3 UE-to-Network Relay can support flow based mapping at SDAP layer when converting PC5 flow to Uu Flow, or vice versa, during traffic forwarding. Note that since L3 based Sidelink Relay UE works like an IP router, remote UE is transparent to the base station, i.e., the base station cannot know whether the traffic transmitted by a relay UE originates from this relay UE itself, or originates from a remote UE but is forwarded by this relay UE.

In contrast, in case of L2 based SL Relay, relaying is performed above RLC sublayer via Relay UE for both CP and UP between Remote UE and network. Uu SDAP/PDCP and RRC are terminated between Remote UE and gNB, while RLC, MAC and PHY are terminated in each link (i.e. the link between Remote UE and UE-to-Network Relay UE and the link between UE-to-Network Relay UE and the gNB) .

An adaptation layer over RLC layer is supported in Uu to perform bearer mapping and it can be also placed over PC5 to perform bearer mapping at sidelink. The adaptation layer between the Relay UE and gNB is able to differentiate between bearers (SRBs, DRBs) of a particular Remote UE. Within a Uu DRB, different Remote UEs and different bearers of the Remote UE can be indicated by additional information included in adaptation layer header. Unlike in L3 relay, in L2 relay the base station is aware of each remote UE, and thus before the relay UE starts to forward normal data traffic, the end-to-end connection between a remote UE and the base station should be established first. After establishing the RRC connection via SL relay, the remote UE can then forward data traffic based on the established bearers and the forwarding/router information carried in adaptation layer.

Recommended bit rate and Recommended bit rate query

In NR, to enhance MMTEL (multimedia telephony) IMS (IP multimedia subsystem) voice and video, RAN-assisted codec adaptation is introduced.

RAN-assisted codec adaptation provides a means for the gNB to send codec adaptation indication with recommended bit rate to assist the UE to select or adapt to a codec rate for MMTEL voice or MMTEL video. The RAN-assisted codec adaptation mechanism supports the uplink/downlink bit rate increase or decrease. For a bearer associated with configuration of MBR greater than GBR, the recommended uplink/downlink bit rate is within boundaries set by the MBR and GBR of the concerned bearer.

For uplink or downlink bit rate adaptation, gNB may send a recommended bit rate to the UE to inform the UE on the currently recommended transport bit rate on the local uplink or downlink, which the UE may use in combination with other information to adapt the bit rate, e.g. the UE may send a bit rate request to the peer UE via application layer messages, which the peer UE may use in combination with other information to adapt the codec bit rate. The recommended bit rate is in kbps at the physical layer at the time when the decision is made.

The recommended bit rate for UL and DL is conveyed as a MAC Control Element (CE) from the gNB to the UE as outlined in Figure 1.

Based on the recommended bit rate from the gNB, a UE may initiate an end-to-end bit rate adaptation with its peer (UE or MGW) . The UE may also send a query message to its local gNB to check if a bit rate recommended by its peer can be provided by the gNB. The UE is not expected to go beyond the recommended bit rate from the gNB.

The recommended bit rate query message is conveyed as a MAC CE from the UE to the gNB as outlined in Figure 2.

A prohibit timer can be configured per logical channel by the network to limit UEs sending frequent query MAC CEs. Independent prohibit timers are used for each direction (uplink and downlink) to prohibit the UE from retransmitting exactly the same query MAC CE to the gNB during the configured time.

SUMMARY OF THE INVENTION

A method is provided to support remote UE transmitting recommended bit rate query to the base station via the processing of relay UE. In one novel aspect, a new sidelink MAC CE is introduced to indicate the desired bit rate for a specific sidelink logical channel or for a specific Uu/SL radio bearer. In one novel aspect, after receiving the recommended bit rate query MAC CE, the relay UE forwards the MAC CE of this remote UE to the base station over Uu interface after adding information related to remote UE identity. In one novel aspect, the recommended bit rate query MAC CE, when received by the relay UE, is mapped to a specific uplink logical channel priority value or a specific uplink logical channel priority level, which can be used to compare priority with other UL data or UL MAC CE.

A method is also provided for a base station to transmit recommended bit rate to a remote UE. In one novel aspect, the recommended bit rate MAC CE for a remote UE is transmitted along with the identity of the remote UE from the base station to the relay UE. In one novel aspect, after relay UE receives the recommended bit rate MAC CE, the relay UE forwards the MAC CE to the targeted remote UE according to the associated identity of remote UE. In one novel aspect, the recommended bit rate MAC CE has a fixed or configured sideink logical channel priority value, and/or a related priority value comparable with other SL data and SL MAC CE.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, where like numerals indicate like components, illustrate embodiments of the invention.

Figure 1 is an exemplary signaling flow for a base station (gNB) to send recommended bit rate for an uplink or downlink logical channel to a UE.

Figure 2 is an exemplary signaling flow for a UE to send recommended bit rate query to the base station (gNB) .

Figure 3 is an exemplary signaling flow for a remote UE to send recommended bit rate query to the base station by putting the information into a RLC SDU.

Figure 4 is an exemplary signaling flow for a remote UE to send recommended bit rate query to the base station by carrying the information in the form of a MAC CE.

Figure 5 is an exemplary signaling flow for each UE to aggregate the bit rate query from itself and downstream hop UEs to the upstream hop UE/gNB in the relay path.

Figure 6 is an exemplary signaling flow for the base station to send recommended bit rate to a remote UE by putting the information into a RLC SDU.

Figure 7 is an exemplary signaling flow for the base station to send recommended bit rate to a remote UE by carrying the information in the form of a MAC CE.

Figure 8 is an exemplary signaling flow and corresponding MAC subPDU format for a remote UE to send an UL MAC CE to the base station, wherein the RLC header may not need to be present.

Figure 9 is an exemplary signaling flow and corresponding MAC subPDU format for the base station to send a DL MAC CE to a remote UE, wherein the RLC header may not need to be present.

Figure 10 is an exemplary signaling flow and corresponding MAC subPDU format for a source UE to send a SL MAC CE to a target UE in UE-to-UE relay, wherein the RLC header may not need to be present.

DETAILED DESCRIPTION

Reference will now be made in detail to some embodiments of the invention, examples of which are illustrated in the accompanying drawings.

MAC PDU format for transmission between remote UE and the base station in L2 relay.

Before we discuss the scheme for transmission of recommended bit rate query and recommended bite rate, we discuss a more general framework for traffic forwarding in L2 relay. To be specific, we want to address two questions: for uplink traffic, how the base station knows whether the received traffic is from a relay UE or is from specific remote UE; and for downlink traffic, how a UE knows that the received traffic is for itself or for another remote UE.

To distinguish the source of uplink traffic over Uu interface, there are several possible embodiments.

In one embodiment, traffic from the relay UE itself and traffic from the remote UEs are not allowed to be multiplexed together.

In one example of the embodiment wherein multiplexing traffic from a relay UE and remote UEs are not allowed, a relay UE uses separate UL resource to transmit UL MAC PDUs dedicated the relay UE and UL MAC PDUs dedicated for remote UEs. When the base station receives an UL MAC PDU, it can know whether the traffic is for the relay UE or for remote UEs based on the resource on which the UL MAC PDU is received. If an UL MAC PDU is received on the resource dedicated for remote traffic, the base station assumes that each MAC subPDU included in the UL MAC PDU has an adaptation layer header, which indicates the identity of the remote UE; otherwise, the base station handles the received UL MAC PDU following legacy procedure, i.e. assuming that the adaptation layer header does not exist.

In one embodiment, traffic from the relay UE itself and traffic from the remote UEs are allowed to be multiplexed together. In this embodiment, some indicator is needed to be included in each MAC subPDU, so that the base station can link each MAC subPDU to the correct source UE.

In one example of the embodiment wherein multiplexing traffic from a relay UE and remote UEs are allowed, a MAC subPDU for the relay UE (i.e. the UE who sends the UL MAC PDU via Uu) and a MAC subPDU from remote UE (i.e. via the forwarding of this relay UE) apply separate uplink LCID values. The LCID value of a MAC subPDU can be indicated the MAC subheader of the MAC subPDU, by considering the LCID field only or considering both the LCID file and the eLCID field, if exists. By this way, the base station can check the UL LCID value to know whether a MAC subPDU is from a remote UE. If yes, an adaptation layer header exists in the payload of the MAC subPDU to identify the remote UE. Otherwise, the adaptation layer header does not exist in the payload of the MAC subPDU.

In one example of the embodiment wherein multiplexing traffic from a relay UE and remote UEs are allowed, the MAC subPDU from relay and a MAC subPDU from remote UEs are distinguished by using the R bit in MAC subheader. For example, if the R bit is 0, this is the legacy case and the MAC subPDU comes from the relay UE. Otherwise, i.e. if the R bit is 1, this MAC subPDU comes from a remote UE and this this MAC subPDU further includes an adaptation layer header in its payload.

In one example of the embodiment wherein multiplexing traffic from a relay UE and remote UEs are allowed, a new MAC subheader format is introduced for UL traffic comes from a remote UE. For example, a dedicated UL LCID is reserved for UL data for relay. When gNB reads the dedicated UL LCID value, gNB knows that the MAC subheader format is different from legacy MAC subheader format. The new MAC subheader format, in addition to the first UL LCID (used to indicate that the included content is from a remote UE) , may include the second UL LCID to indicate the UL logical channel ID of UL data or the type of UL MAC CE included in the MAC payload.

In one example of the embodiment wherein multiplexing traffic from a relay UE and remote UEs are allowed, an indicator in RLC header is used to indicate whether the RLC SDU Included in the UL MAC subPDU includes the adaption layer header or not.

To distinguish the target of downlink traffic over Uu interface, there are also several possible embodiments. The embodiments and examples are same as the ones used to distinguish the source of uplink traffic over Uu interface, as we mentioned above.

Then, we discuss the case of traffic over PC5 interface.

To distinguish the source remote UE of uplink traffic over PC5 interface, the adaptation layer headers always insides in the SL MAC subPDU, and thus the relay UE can determine the routing path according to the identity of remote UE included in the adaptation layer header.

In the reverse direction, to distinguish the target remote UE of downlink traffic over PC5 interface, there are two possible implementation.

In one implementation, the adaption layer header always exists for a SL MAC subPDU regardless of whether the receiver UE is exactly the target UE or not. In this embodiment, the receiver UE uses the identity of target UE included in the adaption layer header to decide whether this SL MAC subPDU is for the receiver UE itself or is for another remote UE.

In one implementation, the adaption layer header exists in a SL MAC subPDU only when the receiver UE is not exactly the target UE. That is, the adaptation layer exists only when there is a need for the receiver UE to further forward the SL MAC subPDU.

Several examples are possible for the implementation that whether the adaptation layer exists depend on whether the receiver UE is the traffic target UE.

In one example, when a transmitter UE transmit traffic to a receiver UE via sidelink, the MAC subPDU whose target UE is the receiver UE and the MAC subPDU whose target UE is not the receiver UE cannot be multiplexed into the same SL MAC PDU. Then, there are only two cases: (1) all SL MAC subPDUs in a SL MAC PDU are for the receiver UE, and (2) no SL MAC subPDUs in a SL MAC PDU are for the receiver UE.

To distinguish the two cases, some methods could be considered. In one method, whether a SL MAC PDU is targeted at the receiver UE is indicated in SCI (e.g. the first-staged or the second-staged sidelink control information) . In one method, whether a SL MAC PDU is targeted at the receiver UE is included in the SL-SCH (sidelink shared channel) subheader of a SL MAC PDU. In a SL MAC PDU, the SL-SCH subheader is put before other SL MAC subPDU to identity essential information of this SL MAC PDU, e.g. the source ID (i.e. the identity of the transmitter UE, who sends the SL MAC PDU, for sidelink communiation) and destination ID (i.e. the identity of the receiver UE for sidelink communication) .

Another way to distinguish the two cases is that, for a receiver UE which is a remote UE but is not a relay UE, it can assume the receive SL MAC PDU does not included adaptation layer header, because there is no SL MAC PDU for it to further forward. Note that this approach is applicable only for single-hop relay scenario, and does not work for a multi-hop relay scenario, wherein a UE may simultaneously be a relay UE and a remote UE.

In another example, when a transmitter UE transmit traffic to a receiver UE via sidelink, the MAC subPDU whose target UE is the receiver UE and the MAC subPDU whose target UE is not the receiver UE can be multiplexed into the same SL MAC PDU. Several methods can be considered to indicate whether a MAC subPDU has the target UE equal to the receiver UE. In one method, the indicator is in the SL MAC subheader of each MAC subPDU. In one method, the indicator is in the SL RLC header of the SL RLC SDU of each MAC subPDU.

Transmission of Recommended bit rate query in L2 relay

In L2 relay, the base station is aware of each remote UE connecting to the base station via relay UEs.

The recommended bit rate query, aiming to enhance the QoS for MMTEL voice and video, is for an end-to-end application. Thus, to ensure good end-to-end QoS, it would be preferred that the gNB clearly knows the desired bit rate of each remote UE.

To transmit recommended bit rate query, a remote UE sends the desired bit rate to the base station via relay UE.

In one embodiment, the recommended bit rate query is carried by control signaling, e.g. via a RLC SDU over UL-DCCH. For example, the information of recommended bit rate query may be included in an existing RRC signaling such as SidelinkUEInformation or UEAssistanceInformation message, or a new RRC message, and the RRC signaling is included in a RLC SDU and to be transmitted from remote UE to the base station via the forwarding of relay UE. In this embodiment, recommended bit rate query is transmitted via dedicated signaling (i.e. same way as how a remote UE sends UL data to the base station via L2 SL relay) . An exemplary signaling for this embodiment is illustrated in Figure 3.

In one embodiment, the desired bit rate is indicated by a sidelink MAC CE (control element) . In one example, the sidelink MAC CE including the desired bit rate further indicates the traffic direction (i.e. uplink or downlink) , and the traffic flow related information such as QoS flow ID, sidelink radio bearer ID, end-to-end Uu radio bearer ID, and/or Uu/SL logical channel ID corresponding to the included desired bit rate.

In one embodiment, the desired bit rate, along with the traffic direction, and traffic flow information, is carried by a PC5-RRC message from remote UE to relay UE. In this case, the relay UE becomes aware of the desired bit rate of the remote UE, and the relay UE may forward the desired bit rate information to the gNB using the mechanisms described below.

If the desired bit rate is carried by a sidelink MAC CE, there are different ways to transmit it from remote UE to relay UE.

In one embodiment, the sidelink MAC CE for recommended bit rate query, like other sidelink MAC CE, is multiplexed into a SL MAC PDU according to the legacy LCP and multiplexing procedure.

In one embodiment, the sidelink MAC CE for recommended bit rate query is treated as a typical SL RLC SDU data. That is, a MAC subPDU is formed by adding an adaptation layer header, optionally adding an SL RLC header, and adding an MAC subheader, whose LCID value indicated in the LCID field and/or eLCID field tells the receiver that this MAC subPDU is to carry recommended bit rate query. Then, this MAC subPDU including the recommend bit rate query is forwarded from remote UE to gNB via relay UE.

After relay UE receives the recommended bit rate query, there are several ways to handle the query.

In one embodiment, if the recommended bit rate query is carried in a format of SL MAC CE without associated RLC header or adaptation layer header, the relay UE may consider the SL MAC CE as a RLC SDU. That means the relay UE adds adaptation layer header and RLC header in front of the SL MAC CE payload to form a RLC PDU, and then transmit to gNB by applying legacy Uu LCP procedure. When the RLC PDU is multiplexed into an UL MAC PDU, the MAC subheader associated with the RLC PDU for recommend bit rate query may include an UL LCID value corresponding for “recommend bit rate query MAC CE from remote UE” . For multi-hop scenario, the relay UE may package the SL MAC CE to be a SL RLC PDU, and then transmit it to the upstream relay UE by applying legacy sidelink LCP procedure. Similarly, the MAC subheader for the SL RLC SDU has a LCID to identify the content of RLC SDU as a recommended bit rate query MAC CE. In one example, the added adaptation layer header includes identity of the remote UE who initiates the query.

In one embodiment, if the recommended bit rate query is carried in a format of SL MAC CE with associated RLC header or adaptation layer header, the relay UE updates the RLC header and adaptation layer header, and then forwards the updated RLC PDU to the next hop (i.e. gNB or the upstreaming relay node) . If the relay UE forwards the RLC PDU to gNB, the MAC subheader of the RLC PDU indicates the LCID value corresponding to recommended bit rate query MAC CE from remote UE. In contrast, if the relay UE forwards the RLC PDU to the upstream relay UE, the SL MAC subheader of the RLC PDU indicates the LCID value corresponding to recommended bit rate query SL MAC CE.

Figure 4 shows the signaling flow of mentioned embodiments, i.e. transmitting recommended bit rate query via MAC CE.

In one embodiment, after receiving the recommended bit rate query from the remote UE (either as a MAC CE or as a PC5-RRC message) , the relay UE does not directly forward the query to gNB. Instead, the relay UE is triggered by the remote UE to initiate its own recommended bit rate query. In one example, the query of the relay UE may indicate/include query information from one or more remote UEs individually. In one example, the query of the relay UE may indicate the required bit rate for one or more logical channels to support query from one or more of its associated remote UEs.

For example, as illustrated in Figure 5, assume a relay UE is associated with

remote UEs

1, 2, and 3. Remote UE 1 requires 2500 kbps for UL transmission over sidelink logical channel 1, which maps to UL logical channel 1 of the relay UE. Remote UE 2 requires 2500 kbps for UL transmission over sidelink logical channel 2, which maps to UL logical channel 2 of the relay UE. Remote UE 3 requires separate 2500 kbps for UL transmission over both sidelink

logical channel

1 and 2, which maps to UL

logical channel

1 and 2 respectively. As a result, the relay UE may sends its query to gNB, indicating that 5000 kbps is required for UL logical channel 1 (2500 kbps for sidelink logical channel 1 of

remote UE

1, and 2500 kbps for sidelink logical channel 1 of remote UE 3) and 5000 kbps is required for UL logical channel 2 (2500 kbps for sidelink logical channel 2 of

remote UE

2, and 2500 kbps for sidelink logical channel 2 of remote UE 3) . In this example, the relay UE does not report the query of individual remote UE. Instead, the relay UE queries a bit rate not less than the total sum of bit rate required to support the query from all its remote UEs (and downstream relay UEs in multi-hop scenarios) . Notice that in the example, the base station just derive the “summary report” of required uplink or downlink bandwidth to support all the involved remote UEs, but has no idea about the query of each remote UE. As a result, the base station has no assistant information to update sidelink configuration for a specific remote UE.

After the base station receive query from each remote UE, the base station may have some corresponding action. For example, if a remote UE requests more uplink bit rate, the base station may schedule more uplink resource for the relay UE of the concerned remote UE to forward more data from this remote UE to the base station. Another example is that, the base station may allocate more transmission resource for the remote UE to transmit more UL data over sidelink, wherein the signaling configuring transmission resource may either be forwarded by the relay UE to the remote UE, or result in configuration signalling from the relay UE to the remote UE (for example, a PC5-RRC configuration message) to update the remote UE’s sidelink configuration.

In addition, the base station may reconfigure the configuration of logical channels on Uu and/or sidelink as a response of receiving bit rate query from remote UE.

For example, in case a remote UE requests for more uplink data rate, the base station may reconfigure the uplink logical channel of the relay UE, which is used to forward the data of the remote UE, with a higher logical channel priority or with a higher prioritized bit rate. By this way, relay UE will transmit more data coming from the remote UE whose query is received. More generally, in addition to reconfigure the uplink channel which carry the relayed traffic, the base station may also reconfigure the sidelink logical channel of each relay UE and remote UE along the routing path from remote UE to the base station, to ensure that the uplink data from the remote UE can be treated with a higher priority.

For example, in case a remote UE requests a higher downlink data rate, the base station may schedule more downlink resource to the relay UE to transmit downlink data of this remote UE.Besides, the base station may schedule more sidelink resource for each relay UE on the path from the base station to the remote UE, to ensure that sufficient sidelink resource is available to support the requested downlink data rate. In addition to ensuring sufficient resource, the base station may further configure the sidelink logical channels (e.g. increase logical channel priority or increase prioritized bit rate) which are used to forward the downlink traffic of the remote UE.

Transmission of Recommended bit rate in L2 relay

Similar to NR Uu case, the base station may send recommended bit rate to a remote UE to suggest the suitable bit rate.

In L2 relay, since gNB is aware of the existence of each remote UE, the information of recommended bit rate from gNB should be received by the remote UE.

In one embodiment, as illustrated in Figure 6, the recommended bit rate is carried by control signaling, e.g. via a RLC SDU over DL-DCCH which will then be forwarded by the relay UE over sidelink to the remote UE. For example, the information of recommended bit rate may be included in an existing RRC signaling such as RRCReconfiguration message, and the RRC signaling is included in a RLC SDU and to be transmitted from the base station to the remote UE via the forwarding of relay UE. In this embodiment, recommended bit rate is transmitted via dedicated signaling (i.e. same way as how the base station sends DL data to a remote UE via L2 SL relay) .

In one embodiment, gNB sends the indication to relay UE, which indicates the targeted UL/DL direction, the target traffic flow (e.g. identified by QoS flow ID, Uu/SL logical channel ID, or Uu/SL radio bearer ID) , and/or the targeted remote UE.

In one example, the information mentioned above is included in the payload of a MAC CE.A new MAC CE type may be specified to carry recommended bit rate to a remote UE. This MAC CE type may have its own downlink LCID value specified by the LCID field or both the LCID field and e-LCID field in the MAC subheader. In case the MAC subheader indicates the LCID value corresponding to the recommended bit rate MAC CE for a remote UE, the corresponding MAC CE payload includes the information of the remote UE, e.g. remote UE ID.

Another example for gNB to send recommended bit rate for a remote UE, is to put the information of the targeted remote UE (e.g. target remote UE ID) in the adaptation layer header, while other information mentioned above is included in the payload of a MAC CE. For example, the gNB may treat the MAC CE payload as a RLC SDU, and thus sequentially adds adaptation layer header, optionally RLC header, and MAC subheader for it to form a MAC subPDU. After relay UE receives a DL MAC PDU including the MAC subPDU, the relay UE knows that this MAC subPDU carries a recommended bit rate MAC CE towards a remote UE by checking the LCID value indicated in LCID and/or eLCID field in the MAC subheader. The relay UE then updates the RLC header (if exist and needed) and adaptation layer header (if needed) , and forwards the SL RLC SDU to the remote UE or the downstream relay UE. When multiplexing the SL RLC SDU to a SL MAC PDU, the SL MAC subheader associated with the SL RLC SDU includes an LCID value corresponding to recommended bit rate MAC CE over sidelink. Note that similar to recommended bit rate query MAC CE over sidelink, the recommended bit rate MAC CE over sidelink has its unique LCID value. Corresponding signaling is shown in Figure 7.

The remote UE ID, either carried in MAC CE payload or included in adaptation layer header, may be expressed in several forms.

In one embodiment, the remote UE ID is the L2 source ID (used for sidelink communication) of the targeted remote UE.

In one embodiment, the remote UE ID is a local ID, which may be assigned by the relay UE or by the network, to identify a specific remote UE associated with this relay UE.

In one embodiment, the remote UE ID follows the order of SL-DestinationIdentity in SL-TxResourceReqList. For example, if the remote UE is listed as the third destination UE in SL-DestinationIdentity in SL-TxResourceReqList of this relay UE, then the remote UE has remote UE ID field equal to 2 (starting from 0) in this MAC CE payload. The operation could be same as what we have when determining content of sidelink BSR MAC CE.

There are two ways for a relay UE to forward the recommended bit rate MAC CE to the remote UE.

In one embodiment, the MAC CE payload, along with the adaptation layer header, optionally the RLC header, and the MAC subheader forms a SL MAC subPDU and is sent by relay UE to the remote UE. From the LCID for the MAC subheader of the MAC subPDU, remote UE knows that this is a recommended bit rate MAC CE, and removes RLC header and adaptation layer header to read the MAC CE payload.

In one embodiment, only the MAC CE payload and the MAC subheader forms a MAC subPDU. Upon receiving the MAC subPDU, from the LCID for the MAC subheader of the MAC subPDU, remote UE knows that this is a recommended bit rate MAC CE.

Transmission of Recommended bit rate query in L3 relay

In L3 relay, remote UEs are transparent to the gNB. So, there is no need to forward the query of an individual remote UE to the gNB. Instead, each relay UE needs to guarantee that the desired bit rate of the associated remote UEs and downstream relay UEs can be satisfied.

A hop-by-hop bit rate query may happen like a chain reaction along the path from remote UE to gNB. Firstly, the remote UE sends its query to its relay UE, e.g. via a sidelink MAC CE for bit rate query as we mentioned before. After receiving the sidelink MAC CE from remote UEs, the relay UE may summarize these queries, and determine its amount of required bit rate to support query from remote UEs, and then trigger its own recommended bit rate query and send the query to the upstream relay node or to the gNB. For example, the bit rate requested by a relay UE should be no less than the total sum of bit rate requested by all its downstream relay UEs or remote UEs.

Transmission of Recommended bit rate in L3 relay

In L3 relay, since gNB is not aware of remote UEs, gNB follow legacy MAC procedure to send recommended bit rate MAC CE to the relay UE. And, after receiving the MAC CE, the relay UE distribute the bit rate to its remote UEs and its downstream relay UEs. This is a chain-based hop-by-hop process for recommended bit rate allocation starting from the base station to the end of the relay path.

MAC CE to support recommended bit rate and recommended bit rate query over sidelink

In previous description, we describe that for remote UE to send the recommend bit rate query to the gNB, a new SL MAC CE should be introduced. Here, we call it SL recommended bit rate query MAC CE since it is transmitted over sidelink.

In addition, to allow relay UE to forward a recommended bit rate from gNB to a remote UE, a new SL MAC CE should be introduced. Here, we call it SL recommended bit rate MAC CE since it is transmitted over sidelink.

There are several ways to configure the priority of the SL MAC CE for recommended bit rate query and for recommended bit rate, which is used to compare with other SL MAC CE or SL data during SL LCP procedure and during the SL MAC PDU multiplexing process.

In one embodiment, the priority of the SL MAC CE for recommended bit rate query or for recommended bit rate could be a fixed (e.g. the highest-priority sidelink logical channel priority value) or be configurable by the network.

In one embodiment, the relative priority of the SL MAC CE for recommended bit rate query or for recommended bit rate is specified. In one example, the priority of SL recommended bit rate query or SL recommended bit rate may be lower than SCCH (sidelink common control channel) data but higher than SL CSI report MAC CE. In one example, the priority of SL recommended bit rate query or SL recommended bit rate is equal to the priority of SL CSI report MAC CE. In one example, the priority of SL recommended bit rate query or SL recommended bit rate is lower than SL CSI report MAC CE but higher than STCH (sidelink traffic channel) data. In one embodiment, the priority of SL recommended bit rate query or SL recommended bit rate is lower than STCH data.

There are two ways to compare priority of SL recommended bit rate query or SL recommended bit rate MAC CE with other SL data or SL MAC CE.

In one embodiment, compare the absolute priority value first –the one with a smaller priority value has a higher priority. If they both have the same priority value, we then use the relative priority order mentioned before to determine the priority. For example, assume recommended bit rate MAC CE always have a relatively higher priority than STCH. If recommended bit rate MAC CE has a priority value 3, then in this embodiment, its priority is lower than STCH data with priority less than 3 but higher than STCH data with priority equal to or more than 3.

In one embodiment, compare the relative priority order first. If they both have the same priority order, then we compare the absolute priority value, if configured.

In one embodiment, SL recommended bit rate query MAC CE has a higher priority than SL recommended bit rate MAC CE.

In one embodiment, SL recommended bit rate query MAC CE has a lower priority than SL recommended bit rate MAC CE.

In one embodiment, SL recommended bit rate query MAC CE and SL recommended bit rate MAC CE have equivalent priority.

MAC CE to carry recommended bit rate and recommended bit rate query over Uu for a remote UE.

As mentioned before, when a relay UE forwards recommended bit rate query of a remote UE to the base station, the UL LCID included in the MAC subheader of the recommended bit rate query MAC CE from remote UE should be different from the UL LCID for legacy recommended bit rate query MAC CE. Otherwise, gNB would assume that the recommend bit rate query comes from the relay UE itself and would fail to decode the content of MAC CE payload. To distinguish the recommended bit rate query MAC CE for relay UE and for remote UE, we should assign the recommended bit rate query MAC CE for remote UE with a distinct UL LCID. Here, we call the UL MAC CE as “relay-specific recommended bit rate query” since it is used only in the SL relay scenario.

Similarly, when the base station wants to send a recommended bit rate MAC CE to a remote UE, the base station should not apply the existing LCID for recommended bit rate MAC CE in the MAC subheader. Otherwise, the relay UE would assume that the recommended bit rate MAC CE is for the relay UE itself, rather than for the remote UE. To avoid the ambiguity, we should assign the recommended bit rate MAC CE for remote UE with a distinct DL LCID. Here, we call the DL MAC CE as “relay-specific recommended bit rate” since it is used only in the SL relay scenario.

For the UL MAC CE “relay-specific recommended bit rate query” , its logical channel priority could be similar to the UL MAC CE for recommended bit rate query.

In one embodiment, the relay-specific recommended bit rate query MAC CE has a UL LCH priority lower than recommended bit rate query MAC CE, but higher than padding (Uu) BSR and padding sidelink BSR.

In one embodiment, the relay-specific recommended bit rate query MAC CE and legacy recommended bit rate query MAC CE have equivalent priority. For example, when a relay UE have both to transmit, which one has a higher priority to be multiplexed into a UL MAC PDU may be up to UE implementation.

As for the DL MAC CE for relay-specific recommended bit rate, how to handle the priority comparison with other DL MAC CE is up to network implementation.

In this invention, we propose how to deliver a UL MAC CE (recommended bit rate query MAC CE) from a remote UE to the base station, and how to deliver a DL MAC CE (recommended bit rate MAC CE) from the base station to a remote UE. The main concept is that if we want to forward a MAC CE, this MAC CE needs to add adaptation layer header for routing. And, with the addition of adaption layer header, we need additional LCID. For example, to forward a DL MAC CE, we need a new DL LCID specific for relay so that when relay UE receive the DL MAC subPDU, the relay UE knows the existence of adaptation layer header, and thus can route it correctly. For example, to forward a UL MAC CE, we need a new UL LCID specific for relay, so that when the base station receive the UL MAC CE, the base station knows that this UL MAC CE comes from a remote UE, and know the existence of adaptation layer header included in the MAC SDU.

Figure 8 and Figure 9 show the general signaling and message format to forward UL MAC CE and DL MAC CE respectively. Notice that RLC header may not be present. Or, we can say that the MAC CE payload, plus the adaptation layer header and the RLC header, forms a MAC SDU. The only difference from legacy MAC SDU is that the MAC SDU includes adaptation layer header and the PDCP PDU content is replaced by a MAC CE payload. To indicate the two differences from legacy MAC SDU, we need to apply a new LCID in either Uu or PC5 interfaces.

Actually the framework can be used to carry other UL MAC CE or DL MAC CE. For example, it would be quite useful if a remote UE can send UL BSR (buffer status report) via the forwarding of the relay UE to inform gNB of its amount of uplink data available in uplink buffer. Based on the feedback from remote UE, the base station can provide sufficient resource or higher priority along the path to forward traffic of the remote UE, if remote UE has a lot of data to transmit.

Additional application for SL MAC CE forwarding

There are a few ways to extend the application of the proposed SL MAC CE forwarding mechanism.

In one embodiment, a base station may send a DL MAC CE to all remote UEs of a relay UE, or all downstream UEs of a relay UE. For example, the base station sends a DL MAC CE to a relay UE, to query for BSR report or to query recommended bit rate. After receiving the DL MAC CE, the relay UE forwards it to all the target UEs. In one example, the relay UE may forward the DL MAC CE to each of its remote UE one by one through unicast. In one example, the relay UE may forward the DL MAC CE via groupcast or broadcast to each of its remote UE or downstream UEs.

There are some ways for a relay UE to know which UEs this DL MAC CE should be forwarded to.

In one embodiment, the identity of UEs to receive the DL MAC CE is explicitly indicated in the adaption layer header contained in the MAC subPDU carrying the DL MAC CE. As mentioned before, the identity of UEs could be the local identity, e.g. local identity equal to 3 refers to the third remote UEs of a relay UE.

In one embodiment, when a relay UE receive a specific type of DL MAC CE (e.g. with a distinct DL LCID value) , the relay UE considers itself and all its downstream UEs as the target UEs to apply the DL MAC CE. Thus, the relay UE always forwards the DL MAC CE to all its downstream UEs.

In one embodiment, when a relay UE receives a specific type of DL MAC CE (e.g. with a distinct DL LCID value) , the relay UE considers all remote UEs (i.e. there is no further downstream UE behind it) as the target UE to apply the DL MAC CE. That is, a relay UE will not apply the DL MAC CE, but just forward the DL MAC CE to the downstream UE. In contrast, a remote UE will apply the DL MAC CE after receiving the DL MAC CE forwarded from its upstream relay UE.

In one embodiment, when a relay UE receives a specific type of DL MAC CE (e.g. with a distinct DL LCID value) , the relay UE considers all downstream relay UEs as the target UE. In one example, the relay UE forward the DL MAC CE to a downstream UE only when the downstream UE is also a relay UE. In another example, the relay UE forward the DL MAC CE to each downstream UE. If the downstream UE is a relay UE as well, the downsteam UE apply the DL MAC CE. If the downstream UE is a remote UE (i.e. there is no further downstream UE behind it) , the downstream UE ignores the DL MAC CE.

In one embodiment, when a relay UE receives a specific type of DL MAC CE (e.g. with a distinct DL LCID value) , the relay UE considers all downstream relay UEs along the routing path from the base station to the destination UE (e.g. as specified in the adaptation layer header) as the UE to apply the DL MAC CE. As a result, when a relay receives the DL MAC CE, the relay UE not just forwards the DL MAC CE, but also apply the DL MAC CE.

In one embodiment, when a relay UE receives a specific type of DL MAC CE (e.g. with a distinct DL LCID value) , the relay UE considers all downstream relay UEs of the destination UE (e.g. as specified in the adaptation layer header) as the UE to apply the DL MAC CE. As a result, when a relay UE receives the DL MAC CE, if the relay UE is an upstream UE of the target UE, the relay UE forwards it to the target UE without applying it. Otherwise, the relay UE forwards the DL MAC CE to all its downstream UEs (i.e. including remote UEs only, including relay UE only, or including both remote UEs and relay UEs) .

In one embodiment, when a relay UE receives a specific type of DL MAC CE, there is an additional indicator associated with this DL MAC CE to indicate which UEs this DL MAC CE should be forwarded to. In one example, the DL MAC CE should only be forwarded towards the destination UE (e.g. as specified in the adaptation layer header) . In one example, the DL MAC CE should be forwarded to all downsteam UEs of this relay UE. In one example, the DL MAC CE should be forwarded to all downsteam UEs of this destination UE.

In one embodiment, when a relay UE receives a specific type of DL MAC CE, there is an additional indicator associated with this DL MAC CE to indicate which UE should apply the DL MAC CE. In one example, only the destination UE as indicated in the adaption layer header should apply the DL MAC CE. In one example, all relay UEs forwarding the DL MAC CE should apply it as well. In one example, all relay UE and remote UEs receiving this DL MAC CE should apply it. In one example, the destination UE indicated in the adaption layer header needs not apply the DL MAC CE, but only the downstream UEs of the destination UE should apply the DL MAC CE.

There is at least one way for a relay UE to forward DL MAC CE (or more generally, to forward DL message or any SL message) via groupcast or broadcast over sidelink to downstream UEs.

In one embodiment of transmitting DL MAC CE or downlink message via sidelink groupcast or broadcast, a specific L2 destination ID is dedicated for relay. If a remote UE receives a sidelink MAC PDU, whose source ID is the identity of its relay UE/upstream UE and whose destination ID is the specific L2 destination ID for relay, the remote UE decodes the SL MAC PDU and forwards it to upper layer. In one example, a specific/fixed L2 destination ID is dedicated for relay, so different relay UEs could use the same (fixed) L2 destination ID to send a SL MAC PDU to all its downstream UEs via groupcast. In other words, we can consider the specific/fixed L2 destination ID similar to one kind of groupcast destination ID. The difference is that groupcast destination ID is associated with a specific groupcast service, and all the receivers are interested in the groupcast service. In contrast, the specific/fiexed L2 destination ID is dedicated for relay, and all the receivers are the downstream UEs of the relay UE who transmits the SL MAC PDU. In another example, the L2 destination IDs for different relay UE to distribute messages via groupcast could be different.

In sidelink communication, when a transmitter UE has traffic for different receiver UEs, traffic for different receiver UEs should be transmitted via different SL MAC PDU. This ensures that a receiver UE does not need to receive traffic not for itself to receive or forward. Following this principle, for DL MAC CE forwarding, when a relay UE wants to forward multiple DL MAC CEs to different downstream/remote UEs via different next-hop UEs, the relay UE needs to transmit these DL MAC CEs towards different next-hop UEs in separate SL MAC PDU. This means a relay UE may need to transmit several very small packets for different downstream UEs. To improve transmission efficiency, we suggest relaxing the mentioned multiplexing rule, i.e. allow the relay UE to multiplex these DL MAC CEs towards different next-hop UEs into the same SL MAC PDU with some restrictions.

In one embodiment, if DL MAC CEs towards different next-hop UEs are multiplexed in the same SL MAC PDU, this SL MAC PDU cannot further include SL MAC subPDU for data, or this SL MAC PDU can further include SL MAC subPDU for data only when the size of SL MAC PDU is below a threshold. The intention is to limit the SL MAC PDU size so as to meet a balance between transmission efficiency and reception efficiency, i.e. a receiver UE should not be requested to receive a SL MAC PDU including much data not for itself.

In one embodiment, DL MAC CEs and SL MAC CEs towards different next-hop UEs are multiplexed in the same SL MAC PDU.

In this invention, we propose the framework for the network and a remote UE to exchange UL MAC CE or DL MAC CE via relay UE (s) . In fact, the framework could also be applied to the scenario of UE-to-UE relay. The only difference is that for UE-to-UE relay, we forward SL MAC CE via relay UE (s) , rather than forward UL MAC CE or DL MAC CE via relay UE (s) . For example, for a mode 2d kind of resource allocation method, a group lead can work as a resource coordinator, and allocate resource for each member UE with a single-hop or multi-hop distance based on sidelink BSR report of each member UE.

In such as UE-to-UE relay scenario, how we forward SL MAC CE is very similar to how we forward UL and DL MAC CE in a UE-to-Network relay. We can add adaptation layer header (e.gs. for routing purpose) for a SL MAC CE to form a SL MAC subPDU. Besides, we may have an indicator to indicate that this SL MAC subPDU includes a (certain type of) SL MAC CE, e.g. apply a specific sidelink LCID value in the MAC subheader of the SL MAC subPDU.

Notice that in the aforementioned UL/DL MAC CE forwarding scheme, the adaptation layer header includes the identity of the target UE (remote UE) only. This is because for uplink, the target is always the network, and thus we just need to include remote UE ID (source of the UL MAC CE) in adaption layer header. Similarly, for downlink, the source is always the network, and thus we just need to include the remote UE ID (target of the DL MAC CE) in the adaption layer header as well.

In contrast, for SL MAC CE forwarding, since both the source and the target of a SL MAC CE are UEs, the adaptation layer header needs to include both the source UE ID and the target UE ID, so that the target UE can know who initiates the SL MAC CE by the source UE ID. Figure 10 shows an exemplary signaling flow, wherein the SL MAC CE is packaged into a SL MAC subPDU, and is forwarded from source UE to the target UE based on the routing information (including source ID and target ID) of the adaptation layer header.

Claims

A method for a remote UE to transmit recommended bit rate query to the base station via layer 2 UE-to-Network relay comprising:

(Step 1) Remote UE sends the message including recommended bit rate query to a relay UE; and

(Step 2) The relay UE sends the corresponding message to the upstream relay UE. Step 2 happens only for multi-hop scenario, and step 2 may repeat several times until the message is received by a relay UE with active Uu connection.

(Step 3) The relay UE with active Uu connection sends the corresponding message to the base station.
The method of claim 1, wherein the mentioned message in STEP 1 is carried by a RLC SDU.
The method of claim 2, wherein the mentioned RLC SDU includes an existing RRC message or a new RRC message which contains the query report.
The method of claim 1, wherein the mentioned message in STEP 1 is carried by a sidelink MAC CE dedicated for recommended bit rate query for a remote UE. The new SL MAC CE has distinct LCID different from existing SCCH data, STCH data, and SL CSI report MAC CE.
The method of claim 4, wherein an adaptation layer header and optionally an SL RLC header is further added to the SL MAC CE payload and SL MAC subheader to form a SL MAC subPDU for transmission.
The method of claim 4, after a relay UE receives message including the information of recommended bit rate query from remote UE, in step 2 of claim 1, the relay UE repeats procedure in claim 5 to form a SL MAC subPDU for transmission over sidelink.
The method of claim 4, after a relay UE receives message including the information of recommended bit rate query from remote UE, in step 3 of claim 1, the relay UE adds an adaptation layer header and optionally an RLC header to form a UL MAC subPDU.
The method of claim 7, wherein the UL LCID (logical channel ID) value indicated in the MAC subheader of the mentioned UL MAC subPDU is dedicated for recommended bit rate query for remote UE.
A method for a base station to transmit recommended bit rate to a remote UE via layer 2 UE-to-Network relay comprising:

(Step 1) The base station sends the message including recommended bit rate to a relay UE; and

(Step 2) The relay UE sends the corresponding message to the downstream relay UE. Step 2 happens only for multi-hop scenario, and step 2 may repeat several times until the message is received by a relay UE with direct sidelink link to the targeted remote UE.

(Step 3) The relay UE sends the corresponding message to the remote UE.
The method of claim 9, wherein the mentioned message in STEP 1 is carried by a RLC SDU.
The method of claim 10, wherein the mentioned RLC SDU includes an existing RRC message or a new RRC message which contains the query.
The method of claim 9, wherein the mentioned message in STEP 1 is carried by a new DL MAC CE dedicated for recommended bit rate query for a remote UE.
The method of claim 12, wherein an adaptation layer header and optionally an RLC header is further added to the DL MAC CE payload and DL MAC subheader to form a DL MAC subPDU for transmission.
The method of claim 12, after a relay UE receives message including the information of recommended bit rate from the base station, in step 2 of claim 9, the relay UE add an adaptation layer header, optionally an SL RLC header, and a SL MAC subheader to the received MAC CE payload to form a SL MAC subPDU for transmission over sidelink.
The method of claim 14, wherein the SL LCID (logical channel ID) value indicated in the MAC subheader of the mentioned SL MAC subPDU is dedicated for recommended bit rate for remote UE, which is different from the LCID of existing SCCH data, STCH data, and SL MAC CE.
The method of claim 12, after a relay UE receives message including the information of recommended bit rate from the base station, in step 3 of claim 9, the relay UE forwards the received SL MAC CE, including SL MAC subheader and SL MAC CE payload, for recommended bit rate to the remote UE.
The method of claim 16, wherein an adaptation layer header and optionally a SL RLC header may be transmitted along with the SL MAC CE for recommended bit rate for remote UE.