Enhanced scheduling in wireless networks with relay functionality

Abstract

Enhanced scheduling in wireless networks with relay functionality. In cellular or other wireless networks, relay terminal devices can be introduced to support indirect network connectivity for remote terminal devices in out-of-coverage (OoC) areas, thus improving network coverage. Such relay terminal devices buffer upstream and downstream data from / to other terminal devices connected indirectly. However, relay terminal devices can have a limited memory allocation for buffering. This limitation has a great impact on the optimal resource scheduling performed by network access devices. Therefore, it is proposed that relay terminal devices report information about their available or maximum buffer capacity to their respective network access devices to enable optimal resource scheduling by the access devices.

Description

Technical Field

[0001] The present invention relates to resource scheduling in wireless networks with relay capabilities (e.g., but not limited to, cellular networks having indirect network connections for remote communication devices (e.g., terminal devices such as user equipment (UEs)) outside the network coverage area). Background Technology

[0002] Many wireless communication systems use network access devices (such as base stations, Node Bs (eNB, eNodeB, gNB, gNodeB, ng-eNB, etc.), access points, etc.) to provide geographic service areas in which wireless communication devices (e.g., terminal devices such as mobile stations or UEs) communicate with access devices serving the specific geographic service area where the terminal device is located. Access devices are connected within the network, allowing communication links to be established between wireless communication devices and other devices. In some cases, the communication link is between wireless communication devices that are close to each other. In these cases, it may be desirable to have a direct communication link between two wireless communication devices, rather than communicating through an access device. This 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 can be a subset of the communication resources used by the communication system for communication between wireless communication devices and access devices, or they can be different sets of communication resources (e.g., unlicensed frequency bands or millimeter-wave frequency bands).

[0003] In-Coverage (InC) communication devices are communication devices that are within the service area of ​​an access device and are capable of communicating with the access device. Out-of-Coverage (OoC) devices or remote communication devices are typically communication devices that are not within the service area of ​​any access device or are within the service area of ​​an access device but are not permitted to be accessed by the access device (e.g., because it is a non-public network (NPN) access device).

[0004] Service requirements related to wireless communication systems are considered in different ways for D2D (Direct-to-Directional) connections. The first approach uses direct device connections without any intermediate network entity. The second approach provides a relay communication device between two remote devices. The third approach provides a relay communication device between the remote communication device and the network. This is called the indirect network connection mode. Relay communication devices can use various access schemes, such as 5G New Radio (NR) radio access technology, Long Term Evolution (LTE), WiFi, or fixed broadband.

[0005] Radio frequency (RF) resources are considered expensive to use, and their management presents significant challenges for the evolution of cellular networks. Furthermore, data services with stringent latency and reliability requirements in upcoming cellular networks necessitate effective resource allocation schemes for their success.

[0006] In a radio access network (RAN), the access equipment should schedule communication resources for transmission for all communication devices to achieve maximum efficiency in spectrum resource utilization. In a RAN that supports indirect network connections, this includes scheduling for any indirectly connected remote or relay communication devices.

[0007] Therefore, scheduling should be extended to work on both directly and indirectly connected communication devices, including those indirectly connected via two or more relay communication devices (“multi-hops”). Furthermore, the scheduling solution should take into account that relay communication devices may have limited buffer memory space available for buffering data used to relay data streams. Therefore, access devices should perform scheduling in a manner that prevents buffer overflows and the resulting data loss. Additionally, the scheduling solution should consider that the buffer memory available at the relay communication device for buffering data for a specific upstream parent communication device or downstream child communication device can vary depending on the device type (e.g., low-cost Internet of Things (IoT) nodes versus powerful mobile phones) and over time (e.g., if a relay communication device has only one child remote communication device at a given time, it can have significantly more buffer memory available for that child device than if it has fifteen downstream communication devices assigned to it). Summary of the Invention

[0008] The purpose of this invention is to provide an extended scheduler that also considers communication devices with indirect connections in wireless networks.

[0009] This objective is achieved by the apparatus according to claims 1 and 4, the access device according to claim 12, the communication device according to claim 13, the method according to claims 14 and 15, and the computer program product according to claim 16.

[0010] According to a first aspect, an apparatus is provided for scheduling communication resources of at least one communication device in a wireless network (e.g., at an access device, at a relay communication device, or at a remote communication device), wherein the apparatus comprises: a capacity detector configured to detect buffer capacity information signaled from the wireless network and indicating the available or maximum buffer capacity of at least one relay communication device; and a scheduler configured to schedule communication resources for at least one of the following based on the received buffer capacity information: transmitting upstream or downstream data for the target communication device on a device-to-device communication channel between the target communication device and the at least one relay communication device, and transmitting upstream or downstream data for the at least one relay communication device on a device-to-device communication channel between the at least one relay communication device and another relay communication device or on a direct radio access link between the at least one relay communication device and an access device.

[0011] As described above, the apparatus of the first aspect of the present invention can also be included in a remote communication device. This is possible, for example, when the remote communication device operates in a resource self-scheduling mode. In this mode, the remote communication device will, for example, select resources that it can use from a resource pool available to one or more remote communication devices. This could be the case of a remote UE implementing sidelink scheduling mode 2. In this case, the target communication device corresponds to the remote communication device itself. Also as described above, the apparatus of the first aspect of the present invention can also be included in a relay communication device. This is possible, for example, when the relay communication device operates in a resource self-scheduling mode. In this mode, the relay communication device will, for example, select resources that it can use from a resource pool available to one or more relay communication devices. This could be the case of a relay UE implementing sidelink scheduling mode 2, as it is outside the coverage area of ​​the access device. In this case, the target communication device corresponds to the relay communication device itself.

[0012] According to a second aspect, an apparatus is provided for controlling the scheduling of communication resources of at least one communication device in a wireless network (e.g., at the communication device), wherein the apparatus comprises: a capacity detector configured to determine the available or maximum cache capacity of a data cache at a relay communication device; and a capacity reporter configured to report cache capacity information, including the determined available or maximum cache capacity, to the wireless network in response to a triggering event.

[0013] According to a third aspect, an access device including the apparatus described in the first aspect is provided.

[0014] According to a fourth aspect, a communication device is provided that includes the means described in the first or second aspect.

[0015] According to a fifth aspect, a method is provided for scheduling communication resources of at least one communication device in a wireless network, wherein the method includes: detecting buffer capacity information that is signaled from the wireless network and indicates the available or maximum buffer capacity of at least one relay communication device; and scheduling at least one of the following based on the received buffer capacity information: transmitting upstream or downstream data of the target communication device on a device-to-device communication channel between the target communication device and the at least one relay communication device, and transmitting upstream or downstream data of the at least one relay communication device on a device-to-device communication channel between the at least one relay communication device and another relay communication device or on a direct radio access link between the at least one relay communication device and an access device.

[0016] According to a sixth aspect, a method is provided for controlling the scheduling of communication resources of at least one communication device in a wireless network, wherein the method includes: determining the available or maximum buffer capacity of a data buffer at a relay communication device; and reporting the determined available or maximum buffer capacity to the wireless network in response to a triggering event.

[0017] Finally, according to the seventh aspect, a computer program product including a code module is provided, the code module being used to generate the steps of the method described above according to the fifth or sixth aspect when run on a computer device.

[0018] Therefore, the scheduler at the access device receives the required buffer capacity information from directly and indirectly connected remote and / or relay communication devices, thereby enabling optimal scheduling of communication resources for directly and / or indirectly connected remote or relay communication devices, avoiding buffer overflows, congestion, and data loss in relay communication devices. Thus, communication resources can be scheduled for indirectly connected remote or relay communication devices. Therefore, when scheduling communication resources, the access device can also consider the indirectly connected communication devices and their available buffer capacity.

[0019] According to the first option, which can be combined with any of the first to seventh aspects described above, the scheduling can be adapted to determine, based on received buffer capacity information, to add an additional parent relay communication device and / or remove an existing parent relay communication device for one of the relay or remote communication devices in the wireless network. This also includes the case where one parent relay communication device is replaced by another parent relay communication device. Therefore, additional relay data buffer capacity and additional communication resources can be scheduled to increase the data throughput of a specific data stream to or from the relay or remote communication device. For example, this decision can be followed by an instruction message sent to one or both of the relay or remote communication device and the additional parent relay communication device. Optionally, a new parent relay communication device can be added, and simultaneously, the existing parent relay communication device can cease acting as the parent relay for that particular relay or remote communication device. Alternatively, the instruction message can be provided indirectly via the core network. Upon receipt, the instruction message can trigger the addition of an additional upstream relay communication device.

[0020] According to the second option, which can be combined with the first option or any of the first to seventh aspects described above, the scheduling can be adapted to perform buffer capacity control by at least one of the following: instructing the relay communication device to increase or decrease the buffer capacity for a specific logical channel or logical channel group, or a specific downstream relay or remote communication device; switching the relay communication device between an autonomous mode and a directed mode of buffer allocation; setting a buffer allocation policy at the relay communication device; setting the reporting granularity of the relay communication device; and instructing the relay communication device to merge multiple individual buffers into a single buffer allocation. These alternative or cumulative buffer capacity control options enable efficient, flexible, and rapid resource scheduling in wireless networks with communication devices having direct and indirect connections.

[0021] According to a third option, which can be combined with the first or second option or any of the first to seventh aspects described above, the cache capacity report can be adapted to send the cache capacity information to a network function, which forwards the cache capacity information to the scheduling access device of the wireless network. This measure provides the advantage that the cache capacity information does not have to be reported directly to the access device, but can be forwarded to other network functions to provide enhanced reporting flexibility.

[0022] The buffer capacity information can be reported in either an absolute or relative format, depending on the fourth option, which can be combined with any of the first to third options or any of the first to seventh aspects described above. Therefore, the reported buffer capacity information can be adapted to the individual requirements of the selected format or channel used to transmit the buffer capacity information.

[0023] According to the fifth option, which can be combined with any of the first to fourth options or any of the first to seventh aspects described above, the cache capacity report can be combined in the following ways: by reporting different logical channels existing for at least one upstream link and / or at least one downstream link of the relay communication device, different priority levels of cached data existing in the relay communication device, and cache capacity information for at least one of the different downstream communication devices existing for the relay communication device; or by combining the cache capacity reports of one or more downstream relay communication devices with its own cache capacity report. This combination of reported cache capacity information from different sources leads to improved efficiency and speed in reporting and resource scheduling.

[0024] According to the sixth option, which can be combined with any of the first to fifth options or any of the first to seventh aspects described above, cache capacity information can be combined in the following ways: by reporting a cache capacity report in which multiple elements are concatenated binary payloads, each element corresponding to a logical channel of the relay communication device; or by including its own cache capacity report and / or the cache capacity report of the sidelink-connected communication device in a combined cache capacity report; or by summarizing cache capacity information into a more concise cache capacity report; or by reporting pairs of logical channels or logical channel groups and associated cache capacity reports; or by reporting pairs of data priority levels and associated cache capacity reports; or by selecting more relevant or more urgent cache capacity reports for priority reporting; or by combining at least one cache capacity report and at least one cache size report into a single report. This combination of report capacity and / or size information from different sources leads to improved efficiency and speed in reporting and resource scheduling. A specific example of a cache size report could be 3GPP BSR MAC CE, as described later.

[0025] According to the seventh option, which can be combined with any of the first to sixth options or any of the first to seventh aspects described above, the cache capacity report can be encoded by at least one of the following: using a cache capacity index of a lookup table; using a current cache load percentage; mapping the reported cache capacity to a capacity category; using a flag indicating whether a cache capacity threshold has been reached or exceeded; using a composite value indicating the resource usage of the relay communication device, wherein the value is at least partially determined by the current cache capacity of the relay communication device; using a composite value indicating the relay communication device's preference or ability to accept additional remote communication devices, wherein the value is at least partially determined by the current cache capacity of the relay communication device, including metadata about the cache and including specific requests triggered by cache-related conditions. Such an encoding method provides the advantage that the reporting load can be minimized by adapting the reporting load to individual resource scheduling requirements.

[0026] It should be noted that the proposed composite value enables the reporting of relay communication device load (e.g., the current resource usage or ability to accept connections from (one or more) other remote communication devices) and buffer capacity. Therefore, this allows the scheduler to make the most appropriate decision during scheduling.

[0027] As an alternative to or in combination with the seventh option, information about cache load can be reported. For example, the capacity reporter is proposed to include information related to at least one of the following in the cache capacity report information, or to encode the cache capacity report using at least one of the following: an index of a cache load lookup table; the current cache load percentage; past cache load; a mapping of the reported cache load to a load category; a flag indicating whether a cache capacity threshold has been reached or exceeded; a composite value indicating the resource usage of the relay communication device, wherein the value is at least partially determined by its current or past cache load; and a composite value indicating the relay communication device's preference or ability to accept additional remote communication devices, wherein the value is at least partially determined by its current or past cache load.

[0028] According to the eighth option, which can be combined with any of the first to seventh options or any of the first to seventh aspects described above, the cache capacity report can be implemented by reporting the cache capacity information using at least one or a combination of the following: a transport protocol over Internet Protocol (IPC), a Radio Resource Control (RFC) message, a Packet Data Unit (PaCN) of a Packet Data Convergence Protocol (PDCP), a control element of a Media Access Control (MAC) protocol, a Service Data Unit (SDN) of the MAC protocol, and a data format of uplink control information or sidelink control information. The use of the Service Data Unit covers cases where the cache capacity report is transmitted within the MAC payload but not as a control element. These different transmission options provide flexible implementation of the proposed scheduling and reporting solution.

[0029] According to the ninth option, which can be combined with any of the first through eighth options or any of the first through seventh aspects described above, the triggering event can correspond to at least one of the following: a change in the maximum buffer capacity on the relay communication device to a lower capacity; a change in the available buffer capacity of the data buffer; a timer-based trigger; a predetermined percentage increase in the load of the data buffer; a fraction or data size relative to previously reported buffer capacity information; receiving at least one of the following: receiving a buffer capacity query from a scheduling access device or an upstream relay communication device; a change in buffer capacity on a remote communication device; receiving a buffer size or capacity report from a downstream remote or relay communication device; receiving a buffer status message or scheduling request message from a downstream remote or relay communication device; receiving a communication resource request message from a downstream remote or relay communication device; receiving a discovery or status request message from a downstream device or a communication device outside the coverage area; receiving a request from an access device; and receiving a recommended bit rate message or recommended bit rate query message from a downstream remote or relay communication device. These triggering options allow the proposed scheduling and reporting solution to respond quickly and effectively to changing buffer capacity conditions and / or radio channel conditions. Therefore, the threshold can be defined as a fraction or percentage of the cache capacity used (also known as "cache load"), or as the absolute size of the cached data. An example of a scheduling request message could be a scheduling request (SR) bit sent in a side link control information (SCI). As another example, it could be a resource request within a radio resource control (RRC) message.

[0030] It should be noted that the above-mentioned device may be based on discrete hardware circuits with discrete hardware components, an arrangement of integrated chips or chip modules, or on a signal processing device or chip controlled by software routines or programs stored in memory, written on a computer-readable medium, or downloaded from a network (such as the Internet).

[0031] It should be understood that the apparatus according to claims 1 and 4, the access device according to claim 12, the communication device according to claim 13, the method according to claims 14 and 15, and the computer program product according to claim 16 may have particularly similar and / or identical preferred embodiments as defined in the dependent claims.

[0032] It should be understood that the preferred embodiments of the present invention can also be any combination of the independent claims or the above embodiments and the corresponding dependent claims.

[0033] These and other aspects of the invention will be apparent and explained with reference to the embodiments described below. Attached Figure Description

[0034] In the following figures:

[0035] Figure 1 This schematically illustrates a network architecture with a buffer overflow problem in a relay communication device;

[0036] Figure 2 A block diagram of an access device according to various embodiments is shown schematically;

[0037] Figure 3 A block diagram of a communication device according to various embodiments is shown schematically;

[0038] Figure 4 A flowchart of a scheduler according to various embodiments is illustrated schematically;

[0039] Figure 5 A flowchart of a cache capacity reporting procedure according to various embodiments is illustrated schematically;

[0040] Figure 6 The diagram schematically illustrates a network architecture for collecting cache capacity information via a relay communication device according to various embodiments; and

[0041] Figure 7 A network architecture for distributing scheduling information via relay communication devices is illustrated schematically according to various embodiments. Detailed Implementation

[0042] Embodiments of the invention are now described based on resource scheduling of a 5G cellular network for enabling UE-to-network relay functionality, wherein 4G network elements can be incorporated into the proposed 5G solution. Furthermore, at least some of the following embodiments are described based on 5G New Radio (5G NR) radio access technology. Specifically, the relay function enables multi-hop indirect network connections for remote communication devices (e.g., UEs). This is done specifically to achieve improved coverage for communication devices and improved low-power operation for IoT communication devices.

[0043] Throughout this disclosure, the abbreviations “eNB” (4G term) and “gNB” (5G term) are intended to refer to access devices such as cellular base stations or WiFi access points. An eNB / gNB is part of a Radio Access Network (RAN) that provides an interface to functions within the Core Network (CN). The RAN is part of a wireless communications network. It implements Radio Access Technology (RAT). Conceptually, it resides between communication devices such as mobile phones, computers, or any remotely controlled machine and provides connectivity to their CN. The CN is the core part of the communications network, providing numerous services to customers interconnected via the RAN. More specifically, it directs communication flows through the communications network and possibly other networks. In the 3GPP specifications TS 23.303 and TS 24.334 for 4G networks, the so-called Proximity Service (ProSe) function is defined, in particular, to enable connections for cellular communication devices (e.g., UEs) that are temporarily outside the coverage area of ​​the access device (eNB). This specific function is referred to as ProSe UE-to-Network Relay or Relay UE. A relay UE is a communication device that facilitates communication between another OoC UE and an eNB (i.e., an access device) by relaying application and network data services in both directions between an OoC UE and an eNB. Local communication between a relay UE and an OoC UE is referred to as D2D communication, sidelink communication, or PC5 communication. The abbreviation "PC5" specifies the interface used for sidelink communication as defined by ProSe. Furthermore, the abbreviation "UL" is used for the uplink direction from a communication device (e.g., UE) to an access device (e.g., eNB, gNB), the abbreviation "DL" is used for the downlink direction from an access device (e.g., eNB, gNB) to a communication device (e.g., UE), and the abbreviation "SL" is used for sidelink communication between two or more communication devices (e.g., UEs).

[0044] Once a relay relationship is established, the OoC-UE connects via the relay UE and acts as a "remote UE". This means the remote UE has an indirect network connection to the CN, rather than the direct network connection as is normal (see 3GPP specification TS22.261v16.10.0). The term "upstream" is used for data destined for the access device or to indicate a communication device closer to the access device (in terms of hop count), while the term "downstream" is used for data flow from the access device to communication devices in the RAN or to indicate a communication device farther away from the access device (in terms of hop count). The prefix "parent" indicates an upstream relay communication device used by a remote or relay communication device, and the prefix "child" indicates a downstream relay communication device connected to a given relay communication device, or a downstream remote communication device that directly uses a specific relay communication device as its parent.

[0045] Ongoing standardization work (e.g., 3GPP specification TR 22.866v17.1.0) extends the concept of single-hop relay to support communication over multiple radio hops and the use of relays for commercial or IoT applications. ProSe Release 15 only allows single-hop relay communication devices to provide a single connection to the network (access device) so that remote communication devices can have indirect network connections to access devices (e.g., eNB) and 4GCN. Future 3GPP releases beyond Release 16 aim to enable multi-hop relays for 5G systems, where relay UEs can connect to other relay UEs, etc.

[0046] The upcoming standardization steps (which begin in 3GPP specification TR 23.752v0.3.0) are to integrate ProSe for UE-based relays into 5G-based networks and specifications. It is expected that the 4G ProSe concept will be reused as much as possible in 5G specifications, with the 5G V2X architecture (see 3GPP specification TS 23.287v16.1.0) serving as a starting point.

[0047] Furthermore, 3GPP specifications TR 23.733v15.1.0 and TR 36.746v15.1.1 provide research on architectural enhancements, such as enabling IoT devices (in the role of remote UEs) to operate at very low power by connecting to a wider network using relay UEs. Because the relay UEs are physically very close, they can be reached using very low power transmission. This work also includes improvements to the security, speed, and stability of ProSe. These extensions to ProSe are referred to as Enhanced ProSe (“eProSe”).

[0048] One proposed improvement in eProSe is an enhanced relay architecture operating at the second protocol layer (i.e., L2), designed to provide end-to-end Internet Protocol (IP) and Packet Data Convergence Protocol (PDCP) packet transmission for application and / or user data to remote communication devices. The advantage of this architecture is that remote communication devices become directly visible as registered entities in the CN, which is relevant for monitoring and billing purposes, as well as improved control of access devices through the communication equipment.

[0049] Because wireless communication devices vary greatly in characteristics such as low-power operation, maximum permissible latency, achievable transmit output power, achievable duty cycle in transmit and / or receive, required bandwidth, and mobility, wireless network systems such as 5G are designed to be highly flexible in how they can operate. The bandwidth available for UL, SL, and DL data can be dynamically varied under the control of the access device based on data demand and channel conditions at that point in time. To achieve this, a scheduler exists within the access device to schedule communication resources for UL / DL / SL transmissions by the communication devices (e.g., as described in 3GPP specification TS 38.300) and (assist) the RAN in making resource-dependent or relay topology-dependent decisions to optimize the quality of service for all communication devices directly or indirectly served by the access device. UL / DL control information is sent to the communication devices in various ways to communicate scheduling decisions.

[0050] Resource scheduling can be dynamic, meaning that communication resources are allocated on demand based on available data and channel conditions. Semi-persistent scheduling (SPS) is a pre-defined scheduling mechanism that can be quickly activated / deactivated by the access device (e.g., gNB) based on current needs. As an alternative, persistent scheduling can be applied, which is activated once and remains active until explicitly cleared by certain specified events. The idea is to add dynamic scheduling decisions on top of persistent / semi-persistent scheduling decisions to address changes in data rates or special events such as data retransmissions. To enable the scheduler to understand channel conditions, a complex set of reporting structures is defined in the 3GPP specification to report measurements to the access device (e.g., gNB) and control mechanisms for the access device (e.g., gNB) to enable / disable / request reports. These reports thus control the scheduling process. Although most scheduling processes are directly controlled by the scheduler in the access device, the scheduling of communication resources in a wireless network also depends on local decisions made by communication devices that are not under the direct control of the scheduler. For example, self-scheduled resource selection may involve either a remote communication device or a relay communication device selecting a relay communication device, or a remote communication device or a relay communication device re-selecting a relay communication device, or the selection of resources for messages transmitted by remote communication devices that are not within the direct coverage area of ​​the access device and / or are not currently scheduled by the access device (e.g., in Mode 2 defined for sidelink communication in 3GPP specification TS 38.300). These local decisions, in turn, affect and constrain the scheduling decisions that the scheduler in the access device can make. Simultaneously, the scheduler may have devices that directly or indirectly influence these local decisions made by the communication devices. As an example of a direct influence, the access device may directly provide commands or requests to remote communication devices to re-select a specific other parent relay communication device, thereby achieving better quality of service for one or more communication devices in the RAN. As an example of an indirect influence, the access device may configure additional sidelink (SL) resources as a resource pool from which a self-scheduled communication device can select specific resources for transmission via the SL through local decisions. In other words, a remote communication device can run its own scheduler to schedule communication resources and can make its own local decisions about which resources to use and at what time from a predefined subset of resources. These local decisions can be based on various inputs, such as local measurements (e.g., signal or noise levels, reference signal received power, etc.), locally received messages (e.g., SCI messages), configuration data provided by the access device (e.g., parameters provided via RRC messages), or measurement / configuration data provided by the peer communication device. Therefore, these inputs also control the scheduling process, or in other words, these inputs are the control inputs to the scheduling process, where only a portion of the inputs are under the control of the scheduler.As further explanation: if a relay communication device reports its buffer capacity information to a remote communication device, and the remote communication device uses this information to select another relay communication device, then the relay communication device effectively controls the scheduling of communication resources by controlling the allocation of which relay the remote communication device will use and therefore which resources the remote communication device will use for its sidelink communication and (indirectly) the resources provided by the selected relay communication device in the wireless network.

[0051] The element used to implement the scheduling mechanism can be a Radio Resource Control (RRC) protocol, which can potentially operate end-to-end to the UE via one or more hops, taking into account the aforementioned new relay architecture at the second protocol layer (i.e., L2). It can be used for non-time-critical static or semi-static scheduling information; in other words, scheduling configuration. Here, ConfiguredGrantConfig can be an information element used for uplink or sidelink scheduling.

[0052] Another element used to implement scheduling mechanisms can be the control element (CE) of the Media Access Control (MAC) protocol, which is a short element (or information element (IE)) inserted between existing UL / DL / SL transmissions on the MAC layer to effectively signal certain events, measurements, or configurations. A specific example could be the 5G NR Buffer Status Report (BSR) MAC CE, which is used by the communication device (e.g., UE) to signal its current data buffer size to the access device and / or its scheduler. When performing various other 3GPP mechanisms such as Channel State Information (CSI) reporting, Sounding Reference Signal (SRS), or Discontinuous Receive (DRX), the access device (e.g., gNB) can use additional MAC CEs to control the behavior of the communication device (e.g., UE).

[0053] Another element can be the use of Downlink Control Information (DCI), which is a short message transmitted in a low bit rate control channel (e.g., Physical Downlink Control Channel (PDCCH)) with special blind-detectable modulation or coding. This mechanism is implemented at the Physical Protocol Layer (PHY LI) and does not require the use of a MAC L2 header structure. Various DCI formats can be defined using different message contents. Communication resources for dynamic scheduling can be indicated in the DCI. DL data transmission can follow the DCI message, for example, less than 1 ms later, but can be scheduled up to 4 ms earlier. For UL, scheduling can be for the next time slot 1-2 ms earlier, but up to 8 ms earlier.

[0054] Another element could be the use of uplink or sidelink control information (UCI, SCI). This could include, for example, a scheduling request (SR) bit used when no communication resources are available to send a BSR MAC CE or other type of buffer status report. In response to the SR, the scheduler of the access device (e.g., gNB) will allocate uplink communication resources to the communication device (e.g., UE) in the future.

[0055] Another element could be the use of SL / PC5 discovery messages. Such messages can be used, for example, to discover peer relay communication devices for OoC communication devices, to discover one or more potential peer relay communication devices for the purpose of relay selection or reselection by remote or relay communication devices, or to query and / or report the current status and load of nearby relay communication devices. The remote or relay communication device can then use the information learned from the discovery messages (one or more) to make local decisions that affect the scheduling of communication resources. For example, if a remote communication device uses mode 2 resource allocation, it can schedule its sidelink resources differently based on the relay device it has selected or reselected. Furthermore, in cases where the scheduler in the access device is involved in the resource allocation of remote and / or relay communication devices, and if such a device selects a better parent relay communication device due to the relay reselection process, this allows the scheduler in the access device to schedule its resources more efficiently for all scheduled devices in its RAN from that point onward. The transmitted discovery message may be a Model A (i.e., announcement) message that is sent periodically and thus triggered by a timer, or a Model B (i.e., discovery response) message that is triggered by a Model B discovery query message received from a peer communication device (e.g., based on Model A and B as specified in TS 23.303).

[0056] The resource scheduling overview described above applies to communication devices (e.g., UEs) and can also be used for multi-hop solutions. Therefore, depending on the various embodiments, it may be necessary to add new network elements or extend existing elements, as described below. Existing solutions may be insufficient if single-hop or multi-hop relay communication devices are introduced into the network because they may operate on a direct link between the access device (e.g., gNB) and the communication device (e.g., UE), rather than necessarily on an indirect link via a relay between the access device and the communication device.

[0057] In single-hop relay scenarios, an OoC remote communication device (e.g., a remote UE) can schedule its transmissions on the SL connection based on its own channel measurements and random access procedures, or an access device (e.g., a gNB) can schedule all communication resources for all directly and indirectly connected communication devices (e.g., UEs), or a leading communication device (e.g., a UE) of a group of communication devices can coordinate resource allocation for its group members, which can even work if some group members are OoCs but are still within the coverage of the leading group members.

[0058] Note that when an access device (e.g., a gNB) can schedule the communication resources required by indirectly connected communication devices, the efficiency of spectrum use can be increased, while the risk of transmission conflicts and / or unfair spectrum use can be reduced.

[0059] Regarding BSR MAC CE, four different formats are defined in 3GPP specification TS 38.331v15.5.1. A BSR can contain an identifier for a Logical Channel Group (LCG), a set of logical channels with the associated buffer to which the buffer size report applies. More specifically, the buffer size report can include a buffer size field (e.g., 5 or 8 bits long), where bit values ​​can be interpreted based on a predetermined lookup table. The short format can be used to report only one LCG, while the long format can be used to report, for example, one to eight LCGs.

[0060] BSR MAC CE is used as described above, while SLBSR MAC CE is used to specifically report sidelink buffer status. The two types of BSRs can have different formats depending on the number N of LCGs being reported, such as whether N is odd or even, and whether the BSR is truncated. The BSR format may include a "destination index" that encodes an index (e.g., 4 bits) into a list of destination addresses containing data. This can be a unicast destination or a group destination (e.g., multicast D2D / V2X-D2D).

[0061] In IP networks, intermediate routers can use an Explicit Congestion Notification (ECN) mechanism to signal congestion at their location (see IETF specification RFC 3168 for details). Congestion can be caused by, for example, an IP source sending data too fast or insufficient capacity on the outgoing link. In both cases, the impact may be that the router's buffer is full or nearly full. Therefore, filling the router's buffer can serve as a trigger to send an ECN tag along with data packets to the final destination. The final destination then signals the source to the presence of congestion using a protocol acknowledgment (e.g., Transmission Control Protocol (TCP)). The source can then use this information to reduce its data transmission rate. ECN can be applied to cellular 4G / 5G networks (see 3GPP specification TS 36.300v15.2.0 in Section 11.6 for 4G networks and TS38.300v15.5.0 in Section 12.2 for 5G networks). In the event of congestion, the access device (e.g., gNB) itself (e.g., acting as an intermediate router for IP packets destined for / from a communication device (e.g., UE)) can set an ECN bit in the IP packet header to indicate congestion. According to the ECN protocol, this will notify the IP data source that it needs to reduce its data rate.

[0062] In the following embodiments, the term "cache" refers to a buffer of data to be transmitted through a communication link within a communication network, the term "cache size" is intended to represent how much data is actually stored in the cache at a given moment or how much data is calculated as a function (e.g., average) over a specific time period, and the term "cache capacity" is intended to represent how much data can be stored in the cache at a given moment (e.g., additionally or entirely) or how much data is calculated as a function (e.g., average) over a specific time period. The term "cache load" represents a fraction or percentage of the cache capacity used at a given moment or averaged over a specific time period.

[0063] More specifically, cache status information messages are messages that include any kind of cache status information. Cache status information may include cache size information (e.g., Cache Status Report (BSR) or Sidelink Cache Status Report (SL-BSR) as defined in the relevant 3GPP specifications) and cache capacity information. Typical Cache Status Reports (BSRs) or Sidelink Cache Status Reports (SL-BSRs) as defined in the relevant 3GPP specifications only include information about the current cache size. If access devices or the core network also report or manage other cache-related information (such as cache capacity), it will be beneficial for better resource scheduling, especially in relay scenarios. Therefore, it is recommended to use a separate message or to extend existing messages (such as cache status report messages) with cache capacity-related information (i.e., so-called cache capacity reports or cache capacity information). Cache capacity reports may include information about the average available cache capacity (relative or absolute value) at the time of reporting or over a past period, the maximum cache capacity or cache limit (absolute value), the average cache capacity or cache load used at the time of reporting or over a past period (e.g., a fraction of the maximum cache capacity used), as well as metadata (e.g., stable bits) and any other cache-related status information (e.g., LCID, LCG, UE-ID, cache ID, cache capacity alerts, etc.).

[0064] Furthermore, the report should be understood in the sense that it consists of zero or more included reports (received from other devices) plus zero or more information items, wherein the information items may be generated internally or received from another device in another received report. According to various embodiments, a concept is provided for combining multiple buffer capacity reports into a single message (e.g., reports from different nodes or from different logical channels, logical channel groups, or paths) and scheduling communication resources of relay communication devices and remote communication devices to quickly resolve congestion, thereby resolving or preventing buffer overflows in relay communication devices.

[0065] As described above, a relay communication device (e.g., a relay UE) receives and collects one or more cache capacity reports from a sub-telecommunication device and sends these cache capacity reports, possibly in combination, to an access device (e.g., an eNB or gNB), where multiple cache capacity reports are integrated into a single cache size report. Note that cache capacity reports can be combined with other cache capacity reports and / or other cache size reports (obtained from, for example, a BSR MAC CE). This combination of one or more cache capacity reports with one or more cache size reports can then be referred to as a cache status information report.

[0066] In various embodiments, it is further suggested that the access device schedule communication resources for transmission for all communication devices to achieve maximum efficiency in spectrum resource utilization. This can support indirect network connections and therefore supports scheduling for any indirectly connected remote or relay communication devices without buffer overflows and resulting data loss.

[0067] Various embodiments provide a solution for optimal scheduling by an access device in the absence of frequent data loss in intermediate relay communication equipment. This solution includes the access device efficiently collecting necessary information from the communication equipment (e.g., in a RAN) upon which scheduling decisions can be based, including, for example, the communication equipment's buffer size report, buffer capacity report, scheduling requests, locally available buffer size information, or locally available buffer capacity information.

[0068] Figure 1 This schematically illustrates a network architecture with a buffer overflow problem in a relay communication device.

[0069] exist Figure 1 In the scenario shown, the first communication device (e.g., UE1) 12-1 and the second communication device (e.g., UE2) 12-2 act as relay communication devices. The second communication device 12-2, along with the additional third and fourth communication devices (e.g., UE3, UE4) 10-2 and 10-3, rely on the parent relay communication device to establish indirect network connections to the access device (e.g., gNB) 20 and the core network 100. The core network 100 may include network functions such as Network Slice Selection Function (NSSF), User Plane Function (UPF), and Access and Mobility Management Function (AMF). The fifth communication device (e.g., UE5) 10-1 is directly connected to the access device 20 and does not have relay functionality in this scenario.

[0070] A second communication device 12-2 with relay functionality receives a sudden surge in upstream data volume from a remote fourth communication device 10-3 via an SL connection, as indicated by the thick arrow indicating a first event E1. This surge in upstream data volume may have been triggered by an application server (App) 120 connected to the core network 100, and is rapidly filling the buffer allocated by the second communication device 12-2 for upstream data to the fourth communication device 10-3.

[0071] Therefore, it is possible that the second communication device 12-2 does not receive sufficient upstream communication resource allocation (for transmissions to the first communication device 12-1) to offload the buffered data, as indicated by the second event E2. This could be because the access device 20 has not allocated sufficient upstream communication resources for the relay transmission between the first and second communication devices 12-1, due to insufficient communication resources available because of temporarily poor radio channel conditions, or because the access device 20 is unaware that the second communication device 12-2 has a limited buffer capacity available for buffered data (e.g., it could assume a buffer capacity of 16MB, while the second communication device has only allocated 128KB), or because the fourth communication device 10-3 uses self-scheduled SL communication (i.e., not scheduled from the access device 20) to send data to the second communication device 12-2, making it impossible for the access device 20 to control the amount of data transmitted to the second communication device 12-2, as indicated by the third event E3.

[0072] As an example, in 4G / 5G ProSe and 3GPP V2X D2D communication, the latter case of self-scheduled SL communication is explicitly permitted for pre-licensed OoC communication devices that are not directly connected to an access device (e.g., gNB). The transmitter then uses pre-configured or pre-announced frequency resource pools and performs self-scheduled communication within these pools.

[0073] Regardless of whether the fourth communication device 10-3 uses self-scheduled resource allocation or its allocated communication resources are scheduled by the access device 20, the filling of the buffer at the second communication device 12-2 will eventually lead to buffer saturation and thus cause potential packet drop in the relay-type second communication device 12-2, followed by retransmission from the fourth communication device 10-3, for example, when no PDCP acknowledgment is received from the access device 20 (in the case of an L2 relay architecture) or the relay communication device 12-2 (in the case of another relay architecture that provides PDCP acknowledgment only through one radio hop).

[0074] In the case where the fourth communication device 10-3 is scheduled by its parent device (i.e., the second communication device 12-2) on behalf of the access device 20, the second communication device 12-2 can prevent buffer saturation by scheduling fewer communication resources for the fourth communication device 10-3. However, this may result in important data not being sent to the network in a timely manner, or in a situation where less data is needed to flow to the network than that required by the fourth communication device 10-3.

[0075] The ECN mechanism implemented in 4G / 5G networks cannot solve this problem. Because the second communication device 12-2 is a node experiencing congestion, it should be the node that marks IP packets as "congested" using the ECN bits in the IP header. However, the second communication device 12-2 may not necessarily see the IP packets it relays, because depending on the relay solution, it can relay PDCP packets without needing to know or access the unencrypted content of the PDCP Service Data Unit (SDU) containing the IP packets of the remote fourth communication device 10-3. Furthermore, the ECN mechanism in 4G / 5G was developed for coarse-grained voice / video codec rate selection and rate adaptation, such as for LTE Voice (VoLTE) or IP Multimedia Subsystem (IMS) or multimedia telephony service video sessions, for example for mobile phones directly connected to the core network via a set of base stations and network functions, rather than for fine-grained resource control of short burst data transmissions and / or time-critical or energy-critical communications of IoT devices via relay devices.

[0076] Another complication is that the relay data buffer capacity allocated to the second communication device 12-2, which has relay functionality, may dynamically change due to network changes caused by the fact that one or more new relay communication devices and / or remote communication devices are attached to the second communication device 12-2, or one or more existing relay communication devices and / or remote communication devices (other than the fourth communication device 10-3) begin to send more data and thus fill the corresponding buffers (one or more) more quickly, thereby reducing the available buffer capacity allocated to the fourth communication device 10-3. Therefore, if, for example, more remote communication devices are attached, the relay data buffer capacity of each remote communication device decreases. Or, if existing remote communication devices begin to send more data, the maximum buffer capacity remains unchanged, but the available buffer capacity decreases. In both cases, the access device 20 should be notified of the change to improve overall scheduling.

[0077] Another complication is that the relay device may not know which remote device is the source of the high data load, for example, because the source is more than one hop away from the relay device (e.g., via another relay device). This is relevant when the relay device performs resource scheduling on behalf of the access device for its downstream relays and / or remote devices. Figure 1In this scenario, a situation may arise if the buffer of the first relay communication device 12-1 is nearly full and it is unaware that the fourth communication device 10-3 is the responsible source. In this case, for example, the first communication device 12-1 may have difficulty directly signaling to the source (e.g., the fourth communication device 10-3) to send less data because it does not know the source of the data. The first communication device 12-1 could signal its downstream neighbor, the second communication device 12-2, to notify it of the congestion it is causing. This would then prompt the second communication device 12-2 to signal the fourth communication device 10-3. However, this ECN-like mechanism may result in some data from the fourth communication device 10-3 not being sent to the network on time. This mechanism does not allow for adaptation of network scheduling on all upstream links leading from the fourth communication device 10-3.

[0078] According to various embodiments, a relay-type first communication device 12-1 is therefore proposed to be directly connected to access device 20 and to act as a relay communication device for exchanging upstream / downstream data between a remote communication device (e.g., a third communication device 10-2) and access device 20. When triggered by an event, access device 20 provides cache capacity information regarding the available capacity of the data cache residing in the first communication device 12-1 and / or the available capacity of the data cache residing in the relay-type second communication device 12-2 and / or any other possible relay-type communication devices (if present). The provided cache capacity information can be formatted in a recognizable manner such that access device 20 can associate a maximum capacity information item with the specific communication device that initially reported this information item. A scheduler at access device 20 is configured to use the provided cache capacity information to schedule communication resources for transmitting upstream or downstream data from the first communication device 12-1 and / or the second communication device 12-2 and / or any other relay-type communication device.

[0079] However, it should be noted that the provision of cache capacity information is not necessarily limited to within the RAN. It can also be forwarded via a loop to access device 20; that is, a relay communication device (e.g., the first communication device 12-1) can send the cache capacity information to a network function in the core network 100, which can then provide the cache capacity information back to the access device. Alternatively, it can be forwarded to downstream communication devices, such as downstream remote communication devices, which use the information to make an application-level decision about which relay communication device to use in the future, i.e., for the relay reselection process. Or, it can be forwarded to OoC communication devices, such as communication devices discovering status information about the expected relay communication devices in order to make an informed decision about which relay communication to select for future indirect communication, i.e., for the relay selection process.

[0080] Cache capacity information can be forwarded in absolute form (e.g., “X bytes of available capacity”) or relative form (e.g., X% of available cache capacity), and the receiver may optionally derive information about the absolute number of bytes that can be buffered based on this cache capacity information. However, knowledge such as “80% of the cache is full” may be sufficient to trigger mitigation actions (i.e., influence scheduling) without needing to know how many bytes of cache space that 80% corresponds to, particularly if the access device (or core network) manages one or more cache capacities used by the relay communication device, or if the access device (or core network) has received information about the cache capacity from the relay communication device as part of a previous message, or if the percentage is relative to a pre-configured or known cache capacity (e.g., pre-configured as part of a policy), or expressed as an index in a table with values ​​for different cache capacities and cache load-related values.

[0081] In some alternatives, a composite value can be used to indicate the resource usage of a relay communication device. This value can be determined at least in part by the relay communication device's current cache capacity and / or past cache capacity (e.g., current cache load percentage, average cache load percentage over the last 2000ms time window, etc.). In another example, the composite value indicates the relay communication device's preference or ability to accept additional remote communication devices. The composite value can be determined in part by the relay communication device's current cache capacity, or by the average cache capacity calculated over a period of time, or alternatively by the worst-case cache capacity measured over a period of time. A specific example of the latter is the worst-case cache load percentage measured over the past 2000ms time window. The composite value can be encoded as an integer value in, for example, a predefined range (e.g., 0-3 or 0-100), or, for example, as a QoS identifier identifying the quality of service achievable under the current relay load, which is encoded as, for example, a PQI or 5QI identifier.

[0082] Figure 2 A block diagram of an access device according to various embodiments is shown schematically.

[0083] Note that in Figure 2 Only those blocks relevant to the proposed enhanced scheduling functionality are shown. Other boxes have been omitted for brevity.

[0084] Figure 2 The access device can correspond to Figure 1 Access devices (e.g., gNB) 20 or any other type of access device for any wireless network with resource scheduling capabilities.

[0085] according to Figure 2The access device includes a transceiver unit (TRX) 21 for transmitting and receiving wireless messages and / or other wireless signals via an antenna. Messages containing resource scheduling information or commands are generated by one or more schedulers 24 based on buffer size and capacity information derived from directly and indirectly connected communication devices (including remote, relay, or other communication devices) stored in a data storage (DM) 25 (e.g., a database) connected to the scheduler 24.

[0086] In addition, the access device includes a capacity information detector (CD) 22, which detects, for example, cache capacity information contained in a cache capacity report received from a communication device (e.g., a relay UE) via a transceiver unit 21.

[0087] Based on capacity information, such as that obtained from a cache capacity report, scheduler 24 generates scheduling information for the relay communication device, which is forwarded to the relay communication device via transceiver unit 21.

[0088] Therefore, an enhanced scheduling process can be provided that takes into account the available buffer capacity of both directly and indirectly connected relay communication devices.

[0089] Figure 3 A block diagram of a relay communication device (e.g., a relay UE) according to various embodiments is shown schematically.

[0090] Notice, Figure 3 Only those blocks relevant to the proposed enhanced scheduling functionality are shown. Other boxes have been omitted for brevity.

[0091] The communication equipment in Figure 23 can correspond to Figure 1 The first and second communication devices (e.g., UE1 and UE2) 12-1 and 12-2, or any other type of relay communication device for any wireless network with resource scheduling capabilities.

[0092] according to Figure 3 The relay communication device includes a transceiver unit (TRX) 31 for transmitting and receiving wireless messages and / or other wireless signals via an antenna. Messages with buffer capacity information (e.g., buffer capacity reports) are generated by a capacity information generator (IG) 33 based on the available buffer capacity of its own relay data buffer (RDB) 34 and buffer capacity information of the data buffers of one or more connected and / or adjacent relay communication devices that may be derived from it.

[0093] In addition, the relay communication device includes a capacity information detector (CD) 32, which detects cache capacity information contained in a cache capacity report received via transceiver unit 31 from a connected and / or adjacent communication device (e.g., a relay UE).

[0094] Based on its own capacity information and capacity information obtained from cached capacity reports of connected and / or adjacent relay communication devices, capacity information generator 33 generates one or more combined or enhanced cached capacity reports, which include cached capacity information of the relay communication device and its adjacent and / or connected relay communication devices. These combined or enhanced cached capacity reports are forwarded via transceiver unit 31 to the access device or upstream relay communication device in response to a triggering event described later. Forwarding can be direct or indirect (e.g., via multiple hops and / or via network functions). The upstream device can combine the cached capacity report with its own cached capacity report and send the combined report to the access device, or the upstream device can remove cached capacity information (e.g., if the upstream device performs aggregation or selection of cached capacity reports).

[0095] Therefore, an enhanced scheduling process can be provided that takes into account the availability and / or associated buffer capacity of relay communication devices that are directly and indirectly connected.

[0096] Figure 2 and 3 The blocks of the block diagram may be implemented by discrete hardware circuits such as one or more application-specific integrated circuits (ASICs), one or more programmable logic arrays (PLAs), one or more field-programmable gate arrays (FPGAs), or by one or more digital signal processors (DSPs) or other software-controlled processor circuits.

[0097] Figure 4 A flowchart of a scheduler according to various embodiments is illustrated schematically. The scheduler may be implemented at an access device (e.g., gNB or eNB or base station or access point) of a cellular or other wireless network.

[0098] In the first step S401, the access device receives and detects the buffer capacity information of the directly and indirectly connected relay communication devices in the corresponding enhanced buffer capacity report. Then, in step S402, the received buffer capacity information is allocated to the corresponding directly and / or indirectly connected relay communication devices. In step S403, communication resources are scheduled for the communication devices based at least in part on the allocated buffer capacity information. Finally, in step S404, the scheduled communication resources are signaled to the corresponding directly and / or indirectly connected communication devices.

[0099] Figure 5 A flowchart of a cache state information reporting procedure according to various embodiments is illustrated schematically.

[0100] The reporting procedure can be initiated by a triggering event occurring at the respective relay communication device, as described later. In the first step S501, the relay communication device determines the available capacity of its own relay data buffer. Depending on the circumstances and / or the triggering event, the determined capacity may be the capacity of a subset of the buffers. Then, in step S502, the available buffer capacity of one or more indirectly connected neighboring relay communication devices is determined and collected, for example, based on a received buffer capacity report. In step S503, buffer capacity information for its own relay data buffer and / or a combination of directly and / or indirectly connected relay communication devices is generated, for example, in a combined buffer capacity report. In some cases, all buffer capacity information may not be included (e.g., the relay communication device may include only its own and other indirectly connected relay communication devices' buffer capacity information). Furthermore, there may be cases where only its own relay data buffer capacity is reported in step S503 without reporting information for any other neighboring devices. This could be, for example, when the relay communication device has no sub-relay communication devices, or when the sub-relay communication device independently (e.g., via RRC, PDCP, IP, etc.) reports buffer capacity information to the access device and is not combined with the relay communication device. Another possibility is that the relay communication device leaves its own buffer capacity information (even if it is determined) and only reports the buffer capacity information of, for example, indirectly connected relay communication devices.

[0101] Finally, in step S504, the determined and / or collected cache capacity information is reported to the access device and / or the upstream relay communication device. Therefore, the reported cache capacity information may include at least one of the cache capacity information determined in step S501 and the cache capacity information collected in step S502.

[0102] Note that, depending on the triggering event and / or circumstances, the combined cache capacity information may exclude, for example, one or more of the cache capacity information of its own relay data cache, directly connected relay communication devices, or indirectly connected relay communication devices.

[0103] Notice, Figure 4 and 5 The steps of the flowchart can be implemented based on one or more software routines for controlling the processors or computing units provided in the access device or relay communication device, respectively.

[0104] When reported by relay communication equipment, cache capacity information can be encoded in various ways. Enhanced cache capacity reports can include one or more maximum or available cache capacity information items for each report.

[0105] As a first option, multiple items can be reported for different logical channels existing in one or more upstream links and / or one or more downstream links of the relay communication device, wherein the maximum or available buffer capacity can be reported for each logical channel.

[0106] As a second option, multiple items can be reported for different priority categories of cached data existing in the relay communication device, wherein the maximum or available cache capacity can be reported for each priority category.

[0107] As a third option, multiple items can be reported for different downstream communication devices existing in the relay communication device. Specifically, the maximum or available cache capacity can be reported for each downstream communication device. A separate cache can be allocated within the relay communication device for each downstream communication device.

[0108] As a fourth option, buffer capacity reports received from one or more downstream relay communication devices can be combined with their own buffer capacity reports and then reported as a combined buffer capacity report.

[0109] Even when a relay communication device reports more than one available capacity information item, it can still be restricted to reporting fewer than all available capacity information items in the buffer capacity report due to configuration settings from the access device (e.g., gNB) (e.g., indicating that only a subset should be reported temporarily) or due to size constraints (e.g., there is only enough space in the current physical layer transport block to report fewer than all available capacity information elements (e.g., individual maximum buffer capacity)). Other capacity information items can be reported later (e.g., in the next physical layer transport block).

[0110] According to various embodiments, an enhanced cache capacity report can be provided in a combined format, which includes multiple items from the same relay communication device. These can also be combined with values ​​from other relay communication devices within a single cache capacity report, as described later.

[0111] As a first option, the relay communication device can report a binary payload containing N concatenated elements, each element corresponding to buffer capacity information of, for example, one of its logical channels, in ascending order of Logical Channel ID (LCID) or Logical Channel Group (LCG) number. If the access device receiving the buffer capacity report stores the LCID or LCG number in use for the relay communication device, it can reconstruct a matching LCID or LCG number for each element, and thus provide the advantage that encoding can be effective for the complete buffer capacity report without needing to encode the LCID or LCG number.

[0112] As a second option, the relay communication device may include its cache capacity report and / or SL cache size report (e.g., SL BSR MAC CE) and / or UL cache size report (e.g., BSR MAC CE) together with the cache capacity information specified by at least one other option in the combined cache status information report.

[0113] As a third option, the relay communication device can aggregate buffer capacity values, for example, by omitting information reports of nearly empty buffers, in order to provide more efficient or concise reporting to its upstream parent device or access device (e.g., gNB). Alternatively, it can use two or more different formats to encode multiple capacity information items, for example, a compact format (e.g., 2 bits) for less important buffers and a high-detail format (e.g., 8 bits) for more important or most important relay data buffers.

[0114] As a fourth option, relay communication devices can report paired LCID or LCG numbers and related buffer capacity information.

[0115] As a fifth option, relay communication devices can report pairs of data priority level indicators and buffer capacity information.

[0116] As a sixth option, the relay communication device may select only the relevant cache capacity information items (e.g., omit cache capacity information or report nearly empty caches) to report more effectively or preferentially to its upstream parent device or access device, or it may select those cache capacity reports with high cache load, where urgent action (excluding others) is required from the access device and its scheduler.

[0117] As a seventh option, the relay communication device may report, to or from the identified (downstream) communication device, pairs of communication device identifiers and cache capacity information related to the cached data. Alternatively, it may report an ordered list of cache capacity information elements, where each element reports cache capacity information for a set of one or more caches associated with only a single downstream communication device.

[0118] As already mentioned, the maximum or available cache capacity can be reported as an absolute or relative value. Reporting a relative value has the following benefits: along with information about current cache usage (i.e., current cache size), the maximum or available cache capacity can be inferred, and it allows the maximum or available cache capacity to also change dynamically based on the environment without having to re-report both the absolute maximum or available cache capacity value and the cache size report value. The compact reporting format can also help limit signaling overhead.

[0119] According to various embodiments, the information items in the enhanced cache capacity report can be encoded as follows:

[0120] 1. The n-bit category number can refer to the maximum capacity in bytes for a table lookup that accesses the lookup table using, for example, a cache capacity index (e.g., 8-bit length). These values ​​are agreed upon in advance by the standard.

[0121] 2. Encoding of the current cache load percentage (0-100%), which can be encoded as, for example, an 8-bit or 7-bit number representing an integer percentage. This encoding can be useful when the access device can correlate this encoding with reports or earlier reports of cache size information from the same communication device to estimate the absolute value of the maximum cache capacity on the communication device.

[0122] 3. The current cache load percentage (0-100%) is encoded to approximate the true percentage, and can be encoded as 6 bits, 5 bits, 4 bits, 3 bits, or 2 bits. This encoding can be useful when the access device can combine it with reports or earlier reports of cache capacity information from the same communication device. Alternatively, 2-bit encoding can be mapped to categories <25%, <50%, <75%, and >90%.

[0123] 4. A highly compact 1-bit code (flag) that, when set to 1, indicates "cache usage threshold exceeded". The threshold can be a priori determined number, such as an 80% threshold, or it can be a threshold consistent with earlier (setup) communication between the reporting communication device and the access device (e.g., RRC protocol communication). Such a threshold can be defined relative to the UE's maximum memory allocation, the maximum memory available for sidelink or uplink cache, the maximum capacity of a specific cache, the (average) cache load, or the current capacity of a specific cache.

[0124] 5. As in option 3 above, the encoding is n bits, where each value represents a specific threshold of cache load pre-agreed in communication between the access device and the reporting communication device. For example, the access device may link each value to a lookup table of cache full percentage pushed to the communication device during setup (RRC) communication.

[0125] 6. Meta-information about the cache can be reported, such as a single bit (“stable bit”) indicating whether the allocated cache is guaranteed to be at least its current capacity (e.g., “1”) or not guaranteed (e.g., “0”) to remain at that capacity, or a single bit indicating whether the allocated cache needs to shrink (e.g., “1”) or not shrink (e.g., “0”) for any reason (e.g., reconfiguration of relay and / or telematics equipment in the network, or application in relay communication equipment requiring more memory). More bits can be used to encode the reason for cache shrinkage or the duration for which the current cache capacity allocation is guaranteed in relay communication equipment.

[0126] 7. The reported information may include specific requests to the access device arising from cache-related issues, such as an "alarm" field or bit instructing the access device that a relay device wants to offload one or more remote communication devices to another relay device because communication resources are becoming scarce on the relay device itself, or a "capacity" field field instructing the access device how much cache space is available for any future relay or remote communication device if any future relay or remote communication device is added as a child node to the current relay device. When the relay architecture used in the wireless network supports such reconfiguration, this can improve the allocation of relay or remote communication devices to parent relay devices through network topology reconfiguration.

[0127] According to various embodiments, reporting cache capacity information to an access device and / or another communication device in the wireless network can be achieved through the following options:

[0128] 1. Transport protocols over Internet Protocol (IP) can be used, such as Hypertext Transfer Protocol (HTTP), CoAP, Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Message Queuing Telemetry Transport (MQTT), etc. When the reporting relay communication device is not directly connected to the access device, it can relay one or more IP packets carrying one or more transport protocol PDUs and buffer capacity information to the access device. Once the IP packets arrive at the access device, they are forwarded to the network function (NF) indicated by the IP destination address. If the NF is external to the access device, it can notify the access device of the reported buffer capacity information after receiving the buffer capacity report, allowing the access device to use this for scheduling according to various embodiments. Otherwise, if the NF is internal, i.e., located at the access device, it directly receives and uses the reported buffer capacity information.

[0129] 2. The RRC protocol can be used for end-to-end relaying between relay communication devices and access devices in an L2 relay architecture, or, for example, for end-to-end relaying over a single wireless link between a relay communication device and another relay or remote communication device in an L3 relay architecture, or directly reported to peer communication devices via the PC5 interface and SL. RRC messages are then transmitted via PDCP, Radio Link Control (RLC), MAC protocol, and potentially multiple hops. This option offers the benefits of guaranteed transmission reliability (via PDCP, using retransmission) and application of integrity protection. Note that the above-mentioned RRC transmitted device-to-device over a single link is called PC5-RRC.

[0130] 3. PDCP control or data PDU can be used.

[0131] 4. A MAC control element (CE) can be used, which is sent via SL to the next upstream relay device, or via SL to the peer device, or directly via UL to the access device. This is a lightweight approach in which, in some cases, unused space in the transport block can even be opportunistically utilized, for example, as achieved by filling the BSR MAC CE.

[0132] 5. The uplink control information (UCI) data format can be used, which is transmitted directly from the relay communication device to the access device via the UL channel (e.g., via the physical uplink control channel (PUCCH) or the physical uplink shared channel (PUSCH)).

[0133] 6. Within the Side Link Control Information (SCI) data format, it can be transmitted from a relay communication device to another relay or remote communication device via an SL connection.

[0134] 7. PC5 messages via SL, such as relay discovery messages, relay announcement messages, relay discovery response messages, or PC5-RRC messages, can be used. This has the following benefits: it allows reporting to communication devices with which the sender has not yet established a PC5 link, and it allows reporting to multiple devices simultaneously using broadcast messages.

[0135] 8. A combination of the above options, such as reporting directly to the access device via RRC and also reporting to the direct upstream parent trunk device via MAC CE. Or, for example, reporting to the parent trunk device via MAC CE, the parent trunk device then collecting one or more reports from the child trunk device and sending these reports directly to the access device using RRC.

[0136] According to various embodiments, the PDCP control PDU can be used to send buffer capacity information to the access device. According to Section 6.3.8 of 3GPP specification TR38.323v15.6.0, control PDU types 010-111 can still be used for additional extensions and therefore can be used to signal buffer capacity information.

[0137] The new PDU type can use any format, such as a single value reported by a relay device to an upstream parent relay device or directly to an access device, or a buffer capacity report that combines multiple values ​​and is reported to an upstream parent relay device or directly to an access device. The report can consist of the relay device's own buffer capacity report plus information from an aggregated buffer capacity report received from a downstream relay device, or the buffer capacity report can be combined with buffer size information previously reported by the downstream (relay) device (e.g., information from a BSR MAC CE or SLBSR MAC CE).

[0138] This PDCP-based approach is advantageous because it offers low overhead and enables end-to-end transmission from relay communication equipment to access equipment in an L2 relay architecture. PDCP control PDUs can be interleaved with conventional PDCP data PDUs on existing radio bearers.

[0139] like Figure 5 As indicated in the program, the proposed cache capacity report can be triggered by an event (e.g., a rule or instruction) occurring at the relay communication device. Examples of such events could be:

[0140] 1. The maximum buffer capacity on relay communication equipment has been changed to a lower capacity;

[0141] 2. The data relay cache has been filled to a level higher than a defined threshold, where the threshold can be absolute (e.g., measured in bytes) or relative (e.g., a percentage of the total cache capacity available for that particular cache, or a percentage of the total buffer memory available in the communication device).

[0142] 3. Timer-based triggers;

[0143] 4. The load on the relay data cache has increased by at least N% compared to the previously reported load;

[0144] 5. Receive a cache capacity query from the scheduling access device or upstream relay communication device;

[0145] 6. Changes in the cache capacity of remote communication devices;

[0146] 7. Receive a buffer size or capacity report from downstream remote or relay communication equipment;

[0147] 8. Receive buffer status messages (e.g., SL-BSR MAC CE), scheduling request messages, or query messages (e.g., recommended bit rate query MAC CE, or relay status query message, or relay discovery message) from downstream remote or relay communication devices;

[0148] 9. Receiving a recommended bit rate message (e.g., Recommended Bit Rate MAC CE) or a query message (e.g., Recommended Bit Rate Query MAC CE) from a downstream remote or relay communication device; and

[0149] 10. A communication resource request message is received from a downstream remote or relay communication device. For example, a relay discovery request message broadcast by a remote communication device aims to discover a parent relay communication device that may be more suitable than its current relay communication device.

[0150] 11. Receive communication resource request messages or query messages from OoC communication devices. For example, a relay discovery request message broadcast by an OoC communication device aims to discover suitable relay communication devices.

[0151] Where not every relay communication device (e.g., a relay UE) reports its own buffer capacity information directly and independently to the access device (e.g., a gNB), a format for combining reports from multiple relay communication devices to the access device can be used. Combined buffer capacity reporting can be advantageous due to reduced signaling overhead and therefore more efficient use of communication resources. Another potentially advantageous feature is that upstream relay communication devices can gain insight into the buffer capacity reports of their downstream relay communication devices and thus be able to better regulate data traffic or increase their own buffer allocation for certain data flows to help downstream relay communication devices experiencing high buffer loads.

[0152] Examples of various options for combining formats can be:

[0153] 1. The relay communication device reports a binary payload, which consists of N+1 cascaded elements, starting with its own buffer capacity report as the first element. The remaining N elements can then be buffer capacity reports from its downstream relay debugging devices (sub-devices) in ascending order of ID number, where the ID number can be any relevant identifier, such as a Radio Network Temporary Identifier (RNTI), or a ProSe UE ID, or a ProSe Relay UE ID, etc.

[0154] 2. Relay communication equipment combines the buffer capacity reports of downstream relay communication equipment into a combined buffer capacity report through cascading.

[0155] 3. Relay communication devices aggregate buffer capacity reports received from downstream relay communication devices to report more efficiently to their upstream parent devices or access devices. For example, the format can be compressed from the original 8-bit buffer load (%) value to a 2-bit value (e.g., <25%, <50%, <75%, >90%). Individually attributable reports can still be preserved; for example, the reporter's identity can be implicitly encoded according to the order in which the 2-bit elements are sent.

[0156] 4. Relay communication devices can report paired IDs and buffer capacity reports for each relay communication device, where the ID can be one of the IDs defined in Option 1 above. Alternatively, short IDs can be defined to improve efficiency; for example, access devices can convert them into 4-bit or 8-bit indices that report the true identity of the relay communication device.

[0157] 5. Relay communication equipment can select only relevant reports, such as those with high buffer load, where an emergency action from the access device's scheduler is required.

[0158] In one embodiment, an access device (e.g., a gNB) may determine, based on a received buffer capacity report, that a relay or telecom device (e.g., a UE) might require an additional parent relay device above its current parent relay device, because the buffer in that relay device or one of its upstream parent relay devices may fill too quickly or overflow. To achieve this, the access device may instruct a specific relay or telecom device to acquire an additional parent or initiate a parent replacement.

[0159] Figure 6 The diagram schematically illustrates network architectures according to various embodiments, where, for example, a MAC CE is used to collect cache capacity information via a relay communication device. Figure 6 The network architecture components correspond to Figure 1 Components that have the same reference numerals are not described here.

[0160] Access device 20 schedules communication resources based on the received buffer size and capacity information.

[0161] exist Figure 6 In the scenario shown, the remote fourth communication device 10-3 suddenly generates a large amount of data and sends a portion of this data, along with a MAC CE type similar to an SLBSR MAC CE, to its parent (i.e., the second communication device 12-2 of the second relay type) to indicate the remaining data to the parent (arrow R1). Note that for this embodiment, the MAC CE can also be the same as an SLBSR MAC CE.

[0162] New data filling the relay buffer in the second communication device 12-2 exceeds a predefined threshold. This corresponds to an event that triggers the second communication device 12-2 to report its buffer capacity information to the upstream relay type first communication device 12-1, as indicated by arrow R2. It can do this by forwarding a separate new MAC CE element “MaxSize” indicating its maximum buffer capacity, as well as an SL BSR MAC CE or equivalent new MAC CE type indicating its current relay buffer size(s).

[0163] The first communication device 12-1 receives the MaxSize MAC CE and the BSR MAC CE, and then reports its own and the second communication device 12-2's MaxSize information to the access device 20, as indicated by arrow R3. It also adds an extended BSR MAC CE that includes the buffer capacity of itself and the second communication device 12-2. The term "extended" is used here to indicate that the existing BSR MAC CE cannot contain the buffer size of other devices. Therefore, an extended MAC CE is proposed, which can be similar to the existing MAC CE, but also enables the storage of data from other devices.

[0164] Then, the scheduler of access device 20 determines that more bandwidth is needed on the path from the remote fourth communication device 10-3 to the access network, and begins sending messages with resource scheduling information to allocate more communication resources, as follows: Figure 7 As described.

[0165] Figure 7 The diagram schematically illustrates network architectures according to various embodiments, wherein, for example, DL control information (DCI) and RRC messages are used to distribute scheduling information via relay communication devices. Figure 7 The network architecture components correspond to Figure 1 Components that have the same reference numerals are not described here.

[0166] exist Figure 7 In scenarios such as transmitting DCI via PDCCH, the PDCCH only includes dynamic UL and / or DL ​​and / or SL scheduling for the relay-type first communication device 12-1, as indicated by arrow M1. This may not be transmitted once, but rather whenever the first communication device 12-1 is authorized for (additional) communication resources for DL ​​or UL data transmission. Therefore, it can be transmitted multiple times during the scheduling process.

[0167] Then, a first RRC message is sent (e.g., via PDCP), which includes an SL scheduling update for the relay-type second communication device 12-2, as indicated by arrow M2.

[0168] Finally, a second RRC message is sent (e.g., via PDCP), which includes an SL scheduling update for the remote fourth communication device 10-3, as indicated by arrow M3.

[0169] Note that the transmission sequence of the first and second RRC messages can be changed. It can be the default sequence or it can be preset.

[0170] If updating the resource allocation of the fourth communication device 10-3 is not required, the aforementioned second RRC message can be optional.

[0171] With the new resource allocation, the second communication device 12-2 can transmit more data to the first communication device 12-1, and the first communication device 12-1 can transmit more data to the access device 20 in the UL direction, thereby reducing the percentage of relay data buffer usage of the second communication device 12-2.

[0172] In various embodiments, access device 20 can control and thus influence the maximum or available buffer capacity of the relay communication device. It does so in response to one or more previously received buffer capacity reports. Buffer capacity control can be implemented through at least one of the following options:

[0173] 1) Command the relay communication device to increase or decrease the buffer capacity of a specific LCID, or a specific LCG, or a specific downstream sub-relay or remote communication device, or a data stream associated with a specific network slice;

[0174] 2) Switching the relay communication device between the "autonomous mode" of buffer allocation (completed by the relay communication device itself) and the "directed mode" of buffer allocation (where the access device 20 determines the buffer capacity via control commands);

[0175] 3) Configure a policy in the relay communication device regarding how buffer allocation should be performed, wherein the policy may include determining the data buffer capacity in the relay communication device;

[0176] 4) Configure the reporting granularity of reports generated by the relay communication device, for example, switch from a low-precision buffer capacity value to a high-precision buffer capacity value or vice versa, increase the time interval between reports, or request a higher-level report (less detailed) or vice versa; and

[0177] 5) Command relay communication devices can merge multiple separate caches into a single cache allocation. For example, create a shared cache for all upstream relay data traffic instead of maintaining N separate caches for N LCIDs or M separate caches for M downstream communication devices.

[0178] In another embodiment, which can be combined with any other embodiment of the invention or implemented independently of various aspects of the invention, low-latency reporting using scheduling request timing can be provided when the relay communication device is the last relay communication device preceding access device 20 and is directly connected. This reduces the latency between the event that new data becomes available on a communication device and the access device 20 receiving data in the absence of existing UL communication resources authorized for sending application data and / or cache size information (e.g., BSR MAC CE) and / or cache capacity information from the last-hop relay communication device.

[0179] To achieve this, multiple PUCCH scheduling request (SR) configurations can be used in the last-hop relay communication device. These can be configured by the access device 20 and can include at least a first PUCCH SR configuration for low-latency data (including relayed low-latency data) and a second PUCCH SR configuration for non-low-latency data. The PUCCH scheduling request configuration is used to execute a scheduling request (SR) procedure on the PUCCH to request resources for uplink shared channel (UL-SCH) transmission, as defined in 3GPP specifications TS 38.300v16.4.0 and TS 38.321v16.3.0. Each configuration can include a set of PUCCH resources spanning different bandwidth portions and cells. Each logical channel on the relay communication device can be mapped to a specific SR configuration via an RRC configuration defined in TS38.331v16.3.1. An RRC configuration information element (IE) is a ScheduledRequestConfig that can contain a series of ScheduledRequestToAddMod elements. The ScheduledRequestToAddMod elements are configured with parameters for a specific SR configuration to be added, including sr-ProhibitTimer and sr-TransMax, which respectively control the retransmission timer and the maximum number of retransmissions for the SR. Another RRC configuration IE is a ScheduledRequestResourceConfig that defines a specific time / frequency resource configuration for the SR. This includes the periodicityAndOffset field, which defines the frequency at which an SR opportunity occurs and where it occurs (e.g., every time slot (s11) or every eight time slots (s18)). Another RRC configuration IE is ScheduledRequestResourceConfig-v1610, which defines the priority selection (p0 = low, or p1 = high) for a specific ScheduledRequestResourceConfig. Therefore, an SR configuration associated with a logical channel used for low-latency data can, for example, use an SR opportunity with high priority (p1) in every time slot (sl1). Furthermore, the SR configuration associated with the logical channel used for non-low latency data can, for example, use SR opportunities every 7 slots (s18) and low priority (p0).

[0180] Furthermore, the access device can influence cyclic shift and orthogonal coverage sequences, as well as whether a UE should perform frequency hopping. By providing different scheduling request configurations and different PUCCH resources, the access device can identify scheduling requests from each connected UE individually or even per logical channel ID.

[0181] When the relay communication device has low-latency upstream relay data to send to the access device 20, or when the relay communication device is triggered to send buffer size information related to the buffered low-latency upstream relay data to the access device 20 (e.g., using BSR MAC CE), or when the relay communication device is triggered to send buffer capacity indication data related to the buffered low-latency data to the access device 20, the relay communication device may use the first PUCCH SR configuration to send SR signals.

[0182] As a result of receiving a scheduling request, the access device can allocate uplink resources to the relay communication device to send buffered low-latency data. Using the uplink resources allocated by the access device 20, the relay communication device transmits buffered low-latency relay data (if any) and buffer capacity information to the access device 20 (the buffer capacity information can be sent later if the delivery of the low-latency data itself is considered more important).

[0183] It should be noted that this principle can actually be applied to any UE that transmits low-latency data, and is not limited to relay communication equipment.

[0184] Therefore, according to a first aspect of this embodiment, a method for requesting communication resources in a network is provided, the method comprising:

[0185] At the relay communication equipment, a scheduling request (SR) configuration is selected from a set of scheduling request configurations based on the type of data to be transmitted.

[0186] The relay communication device uses the selected scheduling request configuration to send a scheduling request signal.

[0187] The relay communication device uses the communication resources allocated by the access device in response to the selected scheduling request sent to send at least the buffer capacity information to the access device.

[0188] Furthermore, according to a second aspect of this embodiment, a relay communication device for requesting communication resources in a network is provided, the relay communication device comprising:

[0189] The controller is adapted to select a scheduling request (SR) configuration from a set of scheduling request configurations based on the type of data to be sent.

[0190] A transmitter adapted to send a scheduling request signal using a selected scheduling request configuration, the transmitter being configured to send at least buffer capacity information to the access device using communication resources allocated by the access device in response to the sent selected scheduling request.

[0191] In this embodiment, the set of scheduling request configurations includes at least a first scheduling request configuration for low-latency data (including, for example, relayed low-latency data) and a second scheduling request configuration for non-low-latency data.

[0192] In another option of this embodiment, a scheduling request is triggered in response to any of the following events: the relay communication device has low-latency upstream relay data to be sent to the access device, triggering the transmission of buffer capacity information related to the buffered low-latency upstream relay data to the access device, or triggering the transmission of buffer capacity information related to the buffered low-latency data to the access device.

[0193] The benefit of using this low-latency specific SR configuration is that the SR will directly indicate to the scheduler of access device 20 that the low-latency data is pending at the relay communication device for one of its downstream communication devices, so that the scheduler will schedule radio resources for UL at the first possible time and / or with higher priority, which improves scheduling to achieve lower latency.

[0194] However, the access device may not be aware of how much low-latency data the relay communication device has buffered. According to TS38.321, if uplink resources are insufficient, they will also be used to send a Buffer Status Report (BSR) message to the access device. However, in the case of low-latency relay data or low-latency data typically used by the UE, it may be beneficial to use all uplink resources to send the low-latency data. But if this is done, the access device will not be able to distinguish whether the scheduled UL resources are just sufficient, almost sufficient (leaving no space for BSR messages), or insufficient to send the buffered data. For this purpose, one option could be that, in the case of low-latency data for the access device, if all (or almost all, i.e., above a certain threshold) uplink resources within a specific time interval are used to send buffered low-latency data (i.e., without any other content or messages such as BSRs), the access device assumes that uplink resources are insufficient and immediately schedules additional uplink resources. This assumes that the access device will be able to determine, based on received scheduling requests, whether uplink resources are used to send data from the buffer containing low-latency data, for example, by identifying that the scheduling request is associated with a logical channel used to transmit low-latency data. The disadvantage of this approach is that it may allocate too many resources that the UE does not need. Furthermore, if all buffered low-latency data has already been transmitted, the UE may also use additional uplink resources for less urgent data. Therefore, if uplink resources are just sufficient, the access device may not be able to distinguish this situation. Thus, in one embodiment that can be combined with any other embodiment of the invention or implemented independently of various aspects of the invention,

[0195] The UE includes special signals (e.g., by adding flags or setting bits to the header of messages sent to the access device, or appending them to the end of all sent messages) to indicate that more data is waiting to be sent and / or that a BSR is waiting to be sent. Another option is to send a buffer load percentage, buffer capacity index, or flag indicating whether a buffer load threshold has been exceeded to the access device using scheduled uplink resources, if information about buffer capacity is available or managed by the access device, or has already been signaled by a coil buffer capacity report. This can reflect the buffer size after the buffered data has been sent to the access device (i.e., the amount of data remaining in the buffer). Alternatively, the UE can send a copy of a previously sent scheduling request or a new scheduling request related to low-latency data as part of the scheduled uplink resources, or immediately after the last sent message or the first PUCCH opportunity (if this arrives before receiving additional uplink resources). The benefit is that all these signals are generally smaller than a BSR message (e.g., if a separate buffer is used for low-latency data, logical channel ID or logical channel group ID information does not need to be included). This is useful for maximizing the resources available for sending low-latency buffered data, and is also useful, for example, when uplink resources are insufficient to send the BSR and all buffered low-latency data.

[0196] It should be noted that this principle can be applied to any UE that transmits low-latency data, and is not limited to relay communication equipment.

[0197] Therefore, according to a first aspect of this embodiment, a method for requesting communication resources in a network is provided, the method comprising:

[0198] The mobile device uses communication resources allocated by the access device within a given time interval to send cached data of a given type. If the allocated communication resources within the time interval are insufficient to send all cached data of a given type, a cache capacity report, cache load percentage, cache capacity index or flag indicating whether a cache load threshold has been exceeded, or a flag indicating whether more data of a given type is in the mobile device's cache rather than in the BSR is sent as part of the same allocated resources. In one option, the mobile device reserves the number of bits required from the allocated resources to send the cache capacity report, cache load percentage, cache capacity index, or flag for this purpose, and sends this information immediately before (“pre-suspend”) the cached data of a given type or immediately after (“attach”) the cached data of a given type. The number of bits required for this can be pre-agreed / pre-configured by the mobile device and the access device, so all other bits can be used to send cached data of a given type. In another option, cache capacity reports, cache load percentages, cache capacity indexes, or flags are sent as part of the header of the data frame (e.g., MAC(sub) header) or in lieu of the header of the data frame (e.g., MAC(sub) header) (e.g., in lieu of LCID or using the reserved flag R).

[0199] In another option, the relay communication device may maintain a separate buffer for low-latency data, as well as one or more other buffers (e.g., for streaming data that can be buffered separately as lossless and lossy streaming data, bulk data, and latency-insensitive data). For this purpose, the relay communication device may receive information from the remote communication device or access device regarding the type of data to be relayed (which may be, for example, in the form of QoS data, such as 5QI values ​​or logical channel configurations or maximum latency values, or flag / attribute values ​​set during connection establishment, or configurations included in RRC messages, or information in the header of frames / packets). Each of these buffers may be assigned a different identifier, which may be a buffer identifier or an identifier associated with a logical channel / radio bearer (e.g., logical channel ID or LCID) or logical channel group (LCG). These identifiers may be assigned by the relay communication device and can be sent to the access device, or these identifiers may be assigned by the access device and can be sent to the relay communication device. The access device may use such identifiers to define and / or map these identifiers to scheduling request configurations, and transmit the mapping of these identifiers to specific scheduling request configurations to the relay communication device. Using a single, separate cache that aggregates all low-latency data, independent of its originating remote or relay device, simplifies the configuration required to uniquely identify scheduling requests for low-latency data, especially if only a single other cache is used for all other (i.e., non-low-latency) data or messages. Access devices can also define separate scheduling request configurations for different cache sizes or cache load thresholds (e.g., a first scheduling request configuration to use if the cache load percentage is less than 90%, and a second configuration to use if the cache load percentage is at least 90%). This information can be sent as policy information by the Policy Control Function (PCF) or via RRC.

[0200] If a dedicated buffer is used for low-latency data, and resource allocation is prioritized for sending data in the low-latency buffer, the LCID can be omitted from the MAC layer header. Using the mechanism described above to allocate all resources for sending data in a given type of buffer (in this case, low-latency data), and using a buffer capacity report, buffer load percentage, buffer capacity index, or flag to indicate insufficient allocated resources, the mobile device can omit the LCID from the MAC layer header until the low-latency buffer is empty (or below a threshold). Furthermore, if the length of the data payload frame to be used (e.g., MAC PDU / SDU) is known to both the mobile device and the access device (e.g., through pre-configuration), the entire MAC header (including its length field and format) can be omitted. The mobile device can be pre-configured to always switch to a mode that prioritizes sending buffered low-latency data and omits the LCID information from the MAC layer header, or the mobile device can be pre-configured with a strategy that can depend on the buffer load threshold of the low-latency buffer to do so. Alternatively, the access device can use a flag to indicate that scheduled resources will be used to transmit low-latency data.

[0201] Once the low-latency data cache is empty or below a threshold, a cache capacity report, cache load percentage, cache capacity index, or flag is given a value that can be recognized by the access device as an indication that the mobile device will switch back to operating mode. The LCID information is then included again in the MAC layer header. Alternatively, a cache status report should be sent to indicate to the access device that the mobile device has switched back to operating mode. This also includes the LCID information in the MAC layer header and indicates that some other caches (assigned to other LCIDs) may have pending cached data for which uplink resources need to be scheduled.

[0202] In another option, the relay communication device can determine combined cache state information for all intermediate hops (i.e., other relay communication devices) between the remote communication device and the relay communication device. This combined cache state information may include cache size information, such as cache size limits (one or more), cache load levels for each individual cache, or, for example, the type of data to be relayed (e.g., combining all cache state information for low-latency caches used by intermediate relay communication devices or latency-related information, such as the average time data remains in the relay communication device's cache). For this purpose, each relay communication device can send not only its own cache capacity information but also cache capacity information received from intermediate nodes or remote communication devices. Alternatively, the relay communication device can send a message (e.g., an RRC message destined for a particular relay communication device and therefore potentially relayed via one or more downstream relay communication devices) to another (downstream) relay communication device to request its cache capacity information. After collecting, aggregating, and encoding the received cache capacity information from downstream devices (possibly along with its own cache capacity information), the relay communication device can send this combined cache state information to the access device. By providing this information to the access device, the access device can use it to schedule additional sidelink resources, change the timing of the scheduled resources to better align communication between intermediate nodes, and provide instructions on how the relay communication device should use these resources for priority transmission of low-latency data (e.g., by providing the corresponding LCID, LCG, buffer identifier, or remote communication device identifier, which should be given higher priority in time, or for this reason, data should always be sent first before sending any other information (e.g., buffer status report)).

[0203] Based on the received combined buffer state information, the access device can identify a bottleneck in one of the intermediate relay devices used to relay data for a remote UE, and can provide / schedule additional sidelink resources to one or more intermediate relay devices, or instruct to increase the buffer capacity of one or more intermediate relay devices. The relay device can also determine whether to use additional resources or increase its buffer capacity based on received buffer capacity information, for example, based on a pre-configured policy (e.g., received from the access device or from the PCF). Alternatively, it can use additional sidelink resources in unlicensed frequency bands. The relay device and / or the remote UE can also be configured with a resource pool for transmitting low-latency data over the sidelink, separate from one or more resource pools used for transmitting other (i.e., non-low-latency) data. This separate resource pool can use higher frequencies, larger bandwidths, carrier aggregation, and shorter time intervals to enable faster data transmission. Such a resource pool can be configured for a single remote UE (or a very small number of remote UEs) so that the remote UE can transmit its data without sensing the medium before transmitting over the sidelink, thus reducing latency. For this purpose, if a low-latency QoS is requested for a remote UE, the access device authorizes and configures a separate resource pool for sidelink communication, for example, via (directly or via a relay device) an RRC message to the relay device and / or the remote UE. It can also configure the identity of the remote UE and the set of certificates to use (as part of establishing a communication connection over the sidelink) to allow the relay device to identify whether the remote UE is authorized to use the separate resource pool. The relay device can notify the remote UE of the separate resource pool for low-latency communication after a sidelink connection has been established, either during relay discovery or sidelink connection establishment, or via RRC or other messages.

[0204] In another option, based on received cache capacity information (e.g., if the maximum cache capacity is reached or if the remaining memory capacity is insufficient to add additional remote communication devices or relay communication devices), the access device can send a message to the relay communication device to stop making itself discoverable as a relay. Furthermore, criteria for doing so can be sent to the relay communication device (e.g., via a policy (pre)configured) sent by the access device or by the PCF, allowing it to make the decision without consulting or receiving additional messages from the access device. Similarly, if the access device (or the policy-based relay communication device) determines that the latency caused by a particular relay communication device exceeds a threshold (e.g., based on the average time relay data remains in the cache), it can instruct the relay communication device to stop making itself discoverable, or it can instruct the remote communication device to select another relay communication device to transmit its data to the access device or core network. For this purpose, the relay communication device can report the average latency caused by the relay communication device via a PC5 discovery message or via an RRC message. This latency information can be reported by relay communication device, by LCID, by LCG, or by cache ID. The relay communication device can also receive information about the average end-to-end delay for sending messages to the access device via one or more relay communication devices from other relay communication devices (or indirectly from the access device), and can send information about the end-to-end delay to the remote communication device or other relay communication devices in PC5 discovery messages and / or RRC messages.

[0205] In a sub-implementation, low-latency reports using SR timing for a specific remote communication device or a specific downstream logical channel ID or cache ID (which may differ from the LCID used on the Uu interface) for PC5 communication between the remote communication device and the relay communication device can be provided as a special case of the above embodiments. When relaying data for one or more remote communication devices or relay communication devices, the data is typically multiplexed by a relay communication device (i.e., the "previous" relay communication device) directly connected to the access device (e.g., via the Uu interface). For this purpose, the relay communication device may have a mapping of multiple logical channel identifiers / radio bearers used by downstream devices, or, for example, an adaptation layer that can map the communication channels of a specific remote or relay communication device to a set of logical channels / radio bearers on a direct (e.g., Uu) connection between the "previous" relay communication device and the access device. For this purpose, the "previous" relay communication device may aggregate data from multiple downstream relay communication devices or remote communication devices and store it in a common cache. This means that the access device cannot know which device the cached data originates from based on received scheduling requests or BSR messages (which report the cache size for each LCID). It only knows that the data will be sent by the "previous" relay device, but it cannot, for example, determine whether the data belongs to a specific remote device or a specific relay device based on the scheduling request or BSR. Of course, it could use higher-layer information (such as an adaptation layer identifier or IP address), but for low-latency data buffers, it is undesirable to have to decode higher layers before deciding on scheduling additional resources. In the above embodiment, the SR from the relay device to access device 20 does not convey information about which remote device in the group needs immediate scheduling of communication resources for delay-critical data. In this particular sub-embodiment, a PUCCH SR configuration can be created specifically for sending an SR associated with a specific downstream remote device, or for a specific downstream logical channel ID or buffer ID for PC5 communication that needs to send delay-critical data via the relay device. Therefore, the type of data on which the SR configuration selection mentioned above is based can also include the identifier or logical channel ID or buffer ID of the remote device. Different scheduling request configurations can then be selected based on the type of data to be sent, where the data type can include the identifier or logical channel ID of the remote device or the buffer ID to which the data is targeted by the relay. This has the following benefits: when access device 20 receives the specific SR signal from the relay communication device, it immediately knows which remote communication device or downstream logical channel or buffer has the delay-critical data to be transmitted, and can immediately schedule communication resources for all relay communication devices involved in the indirect connection with that remote communication device, as well as for the remote communication device itself, to send the data to its parent relay communication device. Note that the remote communication device itself can also act as a relay communication device.As an additional option, access device scheduling can be dedicated to resources for transmitting low-latency data, and this can be done for remote communication devices or relay communication devices that have identified bottlenecks or have low-latency data to transmit. This can include scheduling resources from the sidelink resource pool at very short repetition intervals or in a separate frequency range to reduce contention. Alternatively, a separate scheduling request message via PC5 / sidelink can be used. In the case of such a sidelink scheduling request, different configurations can be used (e.g., configured by the access device in the relay communication device or remote communication device, or configured by the relay communication itself, after which information about the scheduling request configuration is sent to the remote communication device or downstream relay communication device), allowing the relay communication device to identify which remote communication device or downstream relay communication device or logical channel or buffer it is applied to based on the received sidelink scheduling request. Furthermore, after receiving a sidelink scheduling request, the relay communication device can allocate resources to retrieve data from the buffer of the downstream remote communication device or relay communication device. In the case of low-latency data, a similar mechanism as defined above can be used, whereby buffer capacity information is sent along with the buffered data.

[0206] In another embodiment, buffer capacity information is reported by a relay communication device to one or more peer communication devices using D2D messages (e.g., PC5 discovery announcement messages or PC5 discovery response messages). These peer communication devices use this information, along with other information such as the measured signal strength of received communication messages, to control the selection and / or reselection of the relay communication device. Using this information allows the peer communication devices to (re)select the optimal relay for their indirect communication needs, thereby contributing to the optimal scheduling and distribution of communication resources in the wireless network. The peer communication device can be a relay communication device, a remote communication device, or an OoC communication device. The buffer capacity information transmitted can be a PC5 discovery response message (Model B discovery), or it can be a PC5 discovery announcement message (Model A discovery). The buffer capacity information can be encoded in any of the aforementioned ways. It can also be encoded as part of a combined value “Relay Load,” which indicates the load level on resources of the relay used for its relay-related operations or overall computing and communication operations. Multiple such resource levels, possibly combined with one or more combined values ​​of relay load, can also be reported in a single message. The resources reported or used in the combined trunk load values ​​can be one or more of the following: processing power, memory usage, cache-specific memory usage, upstream or SL or UL bandwidth used, downstream or DL ​​bandwidth used, number of active telecom devices, etc. "Trunking load" can also be encoded as the opposite, "trunking capacity," indicating how much resource is still available to serve new downstream trunks and / or telecom devices instead of the resources used. Therefore, a peer receiving cache capacity information from multiple anticipated trunk devices can determine which trunk device to provide a reasonable received signal strength (e.g., RSRP) combined with sufficient cache capacity. A peer may have been triggered to perform trunk discovery due to timer expiration or because its current trunk device's reported current cache capacity is below a threshold. If the peer finds a more suitable trunk, it can connect to the additional trunk device acting as its parent, and once connected, it can discard the connection to the old parent trunk device.

[0207] In another option, which can be combined with any other prior embodiment or option, based on received cache capacity information (e.g., if the maximum cache capacity is reached or if the remaining memory capacity is insufficient to add an additional remote communication device or relay communication device), the access device can send a message to the relay communication device to stop making itself discoverable as a relay. Furthermore, guidelines for doing so can be sent to the relay communication device (e.g., via a policy (pre)configured) by the access device or by the PCF, allowing it to make the decision without consulting or receiving additional messages from the access device.

[0208] In summary, methods and apparatuses for cellular or other wireless networks have been described, wherein relay terminal devices can be introduced to support indirect network connections for remote terminal devices in an OoC area, thereby improving network coverage. Such relay terminal devices buffer upstream and downstream data from / to other indirectly connected terminal devices. However, relay terminal devices may have limited memory allocation for buffering relay data. This limitation significantly impacts optimal resource scheduling performed by network access devices. Therefore, methods and apparatuses are proposed to configure relay terminal devices to report information about their available or maximum buffer capacity to their respective network access devices to achieve optimal resource scheduling through the access devices.

[0209] While the invention has been illustrated and described in detail in the accompanying drawings and the foregoing description, such illustrations and descriptions are to be considered illustrative or exemplary rather than limiting. The invention is not limited to the disclosed embodiments. The proposed enhanced scheduling can be implemented in all types of wireless networks; for example, it can be applied to devices communicating using cellular wireless communication standards, particularly the 3rd Generation Partnership Project (3GPP) 5G specification. 5G wireless communication devices can be of various types, such as mobile phones, vehicles (for vehicle-to-vehicle (V2V) communication or more generally vehicle-to-everything (V2X) communication), V2X devices, IoT hubs, IoT devices including low-power medical sensors for health monitoring, medical (emergency) diagnostic and treatment devices, devices for hospital use or first responder use, virtual reality (VR) headsets, etc.

[0210] It can also be applied to Integrated Access and Backhaul (IAB) systems. Specifically, mobile IAB nodes may move during operation and may lose connectivity with other IAB nodes or base stations. This can cause sudden changes in their corresponding capacity and load, and consequently, may cause one or more caches on the mobile IAB node to reach their maximum cache capacity.

[0211] Furthermore, this invention can be applied to healthcare applications or connections involving multiple wireless (e.g., 4G / 5G) connected sensor or actuator nodes; healthcare applications or connections where wireless (e.g., 4G / 5G) connected devices occasionally consume or generate continuous data streams at a specific average data rate (e.g., video, ultrasound, X-ray, computed tomography (CT) imaging equipment, real-time patient sensors, audio or voice or video streaming devices used by healthcare professionals); general IoT applications involving wireless, mobile, or fixed sensor or actuator nodes (e.g., smart cities, logistics, agriculture, etc.); emergency services and critical communications applications; V2X systems; systems using high-frequency (e.g., mmWave) RF to improve 5G cellular network coverage; and any other application areas using relayed 5G communications.

[0212] Those skilled in the art, through studying the accompanying drawings, disclosure, and dependent claims, will be able to understand and implement other variations of the disclosed embodiments in practicing the claimed invention. In the claims, the word "comprising" does not exclude other elements or steps, and the words "a" or "an" do not exclude a plurality. A single processor or other unit may implement the functions of several items recited in the claims. Although specific measures are recited in dissimilar dependent claims, this does not imply that combinations of these measures cannot be advantageously used. The foregoing description details certain embodiments of the invention. However, it will be appreciated that the invention can be practiced in many ways, regardless of how detailed the foregoing is presented herein, and is therefore not limited to the disclosed embodiments. It should be noted that the use of specific terminology when describing certain features or aspects of the invention should not be construed as implying a redefinition of that term to be limited to include any specific characteristic of the feature or aspect of the invention associated with that term.

[0213] A single unit or device can perform the functions of several items recited in the claims. Although specific measures are recited in different dependent claims, this does not imply that combinations of these measures cannot be used advantageously.

[0214] The described operations (such as) Figure 4 and 5 The operations indicated herein may be implemented as program code modules of a computer program and / or as dedicated hardware for debugging or lighting equipment. The computer program may be stored and / or distributed on suitable media, such as optical storage media or solid-state media supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunications systems.

Claims

1. An apparatus for scheduling communication resources of at least one communication device (10-1 to 10-3, 12-1, 12-2) in a wireless network, wherein, The device includes: A capacity detector (22) is configured to detect buffer capacity information signaled from the wireless network and indicating the available or maximum buffer capacity of at least one relay communication device (12-1, 12-2); and A scheduler (24) is configured to schedule communication resources for at least one of the following based on received buffer capacity information: transmitting upstream or downstream data of the target communication device (10-3) on a device-to-device communication channel between the target communication device (10-3) and the at least one relay communication device (12-1, 12-2), and transmitting upstream or downstream data of the at least one relay communication device (12-1, 12-2) on a device-to-device communication channel between the at least one relay communication device (12-1, 12-2) and another relay communication device (12-1, 12-2) or on a direct radio access link between the at least one relay communication device (12-1) and the access device (20), wherein the scheduler (24) is configured to determine, based on received buffer capacity information, to add and / or remove at least one parent relay communication device for one of the relay or remote communication devices in the wireless network.

2. The apparatus according to claim 1, wherein, The scheduler (24) is configured to perform cache capacity control by at least one of the following: instructing relay communication devices (12-1, 12-2) to increase or decrease the cache capacity for a specific logical channel or logical channel group, or a specific downstream relay or remote communication device; switching the relay communication devices (12-1, 12-2) between an autonomous mode of cache allocation and a directional mode of cache allocation; setting the cache allocation policy at the relay communication devices (12-1, 12-2); setting the reporting granularity of the relay communication devices (12-1, 12-2); and instructing the relay communication devices (12-1, 12-2) to merge multiple individual caches into a single cache allocation.

3. An apparatus for controlling the scheduling of communication resources of at least one communication device (10-1 to 10-3, 12-1, 12-2) in a wireless network, wherein, The device includes: A capacity detector (32) is configured to determine the available or maximum buffer capacity of the data buffer (34) at the relay communication devices (12-1, 12-2); and A capacity reporter (33) is configured to report cache capacity information, including the determined available or maximum cache capacity, to the wireless network in response to a triggering event, wherein the capacity reporter (33) is configured to send the cache capacity information to a network function, which forwards the cache capacity information to a scheduling access device (20) of the wireless network. The scheduling access device includes a scheduler (24) configured to determine, based on received buffer capacity information, to add and / or remove at least one parent relay communication device for one of the relay or remote communication devices in the wireless network.

4. The apparatus according to claim 3, wherein, The capacity reporter (33) is configured to report the cache capacity information in an absolute or relative format.

5. The apparatus according to claim 3, wherein, The capacity reporter (33) is configured to report cache capacity information for at least one of the following: different logical channels existing for at least one upstream link and / or at least one downstream link of the relay communication device (12-1), different priority levels of cached data existing in the relay communication device (12-1), and different downstream communication devices (12-2, 10-2, 10-3) existing for the relay communication device (12-1), or is configured to combine cache capacity reports of one or more downstream communication devices (12-2, 10-2, 10-3) with its own cache capacity report.

6. The apparatus according to claim 5, wherein, The capacity reporter (33) is configured to report a binary payload in which multiple elements are cascaded, each element corresponding to a buffer capacity report for a logical channel of the relay communication device (12-1), or to include its own buffer capacity report and / or the buffer capacity report of the sidelink-connected communication device (12-2) into a combined buffer capacity report, or to summarize buffer capacity information into a more concise buffer capacity report, or to report pairs of logical channels or logical channel groups and associated buffer capacity reports, or to report pairs of data priority levels and associated buffer capacity reports, or to select more relevant or more urgent buffer capacity reports for priority reporting, or to combine at least one buffer capacity report and at least one buffer size report into a single report.

7. The apparatus according to claim 3, wherein, The capacity reporter (33) is configured to include information relating to at least one of the following in the cache capacity report or to encode the cache capacity report by using at least one of the following: a cache capacity index of a lookup table; Cache load percentage; a mapping of reported cache capacity to capacity categories; a flag indicating whether a cache capacity threshold has been reached or exceeded; a composite value indicating the resource usage of the relay communication device, wherein the value is determined at least in part by its current or past cache capacity; a composite value indicating the relay communication device's preference or ability to accept additional remote communication devices, wherein the value is determined at least in part by its current or past cache capacity, including metadata about the cache and including specific requests triggered by cache-related conditions.

8. The apparatus according to claim 3, wherein, The capacity reporter (33) is configured to include information relating to at least one of the following in the cache capacity report or to encode the cache capacity report by using at least one of the following: an index of a cache load lookup table; the current cache load percentage; past cache load; a mapping of the reported cache load to a load category; a flag indicating whether a cache load threshold has been reached or exceeded; a composite value indicating the resource usage of the relay communication device, wherein the value is determined at least in part by its current or past cache load; or a composite value indicating the preference or capability of the relay communication device to accept additional remote communication devices, wherein the value is determined at least in part by its current or past cache load.

9. The apparatus according to claim 3, wherein, The capacity reporter (33) is configured to report the cache capacity information by using at least one or a combination of the following: a transport protocol over Internet Protocol, a message of Radio Resource Control Protocol, a packet data unit of Packet Data Convergence Protocol, a control element of Media Access Control Protocol, a service data unit of Media Access Control Protocol, and a data format of uplink control information or sidelink control information.

10. The apparatus according to claim 3, wherein, The triggering event corresponds to at least one of the following: the maximum cache capacity on the relay communication device (12-1, 12-2) is changed to a lower capacity, the available cache capacity of the data cache is changed, a timer-based trigger, the load of the data cache increases by a predetermined percentage, a fraction or data size relative to previously reported cache capacity information, a cache capacity query received from the scheduling access device or the upstream relay communication device, a cache capacity change on the remote communication device (10-2, 10-3), a cache size or capacity report received from the downstream remote or relay communication device, a cache status message or scheduling request message received from the downstream remote or relay communication device, a communication resource request message received from the downstream or relay communication device, a discovery or status request message received from the downstream device or a communication device outside the coverage area, a request received from the access device (20), and a recommended bit rate message or recommended bit rate query message received from the downstream remote or relay communication device.

11. An access device (20) for a wireless network, comprising the apparatus according to claim 1 or 2.

12. A relay communication device (12-1, 12-2) for a wireless network, comprising the means according to any one of claims 3 to 10.

13. A method for scheduling communication resources of at least one communication device (10-1 to 10-2, 12-1, 12-2) in a wireless network, wherein, The method includes: Detect (S401) buffer capacity information, which is signaled from the wireless network and indicates the available buffer capacity of at least one relay communication device (12-1, 12-2); and Based on the detected buffer capacity information, schedule (S403) at least one of the following: transmit upstream or downstream data of the target communication device (10-3) on a device-to-device communication channel between the target communication device (10-3) and the at least one relay communication device (12-1, 12-2), and transmit upstream or downstream data of the at least one relay communication device (12-1, 12-2) on a device-to-device communication channel between the at least one relay communication device (12-1, 12-2) and another relay communication device (12-1, 12-2) or on a direct radio access link between the at least one relay communication device (12-1, 12-2) and the access device (20). The method further includes determining, based on the received cache capacity information, to add and / or remove at least one parent relay communication device for one of the relay or remote communication devices in the wireless network.

14. A method for scheduling communication resources of at least one communication device (10-1 to 10-3, 12-1, 12-2) in a wireless network, wherein, The method includes: Determine (S501) the available or maximum buffer capacity of the data buffer (34) at the relay communication equipment (12-1, 12-2); In response to a triggering event, the available or maximum buffer capacity determined is reported to the wireless network (S504); The cache capacity information is sent to the network function, which then forwards the cache capacity information to the scheduling access device (20) of the wireless network; and Based on the received cache capacity information, a decision is made to add and / or remove at least one parent relay communication device for one of the relay or remote communication devices in the wireless network.

15. A computer program product including a code module, said code module being configured to produce the steps of claim 13 or 14 when run on a computer device.

Images