ENHANCED RATE SIGNALING IN WIRELESS NETWORKS WITH RETRANSMISSION FUNCTION

Abstract

In cellular or other wireless networks, relay communication devices can be introduced to support an indirect network connection for remote communication devices in out-of-coverage (OoC) areas. This extends the coverage of the access device and increases the data capacity available to communication devices that may not have optimal coverage from an access device. For directly connected communication devices, mechanisms are defined for bit rate recommendation, bit rate querying, and desired bit rate indication. However, these existing mechanisms do not work for communication devices connected indirectly through a relay communication device.Therefore, it is proposed to determine a new recommendation and / or data rate limit for one or more downstream communication devices at least partially based on a logical channel identity indicated in a received recommendation and / or limit.

Description

ENHANCED RATE SIGNALING IN WIRELESS NETWORKS WITH RETRANSMISSION FUNCTION or LRznn / eznz / E / YiAi Field of invention The invention relates to the scheduling of resources in wireless networks with a relay function, such as, but not limited to, cellular networks with indirect network connections for remote communication devices (e.g., terminal devices such as user equipment (UE) that are outside network coverage). Background of the invention Many wireless communication systems use network access devices (such as base stations, Node Bs (eNB, eNodeB, gNB, gNodeB, ng-eNB, etc.), access points, or similar) to provide geographic service areas where wireless communication devices (e.g., terminal devices such as mobile stations or UEs) communicate with an access device serving a particular geographic service area where the terminal devices are located. The access devices are connected within a network that allows communication links to be established between wireless communication devices and other devices. In some circumstances, communication links are established between wireless communication devices that are close to each other.In these situations, a direct communication link between two wireless communication devices may be desirable instead of communicating through an access device. Such direct communication between communication devices is often referred to as device-to-device (D2D) or peer-to-peer (P2P) communication. The communication resources (e.g., time-frequency blocks) used for D2D or P2P communication may be a subset of the communication resources used by the communication system for communication between wireless communication devices and access devices, or they may be a different set of communication resources (e.g., unlicensed band or millimeter-wave band). q LRznn / eznz / E / YiAi An in-coverage (InC) communication device is a communication device that is within the service area of ​​an access device and is capable of communicating with that access device. An out-of-coverage (OoC) communication device is typically a communication device that is not within the service area of ​​any access device, or that is within the service area of ​​an access device but is not permitted by the access device (e.g., because it is a non-public network (NPN) access device). An OoC communication device may use an indirect network connection to an access device. Note that a communication device can also be an OoC communication device without having any connectivity. Resource scheduling can rely on an intricate interplay of multiple scheduling mechanisms and protocols working together. A scheduler (which may reside on an access device) is expected to ensure a good match between resource allocations and the recommended bit rate values ​​it sends to the communication devices. At the physical layer, resources are typically scheduled at a level of precision, i.e., per frame / subframe or even smaller resource units. At higher layers, scheduling is typically defined in terms of Quality of Service (QoS) profiles, priorities, and so on. In one particular example, 3GPP has defined a concept called the recommended bit rate at the MAC layer (see 3GPP specification TS 38.321).This rate has a default averaging window of two seconds and is provided to each UE connected to the access device, and is intended for a specific logical channel. Using this MAC mechanism allows the access device to dynamically indicate (e.g., not generating too much data for transfer) or change the balance between UEs or between certain logical channels (e.g., because another UE or channel temporarily obtains higher priority for transmitting or receiving data). In turn, this will require adherence to a higher-layer QoS profile, e.g., to guarantee a certain bit rate over a longer period for multiple UEs. The physical layer scheduler needs to take into account the bit rate recommended by the MAC.For example, a programmer could assign a persistent program to a specific communication device, meaning that this communication device is granted recurring resources periodically, allowing it to send data at a bit rate of approximately the recommended value for it. q LRznn / eznz / E / YiAi Various core network (CN) functions are provided for data rate control and limiting. However, these mechanisms do not consider data rate recommendation, control, or limiting within the context of the radio access network (RAN) and relay communication devices. For proper system operation, control mechanisms are needed in both the RAN and the CN, as each has its own unique requirements. Furthermore, in the area of ​​bit rate (data rate) recommendation for wireless networks where relay functions are enabled for communication between communication devices and the wireless network, these relay functions can allow single-hop and / or multi-hop indirect network connections for remote communication devices. A remote communication device is a communication device that connects indirectly to a core network through one or more relay functions. In such networks, a problem is that the RAN's mechanisms for recommending bit rates or data rates no longer function for indirectly connected communication devices. This means that these communication devices cannot query an access device for a bit rate recommendation and cannot receive a bit rate recommendation from the access device. As a result, an indirectly connected communication device has no information about what bit rate it might expect from the access device for a particular logical channel, the access device has no information about what bit rate an indirectly connected communication device would want to use for a particular logical channel, the access device has no way of influencing an indirectly connected communication device that is a data source to go to a lower (or higher) bit rate, and / or the indirectly connected communication device has no direct way of influencing the access device to obtain a higher bit rate should it need to and to signal what rate would be desirable. Brief description of the invention An objective of the present invention is to provide an extended rate recommendation procedure that also considers communication devices indirectly connected in wireless networks. q LRznn / eznz / E / YiAi This object is achieved by means of an apparatus as claimed in claim 1, by means of a relay communication device as claimed in claim 14, by means of a wireless communication system as claimed in claim 15, by means of a method as claimed in claim 16, and by means of a computer program product as claimed in claim 17. q LRznn / eznz / E / YiAi According to a first aspect, an apparatus is provided for controlling the scheduling of communication resources to communication devices in a relay communication device in a wireless network, where the apparatus is configured to: receive from a wireless network access device or a relay communication device upstream of the relay communication device a received data rate recommendation and / or limit that is one of an aggregated data rate recommendation and / or limit indicating a logical channel belonging to at least two communication devices or at least two logical channels of a communication device, or a data rate recommendation and / or limit for a logical channel that has been allocated to one or more downstream devices by the relay communication device; Determine a new message that includes the recommendation and / or data rate limit for one or more downstream communication devices based at least partially on a logical channel identity; and transmit the determined new message that includes the recommendation and / or data rate limit to at least one of the one or more downstream communication devices. According to a second aspect, a method is provided for controlling the scheduling of communication resources for communication devices in a wireless network, wherein the method comprises: receive from an access device or a relay communication device upstream of the wireless network a recommendation and / or received data rate limit that is one of an aggregated recommendation and / or data rate limit indicating a logical channel belonging to at least two communication devices or at least two logical channels of a communication device, or a recommendation and / or data rate limit for a logical channel that has been allocated to one or more downstream devices by the relay communication device; Determine a new recommendation and / or data rate limit for one or more downstream communication devices based at least partially on a logical channel identity; and transmit the new recommendation and / or data rate limit to at least one of the one or more downstream communication devices. According to a third aspect, a relay communication device for a wireless network is provided, comprising an apparatus of the first aspect. q LRznn / eznz / E / YiAi According to a fourth aspect, a wireless communication system is provided comprising a third aspect relay communication device and an access device, wherein the access device is configured to receive from the relay communication device a desired aggregate data rate for a logical channel, and to determine based on a logical channel identity to which downstream communication devices the desired aggregate data rate applies. Finally, in accordance with a fifth aspect, a computer program product is provided, comprising code means to produce the stages of the above method of the second aspect when executed on a computer device. Consequently, boosted rate signaling is provided for wireless networks with relay functions, which has the following advantages: 1. An indirectly connected (remote) communication device can adapt the data rate of its produced data to a rate that can be supported by the access device and also by all intermediate relay communication devices, based on a recommendation from the access device. 2. The access device or scheduler can adapt its resource scheduling to accommodate the anticipated data rates between the access device and all indirectly connected communication devices, because the expected data rates can now be signaled by these communication devices. 3. The access device can efficiently communicate about data rate recommendations with its directly connected relay communication devices in the same way that it communicates with normal directly connected non-relay communication devices. 4. Remote communication devices can send their bit rate recommendation queries and receive bit rate recommendations, just as if they were directly connected to the access device, thus avoiding additional implementation complexity on the remote communication device side. 5. The access device can perform improved scheduling and a reduction in data loss and / or retransmission buffer overflows on the network can be achieved. 6. Communication devices that produce data can optimally adapt their data generation rate to what the network can support instead of learning this rate through trial and error. or LRznn / eznz / E / YiAi It should be noted that determining a new data rate recommendation and / or limit includes updating the existing recommendation and / or limit and / or including (a copy of) a received data rate recommendation and / or limit in a new message. The value of the new recommendation and / or limit can be the same as the previous recommendation and / or limit, or it can be changed as detailed in the following scenarios. Therefore, the new recommendation and / or limit may be different, although not necessarily. One example of determining a new data rate is choosing a new data rate recommendation value based on a preconfigured policy. Another example is adding a message header to a received data rate recommendation to create the new (updated) data rate recommendation.Another example of such a case is when a message header of a received data rate recommendation is updated or partially replaced to form the new (updated) data rate recommendation. Yet another example is when additional identity information (e.g., a UE identifier) ​​or context information (e.g., validity period) is added to a received data rate recommendation to form the new (updated) data rate recommendation. Similar examples can be applied when a new data rate limit is determined by updating a received data rate limit. A further example of determining a new data rate recommendation is receiving a message that includes both a data rate recommendation and a data rate limit, and removing the data rate limit to form the new data rate recommendation.Another example is receiving a message that includes a data rate recommendation, and combining this with a received or determined data rate limit to form the new data rate recommendation and limit. q LRznn / eznz / E / YiAi If a downstream communication device receiving the new recommendation and / or limit is itself a relay communication device, the new recommendation and / or limit may be an aggregate recommendation and / or limit for that downstream communication device and all its downstream communication devices (e.g., successors). Assigning a logical channel to one or more downstream devices via the relay communication device can be accomplished using one or more of the following procedures: a) The relay communication device can allocate a new upstream logical channel, identified by a new logical channel identity (e.g., LCID), to a downstream communication device, e.g., for the indirect connection of the downstream communication device(s), and can therefore carry the data relayed to / from the downstream communication device(s). The allocation of such a new upstream logical channel can be made when the relay communication device receives a request from a downstream communication device to create a new logical channel between the downstream communication device and the relay communication device (e.g., through a request for (in)direct communication for relay purposes), or receives a logical channel identity (e.g.,A logical channel identity (LCID) or a logical channel identity mapping related to one or more logical channels that have been created between two or more downstream communication devices. This new logical channel identity may have a different identifier value than the logical channel identity received from the downstream communication device, but if it is not already in use, the logical channel identity may have the same value as the logical channel identity received from the downstream communication device. The relay communication device may maintain a mapping table that includes a mapping between the logical channel identity received from the downstream communication device and the logical channel identity used for the new upstream logical communication channel.The relay communication device can request from the upstream access device or upstream relay communication device a desired data rate for the new upstream logical channel based on the desired data rate requested and received from the downstream communication device.Optionally, you can inform the upstream access device or upstream relay communication device of the downstream communication device identifier(s) associated with a logical channel identity, the desired requested data rate received from the downstream communication device(s), a recommended (currently) data rate used for a given logical channel identity, and / or the logical channel identity(ies) to which the new logical channel identity applies, and / or a mapping of logical channel identities to other logical channel identities. Although the logical channel identity value may be the same, they are between different devices (e.g., uplink instead of sidelink).The upstream access device or the original relay communication device can send a recommendation and / or data rate limit indicating the new logical channel identity, and in doing so can trigger the relay communication device to derive / determine a new recommendation and / or data rate limit for the downstream communication device. b) The relay communication device can allocate an existing logical channel for upstream communication between the relay communication device and the upstream access device or relay communication device, identified by an existing logical channel identity to a downstream communication device, e.g., to service the indirect connection from the downstream communication device(s) and thus be able to carry the relayed data to / from the downstream communication device(s).The assignment of such an existing logical channel to a downstream communication device can be performed when the relay communication device receives a request from a downstream communication device to create a new logical channel between the downstream communication device and the relay communication device (e.g., through a (in)direct communication request for relay purposes), or receives a logical channel identity or logical channel identity mapping related to one or more logical channels that have been created between two or more downstream communication devices. The relay communication device can maintain a mapping table that indicates a mapping between the logical channel identity received from the downstream communication device and the existing logical channel identity used for the existing upstream logical channel.The mapping may also include logical channel identities of other downstream communication devices assigned to the same existing logical channel and / or receive recommended data rates for the existing logical channel identity and / or the desired data rate(s) existing for the logical channel identities of the downstream communication devices.The relay communication device may inform the upstream access device or upstream relay communication device of the logical channel identity of the existing logical channel to which the received logical channel identity was mapped, and optionally a set of downstream communication device identifier(s) related to a logical channel identity, the desired data rate requested from the downstream communication device, or an aggregate thereof, a recommended (currently) data rate and / or limit used for a given logical channel identity, and / or the logical channel identity received from the downstream communication device and / or a mapping of logical channel identities to other logical channel identities.The relay communication device can request from the upstream access device or upstream relay communication device a new desired data rate for the existing upstream logical channel based on an aggregate of the requested desired data rate received from the downstream communication device and the existing desired data rate(s) for the existing upstream logical channel (i.e., based on the logical channel identities of other downstream communication devices assigned to the same existing logical channel).The upstream access device or upstream relay communication device can send a new data rate recommendation and / or limit indicating the logical channel identity of the existing logical channel, and in doing so can trigger the relay communication device to derive / determine a new data rate recommendation for the downstream communication device. (c) The relay communication device can assign a new / different logical channel identity for a logical channel between a downstream communication device and the relay communication device, or between two downstream communication devices, if the logical channel identity is already in use for another logical channel. In this case, the relay communication device can act as a kind of central register / runner for all downstream logical channel identities. The assignment of such a new upstream logical channel can occur when the relay communication device receives a request from a downstream communication device to create a new logical channel (e.g.,Through a (in)direct communication request, it receives a logical channel identity or a logical channel identity mapping (e.g., LRznn / eznz / E / YiAi) related to one or more logical channels that have been or will be created between two or more downstream communication devices. The relay communication device may assign the logical channel identity received from the downstream communication device to a new / different logical channel identity value in case of a conflict with another logical channel identity value for another downstream communication device.To this end, the relay communication device can maintain a mapping table between the different logical channel identifiers received from the various downstream communication devices and the downstream communication device identities. This ensures that overlapping logical channel identity values ​​are not used, or it tracks, for each logical channel identifier, the downstream communication device identities that use the same logical channel identity values. This prevents tracking overlap and ensures that aggregation / disaggregation is performed correctly. If the relay communication device assigns a new / different logical channel identity value, it can request the downstream communication device to use the new / different logical channel identity value instead.The relay communication device may inform an upstream access device or an upstream relay communication device of the logical channel identity to which the received logical channel identity has been assigned and may indicate that this logical channel identity is used for downstream and / or upstream and / or sidelink communication. In addition, it may report the identifier(s) of the downstream communication device, the desired data rate requested from the downstream communication devices, or an aggregate thereof, a currently recommended data rate used for a given logical channel identity, and / or a mapping of logical channel identities to other logical channel identities.Optionally, you can report all non-overlapping logical channel identities (and their desired data rates) for all logical channels between the relay communication device and its downstream devices, and between all its downstream communication devices. Alternatively, you can report the mapping you maintain between logical channel identities and the identifiers of communication devices involved in the logical channel identified by the logical channel identity. You can also report received logical channel identities to assign logical channel identities. This allows a programming entity on an upstream access device or an upstream relay communication device to individually identify each logical channel used between all downstream communication devices.The upstream access device or upstream relay communication device can send a new data rate recommendation and / or limit for the logical channel identity assigned to the downstream communication device, and in doing so can trigger the relay communication device to derive / determine a new data rate recommendation for the downstream device. Some of the reasons why the relay communication device may need to create a new data rate recommendation for the downstream device include, e.g., because the logical channel identity assigned by the relay communication device may be different from the logical channel identity used by the downstream communication device (e.g., as stored in a mapping table to map received logical channel identities to assigned logical channel identities), or because multiple downstream communication devices report the same logical channel identities and map to the same overlapping logical channel identity value (e.g.(as stored in a mapping table to map received logical channel identities to downstream communication device identifiers), or because you have multiple downstream communication devices that you need to serve over the same upstream logical channel, or because you have multiple downstream communication devices that you need to serve over the same sidelink logical channel (e.g., if the downstream communication device being served over the sidelink logical channel is a relay communication device connected to multiple downstream communication devices), or because you are temporarily unable to achieve the desired data rate, or because you need to balance your data rates across different downstream communication devices.Determining a new data rate recommendation and / or limit may involve creating a new message, the new message including a new data rate and / or limit, and / or including a logical channel identity different from the logical channel identity of the logical channel for which the (aggregated) data rate recommendation was received from an upstream access device or relay communication device, and / or including a different destination from the message received from the upstream access device or relay communication device that contains the (aggregated) data rate recommendation. According to a first option that can be combined with any of the first five aspects above, it can be determined that the new recommendation and / or data rate limit is less than or equal to the received recommendation and / or data rate limit. This allows a portion of the added recommendation and / or data rate limit to be programmed into the relay communication device itself. It also allows, for example, distributing a received addition recommendation among multiple downstream communication devices without retaining any for the relay communication device itself. q LRznn / eznz / E / YiAi According to a second option, which can be combined with the first option or any of the first five points above, the aggregate data rate recommendation and / or limit can include indicator data that shows whether the recommendation and / or aggregate limit applies to an upstream or downstream data flow. This allows scheduling to be separated for upstream and downstream, leading to more efficient scheduling for both. By distinguishing the upstream and downstream direction (e.g., using a flag) in the recommendation and / or limit message, resource scheduling by the access device can be made more efficient and adjusted with separate upstream and downstream data flow recommendations and / or limits. According to a third option, which can be combined with the first or second option or any of the first five aspects above, a request for a desired aggregate data rate for a logical channel can be sent to the access device or the upstream relay communication device. Therefore, data rate requests from downstream remote communication devices can be collected at the relay communication device and signaled to the upstream access device or the upstream (originating) relay communication device. According to a fourth option, which can be combined with any of the first three options or any of the first five aspects above, a request for an aggregated desired data rate for a logical channel can be triggered at least partially based on at least one request for a desired data rate received from one or more downstream communication devices. This measure allows for the provision of a triggering mechanism for the aggregated desired rate request, which can be based on individual data rate requests from remote communication devices. q LRznn / eznz / E / YiAi According to a fifth option, which can be combined with any of the first four options or any of the first five aspects above, a request for a desired data rate for a logical channel can be received on the relay communication device from one or more downstream communication devices. A data rate recommendation and / or limit for the logical channel can be determined on the relay communication device based on the received request, and the determined data rate and / or limit can be used by the relay communication device to respond to the request. In this way, the relay communication device can directly respond to requests for desired data rates from remote communication devices. According to a sixth option that can be combined with any of the first through fifth options or any of the first through fifth aspects above, the relay communication device can be configured to query an internal table to a corresponding downstream communication device and / or a second logical channel identity to send an aggregated data rate recommendation and / or limit to the downstream communication device in response to a data rate recommendation and / or limit received from the access device or the relay communication device upstream of the relay communication device and indicate a first logical channel identity,Alternatively, the relay communication device can be configured to search its internal table for a second logical channel identity to send a new request for a desired data rate to the access device or an upstream relay communication device in response to a request for a desired data rate received from one or more downstream communication devices and indicating a first logical channel identity. In this way, logical channel mapping can be applied to the relay communication device in both upstream and / or downstream directions to identify the destination devices for signaling recommendations, limits, or desired data rates. According to a seventh option, which can be combined with any of the first through sixth options or any of the first through fifth aspects above, the relay communication device can be configured to create an additional logical channel in a wireless link with the access device or an upstream communication device (e.g., its original) when it determines that a new logical channel has been created for a communication link with one or more downstream communication devices. This ensures that channel mapping options are provided for all available logical channels. For example, a successor communication device can create a new logical channel and, in response to the original relay communication device, add a new logical channel to the upstream link. Since a relay can have multiple source communication devices, the new logical channel can be created to a first source communication device while aggregated recommendations are received from a second source communication device. This can be achieved, for example, by the 3GPP Dual Connectivity mode (see 3GPP Specifications 23.504, TS 38.300, and TS 37.340), which is an operating mode where a UE with multi-receiver (Rx) / transmitter (Tx) capability in RRC connected mode can be configured to use the radio resources of two separate schedulers located on two access devices, specifically the master gNB and the secondary gNB. In one example, logical channel identities (e.g., for a multiple relay topology) can be centrally assigned (e.g., by means of a root relay communication device) to ensure that they do not overlap.For this purpose, it may be necessary to communicate the identity information of the communication devices associated with each logical channel identity to the central allocation device (e.g., the root relay communication device). This provides a one-to-one channel mapping to improve signaling efficiency. This mapping (or parts of it) can also be transmitted to an upstream access device or relay communication device, enabling that device to individually identify each downstream logical channel.Possibly, this mapping can be sent together or the mapping can be extended with a desired (aggregated) recommended data rate or a recommended data rate that is used for each logical channel identity as an additional input for the upstream access device or relay communication device. According to an eighth option, which can be combined with any of the first through seventh options or any of the first through fifth aspects above, the internal table can be configured to map a logical channel identity between the relay communication device and the access device or the upstream relay communication device (e.g., its original) to a plurality of logical channel identities between the relay communication device and one or more downstream communication devices. In this way, a one-to-many channel mapping can be provided to improve signaling efficiency. or LRznn / eznz / E / YiAi Alternatively, a one-to-many mapping can be provided, which maps each logical channel identity to an identifier of the communication device that created the logical channel identity or to a set of identifiers of communication devices involved in the logical channel identified by the logical channel identity. This mapping (or parts of it) can also be transmitted to an upstream access device or relay communication device, allowing the upstream access device or relay communication device to individually identify each downstream logical channel. This mapping can possibly be sent as a whole, or it can be extended with a desired (aggregated) recommended data rate or a recommended data rate used for each logical channel identity as additional input for the upstream access device or relay communication device. According to a ninth option, which can be combined with any of the first through eighth options or any of the first through fifth aspects above, the data rate recommendation and / or limit can be transmitted using at least one media access control protocol, radio link control protocol, packet data convergence protocol, radio resource control protocol, and service data adaptation protocol. Therefore, flexible rate signaling can be provided at different protocol levels. According to a tenth option that can be combined with any of the first through ninth options or any of the first through fifth aspects above, the relay communication device can be configured to collect information about at least one desired data rate received from one or more downstream communication devices, to transmit the collected information to the upstream relay communication device or access device, to receive a recommendation and / or data rate limit received from the upstream relay communication device or access device, and to distribute the recommendation and / or data rate limit at least partially among one or more downstream communication devices using a predetermined policy.This measure allows control of the distribution of the aggregate data rate recommendation and / or limit among downstream communication devices in the relay communication device. According to an eleventh option that can be combined with any of the first through tenth options or any of the first through fifth aspects above, the relay communication device can be configured to select the default policy based on at least one of a quality indicator of a logical channel of the relay communication device, a number of communication devices downstream of a relay communication device, a number of communication devices upstream of a relay communication device, a type of downstream communication device, policy selection information received from an upstream communication device or the access device, a quality of service identifier, a network segmentation identifier, and a buffer status of the relay communication device.Therefore, a flexible distribution of the aggregate data rate recommendation and / or limit to downstream communication devices based on different criteria defined by the selected policy can be implemented. q LRznn / eznz / E / YiAi According to a twelfth option that may be combined with any of the first to the eleventh options or any of the first to fifth aspects above, the apparatus is configured to determine additional aggregate data rate recommendation and / or limit for one or more downstream communication devices triggered by the loss of a communication link between the relay communication device and at least one other communication device, or by a determination that the communication link must be stopped; and transmit the new additional data rate recommendation and / or limit to at least one downstream communication device. It is observed that the above devices can be implemented based on discrete hardware circuits with discrete hardware components, integrated chips, or arrays of chip modules, or based on signal processing devices or chips controlled by software routines or programs stored in memories, written on a computer-readable medium, or downloaded from a network, such as the Internet. It should be understood that the apparatus of claim 1, the relay communication device of claim 13, the wireless communication system of claim 14, the method of claim 15, and the computer program product of claim 16 may have similar and / or identical preferred embodiments, in particular, as defined in the dependent claims. It shall be understood that a preferred embodiment of the invention may also be any combination of the dependent claims or preceding embodiments with the respective independent claim. These and other aspects of the invention will become evident from the modalities described below and will be clarified with reference to them. Brief description of the figures or LRznn / rznz / E / YiAi In the following figures: Figure 1 schematically shows a network architecture in which the present invention can be implemented; Figure 2 schematically shows a block diagram of an access device according to various modalities; Figure 3 schematically shows a block diagram of a communication device according to various modalities; Figure 4 schematically shows a flowchart of an enhanced rate recommendation procedure according to various modalities; Figure 5 schematically shows a flowchart of a procedure for reporting the aggregate desired rate according to various modalities; Figure 6 schematically shows a network architecture with one-to-one channel mapping according to a modality; Figure 7 schematically shows a network architecture with one-to-many channel mapping according to a modality; Figure 8 schematically shows an example of a network architecture with one-to-many channel mapping, where a single logical channel indicates the data retransmitted from a group of communication devices; and Figure 9 schematically shows an example of a network architecture with one-to-one channel mapping with unique downstream logical channel identities. or LRznn / eznz / E / YiAi Detailed description of the modalities The embodiments of the present invention are described based on resource scheduling for 5G cellular networks in which UE-to-network relay functions are enabled, where 4G network elements can be incorporated into the proposed 5G solutions. Furthermore, at least some of the following embodiments are described based on a radio access technology using new 5G radio (5G NR). Specifically, the relay functions enable indirect, multi-hop network connections for remote communication devices (e.g., UEs). This is done to achieve improved coverage for communication devices and improved low-power operation, specifically for IoT communication devices. Throughout this description, the abbreviations eNB (4G terminology) and gNB (5G terminology) are intended to refer to an access device such as a cellular base station or a Wi-Fi access point. A gNB may consist of a centralized control plane unit (gNB-CU-CP), multiple centralized user plane units (gNB-CU-UP), and / or multiple distributed units (gNB of gNB). The eNB / gNB is part of the radio access network (RAN), which provides an interface to the functions in the core network (CN). The RAN is part of a wireless communication network. It involves radio access technology (RAT). Conceptually, it resides between a communication device, such as a mobile phone, a computer, or any remotely controlled machine, and provides a connection to its CN. The CN is the core part of the communication network, offering numerous services to clients interconnected through the RAN.More specifically, it directs communication streams over the communication network and possibly other networks. In the 3GPP TS 23.303 and TS 24.334 specifications for 4G networks, so-called Proximity Service Functions (ProSe) are defined to enable—among other things—connectivity for cellular communication devices (e.g., UEs) that are temporarily out of range of an access device (eNB). This particular function is called UE-to-ProSe network relay, or relay UE. The relay UE is a relay communication device that helps another out-of-context (OoC) UE (i.e., indirectly connected remote communication device) communicate with the eNB (i.e., access device) by rerouting application and network data traffic in both directions (upstream and downstream) between the OoC UE and the eNB.Local communication between the relay UE and the OoC UE is called D2D communication, sidelink communication, or PC5 communication. The abbreviation PC5 designates an interface for sidelink communication defined by ProSe and, in 5G networks, is also used to denote sidelink communication for V2X (see 3GPP specification TS 23.287 / TR 37.985). Additionally, the abbreviation UL is used for the uplink direction from the communication device (e.g., UE) to the access device (e.g., eNB, gNB), the abbreviation DL for the downlink direction from the access device (e.g., eNB, gNB) to the communication device (e.g., UE), and the abbreviation SL for sidelink communication between two or more communication devices (e.g., UE). q LRznn / eznz / E / YiAi Furthermore, the term logical channel generally denotes a layer 2 logical channel. In modalities, the logical channel may be, for example, a MAC logical channel, an RLC channel (i.e., RLC carrier), or a radio carrier implemented by a PDCP entity. Once the relay relationship is established, the out-of-context (OoC) UE connects through the relay UE and acts as the remote UE. Generally, a UE can connect to the network directly (direct network connection), or by using another UE as a relay UE (indirect network connection), or using both types of connections. The term "upstream" is used for data destined for an access device or to indicate a communication device that is closer (in terms of hop count) to an access device, while the term "downstream" is used for data flows from an access device destined for a communication device in the RAN or to indicate a communication device that is farther (in terms of hop count) from an access device.A source suffix denotes an upstream relay communication device that is used by a remote or relay communication device, and a successor suffix denotes a downstream relay communication device that connects directly (e.g., via a single wireless link) to a given relay communication device, or a downstream remote communication device that is directly using a particular relay communication device as a source device. or LRznn / eznz / E / YiAi Ongoing standardization work (e.g., the 3GPP specification TR 22.866 vl7.1.0) extends the single-hop relay concept to support communication over multiple wireless rings and the use of relays for commercial or IoT application areas. The ProSe 15 release only permits relay communication devices that provide a single hop to the network (access device), allowing a remote communication device to have an indirect network connection to the access device (e.g., eNB) and the 4G CN. 3GPP Release 17 will define how ProSe, including relays, will operate in 5G networks when using 5GS radio access technology (5G system) and / or NR. Release 18 and later aim to enable multi-hop relay for 5GS, where relay UEs can connect to other relay UEs, and so on. q LRznn / eznz / E / YiAi Furthermore, the 3GPP specifications TR 23.733 V15.1.0 and TR 36.746 v1.1.1 provide studies on architectural enhancement, e.g., to enable the operation of an IoT device (in a remote UE function) at very low power using a relay UE to connect to the wider network. Because the relay UE is physically very narrow, it can be achieved using very low power transmissions. This work also includes security, throughput, and stability improvements to ProSe. These ProSe extensions are called Enhanced ProSe (eProSe). One proposed enhancement in eProSe is an improved relay architecture that operates at the second protocol layer (L2). The new L2 architecture aims to provide end-to-end Internet Protocol (IP) and Packet Data Convergence Protocol (PDCP) packet transmissions to remote communication devices for application and / or user data. A benefit of this architecture is that remote communication devices become directly visible as a registered entity in the CN, which is relevant for monitoring and billing purposes and for improved control by the access device over the communication device. The remote UE can access all the functions of the CN and the access device (e.g., gNB) as if it were directly connected. In addition, there is also an alternative proposal for Layer 3 (L3) relay in ProSe 5G, which maintains a similar relay mechanism to that of 4G. No control plane stack for L3 relay has yet been defined in the 3GPP documents. Typically, this is left as is, since the remote UE in this solution does not have a control plane connection to the CN, but only to its relay UE. q LRznn / eznz / E / YiAi One element for implementing scheduling mechanisms could be the Radio Resource Control (RRC) protocol, which can operate end-to-end to the UEs, potentially through one or more hops, taking into account the new relay architecture mentioned earlier at the second protocol layer (i.e., L2). It can be used for non-time-critical, static, or semi-static scheduling information. In other words, it can be used to configure schedules. Here, ConfiguredGrantConfig could be an information element for uplink or sidelink scheduling. Another element for implementing scheduling mechanisms can be the Media Access Control (MAC) Control Elements (CEs), which are short elements (or Information Elements (IEs)) inserted between existing UL / DL / SL transmissions on the MAC layer, used to efficiently signal certain events, measurements, or configurations. Additional MAC CEs can be used by the access device (e.g., gNB) to control the behavior of the communication device (e.g., UE) when running various other 3GPP mechanisms such as Channel Status Information Reports (CSI), Sounding Reference Signals (SRS), or Discontinuous Receive (DRX). An additional element can be the use of Downlink Control Information (DCI), which is a short message sent on a low bit rate control channel (e.g., a physical downlink control channel (PDCCH)) with a specially perceptible modulation or encoding. This mechanism is implemented at the physical protocol layer (PHY1) and does not need to use the MAC PDU header structure. In this description, several DCI formats can be defined with different information content. Communication resources for dynamic scheduling can be indicated in the DCI. A DCI data transmission can follow the DCI message by, for example, less than 1 ms, but can be scheduled up to 4 ms in advance. For UL, scheduling can be done for the next time slot 1–2 ms in advance, but can be up to 8 ms. q LRznn / eznz / E / YiAi Another element may be the use of uplink or sidelink control information (UCI, SCI). This can include a scheduling request (SR) bit used, for example, when no communication resources are available. In response to an SR, the access device scheduler (e.g., gNB) will allocate uplink communication resources to the communication device (e.g., UE) in the future. The general resource scheduling description applies to communication devices (e.g., UE) and can also be used for multi-hop solutions. Therefore, depending on the configuration, it may be necessary to add new network elements or extend existing ones, as described below. If communication devices with single-hop or multi-hop relaying are introduced into a network, existing solutions may not be sufficient, as they may operate on a direct link between the access device (e.g., gNB) and the communication device (e.g., UE), and not necessarily on an indirect link between the access device and the communication device via a relay. As mentioned initially, the scheduler is expected to ensure a good match between resource allocations and the recommended bit rate values ​​sent to the UEs. For example, a scheduler might assign a persistent program to a specific UE, meaning that this UE is granted recurring resources periodically, allowing it to send data at a bit rate approximately equal to the value recommended to the UE by the gNB. q LRznn / eznz / E / YiAi This can be achieved, for example, by using the MAC layer CE with recommended bit rate as defined in the 3GPP TS 38.321 vlo.5.0, NR specification. This MAC layer CE can be used in the UL direction to indicate to the gNB / programmer a desired bit rate from a UE for UL data (originating from the UE) or for DL ​​data (going to the UE) for a specific Logical Channel Identifier (LCID). Furthermore, this MAC layer CE can be used in the DL direction to indicate to the gNB / programmer the recommended bit rate for UL data (originating from the UE) or for DL ​​data (going to the UE). The MAC CE with the recommended bit rate contains an LCID, which is a unique logical channel for which the request / recommendation is maintained. The LCID contains a Bit Rate field that is 6 bits long, where the bit values ​​should be interpreted according to the following table: Index Recommended bit rate value for NR [kbit / s] Index Recommended bit rate value for NR [kbit / s] 0 Note 1 32 700 1 0 33 800 2 9 34 900 3 11 35 1000 4 13 36 1100 5 17 37 1200 6 21 38 1300 7 25 39 1400 8 29 40 1500 9 32 41 1750 10 3 6 42 2000 11 40 43 2250 12 48 44 2500 13 56 45 2750 14 72 46 3000 15 8 8 47 3500 16 104 48 4000 17 120 49 4500 18 140 50 5000 19 160 51 5500 20 180 52 6000 21 200 53 6500 22 220 54 7000 23 240 55 7500 24 260 56 8000 25 280 57 Reserved 26 300 58 Reserved 27 350 59 Reserved 28 400 60 Reserved 29 450 61 Reserved 30 500 62 Reserved 31 600 63 Reserved Note 1: For the bit rate recommendation message, this index is used to indicate that no new bit rate recommendation is provided. q LRznn / eznz / E / YiAi A gNB can send the MAC CE with recommended bit rate to a UE based on its own decision - to provide a recommendation and / or a UE can consult a recommendation for a specific LCID by sending the MAC CE with recommended bit rate to the gNB, which includes a desired bit rate value. or LRznn / eznz / E / YiAi Note that in the 5G specifications, the Recommended Bit Rate MAC CE is defined more generically than in 4G. In the 4G specifications, it was specifically defined as part of the MMTEL (Multimedia Telephony) specific features in the 3GPP TS 36.331 V15.2.2 specification as MMTEL-Parameters-rl4 under the General RAN Signaling Capabilities in RRC. In 5G, it is defined in the 3GPP TS 38.331 V15.5.1 specification, NR in MACParametersCommon under the General RAN Capabilities Signaling in RRC. Using RRC, eNB / gNB signals to the UE whether the Recommended Bit Rate MAC CE is supported upstream (as a query to eNB / gNB) and / or supported downstream (as a recommendation to the UE). Figure 1 schematically shows a network architecture with relay communication devices. In the scenario shown in Figure 1, a 5G 100 core network (CN) connects to a plurality of base stations (i.e., gNB) 20 of a radio access network. The first UE 10-1s are directly or indirectly connected to one of the respective base stations 20 and act as relay UEs configured to carry upstream data from two or more downstream UE 10-Ds to the respective (service) base station 20 and downstream data from a respective base station 20 to the two or more downstream UE 10-Ds. In the case of a first UE 10-1 connected indirectly (left branch in Figure 1), at least one original UE 10-P can be connected as the relay UE between the first UE 10-1 and the respective base station 20. In addition, one or more downstream UE 10-2s are provided, each within radio range (coverage) of a respective first UE 10-1. Each UE 10-2 is capable of acting as a remote UE, a relay UE, or both, and connects directly to the respective first UE 10-1 via a wireless link and indirectly to a respective base station 20 via a relay function of the respective first UE 10-1. Marked lines indicate possible / optional links to other UEs (not shown). q LRznn / eznz / E / YiAi The core network 100 may comprise network functions such as a Network Partition Selection Function (NSSF), a User Plane Function (UPE), a Session Management Function (SMF), and an Access and Mobility Function (AMF). According to various modalities, base stations 20 or a function in the core network 100 operating through base stations 20 provide downstream data to the first UE 10-1, which includes a recommendation and / or data rate limit for a logical channel identifier (LCID). This recommendation and / or data rate limit for a single LCID contains an aggregate recommendation and / or data rate limit for at least two UEs. After receiving the aggregate recommendation and / or data rate limit, the first UE 10-1 determines, at least partially based on the associated LCID, which of the second UE 10-2 should receive a new recommendation and / or data rate limit. The first UE 10-1 then provides downstream data to at least one of the second UE 10-2, which includes a new recommendation and / or data rate limit, based at least partially on the received aggregate recommendation and / or data rate limit. In an example where multiple second UE 10-2s are provided, the new recommendation and / or data rate limit provided by the first UE 10-1 may comprise a recommendation and / or limit value that is less than the aggregate recommendation and / or limit value included in the received data. In another example, the new recommendation and / or data rate limit provided by the first UE 10-1 has a recommendation / limit value that is equal to the aggregated recommendation and / or data rate limit value included in said received data. q LRznn / eznz / E / YiAi In another example, the aggregate data rate recommendation and / or limit sent to the first UE 10-1 may include indicator data to show whether the aggregate data rate recommendation and / or limit applies to an upstream data flow or a downstream data flow. In another additional example, a UE can send an aggregate desired data rate request for an LCID to an upstream UE or to a base station 20 that is within its radio range. In another additional example, at least one of the second UE 10-2s may be arranged to transmit a desired data rate request for an LCID to a first UE 10-1, wherein the first UE 10-1 may respond to the request with a data rate recommendation and / or limit for that LCID and optionally for one or more other LCID instances. In another example, the first UE 10-1 may be configured to send a desired data rate request for an LCID to an upstream UE (e.g., the originating UE 10-P) or a base station 20 within a radio range, where the request is triggered at least partially based on at least one desired data rate request received from a second UE 10-2. The upstream desired data rate request may contain a single desired data rate for the LCID, where the single desired rate may be the sum total of multiple received desired data rates. If a lookup table of recommendation and / or limit values ​​is used in a mode, the aggregated total (sum) of the desired data rates sent to the upstream UE (e.g., the originating UE 10-P or base station 20) is an approximation (e.g., the lowest value in the table that is at least equal to or greater than the sum of the desired data rates). q LRznn / eznz / E / YiAi In one example, the first 10-1 UE (i.e., relay UE) might receive an aggregate data rate cap of, e.g., 1 Mbps from the originating 10-P UE or base station 20, and this cap might then be divided into a first cap (e.g., 500 kbps) for its own use and a second cap (e.g., 500 kbps) for use by the second 10-2 UE (i.e., successor UE). Or, in the case of a received aggregate rate recommendation, it might be used for the first 10-1 UE itself (acting as a remote UE, i.e., as a data producer / consumer itself, or acting as a normal UE as a data producer / consumer) and for a remote successor UE of the first 10-1 UE. In Figure 1, the second 10-2 UEs that have no successors can be considered as remote UEs. Of course, any distribution can be implemented (e.g., 20% for itself and 80% for a downstream UE). Furthermore, a relay UE can always be enabled to also function as a normal UE in Directly Connected mode. Additionally, a relay UE can be enabled to operate as the remote UE itself. Conversely, a remote UE can be enabled to function as a relay UE. The aggregated data rate recommendation and / or limit is interpreted by the first UE 10-1, and based on this, the first UE will generate and send a new data rate recommendation and / or limit to at least one downstream device. In this regard, it is important to distinguish between Layer 3 (L3) or higher data (e.g., NAS and user data) that can be sent to downstream UEs and newly created, untransmitted Layer 2 (L2) MAC CE elements. The operation of this creation may depend on the technical solution for the relay function. In an L2 relay architecture, the first UE 10-1 may also need to add an RLC channel (because RLC operates on a single hop) to send a new data rate recommendation. This can be activated automatically or through an RRC configuration procedure.For example, in an L2 relay solution, the first UE 10-1 may receive an RRC element rlc-BearerToAddModList or a similar element defined for the creation of the sidelink RLC channel in such a way that it will also create a Radio Link Control (RLC) channel and its associated logical MAC channel ID in response to it. Furthermore, the aggregate data rate recommendation and / or limit can be passed downstream hop by hop with at least one relay UE (e.g., the original 10-P UE on the left branch in Figure 1) to the first 10-1 UE. In such a case, the first 10-1 UE receives the aggregate data rate recommendations and / or limits from base station 20 via the relay function of at least one relay UE, which may have been modified by at least one relay UE in transit. Therefore, the first 10-1 UE may receive its aggregate data rate recommendation and / or limit directly from at least one upstream relay UE and may not recognize that it originates from base station 20. In examples, the aggregate data rate recommendation and / or limit can be created by an original 10-P UE (e.g., a MAC EC-like method with a recommended bit rate) or directly by the access device 20 (e.g., sent via RRC over multiple relay hops to the relay UE 10-1). In both cases, a message carrying the aggregate data rate recommendation and / or limit can be sent by the originating 10-P UE to the first 10-1 UE, while the message creator may differ. Figure 2 schematically shows a block diagram of a relay communication device according to various modes. o LRznn / cznz / E / YiAi It is observed that only those blocks relevant to the proposed enhanced rate recommendation function are shown in Figure 2. Other blocks have been omitted for brevity. The relay communication device in Figure 2 may correspond to the first UE 13-1 in Figure 1 or any other type of relay communication device for any wireless network that has a data rate recommendation and / or a limiting function. According to Figure 2, the relay communication device comprises a transceiver unit (TRX) 21 for transmitting and receiving wireless messages and / or other wireless signals via an antenna. Messages with new recommendations or data rate limits are created by an individual creator recommendation and / or data rate limit (IDRR / L) 24 based at least partially on a logical channel identity (ID) (e.g., LCID) derived by a channel detector (CH-ID) 22 from an aggregate recommendation and / or data rate limit received by the transceiver unit 21 from an access device (e.g., base station 20 in Figure 1) or another upstream communication device (e.g., source UE 10-P in Figure 1). In addition, the relay communication device comprises a memory with a lookup table (LUT) 25 that provides a mapping table between logical channel identifiers of parent (upstream) devices and associated logical channel identifiers of the successor (downstream) and / or remote downstream communication devices. Based on the information provided in the mapping table of lookup table 25 and the aggregate data rate obtained from the received recommendation and / or data rate limit, the individual recommendation and / or data rate limit creator 24 creates a new recommendation and / or data rate limit for at least one of the one or more downstream communication devices and transmits the new recommendation and / or data rate limit over the logical channel with the derived logical channel ID to the derived downstream communication device and / or to the downstream communication device(s) listed in the mapping table in association with the received logical channel ID. The transmission may be direct or indirect (e.g., over multiple hops and / or over a network function).The relay communication device can create the new recommendation and / or data rate limit under consideration of its own data rate and / or desired data rate limitation(s) q LRznn / eznz / E / YiAi. In this way, a boosted data rate recommendation and / or limitation can be provided, whereby directly and indirectly connected relay communication devices are considered together using the mapping table. Figure 3 schematically shows a block diagram of an access device according to various modalities. It can be seen that only those blocks relevant to the proposed enhanced recommendation function are shown in Figure 3. Other blocks have been omitted for brevity. The access device in Figure 3 may correspond to the base station (gNB) 20 in Figure 1 or any other type of access device for any wireless network that has a resource scheduling function. According to Figure 3, the access device comprises a transceiver unit (TRX) 31 for transmitting and receiving wireless messages and / or other wireless signals via an antenna. Messages containing aggregate data rate recommendations and / or limits are generated by a creator aggregate data rate recommendation and / or limit (ADR-R / L) 34 based on a logical channel identifier (e.g., LCID) derived by a channel detector (CH-ID) 32 from a desired aggregate data rate received by the transceiver unit 31 from a downstream communication device. In one example, the access device (e.g., base station (gNB) 20 in Figure 1) could also send these recommendations and / or limits on its own initiative. In this case, the channel detector 32 does not act to receive messages with desired data rates, but rather on other considerations (e.g., available resources and their regular distribution). o LRznn / eznz / E / YiAi Furthermore, the access device comprises a memory with a lookup table (LUT) 35 that provides a mapping table between logical channel identities and directly and indirectly connected downstream communication devices. The mapping table can be defined by a directly connected communication device (e.g., a relay UE). In one example, there can be multiple mapping tables stored in the access device, and each directly connected communication device has all logical channels available for communication with the access device; that is, there is no contention for logical channel identities among these communication devices. Alternatively, the mapping table can be implemented as a single table for all communication devices. In that case, e.g.There is one entry per communication device, and a logical channel identifier for a directly connected communication device can be associated with each table entry. Therefore, for example, LCID 4 can be assigned to the remote UEs {x,y,z} for the directly connected relay UE1 and can also be assigned to different remote UEs {a,b} for the directly connected relay UE2. Based on the received logical channel ID and the desired aggregate data rate, the aggregate data rate recommendation and / or limit creator 34 creates at least one aggregate data rate recommendation and / or limit for downstream communication devices based on the information in the allocation table and transmits this at least one aggregate data rate recommendation and / or limit over the logical channel with the received logical channel ID. In this way, the access device uses the allocation table to determine which communication devices to target if it sends on a particular logical channel ID to a specific directly connected relay communication device. The transmission can be direct or indirect (e.g., via multiple hops and / or through a network function). q LRznn / eznz / E / YiAi In this way, a boosted data rate recommendation and / or limitation can be provided, whereby directly and indirectly connected relay communication devices are considered together using the mapping table. The individual blocks in the block diagrams of Figures 2 and 3 can be implemented using different hardware circuits such as application-specific integrated circuits (ASICs), programmable logic arrays (PLAs), field-programmable gate arrays (FPGAs) or the like, or by digital signal processor(s) (DSPs) or other software-controlled processor circuitry. Figure 4 schematically shows a flowchart of a procedure for limiting the recommendation and / or limiting the boosted rate according to various modalities, which can be implemented in a relay communication device (e.g., the first UE 10-1 in Figure 1) of a cellular or other wireless network. q LRznn / eznz / E / YiAi In the first stage (S401), the relay communication device receives an aggregate data rate recommendation and / or limit from a source communication device or an access device. Then, in stage (S402), a logical channel identifier (e.g., LCID) is derived from the received aggregate data rate recommendation and / or limit. In stage (S403), the associated logical channel identifiers of downstream devices and / or associated remote communication devices are derived from a mapping table available on the relay communication device. Finally, in stage (S404), a new data rate recommendation and / or limit is created with the corresponding logical channel identifier.of associated logical channel based at least in part on the received aggregate data rate recommendation and / or limit and associated logical channel identifiers of downstream devices and / or associated remote communication devices derived from the mapping table under optional consideration of the relay communication device's own data rate requirements. Finally, in stage S405, the new recommendation and / or data rate limit is transmitted to one or more downstream communication devices. Figure 5 schematically shows a flowchart of an aggregate desired rate reporting procedure according to various modalities, which can be implemented on an access device (e.g., base station (gNB) 20 of Figure 1 or eNB or access point) of a cellular or other wireless network. In the first stage (S501), the access device receives a desired aggregate data rate for a logical channel from a downstream communication device. Then, in stage (S502), the logical channel identifier (e.g., LCID) of the associated logical channel is determined. In stage (S503), a mapping table is consulted to derive, from the determined logical channel identifier, the directly and indirectly connected downstream communication devices. Finally, in stage (S504), a recommendation and / or aggregate data rate limit is created, based at least in part on the received desired aggregate data rate and the directly and indirectly connected downstream communication devices. Finally, in stage S505, the aggregated data rate recommendation and / or limit created is transmitted to the associated downstream communication device, i.e., back to the requesting device. This can be a single-hop transmission over a logical channel, e.g., as in a MAC CE, or a multi-pulse potential transmission, as in, e.g., an IP packet, PDCP PDU, or RRC message. Of course, the original query for the desired data rate could have triggered a change in resource allocations so that recommendations and / or limits can also be sent to other downstream devices, not just the requesting communication device, and can also be sent to other logical channels, not just the logical channel for which the data rate recommendation and / or limit is requested. q LRznn / eznz / E / YiAi It should be noted that the flowchart stages in Figures 4 and 5 can be implemented based on one or more software routines used to control a processor or computing unit provided in the relay communication device or access device, respectively. According to various methods, the transmission of recommendations or limits for new and / or aggregated data rates and / or desired aggregated data rates can be achieved through at least one of the following options: 1. The RRC protocol can be used for end-to-end retransmission between the relay communication device and the access device in a Layer 2 relay architecture. RRC messages are transported via the PDCP protocol, through the Radio Link Control (RLC) protocol, via MAC, and through potentially multiple hops. This option offers the benefit of guaranteed transport reliability (using PDCP and relays) and the application of integrity protection. The RRC can be extended with additional messages or fields to carry recommendation values ​​and / or data rate limits. Furthermore, RRC PDUs can carry PDUs from other upper-layer protocols, such as a NAS protocol container (e.g., an NI SM container) or an IPv4 / IPv6 packet, which may contain the transmitted recommendations and / or data rate limits, or desired data rates.RRC could also be used over the sidelink, e.g., as defined in the 3GPP TS 38.331 specification, for example by using an extended RRCReconfigurationSidelink message. 2. PDCP control or data PDUs can be used, for example, by defining new PDCP messages to carry data rate recommendation values ​​and / or limits. PDCP PDUs can, in turn, carry PDUs from other higher-layer protocols, such as SDAP, IPv6, or IPv4, which may contain the transmitted data rate recommendations and / or limits or the desired data rates. For example, SDAP header data can be used by defining new SDAP header fields to carry data rate recommendations and / or limits. 3. MAC control elements (CEs) can be used. This is a lightweight method, where in some cases it is even possible to manufacture the use of unused space in a transport block, e.g., as achieved by using MAC CEs from LRznn / eznz / E / YiAi Addition BSR. You can also use extended MAC CE elements, e.g., an extended Recommended Bit Rate MAC CE, with additional fields to indicate whether the recommended bit rate relates to the downstream / upstream direction (or identifying whether it is in the uplink / downlink or sidelink direction), possible additional fields to indicate / identify the downstream UE for which the LCID value is understood, and / or the identities (e.g., L2 identities) of the downstream UEs between which the logical channel identified by the LCID value has been or will be established. A Recommended Bit Rate MAC CE can also be extended to aggregate / combine multiple LCIDs and corresponding bit rate values ​​into a single message.A recommended bit rate MAC CE can also be extended to include a single bit, or a flag, to identify whether the control element is a recommendation or a query. 4. An extended uplink or downlink control information (UCI, DCI) data format may be used, which is sent directly between a relay communication device and an access device via UL or DL ​​channels (e.g. via an uplink / downlink control physical channel (PUCCH, PDCCH) or a shared uplink / downlink physical channel (PUSCH, PDSCH)). 5. Within an extended Direct Link Control Information (SCI) data format, which can be sent by one relay communication device to another relay communication device over an SL connection. 6. Combination of the above options by, e.g., direct transmission via RRC to or from an access device and also via MAC CE through a single radio hop to an upstream or downstream direct relay communication device. Or, q LRznn / eznz / E / YiAi e.g., via MAC CE to a relay communication device that then collects one or more desired data rate reports from the successor relay communication device(s) and sends them using RRC as an aggregated desired data rate directly to the access device. Figure 6 schematically shows a network architecture with a one-to-one mapping between LCIDs in the first UE according to a modality. In this mode, a one-to-one mapping is implemented in the first UE (UE1) between an LCIDi, respectively, used between the first UE and its originating node (UEO), and an LCIDj used between the first UE (UE1) and a second UE (UE2, UE3), where the second UE can be a relay UE (UE2), a remote UE (UE3), or both (UE2). In the example in Figure 6, the second UE (UE2) includes functionalities because it also obtains its own LCID for its own data. This means that when the first UE (UE1) receives a data rate recommendation or limit from its parent node (UEO) indicating the LCIDi, it can look up the corresponding second UE (UE2 and / or UE3) and the LCIDj, which identifies a logical channel to send a new data rate index or limit to the second UE, in an internal mapping table 25. Conversely, when the first UE (UE1) receives a desired data rate request from a second UE (UE2 or UE3) indicating LCIDj, it can look up the corresponding LCIDi in mapping table 25 to use when sending a new desired data rate request to its parent node (UEO), where the desired data rate value is based, at least partially, on the value received from the second UE. When the LCID values ​​defined in 3GPP version 15 (e.g., tables 6.2.1-1 and 6.2.1-2 of specification TS 38.321 V15.7.0 of In 3GPP, the LCID for downlink and uplink communication is also used for sidelink communication; the LCID can range from 1 to 32. In this mode, the first UE (Ul, relay UE) can support a maximum of 32 second UEs, since each second UE needs at least one associated LCID for an assigned logical channel on the communication link between the first UE and its parent node (UEO) to communicate over a logical channel. More uplink and downlink LCID values ​​are defined in 3GPP version 16 (e.g., Tables 6.2.1-1 / la / lb and 6.2.l-2 / 2a / 2b of the 3GPP TS 38.321 V16.0.0 specification) through an eLCID extension mechanism (a channel range of 320 is added for (2L16 + 191)). This allows a directly connected UE (e.g., UEO) to support a very large number of successor UEs (e.g., relay UE1 or remote UEs).Since relay UEs, remote UEs, and access devices can support different versions of the related standard specification(s), some of these devices may have different restrictions on the number of LCIDs they can understand and support. For example, version 16 UEs only support LCID identifier values ​​4 through 19 for sidelink communication (see Table 6.2.4-1 of the 3GPP TS 38.321 V16.0.0 specification). If a remote UE or relay UE supports the extended number of LCIDs provided by the eLCID extension mechanism, while an upstream remote UE or relay UE supports only the limited number of LCIDs (16), a mapping can be created on a relay UE that maps the limited number of LCIDs to a larger number of LCIDs, e.g.This involves assigning a different LCID to each downstream UE that only supports a limited number of LCIDs and informing the upstream access device or relay UE of the new LCID. In this way, larger remote UEs or relay UEs can be supported in a way that is compatible with older ones. To this end, the mapping can also include, for each downstream UE, the number of LCIDs it supports or the version of the standard specification it supports (e.g., 3GPP uses q reports of LRznn / eznz / E / YiAi capability for this, more like a flag indicating supportextended:true). The assignment of a new LCID can take this into account and, for example, only allocate the reserve values ​​4 to 19 to larger downstream UEs, and reserve an extended set of values ​​for newer downstream UEs.Similarly, if the upstream UE or access device is only capable of handling LCID values ​​4 to 19, then the LCID for any upstream logical channel must be chosen from those values. When a second UE (which is a relay UE (UE2), a remote UE (UE3), or both (UE2)) creates an upstream logical channel identified by LCIDj, this means the first UE will need to create an additional logical channel with an LCIDj on the wireless link to its source node. Retransmitted data traffic from the second UE's LCIDj will then be carried over the LCIDj logical channel, and conversely, incoming retransmitted data, if forwarded, will be sent through the LCIDj to the second UE. Any received recommendation or bit rate limit for the LCIDj may then trigger the creation of a new recommendation and / or data rate limit to be sent to the second UE, indicated by an LCIDj, which specifies a recommendation or limit value that is typically equal to the received value. q LRznn / eznz / E / YiAi It should be noted that the second EU(s) may also optionally implement the proposed enhanced limitation recommendation or procedure, acting like the first EU and using a mapping table. Base station (gNB) 20 can send downstream data rate recommendations and / or limits using, for example, the recommended bit rate MAC CE, e.g., a directly connected UE (UEO). The directly connected UE receiving this recommendation and / or data rate limit can use, for example, a recommended bit rate MAC CE for an equivalent sidelink to send a new data rate recommendation to the first UE (UE1) and / or, e.g., a bit rate limit MAC CE for an equivalent sidelink to send a new data rate limit to the first UE (UE1). The first UE (UE1) receiving these recommendations and / or limits can use the recommended bit rate MAC CE for a sidelink to send new data rate recommendations to second downstream UEs (UE2, UE3). Of course, other methods can also be used as described in later modes. q LRznn / eznz / E / YiAi In one mode, base station (gNB) 20 of a relay UE can request the creation of a new radio carrier (e.g., data radio carrier, DRB) or a new RLC channel from the first UE (UE1) using an RRC reconfiguration message sent from base station 20 to the UE. This request is triggered by determining that a UE downstream of the first UE (e.g., a second UE (UE2, UE3)) requires a new logical channel and / or by determining that a new UE or remote UE downstream of the first UE (e.g., UE2, UE3, or UE4) is being added to the network topology. The use of RRC messages may require control plane connectivity between base station 20 and the first UE. The request may trigger the creation of a new logical channel, associated with the new radio carrier, in the first UE. In another scenario, the first UE requests the core network (CN) 100 to establish a new PDU session after creating a new radio carrier on the first UE, or when it determines that a downstream UE requires a new logical channel and / or that a new UE or remote UE downstream of the first UE is added to the network topology. This may require control plane connectivity between base station 20 and the first UE. If the core network accepts the new PDU session, the first UE uses this PDU session to transmit data traffic between itself and the core network. Even in another scenario, e.g., if RRC cannot be used due to a lack of control plane connectivity, the self-selection of an LCID for a sidelink communication channel by one of the involved UEs—e.g., by the first UE, the UE requiring a new logical channel, or the originating relay UE of the UE requiring a new logical channel—can be used, or any other mechanism considered in 3GPP for LCID selection for ProSe-D2D / V2X-SL communication. Another possible implementation could be for only the relaying UEs directly within the radio range of base station 20 to implement the mode using RRC messaging, while other UEs not within the radio range of base station 20 implement other modes. Therefore, a radio carrier can be created at the request of base station 20, a communication device (UE) can request a new PDU session, or a communication device can select the LCID(s) itself. These options can also be combined depending on which architectural options are implemented (L2 / L3) and other solution choices, and depending on whether the relay communication device (e.g., the first UE) is directly or indirectly connected to base station 20. Optionally, the first UE can send a lower recommendation or limit value to a second UE, instead of the same as defined above. This is useful, for example, if the first UE has limited buffer space available and needs to reduce its current buffer sizes, but still wants to serve the second UE. Or, if the first UE uses a portion of the channel's LCIDi capacity for its own purposes, which, of course, is only possible if the 3GPP specification allows for sharing a single logical channel (and the corresponding Data Radio Carrier, DRB). q LRznn / eznz / E / YiAi The proposed one-to-one mapping between the logical channels (LCIDi) of the source communication devices (P-CD) and the logical channels (LCIDj) of the successor communication devices (CH-CD) in mapping table 25 can be used, for example, for fine-grained recommended data rate control by an upstream node (e.g., the base station (gNB) 20, or another source relay UE (UE0 in Fig. 6) of the first UE (UE1)). In mapping table 25 of the first UE (UE1) in Figure 6, the originating communication device (UE0) has created logical channels P-LCID1, P-LCID3, P-LCID4 and PLCID5 to the first UE (UE1) and the first UE (UE1) as a communication device for successors has created logical channels CH-LCID3, CHLCID4, CH-LCID4' and CH-LCID9 to the second UE (UE2, UE3).According to the current state of mapping table 25, P-LCID1 is associated with CH-LCID4' and UE3, P-LCID3 is associated with CH-LCID4 and UE2, P-LCID4 is associated with CH-LCID9 and UE2, and P-LCID5 has no associated logical channel on the successor UE side (e.g., because UE1 is using this CH-LCID5 for its own data communication in a remote UE role). Note that the two CH-LCID4s indicated in Figure 6 are two distinct logical channels (a first CH-LCID4 between UE1 and UE2 and a second CH-LCID4' between UE1 and UE3). An LCID included within a MAC subheader uniquely identifies a logical channel within the scope of the combination of the source layer 2 identifier and the destination layer 2 identifier. q LRznn / eznz / E / YiAi When the upstream node (UE0) wants to recommend a data rate for a specific downstream remote UE (UE3 or UE4 in Figure 6), it can send a MAC CE with the recommended sidelink bit rate for the specific logical channel P-LCID1 (e.g., P-LCID1 in Figure 6) that is associated with the remote UE. The first UE (UE1, which is a relay UE) will then use this same recommendation value in a new recommendation sent directly to the remote UE (UE3), e.g., using a MAC CE with the recommended sidelink bit rate, if CH-LCID1 (e.g., CH-LCID4 in Figure 6) from its mapping table 25 is associated with a directly connected remote UE (UE3). Alternatively, if the remote UE (UE4) is not directly connected to the first UE but indirectly, then CH-LCID1 (e.g., CH-LCID4 in Figure 6) will be used.CH-LCID4 (in Figure 6) will point to the next downstream board (UE2) that the directly connected remote UE (UE4) uses in its data link path. The first UE (UE1) will then send the recommendation value, e.g., using a new MAC CE with the recommended bit rate for the sidelink, directly to the next-hop relay UE (UE2) on the path to the remote UE (UE4). The next-hop UE (UE2) also applies the same algorithm as the first UE (UE1), and thus the recommendation eventually reaches the destination remote UE (UE4). q LRznn / eznz / E / YiAi The preceding usage example assumes a standard mechanism by which an upstream node (e.g., a base station (gNB) or originating contact UE (OUE)) can learn the exact mapping between each LCIDi and its corresponding successor UE. This can be achieved, for example, for a base station (gNB): each remote UE linking the network registers with the base station using RRC signaling. In response, the base station uses RRC signaling to create a new data radio carrier (DRB) between itself and the remote UE, as well as any new logical channels (e.g., MAC logical channels and / or RLC channels) required on all relay UEs upstream of the new remote UE. The base station also uses the same RRC signaling to configure the mapping table (25) when necessary on all these relay UEs.In this case, the base station orchestrates the entire configuration, learning the exact mapping in this way. Alternatively, if there is no control plane connectivity between the base station and the remote UEs, this can be achieved as follows: each new remote UE joining the network registers with its parent relay UE using a form of D2D communication, which may include one-hop RRC signaling, link-local IP communication, ProSe discovery messages, or other methods. The originating relay UE then allocates new logical channel(s) to the downstream successor remote UE. The originating contact UE, if not directly connected to the base station, uses the same or similar D2D communication to inform its next upstream originating relay UE of the logical channel assignments. This next original relay UE can then create a new logical channel to the reporting relay UE.This next original can, in turn, inform the new logical channel assignments to its upstream source relay, and so on. The final link UE that connects directly to the base station can report the aggregated collected information about the identities and configurations of the logical channels to the base station using, for example, RRC signaling. It can also initiate the process of creating a new PDU session using core network functions. The core network can then send the decision to create a new PDU session to the base station (gNB) 20, through which it will also be sent to the requesting relay UE. The base station can assign a specific data radio bearer with its own LCID(s) to the relay UE for the new PDU session (a bearer can be associated with one or more LCIDs, depending on the bearer properties).In this way, the central network can know the remote UEs that are active for a given relay UE, and the base station (gNB) 20 can also know these relay UEs and knows the associated LCIDi for each one. q LRznn / eznz / E / YiAi Optionally, the first UE (UE1) can aggregate multiple desired bit-rate messages from downstream UEs, received, for example, using the MAC CE with the recommended bit rate from successor UEs or other means. The first UE reports these values ​​upstream by mapping the CH-LCIDj for which it has received a message to a corresponding upstream P-LCIDi for which a new report message with the aggregated desired bit rate will be transmitted, for example, at a future point in time. Specific trigger conditions and / or timers can govern the upstream transmission time(s). Multiple reports with desired bit-rate messages around multiple P-LCIDi can be aggregated into a single upstream message. If the first UE (UE1) does not find a match in mapping table 25 to a second downstream UE (UE2 or UE3), this could be handled as follows: If the P-LCIDi is used for first UE communications, then you can use the aggregate bit rate recommendation. or LRznn / eznz / E / YiAi In any other case, if the P-LCIDi is associated with a remote / relay UE that has already left, disconnected (e.g., due to a handover procedure), or is insensitive, the first UE (UE1) might ignore recommendation messages for this P-LCIDi for a certain period. At some point, base station (gNB) 20 might notice the new situation and request the removal of the P-LCIDi since the channel is no longer needed. Alternatively, the first UE (UE1) might return an error message report for the P-LCIDi to the upstream UE (UEO) or base station (gNB) 20 immediately or at a future point in time (e.g., included in a future / subsequent MAC PDU that is sent). Or, the first UE itself might initiate a procedure to remove or disable the logical channel indicated by the P-LCIDi and / or an associated data radio carrier.Alternatively, the first UE itself can initiate a procedure to terminate the PDU session related to P-LCIDi, if any, since this is no longer required now that the remote UE has disconnected. Optionally, the first UE can send a new data rate recommendation to one or more of its downstream remote / relay UEs that are triggered by the determination that one of its downstream UEs has exited, disconnected (e.g., on its own initiative), handed off to another source device (e.g., another UE or gNB) through a handover procedure (e.g., initiated by a gNB or the downstream UE itself), or has become unresponsive.This allows the first UE, for example, to quickly redistribute a previous recommendation received from an upstream device in a more optimal way to its remaining connected downstream devices (UEs), given the new network topology situation, without having to wait until the upstream device sends a subsequent data rate recommendation. Otherwise, if the P-LCIDi is completely unknown or unexpected, the first UE (UE1) may ignore the message. This is an error situation that is not expected to occur frequently. A second UE (UE2, UE3) can apply 3GPP power-saving methods while remaining connected to the first UE (UE1) as its originating contact. Therefore, it may happen that a second UE, to which a recommendation / limit must be supplied, needs to be available at the time the first UE wants to send the bit rate recommendation / limit. If the second UE is unavailable due to DRX, eDRX, or PSM, the first UE should cache the recommendation / limit and wait until the next event where (1) data is sent to the second UE (i.e., a MAC PDU), or (2) the second UE (i.e., the MAC PDU) starts sending new data (i.e., a MAC PDU) to the first UE and can then send the recommendation / limit. In case 1, it can be included, for example, as a MAC CE within the sent MAC PDU. In case 2, it can be included, for example, as a MAC CE in a MAC PDU sent to the second UE after the event of the MAC PDU sent by the second UE to the first UE after activation, or possibly as part of an ACK message sent by the first UE to the second UE to confirm receipt of the data or MAC PDU. If the second UE is not yet available, while a new recommendation is received by the first UE from an upstream node, then the old cached recommendation can be discarded. If the second UE is unavailable for an extended period, it may be gone, and the corresponding options described above for an unavailable second downstream UE may apply. Figure 7 schematically shows a network architecture with one-to-many mapping between logical channels (LCIDs) in the first UE (UE1) according to various modalities. q LRznn / eznz / E / YiAi For this mode, the previous mode in Figure 6 can be taken as a starting point. The difference now is that a one-to-many mapping is implemented in the first UE (UE1) between a PLCIDi, respectively (e.g., P-LCID1, P-LCID3, P-LCID4 and P-LCID15 in Figure 7) used between the first UE and its source node (UEO) and a CH-LCIDj (e.g., CH-LCID2, CH-LCID3, CH-LCID8, CH-LCID9, CH-LCID17, CH-LCID18, CH-LCID23 and CH-LCID29 in Figure 7) used between the first UE (UE1) and a second UE (UE2 to UE6). This implies that when the first UE (UE1) receives a data rate recommendation from its origin node (UEO) indicating P-LCIDi, it can search its internal mapping table for 25 potentially multiple corresponding second UEs and potentially multiple corresponding CH-LCIDj that identify a logical channel through which to send a new data rate recommendation. In the example in Figure 7, a single aggregate data rate recommendation received from the upstream P-LCIDI can map to five downstream UEs (UE2, UE3, UE4, UE5, and UE6) with CH-LCID8, CH-LCID17, CH-LCID23, CH-LCID2, and CH-LCID29. Then, a single P-LCIDI data rate recommendation of 3000 kbit / s can map to five downstream data rate recommendations (REC in mapping table 25) of 1000 kbit / s for CH-LCID8 to UE2, 500 kbit / s for CH-LCID17 to UE3, 500 kbit / s for CH-LCID23 to UE4, 500 kbit / s for CH-LCID2 to UE5, and 500 kbit / s for CH-LCID29 to UE6, respectively. In one example, the first of these descendant UEs (UE2) might have priority based on a quality of service (QoS) policy implemented by the first UE, as explained later. Any quality indicator from a logical channel (upstream, downstream, relay-related, non-retransmit-related, etc.) or multiple quality indicators from multiple logical channels could be used by the first UE (UE1) to implement the policy. An alternative policy could allocate more bit rate to UE2 and UE6 because these are relays with more downstream UEs (UE7, UE8), so they could potentially have a greater bandwidth requirement. o LRznn / cznz / E / YiAi In another example, a single aggregate data rate recommendation received on, or indicating, the upstream logical channel P-LCID1 could be mapped to two second UEs, the first with three downstream logical channels CH-LCID8, CH-LCID9 and CH-LCID10 and a second with one downstream logical channel CH-LCID16. Conversely, when the first UE (UE1) receives a desired data rate request from a second UE indicating CH-LCIDj, it can look up the corresponding P-LCIDi in mapping table 15 to use when sending a new desired data rate request to its source node (UE0), where the desired data rate value is at least partially based on the value received from the second UE. When a new second UE (either a relay (such as UE2 and UE6) or a remote UE (such as UE3 to UE5), or both) connects to the first UE (UE1), this mode does not require the first UE to request an additional logical channel with a new P-LCIDi on the wireless link with its source node (UEO). The retransmitted data traffic from the new second UE can, in principle, be carried over an existing logical channel (e.g., P-LCIDi) between the first UE (UE1) and its source node (UEO). Optionally, the first UE (UE1) can transmit downstream recommendation / limit values ​​to second UEs, with the sum of these values ​​being less than the aggregate recommendation / limit value received from an upstream device. This is useful, for example, if the first UE (UE1) has limited buffer space available and needs to reduce its buffer sizes, or if it needs to utilize some capacity of the same upstream P-LCIDi. As an alternative, a table mapping a bitrate ID value to an actual bitrate can be used. The sum of the recommendations sent downstream must then not exceed the aggregate recommendation value received. q LRznn / eznz / E / YiAi Optionally, the first EU (EU1) may not additionally send a downstream recommendation / limit to a second EU if that recommendation does not deviate substantially from a previous recommendation / limit sent to that same EU. In one mode, the first UE (UE1) can perform a fair distribution of the bit rate among multiple downstream UEs. For example, all relay / remote UEs (UE2 to UE8) can use the recommended sidelink bit rate MAC EC or another MAC EC in their communication with upstream and downstream nodes. Next, the first UE (UE1) can be configured to carry upstream relay-related data traffic through one or more separate logical channels, while data from the first UE (UE1) to / from the base station (gNB) 20 (not related to relay operations performed by the first UE) can be transferred using different logical channels. If the first UE (UE1) receives from its upstream node (UEO) a MAC EC with a recommended bit rate for sidelink and the included PLCIDi is a relay-related logical channel, then it first identifies the set of all downstream UEs involved that have their data flowing through this logical channel. The first UE (UE1) is assumed to have received a recommendation data rate value Vrec for this logical channel P-LCIDi. It then maps the LCID for each member of the set to a downstream CH-LCIDj (which could have the same or a different value) and sends each member a recommended MAC CE bit rate that includes a new recommendation value Vrec, where the sum over i of all the Vrec values ​​does not exceed the Vrec value. In this way, the available data rate recommendation can be distributed over the set of potentially multiple downstream UEs. The above distribution can be made fair by using a previously received desired data rate (e.g., using a recommended data rate query mechanism as described above) from each member of the set (i.e., downstream UEs) to guide the distribution of the recommended data rate. That is, a UE in the set that desires twice the data rate of another UE in the set will receive approximately twice the most recommended data rate as the other UE. Figure 8 schematically shows an example of a network architecture with a one-to-many channel mapping where a single logical channel indicates data retransmitted from a group of communication devices. In one modality of Figure 8, the first UE (UE1) sends a request for a desired aggregate data rate to base station (gNB) 20, which can respond with a recommended aggregate data rate. A policy is then used to distribute data rate recommendations to downstream UEs. This modality involves first collecting a number of desired data rates received from downstream UEs, then sending the combined amount (aggregate desired data rate) to base station (gNB) 20, and finally receiving a total recommended data rate value (aggregate data rate recommendation) from base station (gNB) 20, which is then distributed to downstream UEs using a policy. or LRznn / eznz / E / YiAi In the specific example in Figure 8, a single PLCID5 logical channel used by the first UE (UE1) carries all retransmitted data from a group of UEs consisting of all UEs downstream of the first UE (UE1). To achieve this, a mapping table 25 of the first UE (UE1) maps the P-LCID5 logical source channel to a group of all downstream UEs (UE2 to UE4) indicated by A in the mapping table. Additionally, a PLCID1 logical source channel is used for the first UE's (UE1) own data (OD). Additionally, a mapping table 25 of the source relay UE (UE0) maps the logical source channels P-LCID25, P-LCID26, and P-LCID27 for the use of the source relay UE (UE0) own data (OD), the logical channel CH-LCID5 of the dependent UE1 device, respectively, wherein the logical source channel P-LCID25 is used for the source relay UE (UE0) own data (OD). The first UE (UE1) sends an aggregated desired bit rate value upstream (indicating, e.g., a P-LCID5 logical channel), which is approximately the sum of the desired bit rates received from the multiple dependent UEs (retransmit and / or remote) that are allocated to the same P-LCID5 logical channel upstream of the first UE (UE1). q LRznn / eznz / E / YiAi The source relay UE (SUE) receives the desired aggregate bit rate value from the first UE (UE1) and sends the same value upstream to the base station (gNB) 20 as the desired aggregate bit rate for a P-LC1D26 logical channel. Base station (gNB) 20 receives the aggregate desired total bit rate message indicating P-LCID26 and, because of the LCID information contained in the message, can determine for which UE group (UE2 to UE4 enclosed as a group in Figure 8) the aggregate desired bit rate is maintained, regardless of whether the determined UEs (UE2 to UE4) are connected directly or indirectly to the first UE (UE1). Figure 9 schematically shows an example of a network architecture with unique downstream LCIDs, i.e., a data rate recommendation / limit is used per remote UE. It is observed that a mapping table 25 used by the first UE (UE1) in Figure 9 does not indicate a UE in this example. Here, the downstream LCIDs are unique values, and therefore mapping table 25 no longer needs to indicate a dependent UE by its identity. The identity of a dependent UE is derived directly from the LCID, since downstream LCIDs are unique. Mapping table 25 maps the logic source channels P-LCID1, PLCID3, P-LCID4, and P-LCID5 to the unique logic dependent channels CH-LCID4 of dependent device UE2, CH-LCID5 of dependent device UE3, and CH-LCID9 of dependent device UE2, respectively, where the logic source channel P-LCID5 is not yet mapped to any downstream logic channel. Therefore, base station (gNB) 20 can send individual data rate recommendations and / or limits to a selected remote UE (e.g., UE3) simply by choosing the correct channel (e.g., PLCID3), assuming that all traffic on that channel relates to that particular remote UE. It is observed that the case in Figure 9 is a specific subcase of the one-to-one mapping case in Figure 6. There, each relay UE has SL links configured with its dependent UEs, so it knows the L2 identity (ID) per dependent, according to the V2X sidelink solution described in the 3GPP TS 23.287 V16.2.0 specification, therefore, it can use L2 dependent UE identities in mapping table 25. q LRznn / eznz / E / YiAi In one mode, it is assumed that base station (gNB) 20 knows the complete relay network topology (e.g., based on previous channel creation, configuration, and / or commissioning procedures and / or communication device notification procedures, or the like) and that, with respect to the topology, base station (gNB) 20 knows the purpose of the different logical channels and / or radio carriers created and / or used by the UEs (e.g., purpose of relay data traffic) and their associated LCIDs. Therefore, in the example in Figure 8, base station (gNB) 20 knows that by sending an aggregated recommendation value to UE0 for logical channel P-LCID26, this value will be distributed as a new recommendation to the first UE (UE1) indicating logical channel CH-LCID5. In addition, base station (gNB) 20 also knows that the first UE (UE1) will distribute this value over its second downstream UEs (UE2 and UE3) using a selected policy, where the relay-type UE (UE2) of the second UEs can also share the aggregate data rate recommendation received from the first UE (UE1) over itself (UE2) and its dependent UE (UE4). The exact sharing method (policy) used by the first UE (UE1) may also be known to base station (gNB) 20 if the data rate distribution policy is governed by base station (gNB) 20 (e.g., via RRC configuration messages). If the policy is fixed (another option), then base station (gNB) will know the fixed policy being used. In general, a policy may depend on design details and / or be defined by a set of configuration parameters and / or rules (e.g., rules that define the actions to be taken under given conditions). These sets of configuration parameters, policies, and / or rules may be provided by one or more different network entities such as gNB, PCF (via AME), SMF, and / or by one or more local entities in the first UE, such as a Universal Integrated Circuit Card (UICC) or an application program.In some of these cases, the gNB can know the effective policy or parts of it, e.g., when the first UE communicates policy elements to the gNB or other network entities (e.g., PCF or SMF) communicate policy elements to the gNB. In other cases, the gNB cannot know the effective policy, e.g., if the active policy elements are not communicated to the gNB and are not determined by the gNB. In the case of a one-to-one mapping between the LCIDs of the logical channels in the originating relay UE (ORUE), the base station (gNB) 20 knows that a recommendation value sent to the originating relay UE (ORUE) for logical channel P-LCID26 will be sent as a new recommendation with the same recommendation value to the logical channel CH-LCID5 of an originating relay UE (ORUE) that is equal to the logical channel P-LCID5 of the first UE (ORUE1). or LRznn / eznz / E / YiAi Based on the programmer's information, the base station (gNB) 20 determines a total recommended data rate value (aggregate data rate recommendation) for the UE group (UE2 to UE4). The total recommended data rate value from the aggregated data rate recommendation is sent back to the source relay UE (UEO) as a recommended bit rate MAC EC element indicating the same P-LCID26 logical channel as indicated in the desired aggregated bit rate message. or LRznn / eznz / E / YiAi The originating relay UE (ORUE) sends a new MAC EC with the recommended bit rate for the sidelink, indicating a logical channel CH-LCID5, to the first UE (UE1). The first UE (UE1) applies a policy to distribute the recommended bit rate among the UEs (UE2 to UE4) in the UE group, as indicated by the aforementioned logical channel LCID5. This may include the downstream UE(s) and the first UE (UE1) itself. The first UE (UE1) can send new recommendations only to UE2 and UE3 (i.e., its dependents). UE2 can then send another new recommendation to its dependent UE4. The policy can be applied with the objective of distributing recommendations to the entire group. The policy could be the fair sharing policy described above or any other. It can be configured by the base station (gNB) 20 or by a function in the core network. In the example above, the logical channel CH-LCID5 indicates all of its dependent UEs (A in the mapping table 25 of the first UE (UE1)). Therefore, the first UE (UE1) sends each of the dependent UEs a recommended data rate message (a MAC EC with a recommended bit rate for sidelink or another type of MAC EC) that includes a value that is approximately a specific fraction / portion of the total recommended data rate value from the aggregated data rate recommendation according to the selected policy. After the dependent UE2 receives the recommended data rate message from the first UE, it can apply a policy to allocate a specific fraction / portion of the total recommended data rate received to its dependent UE4 and allocate the remainder to itself.After that, you can send a recommended data rate message (e.g., MAC EC with recommended bit rate for sidelink or other MAC EC) that contains the data rate allocated to your dependent UE4. As mentioned earlier, an example of a policy could be to provide more data rate to a relay UE than to a remote UE, since a relay UE may need to additionally distribute the data rate budget to downstream UEs, whereas a remote-only UE does not. q LRznn / eznz / E / YiAi The modes described herein can be implemented with another MAC EC element, or a modified one, that defines a data rate limit instead of a recommendation. That is, the recommended bit rate MAC EC format can be reused as such, but it could also be defined as a different type of MAC EC, such as a bit rate limit MAC EC for sidelink or another type. The data rate limit carried by the MAC EC element can be expressed as an aggregate maximum bit rate (AMBR), e.g., per logical channel or set of logical channels, as a guaranteed flow bit rate (GFBR), a maximum flow bit rate (MFBR), or another type.It can also be expressed by an index or identifier value from which a relay UE or remote UE can derive or look up the corresponding data rate limit(s), for example, a 5G QoS Identifier (5QI), PC5 QoS Identifier (PQI), QoS Flow Identifier (QFI), or index value in a preconfigured table of limits. It can also be expressed as a combination of such an identifier value and another type of limit value, for example, a PQI value along with a relative percentage value indicating what percentage of the total bit rate limit associated with the given PQIs should be used as the data rate limit. Furthermore, the methods described herein can be implemented with both data rate recommendations and data rate limits. Therefore, both types of information can be transported in separate MAC CE elements or in a single, combined MAC CE element. Additionally, in one mode, the recommendation and / or limit can be defined as a relative value, e.g., in relation to a maximum data rate that a dependent UE can support, e.g., over a sidelink connection to a source relay UE. For example, it can be calculated similarly to the maximum DL and UL data rate supported by the UE (e.g., as defined in section 4.1.2 of the 3GPP TS 38.306 vl6.0.0 specification). The access device or the source relay UE can transmit the recommendation and / or limit to a downstream UE in an encoded form, e.g., as an indicator of a fraction or percentage of the maximum supported sidelink data rate of that downstream UE. In this case, the source relay UE can know the parameters necessary to perform the maximum sidelink data rate calculation due to its communication link with the downstream UE.The downstream EU can also calculate its own maximum sidelink data rate based on these parameters, so that it can derive the absolute recommendation and / or limit values ​​from the relative indicator values ​​received (e.g., fraction / percentage). In any of the modes described herein, a configurable policy can be implemented in the relay UE (e.g., the first UE), and additional bits can optionally be added to a MAC CE element or other transport message to select a policy (from a finite number of policies) to be applied in the relay UE. For example, the recommended MAC CE bit rate has a pair of unused bits reserved for this purpose. Alternatively, the bits can be repurposed to select a policy in the downstream relay UE to apply, where the selected policy influences the distribution of the recommended bit rate to its downstream UEs. As a further option, policies can be predefined by specification of a selected standard (e.g., 3GPP), preconfigured (e.g., in the UICC), or dynamically configured.Policies can be configured when a UE becomes a relay UE or during the operation of a relay UE. For example, policies can be configured using 5G signaled QoS rules sent to the UE via the NAS protocol. A policy or set of policies can also be sent as configuration items using the RRC protocol, as part of a System Information Block (SIB), or as a set of configuration parameters and / or rules that can be provided by one or more network entities such as PCF (via AME), gNB, or SMF. q LRznn / eznz / E / YiAi In a modification of the mode, a set of policies can also be selected based on a QoS indicator that the relay UE knows is related to the specific LCID indicated in the MAC CE element. Illustrative policies could be: distribute up to 90% of the recommended bit rate fairly among all high-priority logical channels and distribute the remaining 10% among low-priority logical channels, or use up to 40% of the recommended bit rate for yourself and distribute the remaining 60% fairly among downstream UEs. In another mode, a configurable policy can be used in the relay UE (e.g., the first UE), where the policy selection for the distribution policy when receiving a bit rate recommendation from an upstream communication device can be based on the value of a quality indicator (e.g., a 5G QoS identifier, such as the 5QI value). A quality indicator (e.g., 5QI or PQI) can be known in the relay UE for each logical channel identifier (LCID) it uses. A specific example of a quality indicator is the PC5 quality indicator (PQI) associated with each PC5 sidelink connection between a relay UE and multiple of its remote UEs.These values ​​can be used and compared together by the relay UE to select a policy whereby the remote UE with the highest priority PQI value is allocated a relatively larger share of the total data rate recommendation in cases where the total recommendation (as received by the relay UE from an upstream parent device) is insufficient to meet all the data rate requirements of the downstream remote UEs. Another specific example of a quality indicator is a NAS signaling message from the SMF to the relay UE that is sent to inform the UE of changes in QoS parameters (e.g., 5QI, GFBR, MFBR) as defined in 3GPP TS 23.501, version 17.0.0, section 5.7.2.4.1b, which can be sent in this way when notification control is enabled for a QoS flow used by the relay UE.In the relay UE, receiving a new quality indicator value can trigger the selection of a different policy so that the active policy always best matches the current QoS conditions for the upstream link of the relay UE. As an illustrative scenario and policy, a reduction in the GFBR value can trigger the relay UE to select a new policy in which a smaller relative fraction of the data rate recommendation(s) received from the upstream device(s) is propagated to its relay / remote UE(s). This is to better ensure that its own upstream data traffic can be sent as usual, i.e., without data rate reduction, at the expense of providing a lower level of service to its downstream relay / remote UE(s).The notification control mechanism described above, using NAS signaling messages from the SMF to the relay UE, can also be used if alternative QoS profile(s) (per 23.501, section 5.7.1.2a) are used for the relay UE. In this case, when the RAN determines that the current QoS can no longer be guaranteed, it can inform the SMF (which, in turn, informs the UE). Simultaneously, the RAN selects an alternative QoS profile with defined alternative QoS parameters to achieve a new QoS level for the UE that the RAN can meet. The selected alternative QoS profile will also be signaled to the UE via the SMF. The quality parameters contained in this signaling message can, in exactly the same way as described above, trigger the selection of a new policy.If at any point the RAN can again offer the original / most preferred QoS level, or a better alternative QoS level, to the relay UE, then this fact will be notified to the relay UE using the same signaling mechanism, enabling the relay UE to select a corresponding (different) policy. Alternatively, a set of alternative QoS profiles can be provisioned by the gNB, PCF / SMF, or another core network function to the relay UE, which the relay UE can use to select another QoS profile if the desired QoS can no longer be achieved due to changing conditions. The relay UE can then use the chosen alternative QoS profile to change the data rate recommendations for its downstream devices accordingly. In an additional configuration, a relay UE (e.g., the first UE) can be supplied with a table that indicates the upstream-to-downstream QoS mapping. Specifically, this can be a table with one or more entries where one entry maps an upstream 5QI quality indicator to a corresponding PQI quality indicator for downstream logical channels, and vice versa. q LRznn / eznz / E / YiAi The relay UE can then use this table to determine a desired or achievable end-to-end QoS, or its characteristics, for a particular downstream UE. This information can, in turn, be used to determine the distribution policy and / or, as part of a distribution policy, to calculate specific values ​​for downstream recommendations based on the determined end-to-end QoS characteristics. q LRznn / eznz / E / YiAi In yet another scenario, the relay UE selects a policy based on the number of communication devices downstream of a relay UE, which might be, for example, a downstream relay UE that is served by the relay UE. In this case, the relay UE might determine that this particular downstream relay UE is serving a relatively large number (Nr) of the total number of downstream communication devices (Ntot), for example, (Nr / Ntot) > 0.5. The relay UE might then decide to allocate a larger fraction (e.g., (Nr / Ntot)) of its recommended receive data rate(s) and / or budget limit(s) to that downstream relay UE.As in this example, the details of the selected policy can be generated locally by the relay UE based on locally available information, such as measured parameters, received system information and / or parameters, or locally stored policy templates. In general, the selected policy can also be chosen from multiple policy candidates that are predetermined, e.g., by a specification or implementation, generated locally as explained above, and / or preconfigured, e.g., by a network function or information stored in the UICC, and / or dynamically configured during operation, e.g., by RRC communication from the gNB. In yet another mode, the relay UE selects a policy based on a downstream communication device type.This can be a downstream device that connects directly to the relay UE via a communication link (i.e., a dependent device), or it can be a downstream device that is further downstream and therefore not directly connected to the relay UE. An example of a device type that can typically impact the selected policy is the distinction between a relay UE device type and a remote UE device type. (The latter does not act as a relay UE while simultaneously acting as a remote UE.) An advantageous policy for the relay UE is then to allocate a relatively larger fraction of its received data rate recommendation(s) and / or limits to those downstream dependent devices that are relay UE type.Since these devices are likely to serve other downstream relay UEs or remote UEs, and remote UE-type devices are not, relay UE-type devices are more likely to require a relatively higher allocation of the total available data rate to better serve their downstream devices. A further refinement of this approach would be to categorize relay UEs as serving other relay UEs, relay UEs serving only remote UEs, relay UEs not currently serving remote UEs, and remote UEs. The device types mentioned earlier in this list would typically be allocated a relatively larger proportion of the available data rate recommendation budget than the device types mentioned later in the list.Other device type classifications can also be made, for example, defining device types based on radio access technology, such as an NR-based radio device, LTE-based radio device, RedCap (reduced capacity) NR radio device, NB-IoT / LTE-M device, Wi-Fi radio device, etc. Or, distinguishing device types such as video streaming device, audio streaming device, non-streaming device, etc., based on the device's current activity. Multiple device type classifications can also be combined when implementing policy selection based on device type. Alternatively or additionally, the relay UE can receive information from the remote UE, the gNB, a core network function, or an upstream or downstream UE of the data type (e.g.,(lossless data transmission, lossy data transmission, voice call-related data, video call-related data, AR / VR-related data, bulk data, delay-sensitive data, non-delay-sensitive data, input / output data, etc.) that is expected to be transported and used to select a policy and / or to determine a data rate recommendation for one or more downstream devices and / or to determine a data rate recommendation query for one or more upstream devices. In yet another mode, the relay UE selects a policy based on a network partition identifier. This partition identifier could identify a 5G network partition to which the relay UE is currently connected for all its upstream communications. Or, it could identify a 5G network partition to which the downstream communication device (UE) is currently connected. As an example of a typical advantageous use of this selection method, a relay UE can determine (on its own or with the help of the RAN) that one of its dependent relay UEs is operating in a special network partition reserved for high-priority public services, while other downstream UEs are operating in network partitions with default priority.Based on this (high) priority, a relatively larger fraction of the recommended and / or data rate limit could be allocated to the relay UE serving the high-priority network partition. Possibly, even downstream lower-priority UEs could have their recommended and / or data rate limit set to zero to leave as much capacity as possible for the high-priority network partition devices. As another example, the network partition identifier of the relay UE to which it connects, such as LRznn / eznz / E / YiAi, can be used to select a policy. This applies if the relay UE can join different partitions at different times (e.g., a partition with two total partitions to which it can connect), based on particular circumstances (e.g., a partition may only be offered in a particular geographic region or when certain base stations are accessible).Each partition, which constitutes a different network with different priorities / QoS requirements / purposes, may wish to enforce its own rules on how a relay allocates data rate recommendations and / or limits to its downstream devices. Using the partition identifier of the currently connected network partition allows the relay UE to select the correct policy or set of policies to meet the partition's operational and performance goals. For example, depending on the specific network partition serving the remote UEs, it may be considered more or less important, requiring a policy tailored to that need. q LRznn / eznz / E / YiAi Even in another mode that can be combined with any other mode or implemented independently, a relay UE can support reflective QoS (as defined in TS 23.501). The relay UE can communicate its ability to support reflective QoS during initial registration or during PDU session setup (e.g., during the setup of a PDU session to be used for relay communication for one or more downstream UEs) or by sending a NAS message to the AMF / SMF or other core network function. If reflective QoS is enabled for use (e.g., by the SMF) for one or more QoS flows, the NGRAN and UPF are informed to include a QoS flow identifier (QFI) in each downstream message about the respective QoS flow (within the established PDU session) to the relay UE.In this mode, the relay UE can use the QFI received in a message received via the NG-RAN not only to determine a corresponding PC5 QoS flow, but also advantageously to select a data recommendation policy to apply and / or to change the data rate recommendation for one or more downstream UEs and / or send a new data rate recommendation message to one or more downstream UEs. According to the current 3GPP specifications, the reflective QoS configuration for the NG-RAN and UPE, and the QFI in each downstream message to the relay UE, are only applied when reflective QoS is used. However, it would be beneficial to always include the QFI in every downstream message from the NG-RAN to the relay UE.Unfortunately, this can lead to confusion when reflective QoS is applied to update the QoS flow settings and filters in the relay UE (which may be preconfigured by the SMF) for upstream messages. It can also lead to confusion in the NG-RAN and / or SMF / UPF and / or other core network functions regarding whether the relay UE will use reflective QoS or the preconfigured QoS settings. Therefore, to distinguish between reflective and non-reflective QoS applied by the relay UE, in this mode, the SMF can send a message (e.g., via the NAS) indicating whether reflective QoS should be applied or not, e.g., per QoS flow. Alternatively, the SMF can omit sending a reflective QoS timer value / setting to the UE even when the UE has indicated support for reflective QoS.If the reflective QoS timer information was not received by the UE, then upon receiving a message through the NG-RAN that includes a QFI value, it will not derive any new QoS flow configurations or filters and / or update any (pre)configured QoS flow configurations, filters, or QoS mappings and / or apply any default timers and / or reset a timer. As noted above, several other methods can be used to encode the data rate recommendation and / or limitation information. q LRznn / eznz / E / YiAi Examples include a MAC CE element that combines a recommended value with a limit value (e.g., maximum) or a MAC CE element that includes an integer indicating a bit rate value (e.g., kbit / s) instead of an integer category or class number. Furthermore, as explained earlier, several methods can be used to send data rate information to the relay UE (e.g., the first UE) or the remote UE. Examples include MAC CE, the PDCP protocol (which can be end-to-end from the base station (gNB) to the relay UE or a single hop, e.g., from a relay UE to a remote UE), or a single hop, e.g., from one relay UE to another relay UE), and the RRC protocol (e.g., within a newly defined configuration element, it can be end-to-end from the base station (gNB) to the relay UE or a single hop)., from a relay EU to a remote EU or from a relay EU to a relay EU). q LRznn / eznz / E / YiAi For non-retransmitting UEs, conventional procedures (such as a MAC CE recommended bit rate query procedure) can be used to decide when to send a desired (aggregated) data rate request. The timing of sending may also depend on the implementation. Examples of relay UEs (e.g., the first UE) when they send an upstream message with desired data rate request information can be: 1. Send an upstream message with data rate information as soon as at least N (N configurable) data rate messages have been received from the downstream UEs. 2. Based on timer expiration, where a timer can be started (if it is not already running) in response to a message received from a downstream UE. 3. When the combination of messages received from downstream UEs leads to a significant change in a desired uplink / downlink data rate, compared to the previously reported (e.g., last) value(s). Based on rules that combine one or more of the above options with available space in downstream data packets. Examples of relay UEs (e.g., the first UE) when sending a recommendation received from an upstream node (UE or base station (gNB)) to one or more downstream nodes can be: 1. immediately after receiving the recommendation from an upstream node; 2. based on a timer expiration; or 3. Based on rules that combine one or more of the above options with available space in downstream data packets. There may be specific formats defined for combined reports of multiple data rate queries, or combined reports of data rate recommendations, or limits, or limits and recommendations together, for multiple EUs. An example might be using the existing recommended MAC CE bit rate as defined in the 3GPP TS 38.321 V15.5.0 specification. Multiple of these can be sent in a single MAC PDU if necessary, or multiple of them can be sent distributed across multiple MAC PDUs. Alternatively, a message could consist of a list of tupias: {LCID i, UL / DL or upstream / downstream or UL / DL / SL i, Data Rate recommendation_i} Or a message could consist of a list of tupias: {UE-ID k, LCID i, UL / DL i, Data Rate recommendation i} where the UE-ID is a short identifier for a specific relay / remote UE in the RAN, or for a specific relay / remote UE downstream of the message sender (this would allow the identifiers to be encoded even shorter, in principle). Or, a message could consist of a list of tupias: {LCID i, UL / DL i, Data Rate recommendation i, Data Rate limit i} q LRznn / eznz / E / YiAi The above format examples can be wrapped in a MAC CE or transported via one of the other protocols described above. In one scenario, the base station (gNB) might decide, based on received reports, that a relay UE or remote UE needs an additional upstream relay UE beyond the existing one. Otherwise, the desired data rate for one or more crucial data streams (e.g., high-priority, real-time, or low-latency data) cannot be achieved. To meet this need, the base station (gNB) can instruct a specific relay UE or remote UE to acquire an additional source relay UE or to initiate a replacement with a new source relay UE that can provide more bandwidth (i.e., data rate). In a set of modes, the base station (gNB) and its programmer can control and / or influence a recommended data rate for a logical channel (LCID1) for at least one specific UE (e.g., UE1) that connects directly to the base station (gNB). This is triggered by receiving new information about a desired (aggregated) data rate for another logical channel (LCID2) on a UE (e.g., UE2, where UE1 may or may not be the same as UE2). The base station (gNB) or its programmer can, for example, schedule fewer resources for LCID1 and more for LCID2 if UE2 for LCID2 indicates that a higher data rate is desired, and vice versa. Conversely, they can schedule more resources for LCID1 and fewer for LCID2 if UE2 for LCID2 indicates that a lower data rate is desired / required. A related modality may be to send a lower recommended data rate than the previous one in LCID1 if UE2 for LC1D2 indicates that a higher data rate is desired there, and vice versa, or to send a higher recommended data rate than the previous one in LCID1 if UE2 for LCID2 indicates that a lower data rate is desired / required. In the examples above, the recommendations sent can be, respectively, low / high because fewer / more resources are available for LCID1 in the cases above. In an additional mode, the relaying UE (e.g., the first UE) can reduce the data rate recommendation(s) to downstream UEs when its buffer fills up above a threshold or can tailor its data rate recommendation(s) to the downstream UE(s) based on their buffer status. For example, if the total size of buffered data (upstream pending data to the base station (gNB)) exceeds a specific threshold, the relay UE can initiate a recommended data rate reduction policy for the downstream UE(s). Alternatively, the recommended data rate reduction could be specific to one or more LCIDs, depending on the upstream data buffer status for a specific upstream LCID. When the total buffer size of the relay UE has again decreased below the specified threshold, the relay UE can resume applying its original policy without any reduction recommendation(s). In some of the modes described above, a base station (gNB) initially creates a data rate recommendation and then sends it to one or more relay UEs. In this way, the data rate recommendation is filtered to the local portion of the cellular network initiated by the base station (gNB). However, other initiation mechanisms (e.g., RRC, SDAP, or PDCP) may be used for data rate recommendations and / or limits. There may also be other types of control messages from the core network, meaning they originate from any function within the core network that carries such information. These other messages can be used to transmit, for example, specific partition data limits for the uplink that a UE must adhere to, or recommendations that a UE should follow. The recommendation and / or limitation control messages sent to one or more downstream UEs may be based on the data rate recommendation / limit information received and may be sent using a different protocol than the one used to receive the recommendation / limit. or LRznn / eznz / E / YiAi For example, a Recommended Bitrate MAC EC or a Recommended Bitrate MAC EC for Sidelink could be used to send a recommended data rate value to the dependent UE(s) by the relay UE (e.g., the first UE), based on a limit sent via an Extended SDAP protocol message. In this case, a recommendation based on a limit value is sent. Downstream UEs may be out-of-control (OoC) without access to most base station and / or core network functions; for example, they may not be able to use control plane messaging to / from a base station or establish a PDU session with the core network. With this data rate recommendation solution, OoC UEs can still receive data rate recommendations indirectly through the relay UE and apply those recommendations to their upstream data. Alternatively, the relaying UE (e.g., the first UE) can send a limit value to the downstream UE(s) based on the above data rate limit information, e.g., using a newly defined sidelink bit rate limit MAC EC or similar. An additional way to potentially send a data rate limit / recommendation to a downstream UE is via the RRC protocol over the side link (SL), i.e., the PC5 interface. The following describes a mode that can be used in at least one Layer 2 (L2) or Layer 3 (L3) single-hop relay architecture for UE-to-network (U2N) relay. It defines a new MAC CE sidelink (SL-SCH) called the SLRBR, which stands for Sidelink Recommended Bitrate MAC Control Element. The SL-RBR can be assigned a new 6-bit logical channel ID (LCID) in the range 20–61, for example, 61. The SL-RBR can have a fixed size of two octets. It can include one or more of the following fields: • Q: query (1 bit): indicates whether this SL-RBR encodes a bit rate recommendation (Q=0) or is a query (Q=l) for a bit rate recommendation. The name SL-RBR hereafter denotes an SL-RBR with Q=0 and SL-RBR-Q denotes an SL-RBR with Q=I set. • LCID (6 bits): indicates a logical channel identity for which a bit rate is recommended, or for which a recommendation query is made, respectively, for the cases Q=0 and Q=1. • UL / DL (1 bit): Indicates whether this SL-RBR / SL-RBR-Q applies to an upstream (1) or downstream (0) data flow direction. • Bit rate (6 bits): An index in Table 6.1.3.20-1 of TS 38.321 V16.3.0, which encodes a bit rate value for q LRznn / eznz / E / YiAi recommendation (Q=0) or request (Q=1) respectively. The request value can be seen as a UE's preference for a bit rate, i.e., a requested rate. • X (1 bit): Applicable (1) or non-applicable (0) bit rate multiplier. The multiplier, if applicable, can be applied to the bit rate value in a similar manner to that described in TS 38.321 νAβ.3.0 section 6.1.3.20 using the same multiplication factor. This factor is configured by the gNB using an optional parameter bitRateMultiplier-rl6, which can be sent via the RRC to the UEs, including the relay UE and the remote UE. Alternatively, a new parameter bitRateMultiplierSL can be defined, specifying a different multiplier for sidelink communications. • R (1 bit): reserved bit, set to 0. Remote UE traffic is relayed over at least one specific logical channel between the relay UE and the gNB. This channel is referred to here as a proxy LCID for the remote UE. This proxy LCID is used on the Uu interface, whereas the LCID used directly by the remote UE over PC5 is a different logical channel and, therefore, may have a different Logical Channel Identifier (LCID). A proxy LCID could serve one or multiple remote UEs depending, for example, on a mapping of the LCIDs used over Uu to the LCIDs used over PC5 (and vice versa) that can be constructed by the relay UE or the gNB (e.g., as part of an adaptation layer), or depending, for example, on the configuration sent by the gNB, or on specific rules defined in 3GPP standards for logical channel selection in this case.Optionally, the proxy LCID can also serve as the relay UE itself for transporting its own data traffic to / from the gNB. In the case of an L2 relay architecture, there may be defined procedures between a remote UE, a relay UE, and a gNB for accepting a new remote UE or a relay UE and subsequently configuring the L2 RAN end-to-end connection between the remote UE and the gNB. In the case of an L3 relay architecture, there may also be defined procedures for accepting a new remote UE or a relay UE and subsequently configuring a connection between the relay UE and the gNB, and / or a connection between the relay UE and the remote UE.The configuration procedures mentioned above can be used to assign a particular LCID as a proxy LCID for a particular remote UE, or for a particular sidelink LCID associated with a particular remote UE. or LRznn / eznz / E / YiAi A relay UE serving one or more remote UEs can send an SL-RBR to one or more of its remote UE(s), triggered by specific events such as the downlink reception of the recommended MAC CE bitrate from the gNB for the proxy LCID (i.e., the logical channel identifier used in Uu), or the receipt of an SL-RBR-Q from a remote UE. Which of the served remote UEs are eligible to receive a new SL-RBR if the trigger is the downlink reception of the recommended MAC CE bitrate from the gNB is determined by the set of remote UEs associated with the particular proxy LCID value included in that MAC CE received from the gNB. Similarly, for queries, a relay UE can send an uplink MAC CE recommended bitrate query (indicating a proxy LCID) to its gNB, triggered by specific events such as a timer expiration or the receipt of an SL-RBR-Q from one or more of its remote UEs.The LCID value to include in this MAC CE sent by the relay UE to the gNB is determined by the specific triggering conditions. For example, if the trigger is based on a timer, the LCID value might be determined by the logical channel for which the triggered timer was created. Or, for example, if the trigger was SL-RBR-Q reception from a particular remote UE, then the LCID value is typically determined to be equal to the proxy LCID associated with that particular remote UE. A relay UE could use one of several policies to distribute a received recommended bit rate to a set of one or more downstream remote UEs. The gNB's recommended bit rate message may include an LC1D field, which the relay UE can use as an input parameter to execute the policy and / or select a particular stored policy. A policy can, as described herein, be set in the relay UE, pre-configured, or dynamically configured by, e.g., the gNB using, e.g., data sent via the RRC protocol to the relay UE. Typical advantageous policies for this mode and its variants are: 1. Fair distribution: The relay UE can divide the bit rate evenly among the number N of remote UEs associated with the same proxy LCID (where N can be 1). In this case, the gNB preferably recommends a rate value that is, for example, divisible by N and thus allows the encoding of the exact division result in an SL-RBR. 2. Distribution proportional to requested bit rates: The relay UE can divide the bit rate approximately in proportion to the requested bit rate of each of the N applicable remote UEs. The set of applicable UEs is typically all remote UEs that share the same proxy LCID value. If an applicable UE has not (yet) requested a bit rate using SL-RBR-Q, the relay can determine that it requires a fraction (1 / N) of the total rate recommendation, or that it requires nothing (0) until it makes an explicit request. This determination algorithm can be configurable by gNB, a default algorithm in the relay UE, or dependent on situational parameters (e.g., the number of remote UEs served, data load, etc.). 3. Distribution only to data transmission producers and / or consumers: The relay UE can track the subset of remote UEs for a particular LCID or LRznn / eznz / E / YiAi proxy that previously requested a data rate recommendation using SL-RBR. Only this subset of N members (where N can be 1) is used for further distribution of the data rate recommendation according to policy 1 above. 4. Use historical bit rates: Similar to policy 2 above, but instead of assuming that a remote UE that did not request a recommendation is using a fixed fraction, this policy uses a current historical data rate observed by the relay UE for that remote UE. This assumes that the remote UE's preference is to continue transmitting data, as it has done in the past. 5. Proportional distribution based on known quality indicators: The relay UE maintains a table that maps each downstream remote UE to a quality indicator, e.g., a QoS value such as a PQI. The relay UE divides the aggregated bitrate recommendation, preferably, so that each downstream remote UE receives at least one bitrate recommendation that meets the quality indicator, i.e., allows each remote UE to meet its QoS requirements. Alternatively or additionally, the relay UE may allocate a larger portion of the aggregated bitrate recommendation to remote UEs that have stricter QoS requirements as determined by their quality indicator, in a stricter sense, e.g., a PQI with a lower default priority level as defined by TS 23.287, or a PQI with a lower maximum packet error rate as defined by TS 23.287, or a higher bandwidth requirement. 6. Distribution adapted to the current relay load: This aspect of the policy can be combined with one of the other policies. In this case, the relay UE can reduce the calculated recommendation value in one or more remote UEs based on an indication of the current relay load, q LRznn / eznz / E / YiAi. This is an internally calculated indication that uses one or more variables to describe the load on the relay UE's resources due to its functions, which include, for example, user data transmission, user data reception, data relay operations, computation, and discovery operations. Examples of load indicators are device temperature, memory usage, battery power consumption, memory buffer usage for relay operations, CPU load percentage, resource availability percentage in a sidelink resource group, and so on.Generally, the relay UE would use such load indicator(s) to further reduce the calculated value for the downstream recommended bit rate when this load indication is higher. This allows the relay UE to balance its service to its remote UEs against its own resource requirements and limitations. 7. Adapted to the quality of the remote UE link: This aspect of the policy can be combined with one of the other policies. The relay UE will adapt a calculated bit rate recommendation value based on the link quality or a similar indicator of a link to a particular remote UE. For example, the relay UE may determine that a particular link to a remote UE has low quality, and therefore an effective bit rate from that remote UE cannot exceed a certain predetermined threshold value. The relay UE may then decide to reduce the recommendation value calculated according to the policy and send the reduced value to the remote UE. q LRznn / eznz / E / YiAi A relay UE could use one or more policies to aggregate multiple received bitrate recommendation queries (SL-RBR with Q=1) into a single uplink MAC CE recommended bitrate query with an embedded request value that is sent to the gNB. This policy can, as described herein, be set on the relay UE, pre-configured, or dynamically configured by the gNB using data sent via the RRC protocol to the relay UE. Typical advantageous policies for this mode are: 1. Sum of requested bit rates: The relay UE will sum any UL / DL-bit=0 requests received from remote UEs belonging to the same proxy LCID and send the approximate sum as a recommended bit rate query with UL / DL-bit=0 uplink to the gNB; as well as sum any UL / DL=1 requests and send the approximate sum as a recommended bit rate query uplink to the gNB with UL / DL=1. If the exact sum cannot be encoded as one of the allowed bit rate values ​​using the 6 bits of the bit rate field, then the relay UE selects the next highest number for the bit rate. 2. Sum of Requested and Historical Bit Rates: The relay UE will sum the requests as described in Policy 1 above, but will also use historically observed actual data rates from one or more remote UEs that have not yet sent an SL-RBR-Q, or have not sent one recently. These historical rates are added to the sum. This assumes that the preference of those remote UEs that have not (recently) sent an SL-RBR request is to continue transmitting data as they have done in the past. 3. Adapted to current relay load: This aspect of the policy can be combined with one or more of the other policies. In this case, the relay UE will reduce the calculated request value based on an indication of the current relay load—that is, an internally calculated indication using one or more variables that describes the load on the relay UE's resources due to its functions, which include, for example, transmitting user data, receiving user data, data relay operations, computation, and discovery operations. Examples of load indicators are device temperature, memory usage, battery power consumption, memory buffer usage for relay operations, CPU load percentage, resource availability percentage in a sidelink resource group, etc.Generally, the relay UE would use such load indicator(s) to further reduce the calculated request value for the upstream recommended bit rate when this load indication is higher. This allows the relay UE to balance its service to its remote UEs against its own resource requirements and limitations. 4. Adapted to the quality of the remote UE link: This aspect of the policy can be combined with one or more of the other policies. The relay UE will adapt a calculated request value based on the link quality or a similar indicator of a link to a particular remote UE. For example, the relay UE might determine that a particular link to a remote UE has low quality, and therefore an effective bit rate from that remote UE cannot exceed a certain predetermined threshold value. If that remote UE requests a bit rate higher than this threshold, the relay UE might decide to reduce this value and then apply the policy using this reduced value. This is similar to case 3, but now the reduction is made for different reasons and is calculated differently. q LRznn / eznz / E / YiAi To limit the amount of SL-RBR transmitted, a UE can use a bitRateQuerySIProhibitTimer similar to the existing bitRateQuerySIProhibitTimer in TS 38.321 to restrict the rate at which the SL-RBR can be sent. If a relay UE does not have a transmission opportunity for the SL-RBR to a particular remote UE, it can hold the last SL-RBR to be transmitted to that remote UE in memory until the next transmission opportunity arises. Alternatively, the relay UE can calculate the optimal value for the SL-RBR to send just in time before the next transmission opportunity begins. In one variant of this approach, the Q field is not present in SL-RBR and SL-RBR-Q; instead, two different LCID values ​​are assigned to SL-RBR and SL-RBR-Q, respectively. For example, the value 61 for SL-RBR and the value 60 for SL-RBR-Q. This has the advantage of saving a payload bit in the MAC CE, which can then be used for other purposes. q LRznn / eznz / E / YiAi The following describes an alternative mode that can be used in at least one Layer 2 (L2) single-hop relay architecture for UE-to-network (U2N) relay. It defines SL-RBR as in the previous mode and, in addition, also RBR-R, which stands for Recommended Bit Rate for the Relay Control MAC Element. RBR-R is assigned a new DL-SCH logical channel value (LCID or eLCID), for example, 46 or 308. It also defines RBR-RQ to denote a Recommended Bit Rate for the Relay Query Control MAC Element. RBR-RQ is assigned a new UL-SCH logical channel value (LCID or eLCID), for example, 44 or 249. RBR-R / RBR-Q can have a fixed size of four octets. It can include one or more of the following fields: • Remote identifier (16 bits): An identity of a remote UE, encoded, for example, as (part of) an L2 identifier. This encodes the identity of the remote UE that (in the case of RBR-RQ) queried the relay UE for a bit rate recommendation or (in the case of RBR-R) the relay UE will provide a bit rate recommendation to. • SL-LCID (6 bits): Indicates a logical SL channel identity associated with the remote UE identified by remote identifier for which a bit rate is recommended in RBR-R, or for which a recommendation query is made for RBR-RQ. Optionally, this field could be excluded in an additional alternative mode; in this case, an RBR-R / RBR-RQ would correspond to all (active) SL LCIDs used between the relay UE and the remote UE identified by remote identifier. • UL / DL (1 bit): indicates whether this RBR-R / RBR-RQ is applied to an upstream (1) or downstream (0) data flow direction. • Bit rate (6 bits): an index in Table 6.1.3.20-1 of TS 38.321 νAβ.3.0, which encodes a bit rate value for recommendation (Q=0) or request (Q=1) respectively. The request value can be seen as a UE's preference for a bit rate, i.e., a requested rate. • X (1 bit): Applicable (1) or non-applicable (0) bit rate multiplier. The multiplier, if applicable, can be applied to the bit rate value in a similar manner to that described in TS 38.321 V16.3.0 section 6.1.3.20 using the same multiplication factor. This factor is configured by the gNB using an optional parameter bitRateMultiplier-rl6 sent through the RRC to the UEs, including the relay UE and the remote UE. Alternatively, a new parameter bitRateMultiplierSL can be defined that specifies a different multiplier for sidelink communications. • R (2 bits): Reserved bit, set to 0. Optionally, a reserved bit can be used as a remote ID extension bit indicating that a larger remote ID address is included, which is useful in case the short 16-bit remote ID identities of two remote UEs otherwise collide. or LRznn / eznz / E / YiAi In the case of an L2 relay architecture, there may be a procedure between a remote UE, a relay UE, and a gNB for accepting a new remote UE and configuring the L2 RAN end-to-end connection between the remote UE and the gNB. Similarly, for an L3 relay architecture, there may be a procedure for accepting a new relay UE or remote UE, or for configuring the connection between the relay UE and the gNB over Uu, or for configuring the connection between the relay UE and the remote UE over PC5. Such a procedure may also establish a proxy LCID as described in the previous mode. A relay UE serving one or more remote UEs can send an SL-RBR to one or more of its remote UEs, triggered by specific events such as the downlink reception of the gNB's MAC CE RBR-R or the receipt of an SL-RBR-Q from a remote UE. Which of the served remote UEs should receive a new SL-RBR if the trigger is the downlink reception of the gNB's MAC CE RBR-R is, in most cases, determined by the remote ID value indicated in that received MAC CE. Similarly, for queries, a relay UE can send an uplink MAC CE RBR-RQ (indicating a remote UE ID in the remote ID field) to its gNB, triggered by specific events such as timer expiration or the receipt of an SL-RBR-Q from one or more of its remote UEs.The SL-LCID value (if applicable) and the remote identifier value will be included in this MAC CE sent to the gNB. The remote identifier is determined based on the identity of the remote UE and (if applicable) which sidelink LCID of that remote UE is being queried to the gNB. Typically, the remote identifier would identify the same remote UE that sent an SL-RBR-Q activation to the relay UE, and the SL-LCID field (if applicable) would identify the sidelink LCID specified in that SL-RBR-Q activation. q LRznn / eznz / E / YiAi A relay UE could use one of several downstream policies to distribute a received recommended bit rate in addition to a Remote UE. A policy can, as described elsewhere in this document, be set on the relay UE, pre-configured, or dynamically configured by the gNB using data sent via the RRC protocol to the relay UE. Typical advantageous policies for this mode are: 1. Distribution to the greatest effort: send the SL-RBR as soon as possible when sending a MAC PDU to the remote destination UE that has available space for SL-RBR inclusion. 2. Time-bound distribution: as policy 1, but in case a MAC PDU is not sent to the destination remote UE within a configured time limit, create a new MAC PDU and send it to the remote UE even if this PDU does not contain upper-layer data. 3. Deferred distribution: Buffer the locally received recommendation until the destination remote UE signals an SL-RBR-Q and / or a specific timer in the relay triggers. Then, in response, send the buffered recommendation using SL-RBR with policy 1 or 2. 4. Deferred distribution with gNB backup: as policy 3, but in case the bit rate requested in SL-RBRQ is higher than the value stored in the buffer, trigger a new RBR-RQ to the gNB and wait for the response from the RBR-R and then provide this new value to the remote UE using policy 1 or 2. 5. Delta-only distribution: Use one of the other policies 1-4 and, in addition, suppress the SL-RBR sending if the recommendation value of that SL-RBR is equal to the value previously sent to the same remote UE using SL-RBR. Optionally, suppression is not used if the last send event is longer than a configured time interval. A relay UE could use one of several policies above to send received bit rate recommendation queries q LRznn / eznz / E / YiAi (SL-RBR with Q=1) to the gNB as RBR-RQ queries. The policy can, as described elsewhere in this document, be fixed in the relay UE, pre-configured, or dynamically configured by, e.g., the gNB, using data sent over the RRC protocol to the relay UE. Typical advantageous policies for this mode are: 1. Send at maximum effort: send the RBR-RQ as soon as possible after an activation event, when a MAC PDU is sent to the gNB that has available space for the inclusion of this MAC CE. 2. Time-limited distribution: like policy 1, but also applies a time limit similar to downstream policy 2. 3. Delta-only distribution: Use either policy 1 or 2 and, in addition, suppress RBR-RQ sending if the bit rate value is equal to the value previously sent to the gNB using RBR-RQ for the same remote UE and the same SL-LCID. Optionally, suppression is not used if the last send event is longer than a configured time interval. q LRznn / eznz / E / YiAi To limit the amount of RBR-RQs transmitted, a UE can use a bitRateRelayQueryProhibitTimer similar to the existing bitRateQueryProhibitTimer in TS 38.321 to restrict the rate at which the RBR-RQ can be sent. One advantage of this mode is that the gNB can determine in detail the bit rate recommendation for each remote UE it serves, giving the gNB more control over the recommendations. The following describes another alternative mode, based on the same principles as the previous mode applied to an L2 relay architecture. The main difference between this mode and the previous one is that the SL-RBR and SL-RBR-Q are carried directly within an adaptation header sent in communications between the gNB and a relay UE, instead of sending RBR-R and RBR-RQ respectively. The adaptation header is a protocol layer header on the Uu interface located between the RLC and PDCP protocol layers, as defined in TR 23.752 vi.0.0 Annex A. Note that the adaptation header is only used for wrapping; that is, it connects to the PDCP PDUs that are to be relayed by the relay UE.The adaptation header can be defined as a variable-length header, such that it can include other information elements (IEs), such as the MAC CEs to be sent across the sidelink (PC5 interface) to the UE specified in a destination UE identity field or a similar adaptation layer field, over a sidelink channel (LCID) specified in a destination LCID field or a similar adaptation layer field. Specifically, the adaptation header can contain at least one length field indicating the total length of the adaptation header or just the length of the IE container. The IE container can contain one, or optionally one or more, MAC CEs. Other data, such as status reports or configuration settings related to the relay operation, can also be included as IEs within the IE container.Upon receiving such an IE with a MAC CE, it is the responsibility of the relay UE to determine the actual MAC CE to be sent to the destination UE via PC5 and attempt to transmit the determined MAC CE to the destination UE through its PC5 connection to that UE. When making this determination specifically for an included SL-RBR, the relay UE can base its transmitted SL-RBR entirely on the fields included in the SL-RBR within the IE container, or it can adapt the recommended bit rate value (e.g., to a lower value if it is heavily loaded, or lowering the value due to some other policy). Conversely, the relay UE is responsible for receiving SL-RBR-Q from remote UEs and sending such a query (provided there is sufficient MAC PDU space and enabling conditions) to the gNB embedded in an IE in the adaptation header.This allows the gNB to send detailed recommendations, such as SL-RBR, to specific remote UEs, as in the previous q LRznn / eznz / E / YiAi mode. This better assists the relay UE with detailed recommendations, enabling it to make a more informed decision for its final recommendation(s) to the remote UEs. Furthermore, it allows the gNB to receive all specific queries (SL-RBR-Q) from the remote UEs through the relay UE, thus obtaining more granular information. This has the same advantages as the second mode, plus the added benefit that no new MAC CE type definitions are needed in DL-SCH because the gNB can directly include the SLSCH MAC CE within the IE container for DL ​​packets, and the relay UE can directly include the SL-SCH MAC CE within the IE container for UL packets.It also has the added advantage that the IE container in the adaptation header can also be used by the gNB to relay other types of SL-RBR-Q MAC CEs to remote UEs without requiring the relaying UE to know and parse all of these MAC CEs. This is useful, for example, if new SL-RBR-Q MAC CE types are introduced that a legacy relaying UE might not be familiar with. Instead of using the adaptation header to carry the MAC CE message, such as SL-RBR-Q, the relaying UE can also add an adaptation layer header to a received SL-RBR-Q message, for example, after encapsulating it in an RLC / PDCP message. o LRznn / cznz / E / YiAi The following describes a mode that applies when a relay UE or a remote UE performs a procedure to allow itself to be assigned to a new source relay UE while disconnecting from its current source relay UE, where both the old and new source relay UEs are served by the same gNB, either directly or indirectly. This procedure is referred to here as the UE intra-gNB transfer. This mode can be combined with any of the previously described modes. The trigger to initiate the intra-gNB transfer can be a message or instruction from the gNB to the UE or its current source relay UE, or it can be a determination by the relay UE itself that it needs to perform the transfer. In either case, the source relay UE will be notified of the transfer or will eventually notice the UE disconnecting.This can trigger a recalculation of the data rate recommendation(s) and / or limit(s) for any remaining downstream relay or remote UEs. Additionally, the gNB could optionally, on its own initiative, send a new data rate recommendation and / or limit to the (former) source relay UE, for example, reducing the total amount due to the UE's exit or imminent exit as a dependent UE. Also, optionally, the source relay UE could, on its own initiative, send a data rate recommendation query to its parent communication device (e.g., a gNB or a relay UE) to indicate that it needs a new recommendation given the updated situation. The gNB can then respond to this query with an updated data rate recommendation and / or limit.Once the delivered UE has connected to its new source relay UE, it can optionally send a new data rate recommendation query to that parent to notify the new parent of its desired data rate and request a data rate recommendation from the new parent. The source relay UE can respond directly to this request with a recommendation, or it can first send a data rate recommendation query to its own upstream communication device (e.g., gNB or relay UE) to ensure that its upstream devices are also aware of the desired data rates for downstream devices in the new situation. In either case, the intent of this procedure is for the new source relay UE to be able to send a new data rate recommendation to the delivered UE that is now connecting to the new parent (as a remote UE, a relay UE, or both).Note that the UE may use different logical channel identifiers (e.g., different LCID values) with the new parent than it used with the previous parent, depending on the method used to select these identifiers (e.g., it may be configured by the gNB). q LRznn / eznz / E / YiAi A similar procedure to the one described above can be defined for inter-gNB transfers; that is, a procedure in which a UE (either a relay UE or a remote UE) leaves its current source relay UE and connects to a new source relay UE served by a different gNB, either directly or indirectly. In this case, the same behaviors defined above can be used by the old source relay UE, the new source relay UE, and the delivered UE. q LRznn / eznz / E / YiAi In both intra-gNB and inter-gNB handovers, the (old) source relay UE of a remote UE may, after the remote UE's handover to another source relay UE (e.g., after receiving a signal (e.g., a handover request) from the remote UE or the gNB that forms the handover relay UE, or triggered by the relay UE itself) or after a gNB's handover to another gNB, send a message to the remote UE and / or the old or new gNB and / or a core network function (such as AME or SMF) with information about the allocation of logical channels and / or the QoS configuration (e.g., flows / filters / QoS policies) related to those channels and / or the (most recent) data rate recommendation configuration and / or related policies and / or a list of recent messages related to data rate recommendations or data rate recommendation queries. data.This information can then be used by the remote UE and / or the old or new gNB and / or the respective core network function to inform the new source relay UE of the remote UE and / or the new gNB, which can use this information to apply configurations / policies / logical channels similar to those that the old source relay UE applied for its relay communication with the remote UE. This enables a smoother and faster handover procedure. Additionally, in the event of an inter-gNB transfer, the gNB to which the relay UE connects before the transfer can send information about the allocation of logical channels and / or the QoS configuration (e.g., flows / filters / QoS policies) related to those channels and / or the (most recent) data rate recommendation configuration and / or related policies and / or a list of recent messages related to recommended data rates or data rate recommendation queries related to the relay UE and / or its downstream connected UEs to the new gNB to which the relay UE connects after the transfer. In summary, in cellular or other wireless networks, relay communication devices can be introduced to support an indirect network connection for remote communication devices in out-of-context (OoC) areas. This extends the coverage of the access device and increases the data capacity available to communication devices that may not have optimal coverage from an access device. For directly connected communication devices, mechanisms are defined for bit rate recommendation, bit rate querying, and desired bit rate indication. However, these existing mechanisms do not work for communication devices connected indirectly through a relay communication device.Therefore, it is proposed to determine a new recommendation and / or data rate limit for one or more downstream communication devices at least partially based on a logical channel identity indicated in a received recommendation and / or limit. q LRznn / eznz / E / YiAi Although the invention has been illustrated and described in detail in the figures and description above, such illustration and description should be considered illustrative or exemplary, and not restrictive. The invention is not limited to the described embodiments. The proposed enhanced rate recommendation or limitation can be implemented in all types of wireless networks where relays are used. For example, it can be applied to devices communicating using cellular wireless communication standards, specifically the 5G specifications of the 3rd Generation Partnership Project (3GPP). Therefore, wireless communication devices can be different types of devices, e.g., mobile phones, vehicles (for vehicle-to-vehicle (V2V) communication or more general vehicle-to-everything (V2X) communication), V2X devices, IoT hubs, IoT devices, including low-power medical sensors for health monitoring, medical diagnostic and treatment devices (emergency), for hospital use or first aid use, virtual reality (VR) headsets, etc. Furthermore, the invention can be applied in medical applications or connected health services involving multiple wirelessly connected sensor or actuator nodes (e.g., 4G / 5G), in medical applications or connected health services where a wirelessly connected device (e.g., 4G / 5G) occasionally consumes or generates a continuous stream of data at a certain average data rate, for example, video imaging devices, ultrasound, X-ray, computed tomography (CT), real-time patient sensors, audio, voice, or video transmission devices used by medical personnel, in general IoT applications involving wireless, mobile, or stationary sensor or actuator nodes (e.g., smart city, logistics, agriculture, etc.).), in emergency services and critical communication applications, in V2X systems, in systems to improve the coverage of 5G cellular networks using high-frequency RF (e.g., mmWave) and any other application area of ​​5G communication where relaying is used. Furthermore, although the aforementioned embodiments typically describe the creation of a single new MAC / RLC logical channel to carry relay data for a downstream communication device, similar embodiments are possible in which two or more logical channels are created to carry relay data for the downstream communication device, e.g., to handle situations where a single radio carrier requires two or more MAC / RLC logical channels. Those skilled in the art may understand and implement other variations of the embodiments described in the practice of the claimed invention from a study of the figures, description, and appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" does not exclude a plurality.A single processor or other unit can perform the functions of several articles mentioned in the claims. The mere fact that certain measures are mentioned in dependent and mutually different claims does not indicate that a combination of these measures cannot be used. The foregoing description details certain embodiments of the invention. However, it will be appreciated that no matter how detailed the foregoing appears in the text, the invention can be implemented in many ways and is therefore not limited to the embodiments described. It should be noted that the use of particular terminology in describing certain features or aspects of the invention should not be interpreted as the terminology being redefined in the present description to be restricted to including specific features or aspects of the invention with which that terminology is associated. or LRznn / eznz / E / YiAi A single unit or device may perform the functions of several elements mentioned in the claims. The mere fact that certain measures are mentioned in dependent and mutually different claims does not indicate that a combination of these measures cannot be used. The operations described as shown in Figures 4 and 5 can be implemented as program code within a computer program and / or as dedicated hardware for the communication device or related access device, respectively. The computer program can be stored and / or distributed on a suitable medium, such as optical storage or solid-state media supplied with or as part of other hardware, but it can also be distributed in other ways, such as via the Internet or other wired or wireless telecommunications systems.

Claims

1. An apparatus for controlling the scheduling of communication resources to communication devices in a relay communication device (10-1) in a wireless network, characterized in that the apparatus is configured to: receive from an access device (20) of the wireless network or an upstream relay communication device (10-P) of the relay communication device (10-1) a recommendation and / or limit of received data rate that is an aggregated recommendation and / or limit of data rate indicating a logical channel belonging to at least two communication devices or at least two logical channels of a communication device, or a recommendation and / or limit of data rate for a logical channel that has been allocated to one or more downstream communication devices by the relay communication device;Determine a new recommendation and / or data rate limit for one or more downstream communication devices (102, 10-D) at least partially based on a logical channel identity; and transmit the determined new recommendation and / or data rate limit to at least one of the one or more downstream communication devices (10-2, 10-D).

2. The apparatus of claim 1, characterized in that the apparatus is configured to determine that the new recommendation and / or data rate limit is less than or equal to the received recommendation and / or data rate limit.

3. The apparatus of claim 1, characterized in that the received data rate recommendation and / or limit comprises indicator data indicating whether the received recommendation and / or limit applies to an upstream or downstream data flow. 101 4. The apparatus of claim 1, characterized in that the apparatus is configured to send to the access device (20) or the upstream relay communication device (10-P) of the relay communication device (10-1) a request for a desired aggregate data rate for a logical channel.

5. The apparatus of claim 4, characterized in that the request is activated and based at least partially on at least one request for a desired data rate received from one or more downstream communication devices (10-2, 10-D). q LRznn / eznz / E / YiAi 6. The apparatus of claim 1, characterized in that the apparatus is configured to receive a request for a desired data rate for a logical channel from one or more downstream communication devices (10-2, 10-D), to determine based on the received request a recommendation and / or data rate limit for the logical channel, and to respond to the request with the determined recommendation and / or data rate limit.

7. The apparatus of claim 1, characterized in that the apparatus is configured to search in an internal table (25) of the relay communication device (10-1) a corresponding downstream communication device (10-2, 10-D) and a second logical channel identity to send a new recommendation and / or data rate limit to the downstream communication device (10-2, 10-D) in response to a recommendation and / or data rate limit received from the access device (20) or the upstream relay communication device (10-P) of the relay communication device (10-1) and indicate a first logical channel identity,or wherein the apparatus is configured to look up a second logical channel identity in an internal table (25) of the relay communication device (10-1) for which to send a new request for a desired data rate to the access device (20) 102 or an upstream relay communication device (10-P) of the relay communication device (10-1) in response to a request for a desired data rate received from one or more downstream communication devices (IOSS, 10-D) and indicate a first logical channel identity. q LRznn / eznz / E / YiAi, 8. The apparatus of claim 7, characterized in that the apparatus is configured to create an additional logical channel in a wireless link with the access device (20) or an upstream relay communication device (10-P) when it determines that a new logical channel has been created for a communication link with one of the one or more downstream communication devices (10-2, 10-D).

9. The apparatus of claim 7, characterized in that the internal table (25) is configured to map a logical channel identity between the relay communication device (10-1) and the access device (20) or the upstream relay communication device (10-P) to a plurality of logical channel identities between the relay communication device (10-1) and one or more downstream communication devices (10-2, 10-D).

10. The apparatus of claim 1, characterized in that the data rate recommendation and / or limit is transmitted using at least one medium access control protocol, radio link control protocol, adaptation protocol carrying packet data convergence protocol data, packet data convergence protocol, radio resource control protocol, and service data adaptation protocol.

11. The apparatus of claim 1, characterized in that the apparatus is configured to collect information about at least one desired data rate received from one or more downstream communication devices (10-2, 10-D), to transmit the collected information to the upstream relay communication device (10-P) or the access device (20), to receive a data rate recommendation and / or limit received from the upstream relay communication device (10-P) or the access device (20), and to distribute the received data rate recommendation and / or limit at least partially among the one or more downstream communication devices (10-2, 10-D) using a predetermined policy.

12. The apparatus of claim 11, characterized in that the apparatus is configured to select the default policy based on at least one of a quality indicator of a logical channel of the relay communication device (10-1), a number of communication devices downstream of a relay communication device, a number of communication devices upstream of a relay communication device, a type of downstream communication device, policy selection information received from an upstream communication device or the access device, a quality of service identifier, a network partition identifier, and a buffer status of the relay communication device (10-1).

13. The apparatus of claim 1, characterized in that the apparatus is configured to determine a new recommendation and / or additional data rate limit for one or more downstream communication devices (10-2, 10-D) triggered by the loss of a communication link between the relay communication device and at least one other communication device, or by a determination that the communication link should be stopped; and to transmit the new recommendation and / or additional data rate limit to at least one downstream communication device (10-2, 10-D). 104 14. A relay communication device (10-1) for a wireless network, comprising an apparatus according to any one of claims 1 to 13.

15. A wireless communication system comprising a relay communication device (10-1) according to claim 14 and an access device (20), characterized in that the access device (20) is configured to receive from the relay communication device (10-1) a desired aggregate data rate for a logical channel, and to determine, based on a logical channel identity, to which the desired aggregate data rate applies to downstream communication devices.

16. A method for controlling the scheduling of communication resources to communication devices in a wireless network, characterized in that the method comprises: receiving from an access device (20) or an upstream relay communication device (10-P) of the wireless network a recommendation and / or data rate limit that is one of an aggregated recommendation and / or data rate limit indicating a logical channel belonging to at least two communication devices or at least two logical channels of a communication device, or a recommendation and / or data rate limit for a logical channel that has been allocated to one or more downstream devices by the relay communication device; determining a new recommendation and / or data rate limit for one or more downstream communication devices (102, 10-D) at least partially based on a logical channel identity;and transmit the new recommendation and / or determined data rate limit to at least one of the one or more downstream communication devices (10-2, 10-D). 105; 17. A computer program product comprising code means for producing the steps of claim 16 when executed on a computer device.

Images