Enhanced rate signaling in a wireless network with relay functionality

Abstract

To provide an enhanced rate recommendation procedure that also considers indirectly connected communication devices in a wireless network.SOLUTION: In cellular or other wireless networks, relaying communication devices are introduced to support indirect network connections of remote communication devices in out-of-coverage (OoC) areas. The relay communication device determines a new data rate recommendation and / or restriction for one or more downstream communication devices based at least in part on the identification of the logical channel indicated in the received recommendation and / or restriction.SELECTED DRAWING: None

Description

[Technical Field]

[0001] The present invention relates to resource scheduling in wireless networks with relay capabilities, 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 the coverage area of ​​the network. [Background technology]

[0002] Many wireless communication systems use network access devices (e.g., base stations, Node Bs (eNB, eNodeB, gNB, gNodeB, ng-eNB, etc.), access points, or the like) to provide geographical service areas in which wireless communication devices (e.g., terminal devices such as mobile stations or UEs) communicate with the access devices that serve the particular geographic service area in which the terminal devices are located. The access devices are connected within a network that allows communication links to be made between the wireless communication devices and other devices. In some situations, the communication link is between wireless communication devices that are close to each other. In these situations, it is desirable to have a direct communication link between the two wireless communication devices rather than communicating through an access device. Such direct communication between communication devices is often referred to as device-to-device (D2D) communication 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 bands or millimeter wave bands).

[0003] An in-coverage (InC) communication device is a communication device that is within the service area of ​​an access device and has the capability of communicating with the access device. An out-of-coverage (OoC) communication device is a communication device that is typically not within the service area of ​​any access device or is within the service area of ​​an access device but does not allow access (e.g., because it is a non-public network (NPN) access device). An OoC communication device uses an indirect network connection to the access device. It should be noted that a communication device can also be an OoC communication device that has no connectivity.

[0004] Resource scheduling is based on a complex interplay of multiple scheduling mechanisms and protocols working in tandem. The scheduler (which may be located in the access device) is expected to ensure good coordination between resource allocations and the recommended bit rate values ​​it sends to communication devices. At the physical layer, resources are typically scheduled at a very fine-grained level, i.e., per frame / subframe or smaller resource unit. At higher layers, scheduling is typically defined in relation to Quality of Service (QoS) profiles, priorities, etc. For 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 2 seconds, is provided to each UE connected to the access device, and is targeted to a specific logical channel. The use of this MAC mechanism allows the access device to indicate in a fairly dynamic manner (e.g., not to generate too much data to be transferred) or to change the balance between UEs or certain logical channels (e.g., because another UE or another channel temporarily reserves higher priority for transmitting or receiving data). This, in turn, must lead to adhering to higher layer QoS profiles, e.g., guaranteeing a certain bit rate for a longer period of time for some UEs. The physical layer scheduler needs to take into account the MAC recommended bit rate. For example, the scheduler can assign a persistent schedule to a particular communication device, which means that this communication device is guaranteed periodically cycling resources, allowing it to send data at approximately the bit rate recommended to it. Summary of the Invention [Problem to be solved by the invention]

[0005] Various Core Network (CN) functions are provided for data rate control and limitation. However, these mechanisms do not consider data rate recommendation, control, or limitation in the context of the Radio Access Network (RAN) and relay communication devices. For good system operation, control mechanisms for both the RAN and the CN are needed, since each has unique requirements.

[0006] Furthermore, in the field of bit rate (data rate) recommendations for wireless networks in which relay functions are enabled for communications between communication devices and the wireless network, these relay functions can enable single-hop and / or multi-hop indirect network connections for remote communication devices. Remote communication devices are communication devices indirectly connected to the core network via one or more relay functions. In such networks, the problem is that RAN mechanisms for recommending bit or data rates are no longer useful for indirectly connected communication devices. This means that these communication devices cannot query access devices for bit rate recommendations and cannot receive bit rate recommendations from access devices.

[0007] As a result, an indirectly connected communication device has no information about what bit rate it can expect from an access device for a particular logical channel, an access device has no information about what bit rate a particular indirectly connected communication device wants to use for a particular logical channel, an access device has no means to influence an indirectly connected communication device that is a data source to go to a lower (or higher) bit rate, and / or an indirectly connected communication device has no direct means to influence an access device to get a higher bit rate if the access device needs a higher bit rate and to signal which rate is desired.

[0008] It is an object of the present invention to provide an enhanced rate recommendation procedure that also takes into account indirectly connected communication devices in a wireless network. [Means for solving the problem]

[0009] This object is achieved by an apparatus as claimed in claim 1, by a relay communication device as claimed in claim 14, by a wireless communication system as claimed in claim 15, by a method as claimed in claim 16 and by a computer program product as claimed in claim 17.

[0010] According to a first aspect, an apparatus is provided for controlling scheduling of communication resources to communication devices at a relay communication device in a wireless network, wherein the apparatus is configured to: receiving, from an access device or an upstream relay communication device of the wireless network, a received data rate recommendation and / or limit, which is one of an aggregate data rate recommendation and / or limit indicating a logical channel associated with at least two communication devices or at least two logical channels of the communication device, or a data rate recommendation and / or limit of a logical channel assigned by the relay communication device to one or more downstream devices; determining a new message including data rate recommendations and / or restrictions for one or more downstream communication devices based at least in part on the identification of the logical channel; and Transmitting the determined new message including the data rate recommendation and / or limit to at least one of the one or more downstream communication devices.

[0011] According to a second aspect, there is provided a method of controlling scheduling of communication resources to communication devices in a wireless network, the method comprising: receiving, from an access device or an upstream relay communication device of a wireless network, a received data rate recommendation and / or limit, which is one of an aggregate data rate recommendation and / or limit indicating a logical channel associated with at least two communication devices or at least two logical channels of the communication device, or a data rate recommendation and / or limit of a logical channel assigned by the relay communication device to one or more downstream devices; determining new data rate recommendations and / or limitations for one or more downstream communication devices based at least in part on the identification of the logical channel; and transmitting the determined new data rate recommendation and / or limit to at least one of the one or more downstream communication devices.

[0012] According to a third aspect, there is provided a relay communication device of a wireless network comprising the apparatus of the first aspect.

[0013] According to a fourth aspect, there is provided a wireless communication system comprising a relay communication device and an access device of the third aspect, wherein the access device is configured to receive a desired data rate of an aggregate of logical channels from the relay communication device and determine to which downstream communication devices the desired data rate of the aggregate applies based on an identification of the logical channels.

[0014] Finally, according to a fifth aspect there is provided a computer program product comprising code means for producing the steps of the aforementioned method of the second aspect when executed on a computing device.

[0015] Thus, enhanced rate signaling for wireless networks with relaying capabilities is provided, 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 as well as by all intermediate relay communication devices, based on the recommendation of the access device. 2. The expected data rates can now be signaled by these communication devices so that the access device or scheduler can adapt its resource schedule to accommodate the expected data rates between the access device and all indirectly connected communication devices. 3. An access device can efficiently communicate with its directly connected relayed communication devices regarding data rate recommendations in the same manner as it communicates with regular, directly connected, non-relayed communication devices. 4. Remote communication devices can send their bit rate recommendation queries and receive bit rate recommendations in the same manner as if they were directly connected to the access device, avoiding additional implementation complexity on the remote communication device side. 5. Improved scheduling may be performed by the access devices, and a reduction in data loss and / or relay buffer overflow in the network may be achieved. 6. Data-producing communication devices can optimally adapt their generated data rate to what the network can support instead of learning this rate by trial and error.

[0016] It should be noted that determining a new data rate recommendation and / or limit includes updating the data rate recommendation and / or limit and / or including (a copy of) the received data rate recommendation and / or limit in a new message. The value of the new data rate recommendation and / or limit may be the same as the previous recommendation and / or limit or may be changed as detailed in the following embodiments. Thus, the new data rate recommendation and / or limit may be different, but is not required to be different. One example of a case in which a new data rate recommendation is determined is selecting a new data rate recommendation value based on a preconfigured policy. Another example is when a message header is added to a received data rate recommendation to form a new (updated) data rate recommendation. Another example of such a case is when a message header of a received data rate recommendation is partially updated or replaced to form a new (updated) data rate recommendation. Yet another example of such a case is when additional identification information (e.g., a UE identifier) ​​or context information (e.g., a validity period) is added to a received data rate recommendation to form a new (updated) data rate recommendation. An example similar to the previous example may apply to the case of determining a new data rate limit by updating a received data rate limit. A further example of determining a new data rate recommendation is receiving a message including a data rate recommendation and a data rate limit and removing the data rate limit to form a new data rate recommendation. Another example is receiving a message including a data rate recommendation and combining this with a received or determined data rate limit to form a new data rate recommendation and limit.

[0017] In the case where the downstream communication device receiving the new recommendation and / or restriction is itself a relay communication device, the new recommendation and / or restriction is the aggregate recommendation and / or restriction of the downstream communication device and all its downstream (e.g., child) communication devices. Allocating logical channels to one or more downstream devices by a relay communication device may be accomplished by one or more of the following procedures: a) The relay communication device may assign a new upstream logical channel, identified by a new logical channel identification (e.g., LCID), to the downstream communication device, e.g., to provide an indirect connection from the downstream communication device, thus transporting relayed data to / from the downstream communication device. Allocating such a new upstream logical channel may occur when the relay communication device receives a request from the downstream communication device to create a new logical channel between the downstream communication device and the relay communication device for relaying purposes (e.g., via a direct (indirect) communication request) or receives a logical channel identification (e.g., LCID) or logical channel identification mapping associated with one or more logical channels created between two or more downstream communication devices. This new logical channel identification, if not already in use, may have a different identifier value as the logical channel identification received from the downstream communication device, and the logical channel identification may have the same value as the logical channel identification received from the downstream communication device. The relay communication device may maintain a mapping table containing a mapping between the logical channel identification received from the downstream communication device and the logical channel identification used for the new upstream logical communication channel. The relay communication device requests a desired data rate for a new upstream logical channel from an upstream access device or an upstream relay communication device based on the requested desired data rate received from the downstream communication device. Optionally, it reports to the upstream access device or the upstream relay communication device a downstream communication device identifier associated with the logical channel identification, the requested desired data rate received from the downstream communication device, the (currently) used recommended data rate for a particular logical channel identification, and / or one or more logical channel identifications to which the new logical channel identification applies and / or a mapping of the logical channel identification to other logical channel identifications. The values ​​of the logical channel identifications may be the same, but they are between different devices (e.g., uplink instead of sidelink).The upstream access device or parent relay communication device sends data rate recommendations and / or limitations indicating the new logical channel identification, and by doing so, it triggers the relay communication device to derive / determine new data rate recommendations and / or limitations for the downstream communication device. b) The relay communication device may assign an existing logical channel for upstream communication between the relay communication device and an access device or an upstream relay communication device, identified by a logical channel identification already existing in the downstream communication device, for example, to provide an indirect connection from the downstream communication device, thereby transporting relay data to / from the downstream communication device. The assignment of such an existing logical channel to the downstream communication device occurs when the relay communication device receives a request from the downstream communication device to create a new logical channel between the downstream communication device and the relay communication device for relaying purposes (e.g., via a direct (indirect) communication request) or receives a logical channel identification or a logical channel identification mapping associated with one or more logical channels created between two or more downstream communication devices. The relay communication device maintains a mapping table indicating the mapping between the logical channel identification received from the downstream communication device and the existing logical channel identification used for the existing upstream logical channel. The mapping also includes logical channel identifications from other downstream communication devices assigned to the same existing logical channel, and / or the received recommended data rate and / or the existing desired data rate of the existing logical channel identification from the downstream communication device. The relay communication device may report to the upstream access device or the upstream relay communication device the logical channel identification of the existing logical channel to which the received logical channel identification is mapped, and optionally a set of downstream communication device identifiers associated with the logical channel identification, the requested desired data rate (currently) received from the downstream communication device, or an aggregate thereof, the recommended data rate and / or limit (currently) in use for a particular logical channel identification, and / or the mapping of the logical channel identification to the received logical channel identification from the downstream communication device and / or other logical channel identifications.The relay communication device requests a new desired data rate for the existing upstream logical channel from the upstream access device or the upstream relay communication device based on the aggregate of the requested desired data rate received from the downstream communication device and the existing desired data rate of the existing upstream logical channel (i.e., based on the logical channel identification from other downstream communication devices assigned to the same existing logical channel). The upstream access device or the upstream relay communication device can send a new data rate recommendation and / or limit indicating the logical channel identification of the existing logical channel, and by doing so, it can trigger the relay communication device to derive / determine a new data rate recommendation for the downstream communication device. c) The relay communication device assigns a new / different logical channel identification for a logical channel between a downstream communication device and the relay communication device, or between two downstream communication devices, in case the logical channel identification is already in use for another logical channel. In this case, the relay communication device may act as a kind of central registry / broker of all downstream logical channel identifications. Allocating such a new upstream logical channel occurs when the relay communication device receives a request from a downstream communication device to create a new logical channel (e.g., via a direct (indirect) communication request) or receives a logical channel identification or logical channel identification mapping associated with one or more logical channels that have been created or are about to be created between two or more downstream communication devices. The relay communication device assigns a new / different logical channel identification value to a received logical channel identification from a downstream communication device in case it conflicts with another identification value of a logical channel of another downstream communication device. For this purpose, the relay communication device may maintain a mapping table between logical channel identifications received from different downstream communication devices and downstream communication device identifications to track overlaps and ensure that aggregation / decomposition is performed correctly, to ensure that duplicate logical channel identification values ​​are not used, or to track downstream communication device identifications that use the same logical channel identification value for each logical channel identification. In the case where the relay communication device assigns a new / different logical channel identification value, the relay communication device requests the downstream communication device to use the new / different logical channel identification value instead. The relay communication device reports to the upstream access device or upstream relay communication device the logical channel identification to which the received logical channel identification is assigned, indicating that this logical channel identification will be used for downstream and / or upstream and / or sidelink communications. Additionally, it reports the downstream communication device identifier, the requested desired data rate received from the downstream communication device, or an aggregate thereof, the (currently) used recommended data rate for a particular logical channel identification, and / or the mapping of the logical channel identification to other logical channel identifications.Optionally, it reports all non-overlapping logical channel identities (and their desired data rates) of all logical channels between the relay communication device and its downstream devices and all its downstream communication devices, or reports a mapping it maintains between logical channel identities and communication device identifiers included in the logical channels identified by the logical channel identities, or it reports a mapping from received logical channel identities to assigned logical channel identities. This allows a scheduling entity in the upstream access device or upstream relay communication device to individually identify each logical channel used among all downstream communication devices. The upstream access device or upstream relay communication device sends new data rate recommendations and / or limitations for the assigned logical channel identifications to the downstream communication devices, and by doing so triggers the relay communication device to derive / determine new data rate recommendations for the downstream devices.

[0018]

[0101] Some of the reasons why a relay communication device needs to make a new data rate recommendation for a downstream device are, for example, because the logical channel identification assigned by the relay communication device may be different from the logical channel identification used by the downstream communication device (e.g., as stored in a mapping table for mapping received logical channel identifications to assigned logical channel identifications), or because multiple downstream communication devices report the same logical channel identification and have been assigned the same overlapping logical channel identification values ​​(e.g., as stored in a mapping table for mapping received logical channel identifications to downstream communication device identifiers), or because it has multiple other downstream communication devices that it needs to serve via the same upstream logical channel, or because it has multiple downstream communication devices that it needs to serve via the same sidelink logical channel (e.g., if a downstream communication device served via a sidelink logical channel is a relay communication device connected to multiple downstream communication devices), or because it is temporarily unable to achieve the desired data rate, or because it needs to balance its data rates among different downstream communication devices. Determining the new data rate recommendation and / or limit includes creating a new message, the new message including the new data rate and / or limit, and / or including a logical channel identification that is different from the logical channel identification of the logical channel for which the (aggregate) data rate recommendation was received from the access device or upstream relay communication device, and / or including a destination that is different from the message received from the access device or upstream relay communication device including the (aggregate) data rate recommendation.

[0019] According to a first option combined with any of the first to fifth aspects above, the new data rate recommendation and / or limit is determined to be less than or equal to the received data rate recommendation and / or limit. This makes it possible to schedule a portion of the aggregate data rate recommendation and / or limit to the relay communication device itself. It also makes it possible, for example, to distribute the received aggregate recommendation among multiple downstream communication devices without retaining anything on the relay communication device itself.

[0020] According to a second option combined with the first option or any of the above first to fifth aspects, the aggregate data rate recommendation and / or restriction includes indicator data indicating whether the aggregate recommendation and / or restriction applies to an upstream data flow or a downstream data flow. Scheduling can thereby be separate for upstream and downstream, leading to more efficient schedules for both. By distinguishing (e.g., by flags) the upstream and downstream directions in the recommendation and / or restriction message, resource scheduling by the access device is made more efficient and more finely tuned with the separate upstream and downstream data flow recommendation and / or restriction.

[0021] According to a third option, which may be combined with the first or second option or any of the first to fifth aspects described above, a request for a desired data rate of an aggregate of logical channels is sent to an upstream relay communication device of the access device or relay communication device. Thus, data rate requests from downstream remote communication devices can be collected at the relay communication device and signaled to the access device or upstream relay (parent) communication device.

[0022] According to a fourth option, which may be combined with the first to third options or any of the first to fifth aspects described above, the desired data rate request of the aggregate of logical channels may be triggered by and at least partly based on at least one request for a desired data rate received from one of the one or more downstream communication devices. This criterion makes it possible to provide a triggering mechanism for the desired data rate request of the aggregate, which may be based on individual data rate requests of the remote communication devices.

[0023] According to a fifth option, which may be combined with the first to fourth options or any of the first to fifth aspects described above, a request for a desired data rate of a logical channel is received at a relay communication device from one of one or more downstream communication devices, wherein a data rate recommendation and / or limit for the logical channel is determined at the relay communication device based on the received request, and the determined data rate recommendation and / or limit is used by the relay communication device to comply with the request, whereby the relay communication device directly complies with the desired data rate request from the remote communication device.

[0024] According to a sixth option, which may be combined with the first to fifth options or any of the aforementioned first to fifth aspects, the relay communication device is configured to, in response to a data rate recommendation and / or limit received from an access device or an upstream relay communication device of the relay communication device and indicating an identification of a first logical channel, look up in an internal table an identification of a second logical channel for which to send a new data rate recommendation and / or limit to the corresponding downstream communication device and / or downstream communication device, or, in response to a desired data rate request received from one of one or more downstream communication devices and indicating an identification of the first logical channel, look up in an internal table an identification of a second logical channel for which to send a new request for the desired data rate to the access device or the upstream relay communication device of the relay communication device. Thereby, logical channel mapping can be applied in the relay communication device in the upstream and / or downstream direction to identify a target device for signaling the recommendation, limit or desired data rate.

[0025] According to a seventh option, which may be combined with any of the first to sixth options or the first to fifth aspects described above, the relay communication device is configured to create an additional logical channel on a wireless link with the access device or an upstream relay (e.g., its parent) communication device when it determines that a new logical channel has been created for a communication link with one of one or more downstream communication devices. This criterion ensures that channel mapping options are provided for all available logical channels. For example, a child communication device creates a new logical channel, and in response, the parent relay communication device adds the new logical channel on the upstream link.

[0026] Because a relay may have multiple parent communication devices, a new logical channel is created toward a first parent communication device while an aggregation recommendation is received from a second parent communication device. This can be achieved, for example, by 3GPP® dual connectivity mode (see 3GPP® specifications TS 23.504, TS 38.300, and TS 37.340), a mode of operation in which a multiple receiver (Rx) / transmitter (Tx)-capable UE in RRC connected mode can be configured to use the radio resources of two separate schedulers located at two access devices, i.e., a master gNB and a secondary gNB. In one example, logical channel identities (e.g., in a multi-hop relay topology) are centrally assigned (e.g., by a “root” relay communication device) to ensure that they do not overlap. For this purpose, the identity of the communication device associated with each logical channel identification needs to be communicated to a central assigning device (e.g., a “root” relay communication device). Thereby, one-to-one channel mapping can be provided to improve signaling efficiency. This mapping (or parts thereof) may also be transmitted to the upstream access device or relay communication device to enable the upstream access device or relay communication device to individually identify each downstream logical channel, or this mapping may be transmitted together or extended with the desired (aggregate) recommended data rate or the recommended data rates used for each logical channel identification as further input for the upstream access device or relay communication device.

[0027] According to an eighth option, which may be combined with any of the first to seventh options or the first to fifth aspects described above, an internal table is configured to map an identification of a logical channel between the relay communication device and an access device or an upstream relay (e.g., its parent) communication device to multiple identifications of logical channels between the relay communication device and one or more downstream communication devices, whereby one-to-many channel mapping may be provided to improve signaling efficiency.

[0028] Alternatively, a one-to-many mapping is provided that maps each logical channel identification to the identifier of the communication device that created the logical channel identification or to a set of identifiers of communication devices included in the logical channel identified by the logical channel identification. This mapping (or parts thereof) is also transmitted to the upstream access device or relay communication device, allowing the access device or relay communication device to individually identify each downstream logical channel. Alternatively, this mapping can be sent along with or extended with the desired (aggregate) recommended data rate or the recommended data rate being used for each logical channel identification as further input for the upstream access device or relay communication device.

[0029] According to a ninth option, which may be combined with any of the first to eighth options or the first to fifth aspects described above, the data rate recommendations and / or restrictions are transmitted using at least one of a Medium Access Control protocol, a Radio Link Control protocol, a Packet Data Convergence protocol, a Radio Resource Control protocol, and a Service Data Adaptation protocol. Thus, flexible rate signaling at different protocol levels may be provided.

[0030] According to a tenth option, which may be combined with any of the first to ninth options or the first to fifth aspects described above, the relay communication device is configured to collect information on at least one desired data rate received from one or more downstream communication devices, to transmit the collected information to an upstream relay communication device or access device, to receive received data rate recommendations and / or limits from the upstream relay communication device or access device, and to distribute the received data rate recommendations and / or limits at least partially among one or more downstream communication devices using a predetermined policy, which allows controlling the distribution of the aggregate data rate recommendations and / or limits among the downstream communication devices at the relay communication device.

[0031] According to an eleventh option, which may be combined with any of the first to tenth options or the first to fifth aspects, the relay communication device is configured to select a predetermined policy based on at least one of quality indicators of logical channels of the relay communication device, several downstream communication devices of the relay communication device, several upstream communication devices of the relay communication device, a type of the downstream communication device, policy selection information received from the upstream communication device or the access device, a quality of service identifier, a network slice identifier, and a buffer status of the relay communication device, whereby flexible distribution of aggregate data rate recommendations and / or limitations to downstream communication devices based on different criteria defined by the selected policies can be implemented.

[0032] According to a twelfth option, which may be combined with any of the first to eleventh options or the first to fifth aspects described above, the apparatus is configured to determine new data rate recommendations and / or limitations for one or more further downstream communication devices triggered by a loss of a communication link between the relay communication device and at least one other communication device or by a decision that said communication link should be terminated, and to transmit the further new data rate recommendations and / or limitations to the at least one downstream communication device.

[0033] It should be noted that the aforementioned apparatus may be implemented based on a discrete hardware circuit having an arrangement of discrete hardware components, integrated chips, or chip modules, or based on a signal processing device or chip controlled by a software routine or program stored in a memory, written to a computer-readable medium, or downloaded from a network, e.g., the Internet.

[0034] It will 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 have similar and / or identical preferred embodiments, in particular as defined in the dependent claims.

[0035] It will be understood that preferred embodiments of the invention can also be any combination of the dependent claims with the respective independent claim or the above-mentioned embodiments.

[0036] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiment(s) described hereinafter. [Brief explanation of the drawings]

[0037] [Figure 1] 1 illustrates a schematic representation of a network architecture in which the present invention may be implemented; [Figure 2] 1A and 1B illustrate block diagrams of access devices according to various embodiments. [Figure 3] 1A and 1B illustrate block diagrams of communication devices according to various embodiments. [Figure 4] 1 illustrates a flow diagram of an enhanced rate recommendation procedure according to various embodiments. [Figure 5] 1 illustrates a flow diagram of an aggregate desired rate reporting procedure in accordance with various embodiments. [Figure 6] 1 illustrates a schematic diagram of a network architecture with one-to-one channel mapping according to one embodiment. [Figure 7] 1 illustrates a schematic diagram of a network architecture with one-to-many channel mapping according to one embodiment. [Figure 8] 1 illustrates a schematic diagram of an example of a network architecture with one-to-many channel mapping, where a single logical channel represents relay data for a group of communication devices. [Figure 9]1 illustrates a schematic diagram of an example of a network architecture with one-to-one channel mapping with unique downstream logical channel identification. DETAILED DESCRIPTION OF THE INVENTION

[0038] Embodiments of the present invention are described herein based on resource scheduling in a 5G cellular network in which a UE-to-network relay function is enabled, where 4G network elements are incorporated into the proposed 5G solution. Furthermore, at least some of the embodiments described below are described based on 5G New Radio (5G NR) radio access technology. Specifically, the relay function enables multi-hop indirect network connectivity for remote communication devices (e.g., UEs). This is done specifically to achieve improved coverage of communication devices and improved low-power operation of IoT communication devices.

[0039] Throughout this disclosure, the abbreviations "eNB" (4G terminology) and "gNB" (5G terminology) are intended to refer to access devices such as cellular base stations or WiFi access points. A gNB consists of a centralized control plane unit (gNB-CU-CP), multiple centralized user plane units (gNB-CU-UP), and / or multiple distributed units (gNB-DU). An eNB / gNB is part of a radio access network (RAN), providing an interface for functioning in a core network (CN). The RAN is part of a wireless communications network. The RAN implements a radio access technology (RAT). Conceptually, the RAN lies between communication devices such as mobile phones, computers, or any remotely controlled machines and provides their connection to the CN. The CN is the core part of a communications network, providing multiple services to customers interconnected via the RAN. More specifically, the CN manages communication streams over a communications network or other network. In 3GPP® specifications TS 23.303 and TS 24.334 for 4G networks, a so-called proximity service (ProSe) function is defined to enable connectivity for cellular communication devices (e.g., UEs) that are temporarily not within the coverage area of ​​an access device (eNB). This specific function is called ProSe UE-to-network relaying, or relay UE. A relay UE is a relay communication device that helps another OoC UE (i.e., an indirectly connected remote communication device) communicate to an eNB (i.e., an access device) by relaying application and network data traffic in two directions (upstream and downstream) between the OoC UE and the eNB. The local communication between a relay UE and an OoC UE is called D2D communication, or sidelink communication, or PC5 communication. The abbreviation "PC5" designates the interface for sidelink communication in 5G networks as defined by ProSe and is also used to indicate sidelink communication of V2X (see 3GPP® specifications TS 23.287 / TR 37.985).Furthermore, the abbreviation "UL" is used for the uplink direction from a communication device (e.g., a UE) to an access device (e.g., an eNB, a gNB), the abbreviation "DL" represents the downlink direction from an access device (e.g., an eNB, a gNB) to a communication device (e.g., a UE), and the abbreviation "SL" represents sidelink communication between two or more communication devices (e.g., UEs).

[0040] Furthermore, the term "logical channel" generally refers to a logical channel of Layer 2. In an embodiment, a logical channel is, for example, a MAC logical channel, an RLC channel (i.e., an RLC bearer), or a radio bearer implemented by a PDCP entity.

[0041] After the relay relationship is established, the OoC UE is connected via the relay UE and acts as a "remote UE." In general, a UE can be connected to a network directly (direct network connection), or by using another UE as a relay UE (indirect network connection), or by using both types of connections. The term "upstream" is used for data directed to the access device or to indicate a communication device that is closer (in terms of number of hops) to the access device, while the term "downstream" is used for data flow from the access device directed to the communication device in the RAN or to indicate a communication device that is further away (in terms of number of hops) from the access device. The prefix "parent" refers to an upstream relay communication device used by a remote or relay communication device, and the prefix "child" refers to a downstream relay communication device directly connected (e.g., via a single wireless link) to a given relay communication device, or a downstream remote communication device that directly uses a particular relay communication device as a parent.

[0042] Ongoing standardization work (e.g., 3GPP® specification TR 22.866 v17.1.0) extends the concept of single-hop relaying to support communication via multiple wireless hops and the use of relays for commercial or IoT application areas. ProSe Release 15 simply allows relay communication devices to provide a single hop (access device) toward the network to allow remote communication devices to have an indirect network connection to an access device (e.g., eNB) and a 4G CN. 3GPP® Release 17 will define how ProSe, including relays, will operate in 5G networks when using 5GS (5G systems) and / or NR radio access technologies. For Release 18 and beyond, the goal is to enable multi-hop relaying for 5GS, where relay UEs can be connected to other relay UEs, etc.

[0043] Furthermore, 3GPP® specifications TR 23.733 v15.1.0 and TR 36.746 v15.1.1 provide research on architecture enhancements, for example, to enable IoT devices (remote UE role) to operate at very low power by using relay UEs to connect to the wider network. Because the relay UEs are physically very close, this can be achieved using very low-power transmissions. This work also includes security, speed, and stability improvements to ProSe. These extensions to ProSe are called enhanced ProSe ("eProSe").

[0044] One proposed improvement in eProSe is an enhanced relaying architecture that operates at the second protocol layer (i.e., L2). The new L2 architecture is intended to provide end-to-end Internet Protocol (IP) packet and Packet Data Convergence Protocol (PDCP) packet transmission of application and / or user data to a remote communication device. A benefit of this architecture is that the remote communication device becomes directly visible as a registered entity in the CN for monitoring and billing purposes, as well as for improved control by the access device via the communication device. The remote UE can access all the functionality of the CN and the access device (e.g., gNB) as if it were directly connected.

[0045] Furthermore, there is also an alternative proposal for Layer 3 (L3) relaying in ProSe5G that maintains the relaying mechanism similar to how it was in 4G. There is not yet a control plane stack defined in 3GPP documents for L3 relaying. Typically, the remote UE in this solution is ruled out, since it does not have a control plane connection with the CN, but only a control plane connection to its relay UE.

[0046] The element for implementing the scheduling mechanism may be a Radio Resource Control (RRC) protocol that can operate from end-to-end to the UE, potentially via one or more hops, taking into account the aforementioned new relay architecture of the second protocol layer (i.e., L2). It is used for non-time-critical, static or semi-static scheduling information. In other words, the configuration of the schedule. Here, ConfiguredGrantConfig is an information element for uplink or sidelink scheduling.

[0047] Another element for implementing scheduling mechanisms is the Control Element (CE) of the Medium Access Control (MAC) protocol, which is a short element (or Information Element (IE)) inserted between existing UL / DL / SL transmissions over the MAC layer, used to efficiently signal certain events, measurements or configurations. Further MAC CEs are used by access devices (e.g., gNBs) to control the behavior of communication devices (e.g., UEs) when performing various other 3GPP mechanisms, such as Channel State Information (CSI) reporting, Sounding Reference Signals (SRS), or Discontinuous Reception (DRX).

[0048] A further element is the use of Downlink Control Information (DCI), which is a short message sent on a low-bit-rate control channel (e.g., the Physical Downlink Control Channel (PDCCH)) with a special, blindly detectable modulation or coding. This mechanism is implemented at the physical protocol layer (PHY L1) and does not require the use of a MAC PDU header structure. Here, various DCI formats can be defined with different information contents. Communication resources for dynamic scheduling can be indicated in the DCI. DL data transmission follows the DCI message, for example, less than 1 ms later, but can be scheduled up to 4 ms in the future. For the UL, scheduling occurs for the next time slot 1-2 ms in the future, but can be up to 8 ms in the future.

[0049] A further factor is the use of uplink or sidelink control information (UCI, SCI), which includes, for example, a scheduling request (SR) bit that is used when communication resources are not available. In response to the SR, a scheduler in an access device (e.g., gNB) will allocate uplink communication resources for a prospective communication device (e.g., UE).

[0050] The resource scheduling overview above is applicable for communication devices (e.g., UEs) and can be used for multi-hop solutions as well. Thus, according to various embodiments, new network elements need to be added or existing elements need to be extended, as described below. When single or multi-hop relay communication devices are introduced into the network, then existing solutions may not be sufficient because they work with direct links between access devices (e.g., gNBs) and communication devices (e.g., UEs), and not necessarily with indirect links between access devices and communication devices via relays.

[0051] As mentioned earlier, the scheduler is expected to take care of a good match between the resource allocation and the recommended bitrate values ​​it sends to the UE. For example, the scheduler may assign a persistent schedule to a particular UE, meaning that the UE is granted a periodically cycling resource that allows it to send data at a bitrate roughly equivalent to the value recommended by the gNB.

[0052] This can be achieved, for example, by using a recommended bitrate MAC CE as defined in 3GPP® specification TS 38.321 v15.5.0, NR. This MAC layer CE can be used in the UL direction to indicate to the gNB / scheduler the UE's desired bitrate for UL data (originating from the UE) or for DL ​​data (going to the UE) of a particular logical channel ID (LCID). Furthermore, this MAC layer CE can be used in the DL direction as an indication from the gNB / scheduler of the recommended bitrate for UL data (originating from the UE) or for DL ​​data (going to the UE).

[0053] The Recommended Bit Rate MAC CE contains the LCID, i.e., the single logical channel that the request / recommendation holds. The LCID contains a "Bit Rate" field that is 6 bits long, where the bit values ​​are to be interpreted as in the following table:

[0054] [Table 1]

[0055] The gNB may send a recommended bitrate MAC CE to the UE based on its own decision - to provide a recommendation - and / or the UE may inquire about a recommendation for a particular LCID by sending a recommended bitrate MAC CE to the gNB and then including a desired bitrate value.

[0056] Note that in the 5G specifications, the recommended bit rate MAC CE is defined in a more general manner than in 4G. In the 4G specifications, it was specifically defined as an MMtel (Multimedia Telephony) specific feature in 3GPP® specification TS 36.331 v15.2.2 as "MMTEL-Parameters-r14" under General RAN Capabilities Signaling in RRC. In 5G, it was defined in 3GPP® specification TS 38.331 v15.5.1, NR, under "MAC-Parameters Common" under General RAN Capabilities Signaling in RRC. Using RRC, the eNB / gNB signals to the UE whether the recommended bit rate MAC CE is supported in the upstream direction (as a query towards the eNB / gNB) and / or the downstream direction (as a recommendation towards the UE).

[0057] FIG. 1 shows a schematic diagram of a network architecture having a relay communication device.

[0058] In the scenario shown in Figure 1, a 5G core network (CN) 100 is connected to multiple base stations (i.e., gNBs) 20 of the radio access network. A first UE 10-1 is directly or indirectly connected to each of the base stations 20 and acts as a relay UE configured to transport upstream data from two or more downstream UEs 10-D to the respective (serving) base stations 20 and downstream data from the respective base stations 20 to two or more downstream UEs 10-D. In the case of an indirectly connected first UE 10-1 (left branch of Figure 1), at least one parent UE 10-P is connected as a relay UE between the first UE 10-1 and the respective base stations 20.

[0059] Additionally, one or more downstream second UEs 10-2 within radio range (coverage) of each first UE 10-1 are provided, each acting as a remote UE or a relay UE or both and capable of connecting via a wireless link directly to the respective first UE 10-1 and indirectly via the relay function of the respective first UE 10-1 to a respective base station 20. Dotted lines indicate possible / optional links to further UEs (not shown).

[0060] The core network 100 includes network functions such as a network slice selection function (NSSF), a user plane function (UPF), a session management function (SMF), and an access and mobility management function (AMF).

[0061] According to various embodiments, the base station 20 or functionality in the core network operating via the base station 20 provides downstream data to a first UE 10-1 that includes a data rate recommendation and / or restriction for a logical channel ID (LCID). This data rate recommendation and / or restriction for a single LCID includes an aggregate data rate recommendation and / or restriction for at least two UEs. After receiving the aggregate data rate recommendation and / or restriction, the first UE 10-1 determines, based at least in part on the associated LCID, from which one of the second UEs 10-2 is to receive the new data rate recommendation and / or restriction. The first UE 10-1 then provides downstream data to at least one of the second UEs 10-2 that includes the new data rate recommendation and / or restriction based at least in part on the received aggregate data rate recommendation and / or restriction.

[0062] In one example where multiple second UEs 10-2 are provided, the new data rate recommendation and / or limit provided by the first UE 10-1 includes a recommendation and / or limit value that is lower than the aggregate recommendation and / or limit value included in the received data.

[0063] In another example, the new data rate recommendation and / or limit provided by the first UE 10-1 has a recommendation / limit value that is equal to the value of the aggregate data rate recommendation and / or limit included in said received data.

[0064] In a further example, the aggregate data rate recommendation and / or limit sent to the first UE 10-1 includes indicator data to indicate whether the aggregate data rate recommendation and / or limit applies to the upstream data flow or to the downstream data flow.

[0065] In a further example, the UE may send a desired data rate request for a collection of LCIDs to the base station 20 or to upstream UEs within its radio range.

[0066] In a further example, at least one of the second UEs 10-2 is arranged to transmit a desired data rate request for an LCID to the first UE 10-1, whereupon the first UE 10-1 responds to the request with data rate recommendations and / or restrictions for that LCID and optionally one or more other LCIDs.

[0067] In a further example, a first UE 10-1 is configured to send a desired data rate request for an LCID to an upstream UE (e.g., a parent UE 10-P) or base station 20 within radio range, where the request is triggered by and based at least in part on at least one desired data rate request received from a second UE 10-2. The upstream desired data rate request includes a single desired data rate for the LCID, where the single desired rate is an additive sum of multiple received desired data rates. If a lookup table of recommended and / or limiting values ​​is used in one embodiment, the additive sum (sum) of desired data rates sent to the upstream UE (e.g., a parent UE 10-P or base station 20) is an approximate value (e.g., the lowest value from the table that is at least equal to or greater than the sum of the desired data rates).

[0068] In one example, a first UE 10-1 (i.e., a relay UE) receives an aggregate data rate limit, e.g., 1 Mbps, from a parent UE 10-P or base station 20 and splits it into a first limit (e.g., 500 kbps) for use for itself and a second limit (e.g., 500 kbps) for use for one second UE (i.e., child UE) 10-2. Alternatively, in the case of a received aggregate rate recommendation, this is used for the first UE 10-1 itself (acting in the role of remote UE, i.e., acting as a data producer / consumer itself or in the regular UE role as a data producer / consumer) and the first UE's 10-1 child remote UE. In FIG. 1, the second UE 10-2, which itself has no further children, can be considered a remote UE. Of course, any distribution (e.g., 20% for itself and 80% for one downstream UE) can be implemented.

[0069] Furthermore, a relay UE is always enabled to function as a regular UE even in "directly connected" mode, and a relay UE may itself be enabled to function as a remote UE, and conversely, a remote UE may be enabled to function as a relay UE.

[0070] The aggregate data rate recommendation and / or restriction is interpreted by the first UE 10-1, and based on it, the first UE will generate and send new data rate recommendation and / or restriction to at least one downstream device. In this respect, it should be noted that a distinction needs to be made between Layer 3 (L3) or higher data (e.g., NAS and user data) that is forwarded to downstream UEs and newly created Layer 2 (L2) MAC-CE elements that are not forwarded. How the creation works depends on the technical solution of the relay function. In an L2 relay architecture, the first UE 10-1 must also add an RLC channel (since RLC operates via only one hop) to send the new data rate recommendation. This can be automatic or triggered by the RRC setup procedure. For example, in an L2 relay solution, the first UE 10-1 receives an RRCrlc-BearerToAddModList element or a similar element defined for sidelink radio link control (RLC) channel creation, in response to which the first UE 10-1 will create the RLC channel and its associated logical MAC channel ID.

[0071] Furthermore, the aggregate data rate recommendation and / or restriction may be passed downstream hop-by-hop to the first UE 10-1 by at least one relay UE (e.g., parent UE 10-P in the left branch of FIG. 1). In such a case, the first UE 10-1 receives the aggregate data rate recommendation and / or restriction from the base station 20 via the relay function of at least one relay UE, which may have been modified by the at least one relay UE during movement. Thus, the first UE 10-1 receives its aggregate data rate recommendation and / or restriction directly from at least one upstream relay UE and is unaware that it comes from the base station 20.

[0072] In examples, the aggregate data rate recommendation and / or limit may be created by the parent UE 10-P (e.g., in methods such as MAC CE recommended bit rates) or directly by the access device 20 (e.g., sent via RRC over multiple relay hops to a relay UE 10-1). In both cases, a message conveying the aggregate data rate recommendation and / or limit is sent by the parent UE 10-P to the first UE 10-1, while the creator of the message may be different.

[0073] FIG. 2 illustrates a block diagram of a relay communication device according to various embodiments.

[0074] Please note that only the blocks relevant to the proposed enhanced rate recommendation function are shown in Figure 2. Other blocks have been omitted for the sake of brevity.

[0075] The relay communication device of FIG. 2 corresponds to the first UE 10-1 of FIG. 1 or any other type of relay communication device for any wireless network having data rate recommendation and / or restriction functionality.

[0076] 2, the relay communication device includes a transceiver unit (TRX) 21 for transmitting and receiving wireless messages and / or other wireless signals via an antenna. Messages with new data rate recommendations or limitations are created by an individual data rate recommendation and / or limitation creator (IDR-R / L) 24 based at least in part on a logical channel identification (ID) (e.g., LCID) derived by a channel detector (CH-ID) 22 from an aggregate data rate recommendation and / or limitation received by the transceiver unit 21 from an access device (e.g., base station 20 of FIG. 1) or another upstream communication device (e.g., parent UE 10-P of FIG. 1).

[0077] Furthermore, the relay communication device comprises a memory having a look-up table (LUT) 25 providing a mapping table between the logical channel IDs of the parent (upstream) device and the associated logical channel IDs of the child (downstream) device and / or remote downstream communication devices.

[0078] Based on the information provided in the mapping table of the lookup table 25 and the aggregate data rate obtained from the received data rate recommendation and / or limit, the individual data rate recommendation and / or limit creator 24 creates a new data rate recommendation and / or limit for at least one of one or more downstream communication devices and transmits the new data rate recommendation and / or limit to the derived downstream communication device and / or to downstream communication devices listed in the mapping table in association with the received logical channel ID via a logical channel having the derived logical channel ID. The transmission may be direct or indirect (e.g., via multiple hops and / or via a network function). The relay communication device creates the new data rate recommendation and / or limit taking into account its own desired data rate and / or data rate limit.

[0079] Thereby, enhanced data rate recommendations and / or restrictions may be provided whereby directly and indirectly connected relay communication devices are taken into account together via a mapping table.

[0080] FIG. 3 illustrates a block diagram of an access device according to various embodiments.

[0081] Please note that only the blocks relevant to the proposed enhanced recommendation feature are shown in Figure 3. Other blocks have been omitted for the sake of brevity.

[0082] The access device of FIG. 3 corresponds to base station (gNB) 20 of FIG. 1 or any other type of access device for any wireless network with resource scheduling functionality.

[0083] According to FIG. 3, an access device includes a transceiver unit (TRX) 31 for transmitting and receiving wireless messages and / or other wireless signals via an antenna. Messages having aggregate data rate recommendations and / or limitations are generated by an aggregate data rate recommendation and / or limitation creator (ADR-R / L) 34 based on a logical channel ID (e.g., LCID) derived by a channel detector (CH-ID) 32 from an aggregate desired 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 of FIG. 1) may also send these data rate recommendations and / or limitations autonomously. In this case, the channel detector 32 is guided not by the received “desired data rate” message but by other considerations (e.g., available resources and their fair distribution).

[0084] Furthermore, the access device includes a memory having a look-up table (LUT) 35 that provides a mapping table between logical channel IDs and associated directly and indirectly connected remote downstream communication devices. The mapping table is one table defined for each directly connected communication device (e.g., 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 at its disposal for communication with the access device, i.e., there is no contention for logical channel IDs among these communication devices. Alternatively, the mapping table can be implemented as one table for all communication devices. In that case, for example, there is one entry for each communication device, and the logical channel identifiers of the directly connected communication devices can be associated with each table entry, and the identifiers of the directly connected communication devices can be associated with each table entry. Thus, for example, LCID4 is mapped to remote UE {x, y, z} of directly connected relay UE 1 and similarly mapped to different remote UE {a, b} of directly connected relay UE 2.

[0085] Based on the received logical channel ID and the aggregate desired data rate, the aggregate data rate recommendation and / or limit creator 34 creates at least one aggregate data rate recommendation and / or limit for a downstream communication device based on information in the mapping table and transmits the at least one aggregate data rate recommendation and / or limit over the logical channel having the received logical channel ID. Thus, when it sends a particular logical channel ID to a particular directly connected relay communication device, the mapping table is used by the access device to derive the communication device to be addressed. The transmission may be direct or indirect (e.g., across multiple hops and / or via a network function).

[0086] Thereby, enhanced data rate recommendations and / or restrictions are provided whereby directly and indirectly connected relay communication devices are taken into account together via a mapping table.

[0087] The individual blocks of the block diagrams of Figures 2 and 3 may be implemented by discrete 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 processors (DSPs) or other software controlled processor circuits.

[0088] FIG. 4 illustrates generally a flow diagram of an enhanced rate recommendation and / or restriction procedure according to various embodiments, implemented in an intermediate communication device (eg, first UE 10-1 of FIG. 1) of a cellular or other wireless network.

[0089] In a first step S401, the relay communication device receives an aggregate data rate recommendation and / or limit from a parent communication device or access device. Then, in step S402, a logical channel ID (e.g., LCID) is derived from the received aggregate data rate recommendation and / or limit. In step S403, associated logical channel IDs of downstream devices and / or associated remote communication devices are derived from a mapping table available in the relay communication device. Then, in step S404, new data rate recommendations and / or limits with associated logical channel IDs are created based at least in part on the received aggregate data rate recommendation and / or limit and the associated logical channel IDs 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.

[0090] Finally, in step S405, the generated new data rate recommendations and / or limits are transmitted to one or more downstream communication devices.

[0091] FIG. 5 illustrates a flow diagram of an aggregation desired rate reporting procedure according to various embodiments, implemented in an access device (e.g., base station (gNB) 20 or eNB or access point of FIG. 1) of a cellular or other wireless network.

[0092] In a first step S501, the access device receives a desired data rate for an aggregate of logical channels from a downstream communication device. Then, in step S502, a logical channel ID (e.g., LCID) for the associated logical channel is determined. In step S503, a mapping table is consulted to derive from the determined logical channel ID associated directly and indirectly connected downstream communication devices. Then, in step S504, an aggregate data rate recommendation and / or limit is made based at least in part on the received aggregate desired data rate and the associated directly and indirectly connected downstream communication devices.

[0093] Finally, in step S505, the generated aggregate data rate recommendation and / or limit is transmitted to the associated downstream communication device, i.e., back to the requesting device, either as a single-hop transmission over a logical channel, e.g., in a MAC CE, or as a potentially multi-hop transmission, e.g., in an IP packet, PDCP PDU, or RRC message.

[0094] Of course, the initial query of the desired data rate triggered a change in resource allocation so that recommendations and / or limits are sent not only to the requesting communication device but also to other downstream devices, and data rate recommendations and / or limits are sent not only to the requested logical channel but also to other logical channels.

[0095] It should be noted that the steps of the flowcharts of Figures 4 and 5 are 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 embodiments, the transmission of the new and / or aggregate data rate recommendation or limit and / or aggregate desired data rate is accomplished by at least one of the following options: 1. In the case of an L2 relay architecture, the RRC protocol is used end-to-end between the relay communication device and the access device. RRC messages are transported via PDCP via Radio Link Control (RLC) via MAC protocol, potentially over multiple hops. This option has the advantage that transport reliability is guaranteed (via PDCP, using retransmissions) and integrity protection is applied. RRC is extended with additional messages or fields to carry data rate recommendations and / or constraints. Furthermore, RRC PDUs may carry PDUs of other higher layer protocols, such as NAS protocol containers (e.g., N1 SM containers) or IPv4 / IPv6 packets containing transmitted data rate recommendations and / or constraints or desired data rates. RRC over sidelink may also be used, for example, using an extended RRCReconfigurationSidelink message, as defined in 3GPP specification TS 38.331. 2. PDCP control or data PDUs are used, for example, by defining new PDCP messages to carry data rate recommendations and / or restrictions. PDCP PDUs in turn carry PDUs of other higher layer protocols, e.g., SDAP, IPv6, or IPv4, that contain transmitted data rate recommendations and / or restrictions or desired data rates. As an example, SDAP header data is used, for example, by defining new SDAP header fields to carry data rate recommendations and / or restrictions. 3. A MAC Control Element (CE) is used. This is a lightweight method, where it is even possible to advantageously use unused space in a transport block, as achieved, for example, by a "padding BSR" MAC CE. It also uses an extended MAC CE element, e.g., an extended Recommended Bit Rate MAC CE, with, for example, an additional field to indicate whether the recommended bit rate relates to the downstream / upstream direction (or to identify whether it is in the uplink / downlink or sidelink direction), and possibly additional fields to indicate / identify the downstream UE for which the LCID value is intended and / or the identity (e.g., L2 identity) of the downstream UE between which the logical channel identified by the LCID value has been or will be established. The Recommended Bit Rate MAC CE is also extended to aggregate / combine multiple LCIDs and corresponding bit rate values ​​into a single message. The Recommended Bit Rate MAC CE is also extended to include a single bit or flag to identify whether the control element is a recommendation or a query. 4. An enhanced uplink or downlink control information (UCI, DCI) data format is used that is sent directly between the relay communication device and the access device over the UL or DL ​​channel (e.g., via a physical uplink / downlink control channel (PUCCH, PDCCH) or a physical uplink / downlink shared channel (PUSCH, PDSCH)). 5. In an extended sidelink control information (SCI) data format sent by a relay communication device to another relay communication device over an SL connection. 6. A combination of the above options by transmitting directly to or from the access device via RRC and also directly via MAC CE via a single radio hop to an upstream or downstream relay communication device, or, for example, via MAC CE to a relay communication device that then collects one or more desired data rate reports from child relay communication devices and sends these using RRC as the aggregate desired data rate directly to the access device.

[0096] FIG. 6 illustrates schematically a network architecture with one-to-one mapping between LCIDs in a first UE according to one embodiment.

[0097] In this embodiment, a one-to-one mapping is implemented in the first UE (UE1) between the LCIDi used between the first UE and its parent node (UE0) and the LCIDj used between the first UE (UE1) and the second UE (UE2, UE3), respectively, where the second UE is a relay UE (UE2), a remote UE (UE3), or both (UE2). In the example of Figure 6, the second UE (UE2) also obtains its own LCID for its own data, and therefore includes both functionality.

[0098] This implies that when a first UE (UE1) receives a data rate recommendation or restriction from its parent node (UE0) indicating LCIDi, UE1 can look up in its internal mapping table 25 the corresponding second UE (UE2 and / or UE3) and the LCIDj that identifies the logical channel for sending the new data rate recommendation or restriction to the second UE. Conversely, when a first UE (UE1) receives a desired data rate request from a second UE (UE2 or UE3) indicating LCIDj, it can look up in its mapping table 25 the corresponding LCIDi for use when sending a new desired data rate request to its parent node (UE0), where the desired data rate value is based at least in part on the value received from the second UE.

[0099] When the LCID values ​​as defined in 3GPP® Release 15 (e.g., Tables 6.2.1-1 and 6.2.1-2 of 3GPP® specification TS 38.321 v15.7.0) for downlink and uplink communications are also used for sidelink communications, the LCIDs may be in the range of 1 to 32. In that case, in this embodiment, a first UE (U1, relay UE) can support at most 32 second UEs, if each second UE requires at least one associated LCID of an assigned logical channel for the communication link between the first UE and its parent node (UE0) to be able to communicate via the logical channel. A larger number of LCID values ​​for uplink and downlink are defined in 3GPP® Release 16 (e.g., Tables 6.2.1-1 / 1a / 1b and 6.2.1-2 / 2a / 2b of 3GPP® Specification TS 38.321 v16.0.0) through the eLCID extension mechanism (adding channel ranges 320 to (2^16+191)). This allows a directly connected relay UE (e.g., UE0) to support a very large number of child UEs (e.g., relay UE1 or remote UEs). Because relay UEs, remote UEs, and access devices support different versions of the relevant standards, some of these devices have different constraints regarding the number of LCIDs they understand and support. For example, a Release 16 UE only supports LCID identifier values ​​"4" to "19" for sidelink communication (see Table 6.2.4-1 of 3GPP® Specification TS 38.321 v16.0.0). If a remote UE or relay UE supports the expanded number of LCIDs provided by the eLCID extension mechanism, while a downstream remote UE or relay UE, or an upstream relay UE, supports only the limited number of LCIDs in Release 16, a map is created in the relay UE that maps the limited number of LCIDs to multiple LCIDs, for example by assigning a different LCID for each downstream UE that supports only the limited number of LCIDs and that instead reports the new LCID to the upstream access device or relay UE.In this way, older remote or relay UEs can be supported in a backward-compatible manner. To this end, the mapping also includes for each downstream UE the number of LCIDs it supports, or the version of the standard it supports (e.g., 3GPP uses "capability reporting" for this, and is therefore closer to a flag stating "supports extended: true"). The allocation of new LCIDs takes this into account, for example, reserving only values ​​"4" through "19" for allocation to older downstream UEs and reserving an extended set of values ​​for newer downstream UEs. Similarly, if an upstream UE or access device can only handle LCID values ​​"4" through "19," then the LCID for any upstream logical channel must be chosen from among those values. When a second UE (either a relay UE (UE2) or a remote UE (UE3) or both (UE2)) creates an additional upstream logical channel identified by LCIDj, this embodiment implies that the first UE will need to create an additional logical channel with LCIDi on the wireless link with its parent node. Relay data traffic coming from LCIDj of the second UE will then be transported via logical channel LCIDi, and conversely, incoming relay data via LCIDi, if forwarded, will be sent to the second UE via LCIDj. Any bit rate recommendation or limit received for LCIDi will then trigger the creation of a new data rate recommendation and / or limit to be sent to the second UE indicating LCIDj and indicating a recommendation or limit value usually equal to the received value.

[0100] It should be noted that the second UE can also act like the first UE and use the mapping table to optionally implement the proposed enhanced recommendation or restriction procedures.

[0101] The base station (gNB) 20 can send downstream data rate recommendations and / or limitations, e.g., to a directly connected UE (UE0), e.g., using a recommended bitrate MAC CE. The directly connected UEs receiving these data rate recommendations and / or limitations can send new data rate recommendations to a first UE (UE1), e.g., using an equivalent sidelink recommended bitrate MAC CE, and / or new data rate limitations to the first UE (UE1), e.g., sending an equivalent sidelink bitrate limitation MAC CE. The first UE (UE1) receiving these recommendations and / or limitations can send new data rate recommendations to downstream second UEs (UE2, UE3) using the sidelink recommended bitrate MAC CE. Of course, other methods can also be used, as shown in the embodiments described below.

[0102] In one embodiment, in response to determining that a downstream UE of the first UE (e.g., a second UE (UE2, UE3)) requires a new logical channel and / or determining that a new relay or remote UE downstream of the first UE (e.g., UE2, UE3, or UE4) is added to the network topology, the relay UE base station (gNB) 20 requests the first UE (UE1) to create a new radio bearer (e.g., a data radio bearer, DRB) or a new RLC channel using an RRC reconfiguration message sent from the base station 20 to the UE. Using an RRC message requires control plane connectivity between the base station 20 and the first UE. The request triggers the creation of a new logical channel in the first UE, associated with the new radio bearer.

[0103] In another embodiment, the first UE requests the core network (CN) 100 to establish a new PDU session after creation of a new radio bearer for the first UE or when it determines that a downstream UE requires a new logical channel and / or determines that a new relay UE or remote UE downstream of the first UE is added to the network topology. This requires control plane connectivity between the base station 20 and the first UE. If the core network accepts the new PDU session, the first UE uses this PDU session to relay data traffic between this particular downstream UE and the core network.

[0104] In yet another embodiment, when RRC cannot be used, e.g., because there is no control plane connectivity, self-selection of the LCID of the sidelink communication channel by one of the involved UEs, e.g., by the first UE or by the UE needing the new logical channel or by the parent relay UE of the UE needing the new logical channel, may be used, or any other mechanism considered in 3GPP for LCID selection for ProSe-D2D / V2X-SL communication. One possible implementation could also be that only relay UEs that are directly within radio range of the base station 20 implement an embodiment using RRC messaging, while other UEs that are not within radio range of the base station 20 implement other embodiments.

[0105] Thus, a radio bearer is created at the request of the base station 20, the communication device (UE) requests a new PDU session, or the communication device selects an LCID itself. These options can also be combined depending on what architecture choice is made (L2 / L3) and further solution choices, and whether an intermediate communication device (e.g., a first UE) is directly or indirectly connected to the base station 20.

[0106] Optionally, the first UE sends a lower recommendation or limit value to the second UE instead of "equal" as defined previously. This is useful, for example, if the first UE has limited buffer space available and needs to reduce its current buffer size but still wants to serve the second UE. Or, if the first UE uses part of the capacity on channel LCIDi for its own purposes, which of course may only be possible if sharing of a single logical channel (and corresponding Data Radio Bearer, DRB) is to be allowed by the 3GPP specifications.

[0107] The proposed one-to-one mapping between the logical channel (LCIDi) of the parent communication device (P-CD) and the logical channel (LCIDj) of the child communication device (CH-CD) in the 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 parent relay UE (UE0 in FIG. 6) of the first UE (UE1). In the mapping table 25 of the first UE (UE1) in FIG. 6, the parent communication device (UE0) created logical channels P-LCID1, P-LCID3, P-LCID4, and P-LCID5 for the first UE (UE1), and the first UE (UE1) as a child communication device created logical channels CH-LCID3, CH-LCID4, CH-LCID4′, and CH-LCID9 for the second UEs (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 child UE side (e.g., because UE1 is using this CH-LCID5 for its own data communication in the role of remote UE). Note that the two CH-LCID4s shown in Figure 6 are two separate logical channels (the first CH-LCID4 between UE1 and UE2 and the second CH-LCID4' between UE1 and UE3). The LCID included in the MAC subheader uniquely identifies a logical channel within the combination of source layer 2 ID and destination layer 2 ID.

[0108] When an upstream node (UE0) wants to recommend a data rate for a particular downstream remote UE (UE3 or UE4 in Fig. 6), the upstream node (UE0) can send a sidelink recommended bitrate MAC CE for a particular logical channel P-LCIDi (e.g., P-LCID1 in Fig. 6) associated with the remote UE. If CH-LCIDj (e.g., CH-LCID4' in Fig. 6) in its mapping table 25 relates to the directly connected remote UE (UE3), the first UE (the relay UE 1) will then use this same recommended value in a new recommendation sent directly to the remote UE (UE3), for example, by using the sidelink recommended bitrate MAC CE. Alternatively, if the remote UE (UE4) is indirectly connected to the first UE, then CH-LCIDj (e.g., CH-LCID4 in Fig. 6) will point to the next downstream relay (UE2) that the indirectly connected remote UE (UE4) is using in its data relay path. The first UE (UE1) will then send the recommendation directly to the next hop relay UE (UE2) on its way towards the remote UE (UE4), for example by using the new sidelink recommended bit rate MAC CE. The next hop relay UE (UE2) will also apply the same algorithm as the first UE (UE1), so that the recommendation will eventually reach the targeted remote UE (UE4).

[0109] The above use case assumes that a standard mechanism exists by which an upstream node (e.g., base station (gNB) 20 or parent relay UE (UE0)) can learn the exact mapping between each LCIDi and the corresponding child UE. This can be achieved, for example, for a base station (gNB): each new remote UE joining the network registers itself with the base station using RRC signaling. In response, the base station uses RRC signaling to create a new data radio bearer (DRB) between itself and the remote UE, as well as any new logical channels (e.g., MAC logical channels and / or RLC channels) required in all relay UEs upstream of the new remote UE; the base station also performs, via the same RRC signaling, the mapping table 25 configuration as required in all these relay UEs. In this case, the base station organizes the entire configuration so that the base station can learn the exact mapping in this way. It can also be achieved, for example, in the absence of control plane connectivity between the base station and the remote UEs, as follows: each new remote UE joining the network registers itself 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 others. The parent relay UE assigns a new logical channel to the new downstream child remote UE. If the parent relay UE is not directly connected to the base station, it reports the logical channel assignment to its next upstream parent relay UE using the same or similar D2D communication. This next parent, in turn, creates a new logical channel toward the reporting relay UE. This next parent, in turn, reports the new logical channel assignment to its next upstream parent relay, and so on. The final relay UE directly connected to the base station reports the collective collected information on logical channel identification and configuration to the base station, for example, using RRC signaling, and it initiates the process to create a new PDU session via the core network functions.The core network then sends a decision regarding the creation of a new PDU session to the base station (gNB) 20, which will also be sent to the requesting relay UE via the base station (gNB) 20. The base station can allocate a specific data radio bearer with the relay UE's own LCID for the new PDU session (one bearer is associated with one or more LCIDs depending on the bearer properties). In this way, the core network can recognize the active remote UEs for a given relay UE, and the base station (gNB) 20 can also recognize these relay UEs and know their associated LCIDs.

[0110] Optionally, the first UE (UE1) aggregates multiple desired bit rate messages received from downstream UEs, e.g., using recommended bit rate MAC CE from child UEs or other means. The first UE reports these values ​​upstream by mapping the CH-LCIDj from which it received the message to the corresponding upstream P-LCIDi, to which a new reporting message with the aggregated desired bit rate is to be transmitted, e.g., at a future time. Specific trigger conditions and / or timers can govern the time of upstream transmission. Multiple reports with desired bit rate messages for multiple P-LCIDi are aggregated into a single upstream message.

[0111] If a first UE (UE1) does not find a match in the mapping table 25 towards a downstream second UE (UE2 or UE3), this may be handled as follows:

[0112] If the P-LCIDi is used for the first UE's own communication, then the P-LCIDi uses the aggregate bit rate recommendation itself.

[0113] Alternatively, 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 unresponsive, the first UE (UE1) can ignore the recommendation message for this P-LCIDi for a certain period of time. At some point, the base station (gNB) 20 will notice the new situation and request removal of the P-LCIDi since the channel is no longer needed. Alternatively, the first UE (UE1) can return an error message report for the P-LCIDi (e.g., included in a future / next MAC PDU to be sent) to the upstream UE (UE0) or the base station (gNB) 20 immediately or at a future time. Alternatively, the first UE itself can initiate a procedure to remove or deactivate the logical channel indicated by the LCIDi and / or its associated data radio bearer. Alternatively, the first UE itself can initiate a procedure to stop the PDU session associated with the P-LCIDi, if any, since it is no longer needed since the remote UE has disconnected. Optionally, the first UE sends new data rate recommendations to one or more of its remaining downstream remote / relay UEs triggered by a determination that one of its downstream UEs has left, disconnected (e.g., voluntarily), been handed over to another parent device (e.g., another relay UE or gNB) via a handover procedure (e.g., initiated by the gNB or by the downstream UE itself), or become unresponsive. This allows the first UE to quickly redistribute previous recommendations received from upstream devices to its remaining connected downstream devices (UEs) in an optimal manner given the new network topology situation, for example, without having to wait until the upstream device sends its next data rate recommendation.

[0114] Otherwise, if P-LCIDi is completely unknown or unexpected, the first UE (UE1) will ignore the message, which is an error situation that is not expected to occur frequently.

[0115] The second UEs (UE2, UE3) remain connected to the first UE (UE1) as its parent relay and apply 3GPP power saving methods. Therefore, it happens that the second UE to which the recommendations / restrictions need to be delivered is unavailable at the time when the first UE wants to send the recommended / restricted bit rate.

[0116] If the second UE is unavailable due to DRX or eDRX or PSM, then the first UE should cache the recommendations / restrictions and wait until the next opportunity when (1) data is to be sent to the second UE, i.e., MAC PDU, or (2) the second UE wakes up again and starts sending new data, i.e., MAC PDU, to the first UE, and then sends the recommendations / restrictions. In case 1, it is included, for example, as a MAC CE inside the sent MAC PDU. In case 2, it is included, for example, as a MAC CE in the MAC PDU sent to the second UE following the event of a MAC PDU sent by the second UE to the first UE after waking up, or as part of an ACK message sent by the first UE to the second UE to acknowledge receipt of the data or MAC PDU.

[0117] If the second UE is still unavailable while a new recommendation is received by the first UE from the upstream node, then the old cached recommendation may be discarded.

[0118] If the second UE is unavailable for an extended period of time, the second UE may have moved away and the corresponding options described above for the case of an unavailable downstream second UE may be provided.

[0119] FIG. 7 illustrates schematically a network architecture with one-to-many mapping between logical channels (LCIDs) in a first UE (UE1) according to various embodiments.

[0120] For this embodiment, the previous embodiment of Fig. 6 can be considered as a starting point, where the difference is that a one-to-many mapping is performed in the first UE (UE1) between the P-LCIDi (e.g., P-LCID1, P-LCID3, P-LCID4 and P-LCID15 in Fig. 7) used between the first UE and its parent node (UE0) and the CH-LCIDj (e.g., CH-LCID2, CH-LCID3, CH-LCID8, CH-LCID9, CH-LCID17, CH-LCID18, CH-LCID23 and CH-LCID29 in Fig. 7) used between the first UE and the second UEs (UE2 to UE6), respectively.

[0121] This implies that when a first UE (UE1) receives a data rate recommendation from its parent node (UE0) indicating P-LCIDi, UE1 can search in its internal mapping table 25 for potentially multiple corresponding second UEs and potentially multiple corresponding CH-LCIDj that identify the logical channel to which the new data rate recommendation should be sent.

[0122] 7, the single aggregate data rate recommendation received from upstream P-LCID1 can be mapped to five downstream second UEs (UE2, UE3, UE4, UE5, and UE6) with respective CH-LCID8, CH-LCID17, CH-LCID23, CH-LCID2, and CH-LCID29. P-LCID1's single data rate recommendation of 3000 kbit / s then maps to five downstream data rate recommendations ("REC" in mapping table 25): 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.

[0123] In one example, the first of these downstream UEs (UE2) is given priority based on some quality of service (QoS) related policy implemented by the first UE, as will be described later. Any quality indicator of a logical channel (upstream, downstream, relay-related, non-relay-related, etc.) or multiple quality indicators coming from multiple logical channels can be used by the first UE (UE1) for policy enforcement.

[0124] An alternative policy may allocate more bitrate to UE2 and UE6 since they are relays with further downstream UEs (UE7, UE8) and therefore may potentially have higher needs for bandwidth.

[0125] In another example, a single aggregate data rate recommendation received on or indicating logical upstream channel P-LCID1 may map to two second UEs, the first one having three logical downstream channels CH-LCID8, CH-LCID9, and CH-LCID10, and the second one having one logical downstream channel CH-LCID16.

[0126] Conversely, when a first UE (UE1) receives a desired data rate request from a second UE indicating CH-LCIDj, UE1 can look up the corresponding P-LCIDi in mapping table 15 for use when sending a new desired data rate request to its parent node (UE0), where the desired data rate value is based at least in part on the value received from the second UE.

[0127] When a new second UE (relay (e.g., UE2 and UE6) or remote (e.g., UE3 to UE5) or both) connects to the first UE (UE1), this embodiment does not require that the first UE would request an additional logical channel with a new P-LCIDi on the wireless link with its parent node (UE0). The relay data traffic of the new second UE can in principle be transported via the existing logical channel (e.g., P-LCID1) between the first UE (UE1) and its parent node (UE0).

[0128] Optionally, the first UE (UE1) sends downstream recommendation / limit values ​​to the second UE, the sum of which is lower than the aggregate recommendation / limit value received from the upstream device. This is useful, for example, if the first UE (UE1) has limited buffer space available and needs to reduce its buffer size, or if UE1 needs to use some capacity of the same upstream P-LCIDi itself. As an alternative option, a table is used that maps bitrate ID values ​​to actual bitrates. The sum of the recommendations sent downstream must then not exceed the received aggregate recommendation value.

[0129] Optionally, the first UE (UE1) does not send further downstream recommendations / restrictions to the second UE if the recommendations do not deviate significantly from the previous recommendations / restrictions sent to the second UE.

[0130] In one embodiment, the first UE (UE1) performs bitrate fair sharing among multiple downstream UEs. As an example, all relay / remote UEs (UE2 to UE8) use the sidelink recommended bitrate MAC CE or another MAC CE in their communications with upstream and downstream nodes.

[0131] The first UE (UE1) is then configured to carry relay-related data traffic upstream via one or more separate logical channels, while the first UE's (UE1) own data (not related to the relaying operations performed by the first UE) to / from the base station (gNB) 20 is transferred using a different logical channel.

[0132] When a first UE (UE1) receives a sidelink recommended bit rate MAC CE from its upstream node (UE0) and the included P-LCIDi is a relay-related logical channel, then UE1 first identifies the set of all associated downstream UEs that stream their data through this logical channel.

[0133] Assume that a first UE (UE1) receives a recommended data rate value Vrec for this logical channel P-LCIDi. UE1 then maps every set member of LCID to downstream CH-LCIDj (which can be the same or different values) and sends a Recommended Bit Rate MAC CE to every member containing the new recommended value Vrec_i≦Vrec, where the sum of all Vrec_i over i does not exceed the value Vrec.

[0134] Thereby, the available data rate recommendations can be distributed across potentially multiple sets of downstream UEs.

[0135] Such distribution can be done fairly by using the previously received desired data rate of each set member (i.e., downstream UE) to guide the distribution of the recommended data rate (e.g., using the recommended data rate query mechanism as described above). That is, a UE in the set that desires twice the data rate of another UE in the set will receive approximately twice the recommended data rate of the other UE.

[0136] FIG. 8 illustrates schematically an example of a network architecture with one-to-many channel mapping, where a single logical channel represents relay data for a group of communication devices.

[0137] In one embodiment of Figure 8, a first UE (UE1) sends an aggregate desired data rate request to base station (gNB) 20, which responds with an aggregate suggested data rate, where a policy is used to distribute the data rate suggestions to downstream UEs. This embodiment involves collecting several desired data rates received from downstream UEs, then sending the combined number (aggregate desired data rate) to base station (gNB) 20, and then receiving a total suggested data rate value (aggregate data rate suggestion) from base station (gNB) 20, which is then distributed to the downstream UEs using the policy.

[0138] In the example of Figure 8, a single logical channel P-LCID5 used by a first UE (UE1) indicates all relayed data of a group of UEs consisting of all downstream UEs of the first UE (UE1). To achieve this, the mapping table 25 of the first UE (UE1) maps the logical parent channel P-LCID5 to a group of all downstream UEs (UE2 to UE4) denoted by "A" in the mapping table. Additionally, the logical parent channel P-LCID1 is used for the first UE's (UE1) own data (OD).

[0139] Furthermore, the mapping table 25 of the parent relay UE (UE0) maps the logical parent channels P-LCID25, P-LCID26 and P-LCID27 to the parent relay UE (UE0), the logical channel CH-LCID5 of the child device UE1 and the logical channel CH-LCID1 of the child device UE1, respectively, where the logical parent channel P-LCID25 is used for the parent relay UE (UE0)'s own data (OD).

[0140] The first UE (UE1) sends an aggregate desired bit rate value upstream (e.g., indicating logical channel P-LCID5) that is approximately the sum of the desired bit rates received from multiple child UEs (relay and / or remote) assigned to the same upstream logical channel P-LCID5 of the first UE (UE1).

[0141] The parent relay UE (UE0) receives the aggregate desired bit rate value from the first UE (UE1) and sends the same value as the aggregate desired bit rate of the logical channel P-LCID26 upstream to the base station (gNB) 20.

[0142] The base station (gNB) 20 receives one aggregate desired total bit rate message with LCID information included in the message indicating the P-LCID 26 and enabling it to determine for which group of UEs (UE2 to UE4 circled as a group in Figure 8) the aggregate desired bit rate will be maintained, regardless of whether the determined UEs (UE2 to UE4) are directly or indirectly connected to the first UE (UE1).

[0143] FIG. 9 illustrates schematically an example of a network architecture with unique downstream LCIDs, i.e., one data rate recommendation / limitation is used per remote UE.

[0144] Note that the mapping table 25 used by the first UE (UE1) in Figure 9 does not indicate the UE in this example. Now, the downstream LCID is a unique value, and therefore the mapping table 25 no longer needs to indicate the child UE by its identification. Because the downstream LCID is unique, the identification of the child UE can be derived directly from the LCID.

[0145] The mapping table 25 maps the logical parent channels P-LCID1, P-LCID3, P-LCID4 and P-LCID5 to unique logical child channels CH-LCID4 of child device UE2, CH-LCID5 of child device UE3 and CH-LCID9 of child device UE2, respectively, where logical parent channel P-LCID5 is not yet mapped to a downstream logical channel.

[0146] Thus, base station (gNB) 20 can send individual data rate recommendations and / or restrictions to a selected remote UE (e.g., UE3) simply by selecting the correct channel (e.g., P-LCID3), assuming all traffic on that channel is associated with that particular remote UE.

[0147] It should be noted that the case of Figure 9 is a particular sub-case of the one-to-one mapping case of Figure 6. Here, each relay UE has an SL link setup with its child UEs such that the V2X sidelink solution described in 3GPP specification TS 23.287v16.2.0 ensures that each relay UE knows the L2 identity (ID) for each child, and therefore each relay UE can use the L2 child UE identity in the mapping table 25.

[0148] In one embodiment, it is assumed that the base station (gNB) 20 knows the entire relay network topology (e.g., based on previous channel creation, configuration and / or commissioning procedures and / or reporting procedures of the communication devices, or the like), and in connection with the topology, the base station (gNB) 20 knows the purpose (e.g., data traffic relay purpose) of the different logical channels and / or radio bearers created and / or used by the UEs and their associated LCIDs. Thus, in the example of Figure 8, the base station (gNB) 20 learns by sending an aggregate recommendation value of logical channel P-LCID 26 to UE0, which will be distributed as a new recommendation to the first UE (UE1) indicating logical channel CH-LCID5.

[0149] Furthermore, the base station (gNB) 20 also knows that the first UE (UE1) will distribute this value via second UEs downstream thereof (UE2 and UE3) using the selected policy, whereby the relay type UE (UE2) of the second UE also shares the received aggregate data rate recommendation from the first UE (UE1) via itself (UE2) and its child UE (UE4).

[0150] In the case where the policy for data rate distribution is managed by the base station (gNB) 20 (e.g., via RRC configuration messages), the exact sharing method (policy) used by the first UE (UE1) is also known by the base station (gNB) 20. If the policy is fixed (another option), then the base station (gNB) will know that a fixed policy is being used. Generally, the policy depends on the design details and / or is also defined by a set of configuration parameters and / or rules (e.g., rules that define which action should be taken under given conditions). These sets of configuration parameters, policies and / or rules are provided by one or more different network entities, such as the gNB, the PCF (via the AMF), the 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 knows the effective policy or portions thereof, for example, when the first UE communicates policy elements to the gNB or another network entity (e.g., PCF or SMF) communicates policy elements to the gNB. In other cases, the gNB does not know the effective policy, for example, when the active policy elements are not communicated to and determined by the gNB.

[0151] In the case of a one-to-one mapping between the LCIDs of the logical channels in the parent relay UE (UE0), the base station (gNB) 20 knows that the recommendation value sent to the parent relay UE (UE0) of the logical channel P-LCID26 will be sent as a new recommendation with the recommendation value equal to the logical channel CH-LCID5 of the parent relay UE (UE0) which is equal to the logical channel P-LCID5 of the first UE (UE1).

[0152] Based on the scheduler information, the base station (gNB) 20 determines a total recommended data rate value (aggregate data rate recommendation) for the group of UEs (UE2 to UE4).

[0153] The total suggested data rate value of the aggregate data rate recommendation is sent back to the parent relay UE (UE0) as a Recommended Bit Rate MAC CE element indicating the same logical channel P-LCID 26 as indicated in the aggregate desired bit rate message.

[0154] The parent relay UE (UE0) sends a new sidelink recommended bitrate MAC CE indicating logical channel CH-LCID5 to the first UE (UE1). The first UE (UE1) applies a policy to distribute the recommended bitrate among the UEs (UE2 to UE4) that are in the group of UEs indicated by said logical channel LCID5. This includes the downstream UEs and the first UE (UE1) itself. The first UE (UE1) sends the new recommendation only to UE2 and UE3 (i.e., its children). UE2 then sends another new recommendation to its child UE4. The policy is applied to distribute the recommendation across the group.

[0155] The policy can be the fair sharing policy mentioned above or any other policy. The policy can be configurable by the base station (gNB) 20 or by a function in the core network. In the above example, the logical channel CH-LCID5 indicates all its child UEs ("A" in the mapping table 25 of the first UE (UE1)). Therefore, the first UE (UE1) sends each of its child UEs a recommended data rate message (sidelink recommended bitrate MAC CE or another MAC type CE) containing a value equivalent to a specific percentage / portion of the total recommended data rate value of the aggregate data rate recommendation according to the selected policy. After child UE2 receives the recommended data rate message from the first UE, child UE2 applies the policy to allocate a specific percentage / portion of the total recommended data rate it received to its child UE4 and the remainder to itself. Child UE2 sends a recommended data rate message (e.g., sidelink recommended bitrate MAC CE or another MAC type CE) containing the allocated data rate to its child UE4.

[0156] As already mentioned above, an example policy could be to provide more data rate to relay UEs than to remote UEs, since relay UEs need to distribute their data rate budget further to downstream UEs, whereas remote-only UEs do not.

[0157] The embodiments described herein may be implemented with a different MAC CE element, or a modification, that defines a data rate limit instead of a recommendation. That is, the recommended bit rate MAC CE format may be reused as such, but defined as a different type of MAC CE, such as a sidelink bit rate limited MAC CE, or other type. The data rate limit carried by the MAC CE element may be expressed as an Aggregated Maximum Bit Rate (AMBR), e.g., per logical channel or set of logical channels, a Guaranteed Flow Bit Rate (GFBR), a Maximum Flow Bit Rate (MFBR), or other type. Such data rate limits may also be expressed by an index or identifier value, e.g., a 5G QoS Identifier (5QI), a PC5 QoS Identifier (PQI), a QoS Flow Identifier (QFI), or an index into a pre-configured table of limits, from which a relay or remote UE can derive or look up the corresponding data rate limit. Such data rate limits may also be expressed as a combination of an identifier value and another type of limit value, such as a PQI value together with a relative percentage value indicating what percentage of the total bit rate limit associated with a given PQI should be used as the data rate limit.

[0158] Additionally, the embodiments described herein may be implemented with data rate recommendations and data rate restrictions, such that both types of information are carried in separate MAC CE elements or in a combined new MAC CE element.

[0159] Additionally, in one embodiment, the recommendation and / or limit are defined as relative values ​​with respect to the maximum data rate that the child UE can support, e.g., via a sidelink connection towards a parent relay UE. For example, the recommendation and / or limit are calculated as the DL and UL maximum data rates supported by the UE (e.g., as defined in section 4.1.2 of 3GPP specification TS 38.306 v16.0.0). The access device or parent relay UE transmits the recommendation and / or limit to the downstream UE, encoded, e.g., as a fraction or percentage indicator of the downstream UE's maximum supported sidelink data rate. In this case, the parent relay UE knows the parameters necessary for performing the maximum sidelink data rate calculation over its communication link with the downstream UE. The downstream UE also calculates its own maximum sidelink data rate based on these parameters, and the downstream UE can then derive absolute recommendation and / or limit values ​​from the received relative (e.g., fraction / percentage) indicator values.

[0160] In any embodiment described herein, a configurable policy is implemented in the relay UE (e.g., the first UE), and an additional bit is optionally added in the MAC CE element or other transport message to allow selection (from a finite number of policies) of the policy to be applied at the relay UE. In one example, the recommended bit rate MAC CE has a couple of "reserved" unused bits that can be used for this purpose. As another option, the bit is repurposed to select the policy at downstream relay UEs to be applied, where the selected policy affects its distribution of the recommended bit rate to further downstream UEs. As a further option, the policy is predefined by the specification of the selected standard (e.g., 3GPP), pre-configured (e.g., in the UICC), or dynamically configured, for example, at the moment the UE becomes a relay UE or during operation of the relay UE. For example, the policy is configured using 5G signaled QoS rules sent to the UE via the NAS protocol. The policy or set of policies may also be sent as a component using the RRC protocol, or as part of a system information block (SIB), or as a set of configuration parameters and / or rules provided by one or more network entities such as the PCF (via the AMF), the gNB or the SMF.

[0161] In a modified embodiment, the set of policies to choose from is also selected based on the QoS indicators known by the relay UE to be associated with the particular LCID indicated in the MAC CE element.

[0162] An example policy could be "distribute up to 90% of the recommended bitrate fairly among all high priority logical channels, and the remaining 10% fairly among low priority logical channels" or "use up to 40% of the recommended bitrate for yourself, and distribute the remaining 60% fairly among downstream UEs."

[0163] In another embodiment, a configurable policy is used in a relay UE (e.g., a first UE), where policy selection of an allocation policy when receiving a bitrate recommendation from an upstream communication device may be based on a quality indicator value (e.g., a 5G QoS indicator such as a 5QI value). The quality indicator (e.g., a 5QI or PQI) is known at the relay UE for each Logical Channel Identification (LCID) it uses. One specific example of a quality indicator is a PC5 Quality Indicator (PQI) associated with each PC5 sidelink connection between the relay UE and its multiple remote UEs. In cases where the total recommendation (as received by the relay UE from the upstream parent device) is insufficient to accommodate all data rate requirements of downstream remote UEs, such values ​​may be used and compared together by the relay UE to select a policy in which remote UEs with the highest priority PQI values ​​are allocated a relatively larger share of the total data rate recommendation. Another example of a quality indicator is a NAS signaling message from the SMF to a relay UE 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, thus sent when notification control is enabled for a QoS flow used by the relay UE. At the relay UE, reception of a new quality indicator value triggers the selection of a different policy, so that the active policy always best matches the current QoS conditions of the link upstream of the relay UE. As an example situation and policy, a reduction in the GFBR value triggers the relay UE to select a new policy in which a lower relative proportion of the received data rate recommendation from the upstream device has been propagated to its downstream relay / remote UE in order to better ensure that its own upstream data traffic can be sent as normal, i.e., without data rate reduction, at the cost of providing less service to its downstream relay / remote UE.The aforementioned notification control mechanism using NAS signaling messages from the SMF to the relay UE is also used in the case where there is an alternative QoS profile (according to 23.501 section 5.7.1.2a) to be used for the relay UE. In this case, when the RAN determines that the current QoS cannot be guaranteed any longer, it can inform this to the SMF (which will then inform the UE), and at the same time, the RAN selects an alternative QoS profile with defined alternative QoS parameters to achieve the UE's new QoS level that can be met by the RAN. The selected alternative QoS profile will also be signaled to the UE via the SMF. The quality parameters included in this signaling message can trigger the selection of a new policy in exactly the same way as described above. At some point, the RAN can then use the same signaling mechanism to again provide the relay UE with the initial / most preferred QoS level, or a better alternative QoS level, by being informed of this fact again, allowing the relay UE to select a corresponding (different) policy. Alternatively, a set of alternative QoS profiles is provisioned by the gNB, PCF / SMF or other core network function to the relay UE that the relay UE can use to select another QoS profile when the desired QoS is no longer achievable due to changing conditions and uses the selected alternative QoS profile to change the data rate recommendations of its downstream devices accordingly.

[0164] In a further embodiment, a relay UE (e.g., a first UE) is provisioned with a table indicating upstream-to-downstream QoS mapping. Specifically, this may be a table having one or more entries where the entries map an upstream PQI quality indicator to a corresponding PQI quality indicator of a downstream logical channel, and vice versa. The relay UE then uses this table to determine the desired or achievable end-to-end QoS, or characteristics thereof, for a particular downstream UE. This information is then used to determine a distribution policy and / or to calculate, as part of the distribution policy, a particular value for a downstream recommendation based on the determined end-to-end QoS characteristics.

[0165] In yet another embodiment, the policy is selected by the relay UE based on several downstream communication devices of the relay UE, which may be downstream relay UEs served by the relay UE. In this case, the relay UE determines that this particular downstream relay UE serves a relative majority (Nr) of the total number of downstream communication devices (Ntot), e.g., (Nr / Ntot)>0.5. The relay UE then decides to allocate a certain larger percentage (e.g., (Nr / Ntot)) of its receive data rate recommendation and / or limit budget to that one downstream relay UE. As in this example, the details of the selected policy are generated locally by the relay UE based on locally available information, such as measured parameters, received system information and / or parameters, or a locally stored policy template. In general, the selected policy may also be selected from multiple candidate policies that are predetermined, e.g., by a specification or implementation, locally generated as described above, and / or pre-configured, e.g., by information stored in a network function or UICC, and / or dynamically configured during operation, e.g., by RRC communication from a gNB. In a further embodiment, the policy is selected by the relay UE based on the type of downstream communication device. This may be a downstream device directly connected to the relay UE via a communication link (i.e., a child device), or it may be a downstream device that is further downstream and therefore not directly connected to the relay UE. One example of a device type that typically influences the selected policy is the distinction between relay UE device type or remote UE device type (the latter then not simultaneously functioning as a relay UE while functioning as a remote UE). One advantageous policy for a relay UE is then to assign a relatively large proportion of its receive data rate recommendation and / or limit to those child downstream devices that are type relay UE. Remote UE type devices do not do this because these devices are likely to be serving further downstream relay UEs or remote UEs.Therefore, 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 is to classify among "relay UEs serving other relay UEs," "relay UEs serving only remote UEs," "relay UEs not currently serving remote UEs," and "remote UEs." The preceding device types in this list are then typically allocated a relatively higher proportion of the recommended available data rate budget than device types stated later in the list. Other device type classifications may also be made, for example, defining device types based on radio access technology, such as NR-based wireless devices, LTE-based wireless devices, NR RedCap (Reduced Capability) wireless devices, NB-IoT / LTE-M devices, and Wi-Fi wireless devices. Alternatively, device types may be distinguished based on current device activity, such as "video streaming devices," "audio streaming devices," and "non-streaming devices." These various device type classifications may also be combined when implementing policy selection based on device type. Alternatively or additionally, the relay UE receives information from a remote UE or gNB or core network function or upstream or downstream UE, the type of data (e.g., lossless streaming data, lossy streaming data, voice call related data, video call related data, AR / VR related data, bulk data, delay sensitive data, delay insensitive data, I / O data, etc.) expected to be transported and used to select a policy and / or determine a data rate recommendation for one or more downstream devices and / or determine a data rate recommendation query for one or more upstream devices.

[0166] In a further embodiment, the policy is selected by the relay UE based on a network slice identifier. This slice identifier may identify the 5G network slice to which the relay UE is currently connected for all its upstream communications. Alternatively, the slice identifier may identify the (5G) network slice to which a downstream communication device (UE) is currently connected. As an example of a representative advantageous use of this manner of selection, the relay UE determines (by itself or with the help of the RAN) that one of its child relay UEs is operating in a special network slice reserved for high-priority public services, while other downstream UEs are operating in network slices with default priorities. Based on this (high) priority, a relatively high proportion of data rate recommendations and / or limitations may be assigned to the relay UE serving the high-priority network slice. Optionally, lower-priority downstream UEs may also be sent zeros as data rate recommendations and / or limitations to leave as much capacity as possible for the high-priority network slice device. As another example, if a relay UE is connected to a different slice (e.g., one slice out of two total slices to which it is connected) at different times based on specific circumstances (e.g., one slice is only provided in a specific geographical area or when a specific base station is reachable), the network slice identifier of the current network slice to which it is connected is used to select a policy. Each slice, comprising different networks with different priorities / QoS requirements / objectives, may want the relay to impose its specific rules regarding how it allocates data rate recommendations and / or restrictions to its downstream devices. Using the slice identifier of the current network slice to which it is connected allows the relay UE to select the correct policy or set of policies to meet the slice's operational and performance goals, depending on whether the particular network slice serving the remote UE requires a policy tailored to its needs, e.g., whether it is considered more or less critical.

[0167] In yet another embodiment, which may be combined with any other embodiment or implemented independently, the relay UE supports reflective QoS (as defined in TS 23.501). The relay UE signals its capability to support reflective QoS during initial registration or PDU session setup (e.g., during 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. When reflective QoS is triggered to be used for one or more QoS flows (e.g., by the SMF), the NG-RAN and UPF are informed by the relay UE to include a QoS flow identifier (QFI) in each downstream message via each QoS flow (within the established PDU session). In this embodiment, the relay UE uses the received QFI in the message received via the NG-RAN message not only to determine the corresponding PC5 QoS flow, but also to advantageously select and apply and / or modify a data recommendation policy for one or more downstream UEs and / or send a new data rate recommendation message to one or more downstream UEs. As per the current 3GPP specification, the NG-RAN's Reflected QoS configuration and UPF and QFI in each downstream message to the relay UE are only applied when Reflected QoS is used. However, it would be beneficial to always include the QFI in each downstream message from the NG-RAN to the relay UE. Unfortunately, this creates confusion when Reflected QoS should be applied to update the QoS flow configuration and filters in the relay UE (pre-configured by the SMF) in the upstream message, and also creates confusion in the NG-RAN and / or SMF / UPF and / or other core network functions as to whether Reflected QoS or the pre-configured QoS configuration will be used by the relay UE.Therefore, to distinguish between reflective and non-reflective QoS being applied by a relay UE, in this embodiment, the SMF may, for example, send a message to the UE (e.g., via the NAS) whether reflective QoS needs to be applied for a QoS flow, and / or the SMF may omit sending reflective QoS timer values / configurations to the UE even if the UE indicates support for reflective QoS. If reflective QoS timer information is received by the UE, then upon receiving a message via NG-RAN containing a QFI value, it shall not derive any new QoS flow configurations or filters and / or shall not update any (pre-)configured QoS flow configurations, filters or QoS mappings and / or shall not apply any default timers and / or shall not reset timers.

[0168] As previously mentioned, various other means for encoding data rate recommendation and / or restriction information may be used.

[0169] Examples include a MAC CE element that combines a limit (e.g., maximum) value in addition to a recommended value, or a MAC CE element that includes an integer indicating a bit rate value (e.g., kbit / sec) instead of an integer category or class number. Furthermore, as mentioned above, various means of sending data rate information to a relay UE (e.g., first UE) or a remote UE can be used. Examples include MAC CE, PDCP protocol (which can be end-to-end from the base station (gNB) to the relay UE or a single hop, e.g., from the relay UE to the remote UE, or a single hop, e.g., from the relay UE to the relay UE), and RRC protocol (e.g., within a newly defined component, from the base station (gNB) to the relay UE or a single hop, e.g., from the relay UE to the remote UE or from the relay UE to the relay UE).

[0170] For non-relay UEs, conventional procedures (such as the Recommended Bit Rate MAC CE Query procedure) may be used to determine when to send the (aggregate) desired data rate request, which may also be implementation dependent at the time of sending.

[0171] An example for a relay UE (e.g., a first UE) of when to send an upstream message with desired data rate request information could be: 1. Send an upstream message with data rate information as soon as at least N (configurable N) data rate messages are received from downstream UEs. 2. Based on timer expiration, where the timer may be started (if not already running) in response to a message received from a downstream UE. 3. When a combination of messages received from downstream UEs leads to a significant change in the desired uplink / downlink data rate compared to the previous (e.g., last) reported value. 4. Based on the available space in the downstream data packet and rules that combine one or more of the aforementioned options.

[0172] Examples for a relay UE (e.g., a first UE) of when to send a recommendation received from an upstream node (UE or base station (gNB)) to one or more downstream nodes may include: 1. Immediately after receiving a recommendation from an upstream node, 2. Based on timer expiration, or 3. Based on the available space in the downstream data packet and a rule that combines one or more of the aforementioned options.

[0173] For multiple UEs, there are specific formats defined for the combined reporting of multiple data rate queries, or data rate recommendations, or restrictions, or restrictions and recommendations.

[0174] One example is to use the existing recommended bit rate MAC CEs as defined in 3GPP® specification TS 38.321 v15.5.0, where multiple of these can be sent in a single MAC PDU, or multiple can be spread across multiple MAC PDUs, if desired.

[0175] Alternatively, a message can consist of a list of tuples: {LCID_i,UL / DL or upstream / downstream or UL / DL / SL_i,Data Rate recommendation_i}

[0176] Alternatively, the message can consist of a list of tuples: {UE-ID_k,LCID_i,UL / DL_i,Data Rate recommendation_i} Here, UE-ID is a short identifier of a particular remote / relay UE within the RAN or of a particular remote / relay UE downstream of the sender of the message (this in principle allows the ID to be encoded more briefly).

[0177] Alternatively, the message can consist of a list of tuples: {LCID_i,UL / DL_i,Data Rate recommendation_i,Data Rate limit_i}

[0178] The above example formats may be wrapped in a MAC CE or transported via one of the other protocols mentioned above.

[0179] In one embodiment, the base station (gNB) may determine, based on the received report, that a relay UE or remote UE needs additional upstream relay UEs on top of its current one. Otherwise, the desired data rate of one or more critical data streams (e.g., high priority, real-time, or low latency data) cannot be met. To meet this need, the base station (gNB) instructs a particular relay UE or remote UE to acquire additional parent relay UEs or to initiate replacement with a new parent relay UE that can provide more bandwidth (i.e., data rate).

[0180] In one set of embodiments, the base station (gNB) and its scheduler are triggered by receiving new information regarding a desired data rate (of an aggregate) of another logical channel (LCID2) for a UE (e.g., UE2, where UE1 may or may not be equal to UE2) to control and / or influence the recommended data rate of one logical channel (LCID1) of at least one specific UE (e.g., UE1) directly connected to the base station (gNB). The base station (gNB) or its scheduler may, for example, schedule fewer resources for LCID1 and more resources for LCID2 if UE2 with LCID2 indicates that more data rate is desired there, or vice versa, or schedule more resources for LCID1 and fewer resources for LCID2 if UE2 with LCID2 indicates that less data rate is needed / desired.

[0181] A related embodiment is to send a lower previous recommended data rate for LCID1 if UE2 on LCID2 indicates that more data rate is desired there, and vice versa, or to send a higher previous recommended data rate for LCID1 if UE2 on LCID2 indicates that less data rate is needed / desired.

[0182] In the above example, in the above case, fewer / more resources respectively are available for LCID1, so the recommendation sent is lower / higher respectively.

[0183] In a further embodiment, the relay UE (e.g., the first UE) reduces its data rate recommendation to the downstream UE when its buffer fills above a threshold, or adapts its data rate recommendation to the downstream UE based on its buffer status.

[0184] For example, if the total buffered data size (upstream pending data towards the base station (gNB)) exceeds a specified threshold, the relay UE initiates a policy to reduce the recommended data rate to downstream UEs. Alternatively, the reduction in the recommended data rate can be specific to one or more LCIDs, depending on the upstream data buffer status of a particular upstream LCID. When the total buffer size of the relay UE is reduced again below the specified threshold, the relay UE begins to reapply its original policy without the recommended reduction.

[0185] In some of the above-described embodiments, the data rate recommendation was initially made by the base station (gNB) and then sent to one or more relay UEs. In this way, the data rate recommendation "trickles down" to the local portion of the cellular network initiated by the base station (gNB).

[0186] However, other initiation mechanisms for data rate recommendation and / or restriction (eg, RRC or SDAP or PDCP) may be used.

[0187] There may also be other types of control messages coming from the core network, i.e., from any function in the core network that carries such information, used for example to convey uplink slice-specific data limits to be adhered to by the UE, or recommendations for the UE to follow.

[0188] The recommendation and / or restriction control messages sent to one or more downstream UEs are based on the received data rate recommendation / restriction information and are sent using a protocol other than that used to receive the recommendation / restriction.

[0189] For example, the Recommended Bit Rate MAC CE or Sidelink Recommended Bit Rate MAC CE can be used by a relay UE (e.g., a first UE) to send a recommended data rate value to a child UE based on a restriction sent via an extended SDAP protocol message. In this case, the recommendation is sent based on the restriction value. The downstream UE may be an OoC UE that does not have access to most base station and / or core network capabilities; for example, the downstream UE may not be able to use control plane messaging to / from the base station or establish a PDU session with the core network. With this data rate recommendation solution, the OoC UE can further receive the data rate recommendation indirectly via the relay UE and apply the recommendation to their upstream data.

[0190] Alternatively, the relay UE (e.g., the first UE) may send a limiting value to the downstream UE based on the aforementioned data rate limiting information, e.g., using a newly defined sidelink bit rate limiting MAC CE or similar.

[0191] A further means for potentially sending data rate restrictions / recommendations to downstream UEs is via the RRC protocol over the Sidelink (SL), i.e., PC5 interface.

[0192] An embodiment for use in at least a Layer 2 (L2) or Layer 3 (L3) single-hop relay architecture for UE-to-Network (U2N) relaying is described below. The embodiment defines a new Sidelink (SL-SCH) MAC CE called "SL-RBR" which stands for Sidelink Recommended Bit Rate MAC Control Element. The SL-RBR is assigned a new 6-bit Logical Channel (LCID) value in the range 20-61, e.g., 61. The SL-RBR has a fixed size of two octets. The SL-RBR contains one or more of the following fields: Q: "Query" (1 bit): indicates whether this SL-RBR encodes a bitrate recommendation (Q=0) or whether this SL-RBR is a query for a bitrate recommendation (Q=1). In the following, the name "SL-RBR" denotes an SL-RBR with Q=0, and "SL-RBR-Q" denotes an SL-RBR with Q=1 set. · LCID (6 bits): Indicates the logical channel identification for which the bit rate is recommended or a recommendation query is made for the cases Q=0 and Q=1, respectively. · UL / DL (1 bit): Indicates whether this SL-RBR / SL-RBR-Q applies to the upstream (1) or downstream (0) data flow direction. Bitrate (6 bits): Index into table 6.1.3.20-1 of TS 38.321 v16.3.0, encoding the bitrate value recommended (Q=0) or requested (Q=1), respectively. The "requested" value can be seen as the UE's preference for bitrate, i.e., the requested rate. X (1 bit): Applicable (1) or inapplicable (0) bit rate multiplier. The multiplier is applied to the bit rate value in a manner similar to that described in TS 38.321 v16.3.0 section 6.1.3.20, using the same multiplication factor, if applicable. This multiplier is configured by the gNB using the optional parameter bitRateMultiplier-r16 sent via RRC to UEs, including relay and remote UEs. Alternatively, a new parameter bitRateMultiplierSL is defined, which specifies a separate multiplier for sidelink communication. · R (1 bit): Reserved bit, set to 0.

[0193] Remote UE traffic is relayed by at least one specific logical channel between the relay UE and the gNB. Such a channel is referred to herein as the remote UE's "proxy LCID." Such a proxy LCID is used on the Uu interface, while the LCID used directly by the remote UE via PC5 is a different logical channel and therefore has a different logical channel identifier (LCID). One proxy LCID may be provided to one or more remote UEs, depending, for example, on a mapping of LCIDs used via Uu to LCIDs used via PC5 (or vice versa) established by the relay UE or by the gNB (e.g., as part of the adaptation layer), or depending, for example, on a configuration sent by the gNB, or, in this case, on specific rules defined in 3GPP standards for logical channel selection. Optionally, a proxy LCID is also provided to the relay UE itself for transport of its own data traffic to / from the gNB. In the case of an L2 relay architecture, there are defined procedures between the remote UE, relay UE, and gNB for the acceptance of a new remote or relay UE and the subsequent setup of a RAN L2 end-to-end connection between the remote UE and the gNB. In case of an L3 relay architecture, there are also defined procedures for the acceptance of a new remote or relay UE and the subsequent setup of a connection between the relay UE and the gNB and / or between the relay UE and the remote UE. Such setup procedures are used to allocate a specific LCID as a proxy LCID for a specific remote UE or for a specific sidelink LCID associated with a specific remote UE.

[0194] A relay UE serving one or more remote UEs may be triggered by a specific event, such as downlink reception of a Recommended Bitrate MAC CE from a gNB with a Proxy LCID (i.e., the ID of the logical channel used for Uu) or reception of an SL-RBR-Q from the remote UE, to send to one or more of its remote UEs. If the trigger is DL reception of a Recommended Bitrate MAC CE from the gNB, which of the served remote UEs are eligible to receive a new SL-RBR is determined by the set of remote UEs associated with the specific Proxy LCID value included in that received MAC CE from the gNB. Similarly, for a query, a relay UE may be triggered by a specific event, such as timer expiration or reception of an SL-RBR-Q from one or more of its remote UEs, to send a Recommended Bitrate Query MAC CE (indicating the Proxy LCID) in the uplink to its gNB. The LCD value to include in this MAC CE sent by the relay UE to the gNB is determined by the specific trigger condition. For example, if the trigger is based on a timer, the LCID value is determined by the logical channel for which the triggered timer was created. Or, for example, if the trigger was the receipt of a SL-RBR-Q from one particular remote UE, then the LCID value would normally be determined to be equal to the proxy LCID associated with that particular remote UE.

[0195] The relay UE may use one of several policies for distributing the received recommended bit rate to a set of one or more downstream remote UEs. The received recommended bit rate message from the gNB includes an LCID field that is used by the relay UE as an input parameter for implementing the policy and / or selecting a particular stored policy. The policy may be fixed or pre-configured in the relay UE as described herein, or may be dynamically configured, e.g., by the gNB, using data sent to the relay UE via the RRC protocol. Exemplary advantageous policies of this embodiment and its variants are: 1. Fair distribution - A relay UE can divide the bit rate equally across N 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 thereby allows encoding of an accurate division result value in the SL-RBR. 2. Distribution Proportional to Requested Bit Rate—The relay UE can distribute the bit rate approximately proportional to the requested bit rate of each of the N applicable remote UEs. The set of applied UEs is typically all remote UEs sharing the same proxy LCID value. If an applicable UE has not (yet) requested a bit rate using SL-RBR-Q, the relay can decide that it requires a percentage of the total rate recommendation (1 / N), or that it does not require anything (0) until it makes an explicit request. This decision algorithm is configurable by the gNB, or is a default algorithm in the relay UE, or is dependent on situational parameters (e.g., number of served remote UEs, data load, etc.). 3. Distribution to streaming data producers and / or consumers only - The relay UE can keep track of the subset of remote UEs of a particular proxy LCID that have previously requested data rate recommendations using SL-RBR. Only this subset of N members (N can be 1) will be used for further distribution of data rate recommendations according to policy 1 above. 4. Use Historical Bit Rate - Similar to policy 2 above, but instead of assuming the remote UE did not request a fixed rate, this policy uses the actual historical data rate observed by the remote UE and the relay UE, assuming that the remote UE's preference is to continue streaming data as it did in the past.

[0196] 5. Allocation proportional to known quality indicators—The relay UE stores a table that maps each downstream remote UE to a quality indicator, e.g., a QoS value such as a PQI. The relay UE preferably divides the aggregate bitrate recommendation so that each downstream remote UE at least receives a bitrate recommendation according to the quality indicator, i.e., which allows each remote UE to meet its QoS requirements. Alternatively or additionally, the relay UE allocates a larger share of the aggregate bitrate recommendation to those remote UEs with stricter QoS requirements as determined by their quality indicators, stricter meanings, e.g., PQIs with lower default priority levels as defined by TS 23.287, or PQIs with lower maximum packet error rates as defined by TS 23.287, or higher bandwidth requirements. 6. Allocation Adapted to Current Relay Load—This policy aspect can be combined with one of the other policies. In this case, the relay UE lowers its calculated recommendation to one or more remote UEs based on an indication of the current relay load, i.e., an internally calculated indication using one or more variables describing the load on the relay UE's resources due to its functionality, including, for example, user data transmission, user data reception, data relaying operations, calculations, and sensing operations. Examples of load indicators include device temperature, memory usage, battery energy consumption, memory buffer usage of relay operations, CPU load percentage, resource availability percentage in the sidelink resource pool, etc. Typically, the relay UE uses such load indicators to lower the calculated downstream recommended bit rate when this load indication is higher. This allows the relay UE to balance its services towards its remote UEs against its own resource requirements and limitations. 7. Adaptation to Remote UE Link Quality—This policy aspect can be combined with one of the other policies. The relay UE will adapt its calculated bit rate recommendation based on the link quality or similar indicator of the link towards a particular remote UE. For example, the relay UE may determine that a particular link to a remote UE has poor quality and therefore the effective bit rate to or from that remote UE cannot exceed a certain determined threshold value. The relay UE then decides to reduce the recommendation calculated by the policy and sends the reduced value to the remote UE.

[0197] The relay UE may use one or more of several policies for aggregating multiple received bit rate recommendation queries (SL-RBR with Q=1) into a single uplink recommended bit rate query MAC CE with included requested value sent to the gNB. This policy may be fixed or pre-configured in the relay UE, or dynamically configured by the gNB using data sent to the relay UE via the RRC protocol, as described herein. Exemplary advantageous policies of this embodiment are: 1. Sum of requested bitrates - The relay UE will sum any UL / DL bit=0 requests received from remote UEs associated with the same proxy LCID and send the approximate sum as one recommended bitrate query to the gNB with UL / DL bit=0 uplink, as well as sum any UL / DL=1 requests and send the approximate sum as one recommended bitrate query uplink to the gNB with UL / DL=1. If the exact sum cannot be encoded as one of the allowed bitrate values ​​using the 6 bits of the bitrate field, then the second highest number of bitrates is selected by the relay UE. 2. Sum of requested and historical bit rates - The relay UE will sum the requests as in policy 1 above, but in addition, the relay UE uses the actual data rates observed in history of 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 streaming data as they did in the past. 3. Adaptation to Current Relay Load—This policy aspect can be combined with one or more of the other policies. In this case, the relay UE will reduce its calculated request value based on an indication of the current relay load, i.e., an internally calculated indication using one or more variables describing the load on the relay UE's resources due to its functions, including, for example, user data transmission, user data reception, data relaying operations, calculations, and sensing operations. Examples of load indicators include device temperature, memory usage, battery energy consumption, memory buffer usage of relay operations, CPU load percentage, resource utilization percentage in the sidelink resource pool, etc. Typically, the relay UE will use such load indicator to reduce the calculated request value of the upstream recommended bitrate query more when this load indication is higher. This allows the relay UE to balance its services towards its remote UEs against its own resource requirements and limitations. 4. Adaptation to Remote UE Link Quality—This policy aspect can be combined with one or more of the other policies. The relay UE will adapt the calculated request value based on the link quality or similar indicator of the link towards a particular remote UE. For example, the relay UE may determine that a particular link to a remote UE has low quality, and therefore the effective bit rate to or from that remote UE cannot exceed a certain determined threshold value. If that remote UE requests a bit rate higher than this threshold, the relay UE may decide to reduce this value and then apply a policy using this reduced value. This is similar to case 3, but here the reduction is made for other reasons and is calculated differently.

[0198] To limit the amount of SL-RBRs transmitted, the UE uses a timer bitRateQuerySlProhibitTimer similar to the existing timer bitRateQueryProhibitTimer in TS 38.321 to throttle the rate at which SL-RBRs can be sent.

[0199] If the relay UE does not have an opportunity to transmit SL-RBR to a particular remote UE, it keeps in memory the most recent SL-RBR that is to be sent to that remote UE until the next transmission opportunity occurs. Alternatively, the relay UE calculates the optimal value of SL-RBR to send just before the next transmission opportunity begins. In a first variant of this embodiment, the field Q is not present in SL-RBR and SL-RBR-Q; instead, two different LCID values ​​are assigned for L-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 one bit of payload in the MAC CE, which is then used for other purposes.

[0200] An alternative embodiment that may be used at least in a Layer 2 (L2) single-hop relay architecture for UE-to-Network (U2N) relaying is now described. Such an alternative embodiment defines SL-RBR exactly as in the previous embodiment, and in addition also defines "RBR-R" to represent the recommended bit rate of the relay MAC control element. RBR-R is assigned a new DL-SCH logical channel (LCID or eLCID) value, e.g., 46 or 308. It also defines "RBR-RQ" to indicate the recommended bit rate of the relay query MAC control element. RBR-RQ is assigned a new UL-SCH logical channel (LCID or eLCID) value, e.g., 44 or 249. RBR-R / RBR-Q has a fixed size of four octets. It contains one or more of the following fields: Remote ID (16 bits): Remote UE identity, encoded as (part of) the L2 identifier. This encodes the identity of the remote UE that has inquired about a bit rate recommendation for a relay UE (in case of RBR-RQ) or that is to be provided with a bit rate recommendation by the relay UE (in case of RBR-R). SL-LCID (6 bits): Indicates the SL logical channel identification associated with the Remote ID identified remote UE for which the bit rate is recommended in RBR-R or for which a recommendation query is made for RBR-RQ. Optionally, this field can be omitted in further alternative embodiments, in which case the RBR-R / RBR-RQ is associated with all (active) SL LCIDs used between the Relay UE and the Remote ID identified remote UE. · UL / DL (1 bit): Indicates whether this RBR-R / RBR-RQ applies to the upstream (1) or downstream (0) data flow direction. Bitrate (6 bits): Index into table 6.1.3.20-1 of TS 38.321 v16.3.0, encoding the bitrate value recommended (Q=0) or requested (Q=1), respectively. The "requested" value can be thought of as the UE's preference for bitrate, i.e., the requested rate. X (1 bit): Applicable (1) or inapplicable (0) bit rate multiplier. The multiplier is applied to the bit rate value in a manner similar to that described in TS 38.321 v16.3.0 section 6.1.3.20, using the same multiplication factor, if applicable. This multiplier is configured by the gNB using the optional parameter bitRateMultiplier-r16, sent via RRC to UEs, including relay and remote UEs. Alternatively, a new parameter bitRateMultiplierSL is defined, which specifies a separate multiplier for sidelink communication. · R (2 bits): Reserved bits, set to 0. Optionally, the reserved bits are used as remote ID extension bits to indicate that a larger remote ID address is included, which is useful when the short 16-bit remote ID identities of two remote UEs would otherwise collide.

[0201] For an L2 relay architecture, there are procedures between the remote UE, relay UE, and gNB for accepting a new remote UE and setting up a RAN L2 end-to-end connection between the remote UE and the gNB. Similarly, for an L3 relay architecture, there are procedures for accepting a new relay or remote UE, or for setting up a connection between the relay UE and the gNB via Uu, or for setting up a connection between the relay UE and the remote UE via PC5. Such procedures also set up a "proxy LCID" as described in the previous embodiment. A relay UE serving one or more remote UEs can be triggered by a specific event, such as downlink reception of an RBR-R MAC CE from the gNB or reception of an SL-RBR-Q from the remote UE, to send SL-RBRs to one or more of its remote UEs. When the trigger is DL reception of an RBR-R MAC CE from the gNB, which of the served remote UEs should receive the new SL-RBR is often determined by the Remote ID value indicated in the received MAC CE. Similarly, for queries, a relay UE may be triggered by a specific event, such as a timer expiry or the receipt of an SL-RBR-Q from one or more of its remote UEs, to send an RBR-R-QMAC CE (indicating the remote UE ID in the Remote ID field) in uplink to its gNB. The SL-LCID value (if applicable) and the Remote ID value included in this MAC CE sent to the gNB are determined based on the identity of the remote UE and (if applicable) for which sidelink LCID of that remote UE the query should be made to the gNB. Typically, the Remote ID identifies the same remote UE that sent the triggering SL-RBR-Q to the relay UE, and the SL-LCID field (if applicable) identifies the sidelink LCID indicated in the triggering SL-RBR-Q.

[0202] The relay UE may use one of several downstream policies for further distributing the received recommended bit rate to the remote UEs. The policies may be fixed or pre-configured in the relay UE, or dynamically configured by the gNB using data sent to the relay UE via the RRC protocol, as described elsewhere herein. Exemplary advantageous policies of this embodiment are: 1. Best Effort Distribution - Send the SL-RBR as soon as possible when a MAC PDU is being sent to a target remote UE that has space available for inclusion of the SL-RBR. 2. Time-bounded distribution - like policy 1, but if a MAC PDU has not been sent to the target remote UE within some configured time limit, create a new MAC PDU and send it to the remote UE even if this PDU does not contain higher layer data. 3. Rage Distribution - Buffer received recommendations locally until the target remote UE signals SL-RBR-Q and / or a specific timer for relay triggering, then send the buffered recommendations using SL-RBR in response using policy 1 or 2. 4. Rage distribution with gNB fallback - as policy 3, but if the requested bitrate in the SL-RBR-Q is higher than the buffered value, trigger a new RBR-RQ to the gNB, wait for the response RBR-R, and then provide this new value to the remote UE using policy 1 or 2. 5. Delta-only distribution - uses one of the other policies 1-4 and also suppresses the transmission of SL-RBR if the suggested value of 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 transmission event was longer than the configured time interval.

[0203] The relay UE may use one of several upstream policies for sending the received bitrate recommendation query (SL-RBR with Q=1) as an RBR-RQ query to the gNB. The policy may be fixed or pre-configured in the relay UE, as described elsewhere herein, or may be dynamically configured, e.g., by the gNB, using data sent to the relay UE via the RRC protocol. Exemplary advantageous policies of this embodiment are: 1. Best Effort Transmission - Send an RBR-RQ as soon as possible after the triggering event when a MAC PDU is being sent to the gNB that has space available for the inclusion of this MAC CE. 2. Time-bounded distribution—Like policy 1, but also applies a time limit similar to downstream policy 2. 3. Delta-only distribution - Use one of policies 1 or 2, and additionally throttle RBR-RQ transmissions if the bitrate value is equal to the value previously sent to the gNB using an RBR-RQ for the same remote UE and the same SL-LCID. Optionally, throttling is not used if the last transmission event was longer than the configured time interval.

[0204] To limit the amount of RBR-RQs transmitted, the UE uses a timer bitRateRelayQueryProhibitTimer similar to the existing timer bitRateQueryProhibitTimer in TS 38.321 to constrain the rate at which RBR-RQs can be sent.

[0205] An advantage of this embodiment is that it provides more control of the recommendations to the gNB, allowing the gNB to determine in detail the bit rate recommendations for each remote UE it serves.

[0206] Yet another alternative embodiment will be described below, based on the same principles as the previous embodiment applied to the L2 relay architecture. The main difference of this embodiment relative to the previous embodiment is that SL-RBR and SL-RBR-Q are carried directly in the adaptation header sent in the communication between the gNB and the relay UE, instead of sending RBR-R and RBR-RQ, respectively. The adaptation header is a protocol layer header of the Uu interface between the RLC and PDCP protocol layers as defined in TR23.752v1.0.0 Annex A. It should be noted that the adaptation header is simply used to wrap, i.e., is attached to, the PDCP PDU that needs to be relayed by the relay UE. The adaptation header is defined as a variable-length header to contain other information elements (IEs), such as MAC CE, that are to be sent via the sidelink (PC5 interface) to the UE indicated in the "Target UE Identification" field or similar field of the adaptation layer, via the sidelink channel (LCID) indicated in the "Target LCID" field or similar field of the adaptation layer. Specifically, the Adaptation Header includes at least one "Length" field indicating the total length of the Adaptation Header or just the length of the IE container. The IE container includes one, or optionally one or more, MAC CEs. Other data, such as status reports or configuration settings related to the relay operation, are also included as IEs in the IE container. When receiving such an IE with a MAC CE, it is the responsibility of the relay UE to determine the actual MAC CE that is to be sent to the target UE via PC5 and to attempt to transmit the determined MAC CE to the target UE via its PC5 connection with the target UE. When making this decision regarding the specific included SL-RBR, the relay UE either bases its transmitted SL-RBR entirely on the field as included in the SL-RBR in the IE container, or the relay UE adapts the recommended bitrate value (e.g., to a lower value if it is heavily loaded, or by reducing the value due to some other policy).Vice versa, the relay UE is responsible for receiving SL-RBR-Qs from the remote UE and for sending such queries to the gNB embedded in an IE in the Adaptation header (provided that MAC PDU space exists and trigger conditions allow it). This allows the gNB to send detailed recommendations as SL-RBRs to specific remote UEs as in the previous embodiment and better assist the relay UE with detailed recommendations based on which the relay UE can make a better-informed decision on its final recommendation to the remote UE, and also allows the gNB to receive all specific queries (SL-RBR-Qs) coming from the remote UE via the relay UE, thereby obtaining finer-grained information. Since the gNB includes the SL-SCH MAC CE directly in the IE container of DL packets and the relay UE includes the SL-SCH MAC CE directly in the IE container of UL packets, this has the same advantages as described for the second embodiment, with the additional advantage that no new MAC CE type definition for DL-SCH is required. It also has the added advantage that the IE container in the Adaptation header can also be used by the gNB to send other types of SL MAC CEs in a relay manner to the remote UE without requiring the relay UE to know about all these MAC CEs and be able to parse them, which is useful, for example, when new types of SL MAC CEs are introduced that legacy relay UEs do not know about. Instead of using the Adaptation header to carry MAC CE messages such as SL-RBR-Q, the relay UE also adds an Adaptation Layer header to the received SL-RBR-Q message, for example after encapsulating it in an RLC / PDCP message.

[0207] Next, we describe an embodiment that applies when a relay UE or remote UE performs a procedure to disconnect from its current parent relay UE and have it assigned to a new parent relay UE, where both the old parent relay UE and the new parent relay UE are served directly or indirectly by the same gNB. This procedure is referred to herein as an intra-gNB handover of a UE. This embodiment can be combined with any of the previous embodiments. The trigger for initiating an intra-gNB handover may be a message or command from the gNB to the UE or to its current parent relay UE, or such a trigger may be a decision by the relay UE itself that it requires a handover. In either case, the parent relay UE will be notified of the handover, or the parent relay UE will eventually become aware of the UE's disconnection. This is the trigger for redetermining data rate recommendations and / or limitations to any remaining downstream relay or remote UEs. Additionally, optionally, the gNB may spontaneously send new data rate recommendations and / or limitations to the (old) parent relay UE, lowering the total amount due, for example, to the departure or emergency departure of the UE as a child UE. Optionally, the parent relay UE may also spontaneously send a data rate recommendation query to its parent communication device (e.g., gNB or relay UE) to indicate that it needs a new recommendation given the updated situation. The gNB then responds to this query with the updated data rate recommendation and / or restriction. After the handover UE connects to its new parent relay UE, the handover UE optionally sends a new data rate recommendation query to its parent to inform the new parent of its desired data rate and to request a data rate recommendation from the new parent. The parent relay UE responds to this request directly with a recommendation, or the parent relay UE sends a data rate recommendation query to its own upstream communication device (e.g., gNB or relay UE) to ensure that its upstream device is also aware of the desired data rates of downstream devices in the new situation.In either case, the purpose of this procedure is that the new parent relay UE can send new data rate recommendations to the handed over UEs that are now connected to the new parent (as remote UEs, as relay UEs, or both). Note that the UE may use other logical channel identifiers (e.g., different LCID values) with the new parent than the ones it used with the old parent, depending on the method used for the selection of these identifiers (e.g., that is configured by the gNB).

[0208] Similar embodiments to those described above may be defined for the case of an inter-gNB handover, i.e., a procedure in which a UE (relay UE or remote UE) is moving away from its current parent relay UE and is connecting, directly or indirectly, to a new parent relay UE served by a different gNB. In this case, the same behavior as defined above may be used by the old and new parent relay UEs, as well as by the handed over UE.

[0209] For both intra-gNB and inter-gNB handover cases, the (old) parent relay UE of the remote UE, upon handover of the remote UE to another parent relay UE (e.g., after receiving a signal (e.g., handover request) from the remote UE or gNB informing the relay UE of the handover or triggered by the relay UE itself) or upon handover of the relay UE from one gNB to another gNB, sends a message to the remote UE and / or old or new gNB and / or core network function (e.g., AMF or SMF) with information about the logical channel allocation and / or QoS configuration (e.g., QoS flows / filters / policies) associated with those channels and / or the (latest) data rate recommendation configuration and / or associated policies, and / or a list of recent messages related to data rate recommendations or data rate recommendation queries. This information is then used by the remote UE and / or the old or new gNB and / or the respective core network functions to inform the new parent relay UE of the remote UE and / or the new gNB, and the new parent relay UE can use this information to apply similar configurations / policies / logical channels that the old parent relay UE applied for its relayed communication with the remote UE, which allows for a smoother and faster handover procedure.

[0210] Furthermore, in case of an inter-gNB handover, the gNB to which the relay UE is connected before the handover sends information regarding logical channel allocations and / or QoS configurations (e.g. QoS flows / filters / policies) associated with those channels and / or the (latest) data rate recommendation configurations and / or associated policies and / or recommended data rates or a list of recent messages or data rate recommendation queries associated with the relay UE and / or its connected downstream UEs to the new gNB to which the relay UE is connected after the handover.

[0211] In summary, in cellular or other wireless networks, relay communication devices may be introduced to support indirect network connectivity of remote communication devices within an OoC area, thereby extending access device coverage and increasing available data capacity for communication devices that may not be within the optimal coverage range of the access device. For directly connected communication devices, mechanisms for bit rate recommendation, bit rate query, and desired bit rate indication are defined. However, these existing mechanisms do not work for communication devices indirectly connected via relay communication devices. Therefore, it is proposed to determine new data rate recommendations and / or restrictions for one or more downstream communication devices based at least in part on the identification of the logical channel indicated in the received recommendations and / or restrictions.

[0212] While the present invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered as illustrative or exemplary, and not restrictive. The present invention is not limited to the disclosed embodiments. The proposed enhanced rate recommendations or restrictions may be implemented in all types of wireless networks in which repeaters are used. For example, the present invention may be applied to devices communicating using cellular wireless communication standards, particularly the 3rd Generation Partnership Project (3GPP®) 5G specifications.

[0213] Thus, the wireless communication device can be a different type of device, for example, a mobile phone, a vehicle (for vehicle-to-vehicle (V2V) communication or more general vehicle-to-everything (V2X) communication), a V2X device, an IoT hub, an IoT device including low-power medical sensors for health management, medical (emergency) diagnostic and treatment devices for hospital use or first responder use, a virtual reality (VR) headset, etc.

[0214] Furthermore, the present invention may be applied in medical applications or connected healthcare where multiple wireless (e.g., 4G / 5G) connected sensor or actuator nodes participate, in medical applications or connected healthcare where wireless (e.g., 4G / 5G) connected equipment consumes or generates continuous data streams at certain average data rates, such as video, ultrasound, X-ray, computed tomography (CT) imaging devices, real-time patient sensors, audio or voice or video streaming devices used by medical staff, in general IoT applications involving wireless, mobile or fixed, sensor or actuator nodes (e.g., smart cities, logistics, agriculture, etc.), in emergency services and critical communication applications, in V2X systems, in systems for improved coverage of 5G cellular networks using high frequency (e.g., mmWave) RF, and any other application area of ​​5G communications where relaying is used.

[0215] Furthermore, while the above-described embodiments generally describe the creation of a single new MAC / RLC logical channel to carry relayed data for downstream communication devices, similar embodiments are possible in which two or more logical channels are created to carry relayed data for downstream communication devices, for example, to address situations where a single radio bearer requires two or more MAC / RLC logical channels. Other modifications to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure, and the appended claims. In the claims, the word "comprises" does not exclude other elements or steps, and the singular does not exclude the presence of a plurality. A single processor or other unit may perform the functions of several items recited in the claims. The mere fact that certain means are recited in mutually different dependent claims does not indicate that a combination of these means cannot be used to advantage. The foregoing description details certain embodiments of the present invention. However, no matter how detailed the foregoing appears in text, it will be understood that the invention can be embodied in many ways and is therefore not limited to the disclosed embodiments. It should be noted that the use of a particular terminology when describing certain features or aspects of the present invention should not be understood to imply that the terminology has been redefined herein to be limited to include any particular characteristic of the feature or aspect of the present invention to which the terminology pertains.

[0216] A single unit or device may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0217] 4 and 5 may be implemented as program code means of a computer program and / or as dedicated hardware in an associated communication or access device, respectively. The computer program may be stored and / or distributed on a suitable medium, such as an optical storage medium or a solid-state medium, provided together with or as part of other hardware, but may also be distributed in other ways, such as via the Internet or other wired or wireless telecommunications systems.

Claims

1. 1. An apparatus for controlling scheduling of communication resources to communication devices in a relay communication device in a wireless network, comprising: receiving, from an access device of the wireless network or an upstream relay communication device of the relay communication device, a received data rate recommendation and / or restriction, which is one of an aggregate data rate recommendation and / or restriction indicating logical channels associated with at least two communication devices or associated with at least two logical channels of a communication device, or receiving data rate recommendations and / or restrictions of logical channels assigned by the relay communication device to one or more downstream communication devices; determining new data rate recommendations and / or limits for one or more downstream communication devices based at least in part on the identification of the logical channel; transmitting the determined new data rate recommendation and / or limit to at least one of the one or more downstream communication devices; Device.

2. The device of claim 1 , wherein the device determines that the new data rate recommendation and / or limit is less than or equal to the received data rate recommendation and / or limit.

3. 2. The apparatus of claim 1, wherein the received data rate recommendation and / or limit includes indicator data indicating whether the received recommendation and / or limit applies to an upstream data flow or a downstream data flow.

4. The apparatus of claim 1 , wherein the apparatus sends a request for a desired data rate for an aggregate of logical channels to the access device or the upstream relay communication device of the relay communication device.

5. The apparatus of claim 4 , wherein the request is triggered based at least in part by at least one request for a desired data rate received from one of the one or more downstream communication devices.

6. 2. The apparatus of claim 1, wherein the apparatus receives a request for a desired data rate for a logical channel from one of the one or more downstream communication devices, determines a data rate recommendation and / or limit for the logical channel based on the received request, and responds to the request with the determined data rate recommendation and / or limit.

7. 2. The apparatus of claim 1, wherein, in response to a data rate recommendation and / or restriction received from the access device or from the upstream relay communication device of the relay communication device and indicating an identification of a first logical channel, the apparatus searches in an internal table of the relay communication device for an identification of a second logical channel for sending a new data rate recommendation and / or restriction to the downstream communication device and a corresponding downstream communication device, or, in response to a request for a desired data rate received from one of the one or more downstream communication devices and indicating an identification of a first logical channel, the apparatus searches in the internal table of the relay communication device for an identification of a second logical channel for sending a new request for a desired data rate to the access device or to the upstream relay communication device of the relay communication device.

8. 8. The apparatus of claim 7, wherein when the apparatus determines that a new logical channel has been created for a communication link with one of the one or more downstream communication devices, the apparatus creates an additional logical channel on the wireless link with the access device or an upstream relay communication device.

9. 8. The apparatus of claim 7, wherein the internal table maps an identification of a logical channel between the relay communication device and the access device or the upstream relay communication device to multiple identifications of logical channels between the relay communication device and the one or more downstream communication devices.

10. 10. The apparatus of claim 1, wherein the data rate recommendation and / or limitation is transmitted using at least one of a Medium Access Control Protocol, a Radio Link Control Protocol, a Packet Data Convergence Protocol Data Carrying Adaptation Protocol, a Packet Data Convergence Protocol, a Radio Resource Control Protocol, and a Service Data Adaptation Protocol.

11. 10. The apparatus of claim 1, wherein the apparatus collects information regarding at least one desired data rate received from the one or more downstream communication devices, transmits the collected information to the upstream relay communication device or the access device, receives received data rate recommendations and / or limits from the upstream relay communication device or the access device, and distributes the received data rate recommendations and / or limits at least in part among the one or more downstream communication devices using a predetermined policy.

12. 12. The apparatus of claim 11, wherein the apparatus selects the predetermined policy based on at least one of a quality indicator of a logical channel of the relay communication device, a number of downstream communication devices of the relay communication device, a number of upstream communication devices of the 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 slice identifier, and a buffer status of the relay communication device.

13. the apparatus determines, triggered by a loss of a communication link between the relay communication device and at least one other communication device or by a decision that the communication link should be terminated, further new data rate recommendations and / or limitations for one or more downstream communication devices; transmitting the further new data rate recommendations and / or restrictions to at least one downstream communication device; 10. The apparatus of claim 1.

14. A relay communication device for a wireless network, comprising an apparatus according to any one of claims 1 to 13.

15. 15. A wireless communication system comprising: a relay communication device according to claim 14; and an access device, wherein the access device receives a desired data rate for an aggregate of logical channels from the relay communication device; and determines for which downstream communication devices the desired data rate of the aggregate applies based on an identification of the logical channels.

16. 1. A method for controlling scheduling of communication resources to communication devices in a wireless network, comprising: receiving, from an access device or an upstream relay communication device of the wireless network, received data rate recommendations and / or limitations, the received data rate recommendations and / or limitations being one of logical channels associated with at least two communication devices, or aggregate data rate recommendations and / or limitations indicative of at least two logical channels of a communication device, or data rate recommendations and / or limitations of logical channels assigned by the relay communication device to one or more downstream devices; determining new data rate recommendations and / or limitations for one or more downstream communication devices based at least in part on the identification of the logical channel; transmitting the determined new data rate recommendation and / or limit to at least one of the one or more downstream communication devices; A method comprising:

17. 17. A computer program comprising code means for causing the steps of the method according to claim 16 when said computer program is executed on a computing device.

Images