WO2025231607A1

WO2025231607A1 - Pdu transmissions

Info

Publication number: WO2025231607A1
Application number: PCT/CN2024/091393
Authority: WO
Inventors: Boyan Yanakiev; Claudio Rosa; Benoist Pierre Sebire; Zexian Li; Chunli Wu
Original assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy; Nokia Technologies Oy
Current assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy; Nokia Technologies Oy
Priority date: 2024-05-07
Filing date: 2024-05-07
Publication date: 2025-11-13
Anticipated expiration: 2026-11-07

Abstract

Embodiments of the present disclosure relate to protocol data unit (PDU) transmissions. In an aspect, a terminal device receives, from a network device, an indication indicative of at least one PDU size. The terminal device constructs at least one PDU having a fixed size. The fixed size is associated with the at least one PDU size. The terminal device transmits, to the network device, information on a number of the at least one PDU available for transmission. The terminal device receives, from the network device, an indication indicative of resource allocation; and transmits, to the network device, at least a portion of the at least one PDU based on the resource allocation. In this way, the power efficiency and processing speed may be improved.

Description

PDU TRANSMISSIONS

FIELD

Various example embodiments relate to the field of telecommunication and in particular, to a terminal device, a network device, methods, apparatuses and a computer readable medium for protocol data unit (PDU) transmissions.

BACKGROUND

A communication network can be seen as a facility that enables communications between two or more communication devices, or provides communication devices access to a data network. A mobile or wireless communication network is one example of a communication network.

Such communication networks operate in accordance with standards, such as those promulgated by 3GPP (Third Generation Partnership Project) or ETSI (European Telecommunications Standards Institute) . Examples of such standards include the so-called 5G (5th Generation) standard or other standards promulgated by 3GPP.

SUMMARY

In general, example embodiments of the present disclosure provide a solution for PDU transmissions.

In a first aspect, there is provided a terminal device. The terminal device comprises at least one processor and at least one memory storing instructions. When executed by the at least one processor, the instructions cause the terminal device at least to: construct at least one PDU having a fixed size, wherein the fixed size is associated with the at least one PDU size; and transmit, to a network device, information on a number of the at least one PDU available for transmission.

In a second aspect, there is provided a network device. The network device comprises at least one processor and at least one memory storing instructions. When executed by the at least one processor, the instructions cause the network device at least to: receive, from a terminal device, information on a number of at least one PDU having a fixed size; and determine a buffer status of the terminal device based on the number of the at least one PDU and the fixed size.

In a third aspect, there is provided a method. The method comprises: constructing, at a terminal device, at least one protocol data unit (PDU) having a fixed size; and transmitting, to a network device, information on a number of the at least one PDU available for transmission.

In a fourth aspect, there is provided a method. The method comprises: receiving, at a network device and from the terminal device, information on a number of at least one protocol data unit (PDU) having a fixed size; and determining a buffer status of the terminal device based on the number of the at least one PDU and the fixed size.

In a fifth aspect, there is provided an apparatus. The apparatus comprises means for constructing at a terminal device, at least one protocol data unit (PDU) having a fixed size; and means for transmitting, to a network device, information on a number of the at least one PDU available for transmission.

In a sixth aspect, there is provided an apparatus. The apparatus comprises means for receiving, at a network device and from the terminal device, information on a number of at least one protocol data unit (PDU) having a fixed size; and means for determining a buffer status of the terminal device based on the number of the at least one PDU and the fixed size.

In a seventh aspect, there is provided a non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the method according to the above third or fourth aspect.

In an eighth aspect, there is provided a computer program product comprising program instructions for performing at least the method according to the above third or fourth aspect.

In a ninth aspect, there is provided a computer program comprising instructions, which, when executed by an apparatus, cause the apparatus at least to perform at least the method according to the above third or fourth aspect.

In a tenth aspect, there is provided a terminal device. The terminal device comprises: constructing circuitry configured to construct at least one protocol data unit (PDU) having a fixed size; and transmitting circuitry configured to transmit, to a network device, information on a number of the at least one PDU available for transmission.

In an eleventh aspect, there is provided a network device. The network device comprises: receiving circuitry configured to receive, from a terminal device, information on a number of at least one protocol data unit (PDU) having a fixed size; and determining circuitry configured to determine a buffer status of the terminal device based on the number of the at least one PDU and the fixed size.

It is to be understood that the summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.

BRIEF DESCRIPTION OF THE DRAWINGS

Some example embodiments will now be described with reference to the accompanying drawings, in which:

Fig. 1A illustrates an example communication system in which embodiments of the present disclosure may be implemented;

Fig. 1B illustrates a schematic diagram illustrating different types of user equipments;

Fig. 1C illustrates a schematic diagram illustrating a 6G radio protocol stack structure for the user plane in which embodiments of the present disclosure may be implemented;

Fig. 1D illustrates a schematic diagram illustrating a RPU management in which embodiments of the present disclosure may be implemented;

Fig. 1E illustrates a schematic diagram illustrating a dual stack operation in which embodiments of the present disclosure may be implemented;

Fig. 2 illustrates an example signaling chart of an example process according to some embodiments of the present disclosure;

Fig. 3 illustrates a schematic diagram illustrating a signaling flow of BSR and allocation grant based on fixed-size RPU PDUs according to some embodiments of the present disclosure;

Fig. 4 illustrates a schematic diagram illustrating strategies for fixed-size RPU PDUs preparation according to some embodiments of the present disclosure;

Fig. 5A and Fig. 5B illustrate schematic diagrams illustrating scalable RPU PDU sizes according to some embodiments of the present disclosure;

Fig. 6 illustrates a schematic diagram illustrating a signaling flow of BSR and allocation grant based on based on UE-driven scaling of RPU PDU sizes according to some embodiments of the present disclosure;

Fig. 7 illustrates a schematic diagram illustrating an example of a BSR MAC CE according to some embodiments of the present disclosure;

Fig. 8 illustrates a schematic diagram illustrating a method implemented at a terminal device according to some embodiments of the present disclosure;

Fig. 9 illustrates a schematic diagram illustrating a method implemented at a network device according to some embodiments of the present disclosure;

Fig. 10 illustrates a simplified block diagram of an apparatus that is suitable for implementing embodiments of the present disclosure; and

Fig. 11 illustrates a block diagram of an example computer readable medium in accordance with some embodiments of the present disclosure.

Throughout the drawings, the same or similar reference numerals represent the same or similar element.

DETAILED DESCRIPTION

Principles of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. The disclosure described herein can be implemented in various manners other than the ones described below.

In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

References in the present disclosure to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It shall be understood that although the terms “first” and “second” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another and do not limit the order of elements or steps. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and/or” includes any and all combinations of one or more of the listed terms.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and/or “including” , when used herein, specify the presence of stated features, elements, and/or components etc., but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof. As used herein, “at least one of the following: <a list of two or more elements> ” and “at least one of <a list of two or more elements> ” and similar wording, where the list of two or more elements are joined by “and” or “or” , mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

As used in this application, the term “circuitry” may refer to one or more or all of the following:

(a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and

(b) combinations of hardware circuits and software, such as (as applicable) :

(i) a combination of analog and/or digital hardware circuit (s) with software/firmware and

(ii) any portions of hardware processor (s) with software (including digital signal processor (s) ) , software, and memory (ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and

(c) hardware circuit (s) and or processor (s) , such as a microprocessor (s) or a portion of a microprocessor (s) , that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

As used herein, the term “communication network” refers to a network following any suitable communication standards, such as Long Term Evolution (LTE) , LTE-Advanced (LTE-A) , Wideband Code Division Multiple Access (WCDMA) , High-Speed Packet Access (HSPA) , Narrow Band Internet of Things (NB-IoT) and so on. Furthermore, the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the future fifth generation (5G) , the sixth generation (6G) communication protocols, and/or any other protocols either currently known or to be developed in the future. Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.

As used herein, the term “network device” refers to a node in a communication network via which a terminal device accesses the network and receives services therefrom. The network device may refer to a base station (BS) or an access point (AP) , for example, a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , a NR NB (also referred to as a gNB) , a Remote Radio Unit (RRU) , a radio header (RH) , a remote radio head (RRH) , a relay, a low power node such as a femto, a pico, and so forth, depending on the applied terminology and technology.

The term “terminal device” refers to any end device that may be capable of wireless communication. By way of example rather than limitation, a terminal device may also be referred to as a communication device, user equipment (UE) , a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , or an Access Terminal (AT) . The terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA) , portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , USB dongles, smart devices, wireless customer-premises equipment (CPE) , an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD) , a vehicle, a drone, a medical device and applications (e.g., remote surgery) , an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts) , a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. In the following description, the terms “terminal device” , “communication device” , “terminal” , “user equipment” and “UE” may be used interchangeably.

Some embodiments may relate to PDU transmissions. Generally, PDUs for transmission may be prepared with various sizes. Buffer status report (BSR) is a well-known medium access control (MAC) procedure that tells the network how much data the UE has buffered for transmission. The flexible PDU sizes and the byte-level BSR may result in higher power consumption and low processing speed, especially for high bitrate services. A scheme for PDU transmissions with a fixed size may be designed. Further studies on such scheme are still needed.

Some example embodiments of the present disclosure provide a solution on transmission of PDUs with a fixed size. Especially, a UE receives an indication indicative of at least one PDU size. The UE constructs at least one PDU having a fixed size. The fixed size is associated with the at least one PDU size. The UE transmits, to the network device, information on a number of the at least one PDU available for transmission. The UE receives, from the network device, an indication indicative of resource allocation; and transmits, to the network device, at least a portion of the at least one PDU based on the resource allocation. In this way, the power efficiency and processing speed may be improved since the processing complexity may be reduced and the PDUs may be constructed before the resource allocation is known.

Embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. Reference is first made to Fig. 1A, which illustrates an example communication system 100 in which embodiments of the present disclosure may be implemented. The system 100 includes a terminal device 110 and a network device 120. The terminal device 110 is capable of connecting and communicating in an UL and/or DL with the network device 120. In communication systems, an UL refers to a link in a direction from a terminal device 110 to a network device 120, and a DL refers to a link in a direction from the network device 120 to the terminal device 110. The network device 120 may transmit scheduling information scheduling uplink resources for an uplink transmission to the terminal device 110, and the terminal device 110 may transmit a plurality of repetitions of the uplink transmission to the network device 120.

Communications in the communication system 100 may be implemented according to any proper communication protocol (s) , comprising, but not limited to, cellular communication protocols of 1G, 2G, 3G, 4G, 5G, 6G and on the like, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) 802.11 and the like, and/or any other protocols currently known or to be developed in the future. Moreover, the communication may utilize any proper wireless communication technology, comprising but not limited to: Code Division Multiple Access (CDMA) , Frequency Division Multiple Access (FDMA) , Time Division Multiple Access (TDMA) , Frequency Division Duplex (FDD) , Time Division Duplex (TDD) , Multiple-Input Multiple-Output (MIMO) , Orthogonal Frequency Division Multiple (OFDM) , Discrete Fourier Transform spread OFDM (DFT-s-OFDM) and/or any other technologies currently known or to be developed in the future.

It is to be understood that the numbers of devices (i.e., the terminal device 110 and the network device 120) and their connection relationships and types shown in Fig. 1A are only for the purpose of illustration without suggesting any limitation. For example, the communication system 100 may include any suitable numbers of devices adapted for implementing embodiments of the present disclosure. For example, while Fig. 1A depicts the terminal device 110 as a mobile phone, the terminal device 110 may be any type of user equipment.

Some embodiments of the present disclosure may be applied based on a design of a dual stack radio protocol. Hereinafter, the term “dual stack” may be interchangeably used with the term “dual configuration” or “dual track” . For example, in a design of 6G radio protocol, there may be two stacks (or two configurations) . The first radio protocol stack may be referred to as an anchor protocol stack (APS) . The second radio protocol stack may be referred to as a fast protocol stack (FPS) . Other terms for the protocol stacks are also possible. The APS may be designed for low bitrate services, coverage (e.g., bit-level optimizations) and reliability (e.g., radio link control (RLC) automatic repeat request (ARQ) ) . The FPS may be designed for high bitrate services, where the focus is on a processing-friendly and parallel processing implementation-friendly design employing the concept of radio processing units (RPUs) , enabling parallel processing of the radio functions.

With the dual stack radio protocol, the complex mechanisms and optimizations that are fully justified for low bitrate services need not be used for very high bitrate services. A simple device may only implement the first stack (i.e., the APS) , possibly removing the need to introduce the equivalent of machine type communications (MTC) , narrowband internet of things (NB-IoT) and reduced capability (RedCap) . A more complex and capable device would implement both stacks (i.e., both the APS and the FPS) . The higher the bitrates the device supports, the larger the number of RPUs the FPS would incorporate. Fig. 1B illustrates a schematic diagram illustrating different types of user equipments (UEs) . As shown in Fig. 1B, the UE 110-1 may only implement the APS, and the UEs 110-2 and 110-3 may implement both the APS and the FPS comprising one or more RPUs. As an example, four RPUs may be incorporated in the FPS of the UE 110-2; and eight RPUs may be incorporated in the FPS of the UE 110-3. The hardware implementation of the RPUs may indicate certain data throughput capabilities for the UE. The UE 110-1 may be a low-cost UE and the UE 110-3 may be a high-end UE. The UEs in Fig. 1B may be specific examples of the UE 110 in Fig. 1A. Other types of UEs are also possible.

On the transmitter side, one common layer needs to oversee the allocation of incoming service data units (SDUs) to each RPU. To maximize the number of tasks that can be executed in parallel, the common layer for allocation of incoming SDUs to each RPU needs to be located as high up in the radio protocols as possible. One candidate layer is the higher part of the packet data convergence protocol (PDCP) layer, after sequence number (SN) allocation but before other functions such as security and header compression. This allows these other functions to be performed in parallel on each RPU while allowing the receiver to re-order the SDUs coming out of the RPUs. Fig. 1C illustrates a schematic diagram illustrating a 6G radio protocol stack structure 130 for the user plane in which embodiments of the present disclosure may be implemented. The PDCP layer may be divided into a PDCP-high (PDCP-HI) layer and a PDCH-low (PDCP-LOW) layer. The service data adaptation protocol (SDAP) layer, the PDCP-HI layer and the physical (PHY) layer may be common layers for the APS and the FPS. The PDCP-LOW layer, the RLC layer and the MAC layer may be different for the APS and the FPS. In some implementations, the PDCP-LOW layer, the RLC layer and the MAC layer for the FPS may enable lower complexity and fast operation.

To maximize the power saving gains made possible by the RPU framework, the number of RPUs that are activated can be adjusted according to the instantaneous bitrate or load to be provided. Fig. 1D illustrates a schematic diagram illustrating a RPU management in which embodiments of the present disclosure may be implemented. In the example of Fig. 1D, a total of four RPUs are assumed to be available. The higher the instantaneous load is provided, the more RPUs are activated.

Depending on whether the RPUs share a common memory and how they are activated, it is possible that some RPU management schemes would require specific mechanisms to be introduced in standards. For instance, if the RPUs operate on segregated memory resources, it is likely that each RPU would then host its own transmission and reception windows, thus impacting sequence numbers and status reports management. Conversely, RPUs operating on shared resources would allow common windows to be used, with no impact to sequence numbers or status reports.

Being always present, the APS is a logical host for the control plane functions such as idle mode, connect mode and related configurations of the radio resource control (RRC) . By containing all control plane (CP) functions within the APS, not only is the FPS free to focus on user plane transfer for a simplified design, but it needs not to be active when the bitrate requirements are low.

As mentioned above, BSR is a well-known MAC procedure that tells the network how much data the UE has buffered for transmission. The BSR of the APS may be expected to follow that of previous generations, e.g., the BSR in 5G, and may be referred to as A-BSR. For FPS, a BSR format may be expected to facilitate operation with hardware optimized L2 implementation allowing much higher bit rates, possibly cope with fixed-size PDUs per RPU, and potentially support reporting the amount of data buffered per RPU. Some example embodiments of the present disclosure provide a solution for an enhanced mechanism for deriving and reporting to the gNB advanced UL scheduling assistance information in case of fixed PDU size per RPU.

The operation with the dual stack radio protocol with fixed PDU size per RPU may be described with reference to Fig. 1E. Fig. 1E illustrates a schematic diagram illustrating a dual stack operation 140 in which embodiments of the present disclosure may be implemented. In the example dual stack operation 140 in Fig. 1E, it is assumed that data splitting is performed in the PDCP layer at transmitter side. In the 6G dual stack radio protocol with APS and FPS, RPUs may be incorporated to handle high data rates. Concatenation/segmentation of IP packets into fixed size PDCP PDUs may be performed at the PDCP-HI layer (i.e., outside of the RPUs) or at the PDCP-LOW layer (i.e., within a RPU) with the assumption of data routing to RPUs at PDCP layer. In some implementations, concatenation/segmentation of IP packets into fixed size PDUs could also be performed entirely at RLC, or jointly between PDCP and RLC. The PDCP-LOW may also apply encryption/ciphering/integrity protection. In the example in Fig. 1E, the MAC layer may be divided into a MAC-high (MAC-HI) layer and a MAC-low (MAC-LOW) layer. The MAC-LOW layer may be a common layer for the APS and the FPS. The MAC-HI layer may be different for the APS and the FPS. At each transmission time interval (TTI) , in response to a request by the MAC (-LOW) layer, an RPU delivers to the MAC (-LOW) layer a set of fixed size RLC PDUs that are multiplexed in one transport block (TB) . Each RPU may be required to provide indication indicative of buffered data to MAC (-LOW) for data volume determination (for BSR) at MAC, which may be comparable to MAC requesting data volume information from each PDCP/RLC entities.

Assuming each RPU provides fixed-size PDUs to MAC (-LOW) and the gNB knows that size, byte level BSR reporting is unnecessary and suboptimal. A solution may be to change the meaning of the BSR table from number of bytes to number of fixed-size PDUs. Further studies for such solution are still needed. It should be understood that the dual stack architecture in Figs. 1B-1E are merely for illustration, examples of the present disclosure may also apply to other architectures.

Fig. 2 illustrates an example signaling chart illustrating an example process 200 according to some embodiments of the present disclosure. For the purpose of discussion, the example 200 will be described with reference to Fig. 1A, and the process 200 may involve the terminal device 110 and the network device 120 as shown in Fig. 1A. It would be appreciated that although the process 200 has been described in the communication system 100 of Fig. 1A, this process may be likewise applied to other communication scenarios.

As shown in Fig. 2, the terminal device 110 constructs (or prepares or generates) (202) at least one PDU. The at least one PDU has a fixed size. The terminal device 110 transmits (204) , to the network device 120, information 206 indicating a number of the at least one PDU available for transmission. The network device 120 receives (208) the information 206 indicating the number from the terminal device 110 and may determine (210) a buffer status of the terminal device 110 based on the number of the at least one PDU and the fixed size. In this way, the terminal device may report the buffer status value by indicating the number of fixed-size PDUs available for transmission, which improves the power efficiency and processing speed.

In some embodiments, the information 206 indicating the number of the at least one PDU available for transmission may be included in a report of buffer status information. In a specific example, the information 206 indicating the number of the at least one PDU with the fixed size may occupy 5 bits in a BSR and the reportable range of the number is 0-31. The size of the information 206 may be changed according to the reportable range of the number.

In some embodiments, the fixed size may be predefined. Alternatively, the terminal device 110 may receive, from the network device 120, an indication indicative of the fixed size. In other words, the network device 120 may configure the fixed PDU size for the terminal device 110. A specific example implementation selecting the RPU PDU size by the network device 120 is illustrated below in “Example derivation of RPU PDU size” . The terminal device 110 may construct PDUs having the fixed PDU size configured by the network device 120. The reportable buffer range the terminal device 110 may correspond to a product of the fixed size and the maximum reportable number of fixed-size PDUs. For example, if a 5-bit field is used for indicating the number of fixed-size PDUs, the range of the number of fixed-size PDUs that can be reported is 0-31, and the maximum reportable number is 31. In some embodiments, the at least one fixed PDU size for the terminal device 110 may be predefined or specified in the specifications.

In some embodiments, the terminal device 110 may receive an indication indicative of at least one PDU size from the network device 120 and select the fixed size from the at least one PDU size. The terminal device 110 may transmit value information indicative of the fixed size to the network device 120. In other words, if the network device 120 indicates multiple candidate PDU sizes to the terminal device 110, the terminal device 110 may select one PDU size for constructing PDUs and report the selected PDU size to the network device 120. For example, when transmitting the information 206 indicating a number of the at least one PDU available for transmission to the network device 120, the terminal device 110 may transmit the value information indicative of the fixed size selected from the at least one PDU size to the network device 120.

Assuming that APS communication has been ongoing for some time and channel quality measurements or channel status measurements are available. It is also assumed that the signal to interference noise ratio (SINR) of the terminal device 110 is good enough to support a smallest possible fixed RPU PDU size. It is noted that the terminal device 110 may not actually have to have data to send. The terminal device 110 may check its supported RPU PDU sizes. In some implementations, the supported RPU PDU sizes may be a subset of the predefined PDU sizes specified in standards. The terminal device 110 may calculate the bandwidth (BW) required for each RPU PDU size supported per TTI based on the average modulation and coding scheme (MCS) locally stored. The terminal device 110 may check that the BW can be supported based on its power headroom. Then, the terminal device 110 may select the first RPU PDU size (i.e., the smallest RPU PDU size) from the list of supported RPU PDU sizes.

Other inputs to enhance the RPU PDU size decision by the terminal device 110 are also possible. For example, the terminal device 110 may have some traffic information on the volume of traffic coming over the FPS (for example XR awareness signalling over user assistance information (UAI) ) . Since the terminal device 110 knows its SDU size, the terminal device 110 can select a larger RPU PDU size instead of the smallest one, so as to avoid too much padding/segmenting. Such algorithm is given for illustration without suggesting any limitation. Additional inputs to the algorithm are also possible. Other algorithms are also possible.

In some embodiments, the number of the at least one PDU available for transmission is determined based on data buffered in the terminal device 110. For example, if multiple processing units of the terminal device are activated and the same fixed size is configured or determined for the activated processing units, the terminal device may determine the total number of PDUs available for transmission in the activated processing units and report the total number to the network device 120. The processing unit may be implemented as a RPU in Figs. 1B-1E. Other types of RPUs are also possible. The reportable buffer range of a processing unit of the terminal device 110 may correspond to a product of the fixed size and the maximum reportable number of fixed-size PDUs.

In some embodiments, the at least one PDU size may be associated with at least one processing unit of the terminal device 110. The fixed size is one among the at least one PDU size and is associated with one among the at least one processing unit. In some implementations, the terminal device 110 may receive, from the network device 120, an indication indicative of the at least one PDU size associated with the at least one processing unit. Alternatively, the at least one PDU size associated with the at least one processing unit may be determined by the terminal device 110 or predefined. The terminal device 110 may determine at least one PDU number. Each of the at least one PDU number is a number of at least one PDU having a corresponding PDU size determined based on data buffered in a corresponding processing unit. When transmitting (204) the information 206 indicating the number of the at least one PDU available for transmission, the terminal device 110 may transmit, to the network device 120, information indicative of at least one PDU number associated with the at least one processing unit. In other words, respective fixed PDU sizes may be configured or determined for PDU construction in each processing unit of the terminal device 110. The terminal device 110 may report the respective PDU number for each processing unit. The reportable buffer range of a processing unit of the terminal device 110 may correspond to a product of the fixed PDU size corresponding to the processing unit and the maximum reportable number of fixed-size PDUs.

In some embodiments, the terminal device 110 may transmit, to the network device 120, value information indicative of the at least one PDU size associated with the at least one processing unit. In an example, the network device 120 may configure a set of PDU sizes for the terminal device 110 and the terminal device 110 may select a respective PDU size for each processing unit from the set of PDU sizes. In another example, the network device 120 may configure a respective set of PDU sizes for each processing unit of the terminal device 110 and the terminal device 110 may select a respective PDU size for each processing unit from the respective set of PDU sizes. When reporting the respective PDU number for each processing unit, the terminal device 110 may also transmit the respective fixed PDU sizes based on which the PDUs in each processing units are constructed.

In some embodiments, the terminal device 110 may obtain a scaling factor. For example, the terminal device 110 may determine the scaling factor at least based on a base PDU size and determine the fixed size based on the base PDU size and the scaling factor. The base PDU size may also be referred to as a reference PDU size. The terminal device 110 may transmit the scaling factor to the network device 120. In some implementations, the terminal device 110 may receive an indication indicative of the base PDU size from the network device 120. Alternatively, the base PDU size may be determined by the terminal device 110 or predefined. For example, when transmitting the information 206 indicating the number of the at least one PDU available for transmission to the network device 120, the terminal device 110 may transmit the scaling factor to the network device 120. The network device 120 may be able to determine the buffer status of the terminal device 110 based on the scaling factor and the number of the at least one PDU available for transmission reported by the terminal device 110 as well as the base PDU size configured by the network device 120.

In some embodiments, the terminal device 110 may determine a number x₀ of PDUs having the base PDU size based on data buffered in at least one processing unit of the terminal device 110. If the number x₀ exceeds a maximum reportable number, the terminal device may determine the scaling factor and thus determine the fixed size based on the base PDU size and the scaling factor. If the number x₀ does not exceed the maximum reportable number, the fixed size may be equal to the base PDU size. The reportable buffer range based on the a scalable PDU size may be increased. In this way, the reportable buffer range may be dynamically adapted to the immediate data traffic variability, the flexibility of such scheme may be increased without increasing the overhead of the network device.

In some embodiments, at least one base PDU size may be associated with at least one processing unit of the terminal device 110. The terminal device 110 may determine at least one scaling factor associated with the at least one processing unit at least based on the at least one base PDU size, determine at least one PDU size associated with the at least one processing unit based on the at least one base PDU size and the at least one scaling factor. The fixed size is one among the at least one PDU size and is associated with one among the at least one processing unit. In some implementations, the terminal device 110 may receive an indication indicative of the at least one base PDU size associated with the at least one processing unit of the terminal device 110 from the network device 120. Alternatively, the at least one base PDU size associated with the at least one processing unit may be determined by the terminal device 110 or predefined. The terminal device 110 may determine at least one PDU number. Each of the at least one PDU number is a number of at least one PDU having a corresponding PDU size determined based on data buffered in a corresponding processing unit. In this case, the PDU size may be fixed as one value per a processing unit. When transmitting information 206 indicating the number of the at least one PDU available for transmission, the terminal device 110 may transmit, to the network device 120, information indicative of the at least one PDU number and the at least one scaling factor associated with the at least one processing unit.

In other words, a corresponding PDU size may be determined for each processing unit of the terminal device based on the respective base PDU size and the respective scaling factor. For a corresponding processing unit among the at least one processing unit, the terminal device 110 may determine a corresponding number x₀ of at least one PDU having a corresponding base PDU size based on data buffered in the corresponding processing unit. For the corresponding processing unit among the at least one processing unit, if the corresponding number x₀ exceeds a maximum reportable number, the terminal device may determine a scaling factor associated with the corresponding processing unit and thus determine the corresponding fixed PDU size based on the corresponding base PDU size and the corresponding scaling factor. If the corresponding number x₀ does not exceed the maximum reportable number, the corresponding fixed PDU size may be equal to the corresponding base PDU size.

In some embodiments, the network device 120 may determine the resource allocation based on buffer status of the terminal device 110. For example, the network device 120 may determine the resource allocation based on the information 206. In this way, a link between buffer status reporting by the terminal device and the resource scheduling by the network device may be established via the mutual agreement on a quasi-static PDU size. The network device 120 may determine a size of the resource allocation based on at least one of the following: the information 206 indicating the number of the at least one PDU; a modulation and coding scheme (MCS) ; or physical resource blocks (PRBs) . The size of the resource allocation may be smaller than the buffer status value indicated by the information 206.

In some embodiments, the network device 120 may transmit an indication indicative of resource allocation to the terminal device 110. The terminal device 110 may transmit at least a portion of the constructed fixed-size PDU (s) to the network device 120.

In some embodiments, the terminal device 110 may construct PDUs having the fixed PDU size configured by the network device 120 or selected by the terminal device 110. The number of the at least one PDU available for transmission is determined based on data buffered in at least one processing unit of the terminal device 110. A target size of the resource allocation determined by the network device 120 may be an integer multiple of the fixed size, and the integer is no greater than the number of the at least one PDU available for transmission. In a specific example, the fixed PDU size is X, the reported number of the at least one PDU available for transmission is x, and the size of the resource allocation is A=aX, where a is an integer no greater than x. This is not always necessary. In some implementations, the size of the resource allocation is as close as possible to an integer multiple of the fixed PDU size but does not exceed the buffer status value reported by the terminal device.

In some embodiments, the terminal device 110 may construct PDUs having respective fixed PDU sizes in each processing unit. The respective fixed PDU sizes may be configured by the network device 120 for PDU construction in each processing unit of the terminal device 110. The terminal device 110 may report the respective PDU number for each processing unit. Alternatively, the respective fixed PDU sizes may be determined by the terminal device 110 based on respective scaling factors and respective base PDU sizes for the processing units. The terminal device 110 may report the respective PDU number and the respective scaling factor for each processing unit. The network device 120 may determine the resource allocation based on the respective PDU numbers and the respective fixed PDU sizes for the processing units. A target size of the resource allocation determined by the network device 120 is a sum of a product of the respective fixed PDU sizes and corresponding integers, and the corresponding integers are not greater than the respective PDU numbers, respectively. In other words, the size of the resource allocation is as close as possible to a sum of a product of the respective fixed PDU sizes and corresponding integers but does not exceed the buffer status value reported by the terminal device.

In some embodiments, the network device 120 may determine to activating at least one processing unit of the terminal device 110 supporting a fixed PDU size and transmit, to the terminal device 110, an indication indicative of activating the at least one processing unit of the terminal device 110. The network device 120 may determine to activating at least one processing unit of the terminal device 110 supporting a fixed PDU size based on various conditions, for example but not limited to, a data rate related to the terminal device 110 exceeds a nominal data rate; a power condition of the terminal device 110 satisfies a power requirement; a throughput of the terminal device 110 satisfies a throughput requirement; or the terminal device 110 supports a MCS in terms of achievable signal to interference plus noise ratio (SINR) .

In some embodiments, the terminal device 110 may transmit capability information to the network device 120. The capability information may include an indication indicative of a capability of supporting a fixed PDU size. For example, the network device may be aware that the terminal device 110 may support constructing PDUs with a fixed size and reporting the number of PDUs available for transmission in the BSR instead of reporting the number of bytes. Alternatively or additionally, the capability information may include an indication indicative of a set of PDU sizes supported by the terminal device 110. The network device 120 may thus configure the fixed size or candidate PDU sizes for the terminal device from the set of PDU sizes supported by the terminal device 110. An ordering in the set of PDU sizes is indicative of a priority of the set of PDU sizes. Alternatively or additionally, the capability information may include an indication indicative of at least one subset of fixed PDU sizes supported by at least one processing unit of the terminal device 110. The network device 120 may thus configure the fixed size or candidate PDU sizes for a processing unit from the set of PDU sizes supported by the processing unit.

In some embodiments, the network device 120 may determine the fixed size for the terminal device 110 to perform PDU construction. Alternatively, the network device 120 may determine at least one PDU size for the terminal device 110 to select the fixed size for PDU construction. Alternatively, the network device 120 may determine at least one PDU size for corresponding processing unit (s) of the terminal device 110 to perform PDU construction. Alternatively, the network device 120 may determine a base PDU size for the terminal device 110 to determine a scaling factor (if needed) and perform PDU construction. Alternatively, the network device 120 may determine at least base PDU size for corresponding processing unit (s) of the terminal device 110 to determine corresponding scaling factor (s) (if needed) and perform PDU construction.

In some embodiments, such size determination may be performed based on a channel condition between the terminal device 110 and the network device 120. Alternatively or additionally, such size determination may be performed based on a power headroom of the terminal device 110. Alternatively or additionally, such size determination may be performed based on a load of the network device 120. Alternatively or additionally, such size determination may be performed based on traffic information of the terminal device 110. Alternatively or additionally, such size determination may be performed based on a power cost function of padding versus segmenting of the terminal device 110. Alternatively or additionally, such size determination may be performed based on the capability information of the terminal device 110.

In some embodiments, the network device 120 may determine the fixed size for the terminal device 110 or for a corresponding processing unit of the terminal device 110. When determining the fixed size, the network device may determine a group of PDU sizes and determine the fixed size as a smallest one in the group of PDU sizes.

In some embodiments, the network device 120 may determine the base PDU size for the terminal device 110 or for a corresponding processing unit of the terminal device 110. When determining the base PDU size, the network device may determine a group of PDU sizes and determine the base PDU size as a smallest one in the group of PDU sizes.

In some embodiments, the terminal device 110 may receive, from the network device 120, an indication indicative of a strategy for PDU construction, and allocate packets to at least one PDU based on the strategy for PDU construction. If the strategy for PDU construction is a first strategy, when allocating the packets to the at least one PDU based on the strategy for PDU construction, the terminal device 110 may pad each of the packets to an individual PDU. If the strategy for PDU construction is a second strategy, when allocating the packets to the at least one PDU based on the strategy for PDU construction, the terminal device 110 may concatenate the packets and segment the concatenated packets to the at least one PDU. The strategy may be a method or a scheme to construct the PDU by the terminal device 110.

Fig. 3 illustrates a schematic diagram illustrating a signaling flow 300 of BSR and allocation grant based on fixed-size RPU PDUs according to some embodiments of the present disclosure. The flow 300 may be a more specific example of the process 200 of Fig. 2. The terminal device 110 may be called as UE and the network device 120 may be called as gNB for short.

At 301, at the beginning of the connection between the UE 110 and the gNB 120, the UE 110 may send an FPS capability report in an analogous manner with any other capability reporting. There may be many different capability reports for the FPS. Embodiments of the present disclosure may focus on the capabilities relevant to BSR. Alternatively or additionally, the FPS capability report may be only on the capability relevant to the BSR. In some embodiments, the UE 110 may declare that it can perform APS/FSP stack splitting with fixed RPU PDU sizes for the FPS.

In some implementations, the RPU may be a specific piece of dedicated hardware. The sizes of the RPU input buffer and the RPU output buffer may be a relevant capability for the possible fixed RPU PDU sizes to be supported by the RPU. Every piece of CPU hardware may have a certain size of an input buffer where data can come in for processing by whatever software is running on it. The CPU hardware may be implemented as a processor of the UE. In digital signal processor (DSP) terms, the size of an input buffer may be register sizes and count of registers. If the program does not run to advance this data, then after a certain of bytes, the buffer will be full and it is not able to put more data in the buffer without overwriting. Typically, the buffers are much bigger than one specific typical write operation. In some embodiments, this input buffer may take e.g., 1500 bytes so that (at least) one IP packet may be written. In an example, there may be 1MByte of input buffer, then 900 bytes or so IP packets may be fixed, and more than 1MBytes PDU sizes may be probably not supported. Similar principles may apply to the output buffer.

At 302, the gNB 120 may instruct the UE 110 to activate the FPS. In some implementations, this is expected to be enabled when data rates exceed some nominal value and power and/or throughput requirements for FPS enablement are satisfied.

At 303, the gNB 120 may check the channel conditions between the UE 110 and the gNB 120 e.g., based on CSI/CQI information and/or received UL signals. The channel conditions may be an input towards the decisions at step 305. At 304, the gNB 120 may check the UL power conditions of the UE 110, e.g., based on a power headroom reporting (PHR) . The UL power conditions may be an input towards the decisions at step 305.

At 305, the gNB 120 may be tasked to evaluate a suitable RPU PDU size X given a number of constraints from at least one of the UE capabilities (e.g., RPU capabilities) , channel conditions, UL power conditions and/or current load.

RPU PDU sizes

Examples of the RPU PDU sizes that can be considered suitable are given and not intended for limitation. For example, RPU PDU sizes can be the default IPv6 sizes of 1280 bytes, the default ethernetv2 sizes of 1500 bytes or the default jumbo frame of 9216 bytes. These sizes may apply to most internet traffic. For the purposes of illustration, the few bytes necessary for the RPU inner layers (e.g., PDCP-LOW, RLC, MAC-HI) are ignored.

In general, some embodiments of the present disclosure suited for 6G dual stack approach with high BW availability and high data rates with priority on high throughput and where at least power consumption and spectrum efficiency are less of a concern –after all, pushing Gbps assumes we have quite some spectra available. It is therefore envisioned that most of the time the RPU PDU size will be bigger than the maximum transmission unit (MTU) of the incoming traffic so that there will never be segmentation only of the incoming packets.

In some embodiments, the outcome of the decision at step 305 may be an RPU PDU size X to be signalled at step 306. If multiple RPUs are activated in the UE 110, the PDU size X indicated by the gNB 120 may apply to all the activated RPUs. There can be various different strategies by which the gNB determines the most suitable RPU PDU size. An example algorithm will now be explained.

Example derivation of RPU PDU size

Assuming that APS communication has been ongoing for some time; prior PHR and CQI/CSI reports are available; and the link adaptation (LA) has had enough time to adapt the modulation and coding scheme (MCS) . It is also assumed that the SINR of the UE 110 is good enough to support a smallest possible fixed RPU PDU size. In a specific example, a size of 1500 bytes (atypical MTU size) may be taken from possible RPU PDU sizes as the smallest RPU PDU size supported by the UE 110, meaning that given the current LA, MCS and PHR reported, the gNB 120 can allocate an approximate number of physical resource blocks (PRBs) . The UE 110 may support the MCS in terms of achievable SINR and may have enough power for the bandwidth required by the allocated PRBs. It should be noted that the UE 110 does not actually have to have data to send.

If these conditions are not satisfied at the moment of execution of step 305, then the enablement of the FPS stack with fixed RPU PDUs should be rejected and communication should be downgraded to APS only as the UE clearly does not support high data rates in the given average conditions.

With the above assumptions, at step 305, the gNB 120 may check the RPU PDU sizes that are supported by the UE 110. The RPU PDU sizes that are supported by the UE 110 may be reported by the UE 110 at step 301. For example, the supported RPU PDU sizes may be part of UE capabilities signalled to the gNB 120. In some implementations, the supported RPU PDU sizes may rely on a set of predefined PDU sizes (e.g., specified in standards) . For example, the supported RPU PDU sizes may be a subset of the predefined PDU sizes specified in standards. In some embodiments, the UE 110 may further express a preference on the supported RPU PDU sizes, for instance by ordering the PDU sizes from the most preferred to the least preferred.

The gNB 120 may calculate the BW required for each RPU PDU size supported per TTI based on the LA converged MCS. The gNB 120 may check that the BW can be supported based on the UE’s power headroom report. Then, the gNB 120 may select the first RPU PDU size (i.e., the smallest RPU PDU size) from the list of supported RPU PDU sizes.

Other inputs to enhance the decision at step 305 are also possible. For example, if the gNB has some traffic information on the volume of traffic coming over the FPS (for example XR awareness signalling over user assistance information (UAI) ) , the gNB can select a larger RPU PDU size instead of the smallest one, so as to avoid too much padding/segmenting. Alternatively or additionally, a power cost function of padding vs segmenting can be provided by the UE based on UE implementation as an input. The gNB may determine the RPU PDU size at least based on the power cost function of padding vs segmenting.

The above algorithm is given for illustration without suggesting any limitation. Additional inputs to the algorithm are also possible. Other algorithms are also possible.

In some embodiments, the outcome of the decision at step 305 may be multiple PDU sizes for the UE 110 to select and indicate. For example, the gNB 120 may determine a list of candidate RPU PDU sizes for the UE 110. If multiple RPUs are activated in the UE 110, the list of candidate RPU PDU sizes indicated by the gNB 120 may apply to all the activated RPUs. The UE 110 may select a candidate PDU size among the list of candidate PDU sizes. In this case, the selected RPU PDU size may be the same for the activated RPUs of the UE 110.

Alternatively, the gNB 120 may determine a PDU size for each RPU of the UE 110, e.g., a PDU size of X₁ for a first activated RPU, a PDU size of X₂ for a second activated RPU, etc. In other words, the PDU size may be determined per RPU so that each RPU has its own fixed size.

In some embodiments, the gNB 120 may determine a list of candidate PDU sizes for each RPU of the UE 110. The UE 110 may select one among the corresponding list of candidate PDU sizes for each RPU.

At 306, the size derived at step 305 is signalled over RRC or MAC CE or other suitable signalling to the UE 110. For example, size information indicative of a size value X may be signalled to the UE 110. In another example, the size information indicative of at least one size value per at least one RPU may be signalled to the UE 110 so that each RPU has its own fixed size. This can be used to have granular control of the possible allocation sizes. In a further example, a list of candidate size values may be signalled to the UE 110.

At 307, the UE 110 may use the signalled RPU PDU size to prepare fixed-size PDUs. In one example, if one RPU PDU size X is configured for the UE 110, the UE 110 may prepare PDUs having the PDU size X based on data buffered in the UE 110. For example, x PDUs having the PDU size X may be prepared.

There are various of strategies that can be used for constructing fixed-size PDUs. Example strategies for fixed-size RPU PDUs preparation may be illustrated in Fig. 4. An indication indicating a strategy (or a method) for fixed-size PDU construction to be used at step 307 may be signalled by the gNB 120, or left for UE implementation, or codified in a standard. In an example, the gNB 120 may select the desired strategy and the UE 110 can execute the strategy determined and indicated by the gNB 120. Availability of certain strategies may be subject to UE capability.

Fig. 4 illustrates a schematic diagram illustrating strategies for fixed-size RPU PDUs preparation according to some embodiments of the present disclosure. In the example of Fig. 4, packets 401, 402, 403, 404 and 405 come from the PDCP-HI layer and may be constructed to be fixed-size PDUs. In the first strategy 410, the five packets are padded to five fixed-size PDUs. The packet 401 is not padded. The packets 402, 403, 404 and 405 are padded with padded bits 412, 413, 414 and 415, respectively. In the second strategy 420, the five packets are concatenated and then segmented and only the last packet 405 is padded with padded bits 421. Four fixed-size PDUs are constructed. A combination of the first strategy 410 and the second strategy 420 is also possible. In the third strategy 430, the packets are concatenated and then segmented to PDUs having a larger fixed size. Only the last packet 405 is padded with padded bits 431. Two fixed-size PDUs are constructed. In the strategy 430, selecting a larger RPU PDU size can reduce the need for segmentation and in some cases provide potential reduced power consumption due to the reduced number of operations. This can be used by the gNB when weighing in RPU PDU sizes to request. In an example, the RPU PDU sizes in the strategy 410, in the strategy 420 and in the strategy 430 may be X bytes, X bytes and 2X bytes, respectively.

In some implementations, the strategies may be independently defined per RPU so that the gNB 120 can have better granular control of the PDUs prepared with the goal of better fitting the grant to the available data and transmission conditions. In an example, if the PDU size is configured per RPU (e.g, a PDU size of X₁ for a first activated RPU, a PDU size of X₂ for a second activated RPU, etc. ) , the UE 110 may prepare PDUs per RPU. For example, x₁ PDUs having the PDU size X₁ may be prepared for the first activated RPU, x₂ PDUs having the PDU size X₂ may be prepared for the second activated RPU, etc. In this case, the x1 PDUs and the x2 PDUs may be the RPU PDUs.

Referring back to Fig. 3, at 308, the UE 110 may indicate the number of available RPU PDUs in its buffer. Those available RPU PDUs can be ready PDUs or just data yet to be processed expressed as fixed-size RPU PDUs. The term "ready PDUs" herein may refer to PDUs that have been processed and lined up in the output buffer. Ideally, the ready PDUs only need to be transmitted and never have to be re-processed. The available BSR MAC CEs can be used with a change of the meaning so that the values reported are interpreted as integer number of fixed-size PRU PDUs instead of the number of bytes. This also means BSR tables are in fact not used and the quantization error associated with the BSR tables is now accounted for in the strategies for fixed-size RPU PDUs preparation. In one example, if x PDUs having the PDU size X are prepared, the UE 110 may indicate the number x. In another example, if two RPUs are activated, x₁ PDUs having the PDU size X₁ are prepared for the first activated RPU, and x₂ PDUs having the PDU size X₂ are prepared for the second activated RPU, the UE 110 may indicate the numbers x₁ and x₂ for the two activated RPUs. For the case where there are one or more candidate PDU sizes configured, the UE 110 may select a PDU size from the one or more candidate PDU sizes and indicate the selected PDU size and the number of PDUs corresponding to the selected PDU size.

At 309, the gNB 120 may grant (or allocate) resources for the PDU transmissions. When granting resources, the gNB 120 may allocate a size that matches as much as possible an integer number of fixed-size RPU PDUs, so to avoid padding at the UE 110. The grant may be smaller than the UE reported buffer status value due to channel conditions, power limitations or gNB load. For example, if the number x for the RPU PDU size X is indicated for the UE 110, the target resource allocation size may be A=aX where a≤x. In another example, if two RPUs of the UE 110 are activated and the numbers x₁ and x₂ for the RPU PDU sizes X₁ and X₂ are indicated for respective activated RPUs of the UE 110, the target resource allocation size may be A=a₁X₁+a₂X₂, where a₁≤x₁, a₂≤x₂. The UE 110 may then transmit at least part of the prepared RPU PDUs based on the granted resources.

At 310, with communication ongoing, the continuous and periodic re-evaluation of the conditions may be performed. For example, the gNB 120 may re-evaluate the buffer size, the power condition and the channel condition of the UE 110. Steps 311 to 314 may be performed in a similar manner as the steps 305-308. At 311, the gNB 120 may determine a suitable RPU PDU size Y. If the RPU PDU size Y is different from the RPU PDU size X signalled in step 306, at 312, the gNB 120 may signal the RPU PDU size Y to the UE 110. At 313, the UE 110 may prepare PDUs having the RPU PDU size Y. In some embodiments, the updated PDU size Y is an integer multiple of a previous size X, e.g., 2X=Y. Therefore, if there are prepared PDUs of the previous size X, the prepared PDUs having size X do not need to be re-processed due to the multiplicative relationship between the previous and updated PDU sizes. At 314, the UE 110 may indicate the number y of fixed-size RPU PDUs available in its buffer.

In this way, a link between the BSR reporting from the UE and the resource scheduling by the gNB is established via the mutual agreement on a quasi-static RPU PDU size. The fixed RPU PDU size may be adapted so that the gNB can allocate resources according to the channel conditions.

In the step 305 of Fig. 3, a small RPU PDU size may be selected, e.g., a minimum workable size for IP packets -e.g., 1500 bytes. The step 305 in Fig. 3 can be useful for initial channel condition and initial load conditions of the gNB, but those conditions might change as the UE moves in the environment or the gNB experiences a higher or lower load. It is therefore desirable to create a mechanism that is not rigid and the PDU size can gracefully change and adapt to the conditions. In some embodiments of the present disclosure, the fixed-size RPU PDUs is achieved by designing the RPU PDU sizes in sets of exponentially growing sizes. Selecting a small RPU PDU size initially and generally running with a RPU PDU size several times smaller than the currently possible allocation is desired to allow for graceful scaling of PDU sizes as described in “Scaling PDU sizes and filling a transport block” .

Scaling PDU sizes and filling a transport block

An example implementation of scaling PDU sizes is illustrated without suggesting any limitation. Other algorithms for PDU size scaling are also possible. In a specific example, it is supposed that the UE supports 1500, 3000, 6000 etc. bytes of PDU sizes. It is supposed the gNB starts with the smallest 1500 bytes, e.g., as described in “Example derivation of RPU PDU size” . The size of “1500 bytes” may be called the currently selected base PDU size (BASE PDU SIZE) . An example RPU PDU size scaling algorithm may be defined in equation (1) :
FIXED RPU PDU SIZE= BASE PDU SIZE×2^scaling ^factor (1)

where the scaling factor is a scaling factor between the base PDU size and may be signaled between the gNB and the UE.

Assume the scaling factor may be an integer in the range 0-7 which can be signalled with 3 bits only. For example, the UE may determine the scaling factor and report the scaling factor along with the number of fixed-size RPU PDUs to the gNB in the BSR. In this example, the scaling factor occupies 3 bits out of 8 bits in the BSR. Assume that the remaining 5 bits of the current long BSR are used to signal 0-31 number of fixed-size RPU PDUs. For example, the UE may report number x of the fixed-size PDUs and the scaling factor , indicating a buffer status value of FIXED RPU PDU SIZE×x=BASE PDU SIZE×2^scaling ^factor×x, where 0≤x≤31, 0≤scaling factor≤7 and the BASE PDU SIZE is previously signalled from the gNB to the UE.

With the above example algorithm (1) for a starting BASE PDU SIZE = 1500 bytes and scaling factor = 0, then FIXED RPU PDU SIZE=1500 bytes and the UE can report 0 to 46500 bytes buffered in chunks of 1500 bytes.

When the conditions improve suppose, then the scaling factor =4 , and the FIXED RPU PDU SIZE=24000 bytes. The range of reporting is then 0 to 744000 bytes in chunks of 24000 bytes.

It is possible to introduce offset range so that for higher scaling factor values, the reporting range for a scaling factor value starts from for example the middle of the reporting range for the previous scaling factor value. This can be represented in equation (2):

For example, when the UE report number y of the fixed-size PDUs and the scaling factor, the buffer status value may be represented in equation (3) :

where 0≤x≤31 , 0≤scaling factor≤7 and the FIXED RPU PDU SIZE may be defined based on equation (1) .

Fig. 5A and Fig. 5B illustrate schematic diagrams illustrating scalable RPU PDU sizes according to some embodiments of the present disclosure. The buffer status value is plotted for all scaling factors (up to 7) . In the example of Fig. 5A, the selected BASE PDU SIZE = 1500 . In the example of Fig. 5B, the selected BASE PDU SIZE = 6000.

In this way, no matter how the BASE PDU SIZE changes exponentially or no matter how the scaling factor changes, if the above scaling formulae is followed, the sizes of the RPU PDUs will always be an integer multiple of each other. This means that if the gNB assigns a large allocation, integer multiple of previously prepared PDUs can fit without the need of further actions.

In some embodiments, the parameters related to the scaling PDU sizes can be defined per RPU, so that the gNB always has coarse and fine grain control of the allocation. For example, the gNB may configure the parameter BASE PDU SIZE per RPU. Alternatively or additionally, the UE may determine the scaling factor per RPU. Thus, there may be a respective fixed PDU size FIXED RPU PDU SIZE for each RPU. The UE may construct PDUs with the respective fixed sizes and report the respective scaling factors and the respective PDU numbers per RPU to the gNB.

This graceful scaling can be initiated by both the gNB and the UE. For example, the gNB can configure the BASE PDU SIZE (with large scale variations based on known or predicted channel conditions) while the UE is tasked with determining the scaling factor (with small scale variations based on immediate data variability) .

Fig. 6 illustrates a schematic diagram illustrating a signaling flow of BSR and allocation grant based on based on UE-driven scaling of RPU PDU sizes according to some embodiments of the present disclosure. The flow 600 may be a more specific example of the process 200 of Fig. 2. The terminal device 110 may be called as UE and the network device 120 may be called as gNB for short. The same reference numerals are used to denote the elements or components described in Fig. 3 having the same operations as the elements or components described in Fig. 3, and detailed description thereof will be omitted.

At 605, the gNB 120 may be tasked to evaluate a suitable base PDU size given a number of constraints from the UE capabilities (e.g., RPU capabilities) , channel conditions, UL power conditions and/or current load. The step 605 may be performed in a similar manner as the step 305 in Fig. 3, and differ in that the size X is a BASE PDU SIZE determined by the gNB 120. In some embodiments, the BASE PDU SIZE X may be determined per RPU.

At 606, the gNB 120 transmits the BASE PDU SIZE X to the UE 110. At 607, the UE 110 may evaluate the internal buffer needs and select a suitable scaling factor. For example, the UE 110 knows best the current incoming traffic load and thus may be tasked with determining and signalling the scaling factor. At 608, the UE 110 may determine the FIXED RPU PDU SIZE as X×2^scaling ^factor. At 609, the UE may prepare PDUs having a size of the FIXED RPU PDU SIZE. At 610, the UE 110 may signal the number x of the PDUs having the size of the FIXED RPU PDU SIZE and the determined scaling factor to the gNB 120. At 611, the gNB may calculate the total signalled bytes and determine a resource allocation A for the UE. At 612, the gNB 120 may grant the resource allocation A for the PDU transmissions. When granting resources, the gNB 120 may allocate a size that matches as much as possible an integer number of fixed-size RPU PDUs, so to avoid padding at the UE 110. The grant can be smaller than the UE reported buffer status value due to channel conditions, power limitations or gNB load. The UE 110 may then transmit at least part of the prepared PDUs based on the granted resources.

At 613, the with communication ongoing, the continuous and periodic re-evaluation of the conditions may be performed. The gNB 120 may determine a suitable base PDU size Y. If the base PDU size Y is different from the base PDU size X signalled in step 606, at the gNB 120 may signal the base PDU size Y to the UE 110. At 614, the UE 110 may use the updated base PDU size Y to perform PDU size scaling. If the UE 110 does not receive an updated base PDU size, at 614, the UE 110 may re-evaluate the internal buffer needs and re-select a scaling factor, if needed, based on the base PDU size X.

In this way, additional padding is avoided, especially if the gNB is not aware of the RPU PDU size and/or cannot modify the RPU PDU size.

In some embodiment, the scaling factor may be carried in the same BSR MAC CE as the number of RPU PDUs. As demonstrated in “Scaling PDU sizes and filling a transport block” , this can be done within the same 8 bits currently available in the MAC CE. In this way, there is never an ambiguity as to what is being reported, although some extra calculations are required by the two sides.

It should be noted that the example here with 8-bit BSR field can be adapted to any other BSR format defined in 6G. The example BSR field here with a 3-bit scaling factor field and a 5-bit PDU number field is merely an example without suggesting any limitation.

In some embodiments, the FIXED RPU PDU SIZE in “Scaling PDU sizes and filling a transport block” and the method 600 is meant as the actual RPU PDU size to be prepared as well as the reported one. In other words, after determining the scaling factor, the UE may construct PDUs having a size of FIXED RPU PDU SIZE and report the number of the PDUs having the of FIXED RPU PDU SIZE available for transmission.

In some embodiments, the FIXED RPU PDU SIZE may be only the size for the BSR report scaling and the UE continues to always prepare RPU PDUs of the size BASE PDU SIZE . For example, if the UE constructs x₀ PDUs having a size of BASE PDU SIZE while the x is larger than the maximum reportable number 31, the UE may determine a scaling factor , then the buffer status value may be represented as BASE PDU SIZE×x₀=FIXED RPU PDU SIZE×x₁ , where 0≤x₁≤31 and the FIXED RPU PDU SIZE may be determined based on equation (1) . The UE may report the number x₁ and the scaling factor while still constructing RPU PDUs of the size BASE PDU SIZE. In such cases the gNB can still simply sum the bytes per LCG and grant based on that with no additional bookkeeping.

In case that the UE is solely responsible for selecting RPU PDU size from the configured values, an alternative example of BSR MAC CE may include an indication of the selected RPU PDU size and an indication of the number of RPUs with data in buffer. Fig. 7 illustrates a schematic diagram illustrating an example of a BSR MAC CE according to some embodiments of the present disclosure. In this example, the number of RPU PDU sizes configured by gNB is 32 and up to 8 RPUs can be supported. Assuming only one PDU is prepared for each active RPU. The number of active RPUs and the RPU PDU size may be determined based on data buffered in the UE. The gNB is able to determine the buffer status of the UE based on the number of active RPUs and the RPU PDU size.

With some embodiments of the present disclosure a link between the BSR reporting from the UE and the resource scheduling by the gNB is established via the mutual agreement on a quasi-static RPU PDU size. For example, under the APS/FPS dual stack operation, the link between the BSR reporting from the UE and the resource scheduling by the gNB via the mutual agreement on a quasi-static RPU PDU size may be considered for the FPS, where high data rates are required. It should be understood that the link between the BSR reporting from the UE and the resource scheduling by the gNB via the mutual agreement on a quasi-static RPU PDU size can also apply to any radio stack where fixed or quasi-static size PDUs can be deployed.

It may be assumed that the BSR is reported per LCG. In the scope of the FPS operation, one LCG can be mapped to one or more RPUs. The RPU or MAC or APS entities may prepare the BSR report. Although some embodiments of the present disclosure are illustrated with respect to UL operation, it is understood that some aspects of the present disclosure could equally apply to DL operation.

With some embodiments of the present disclosure, the UE may report the BSR as a set of numbers of PDUs of quasi-static sizes (also referred to as “RPU PDU size” or “PDU size” ) instead of the number of bytes. The gNB may schedule resources so that the resource allocation size is as close as possible to an integer number of said PDUs of quasi-static sizes. This is done to as much as possible avoid padding at the UE. It should be note that the gNB can still adjust to the current load and channel conditions. The agreement between gNB and UE on the RPU PDU size may be handled via RRC and MAC signalling, potentially per LCG. Alternatively, the UE may inform gNB about the RPU PDU size in the BSR. The agreed RPU PDU size may be valid until an updated agreement is in place if not explicitly indicated by the UE in the BSR. This mechanism allows for dynamic size of the resource reporting and grant based on channel/power conditions.

In some embodiments, the information about the RPU PDU size can be in the form of a pointer/index towards a known table of possible RPU PDU sizes. The table of possible RPU PDU sizes may be either specified, signalled by the UE or the gNB via RRC signalling, or even broadcasted by the gNB.

It could be configurable whether the PDU size is static, where only the number of PDUs is reported, or the UE is allowed to select the PDU size, where the UE can indicate the selected PDU size together with the number of PDUs. In some embodiments, there could be a limited number of PDU sizes configured by the network and the UE may indicate which PDU size is used.

The fixed RPU PDU size may be adapted so that the gNB can allocate resources according to the channel conditions. The signalling required for BSR table adjustment and comprehension may be designed. In addition, since the sizes of the RPU PDUs will always be an integer multiple of each other, if there be a need to change the fixed RPU PDU size, the previously prepared PDUs can fit the updated RPU PDU size without the need of further actions by the UE.

Operating with PDUs of quasi-static size makes it possible to prepare PDUs entirely offline without any knowledge of the actual gNB allocation. Operating with PDUs of quasi-static size is suited for high data rate continuous transmissions, where the potential overhead due to additional padding is negligible relatively to the large size allocations.

It should also be noted that while some embodiments of the present disclosure assume a dual stack approach relying on RPUs, the same principles could also be used in scenarios where only one stack is deployed without RPUs and where fixed PDU size (s) are used on the radio link.

Fig. 8 illustrates a schematic diagram illustrating a method 800 implemented at a terminal device according to some embodiments of the present disclosure. For the purpose of discussion, the method 800 will be described from the perspective of the terminal device 110 as shown in Fig. 1A.

As shown in Fig. 8, at block 810, the terminal device 110 constructs at least one protocol data unit (PDU) having a fixed size. At block 820, the terminal device 110 transmits, to a network device, information on a number of the at least one PDU available for transmission.

In some embodiments, the terminal device 110 may receive, from the network device, an indication indicative of the fixed size.

In some embodiments, the terminal device 110 may receive, from the network device, an indication indicative of at least one PDU size and select the fixed size from the at least one PDU size. The terminal device 110 may transmit, to the network device, value information indicative of the fixed size.

In some embodiments, the number of the at least one PDU may be determined based on data buffered in the terminal device.

In some embodiments, at least one PDU size may be associated with at least one processing unit of the terminal device 110. The fixed size is one among the at least one PDU size. The terminal device 110 may determine at least one PDU number. Each of the at least one PDU number is a number of at least one PDU having a corresponding PDU size determined based on data buffered in a corresponding processing unit. When transmitting information on the number of the at least one PDU available for transmission, the terminal device 110 may transmit, to the network device, information indicative of the at least one PDU number associated with the at least one processing unit.

In some embodiments, the terminal device 110 may receive, from the network device, an indication indicative of the at least one PDU size associated with the at least one processing unit. Alternatively, the terminal device 110 may transmit, to the network device, value information indicative of the at least one PDU size associated with the at least one processing unit.

In some embodiments, the terminal device 110 may determine a scaling factor at least based on a base PDU size and determine the fixed size based on the base PDU size and the scaling factor. The terminal device 110 may transmit, to the network device, the scaling factor.

In some embodiments, the terminal device 110 may receive, from the network device, an indication indicative of the base PDU size. In some embodiments, the terminal device 110 may determine a first number of at least one PDU having the base PDU size based on data buffered in the terminal device 110. The scaling factor may be determined in the case that the first number exceeds a maximum reportable number.

In some embodiments, at least one base PDU size may be associated with at least one processing unit of the terminal device 110. The terminal device 110 may determine at least one scaling factor associated with the at least one processing unit at least based on the at least one base PDU size; determine at least one PDU size associated with the at least one processing unit based on the at least one base PDU size and the at least one scaling factor. The fixed size is one among the at least one PDU size and is associated with one among the at least one processing unit. The terminal device 110 may determine at least one PDU number. Each of the at least one PDU number is a number of at least one PDU having a corresponding PDU size determined based on data buffered in a corresponding processing unit. When transmitting information on the number of the at least one PDU available for transmission, the terminal device 110 may transmit, to the network device, information indicative of the at least one PDU number and the at least one scaling factor associated with the at least one processing unit. In some embodiments, the terminal device 110 may receive, from the network device, an indication indicative of the at least one base PDU size associated with the at least one processing unit of the terminal device 110.

In some embodiments, for a corresponding processing unit among the at least one processing unit, the terminal device 110 may determine a corresponding first number of at least one PDU having a corresponding base PDU size based on data buffered in the corresponding processing unit. A scaling factor associated with the corresponding processing unit may be determined in the case that the corresponding first number exceeds a maximum reportable number.

In some embodiments, the terminal device 110 may receive, from the network device, an indication indicative of resource allocation; and transmit, to the network device, at least a portion of the at least one PDU based on the resource allocation. A target size of the resource allocation is an integer multiple of the fixed size, and the integer is no greater than the number of the at least one PDU available for transmission.

In some embodiments, the terminal device 110 may receive, from the network device, an indication indicative of resource allocation; and transmit, to the network device, at least a portion of the at least one PDU based on the resource allocation. A target size of the resource allocation is a sum of a product of the at least one PDU size and corresponding integers, and the corresponding integers are not greater than the at least one PDU number, respectively.

In some embodiments, the terminal device 110 may transmit, to the network device, capability information. The capability information may include an indication indicative of a capability of supporting a fixed PDU size. Alternatively or additionally, the capability information may include an indication indicative of a set of PDU sizes supported by the terminal device 110. Alternatively or additionally, the capability information may include an indication indicative of at least one subset of fixed PDU sizes supported by at least one processing unit of the terminal device 110. In some embodiments, an ordering in the set of PDU sizes may be indicative of a priority of the set of PDU sizes. In some embodiments, the information on the number of the at least one PDU available for transmission may be included in a report of buffer status information.

In some embodiments, the terminal device 110 may receive, from the network device, an indication indicative of a strategy for PDU construction; and allocate packets to the at least one PDU having the fixed size based on the strategy for PDU construction. In some embodiments, when allocating the packets to the at least one PDU based on the strategy for PDU construction, the terminal device 110 may pad each of the packets to an individual PDU in the at least one PDU having the fixed size in the case that the strategy for PDU construction is a first strategy. In some embodiments, when allocating the packets to the at least one PDU based on the strategy for PDU construction, the terminal device 110 may concatenate the packets and segmenting the concatenated packets to the at least one PDU having the fixed size in the case that the strategy for PDU construction is a second strategy.

With the method 800, the terminal device may report the buffer status value by indicating the number of fixed-size PDUs available for transmission, which improves the power efficiency and processing speed.

Fig. 9 illustrates a schematic diagram illustrating a method 900 implemented at a network device according to some embodiments of the present disclosure. For the purpose of discussion, the method 900 will be described from the perspective of the network device 120 as shown in Fig. 1A.

As shown in Fig. 9, at block 910, the network device 120 receives, from a terminal device, information on a number of at least one protocol data unit (PDU) having a fixed size. At block 920, the network device 120 determines a buffer status of the terminal device based on the number of the at least one PDU and the fixed size.

In some embodiments, the network device 120 may transmit, to the terminal device, an indication indicative of the fixed size.

In some embodiments, the network device 120 may transmit, to the terminal device, an indication indicative of at least one PDU size; and receive, from the terminal device, value information indicative of the fixed size.

In some embodiments, the number of the at least one PDU having the fixed size may be associated with data buffered in the terminal device.

In some embodiments, at least one PDU size is associated with at least one processing unit of the terminal device, the fixed size is one among the at least one PDU size and is associated with one among the at least one processing unit. When receiving information on the number of the at least one PDU available for transmission, the network device 120 may receive, from the terminal device, information indicative of the at least one PDU number associated with the at least one processing unit. Each of the at least one PDU number is a number of at least one PDU having a corresponding PDU size determined based on data buffered in a corresponding processing unit.

In some embodiments, the network device 120 may transmit, to the terminal device, an indication indicative of the at least one PDU size associated with the at least one processing unit.

In some embodiments, the network device 120 may receive, from the terminal device, value information indicative of the at least one PDU size associated with the at least one processing unit.

In some embodiments, the network device 120 may receive, from the terminal device, a scaling factor. The fixed size may be determined based on a base PDU size and a scaling factor. In some embodiments, the network device 120 may transmit, to the terminal device, an indication indicative of the base PDU size.

In some embodiments, at least one base PDU size may be associated with at least one processing unit of the terminal device. When receiving information on the number of the at least one PDU available for transmission, the network device 120 may receive, from the terminal device, information indicative of at least one PDU number and at least one scaling factor associated with the at least one processing unit. The network device 120 may determine at least one PDU size based on the at least one base PDU size and the at least one scaling factor. Each of the at least one PDU number is a number of at least one PDU having a corresponding PDU size determined based on data buffered in a corresponding processing unit. The corresponding PDU size may be determined based on a corresponding base PDU size and a corresponding scaling factor associated with the corresponding processing unit.

In some embodiments, the network device 120 may transmit, to the terminal device, an indication indicative of the at least one base PDU size associated with the at least one processing unit of the terminal device.

In some embodiments, the network device 120 may determine a resource allocation based on the buffer status; and transmit, to the terminal device, an indication indicative of resource allocation. A size of the resource allocation is determined based on at least one of the following: the information on the number of the at least one PDU; a modulation and coding scheme (MCS) ; or physical resource blocks (PRBs) .

In some embodiments, the network device 120 may determine a resource allocation based on the fixed size and the number of the at least one PDU available for transmission. A target size of the resource allocation is an integer multiple of the fixed size, and the integer is no greater than the number of the at least one PDU available for transmission.

In some embodiments, the network device 120 may determine a resource allocation based on the at least one PDU number and the at least one PDU size. A target size of the resource allocation is a sum of a product of the at least one PDU size and corresponding integers, and the corresponding integers are not greater than the at least one PDU number, respectively.

In some embodiments, the network device 120 may transmit, to the terminal device, an indication indicative of activating at least one processing unit of the terminal device supporting a fixed PDU size based on at least one of the following: a data rate related to the terminal device exceeding a nominal data rate; a power requirement being satisfied; a throughput requirement being satisfied; or the terminal device supporting a modulation and coding scheme (MCS) in terms of achievable signal to interference plus noise ratio (SINR) .

In some embodiments, the network device 120 may determine the fixed size based on at least one of the following: a channel condition between a terminal device and the network device 120; a power headroom of the terminal device; a load of the network device 120; traffic information of the terminal device; a power cost function of padding versus segmenting of the terminal device; or capability information of the terminal device.

In some embodiments, the network device 120 may determine the at least one PDU size based on at least one of the following: a channel condition between a terminal device and the network device 120; a power headroom of the terminal device; a load of the network device 120; traffic information of the terminal device; a power cost function of padding versus segmenting of the terminal device; or capability information of the terminal device.

In some embodiments, the network device 120 may determine the base PDU size based on at least one of the following: a channel condition between a terminal device and the network device 120; a power headroom of the terminal device; a load of the network device 120; traffic information of the terminal device; a power cost function of padding versus segmenting of the terminal device; or capability information of the terminal device.

In some embodiments, the network device 120 may determine the at least one base PDU size based on at least one of the following: a channel condition between a terminal device and the network device 120; a power headroom of the terminal device; a load of the network device 120; traffic information of the terminal device; a power cost function of padding versus segmenting of the terminal device; or capability information of the terminal device.

In some embodiments, the capability information may include at least one of the following: an indication indicative of a capability of supporting a fixed PDU size; an indication indicative of a set of PDU sizes supported by the terminal device; or an indication indicative of at least one subset of fixed PDU sizes supported by at least one processing unit of the terminal device. In some embodiments, an ordering in the set of PDU sizes is indicative of a priority of the set of PDU sizes.

In some embodiments, when determining the fixed size, the network device 120 may determine a group of PDU sizes and determine the fixed size as a smallest one in the group of PDU sizes.

In some embodiments, the information on the number of the at least one PDU available for transmission may be included in a report of buffer status information.

In some embodiments, the network device 120 may transmit, to the terminal device, an indication indicative of a strategy for PDU construction; and receive packets from the terminal device. The packets are allocated to the at least one PDU having the fixed size based on the strategy for PDU construction.

In some embodiments, each of the packets may be padded to an individual PDU in the at least one PDU having the fixed size in the case that the strategy for PDU construction is a first strategy.

In some embodiments, the packets may be concatenated and segmented to the at least one PDU having the fixed size in the case that the strategy for PDU construction is a second strategy.

With the method 900, the network device may schedule resource for the buffered data of the terminal device based on the number of fixed-size PDUs available for transmission, which improves the power efficiency and processing speed.

In some embodiments, an apparatus capable of performing any of the method 800 (for example, the terminal device 110) may comprise means for performing the respective steps of the method 800. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

In some embodiments, the apparatus comprises: means for constructing at a terminal device, at least one protocol data unit (PDU) having a fixed size; and means for transmitting, to a network device, information on a number of the at least one PDU available for transmission.

In some embodiments, the apparatus may further include means for receiving, from the network device, an indication indicative of the fixed size.

In some embodiments, the apparatus may further include means for receiving, from the network device, an indication indicative of at least one PDU size; means for selecting the fixed size from the at least one PDU size; and means for transmitting, to the network device, value information indicative of the fixed size.

In some embodiments, the number of the at least one PDU is determined based on data buffered in the terminal device.

In some embodiments, at least one PDU size is associated with at least one processing unit of the terminal device, the fixed size is one among the at least one PDU size. The apparatus may further include means for determining at least one PDU number, wherein each of the at least one PDU number is a number of at least one PDU having a corresponding PDU size determined based on data buffered in a corresponding processing unit. Means for transmitting information on the number of the at least one PDU available for transmission may include means for transmitting, to the network device, information indicative of the at least one PDU number associated with the at least one processing unit.

In some embodiments, the apparatus may further include means for receiving, from the network device, an indication indicative of the at least one PDU size associated with the at least one processing unit.

In some embodiments, the apparatus may further include means for transmitting, to the network device, value information indicative of the at least one PDU size associated with the at least one processing unit.

In some embodiments, the apparatus may further include means for determining a scaling factor at least based on a base PDU size; means for determining the fixed size based on the base PDU size and the scaling factor; and means for transmitting, to the network device, the scaling factor.

In some embodiments, the apparatus may further include means for receiving, from the network device, an indication indicative of the base PDU size.

In some embodiments, the apparatus may further include means for determining a first number of at least one PDU having the base PDU size based on data buffered in the terminal device. The scaling factor is determined in the case that the first number exceeds a maximum reportable number.

In some embodiments, at least one base PDU size is associated with at least one processing unit of the terminal device. The apparatus may further include means for determining at least one scaling factor associated with the at least one processing unit at least based on the at least one base PDU size; means for determining at least one PDU size associated with the at least one processing unit based on the at least one base PDU size and the at least one scaling factor, wherein the fixed size is one among the at least one PDU size and is associated with one among the at least one processing unit, means for determining at least one PDU number, wherein each of the at least one PDU number is a number of at least one PDU having a corresponding PDU size determined based on data buffered in a corresponding processing unit. Means for transmitting information on the number of the at least one PDU available for transmission may include: means for transmitting, to the network device, information indicative of the at least one PDU number and the at least one scaling factor associated with the at least one processing unit.

In some embodiments, the apparatus may further include means for receiving, from the network device, an indication indicative of the at least one base PDU size associated with the at least one processing unit of the terminal device.

In some embodiments, the apparatus may further include means for determining, for a corresponding processing unit among the at least one processing unit, a corresponding first number of at least one PDU having a corresponding base PDU size based on data buffered in the corresponding processing unit. A scaling factor associated with the corresponding processing unit is determined in the case that the corresponding first number exceeds a maximum reportable number.

In some embodiments, the apparatus may further include means for receiving, from the network device, an indication indicative of resource allocation; and means for transmitting, to the network device, at least a portion of the at least one PDU based on the resource allocation. A target transport block size of the resource allocation is an integer multiple of the fixed size, and the integer is no greater than the number of the at least one PDU available for transmission.

In some embodiments, the apparatus may further include means for receiving, from the network device, an indication indicative of resource allocation; and means for transmitting, to the network device, at least a portion of the at least one PDU based on the resource allocation. A target transport block size of the resource allocation is a sum of a product of the at least one PDU size and corresponding integers, and the corresponding integers are not greater than the at least one PDU number, respectively.

In some embodiments, the apparatus may further include means for transmitting, to the network device, capability information. The capability information may include at least one of the following: an indication indicative of a capability of supporting a fixed PDU size; an indication indicative of a set of PDU sizes supported by the terminal device; or an indication indicative of at least one subset of fixed PDU sizes supported by at least one processing unit of the terminal device.

In some embodiments, an ordering in the set of PDU sizes is indicative of a priority of the set of PDU sizes.

In some embodiments, the information on the number of the at least one PDU available for transmission is comprised in a report of buffer status information.

In some embodiments, the apparatus may further include means for receiving, from the network device, an indication indicative of a strategy for PDU construction; and means for allocating packets to the at least one PDU having the fixed size based on the strategy for PDU construction.

In some embodiments, means for allocating the packets to the at least one PDU based on the strategy for PDU construction may include means for padding each of the packets to an individual PDU in the at least one PDU having the fixed size in the case that the strategy for PDU construction is a first strategy.

In some embodiments, means for allocating the packets to the at least one PDU based on the strategy for PDU construction may include means for concatenating the packets and segmenting the concatenated packets to the at least one PDU having the fixed size in the case that the strategy for PDU construction is a second strategy.

In some embodiments, an apparatus capable of performing any of the method 900 (for example, the network device 120) may comprise means for performing the respective steps of the method 900. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

In some embodiments, the apparatus comprises: means for receiving, at a network device and from the terminal device, information on a number of at least one protocol data unit (PDU) having a fixed size; and means for determining a buffer status of the terminal device based on the number of the at least one PDU and the fixed size.

In some embodiments, the apparatus may further include means for transmitting, to the terminal device, an indication indicative of the fixed size.

In some embodiments, the apparatus may further include means for transmitting, to the terminal device, an indication indicative of at least one PDU size; and means for receiving, from the terminal device, value information indicative of the fixed size.

In some embodiments, the number of the at least one PDU having the fixed size is associated with data buffered in the terminal device.

In some embodiments, at least one PDU size is associated with at least one processing unit of the terminal device, the fixed size is one among the at least one PDU size and is associated with one among the at least one processing unit. Means for receiving information on the number of the at least one PDU available for transmission may include: means for receiving, from the terminal device, information indicative of the at least one PDU number associated with the at least one processing unit. Each of the at least one PDU number is a number of at least one PDU having a corresponding PDU size determined based on data buffered in a corresponding processing unit.

In some embodiments, the apparatus may further include means for transmitting, to the terminal device, an indication indicative of the at least one PDU size associated with the at least one processing unit.

In some embodiments, the apparatus may further include means for receiving, from the terminal device, value information indicative of the at least one PDU size associated with the at least one processing unit.

In some embodiments, the apparatus may further include means for receiving, from the terminal device, a scaling factor. The fixed size is determined based on a base PDU size and a scaling factor.

In some embodiments, the apparatus may further include means for transmitting, to the terminal device, an indication indicative of the base PDU size.

In some embodiments, at least one base PDU size is associated with at least one processing unit of the terminal device. Means for receiving information on the number of the at least one PDU available for transmission may include: means for receiving, from the terminal device, information indicative of at least one PDU number and at least one scaling factor associated with the at least one processing unit. The apparatus may further include means for determining at least one PDU size based on the at least one base PDU size and the at least one scaling factor. Each of the at least one PDU number is a number of at least one PDU having a corresponding PDU size determined based on data buffered in a corresponding processing unit. The corresponding PDU size is determined based on a corresponding base PDU size and a corresponding scaling factor associated with the corresponding processing unit.

In some embodiments, the apparatus may further include means for transmitting, to the terminal device, an indication indicative of the at least one base PDU size associated with the at least one processing unit of the terminal device;

In some embodiments, the apparatus may further include means for determining a resource allocation based on the buffer status; and means for transmitting, to the terminal device, an indication indicative of resource allocation. A transport block size of the resource allocation is determined based on at least one of the following: the information on the number of the at least one PDU; a modulation and coding scheme (MCS) ; or physical resource blocks (PRBs) .

In some embodiments, the apparatus may further include means for determining a resource allocation based on the fixed size and the number of the at least one PDU available for transmission. A target transport block size of the resource allocation is an integer multiple of the fixed size, and the integer is no greater than the number of the at least one PDU available for transmission.

In some embodiments, the apparatus may further include means for determining a resource allocation based on the at least one PDU number and the at least one PDU size. A target transport block size of the resource allocation is a sum of a product of the at least one PDU size and corresponding integers, and the corresponding integers are not greater than the at least one PDU number, respectively.

In some embodiments, the apparatus may further include means for transmitting, to the terminal device, an indication indicative of activating at least one processing unit of the terminal device supporting a fixed PDU size based on at least one of the following: a data rate related to the terminal device exceeding a nominal data rate; a power requirement being satisfied; a throughput requirement being satisfied; or the terminal device supporting a modulation and coding scheme (MCS) in terms of achievable signal to interference plus noise ratio (SINR) .

In some embodiments, the apparatus may further include means for determining the fixed size based on at least one of the following: a channel condition between a terminal device and the network device; a power headroom of the terminal device; a load of the network device; traffic information of the terminal device; a power cost function of padding versus segmenting of the terminal device; or capability information of the terminal device.

In some embodiments, the apparatus may further include means for determining the at least one PDU size based on at least one of the following: a channel condition between a terminal device and the network device; a power headroom of the terminal device; a load of the network device; traffic information of the terminal device; a power cost function of padding versus segmenting of the terminal device; or capability information of the terminal device.

In some embodiments, the apparatus may further include means for determining the base PDU size based on at least one of the following: a channel condition between a terminal device and the network device; a power headroom of the terminal device; a load of the network device; traffic information of the terminal device; a power cost function of padding versus segmenting of the terminal device; or capability information of the terminal device.

In some embodiments, the apparatus may further include means for determining the at least one base PDU size based on at least one of the following: a channel condition between a terminal device and the network device; a power headroom of the terminal device; a load of the network device; traffic information of the terminal device; a power cost function of padding versus segmenting of the terminal device; or capability information of the terminal device.

In some embodiments, the capability information may include at least one of the following: an indication indicative of a capability of supporting a fixed PDU size; an indication indicative of a set of PDU sizes supported by the terminal device; or an indication indicative of at least one subset of fixed PDU sizes supported by at least one processing unit of the terminal device.

In some embodiments, means for determining the fixed size may include: means for determining a group of PDU sizes; and means for determining the fixed size as a smallest one in the group of PDU sizes.

In some embodiments, the apparatus may further include means for transmitting, to the terminal device, an indication indicative of a strategy for PDU construction; and means for receiving packets from the terminal device, wherein the packets are allocated to the at least one PDU having the fixed size based on the strategy for PDU construction.

In some embodiments, each of the packets is padded to an individual PDU in the at least one PDU having the fixed size in the case that the strategy for PDU construction is a first strategy.

In some embodiments, the packets are concatenated and segmented to the at least one PDU having the fixed size in the case that the strategy for PDU construction is a second strategy.

In some embodiments, the apparatus further comprises means for performing other steps in some embodiments of the method 900. In some embodiments, the means comprises at least one processor and at least one memory including computer program code, the at least one memory and computer program code configured to, with the at least one processor, cause the performance of the apparatus.

Fig. 10 is a simplified block diagram of a device 1000 that is suitable for implementing embodiments of the present disclosure. The device 1000 may be provided to implement the communication device, for example the terminal device 110, or the network device 120 as shown in Fig. 1A. As shown, the device 1000 includes one or more processors 1010, one or more memories 1020 coupled to the processor 1010, and one or more communication modules 1040 coupled to the processor 1010.

The communication module 1040 is for bidirectional communications. The communication module 1040 has at least one antenna to facilitate communication. The communication interface may represent any interface that is necessary for communication with other network elements.

The processor 1010 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 1000 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.

The memory 1020 may include one or more non-volatile memories and one or more volatile memories. Examples of the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 1024, an electrically programmable read only memory (EPROM) , a flash memory, a hard disk, a compact disc (CD) , a digital video disk (DVD) , and other magnetic storage and/or optical storage. Examples of the volatile memories include, but are not limited to, a random access memory (RAM) 1022 and other volatile memories that will not last in the power-down duration.

A computer program 1030 includes computer executable instructions that are executed by the associated processor 1010. The program 1030 may be stored in the ROM 820. The processor 1010 may perform any suitable actions and processing by loading the program 1030 into the RAM 1020.

The embodiments of the present disclosure may be implemented by means of the program 1030 so that the device 1000 may perform any process of the disclosure as discussed with reference to Figs. 2 to 9. The embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

In some embodiments, the program 1030 may be tangibly contained in a computer readable medium which may be included in the device 1000 (such as in the memory 1020) or other storage devices that are accessible by the device 1000. The device 1000 may load the program 1030 from the computer readable medium to the RAM 1022 for execution. The computer readable medium may include any types of tangible non-volatile storage, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like. Fig. 11 shows an example of the computer readable medium 1100 in form of CD or DVD. The computer readable medium has the program 1030 stored thereon.

Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, apparatus, system, technique or method described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer readable storage medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target real or virtual processor, to carry out and of the methods, 800, 900 as described above with reference to Figs. 8-9. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of the present disclosure, the computer program codes or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above. Examples of the carrier include a signal, computer readable medium, and the like.

The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. The term “non-transitory, ” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM) .

Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.

Although the present disclosure has been described in languages specific to structural features and/or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

A terminal device comprising:

at least one processor; and

at least one memory storing instructions that, when executed by the at least one processor, cause the terminal device at least to:

construct at least one protocol data unit (PDU) having a fixed size; and

transmit, to a network device, information on a number of the at least one PDU available for transmission.
The terminal device of claim 1, wherein the terminal device is further caused to:

receive, from the network device, an indication indicative of the fixed size.
The terminal device of claim 1, wherein the terminal device is further caused to:

receive, from the network device, an indication indicative of at least one PDU size;

select the fixed size from the at least one PDU size; and

transmit, to the network device, value information indicative of the fixed size.
The terminal device of any of claims 1-3, wherein the number of the at least one PDU is determined based on data buffered in the terminal device.
The terminal device of claim 1, wherein at least one PDU size is associated with at least one processing unit of the terminal device, the fixed size is one among the at least one PDU size,

wherein the terminal device is further caused to:

determine at least one PDU number, wherein each of the at least one PDU number is a number of at least one PDU having a corresponding PDU size determined based on data buffered in a corresponding processing unit; and

wherein transmitting information on the number of the at least one PDU available for transmission comprises:

transmitting, to the network device, information indicative of the at least one PDU number associated with the at least one processing unit.
The terminal device of claim 5, wherein the terminal device is further caused to:

receive, from the network device, an indication indicative of the at least one PDU size associated with the at least one processing unit.
The terminal device of claim 5, wherein the terminal device is further caused to:

transmit, to the network device, value information indicative of the at least one PDU size associated with the at least one processing unit.
The terminal device of claim 1, wherein the terminal device is further caused to:

determine a scaling factor at least based on a base PDU size;

determine the fixed size based on the base PDU size and the scaling factor; and

transmit, to the network device, the scaling factor.
The terminal device of claim 8, wherein the terminal device is further caused to:

receive, from the network device, an indication indicative of the base PDU size.
The terminal device of claim 8 or 9, wherein the terminal device is further caused to:

determine a first number of at least one PDU having the base PDU size based on data buffered in the terminal device; and

wherein the scaling factor is determined in the case that the first number exceeds a maximum reportable number.
The terminal device of claim 1, wherein at least one base PDU size is associated with at least one processing unit of the terminal device, and the terminal device is further caused to:

determine at least one scaling factor associated with the at least one processing unit at least based on the at least one base PDU size;

determine at least one PDU size associated with the at least one processing unit based on the at least one base PDU size and the at least one scaling factor, wherein the fixed size is one among the at least one PDU size and is associated with one among the at least one processing unit,

determine at least one PDU number, wherein each of the at least one PDU number is a number of at least one PDU having a corresponding PDU size determined based on data buffered in a corresponding processing unit; and

wherein transmitting information on the number of the at least one PDU available for transmission comprises:

transmitting, to the network device, information indicative of the at least one PDU number and the at least one scaling factor associated with the at least one processing unit.
The terminal device of claim 11, wherein the terminal device is further caused to:

receive, from the network device, an indication indicative of the at least one base PDU size associated with the at least one processing unit of the terminal device.
The terminal device of claim 11 or 12, wherein the terminal device is further caused to:

for a corresponding processing unit among the at least one processing unit, determine a corresponding first number of at least one PDU having a corresponding base PDU size based on data buffered in the corresponding processing unit,

wherein a scaling factor associated with the corresponding processing unit is determined in the case that the corresponding first number exceeds a maximum reportable number.
The terminal device of any of claims 1-4 or 8-10, wherein the terminal device is further caused to:

receive, from the network device, an indication indicative of resource allocation; and

transmit, to the network device, at least a portion of the at least one PDU based on the resource allocation,

wherein a target size of the resource allocation is an integer multiple of the fixed size, and the integer is no greater than the number of the at least one PDU available for transmission.
The terminal device of any of claims 5, 6, 7 or 11, wherein the terminal device is further caused to:

receive, from the network device, an indication indicative of resource allocation; and

transmit, to the network device, at least a portion of the at least one PDU based on the resource allocation,

wherein a target size of the resource allocation is a sum of a product of the at least one PDU size and corresponding integers, and the corresponding integers are not greater than the at least one PDU number, respectively.
The terminal device of any of claims 1-15, wherein the terminal device is further caused to:

transmit, to the network device, capability information, wherein the capability information comprises at least one of the following:

an indication indicative of a capability of supporting a fixed PDU size;

an indication indicative of a set of PDU sizes supported by the terminal device; or

an indication indicative of at least one subset of fixed PDU sizes supported by at least one processing unit of the terminal device.
The terminal device of claim 16, wherein an ordering in the set of PDU sizes is indicative of a priority of the set of PDU sizes.
The terminal device of any of claims 1-17, wherein the information on the number of the at least one PDU available for transmission is comprised in a report of buffer status information.
The terminal device of any of claims 1-18, wherein the terminal device is further caused to:

receive, from the network device, an indication indicative of a strategy for PDU construction; and

allocate packets to the at least one PDU having the fixed size based on the strategy for PDU construction.
The terminal device of claim 19, wherein allocating the packets to the at least one PDU based on the strategy for PDU construction comprises one of the following:

padding each of the packets to an individual PDU in the at least one PDU having the fixed size in the case that the strategy for PDU construction is a first strategy; or

concatenating the packets and segmenting the concatenated packets to the at least one PDU having the fixed size in the case that the strategy for PDU construction is a second strategy.
A network device comprising:

at least one processor; and

at least one memory storing instructions that, when executed by the at least one processor, cause the network device at least to:

receive, from a terminal device, information on a number of at least one protocol data unit (PDU) having a fixed size; and

determine a buffer status of the terminal device based on the number of the at least one PDU and the fixed size.
The network device of claim 21, wherein the network device is further caused to:

transmit, to the terminal device, an indication indicative of the fixed size.
The network device of claim 21, wherein the network device is further caused to:

transmit, to the terminal device, an indication indicative of at least one PDU size; and

receive, from the terminal device, value information indicative of the fixed size.
The network device of any of claims 21-23, wherein the number of the at least one PDU having the fixed size is associated with data buffered in the terminal device.
The network device of claim 21, wherein at least one PDU size is associated with at least one processing unit of the terminal device, the fixed size is one among the at least one PDU size and is associated with one among the at least one processing unit,

wherein receiving information on the number of the at least one PDU available for transmission comprises:

receiving, from the terminal device, information indicative of the at least one PDU number associated with the at least one processing unit, and

wherein each of the at least one PDU number is a number of at least one PDU having a corresponding PDU size determined based on data buffered in a corresponding processing unit.
The network device of claim 25, wherein the network device is further caused to:

transmit, to the terminal device, an indication indicative of the at least one PDU size associated with the at least one processing unit.
The network device of claim 25, wherein the network device is further caused to:

receive, from the terminal device, value information indicative of the at least one PDU size associated with the at least one processing unit.
The network device of claim 21, wherein the network device is further caused to:

receive, from the terminal device, a scaling factor,

wherein the fixed size is determined based on a base PDU size and a scaling factor.
The network device of claim 28, wherein the network device is further caused to:

transmit, to the terminal device, an indication indicative of the base PDU size.
The network device of claim 21, wherein at least one base PDU size is associated with at least one processing unit of the terminal device, and wherein receiving information on the number of the at least one PDU available for transmission comprises:

receiving, from the terminal device, information indicative of at least one PDU number and at least one scaling factor associated with the at least one processing unit;

wherein the network device is further caused to:

determine at least one PDU size based on the at least one base PDU size and the at least one scaling factor,

wherein each of the at least one PDU number is a number of at least one PDU having a corresponding PDU size determined based on data buffered in a corresponding processing unit;

wherein the corresponding PDU size is determined based on a corresponding base PDU size and a corresponding scaling factor associated with the corresponding processing unit.
The network device of claim 30, wherein the network device is further caused to:

transmit, to the terminal device, an indication indicative of the at least one base PDU size associated with the at least one processing unit of the terminal device.
The network device of any of claims 21-31, wherein the network device is further caused to:

determine a resource allocation based on the buffer status; and

transmit, to the terminal device, an indication indicative of resource allocation, wherein a size of the resource allocation is determined based on at least one of the following:

the information on the number of the at least one PDU;

a modulation and coding scheme (MCS) ; or

physical resource blocks (PRBs) .
The network device of any of claims 21-24 or 28-29, wherein the network device is further caused to:

determine a resource allocation based on the fixed size and the number of the at least one PDU available for transmission,

wherein a target size of the resource allocation is an integer multiple of the fixed size, and the integer is no greater than the number of the at least one PDU available for transmission.
The network device of any of claims 25, 26, 27 or 30, wherein the network device is further caused to:

determine a resource allocation based on the at least one PDU number and the at least one PDU size,

wherein a target size of the resource allocation is a sum of a product of the at least one PDU size and corresponding integers, and the corresponding integers are not greater than the at least one PDU number, respectively.
The network device of any of claims 21-34, wherein the network device is further caused to:

transmit, to the terminal device, an indication indicative of activating at least one processing unit of the terminal device supporting a fixed PDU size based on at least one of the following:

a data rate related to the terminal device exceeding a nominal data rate;

a power requirement being satisfied;

a throughput requirement being satisfied; or

the terminal device supporting a modulation and coding scheme (MCS) in terms of achievable signal to interference plus noise ratio (SINR) .
The network device of claim 22, wherein the network device is further caused to:

determine the fixed size based on at least one of the following:

a channel condition between a terminal device and the network device;

a power headroom of the terminal device;

a load of the network device;

traffic information of the terminal device;

a power cost function of padding versus segmenting of the terminal device; or

capability information of the terminal device.
The network device of claim 23 or 26, wherein the network device is further caused to:

determine the at least one PDU size based on at least one of the following:

a channel condition between a terminal device and the network device;

a power headroom of the terminal device;

a load of the network device;

traffic information of the terminal device;

a power cost function of padding versus segmenting of the terminal device; or

capability information of the terminal device.
The network device of claim 29, wherein the network device is further caused to:

determine the base PDU size based on at least one of the following:

a channel condition between a terminal device and the network device;

a power headroom of the terminal device;

a load of the network device;

traffic information of the terminal device;

a power cost function of padding versus segmenting of the terminal device; or

capability information of the terminal device.
The network device of claim 29, wherein the network device is further caused to:

determine the at least one base PDU size based on at least one of the following:

a channel condition between a terminal device and the network device;

a power headroom of the terminal device;

a load of the network device;

traffic information of the terminal device;

a power cost function of padding versus segmenting of the terminal device; or

capability information of the terminal device.
The network device of any of claims 36-39, wherein the capability information comprises at least one of the following:

an indication indicative of a capability of supporting a fixed PDU size;

an indication indicative of a set of PDU sizes supported by the terminal device; or

an indication indicative of at least one subset of fixed PDU sizes supported by at least one processing unit of the terminal device.
The network device of claim 40, wherein an ordering in the set of PDU sizes is indicative of a priority of the set of PDU sizes.
The network device of claim 36, wherein determining the fixed size comprises:

determining a group of PDU sizes; and

determining the fixed size as a smallest one in the group of PDU sizes.
The network device of any of claims 21-42, wherein the information on the number of the at least one PDU available for transmission is comprised in a report of buffer status information.
The network device of any of claims 21-43, wherein the network device is further caused to:

transmit, to the terminal device, an indication indicative of a strategy for PDU construction; and

receive packets from the terminal device, wherein the packets are allocated to the at least one PDU having the fixed size based on the strategy for PDU construction.
The network device of claim 44, wherein one of the following:

each of the packets is padded to an individual PDU in the at least one PDU having the fixed size in the case that the strategy for PDU construction is a first strategy; or

the packets are concatenated and segmented to the at least one PDU having the fixed size in the case that the strategy for PDU construction is a second strategy.
A method comprising:

constructing, at a terminal device, at least one protocol data unit (PDU) having a fixed size; and

transmitting, to a network device, information on a number of the at least one PDU available for transmission.
A method comprising:

receiving, at a network device and from a terminal device, information on a number of at least one protocol data unit (PDU) having a fixed size; and

determining a buffer status of the terminal device based on the number of the at least one PDU and the fixed size.
An apparatus comprising:

means for constructing at a terminal device, at least one protocol data unit (PDU) having a fixed size; and

means for transmitting, to a network device, information on a number of the at least one PDU available for transmission.
An apparatus comprising:

means for receiving, at a network device and from a terminal device, information on a number of at least one protocol data unit (PDU) having a fixed size; and

means for determining a buffer status of the terminal device based on the number of the at least one PDU and the fixed size.
A computer readable medium comprising program instructions that, when executed by an apparatus, cause the apparatus to perform at least one of the methods of claims 46-47.