Enhanced scheduling in wireless networks using relay functionality

Abstract

In cellular or other wireless networks, relay terminal devices are introduced to support indirect network connectivity to remote terminal devices located in out-of-coverage areas, thereby improving network coverage. Such relay terminal devices buffer upstream and downstream data with other indirectly connected terminal devices, but these devices have limited memory allocation for buffering. This limitation significantly impacts the optimal resource scheduling performed by network access devices. [Solution] To enable optimal resource scheduling by access devices, relay terminal devices are instructed to report information about their available or maximum buffer capacity to each of their network access devices.

Description

Technical Field

[0001] The present invention relates to resource scheduling in a wireless network using a relay function, such as a cellular network, for indirect network connection to a remote communication device outside network coverage (for example, a terminal device such as a user equipment (UE)), without limitation.

Background Art

[0002] Many wireless communication systems use a network access device (for example, a base station, a Node B (eNB, eNodeB, gNB, gNodeB, ng-eNB, etc.), an access point, etc.) so that a wireless communication device (for example, a terminal device such as a mobile station or a UE) can communicate with an access device that serves a specific geographical service area where the terminal device is located. The access device is connected within the network and enables the creation of a communication link between the wireless communication device and other devices. In some situations, the communication link exists between wireless communication devices that are close to each other. In such a situation, it is desirable to have a direct communication link between the two wireless communication devices rather than communicating through the access device. Such direct communication between communication devices is often referred to as device-to-device (D2D) communication or peer-to-peer (P2P) communication. The communication resources (for example, time-frequency blocks) used for D2D or P2P communication may be a subset of the communication resources used by the communication system for communication between the wireless communication device and the access device, or may be a different set of communication resources (for example, an unlicensed band or a millimeter wave band).

[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 (for example, because they are non-public network (NPN) access devices).

[0004] Service requirements for wireless communication systems consider D2D in various ways. The first approach is to use direct device-to-device connections without any intermediary network entities. The second approach is to place a relay communication device between two remote devices. The third approach is to place a relay communication device between the remote communication device and the network. This is called an indirect network connection mode. The relay communication device can use multiple access schemes, such as 5G New Radio (NR) radio access technology, Long Term Evolution (LTE), WiFi, or fixed broadband.

[0005] Radio frequency resources are seen as expensive utilities, and their management poses a significant challenge to the evolution of cellular networks. Furthermore, data traffic in modern cellular networks, with its stringent latency and reliability requirements, necessitates efficient resource allocation schemes to ensure success.

[0006] In a radio access network (RAN), to achieve maximum spectral resource utilization, access devices should schedule transmission resources for all communication devices. In RANs supporting indirect network connectivity, this includes scheduling for all indirectly connected remote or relay communication devices.

[0007] Therefore, scheduling should be extended to function for directly and indirectly connected communication devices, including those connected indirectly through two or more relay communication devices ("multi-hop"). In addition, scheduling solutions should consider that the available buffer memory space of relay communication devices is limited for buffering data for the relayed data flow. Therefore, access devices must perform scheduling in a manner that avoids buffer overflows and the resulting data loss. Furthermore, scheduling solutions should consider that the buffer memory available in a relay communication device for buffering data for a particular upstream parent communication device or downstream child communication device varies depending on the device type (e.g., a low-cost Internet of Things (IoT) node vs. a high-power mobile phone) and over time (for example, if a relay communication device has only one child telecommunication device at a given time, this child device has much more buffer memory available than if 15 downstream communication devices were allocated to it). [Overview of the Initiative] [Problems that the invention aims to solve]

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

[0009] This objective is achieved by devices as claimed in claims 1 and 4, by access devices as claimed in claim 12, by communication devices as claimed in claim 13, by methods as claimed in claims 14 and 15, and by computer programs as claimed in claim 16.

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

[0011] As described above, the apparatus of the first aspect of the present invention also includes a telecommunications device. This is possible, for example, when the telecommunications device operates in a resource self-scheduling mode. In such a mode, the telecommunications device selects resources that it can use from a pool of resources available to, for example, one or more telecommunications devices. For example, this is when the telecommunications UE implements sidelink scheduling mode 2. In such a case, the target communication device corresponds to the telecommunications device itself. As described above, the apparatus of the first aspect of the present invention also includes a relay communication device. This is possible, for example, when the relay communication device operates in a resource self-scheduling mode. In such a mode, the relay communication device selects resources that it can use from a pool of resources available to, for example, one or more relay communication devices. This is when the relay UE implements sidelink scheduling mode 2, for example, since the relay UE is outside the coverage of the access device. In such a 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 (for example, in a communication device), the apparatus comprising: a capacity detector configured to determine the available or maximum buffer capacity of a data buffer in a relay communication device; and a capacity reporter for reporting buffer capacity information, including the determined available or maximum buffer capacity, to the wireless network in response to a trigger event.

[0013] According to a third aspect, an access device is provided that includes the apparatus of the first aspect.

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

[0015] According to a fifth aspect, a method is provided for scheduling communication resources for at least one communication device in a wireless network, the method comprising: detecting buffer capacity information indicating the available or maximum buffer capacity of at least one relay communication device, which is signaled from the wireless network; and scheduling at least one of the following based on the received buffer capacity information: upstream or downstream data transmission for the target communication device on a device-to-device communication channel between the target communication device and at least one relay communication device, and upstream or downstream data transmission for at least one relay communication device on a device-to-device communication channel between at least one relay communication device and another relay communication device, or on a direct wireless access link between 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, the method comprising the steps of determining the available or maximum buffer capacity of a data buffer in a relay communication device, and reporting the determined available or maximum buffer capacity to the wireless network in response to a trigger event.

[0017] Finally, according to the seventh aspect, a computer program is provided which, when executed on a computer device, includes coding means for producing the steps of the method described above according to the fifth or sixth aspect.

[0018] Therefore, in an access device, the scheduler receives the required buffer capacity information from directly connected and indirectly connected remote and / or relay communication devices, thereby enabling optimal scheduling of communication resources to directly connected and / or indirectly connected remote or relay communication devices, and avoiding buffer overflow, congestion, and data loss at relay communication devices. Thus, communication resources are scheduled to indirectly connected remote or relay communication devices. In this way, the access device also considers the indirectly connected communication devices and their available buffer capacity when scheduling communication resources.

[0019] According to the first option, combined with any of the first to seventh embodiments described above, scheduling is adapted to make a decision, based on received buffer capacity information, to add an additional parent relay communication device to one of the relay or telecommunication devices in the wireless network, and / or remove an existing parent relay communication device. This also includes cases where one parent relay communication device is replaced with another relay communication device. This makes it possible to schedule additional relay data buffer capacity and additional communication resources to increase data throughput for a particular data flow to or from the relay or telecommunication devices. For example, following the decision, an instruction message is sent to one or both of the relay or telecommunication devices and to the additional parent relay communication device. Optionally, one new parent relay communication device may be added, and at the same time, the existing parent relay communication device ceases to function as a parent relay for that particular relay or telecommunication device. Alternatively, the instruction message may be provided indirectly via the core network. After being received, the instruction message triggers the addition of the additional upstream relay communication device.

[0020] According to the first option or the second option combined with any of the first to seventh embodiments described above, scheduling is adapted to implement buffer capacity control by at least one of the following: commanding a relay communication device to increase or decrease the buffer capacity for a specific logical channel or logical channel group, or for a specific downstream relay or telecommunication device; switching a relay communication device between an autonomous mode for buffer allocation and an instruction mode for buffer allocation; setting a buffer allocation policy on a relay communication device; setting the reporting granularity of a relay communication device; and commanding a relay communication device to merge multiple separate buffers into a single buffer allocation. These alternative or cumulative buffer capacity control options enable effective, flexible, and high-speed resource scheduling in wireless networks using directly and indirectly connected communication devices.

[0021] According to the first or second option, or a third option combined with any of the first to seventh embodiments described above, buffer capacity reporting is adapted to send buffer capacity information to a network function that transfers buffer capacity information to a scheduling access device of the wireless network. This means offers the advantage that buffer capacity information does not need to be reported directly to the access device and can be transferred to other network functions to enable the flexibility of enhanced reporting.

[0022] According to any of the first to third options, or a fourth option combined with any of the first to seventh aspects described above, buffer capacity information is reported in an absolute or relative format. This makes it possible to adapt the reported buffer capacity information to the selected format or to the individual requirements of the channel used to transfer the buffer capacity information.

[0023] According to any of the first to fourth options, or a fifth option combined with any of the first to seventh aspects described above, buffer capacity reporting can be combined by reporting buffer capacity information for different logical channels present for at least one upstream link and / or at least one downstream link of a relay communication device, different priority classes of buffer data present in the relay communication device, and at least one of different downstream communication devices present for the relay communication device, or by combining the buffer capacity reports of one or more downstream relay communication devices with its own buffer capacity report. Such combinations of reported buffer capacity information from different sources result in improved reporting efficiency and speed, as well as improved resource scheduling.

[0024] According to any of the first to fifth options, or a sixth option combined with any of the first to seventh aspects described above, buffer capacity information can be combined by reporting a binary payload consisting of multiple concatenated elements, where each element corresponds to the buffer capacity report of one logical channel of a relay communication device; including its own buffer capacity report and / or the buffer capacity reports of side-link connected communication devices in a combined buffer capacity report; summarizing the buffer capacity information into a more compressed buffer capacity report; reporting pairs of logical channels or logical channel groups with associated buffer capacity reports; reporting pairs of data priority classes with associated buffer capacity reports; selecting more relevant or urgent buffer capacity reports for priority reporting; or combining at least one buffer capacity report and at least one buffer size report into a single report. Such combinations of reported capacity and / or size information from different sources result in improved reporting efficiency and speed, as well as improved resource scheduling. A specific example of a buffer size report is the 3GPP® BSR MAC CE, as described below.

[0025] According to any one of the first to sixth options, or a seventh option combined with any one of the first to seventh aspects described above, the buffer capacity report may use a buffer capacity index for a look-up table, use the current buffer load rate, map to a capacity category of the reported buffer capacity, use a flag indicating whether a buffer capacity threshold has been reached or exceeded, use a composite value indicating the resource utilization rate of a relay communication device, where the composite value is at least partially determined by the current buffer capacity of the relay communication device, use a composite value indicating the settings or functions of the relay communication device for accepting additional remote communication devices, where the value is partially determined by the current buffer capacity of the relay communication device, include meta-information about the buffer, and include specific requests triggered by buffer-related conditions. It is possible to encode by at least one of these. Such a coding method provides the advantage that the reporting load is minimized by adapting it to individual resource scheduling requirements.

[0026] Note that the proposed composite value enables reporting of relay communication device load (e.g., current resource utilization rate or ability to accept other remote communication device connections) along with an indication of buffer capacity. Thus, this enables the scheduler to make the most appropriate decisions in scheduling.

[0027] As an alternative to, or in combination with, the seventh option, information about buffer load can be reported. For example, it is proposed that the capacity reporter include information related to the buffer capacity report within the buffer capacity report, or encode the buffer capacity report, by including at least one of the following: an index for a buffer load lookup table, the current buffer load percentage, past buffer load, mapping of reported buffer loads to load categories, a flag indicating whether a buffer load threshold has been reached or exceeded, a composite value indicating the resource utilization of a relay communication device, the composite value being determined at least partially by its current or past buffer load, or a composite value indicating the relay communication device's preference or ability to accept additional telecommunication devices, the composite value being determined at least partially by its current or past buffer load.

[0028] According to any of the first to seventh options, or an eighth option combined with any of the first to seventh aspects described above, buffer capacity reporting is achieved by using at least one or a combination thereof of the following data formats: the Internet Protocol's higher-level transport protocol, the Radio Resource Control Protocol's messages, the Packet Data Convergence Protocol's packet data units, the Media Access Control (MAC) protocol's control elements, the MAC protocol's service data units, and the uplink control information or sidelink control information. The use of service data units covers cases where the buffer capacity report is transported within the MAC payload rather than as a control element. These different transmission options enable flexible implementation of the proposed scheduling and reporting solution.

[0029] According to any one of the first to eighth options, or the ninth option combined with any one of the first to seventh aspects described above, the trigger event is a change to a low capacity of the maximum buffer capacity on the relay communication device, a change in the available buffer capacity of the data buffer, a timer-based trigger, an increase in the load of the data buffer due to a predetermined ratio, rate, or data size with respect to the previously reported buffer capacity information, receipt of a buffer capacity query from an access device on the scheduling side or an upstream relay communication device, a change in the buffer capacity on the remote communication device, receipt of a buffer size or capacity report from a downstream remote or relay communication device, receipt of a buffer status message or a scheduling request message from a downstream remote or relay communication device, receipt of a communication resource request message from a downstream remote or relay communication device, receipt of a discovery or status request message from a downstream device or a communication device outside the coverage area, receipt of a request from an access device, and receipt of a recommended bit rate message or a recommended bit rate query message from a downstream remote or relay communication device. At least one of these trigger options enables a fast and efficient responsiveness of the proposed scheduling and reporting solution to changes in the buffer capacity state and / or the radio channel state. Therefore, the threshold is determined as a ratio or percentage of the buffer capacity used (also referred to as "buffer load") or as the absolute size of the buffer data. An example of a scheduling request message is the scheduling request (SR) bit sent within the sidelink control information (SCI). Another example is the resource request within the radio resource control (RRC) message.

[0030] It should be noted that the above-mentioned devices are implemented based on a discrete hardware network including an arrangement of discrete hardware components, integrated chips, or chip modules, or on signal processing devices or chips controlled by software routines or programs stored in memory, written to computer-readable media, or downloaded from a network such as the Internet.

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

[0032] It should be understood that preferred embodiments of the present invention may also be any combination of the dependent claims or embodiments described above with the individual independent claims.

[0033] These and other aspects of the present invention will be evident from the embodiments described below and will become apparent with reference thereto. [Brief explanation of the drawing]

[0034] [Figure 1] This is a schematic diagram of a network architecture with a buffer overflow problem in a relay communication device. [Figure 2] This is a schematic block diagram of an access device in various embodiments. [Figure 3] This is a schematic block diagram of a communication device in various embodiments. [Figure 4] This is a schematic flowchart of the scheduling procedure in various embodiments. [Figure 5] This is a schematic flowchart of the buffer capacity reporting procedure using various embodiments. [Figure 6]This is a schematic diagram of a network architecture in which buffer capacity information is collected via a relay communication device, according to various embodiments. [Figure 7] This is a schematic diagram of a network architecture in which scheduling information is distributed via relay communication devices, according to various embodiments. [Modes for carrying out the invention]

[0035] Next, embodiments of the present invention will be described based on resource scheduling for a 5G cellular network with UE-to-network relay functionality enabled, where 4G network elements are incorporated into the proposed 5G solution. Furthermore, at least some of the following embodiments will be described based on 5G New Radio (5G NR) radio access technology. Specifically, the relay functionality enables multi-hop indirect network connectivity for remote communication devices (e.g., UEs). This is done to improve coverage of communication devices, particularly for IoT communication devices, and to improve low-power operation.

[0036] Throughout this disclosure, the abbreviations “eNB (4G term)” and “gNB (5G term)” are intended to mean access devices such as cellular base stations or WiFi access points. eNB / gNB are part of the Radio Access Network (RAN) and provide interfaces to functions within the Core Network (CN). The RAN is part of the wireless communication network. The RAN implements Radio Access Technology (RAT). Conceptually, the RAN exists between communication devices such as mobile phones, computers, or any remotely controlled machines and provides connectivity to their CN. The CN is the central part of the communication network and provides many services to customers interconnected via the RAN. More specifically, the CN directs communication streams over the communication network and, potentially, other networks. 3GPP® specifications TS23.303 and TS24.334 for 4G networks define so-called proximity service (ProSe) functionality, which enables connectivity, in particular, for cellular communication devices (e.g., UEs) that are temporarily not within the coverage of an access device (eNB). This particular function is called ProSe UE-to-network relay, or relay UE. A relay UE is a communication device that helps another OoC UE communicate with an eNB (i.e., an access device) by relaying application and network data traffic bidirectionally between the OoC UE and the eNB. Local communication between the relay UE and the OoC UE is called D2D communication, sidelink communication, or PC5 communication. The abbreviation "PC5" represents an interface for sidelink communication as defined by ProSe. Furthermore, the abbreviation "UL" is used in the uplink direction from a communication device (e.g., UE) to an access device (e.g., eNB, gNB), the abbreviation "DL" is used in 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).

[0037] Once a relay relationship is established, the OoC-UE is connected via the relay UE and functions as a “remote UE.” This situation means that the remote UE has an indirect network connection to the CN, the opposite of a direct network connection in a typical case (see 3GPP® specification TS22.261v16.10.0). The abbreviation “upstream” is used for data destined for an access device or to indicate a communication device closer to the access device (in terms of hop count), while the term “downstream” is used in a RAN for data flows from an access device to a communication device destined for a communication device or to indicate a communication device further away from the access device (in terms of hop count). The prefix “parent” represents an upstream relay communication device used by a remote or relay communication device, and the prefix “child” represents a downstream relay communication device connected to a given relay communication device, or a downstream remote communication device directly using a particular relay communication device as its parent.

[0038] Current standardization efforts (e.g., 3GPP® specification TR22.866v17.1.0) extend 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 permits relay communication devices that provide a single hop to the network (access device) to enable remote communication devices to have indirect network connectivity to access devices (e.g., eNBs) and 4G CNs. In future 3GPP® releases after Release 16, the aim is to enable multi-hop relay for 5G systems, where relay UEs can connect to other relay UEs, etc.

[0039] The standardization step that will occur in the near future (initiated by 3GPP® specification TR23.752v0.3.0) is to integrate UE-based ProSe for relaying into 5G-based networks and specifications. It is expected that the 4G ProSe concept will be reused in 5G specifications as much as possible, in which case the 5G V2X architecture (see 3GPP® specification TS23.287v16.1.0) will serve as the starting point.

[0040] Furthermore, 3GPP® specifications TR23.733v15.1.0 and TR36.746v15.1.1 provide research into architectural enhancements that allow IoT devices (in the role of remote UEs) to operate at extremely low power by using relay UEs to connect to wide-area networks. Relay UEs are physically very close and therefore reachable using extremely low-power transmissions. This work also includes improvements to security, speed, and stability for ProSe. Such enhancements to ProSe are called Enhanced ProSe ("eProSe").

[0041] One of the improvements proposed in eProSe is an enhanced relay architecture operating at a second protocol layer (i.e., L2) intended to provide end-to-end transmission of Internet Protocol (IP) and Packet Data Convergence Protocol (PDCP) packets to remote communication devices regarding application and / or user data. The advantage of this architecture is that remote communication devices become directly visible as entities registered with the CN, which relates to improved control by access devices on communication devices for monitoring and billing purposes.

[0042] Because the characteristics of wireless communication devices vary greatly in terms of, for example, low-power operation, maximum allowable latency, achievable transmit power, achievable duty cycles in transmission and / or reception, and required bandwidth and mobility, wireless network systems such as 5G systems are designed with great flexibility in terms of how they can operate. The bandwidth available to a device for UL data, SL data, and DL data can change dynamically under the control of the access device, based on the data needs and the channel state at that time. To achieve this, a scheduler exists within the access device to schedule communication resources for UL / DL / SL transmissions of the communication device (e.g., as described in 3GPP® specification TS38.300) and to make (or help make) resource-related or relay topology-related decisions to the RAN, in order to optimize the quality of service for all communication devices served directly or indirectly by the access device. UL / DL control information is sent to the communication device in various ways to communicate scheduling decisions.

[0043] Resource scheduling is dynamic, meaning that communication resources are allocated on demand based on available data and channel status. Semi-persistent scheduling (SPS) is a preset schedule that can be quickly activated / deactivated by the access device (e.g., gNB) based on current demand. As a further option, persistent scheduling is applied, which, once activated, remains active until explicitly cleared by a specific designated event. The idea is that dynamic scheduling decisions can be added to persistent / semi-persistent scheduling decisions to address special events such as fluctuations in data rates or data retransmissions. A complex ensemble of reporting structures, along with control mechanisms for the access device (e.g., gNB) to enable / disable / request reports so that the scheduler can know about channel status, is defined in the 3GPP® specification for reporting measurements to the access device (e.g., gNB). Thus, these reports control the scheduling process. While most scheduling processes are directly controlled by the scheduler within the access device, the scheduling process for communication resources within a wireless network also depends on local decisions made by communication devices that are not under the direct control of the scheduler. For example, the selection of a relay communication device by a remote communication device or a relay communication device, the re-selection of a relay communication device by a remote communication device or a relay communication device, or the self-scheduling resource selection of a resource used by a remote communication device to transmit a message that is not within the direct coverage of the access device and / or is not currently scheduled by the access device (e.g., Mode 2 as defined in 3GPP® specification TS38.300 for sidelink communication). These local decisions successively influence and constrain the scheduling decisions that the scheduler within the access device can make. Simultaneously, the scheduler has means of directly or indirectly influencing these local decisions made by communication devices.As an example of direct impact, an access device directly issues commands or requests to a telecommunications device, re-selecting a specific other parent relay communication device to achieve better quality service for one or more communication devices in the RAN. As an example of indirect impact, an access device can configure additional sidelink (SL) resources as a resource pool, and a self-scheduling communication device can select specific resources from this resource pool to transmit over the SL by local decision. In other words, a telecommunications device runs its own scheduler to schedule communication resources and makes its own local decisions about which resources to use and when from a subset of predefined resources. These local decisions are based on various inputs, such as local measurements (e.g., signal or noise levels, reference signal received power, etc.), local received messages provided by the access device (e.g., SCI messages), configuration data (e.g., parameters given via RRC messages), or measurements / configuration data provided by peer communication devices. Thus, these inputs also control the scheduling process; in other words, these inputs are control inputs to the scheduling process, with only a portion of the inputs being under the control of the scheduler. As a further example, if a relay communication device reports its buffer capacity information to a remote communication device, and the remote communication device uses that information to select another relay communication device, the relay communication device efficiently controls the scheduling of communication resources by controlling the allocation of relays used by the remote communication device, and consequently the resources used by the remote communication device for its sidelink communications, and (indirectly) the resources provided by the selected relay communication device in the wireless network.

[0044] The element for implementing the scheduling mechanism is a radio resource control (RRC) protocol that can operate end-to-end to the UE, potentially over one or more hops, taking into account the aforementioned new relay architecture at the second protocol layer (i.e., L2). This element is used for non-time-critical, static or semi-static scheduling information; in other words, scheduling. Here, ConfiguredGrantConfig is the information element for uplink or sidelink scheduling.

[0045] Another element for implementing scheduling mechanisms is 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, used to efficiently signal specific events, measurements, or settings. A concrete example is the Buffer Status Report (BSR) MAC CE in 5G NR, used by communication devices (e.g., UEs) to signal their current data buffer size to the access device and / or its scheduler. Further MAC CEs are used by access devices (e.g., gNBs) to control the behavior of communication devices (e.g., UEs) when implementing various other 3GPP® mechanisms such as Channel State Information (CSI) reporting, Sounding Reference Signal (SRS), or Intermittent Reception (DRX).

[0046] A further element is the use of Downlink Control Information (DCI), which is a short message with special, blind-detectable modulation or encoding sent over a low-bitrate control channel (e.g., a Physical Downlink Control Channel (PDCCH)). This mechanism is implemented at the Physical Protocol Layer (PHY L1) and does not require the use of MAC L2 header structures. Here, various DCI formats are defined by various information content. Communication resources for dynamic scheduling are indicated in the DCI. DL data transmission follows the DCI message, for example, less than 1 ms later, but can be scheduled up to 4 ms ahead. In UL, scheduling is done for the next time slot 1-2 ms ahead, but can be up to 8 ms ahead.

[0047] A further element is the use of uplink or sidelink control information (UCI, SCI). This includes scheduling request (SR) bits, which are used when there are no available communication resources to send, for example, a BSR MAC CE or other types of buffer status reports. In response to an SR, the scheduler of the access device (e.g., gNB) allocates uplink communication resources for a future communication device (e.g., UE).

[0048] A further element is the use of SL / PC5 discovery messages. Such messages are used to discover peer relay communication devices for OoC communication devices, to discover 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 information thus obtained from discovery messages is then used by remote or relay communication devices to make local decisions that affect the scheduling of communication resources. For example, if a remote communication device uses mode 2 resource allocation, it will schedule its sidelink resources differently according to the selected or reselected relay device. Also, if a scheduler in an access device is involved in resource allocation for remote and / or relay communication devices, and a better parent relay communication device is selected by such device as a result of the relay reselection process, from that point onward, the scheduler in the access device will be able to schedule its resources more efficiently overall for all devices scheduled within its RAN. The transmitted discovery messages are either Model A (i.e., Announce) messages that are sent periodically and therefore triggered by a timer, or Model B (i.e., Discovery Response) messages that are triggered by Model B discovery query messages received from peer communication devices (for example, based on Model A and Model B as specified in TS23.303).

[0049] The resource scheduling outline described above is applicable to communication devices (e.g., UEs) and can also be used for multi-hop solutions. Therefore, depending on the various embodiments, new network elements may need to be added or existing elements may need to be extended, as described below. When single-hop or multi-hop relay communication devices are introduced into the network, existing solutions are insufficient because they work for direct links between access devices (e.g., gNBs) and communication devices (e.g., UEs), but do not necessarily work for indirect links between access devices and communication devices via relays.

[0050] In a single-hop relay scenario, an OoC (Out of Control) telecommunications device (e.g., a remote UE) can self-schedule transmissions on its SL (Service Level) connection based on its channel measurements and random access process, or an access device (e.g., a gNB) can schedule all communication resources to all directly connected and indirectly connected communication devices (e.g., UEs). Alternatively, one critical communication device (e.g., a UE) within a group of communication devices can coordinate resource allocation to its group members, which can function even if some group members become OoC, as long as the coverage of the critical group members remains.

[0051] It should be noted that if the communication resources required by indirectly connected communication devices can be scheduled by the access device (e.g., gNB), the risk of transmission collisions and / or unfair spectrum use is reduced, and the efficiency of spectrum use is increased.

[0052] Regarding BSR MAC CE, the 3GPP® specification TS38.331v15.5.1 defines four different formats. A BSR includes an identifier for a Logical Channel Group (LCG), which is a group of logical channels with associated buffers to which a buffer size report applies. More specifically, the buffer size report includes a buffer size field (e.g., 5 or 8 bits long) whose bit value is interpreted based on a predetermined lookup table. A shorter format is used to report a single LCG, while a longer format is used to report, for example, 1 to 8 LCGs.

[0053] BSR MAC CEs are used as described above, while SL BSR MAC CEs are used specifically for reporting sidelink buffer status. Both types of BSRs have different formats depending on the number N of LCGs being reported, for example, whether N is odd or even, and whether the BSR is truncated. The BSR format includes a "destination index" which encodes an index (e.g., 4 bits) into a list containing the destination address of the data. This is a unicast destination or a group destination (e.g., multicast D2D / V2X-D2D).

[0054] In IP networks, an explicit congestion notification (ECN) mechanism is used by intermediate routers to signal that congestion is occurring at that router (see IETF specification RFC3168 for details). Congestion occurs, for example, when an IP source transmits at too high a speed or when the transmission link has insufficient capacity. In both cases, it has the effect of filling or nearly filling the buffers on the router. Therefore, a full router buffer can be used as a trigger to send an ECN mark along with the data packet to the final destination. The final destination then signals to the source that congestion is occurring using a protocol acknowledgment (e.g., Transmit Control Protocol (TCP)). The source then uses this information to reduce the data rate of its transmission. ECN is applicable to cellular 4G / 5G networks (see 3GPP® specification TS36.300v15.2.0, section 11.6 for 4G networks and TS38.300v15.5.0, section 12.2 for 5G networks). An access device (e.g., a gNB) itself (e.g., acting as an intermediate router for IP packets to / from a communication device (e.g., a UE)) can set the ECN bit in the IP packet header to indicate congestion if it exists. This informs the IP data source that it needs to reduce its data rate according to the ECN protocol.

[0055] In the following embodiments, the term “buffer” is related to the buffering of data transmitted over a communication link in a communication network; the term “buffer size” is intended to express how much data is actually stored in the buffer at a given moment, or calculated as a function (e.g., average) over a specific period; the term “buffer capacity” is intended to express how much data can be stored in the buffer at a given moment (e.g., additionally or in total), or can be calculated as a function (e.g., average) over a specific period; and the term “buffer load” is intended to express the ratio or proportion of buffer capacity used at a given moment or averaged over a specific period.

[0056] More specifically, a buffer status information message is a message that contains all kinds of buffer status information. Buffer status information includes buffer size information (e.g., a buffer status report (BSR) or sidelink buffer status report (SL-BSR) as defined in the relevant 3GPP® specifications) and buffer capacity information. A typical buffer status report (BSR) or sidelink buffer status report (SL-BSR) as defined in the relevant 3GPP® specifications contains only information about the current buffer size. Especially in relay scenarios, it is beneficial for better resource scheduling if other buffer-related information, such as buffer capacity, is also reported or managed by the access device or core network. Therefore, it is proposed to either use a separate message or extend an existing message (buffer status report message) with buffer capacity-related information, i.e., a so-called buffer capacity report or buffer capacity information. The buffer capacity report includes information on the available buffer capacity (relative or absolute), maximum buffer capacity or buffer limit (absolute), average used buffer capacity or buffer load (e.g., ratio of used maximum buffer capacity) and metadata (e.g., stable bits) averaged over the reporting time or historical period, as well as any other buffer-related status information (e.g., LCID, LCG, UE-ID, buffer ID, buffer capacity alerts, etc.).

[0057] Furthermore, a report is understood to consist of zero or more included reports (received from other devices) with zero or more information items added, in which case the information items are generated internally or received from another device in another received report. Various embodiments provide the concept of combining multiple buffer capacity reports into a single message (e.g., reports from different nodes, or reports from different logical channels, logical channel groups, or routes), as well as the concept of scheduling communication resources of relay communication devices and telecommunication devices to quickly resolve congestion, thereby resolving or preventing buffer overflows in relay communication devices.

[0058] As described above, a relay communication device (e.g., a relay UE) receives and collects one or more buffer capacity reports from child remote communication devices and sends them to an access device (e.g., an eNB or gNB) in a combined form, where the buffer capacity reports are sometimes integrated into a single buffer size report. Note that buffer capacity reports can be combined with other buffer capacity reports and / or other buffer size reports (e.g., obtained from a BSR MAC CE). This combined form of buffer capacity and buffer size reports is then called a buffer status information report.

[0059] In various embodiments, it is further proposed that the access device schedule transmission resources for all communication devices to obtain the most efficient spectral resource utilization. This schedules remote or relay communication devices for any indirect connection to support indirect network connections, so as not to cause buffer overflows that result in data loss.

[0060] Various embodiments provide solutions for optimal scheduling by access devices with minimal data loss in intermediate relay communication devices. The solution involves the efficient collection of necessary information by the access device from communication devices (e.g., within a RAN), including, for example, communication device buffer size reports, buffer capacity reports, scheduling requests, locally available buffer size information, or locally available buffer capacity information, and scheduling decisions can be made based on this information.

[0061] Figure 1 is a schematic diagram of a network architecture with a buffer overflow problem in a relay communication device.

[0062] In the scenario shown in Figure 1, the first communication device (e.g., UE1) 12-1 and the second communication device (e.g., UE2) 12-2 function as relay communication devices, and the second communication device 12-2, as well as the third and fourth communication devices (e.g., UE3, UE4) 10-2, 10-3 themselves, depend on the parent relay communication device to establish their own indirect network connectivity to the access device (e.g., gNB) 20 and the core network 100. The core network 100 includes 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.

[0063] As indicated by the thick arrow as the first event E1, the second communication device 12-2, which has relay capabilities, receives a sudden and large upstream data volume from the remote fourth communication device 10-3 via the SL connection. This large upstream data volume is triggered by the application server (app) 120 connected to the core network 100 and quickly fills the buffer allocated by the second communication device 12-2 for the upstream data of the fourth communication device 10-3.

[0064] Therefore, as indicated by the second event E2, the second communication device 12-2 does not receive sufficient upstream communication resource allocation to offload buffer data (for transmission to the first communication device 12-1). The reason for this situation is that, either due to insufficient available communication resources caused by a temporary deterioration in the wireless channel condition, or because the access device 20 was unaware that the second communication device 12-2 had limited buffer capacity available for buffering data (for example, the second communication device is allocated only 128KB but has a buffer capacity of 16MB), the access device 20 did not allocate sufficient upstream communication resources for relaying data between the first communication device 12-1 and the second communication device 12-2, or the fourth communication device 10-3 used self-scheduling (i.e., not scheduled by the access device 20) SL communication to send data to the second communication device 12-2, and as a result, the access device 20 was unable to control the amount of data sent to the second communication device 12-2, as indicated by the third event E3.

[0065] For example, in 4G / 5G ProSe and 3GPP® V2X D2D communication, the latter case of self-scheduling SL communication is explicitly permitted for pre-authorized OoC communication devices that are not directly connected to the access device (e.g., gNB). In this case, the sender uses pre-configured or pre-announced frequency resource pools and performs self-scheduling within these pools.

[0066] The buffer filling up at the second communication device 12-2 will eventually lead to buffer saturation (regardless of whether the fourth communication device 10-3 uses self-scheduled resource allocation or whether its allocated communication resources are scheduled by the access device 20), and consequently to potential packet drops at the relay-type second communication device 12-2. For example, if a PDCP acknowledgment is not received from the access device 20 (in the L2 relay architecture) or from the relay communication device 12-2 (in the case of another relay architecture where the PDCP acknowledgment is given in only one radio hop), retransmission from the fourth communication device 10-3 will follow.

[0067] In the case where the fourth communication device 10-3 is scheduled by its parent device (i.e., the second communication device 12-2) instead of the access device 20, the second communication device 12-2 can prevent buffer saturation by scheduling less communication resources to the fourth communication device 10-3. However, this may result in important data not being sent to the network in time, or less data flowing to the network than the fourth communication device 10-3 needs.

[0068] The ECN mechanism implemented in 4G / 5G networks does not solve this problem. Since the second communication device 12-2 is a node experiencing congestion, this device should be a node that marks IP packets as "congested" using the ECN bit in the IP header. However, the second communication device 12-2 may relay PDCP packets (depending on the relay solution) without necessarily being aware of or accessing the unencrypted content of the PDCP service data unit (SDU) containing IP packets from the remote fourth communication device 10-3, so the second communication device 12-2 does not necessarily see the IP packets being relayed. Furthermore, the 4G / 5G ECN mechanism is not designed for fine-grained resource control of short bursts of data transmission and / or time-critical or energy-critical communications for IoT devices via relay devices, but rather for coarse-grained rate selection and rate adaptation of voice / video codecs, such as for Multimedia Telephony Service video sessions for mobile phones directly connected to the core network through a set of base stations and network functions, such as Voice over LTE (VoLTE), IP Multimedia Subsystem (IMS), or the core network via a set of base stations and network functions.

[0069] Further complicating matters, the relay data buffer capacity allocated to the second communication device 12-2, which has relay functionality, changes dynamically with network changes. Such changes result from one or more new relay and / or remote communication devices connecting to the second communication device 12-2, or from one or more existing relay and / or remote communication devices (distant from the fourth communication device 10-3) beginning to transmit more data, thereby filling individual buffers more quickly, reducing the available buffer capacity allocated to the fourth communication device 10-3. Therefore, for example, if more remote communication devices are installed, the relay data buffer capacity per remote communication device decreases. Alternatively, if existing remote communication devices begin to transmit more data, the maximum buffer capacity remains the same, but the available buffer capacity decreases. In both cases, the access device 20 should be notified of the changes to improve overall scheduling.

[0070] Another complexity is that a relay communication device may not know which remote communication device is the source of a high data load, for example, if the source is two or more hops away from the relay communication device (e.g., via another relay communication device). This relates to cases where the relay communication device performs resource scheduling for its downstream relay and / or remote communication devices on behalf of the access device. In Figure 1, this situation occurs when the buffer of the first relay-type communication device 12-1 is nearly full and it does not know that the fourth communication device 10-3 is the responsible source. In this case, because the first communication device 12-1 does not know the source of this data, it is difficult for the first communication device 12-1 to directly signal, for example, to send less data to the source (e.g., the fourth communication device 10-3). The first communication device 12-1 can signal congestion to its downstream neighbor, the second communication device 12-2, which then signals to the fourth communication device 10-3. However, this ECN-like mechanism could result in some data from the fourth communication device 10-3 not being sent to the network on time. This mechanism does not adapt network scheduling for all upstream links beyond the fourth communication device 10-3.

[0071] Accordingly, according to various embodiments, it is proposed that, when triggered by an event, a relay-type first communication device 12-1, which is directly connected to the access device 20 and functions as a relay communication device for exchanging upstream / downstream data between the access device 20 and a remote communication device (e.g., a third communication device 10-2), provides the access device 20 with buffer capacity information regarding the available data buffer capacity present in the first communication device 12-1, and / or the available data buffer capacity present in a relay-type second communication device 12-2 and / or any further relay-type communication devices (if any). The given buffer capacity information can be formatted in an identifiable manner so that the access device 20 can associate the information item with the maximum capacity with the specific communication device that first reported this information item, and the scheduler of the access device 20 is configured to use the given buffer capacity information to schedule communication resources for transmitting upstream or downstream data for the first communication device 12-1, the second communication device 12-2, and / or any further relay-type communication devices.

[0072] However, it should be noted that the provision of buffer capacity information is not necessarily achieved solely within the RAN. Buffer capacity information may also be transferred indirectly to the access device 20. That is, a relay communication device (e.g., the first communication device 12-1) sends the buffer capacity information to the network function of the core network 100, which then returns it to the access device to provide the buffer capacity information. Alternatively, the buffer capacity information may be transferred to a downstream communication device, for example, a downstream remote communication device that uses the information to make application-level decisions for the relay re-selection process regarding which relay communication device to use in the future. Alternatively, the buffer capacity information may be transferred to an OoC communication device, for example, a communication device that has discovered status information about an expected relay communication device for the purpose of making decisions to be notified for the relay selection process regarding which relay communication to select for future indirect communication.

[0073] Buffer capacity information is transmitted in absolute form (e.g., "available capacity X bytes") or relative form (e.g., a percentage of available buffer capacity X%), on which the receiver optionally derives information about the absolute number of bytes that can be buffered. However, especially when an access device (or core network) manages one or more buffer capacities used by a relay communication device, when the access device (or core network) receives information about buffer capacity from the relay communication device as part of a preceding message, or when the percentage is relative to a pre-configured or known buffer capacity (e.g., pre-configured as part of a policy), or when it is expressed as an index to a table having values ​​for different buffer capacities and buffer load-related values, the knowledge that, for example, "the buffer is 80% full" is sufficient to trigger a mitigation action (i.e., affect scheduling) without necessarily knowing how many bytes of the buffer space this 80% represents.

[0074] In some alternative forms, a composite value is used to indicate the resource utilization of a relay communication device. This value is at least partially determined by the relay communication device's current and / or past buffer capacity, such as the current buffer load rate, the average buffer load rate over the most recent 2000ms time window, etc. In another example, the composite value indicates the relay communication device's preference or ability to accept additional telecommunication devices. The composite value is partially determined by the relay communication device's current buffer capacity, or by the average buffer capacity calculated over a period, or alternatively by the worst-case buffer capacity measured over a period. A specific example of the latter is the worst-case buffer load rate measured over the most recent 2000ms time window. The composite value can be encoded, for example, as an integer value within a given range (e.g., 0 to 3, or 0 to 100), or as a QoS identifier that identifies the quality of service achievable with the current relay load, such as a PQI or 5QI identifier.

[0075] Figure 2 is a schematic block diagram of an access device in various embodiments.

[0076] Note that Figure 2 shows only the blocks related to the proposed scheduling enhancement feature. Other blocks have been omitted for brevity.

[0077] The access device in Figure 2 corresponds to the access device (e.g., gNB) 20 in Figure 1, or any other type of access device for any wireless network with resource scheduling capabilities.

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

[0079] Furthermore, the access device includes a capacity information detector (CD) 22 that detects buffer capacity information included in a buffer capacity report received from a communication device (e.g., a relay UE) via, for example, a transceiver unit 21.

[0080] For example, based on capacity information obtained from a buffer capacity report, the scheduler 24 generates scheduling information for the relay communication device to be scheduled, and this information is transferred to the relay communication device via the transceiver unit 21.

[0081] This enables a scheduling enhancement process, which in turn takes into account the available buffer capacity of directly and indirectly connected relay communication devices.

[0082] Figure 3 is a schematic block diagram of a relay communication device (e.g., a relay UE) according to various embodiments.

[0083] Note that Figure 3 shows only the blocks related to the proposed scheduling enhancement feature. Other blocks have been omitted for brevity.

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

[0085] As shown in Figure 3, the relay communication device includes a transceiver unit (TRX) 31 for transmitting and receiving radio messages and / or other radio 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 detected available buffer capacity of its own relay data buffer (RDB) 34, and, if possible, derived buffer capacity information of the data buffers of connected and / or nearby relay communication devices.

[0086] Furthermore, the relay communication device includes a capacity information detector (CD) 32 that detects buffer capacity information contained in a buffer capacity report received from a connected and / or nearby communication device (e.g., a relay UE) via the transceiver unit 31.

[0087] Based on its own capacity information and capacity information obtained from buffer capacity reports of connected and / or nearby relay communication devices, the capacity information generator 33 generates a combined or enhanced buffer capacity report that includes buffer capacity information of the relay communication device and its neighbors and / or connected relay communication devices, and is forwarded to the access device or upstream relay communication device via the transceiver unit 31 in response to a trigger event described below. The forwarding is either direct or indirect (e.g., via multiple hops and / or via network functions). The upstream device combines the buffer capacity report with its own buffer capacity report and sends the combined report to the access device, or the upstream device removes buffer capacity information (e.g., creates a summary or selects a buffer capacity report).

[0088] This enables a scheduling enhancement process, which in turn takes into account the availability and / or associated buffer capacity of directly and indirectly connected relay communication devices.

[0089] Each block in the block diagrams of Figures 2 and 3 is executed by discrete hardware circuits such as application-specific integrated circuits (ASICs), programmable logic arrays (PLAs), field-programmable gate arrays (FPGAs), or by digital signal processors (DSPs) or other software-controlled processor circuits.

[0090] Figure 4 is a schematic flowchart of the scheduling procedure in various embodiments, which are implemented in access devices (e.g., gNB, eNB, base station, or access point) of cellular or other wireless networks.

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

[0092] Figure 5 is a schematic flowchart of the buffer status information reporting procedure according to various embodiments.

[0093] The reporting procedure is initiated by trigger events occurring in individual relay communication devices, as described below. In the first step S501, the relay communication device determines the available capacity of its own relay data buffer. The determined capacity is the capacity of a subset of the buffer, depending on the situation and / or the trigger event. Next, in step S502, the available buffer capacity of indirectly connected neighboring relay communication devices is determined and collected, for example, based on the received buffer capacity report. In step S503, combined buffer capacity information for its own relay data buffer and / or directly and / or indirectly connected relay communication devices is generated, for example, in the combined buffer capacity report. In some cases, not all buffer capacity information is included (for example, a relay communication device only includes buffer capacity information for itself and other indirectly connected relay communication devices). Furthermore, in step S503, there are cases where only its own relay data buffer capacity is reported, and information for any other neighboring devices is not reported. Such cases include, for example, when a relay communication device does not have child relay communication devices, or when a child relay communication device independently reports buffer capacity information to an access device (e.g., via RRC, PDCP, IP, etc.) and is not coupled by the relay communication device. A further case is when a relay communication device excludes its own buffer capacity information (even if it is determined) and only reports the buffer capacity information of, for example, an indirectly connected relay communication device.

[0094] Finally, in step S504, the determined and / or collected buffer capacity information is reported to the access device and / or upstream relay communication device. Therefore, the reported buffer capacity information includes at least one of the determined buffer capacity information from step S501 and the collected buffer capacity information from step S502.

[0095] Please note that, depending on the trigger event and / or circumstances, the combined buffer capacity information may exclude one or more of the following: its own relay data buffer, directly connected relay communication devices, or indirectly connected relay communication devices.

[0096] Note that the steps in the flowcharts of Figures 4 and 5 are performed based on one or more software routines used to control the processor or computing unit, respectively, which are provided within the access device or relay communication device.

[0097] When reported by relay communication devices, buffer capacity information is encoded in various ways. Enhanced buffer capacity reports include one or more items of maximum or available buffer capacity information per report.

[0098] As a first option, multiple items are reported for different logical channels present for the upstream and / or downstream links of the relay communication device, in which case the maximum or available buffer capacity is reported for each logical channel.

[0099] As a second option, multiple items are reported for different priority classes of buffer data present in the relay communication device, in which case the maximum or available buffer capacity is reported for each priority class.

[0100] As a third option, multiple items are reported for different downstream communication devices present in relation to the relay communication device, in which case the maximum or available buffer capacity is reported for each downstream communication device. A separate buffer is allocated within the relay communication device for each downstream communication device.

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

[0102] If a relay communication device reports two or more available capacity information items, it may still be constrained to report less information than all available capacity information items in a single buffer capacity report, for example, due to configuration settings from the access device (e.g., gNB) (e.g., instructing it to temporarily report only a subset) or due to size constraints (e.g., the current physical layer transport block does not have enough space to report less information than all available capacity information elements (e.g., individual maximum buffer capacity)). Other capacity information items will be reported later (e.g., in the next physical layer transport block).

[0103] Various embodiments provide an enhanced combined buffer capacity report format that includes multiple items from the same relay communication device. These are also combined with values ​​from other relay communication devices, as described later, within a single buffer capacity report.

[0104] As a first option, the relay communication device reports a binary payload consisting of N concatenated elements, where each element corresponds, for example, to one buffer capacity information for its logical channel, in ascending order of logical channel ID (LCID) number 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, the access device can reconstruct the matching LCID or LCG number for each element, thus providing a complete buffer capacity report with the advantage of efficient encoding, as it does not require encoding the LCID or LCG number.

[0105] As a second option, the relay communication device includes its buffer capacity report and / or SL buffer size report (e.g., SL BSR MAC CE) and / or UL buffer size report (e.g., BSR MAC CE) in the combined buffer status information report, along with buffer capacity information as specified by at least one of the other options.

[0106] As a third option, the relay communication device could summarize buffer capacity values ​​and exclude information reports for, for example, nearly empty buffers, for more efficient or compressed reporting to its upstream parent or access device (e.g., gNB). Alternatively, it could 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 detailed format (e.g., 8 bits) for more important or critical relay data buffers.

[0107] As a fourth option, the relay communication device reports pairs of LCID or LCG numbers with associated buffer capacity information.

[0108] As a fifth option, the relay communication device reports a pair of data priority class indicators and buffer capacity information.

[0109] As a sixth option, the relay communication device may select only the relevant buffer capacity information items for more efficient or prioritized reporting to its upstream parent or access device (for example, excluding buffer capacity information or reports for buffers that are nearly empty), or select buffer capacity reports for high buffer loads that require urgent action by the access device and its scheduler (others are excluded).

[0110] As a seventh option, the relay communication device reports pairs of a communication device identifier and buffer capacity information relating to buffer data to or from the identified (downstream) communication device. Alternatively, the relay communication device reports an ordered list of buffer capacity information elements, in which case each element reports buffer capacity information for one or more sets of buffers associated with only a single downstream communication device.

[0111] As already mentioned, the maximum or available buffer capacity is reported as either an absolute or relative value. Reporting the relative value along with information about the current buffer utilization (i.e., the current buffer size) has advantages, as it allows for inference of the maximum or available buffer capacity, thereby enabling the maximum or available buffer capacity to also change dynamically depending on the situation, without the need to re-report the absolute maximum or available buffer capacity value along with the buffer size report value. A compact reporting format is also preferred to limit signaling overhead.

[0112] According to various embodiments, within the enhanced buffer capacity report, information items are encoded as follows: 1. The n-bit category number refers to the maximum number of bytes of data that can be accessed via a table lookup, for example, by using a buffer capacity index (e.g., 8 bits long) to access the lookup table. These values ​​are pre-agreed upon by the standard. 2. An encoding of the current buffer load percentage (0-100%), for example, encoded as an 8-bit or 7-bit number encoding an integer percentage. This encoding is useful when the access device can correlate the encoding with buffer size information reports or previous reports from the same communication device in order to estimate the absolute value of the maximum buffer capacity at the communication device. 3. An encoding of the current buffer load percentage (0-100%) that approximates the actual percentage, which can be encoded as a 3.6-bit, 5-bit, 4-bit, 3-bit, or 2-bit number. This encoding is useful when the access device can combine this number with buffer capacity information reported or precedented from the same communication device. Optionally, the 2-bit encoding can be mapped to the categories <25%, <50%, <75%, and >90%. 4. A very compact 1-bit encoding (flag) that, when set to 1, indicates that the buffer usage threshold has been exceeded. The threshold is either a priori determined number, such as an 80% threshold, or a threshold agreed upon in the preceding (setup) communication between the reporting communication device and the access device (e.g., RRC protocol communication). Such thresholds are defined for the UE's maximum memory allocation, the maximum memory available to a sidelink buffer or uplink buffer, the maximum capacity of a particular buffer, or the (average) buffer load or current capacity of a particular buffer. 5. Encoding as a number of n bits, as in Option 3 above, where each value represents a specific threshold for buffer load pre-agreed in the communication between the access device and the reporting communication device. For example, the access device pushes a lookup table linking each value to the maximum buffer percentage to the communication device for the setup (RRC) communication. 6. It is possible to report metadata about the buffer, such as a single bit ("stable bit") indicating whether the allocated buffer is guaranteed to be at least its current capacity (e.g., "1") or not guaranteed to remain at this capacity (e.g., "0"), or a single bit indicating whether the allocated buffer needs to be reduced for any reason (e.g., reconfiguration of relay and / or telecommunication devices in a network, or an application in a relay communication device requires additional memory) (e.g., "1") or not (e.g., "0"). The metadata can be encoded with additional bits to encode the reason for buffer reduction or the duration for which the current buffer capacity allocation is guaranteed in the relay communication device. 7. The reported information includes specific requests to the access device arising from buffer-related issues, such as an "Alert" field or bit to indicate to the access device that the relay communication device wants to offload one or more remote communication devices to another relay communication device because the communication resources on the relay communication device itself are running low, or a "Capacity" field to indicate to the access device how much buffer space will be available to those devices in the future if relay or remote communication devices are added as children to the current relay communication device. This improves the allocation of access devices to the parent relay communication device of relay or remote communication devices through network topology reconfiguration, if the relay architecture used in the wireless network supports such reconfiguration.

[0113] According to various embodiments, reporting buffer capacity information to access devices and / or other communication devices within a wireless network can be achieved by the following options: 1. Transport protocols that are higher-level than Internet Protocol (IP), such as Hypertext Transfer Protocol (HTTP), Constrained Application Protocol (CoAP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Message Queuing Telemetry Transport (MQTT), are used. If the reporting relay communication device is not directly connected to the access device, IP packets carrying buffer capacity information that carry transport protocol PDUs are relayed to the access device. When the IP packet reaches the access device, it is forwarded to the Network Function (NF) specified by the IP destination address. If the NF is outside the access device, the NF receives buffer capacity reports sequentially and then notifies the access device of this information so that the access device can use the reported buffer capacity information to schedule according to various embodiments. If, instead, the NF is internal, i.e., on the access device, the access device directly receives and uses the reported buffer capacity information. 2. In an L2 relay architecture, the RRC protocol is used for end-to-end relay between the relay communication device and the access device. For example, in an L3 relay architecture, the RRC protocol is used to report directly to a peer communication device over a single radio link between the relay communication device and another relay or remote communication device, or via the PC5 interface on the SL. RRC messages are transported sequentially over multiple hops using the MAC protocol, Radio Link Control (RLC), and PDCP. This option has the advantage of ensuring transport reliability (via PDCP, using retransmission) and applying integrity protection. Note that the aforementioned RRC sent device-to-device over a single link is referred to as PC5-RRC. 3. PDCP control or data PDU is used. 4. MAC control elements (CEs) are used. MAC CEs are sent on the SL to the next upstream relay communication device, to the peer communication device on the SL, or directly to the access device on the UL. This is a lightweight method that can even opportunistically utilize unused space within the transport block, which can in some cases be achieved by, for example, padding BSR MAC CEs. 5. The Uplink Control Information (UCI) data format is used. This format is sent directly to the access device by the relay communication device via the UL channel (e.g., the Physical Uplink Control Channel (PUCCH) or the Physical Uplink Shared Channel (PUSCH)). 6. A data format within Sidelink Control Information (SCI) that is sent over an SL connection by a relay communication device to another relay or remote communication device. 7. PC5 messages on the SL, such as relay discovery messages, relay announcement messages, relay discovery response messages, or PC5-RRC messages, are used. This has the advantage that the sender can report to communication devices that do not yet have an established PC5 link, and can report to multiple devices simultaneously using broadcast messages. 8. A combination of the above options, for example, by reporting directly to the access device via RRC and directly to the upstream parent relay communication device via MAC CE. Alternatively, for example, by collecting one or more reports from child relay communication devices via MAC CE and reporting them to the parent relay communication device using RRC, sending them directly to the access device.

[0114] According to various embodiments, the PDCP control PDU is used to send buffer capacity information to the access device. According to 3GPP® specification TR38.323v15.6.0, section 6.3.8, control PDU types 010-111 are used to signal buffer capacity information, as further extensions are available.

[0115] The new PDU type can use any format, for example, a single value reported by the relay communication device to the upstream parent relay communication device or directly to the access device, or a buffer capacity report combining multiple values ​​is reported to the upstream parent relay communication device or directly to the access device. The report consists of the relay communication device's own buffer capacity report plus information from aggregated buffer capacity reports received from downstream relay communication devices, or the buffer capacity report is combined with buffer size information from previously reported downstream (relay) communication devices (e.g., information from BSR MAC CE or SL BSR MAC CE).

[0116] This PDCP-based approach offers low overhead and is advantageous in L2 relay architectures because it is transmitted end-to-end from the relay communication device to the access device. The PDCP control PDU is interleaved with regular PDCP data PDUs on the existing radio bearer.

[0117] As shown in the procedure in Figure 5, the proposed buffer capacity reporting is triggered by events (e.g., rules or instructions) occurring in the relay communication device. Such events include: 1. The maximum buffer capacity of the relay communication device has been reduced. 2. The data relay buffer has become full beyond a defined threshold. In this case, the threshold may be absolute (e.g., measured in bytes) or relative (e.g., a percentage of the total buffer capacity available to that particular buffer, or a percentage of the total buffer memory available to the communication device). 3. Timer-based trigger. 4. The load on the relay data buffer increased by at least N% compared to the previously reported load. 5. Receiving buffer capacity queries from scheduling access devices or upstream relay communication devices. 6. Changes in the buffer capacity of the remote communication device. 7. Receiving buffer size or capacity reports from downstream remote or relay communication devices. 8. Receiving buffer status messages (e.g., SL-BSR MAC CE), scheduling request messages, or query messages (e.g., Recommended Bit Rate query MAC CE, relay status query message, or relay discovery message) from downstream remote or relay communication devices. 9. Receiving recommended bitrate messages (e.g., Recommended Bit Rate MAC CE) or query messages (e.g., Recommended Bit Rate Query MAC CE) from downstream remote or relay communication devices. 10. Receipt of communication resource request messages from downstream remote or relay communication devices. For example, relay discovery request messages broadcast by a remote communication device with the intention of discovering a potentially better and more suitable parent relay communication device than the current relay communication device. 11. Receipt of communication resource request messages or query messages from an OoC communication device. For example, a relay discovery request message broadcast by an OoC communication device with the intention of discovering a suitable relay communication device.

[0118] If not all relay communication devices (e.g., relay UEs) directly and independently report their buffer capacity information to access devices (e.g., gNBs), a format is used to report combined information from multiple relay communication devices to the access device. Combined buffer capacity reporting is advantageous because it reduces signaling overhead, thereby making communication resource utilization more efficient. Another potentially advantageous feature is that upstream relay communication devices can gain insights into the buffer capacity reports of their downstream relay communication devices, thereby better regulating data traffic or increasing their own buffer allocation for specific data streams to assist downstream relay communication devices experiencing high buffer loads.

[0119] Examples of various options for the combined format include: 1. A relay communication device reports a binary payload consisting of N+1 concatenated elements, the first of which is its own buffer capacity report. The remaining N elements are the buffer capacity reports of its downstream relay commission devices (children), sorted in ascending order of ID numbers, where the ID number is any relevant identification information such as a Radio Network Temporary Identifier (RNTI), ProSeUE ID, or ProSe Relay UE ID. 2. The relay communication device combines the buffer capacity report of the downstream relay communication device with the combined buffer capacity report by concatenation. 3. The relay communication device summarizes the buffer capacity reports received from the downstream relay communication device for more efficient reporting to its upstream parent or access device. For example, the format is compressed from the original 8-bit buffer load (%) values ​​to 2-bit values ​​(e.g., <25%, <50%, <75%, >90%). Individually attributable reports are still maintained, and for example, reporter identification information is encoded in the order in which the 2-bit elements are sent implicitly. 4. The relay communication device reports a pair of the ID of the individual relay communication device and a buffer capacity report. In this case, the ID is one of the IDs defined in Option 1 above. Alternatively, for efficiency, a shorter ID can be defined, such as a 4-bit or 8-bit index that the access device can interpret as true identification information for the reporting relay communication device. 5. The relay communication device selects only those reports that involve a high buffer load and require urgent action by the access device's scheduler, such as those related to the report.

[0120] In one embodiment, an access device (e.g., a gNB) determines, based on a received buffer capacity report, that a relay or telecommunications device (e.g., a UE) requires an additional parent relay communication device above the current relay communication device because the buffer in the current relay communication device or one of its upstream parent relay communication devices is filling up too quickly or is overflowing. To achieve this, the access device instructs the specific relay or telecommunications device to acquire an additional parent or initiate a parent change.

[0121] Figure 6 is a schematic diagram of a network architecture used in various embodiments, for example, by a MAC CE to collect buffer capacity information via a relay communication device. The components of the network architecture in Figure 6 correspond to the components in Figure 1, so components with the same reference numerals will not be described again here.

[0122] The access device 20 schedules communication resources based on the received buffer size and capacity information.

[0123] In the scenario shown in Figure 6, the remote fourth communication device 10-3 suddenly generates a large data volume and sends a portion of this data to its parent, i.e., the second relay-type second communication device 12-2, along with a MAC CE type similar to the SL BSR MAC CE (arrow R1) to show the parent the remaining data. Note that this MAC CE is also identical to the SL BSR MAC CE in this embodiment.

[0124] The new data fills the relay buffer of the second communication device 12-2 beyond a predetermined threshold, which 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. This may be done by transferring a separate new MAC CE element "MaxSize" indicating its maximum buffer capacity, and an SL BSR MAC CE or an equivalent new MAC CE type indicating its current relay buffer size.

[0125] The first communication device 12-1 receives the MaxSize MAC CE and the BSR MAC CE and successively reports MaxSize information about itself and about the second communication device 12-2 to the access device 20, as indicated by arrow R3. The first communication device 12-1 also adds an extended BSR MAC CE that includes the buffer capacities of itself and the second communication device 12-2. The term "extended" is used here to indicate that the existing BSR MAC CE cannot include the buffer sizes of other devices. Therefore, an extended MAC CE is proposed that is similar to the existing MAC CE but can also store data from other devices.

[0126] Next, the scheduler of access device 20 determines that more bandwidth is needed in 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 will be described later in relation to Figure 7.

[0127] Figure 7 is a schematic diagram of a network architecture used in various embodiments, for example, to distribute DL control information (DCI) and RRC messages via a relay communication device to deliver scheduling information. The components of the network architecture in Figure 7 correspond to the components in Figure 1, so components with the same reference numerals will not be described again here.

[0128] In the scenario shown in Figure 7, the DCI is sent over, for example, a PDCCH, which includes a dynamic UL, DL, and / or SL schedule, only for the relay-type first communication device 12-1, as indicated by arrow M1. This is sent not just once, but whenever the first communication device 12-1 is granted (additional) communication resources for DL ​​or UL data transfer. Thus, the DCI is sent multiple times during the scheduling process.

[0129] Next, as indicated by arrow M2, a first RRC message is sent (e.g., on the PDCP) that includes a schedule update for the SL for the second relay-type communication device 12-2.

[0130] Finally, a second RRC message is sent (e.g., on the PDCP) containing a schedule update for the remote fourth communication device 10-3, as indicated by arrow M3.

[0131] Note that the transmission sequence for the first and second RRC messages will differ. The transmission sequence may be the default sequence or it may be pre-set.

[0132] The second RRC message described above is optional if there is no need to update the resource allocation of the fourth communication device 10-3.

[0133] Next, using the new resource allocation, the second communication device 12-2 can send more data to the first communication device 12-1, and the first communication device 12-1 can send more data towards the access device 20 in the UL direction, thereby reducing the percentage of the relay data buffer utilization of the second communication device 12-2.

[0134] In various embodiments, the access device 20 can control and influence the maximum or available buffer capacity of the relay communication device. This is done in response to one or more previously received buffer capacity reports. Buffer capacity control is achieved by at least one of the following options: 1) Command the relay communication device to increase or decrease the buffer capacity of the data stream associated with a specific LCID, a specific LCG, a specific downstream child relay or telecommunication device, or a specific network slice. 2) The relay communication device is switched between an "autonomous mode" for buffer allocation (performed by the relay communication device itself) and an "instruction mode" for buffer allocation (the access device 20 determines the buffer capacity via control commands). 3) Set a policy in the relay communication device regarding how buffer allocation should be performed. In this case, the policy includes determining the data buffer capacity in the relay communication device. 4) Set the reporting granularity of the reports generated by the relay communication device. For example, switch the low-precision buffer capacity value to the high-precision buffer capacity value, or vice versa. Alternatively, increase the time interval between reports, or request a higher level (less detailed) reporting, or vice versa. 5) Command the relay communication device to merge multiple separate buffers into a single buffer allocation. For example, instead of maintaining N separate buffers for N LCIDs, or M separate buffers for M downstream communication devices, create a shared buffer for all upstream relay data traffic.

[0135] In another embodiment, which can be combined with any other embodiment of the present invention, or which can independently implement an aspect of the present invention, low-latency reporting using scheduling request timing is provided when the relay communication device is the last relay communication device before the access device 20 and is directly connected. This reduces latency between the event in which new data becomes available at some communication devices and the access device 20 receives the data, when no existing UL communication resources have yet been acknowledged to the last-hop relay communication device to transmit application data, buffer size information (e.g., BSR MAC CE), and / or buffer capacity information.

[0136] To achieve this, multiple PUCCH scheduling request (SR) settings are used by the last-hop relay communication device. These settings are configured by the access device 20 and include at least a first PUCCH SR setting for low-latency data (including relayed low-latency data) and a second PUCCH SR setting for non-low-latency data. The PUCCH scheduling request settings are used to request resources for uplink shared channel (UL-SCH) transmission by executing scheduling request (SR) procedures in PUCCH, as defined in 3GPP® specifications TS38.300v16.4.0 and TS38.321v16.3.0. Each setting consists of a set of PUCCH resources across different bandwidth portions and cells. Each logical channel on the relay communication device is mapped to a specific SR setting by an RRC setting, as defined in TS38.331v16.3.1. One RRC configuration information element (IE) is SchedulingRequestConfig, which contains a set of SchedulingRequestToAddMod elements that configure parameters for a specific SR configuration to be added, including sr-ProhibitTimer and sr-TransMax, which control the SR retransmission timer and the maximum number of repeat transmissions, respectively. Another RRC configuration IE is SchedulingRequestResourceConfig, which defines a specific time / frequency resource configuration for SRs. This includes a periodicityAndOffset field that defines how often and where SR opportunities occur, for example, per slot (sl1) or every 8 slots (sl8). Another RRC configuration IE is SchedulingRequestResourceConfig-v1610, which defines the preference selection (p0=low or p1=high) for a particular SchedulingRequestResourceConfig. Therefore, an SR configuration associated with a logical channel for low-latency data would, for example, use high-priority (p1) per slot (sl1) for SR opportunities.Additionally, SR settings associated with logical channels for non-low latency data might use SR opportunities for every 8 slots (sl8) of low priority (p0).

[0137] Furthermore, the access device can influence cyclic shifts and orthogonal cover sequences, as well as whether the UE should perform frequency hops. By providing different scheduling request settings and different PUCCH resources, the access device can identify scheduling requests from each connected UE individually, or even by logical channel ID.

[0138] The relay communication device transmits an SR signal using the SR setting of the first PUCCH when it has low-latency upstream relay data to transmit to the access device 20, or when it is triggered to transmit buffer size information to the access device 20 (e.g., using a BSR MAC CE) related to buffered low-latency upstream relay data, or when it is triggered to transmit buffer capacity indication data to the access device 20 related to buffered low-latency data.

[0139] Upon receiving the scheduling request, the access device allocates uplink resources to the relay communication device to send buffered low-latency data. Using the uplink resources allocated by access device 20, the relay communication device sends buffered low-latency relay data (if any) along with buffer capacity information to access device 20 (which may be sent later if the delivery of the low-latency data itself is considered more important).

[0140] 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 devices.

[0141] Therefore, according to the first aspect of this embodiment, a method for requesting communication resources within a network is proposed, and the method is: In a relay communication device, a scheduling request (SR) setting is selected from a set of scheduling request settings according to the type of data being sent. The relay communication device transmits a scheduling request signal using the selected scheduling request settings, The relay communication device uses communication resources allocated by the access device in response to the selected scheduling request sent, in order to transmit buffer capacity information to the access device.

[0142] Furthermore, according to a second aspect of this embodiment, a relay communication device for requesting communication resources within a network is proposed, and the relay communication device is A controller configured to select a scheduling request (SR) setting from a set of scheduling request settings according to the type of data being sent, A transmitter configured to transmit a scheduling request signal using a selected scheduling request setting, the transmitter being configured to use communication resources allocated by the access device in response to the transmitted selected scheduling request to transmit at least buffer capacity information to the access device.

[0143] In an option of this embodiment, the set of scheduling request settings includes at least a first scheduling request setting for low-latency data (including relayed low-latency data) and a second scheduling request setting for non-low-latency data.

[0144] In another option of this embodiment, the scheduling request is triggered in response to one of the following events: a relay communication device has low-latency upstream relay data to send to an access device and is triggered to send buffer capacity information to the access device associated with the buffered low-latency upstream relay data, or buffer capacity information is triggered to send to the access device associated with the buffered low-latency data.

[0145] The advantage of using such low-latency specific SR settings is that the SR directly indicates to the scheduler of access device 20 that low-latency data is pending in a relay communication device for one of its downstream communication devices, so that the scheduler schedules the radio resource for UL on the first possible occasion and / or with higher priority, thereby improving scheduling to achieve lower latency.

[0146] However, the access device does not know how much low-latency data will be buffered by the relay communication device. According to TS38.321, uplink resources are also used to send Buffer Status Report (BSR) messages to the access device if the uplink resources are insufficient. However, in the case of low-latency relay data or low-latency data for UE in general, it is beneficial to use all uplink resources to send the low-latency data. However, if this is done, the access device cannot distinguish whether the scheduled UL resources are just enough, nearly enough (leaving no room for BSR messages), or insufficient to send the buffered data. For this purpose, in the case of low-latency data for the access device, if all (or nearly all, i.e., above a certain threshold) uplink resources within a given time interval are used to send buffered low-latency data (i.e., without other content or messages such as BSRs), there is one option for the access device to assume that the uplink resources are insufficient and immediately schedule additional uplink resources. This assumes that the access device can determine whether an uplink resource was used to send data from a buffer containing low-latency data by identifying, for example, that the scheduling request is related to a logical channel used to transfer low-latency data, based on the received scheduling request. The disadvantage of doing this is that too many resources that are not needed by the UE are scheduled. Also, if all the low-latency data has already been sent, the UE will use additional uplink resources for less urgent data. Therefore, if the uplink resources alone are sufficient, the access device does not need to be able to distinguish this case.Accordingly, in one embodiment that can be combined with any other embodiment of the present invention, or in which an aspect of the present invention can be independently implemented, the UE includes special signals (e.g., by adding a flag to the header of a message sent to the access device or by setting a bit, or by appending it to the end of all messages sent) to indicate that more data is pending for transmission and / or that the BSR is pending. If information about buffer capacity is available to or managed by the access device, or signaled by a preceding buffer capacity report, there is yet another option, where a buffer load percentage, buffer capacity index, or flag indicating whether the buffer load threshold has been exceeded is sent to the access device using a scheduled uplink resource, which reflects the buffer size after the buffer data has been sent to the access device (i.e., the amount of data remaining in the buffer). Alternatively, the UE sends a duplicate of a previously sent scheduling request or a new scheduling request related to low-latency data as part of a scheduled uplink resource, or immediately after the last sent message or the first PUCCH opportunity (if this occurs before the reception of additional uplink resources). An advantage of all these signals is that they are typically smaller than BSR messages (for example, 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 to maximize the resources used to send low-latency buffered data, and also when uplink resources are insufficient to send the BSR along with all the buffered low-latency data.

[0147] It should be noted that this principle can be applied to any UE transmitting low-latency data and is not limited to relay communication devices.

[0148] Therefore, according to the first aspect of this embodiment, a method for requesting communication resources within a network is proposed, and the method is: To send buffer data of a given type, and if the communication resources allocated to a given time interval are insufficient to send all buffer data of a given type, the mobile device may use the communication resources allocated to the access device for a given time interval to send, as part of the same allocated resources, a buffer capacity report, buffer load rate, buffer capacity index or flag indicating whether the buffer load threshold has been exceeded, or a flag indicating that more data of a given type is in the mobile device's buffer, instead of a BSR. One option is that, for this purpose, the mobile device reserves the necessary number of bits from the allocated resources to send the buffer capacity report, buffer load rate, buffer capacity index or flag, and sends this information immediately before ("prepended") or immediately after ("appended") the buffer data of a given type. The number of bits required for this is pre-agreed / pre-configured by the mobile device and the access device so that all other bits can be used to send buffer data of a given type. Alternatively, the buffer capacity report, buffer load percentage, buffer capacity index, or flags may be sent as part of the dataframe header (e.g., MAC(sub)header) or in place of the header (e.g., instead of LCID, or using the reserved flag R).

[0149] Alternatively, the relay communication device may maintain a separate buffer for low-latency data and one or more other buffers (e.g., data buffered separately as lossless and lossy streaming data, bulk data, and data unaffected by latency) for streaming. For this purpose, the relay communication device receives information about the type of data relayed from the remote communication device or access device (this may take the form of QoS data such as 5QI values, logical channel settings, maximum latency values, flags / attribute values ​​set during connection setup, settings included in RRC messages, or information in the frame / packet header). Each of these buffers is assigned a different identifier, such as a buffer identifier or an identifier related to a logical channel / radio bearer (e.g., logical channel ID i.e., LCID) or logical channel group (LCG). These identifiers are assigned by the relay communication device and transmitted to the access device, or assigned by the access device and transmitted to the relay communication device. The access device uses such identifiers to define and / or map scheduling request settings, and communicates the mapping of these identifiers to specific scheduling request settings to the relay communication device. Using a single, separate buffer to aggregate all low-latency data simplifies the configuration required to uniquely identify scheduling requests for low-latency data, regardless of which remote or relay communication device they originate from, especially when only one other buffer is used for all other (i.e., non-low-latency) data or messages. The access device further defines separate scheduling request settings for different buffer sizes or buffer load thresholds (e.g., a first scheduling request setting used when the buffer load is less than 90%, and a second setting used when the buffer load is at least 90%). This information is sent as policy information via the Policy Control Function (PCF) or RRC.

[0150] If a separate buffer is used for low-latency data and resource allocation is prioritized for sending data within that low-latency buffer, the LCID is omitted from the MAC layer header. Using the above mechanism to use all resources to send buffered data of a given type (low-latency data in this case), and using buffer capacity reports, buffer load rates, buffer capacity indexes, or flags to indicate that allocated resources are insufficient, the mobile device omits the LCID from the MAC layer header until the low-latency buffer is empty (or falls below a threshold). In addition, if both the mobile device and the access device know the length of the payload frame of the data being used (e.g., MAC PDU / SDU) (e.g., through pre-configuration), the entire MAC header (including its length field and format) is omitted. The mobile device may be pre-configured to always switch to a mode where buffered low-latency data is sent first and LCID information is omitted from the MAC layer header, or the mobile device may be pre-configured with a policy to do so, depending on the buffer load threshold for the low-latency buffer. Alternatively, the access device may use a flag to indicate that the scheduled resource is used to send low-latency data.

[0151] Once the low-latency data buffer is empty or falls below a threshold, the buffer capacity report, buffer load percentage, buffer capacity index, or flags are given values ​​that the access device can recognize as an indication that the mobile device is switching back to its original operating mode, thereby including the LCID information back in the MAC layer header. Alternatively, a buffer status report should be sent to the access device to indicate that the mobile device has switched back to its original operating mode, thereby including the LCID information in the MAC layer header, and to indicate that some other buffers (assigned to other LCIDs) have pending buffer data for which uplink resources need to be scheduled.

[0152] Alternatively, the relay communication device determines the combined buffer status information of all intermediate hops (i.e., other relay communication devices) between the remote communication device and the relay communication device, thereby including buffer size information and buffer capacity information such as the buffer size limit and buffer load level of each buffer, separately or for example, for each type of data being relayed (combining all latency-related information such as buffer status information for low-latency buffers used by intermediate relay communication devices, or the average time data resides within the buffers of the relay communication device). For this purpose, each relay communication device transmits not only its own buffer capacity information but also buffer capacity information received from intermediate nodes or remote communication devices. Alternatively, the relay communication device sends a message on the PC5 (for example, an RRC message destined for a specific relay communication device and which may be relayed via one or more downstream relay communication devices) to another (downstream) relay communication device and requests the buffer capacity information of that other (downstream) relay communication device. After collecting, aggregating, and encoding buffer capacity information received by downstream devices, sometimes along with its own buffer capacity information, the relay communication device sends this combined buffer status information to the access device. By providing this information to the access device, the access device uses it to schedule additional sidelink resources, modify the timing of scheduled resources to better align communication between intermediate nodes, and give instructions on how the relay communication device should use these resources for prioritizing the transmission of low-latency data (for example, by providing individual LCID, LCG, buffer identifiers, or telecommunication device identifiers that should have higher temporal priority or that should always be transmitted first before any other information, such as buffer status reports).

[0153] Based on the received combined buffer status information, the access device can determine a bottleneck in one of the intermediate relay communication devices used to relay data for the remote UE, and provide / schedule additional sidelink resources to one or more intermediate relay communication devices, or instruct one or more intermediate relay communication devices to increase their buffer capacity. The relay communication devices can also decide to use additional resources based on the received buffer capacity information, or increase their buffer capacity based on, for example, a pre-configured policy (e.g., received from the access device or PCF). Alternatively, the relay communication devices may use additional sidelink resources in unlicensed bandwidth. The relay communication devices and / or remote UEs may also configure a resource pool on the sidelink for low-latency data transfer, separate from the resource pool used for other (i.e., non-low-latency) data transfers. Such a separate resource pool uses higher frequencies, wider bandwidth, carrier aggregation, and shorter time intervals to enable faster data transfers. Such resource pools are configured for a single remote UE (or a very small number of remote UEs) so that the remote UE can send its data without needing to sense the medium before transmission over the sidelink, thereby reducing latency. For this purpose, if low latency QoS is required for the remote UE, the access device authorizes and configures a separate resource pool for sidelink communication, for example, through RRC messages to the relay communication device and / or the remote UE (either directly or via the relay communication device). The access device also configures the remote UE's identification information and the set of credentials to be used (as part of the communication connection setup over the sidelink) so that the relay communication device can identify whether the remote UE is authorized to use this separate resource pool.The relay communication device notifies the remote UE of a separate resource pool for low-latency communication via RRC or other messages during relay discovery, sidelink connection setup, or after the sidelink connection has been established.

[0154] Alternatively, based on received buffer capacity information (for example, if the maximum buffer capacity has been reached, or if the remaining memory capacity is insufficient to add an additional remote or relay device), the access device may send a message to the relay device to stop itself from being discoverable as a relay. Furthermore, criteria for making this decision are sent to the relay device (for example, pre-configured through a policy sent by the access device or PCF) so that the relay device can make this decision without needing to examine or receive additional messages from the access device. Similarly, if the access device (or, based on the policy, the relay device) determines that the latency induced by a particular relay device exceeds a threshold (for example, based on the average time the relayed data stays in the buffer), the relay device is instructed to stop itself from being discoverable, or the remote device is instructed to select another relay device and forward the data to the access device or core network. For this purpose, the relay device reports the average latency induced by the relay device via a PC5 discovery message or an RRC message. This latency information is reported for each relay communication device, each LCID, each LCG, or each buffer ID. Relay communication devices also receive information from other relay communication devices (or indirectly from access devices) about the average end-to-end latency for sending messages to access devices through one or more relay communication devices, and send information about end-to-end latency to remote communication devices or other relay communication devices in PC5 discovery messages and / or RRC messages.

[0155] In a sub-embodiment, low-latency reporting using SR timing for a specific logical channel ID or buffer ID (which is different from the LCID used in the Uu interface) used for PC5 communication between one specific telecommunication device or between a telecommunication device and a relay communication device is given as a special case of the embodiments described above. In cases where data is relayed for one or more telecommunication devices or relay communication devices, the data is typically multiplexed by a relay communication device (i.e., the "last" relay communication device) that is directly connected to the access device (e.g., via a Uu interface). For this purpose, the relay communication device has a mapping of multiple logical channel identifiers / radio bearers used by the downstream devices, or has a calibration layer that can map, for example, communication channels for a specific telecommunication device to a set of logical channels / radio bearers on a direct (e.g., Uu) connection between the "last" relay communication device and the access device. For this purpose, the "last" relay communication device is convenient for aggregating and storing data coming into a common buffer from multiple downstream relay communication devices or telecommunication devices. This means that an access device cannot know which device the buffered data originated from, based on the scheduling request or BSR message it receives (which reports the buffer size for each LCID). The access device only knows that the data is sent by the "last" relay communication device, and cannot determine, for example, whether the data belongs to a specific remote device or a specific relay communication device based on the scheduling request or BSR. Of course, the access device can use higher-level layer information (compatible layer identifier or IP address), but for buffering low-latency data, it is undesirable to have to decode higher-level layers before deciding to schedule additional resources.In the embodiments described above, the SR from the relay communication device to the access device 20 does not convey information about which remote communication devices in a group require an immediate scheduled communication resource for latency-critical data. In this particular sub-embodiment, it is possible to create a dedicated PUCCH SR setting to send an SR related to a specific downstream remote communication device, or a specific downstream logical channel ID or buffer ID used for PC5 communication that requires the transmission of latency-critical data through the relay communication device. Thus, the type of data underlying the selection of the SR setting mentioned above also includes identification information of the remote communication device or logical channel ID or buffer ID. A different scheduling request setting is then selected depending on the type of data to be transmitted, in which case the type of data includes identification information of the remote device or logical channel ID or buffer ID through which the data is relayed. This has the advantage that when the access device 20 receives this particular SR signal from the relay communication device, the access device immediately knows which remote communication device or downstream logical channel or buffer has latency-critical data to transmit, and can immediately schedule communication resources for all relay communication devices involved in the indirect connection to that remote communication device, as well as for the remote device itself to transmit this data to the remote device's parent relay communication device. Note that this remote communication device also functions as a relay communication device itself. As an additional option, the access device schedules dedicated resources for transmitting low-latency data, which is done for each remote communication device or relay communication device that has low-latency data to transmit or for which a bottleneck has been identified. This includes scheduling resources from the sidelink resource pool with very short iteration intervals or in separate frequency ranges to reduce contention. Another option is that separate scheduling request messages are used on the PC5 / sidelink.In such sidelink scheduling requests, different settings are used (for example, set by the access device in the relay device or on the relay device, or by the relay device itself, and then information about the scheduling request settings is sent to the relay device or downstream relay device) so that the relay device can identify which telecommunications or downstream relay device, or logical channel or buffer, is to be used based on the received sidelink scheduling request. In addition, after receiving the sidelink scheduling request, the relay device allocates resources to retrieve data from the buffer of the downstream telecommunications device or relay device. In the case of low-latency data, buffer capacity information is sent along with the buffer data using a mechanism similar to that described above.

[0156] In yet another embodiment, buffer capacity information is reported by the relay communication device to one or more peer communication devices using D2D messages, such as a PC5 discovery announcement message or a PC5 discovery response message, along with other information such as the measured signal strength of the received communication message, to control the selection and / or reselection of the relay communication device. Using this information, the peer communication devices can (re)select the relay best suited to their indirect communication needs, thus contributing to the process of optimal scheduling and distribution of communication resources within the wireless network. The peer communication devices are relay communication devices, telecommunication devices, or OoC communication devices. The D2D message type used to communicate the buffer capacity information is either a PC5 discovery response message (Model B discovery) or a PC5 discovery announcement message (Model A discovery). The buffer capacity information is encoded in one of the manners described above. The buffer capacity information is also encoded as part of a combined value "relay load" that indicates the level of load on the resources of the relay used for its relay-related operations, or overall computation and communication operations. Multiple such resource levels, which may be combined with one or more combined relay load values, are also reported in a single message. These resources reported or used in combined relay load values ​​are one or more of the following: processing capacity, memory usage, buffer-specific memory usage, used upstream, SL, or UL bandwidth, used downstream or DL ​​bandwidth, the number of active telecommunication devices, etc. "Relay load" is also encoded as the opposite "relay capacity," indicating how much resource is still available to serve new downstream relay and / or telecommunication devices, instead of used resources. A peer communication device receiving buffer capacity information from multiple expected relay communication devices in this way determines which relay communication devices provide a reasonable received signal strength (e.g., RSRP) combined with sufficient buffer capacity.The peer device is triggered to perform relay discovery due to timer expiration or because the reported current buffer capacity of its current relay communication device falls below a threshold. If the peer device finds a more suitable relay, it connects to the additional relay communication device as its parent and drops the connection to the old parent relay communication device once it has connected.

[0157] In the embodiments described above or in other options that can be combined with any other options, based on the received buffer capacity information (for example, if the maximum buffer capacity has been reached, or if the remaining memory capacity is insufficient to add an additional telecommunication device or relay communication device), the access device sends a message to the relay communication device to prevent itself from being discovered as a relay. Furthermore, criteria for making this decision are sent to the relay communication device (for example, through a policy sent by the access device or PCF) so that the relay communication device can make this decision without needing to examine or receive additional messages from the access device.

[0158] In summary, a method and apparatus for cellular networks or other wireless networks is described that can improve network coverage by introducing a relay terminal device to support indirect network connectivity for remote terminal devices within an OoC area. Such a relay terminal device buffers upstream and downstream data from and to other indirectly connected terminal devices. However, the relay terminal device has limited memory allocation for buffering relay data. This limitation has a significant impact on the optimal resource scheduling performed by network access devices. Therefore, in order to enable optimal resource scheduling by access devices, it is proposed to configure the method and apparatus to cause the relay terminal device to report information about its available or maximum buffer capacity to each of its network access devices.

[0159] While the present invention has been illustrated and described in detail in the drawings and prior description, such illustrations and descriptions are illustrative or exemplary and should not be construed as limiting. The present invention is not limited to the embodiments disclosed. The proposed scheduling enhancements can be implemented in any type of wireless network and are applicable, for example, to device communications using cellular wireless communication standards, specifically the Third Generation Partnership Project (3GPP®) 5G specifications. 5G wireless communication devices may be of various types, such as mobile phones, vehicles (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) diagnosis and treatment devices for hospital or first-person use, virtual reality (VR) headsets, etc.

[0160] The present invention is also applicable to Integrated Access and Backhaul (IAB) systems. In particular, mobile IAB nodes move during operation and lose connectivity with other IAB nodes or base stations. Therefore, this causes abrupt changes in their respective capacities and loads, and thus causes one or more buffer sizes in a mobile IAB node to reach their maximum buffer capacity.

[0161] Furthermore, the present invention is applicable to medical applications or connected healthcare products involving multiple wireless (e.g., 4G / 5G) connected sensor or actuator nodes, where the wireless (e.g., 4G / 5G) connected devices occasionally consume or generate a continuous data stream at a constant average data rate, for example, in general IoT applications involving wireless, mobile, or stationary sensor or actuator nodes (e.g., smart cities, logistics, agriculture, etc.), in emergency services and critical communications applications, in V2X systems, in systems with improved coverage for 5G cellular networks using high-frequency (e.g., millimeter-wave) RF, and in any other application area of ​​5G communications where relay is used, including video, ultrasound, X-ray, computed tomography (CT) imaging devices, real-time patient sensors, and acoustic, voice, or video streaming devices used by healthcare professionals.

[0162] Other variations of the disclosed embodiments will be understood and practiced by those skilled in the art from the examination of the drawings, disclosures, and appended claims in practicing the claimed invention. In the claims, the phrase “including” does not exclude other elements or steps, and the singular form does not exclude the plural form. A single processor or other unit performs the functions of several items enumerated in the claims. The mere fact that certain means are described in different dependent claims does not imply that combinations of these means cannot be used advantageously. The preceding description details certain embodiments of the invention. However, regardless of how the preceding description is detailed in text, it should be understood that the invention is practiced in many ways and is therefore not limited to the disclosed embodiments. It should be noted that the use of certain terms in describing certain features or aspects of the invention should not be taken to mean that the terms are redefined herein to be limited to including any particular characteristics of the features or aspects of the invention to which the terms relate.

[0163] A single unit or device performs the functions of several items enumerated in the claims. The mere fact that certain means are described in different dependent claims does not imply that combinations of these means cannot be used advantageously.

[0164] As shown in Figures 4 and 5, the described operations are executed as program code means for a computer program in the commissioning device or the lighting device, and / or as dedicated hardware. The computer program is stored and / or distributed in a suitable medium, such as an optical storage medium or a solid-state medium, together with or as part of other hardware, but is also distributed in other forms, such as via the Internet or other wired or wireless telecommunications systems.

Claims

1. A device for scheduling communication resources for at least one communication device in a wireless network, wherein the device is A capacity detector that detects buffer capacity information indicating the available or maximum buffer capacity of at least one relay communication device, which is signaled from the aforementioned wireless network, A scheduler schedules communication resources based on the received buffer capacity information for at least one of the following: transmission of 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 transmission of 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 wireless access link between the at least one relay communication device and an access device. A device equipped with the following features.

2. The apparatus according to claim 1, wherein the scheduler determines, based on the received buffer capacity information, to add and / or remove at least one parent relay communication device from one of the relay or telecommunication devices in the wireless network.

3. The apparatus according to claim 1, wherein the scheduler performs buffer capacity control by at least one of the following: giving a command to a relay communication device to increase or decrease the buffer capacity for a specific logical channel or logical channel group, or for a specific downstream remote or relay communication device; switching the relay communication device between an autonomous buffer allocation mode and an instructional buffer allocation mode; setting a buffer allocation policy in the relay communication device; setting the reporting granularity of the relay communication device; and giving a command to the relay communication device to merge a plurality of separate buffers into a single buffer allocation.

4. A device for controlling the scheduling of communication resources of at least one communication device in a wireless network, wherein the device is A capacity detector that determines the available or maximum buffer capacity of a data buffer in a relay communication device, A capacity reporter for reporting buffer capacity information, including the determined available or maximum buffer capacity, to the wireless network in response to a trigger event. A device equipped with the following features.

5. The apparatus according to claim 4, wherein the capacity reporter sends the buffer capacity information to a network function that transfers the buffer capacity information to a scheduling access device of the wireless network.

6. The apparatus according to claim 4, wherein the capacity reporter reports the buffer capacity information in an absolute or relative format.

7. The apparatus according to claim 4, wherein the capacity reporter reports buffer 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 a relay communication device, different priority classes of buffer data existing for the relay communication device, and at least one of the different downstream communication devices existing for the relay communication device, or combines the buffer capacity reports of one or more downstream communication devices with its own buffer capacity report.

8. The apparatus according to claim 7, wherein the capacity reporter reports a binary payload consisting of multiple concatenated elements, each element corresponding to a buffer capacity report of one logical channel of the relay communication device; includes its own buffer capacity report and / or the buffer capacity report of a sidelink connected communication device in a combined buffer capacity report; summarizes the buffer capacity information into a more compressed buffer capacity report; reports pairs of logical channels or logical channel groups with associated buffer capacity reports; reports pairs of data priority classes with associated buffer capacity reports; selects more relevant or urgent buffer capacity reports for priority reporting; or combines at least one buffer capacity report and at least one buffer size report into a single report.

9. The apparatus according to claim 4, wherein the capacity reporter includes information related to the buffer capacity report in the buffer capacity report, or encodes the buffer capacity report, by using at least one of the following: a buffer capacity index for a lookup table, a buffer load rate, a mapping of the reported buffer capacity to a capacity category, a flag indicating whether a buffer capacity threshold has been reached or exceeded, a composite value indicating the resource utilization of the relay communication device, wherein the composite value is at least partially determined by its current or past buffer capacity, a composite value indicating the relay communication device's preference or ability to accept additional telecommunication devices, wherein the composite value is at least partially determined by its current or past buffer capacity, metadata about the buffer, and specific requests triggered by buffer-related conditions.

10. The apparatus according to claim 4, wherein the capacity reporter includes information related to the buffer capacity report in the buffer capacity report, or encodes the buffer capacity report, by at least one of the following: an index for a buffer load lookup table, the current buffer load percentage, past buffer load, mapping of the reported buffer load to a load category, a flag indicating whether a buffer load threshold has been reached or exceeded, a composite value indicating the resource utilization of the relay communication device, wherein the composite value is at least partially determined by its current or past buffer load, or a composite value indicating the relay communication device's preference or ability to accept additional remote communication devices, wherein the composite value is at least partially determined by its current or past buffer load.

11. The apparatus according to claim 4, wherein the capacity reporter reports the buffer capacity information by using at least one or a combination thereof of the data formats of the Internet Protocol's higher-level transport protocol, the Wireless Resource Control Protocol's messages, the Packet Data Convergence Protocol's packet data units, the Media Access Control Protocol's control elements, the Media Access Control Protocol's service data units, and the uplink control information or sidelink control information.

12. The apparatus according to claim 4, wherein the trigger event corresponds to at least one of the following: a change in the maximum buffer capacity on a relay communication device to a lower capacity; a change in the available buffer capacity of a data buffer; a timer-based trigger; a predetermined percentage, ratio, or increase in the load on the data buffer due to data size relative to previously reported buffer capacity information; reception of 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; reception of a buffer size or capacity report from a downstream remote or relay communication device; reception of a buffer status message or scheduling request message from a downstream remote or relay communication device; reception of a communication resource request message from a downstream or relay communication device; reception of a discovery or status request message from a downstream device or a communication device outside of coverage; reception of a request from an access device; and reception of a recommended bitrate message or recommended bitrate query message from a downstream remote or relay communication device.

13. An access device for a wireless network comprising the apparatus described in any one of claims 1 to 3.

14. A relay communication device for a wireless network, comprising the apparatus described in any one of claims 4 to 12.

15. A method for scheduling communication resources for at least one communication device in a wireless network, wherein the method is: The steps include detecting the available buffer capacity of at least one relay communication device signaled from the aforementioned wireless network, The steps include scheduling, based on the detected buffer capacity information, at least one of the following: transmission of 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 transmission of 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 wireless access link between the at least one relay communication device and an access device. A method having

16. A method for controlling the scheduling of communication resources of at least one communication device in a wireless network, wherein the method is: A step of determining the available or maximum buffer capacity of the data buffer in the relay communication device, The steps include: reporting the determined available or maximum buffer capacity to the wireless network in response to a trigger event; A method having

17. A computer program, when executed on a computer device, comprising code means for producing steps of the method according to claim 15 or 16.

Images