Logical channel configuration method and device for supporting scheduling in consideration of transmission delay time in wireless communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting higher data transmission rates. A method performed by a terminal in a wireless communication system, according to one embodiment of the present disclosure, comprises the steps of: receiving, from a base station, an RRC message including DSR configuration information and logical channel configuration information for resource allocation according to the priority of a logical channel; identifying whether DSR is triggered on the basis of delay-critical data, which is a PDCP SDU in which the remaining time until the expiration of a discard timer of an LCG is less than the threshold value included in the DSR configuration information; transmitting a DSR to the base station; receiving, from the base station, a first UL grant in response to the DSR transmission; identifying the priority of each logical channel; and generating a MAC PDU on the basis of the first UL grant and the priority of each logical channel, wherein the priority of each logical channel can be changed according to whether the delay-critical data is included on the basis of the logical channel configuration information.

Description

Method and device for establishing a logical channel to support scheduling considering transmission delay time in a wireless communication system

[0001] The present disclosure relates to operations of a terminal and a base station in a wireless communication system, and more particularly, to a method and device for determining a logical channel priority by considering a transmission delay time of an uplink packet during uplink (UL) data transmission.

[0002] 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in the sub-6GHz frequency band such as 3.5 gigahertz (3.5GHz), but also in the ultra-high frequency band called millimeter wave (mmWave) such as 28GHz and 39GHz ('Above 6GHz'). In addition, for 6G mobile communication technology, which is called the system after 5G communication (Beyond 5G), implementation in the terahertz band (for example, the 3 terahertz (3THz) band at 95GHz) is being considered to achieve a transmission speed that is 50 times faster than 5G mobile communication technology and an ultra-low latency time that is reduced to one-tenth.

[0003] In the early stages of 5G mobile communication technology, the goal is to support services and satisfy performance requirements for enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC). These include beamforming and massive MIMO to mitigate path loss of radio waves in ultra-high frequency bands and increase the transmission distance of radio waves, support for various numerologies (such as operation of multiple subcarrier intervals) and dynamic operation of slot formats for efficient use of ultra-high frequency resources, initial access technology to support multi-beam transmission and wideband, definition and operation of BWP (Bidth Part), new channel coding methods such as LDPC (Low Density Parity Check) codes for large-capacity data transmission and Polar Code for reliable transmission of control information, and L2 pre-processing (L2). Standardization has been made for network slicing, which provides dedicated networks specialized for specific services, and pre-processing.

[0004] Currently, discussions are underway to improve and enhance the initial 5G mobile communication technology in consideration of the services that 5G mobile communication technology was intended to support, and physical layer standardization is in progress for technologies such as V2X (Vehicle-to-Everything) to help autonomous vehicles make driving decisions and increase user convenience based on their own location and status information transmitted by vehicles, NR-U (New Radio Unlicensed) for the purpose of system operation that complies with various regulatory requirements in unlicensed bands, NR terminal low power consumption technology (UE Power Saving), Non-Terrestrial Network (NTN), which is direct terminal-satellite communication to secure coverage in areas where communication with terrestrial networks is impossible, and Positioning.

[0005] In addition, standardization of radio interface architecture / protocols is in progress for technologies such as intelligent factories (Industrial Internet of Things, IoT) to support new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) that provides nodes for expanding network service areas by integrating wireless backhaul links and access links, Mobility Enhancement technology including Conditional Handover (CHO) and Dual Active Protocol Stack (DAPS) handover, and 2-step random access (2-step RACH for NR) that simplifies random access procedures. Standardization is also in progress for system architecture / services such as 5G baseline architecture (e.g., Service-based Architecture, Service-based Interface) for grafting Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) that provides services based on the location of the terminal.

[0006] Once these 5G mobile communication systems are commercialized, an explosive increase in connected devices will be connected to the communication network, necessitating enhanced functionality and performance of 5G mobile communication systems and integrated operation of these connected devices. To this end, new research will be conducted on improving 5G performance and reducing complexity, supporting AI services, supporting metaverse services, and drone communications by utilizing eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0007] In addition, the development of these 5G mobile communication systems includes new waveforms to ensure coverage in the terahertz band of 6G mobile communication technology, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), Array Antenna, and Large Scale Antenna, metamaterial-based lenses and antennas to improve the coverage of terahertz band signals, high-dimensional spatial multiplexing technology using Orbital Angular Momentum (OAM), Reconfigurable Intelligent Surface (RIS) technology, as well as full duplex technology to improve the frequency efficiency and system network of 6G mobile communication technology, satellite, AI (Artificial Intelligence) from the design stage and AI-based communication technology that realizes system optimization by internalizing end-to-end AI support functions, and ultra-high-performance communication and computing resources to provide services with complexity that exceeds the limits of terminal computing capabilities. It can serve as a basis for the development of next-generation distributed computing technologies that can be realized by utilizing them.

[0008] As described above and with the development of mobile communication systems, various services have become available, and methods for effectively providing these services are required.

[0009] The disclosed embodiment is intended to provide a device and method capable of effectively providing a delay-sensitive data transmission service in a wireless communication system.

[0010] In order to solve the above problem, a method performed by a terminal in a wireless communication system according to an embodiment of the present disclosure may include the steps of: receiving, from a base station, an RRC (radio resource control) message including DSR (delay status report) configuration information and logical channel configuration information for resource allocation according to the priority of a logical channel; identifying whether DSR is triggered based on delay-critical data, which is a PDCP SDU (packet data convergence protocol service data unit), in which a remaining time until the expiration of a discard timer of an LCG (logical channel group) is less than a threshold value included in the DSR configuration information; transmitting a DSR to the base station; receiving, from the base station, a first UL (uplink) grant in response to the DSR transmission; and identifying a priority of each logical channel; and generating a MAC PDU (medium access control protocol data unit) based on the first UL grant and the priority of each logical channel. The priority of each of the above logical channels can be changed depending on whether delay-critical data is included or not based on the logical channel configuration information.

[0011] In addition, in a wireless communication system according to one embodiment of the present disclosure, a method performed by a base station includes the steps of: transmitting, to a terminal, an RRC (radio resource control) message including DSR (delay status report) configuration information and logical channel configuration information for resource allocation according to priorities of logical channels; receiving, from the terminal, a DSR triggered based on delay-critical data, which is a PDCP SDU (packet data convergence protocol service data unit), in which a remaining time until the expiration of a discard timer of an LCG (logical channel group) is less than a threshold value included in the DSR configuration information; transmitting, to the terminal, a first UL (uplink) grant in response to the DSR transmission; and receiving a MAC PDU (medium access control protocol data unit) generated based on the first UL grant and the priorities of each logical channel, wherein the priorities of each logical channel can be changed based on whether delay-critical data is included based on the logical channel configuration information.

[0012] In addition, a terminal according to an embodiment of the present disclosure may include a transceiver; and a controller coupled to the transceiver. The controller may be configured to receive, from a base station, an RRC (radio resource control) message including DSR (delay status report) configuration information and logical channel configuration information for resource allocation according to priorities of logical channels, identify whether DSR is triggered based on delay-critical data, which is a PDCP SDU (packet data convergence protocol service data unit), in which a remaining time until the expiration of a discard timer of an LCG (logical channel group) is less than a threshold value included in the DSR configuration information, transmit the DSR to the base station, receive a first uplink (UL) grant from the base station in response to the DSR transmission, identify a priority of each logical channel, and generate a MAC PDU (medium access control protocol data unit) based on the first UL grant and the priorities of each logical channel. The priority of each of the above logical channels can be changed depending on whether delay-critical data is included or not based on the logical channel configuration information.

[0013] In addition, it may include a transceiver according to an embodiment of the present disclosure; and a controller coupled to the transceiver. The control unit may be configured to transmit, to a terminal, an RRC (radio resource control) message including DSR (delay status report) configuration information and logical channel configuration information for resource allocation according to priorities of logical channels, receive, from the terminal, a DSR triggered based on delay-critical data, which is a PDCP SDU (packet data convergence protocol service data unit), in which a remaining time until the expiration of a discard timer of an LCG (logical channel group) is less than a threshold value included in the DSR configuration information, transmit, to the terminal, a first UL (uplink) grant in response to the DSR transmission, and receive a MAC PDU (medium access control protocol data unit) generated based on the first UL grant and priorities of each logical channel. The priority of each of the above logical channels can be changed depending on whether delay-critical data is included or not based on the logical channel configuration information.

[0014] The present disclosure provides a device and method capable of effectively providing a delay-sensitive data transmission service in a wireless communication system.

[0015] FIG. 1a illustrates the structure of a next-generation mobile communication system according to one embodiment of the present disclosure.

[0016] FIG. 1b illustrates a wireless protocol structure in a long term evolution (LTE) and new radio (NR) system according to one embodiment of the present disclosure.

[0017] FIG. 1c illustrates a configuration of an application data unit (ADU) unit protocol data unit (PDU) set according to one embodiment of the present disclosure.

[0018] FIG. 1d illustrates a signaling procedure between a terminal and a base station for performing delay-aware scheduling in a next-generation mobile communication system according to an embodiment of the present disclosure.

[0019] FIG. 1e illustrates an example of a Logical Channel Prioritization (LCP) operation of a terminal for uplink data transmission according to one embodiment of the present disclosure.

[0020] FIG. 1f illustrates a signaling procedure between a terminal and a base station for performing delay-aware scheduling with enhanced logical channel setup in a next-generation mobile communication system according to an embodiment of the present disclosure.

[0021] FIG. 1g illustrates an example of a Logical Channel Prioritization (LCP) operation of a terminal to support delay-aware scheduling for uplink data transmission in a next-generation mobile communication system according to an embodiment of the present disclosure.

[0022] FIG. 1h is a flowchart of terminal operations performing delay-aware scheduling operations according to one embodiment of the present disclosure.

[0023] FIG. 1i is a flowchart of a base station operation performing a delay-aware scheduling operation according to one embodiment of the present disclosure.

[0024] FIG. 2 illustrates a terminal device according to one embodiment of the present disclosure.

[0025] FIG. 3 illustrates a base station device according to one embodiment of the present disclosure.

[0026] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the attached drawings. Furthermore, in describing the present disclosure, detailed descriptions of related known functions or configurations will be omitted if they are determined to unnecessarily obscure the gist of the present disclosure. Furthermore, the terms described below are defined in consideration of their functions in the present disclosure and may vary depending on the intent or custom of the user or operator. Therefore, their definitions should be based on the contents throughout this specification. Hereinafter, embodiments of the present invention will be described with reference to the attached drawings.

[0027] The advantages and features of the present disclosure, and methods for achieving them, will become clearer with reference to the embodiments described in detail below together with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below and may be implemented in various different forms. These embodiments are provided solely to ensure that the disclosure of the present disclosure is complete and to fully inform those skilled in the art of the scope of the invention, and the present disclosure is defined only by the scope of the claims. Like reference numerals refer to like elements throughout the specification.

[0028] At this time, it will be understood that each block of the processing flowchart drawings and combinations of the flowchart drawings can be performed by computer program instructions. These computer program instructions can be installed in a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, so that the instructions executed by the processor of the computer or other programmable data processing equipment create a means for performing the functions described in the flowchart block(s). These computer program instructions can also be stored in a computer-available or computer-readable memory that can direct a computer or other programmable data processing equipment to implement the functions in a specific manner, so that the instructions stored in the computer-available or computer-readable memory can also produce a manufactured item that includes an instruction means for performing the functions described in the flowchart block(s). Since the computer program instructions may be installed on a computer or other programmable data processing device, a series of operational steps may be performed on the computer or other programmable data processing device to create a computer-executable process, and the instructions that cause the computer or other programmable data processing device to perform the steps for performing the functions described in the flowchart block(s) may also provide steps for performing the functions described in the flowchart block(s).

[0029] Additionally, each block may represent a module, segment, or portion of code that contains one or more executable instructions for performing a specific logical function(s). It should also be noted that in some alternative implementation examples, the functions described in the blocks may occur out of order. For example, two blocks depicted in succession may actually be executed substantially concurrently, or the blocks may sometimes be executed in reverse order, depending on their respective functions.

[0030] Here, the term '~ part' used in this embodiment means software or hardware components such as FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit), and the '~ part' performs certain roles. However, the '~ part' is not limited to software or hardware. The '~ part' may be configured to be on an addressable storage medium or may be configured to play one or more processors. Therefore, as an example, the '~ part' includes components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and '~ parts' may be combined into a smaller number of components and '~ parts' or further separated into additional components and '~ parts'. Additionally, the components and '~parts' may be implemented to activate one or more CPUs within a device or secure multimedia card. In addition, in an embodiment, the '~parts' may include one or more processors.

[0031] In the following description of the present disclosure, detailed descriptions of related known functions or configurations will be omitted if they are deemed to unnecessarily obscure the gist of the present disclosure. Hereinafter, embodiments of the present disclosure will be described with reference to the attached drawings.

[0032] The terms used in the following description to identify connection nodes, terms referring to network entities, terms referring to messages, terms referring to interfaces between network entities, terms referring to various identification information, etc. are provided as examples for convenience of explanation. Therefore, the present disclosure is not limited to the terms described below, and other terms referring to objects with equivalent technical meanings may be used.

[0033] In the following description, the terms "physical channel" and "signal" may be used interchangeably with data or control signals. For example, while PDSCH (physical downlink shared channel) refers to a physical channel through which data is transmitted, PDSCH can also be used to refer to data. That is, in the present disclosure, the expression "transmitting a physical channel" can be interpreted equivalently to the expression "transmitting data or a signal through a physical channel."

[0034] Hereinafter, in the present disclosure, upper signaling refers to a signal transmission method in which a base station transmits a signal to a terminal using a downlink data channel of the physical layer, or a terminal transmits a signal to a base station using an uplink data channel of the physical layer. Upper signaling can be understood as radio resource control (RRC) signaling or a media access control (MAC) control element (CE).

[0035] For the convenience of explanation below, the present disclosure uses terms and names defined in the 3rd Generation Partnership Project NR (New Radio) or 3rd Generation Partnership Project Long Term Evolution (LTE) standards. However, the present disclosure is not limited by the above terms and names, and may be equally applied to systems conforming to other standards. In the present disclosure, gNB (next generation Node B) may be used interchangeably with eNB (Evolved Node B) for the convenience of explanation. That is, a base station described as an eNB may represent a gNB. In addition, the term terminal may represent a mobile phone, an MTC device, an NB-IoT (NarrowBand-Internet of Things) device, a sensor, as well as other wireless communication devices.

[0036] Hereinafter, the base station is an entity that performs resource allocation of a terminal, and may be at least one of a gNodeB (gNB), an eNode B (eNB), a NodeB, a BS (Base Station), a wireless access unit, a base station controller, or a node on a network. The terminal may include a UE (User Equipment), an MS (Mobile Station), a cellular phone, a smartphone, a computer, or a multimedia system capable of performing a communication function. Of course, the present invention is not limited to the above examples.

[0037] In particular, the present disclosure can be applied to 3GPP NR (5th generation mobile communication standard). Furthermore, the present disclosure can be applied to intelligent services (e.g., smart homes, smart buildings, smart cities, smart cars or connected cars, healthcare, digital education, retail, security and safety-related services, etc.) based on 5G communication technology and IoT-related technology. In the present disclosure, eNB may be used interchangeably with gNB for convenience of explanation. That is, a base station described as eNB may represent a gNB. Furthermore, the term "terminal" may refer to not only mobile phones, NB-IoT devices, and sensors, but also other wireless communication devices.

[0038] Wireless communication systems are evolving from providing voice-oriented services in the early days to broadband wireless communication systems that provide high-speed, high-quality packet data services, such as communication standards such as 3GPP's HSPA (High Speed ​​Packet Access), LTE (Long Term Evolution or E-UTRA (Evolved Universal Terrestrial Radio Access), LTE-Advanced (LTE-A), LTE-Pro, 3GPP2's HRPD (High Rate Packet Data), UMB (Ultra Mobile Broadband), and IEEE's 802.16e.

[0039] As a representative example of a broadband wireless communication system, the LTE system adopts the OFDM (Orthogonal Frequency Division Multiplexing) method in the downlink (DL) and the SC-FDMA (Single Carrier Frequency Division Multiple Access) method in the uplink (UL). The uplink refers to a wireless link in which a terminal (User Equipment; UE or MS; Mobile Station) transmits data or control signals to a base station (eNode B or BS; Base Station), and the downlink refers to a wireless link in which a base station transmits data or control signals to a terminal. The above multiple access method distinguishes the data or control information of each user by allocating and operating the time-frequency resources to be transmitted for each user so that they do not overlap, that is, so as to achieve orthogonality.

[0040] As the future communications system beyond LTE, 5G communication systems must be able to freely reflect the diverse needs of users and service providers. Therefore, they must support services that simultaneously satisfy these diverse requirements. Services being considered for 5G communication systems include Enhanced Mobile Broadband (eMBB), Massive Machine Type Communication (mMTC), and Ultra Reliability Low Latency Communication (URLLC).

[0041] In some embodiments, eMBB may aim to provide data rates that are significantly higher than those supported by existing LTE, LTE-A, or LTE-Pro. For example, in a 5G communication system, eMBB should be able to provide a peak data rate of 20 Gbps in the downlink and a peak data rate of 10 Gbps in the uplink from the perspective of a single base station. Furthermore, a 5G communication system may need to provide both the peak data rate and an increased user-perceived data rate for a terminal. To meet these requirements, a 5G communication system may require improvements in various transmission and reception technologies, including improved multi-input, multi-output (MIMO) transmission technology. Furthermore, while current LTE transmits signals using a maximum 20 MHz transmission bandwidth in the 2 GHz band, a 5G communication system can use a wider frequency bandwidth than 20 MHz in the 3-6 GHz or higher 6 GHz band, thereby meeting the data rates required by the 5G communication system.

[0042] At the same time, mMTC is being considered to support application services such as the Internet of Things (IoT) in 5G communication systems. To efficiently provide the IoT, mMTC may require support for large-scale terminal connections within a cell, improved terminal coverage, improved battery life, and reduced terminal costs. The IoT requires the ability to support a large number of terminals (e.g., 1,000,000 terminals / km2) within a cell, as it provides communication capabilities through the attachment of various sensors and devices. Furthermore, due to the nature of the service, terminals supporting mMTC are likely to be located in shadow areas not covered by cells, such as basements, which may require wider coverage than other services provided by 5G communication systems. Terminals supporting mMTC should be comprised of low-cost terminals, and since frequent battery replacement is unlikely, extremely long battery lifespans, such as 10 to 15 years, may be required.

[0043] Finally, URLLC is a cellular-based wireless communication service used for specific purposes (mission-critical), such as remote control of robots or machinery, industrial automation, unmanned aerial vehicles (UAVs), remote health care, and emergency alerts. Therefore, the communication provided by URLLC may need to provide very low latency (ultra-low latency) and very high reliability (ultra-reliability). For example, a service supporting URLLC may have to satisfy an air interface latency of less than 0.5 milliseconds and may also have a requirement for a packet error rate (PER) of 10-5 or less. Therefore, for services supporting URLLC, 5G systems may be required to provide a smaller Transmit Time Interval (TTI) than other services, while simultaneously allocating a wide range of resources in the frequency band to ensure the reliability of the communication link.

[0044] The three services considered in the aforementioned 5G communication system—eMBB, URLLC, and mMTC—can be multiplexed and transmitted in a single system. To meet the differing requirements of each service, different transmission and reception techniques and parameters may be used between the services. However, the aforementioned mMTC, URLLC, and eMBB are merely examples of different service types, and the service types applicable to this disclosure are not limited to the aforementioned examples.

[0045] Furthermore, while the embodiments of the present disclosure are described below using LTE, LTE-A, LTE Pro, or 5G (or NR, next-generation mobile communication) systems as examples, the embodiments of the present disclosure may also be applied to other communication systems with similar technical backgrounds or channel types. Furthermore, the embodiments of the present disclosure may be applied to other communication systems with some modifications, as determined by a person skilled in the art, without significantly departing from the scope of the present disclosure.

[0046] FIG. 1a illustrates the structure of a next-generation mobile communication system according to one embodiment of the present disclosure.

[0047] Referring to FIG. 1a, as illustrated, a wireless access network of a wireless communication system (hereinafter, a next-generation mobile communication system (New Radio, NR or 5G)) is composed of a next-generation base station (New Radio Node B, hereinafter, gNB) (1a-10) and an access and mobility management function (AMF) (1a-05, New Radio Core Network). A user terminal (New Radio User Equipment, hereinafter, NR UE or terminal) (1a-15) can access an external network through the gNB (1a-10) and the AMF (1a-05).

[0048] In Fig. 1a, the gNB (1a-10) may correspond to an eNB (Evolved Node B) (1a-30) of an existing LTE system. The gNB (1a-10) is connected to an NR UE (1a-15) via a wireless channel and may provide a service superior to that of an existing eNB (1a-20).

[0049] According to one embodiment of the present disclosure, in a next-generation mobile communication system, since all user traffic is serviced through a shared channel, a device is required to collect status information such as buffer status, available transmission power status, and channel status of UEs and perform scheduling, and this can be handled by a gNB (1a-10). A single gNB can typically control multiple cells.

[0050] According to one embodiment of the present disclosure, in order to implement ultra-high-speed data transmission compared to existing LTE, it may have a bandwidth greater than the existing maximum bandwidth, and beamforming technology may be additionally used with orthogonal frequency division multiplexing (hereinafter referred to as OFDM) as a wireless access technology.

[0051] In addition, according to one embodiment of the present disclosure, an adaptive modulation and coding (AMC) method that determines a modulation scheme and a channel coding rate according to the channel status of the terminal can be applied. AMF (1a-05) can perform functions such as mobility support, bearer setup, and QoS setup. AMF is a device that is in charge of various control functions as well as mobility management functions for the terminal and can be connected to multiple base stations. In addition, the next-generation mobile communication system can also be interoperable with the existing LTE system, and AMF (1a-05) is connected to MME (1a-25) through a network interface. MME (1a-25) is connected to eNB (1a-30), which is an existing base station. A terminal that supports LTE-NR Dual Connectivity can transmit and receive data while maintaining a connection to not only gNB (1a-10) but also eNB (1a-30) (1a-35).

[0052] FIG. 1b illustrates a wireless protocol structure in an LTE and NR system according to one embodiment of the present disclosure.

[0053] Referring to FIG. 1b, the wireless protocol of the NR system may be composed of SDAP (service data adaptation protocol) (1b-05)(1b-10), PDCP (packet data convergence protocol) (1b-15)(1b-20), radio link control (RLC) (1b-25)(1b-30), and MAC (medium access control) (1b-35)(1b-40) in the terminal and the gNB, respectively. SDAP (1b-05)(1b-10) may perform an operation to map each QoS flow to a specific DRB (data radio bearer), and the SDAP configuration corresponding to each DRB may be provided from a higher layer (e.g., RRC layer).

[0054] According to one embodiment of the present disclosure, PDCP (1b-15) (1b-20) may be responsible for operations such as IP header compression and / or restoration, and may additionally perform a re-ordering operation on data packets to provide an in-order delivery service to a higher layer. In addition, RLC (1b-25) (1b-30) may reconfigure PDCP PDUs into an appropriate size. MAC (1b-35) (1b-40) may be connected to a plurality of RLC layer devices configured in one terminal, and may perform operations of multiplexing RLC PDUs into MAC PDUs and demultiplexing RLC PDUs from MAC PDUs. The physical (PHY) layer (1b-45)(1b-50) can perform channel coding and modulation of upper layer data, and can perform operations of creating OFDM (orthogonal frequency-division multiplexing) symbols and transmitting them through a wireless channel, or demodulating OFDM symbols received through a wireless channel, decoding the channel, and transmitting them to a higher layer.

[0055] In addition, according to one embodiment of the present disclosure, the PHY layer (1b-45)(1b-50) can use HARQ (hybrid automatic repeat request) for additional error correction, and the receiver can transmit whether or not a packet transmitted by the transmitter has been received with 1 bit. Information on whether or not the packet received by the receiver from the transmitter has been received can be referred to as HARQ ACK / NACK information. In the case of an LTE system, downlink HARQ ACK / NACK information for uplink data transmission can be transmitted through a physical hybrid-arq indicator channel (PHICH). In the case of an NR system, downlink HARQ ACK / NACK information for uplink data transmission can be transmitted through a physical dedicated control channel (PDCCH), which is a channel through which downlink and / or uplink resource allocation, etc. are transmitted, and the base station can determine whether retransmission is necessary or whether a new transmission can be performed through scheduling information of the terminal.

[0056] Unlike LTE, the reason why the base station in the NR system determines whether retransmission is necessary or a new transmission can be performed based on the scheduling information of the terminal may be because NR applies asynchronous HARQ. Uplink HARQ ACK / NACK information for downlink data transmission can be transmitted via the physical uplink control channel (PUCCH) or the physical uplink shared channel (PUSCH). The PUCCH can generally be transmitted in the uplink of the PCell (primary cell), which will be described later. However, if the terminal supports it, HARQ ACK / NACK information for the SCell (secondary cell), which will be described later, can be transmitted, and in this case, the SCell can be referred to as a PUCCH SCell.

[0057] Although not shown in this drawing, an RRC (radio resource control) layer may exist above the PDCP layer of each terminal and base station, and the RRC layer can exchange connection and measurement-related setting control messages for radio resource control.

[0058] Meanwhile, the PHY layer (1b-45)(1b-50) may be composed of one or more frequencies and / or carriers, and the technology of using multiple frequencies simultaneously may be referred to as carrier aggregation (CA). CA technology refers to a technology that additionally uses a primary carrier and one or more secondary carriers (or subcarriers) instead of using only one carrier for communication between a terminal and a base station (e.g., eNB or gNB), and by using CA technology, the transmission capacity can be increased by the number of secondary carriers. Meanwhile, in LTE and NR systems, a cell within a base station that uses a primary carrier may be referred to as a primary cell or PCell, and a cell within a base station that uses a subcarrier may be referred to as a secondary cell or SCell.

[0059] FIG. 1c illustrates an application data unit (ADU) unit PDU set configuration according to one embodiment of the present disclosure.

[0060] Referring to FIG. 1c, various types of traffic can be classified into ADUs, which are units of information that can be distinguished at the application level. In one embodiment, an ADU may be a single photo or picture, a single frame of video data, or a single unit of audio data. An ADU may be classified into PDU sets (1c-10), and a PDU set (1c-10) may be divided into at least one PDU (101, 102, 103, 104, 105, 106) according to its size and transmitted.

[0061] For example, when using the MPEG (moving picture experts group) standard video compression technology in video traffic, a PDU set can be composed of one of 1) a combination of multiple PDUs corresponding to one I (intra)-frame (1c-30), 2) a combination of multiple PDUs corresponding to one B (bidirectional)-frame (1c-40), and 3) a combination of multiple PDUs corresponding to one P (predicted)-frame (1c-50).

[0062] According to one embodiment of the present disclosure, an I-frame (1c-20) can represent a complete photo or picture (1c-21) as an independent frame regardless of the presence or absence of other frames. The P-frame and B-frame (1c-22) are frames that represent change information of the previous I-frame (1c-20), and if the I-frame (1c-20) is not received normally, it may be difficult to normally represent the photo or picture (1c-23) that was intended to be expressed by the P-frame and B-frame (1c-22). In addition, in the case of the B-frame, since it is stored as data that infers the movement between the two frames by referencing both frames between the I-frame and the P-frame, not only the I-frame in front but also the P-frame behind must be received normally in order for the photo or picture that was intended to be expressed by the B-frame to be normally represented.

[0063] For ease of explanation, the embodiments of the present disclosure illustrate the configuration of a PDU set by exemplifying the use of MPEG standard video compression technology in video traffic. However, the contents of the present disclosure are not limited to the configuration of PDU sets in video traffic, and can be applied to all PDU set configurations comprised of general ADU units.

[0064] According to an embodiment of the present disclosure, an XR traffic flow for a specific XR (extended reality) service may be composed of a combination of data (e.g., PDUs, PDU sets, etc.) having different quality of service (QoS) requirements. For example, when video traffic coded in MPEG is transmitted for a specific XR service, several types of PDU sets having different QoS requirements (e.g., delay, reliability, etc.) corresponding to I-frame / B-frame / P-frame may constitute a single XR traffic flow.

[0065] According to one embodiment of the present disclosure, in order to service an XR traffic flow composed of data having various QoS requirements, a network may map the XR traffic flow to one or more QoS flows. As described above, when one or more QoS flows are used to service a specific XR traffic flow, data constituting the same XR traffic flow may be transmitted through different QoS flows according to the QoS requirements. In this case, the different QoS flows may be mapped to different DRBs or may be mapped to the same DRB. In addition, PDU sets transmitted through the same QoS flow may have different priorities. For example, in the case of video traffic, a PDU set corresponding to an I-frame may have a relatively higher priority than a PDU set corresponding to a B-frame or a P-frame. The importance for each PDU set can be expressed as a number from 0 to 8, or {True, false} or {0, 1}, and for downlink data, the UPF can include importance information in the GTP-U header, and the base station can consider the importance when transmitting the PDU set in the downlink. In addition, for the uplink, the importance information can be transmitted from the application layer of the terminal to the lower layer (e.g., SDAP, PDCP, RLC, MAC) through the terminal internal interface, or the importance information can be included in the SDAP / PDCP / RLC header, etc. For example, the MAC layer can check the importance of the data included in the RLC PDU through the RLC header information of the RLC PDU, and at this time, the importance of the data can be ultimately determined by the importance of the PDU set that the data constitutes.

[0066] The following embodiments of the present invention were written under the assumption that a lower importance value of a PDU set indicates a higher importance, but the same method can also be applied to cases where a higher importance value of a PDU set indicates a higher importance. However, in this case, only the method of comparing the importance values ​​of each PDU set to determine relative importance changes.

[0067] FIG. 1d illustrates a signaling procedure between a terminal and a base station for performing delay-aware scheduling in a next-generation mobile communication system according to one embodiment of the present disclosure.

[0068] Referring to FIG. 1d, a terminal (1d-01) can report UE capability information related to a Delay Status Report (DSR) to a base station (1d-03). The base station can set a DSR reporting operation for the terminal based on the UE capability information reported by the terminal. When uplink data is generated, the terminal can transmit a Buffer Status Report (BSR) to request a UL grant (uplink transmission resource) required for uplink data transmission. At this time, if the terminal does not have a UL grant for transmitting the BSR, the terminal can transmit a Scheduling Request to request a UL grant for BSR transmission. Thereafter, the base station transmits a DCI including UL grant information to the terminal based on the BSR transmitted by the terminal, and the terminal can transmit uplink data using the UL grant. If the UL grant resources allocated by the base station to the terminal are insufficient, transmission of uplink data that the terminal must transmit may be delayed. When delay-critical UL data occurs, the UE can transmit a DSR to report the transmission delay status of uplink data to the base station. At this time, delay-critical UL data can mean a PDCP SDU whose remaining time is less than a network configuration threshold (remainingTimeThreshold). At this time, if the UE does not have a UL grant for sending a DSR, the UE can transmit a Scheduling Request to request a UL grant for DSR transmission. Based on the DSR received from the UE, the base station transmits a DCI including UL grant information to the UE, and the UE can transmit uplink data using the UL grant.Through the DSR reporting operation, the base station can perform a certain level of delay-aware scheduling by identifying the transmission delay status of uplink data waiting to be transmitted within the terminal. The specific signaling operations between the terminal (1d-01) and the base station (1d-03) for the above-described operations are as follows.

[0069] In step 1d-10, the terminal (1d-01) and the base station (1d-03) can exchange terminal capability information described below in relation to delay-aware scheduling (hereinafter referred to as delay-aware scheduling).

[0070] * delayStatusReport: New terminal capability information may be defined to indicate whether the terminal supports DSR (Delay Status Report). The terminal capability information may be reported per UE and may not be a mandatory support function. In addition, FDD-TDD differentiation and FR1-FR2 differentiation may not be required. For reference, DSR may include the minimum remaining time (i.e., the time remaining until the PDCP discardTimer expires) of all packets (PDCP SDUs) waiting for transmission per LCG (logical channel group) and the total amount of delay-critical UL data. Alternatively, DSR may optionally include the minimum remaining time and the total amount of delay-critical UL data. In this case, delay-critical UL data may mean PDCP SDUs whose remaining time is less than a network-configured threshold (remainingTimeThreshold). DSR may be used by the terminal to provide the base station with information about the transmission delay time of uplink transmission data.

[0071] In step 1d-12, the base station (1d-03) may transmit an RRCReconfiguration message to the terminal (1d-01) including logical channel configuration information related to DSR configuration and uplink data transmission. Some of the information described below may be included in the RRCReconfiguration message.

[0072] * LCG-DSR-Config: This may refer to configuration information including the ID (Logical Channel Group ID) of the LCG for which DSR is set and the remainingTimeThreshold value to be used in the LCG. If the minimum value of the remaining time (i.e., remaining time) of all packets (SDUs) waiting for transmission in the LCG for which DSR is set becomes less than the remainingTimeThreshold value set for the LCG, the terminal may trigger DSR.

[0073] To support DSR configuration for multiple LCGs, an AddModList containing multiple LCG-DSR-Configs and a ReleaseList containing multiple LCG-IDs can be set.

[0074] * LogicalChannelConfig: This may refer to configuration information related to the logical channel (LCH) corresponding to each RLC bearer. In particular, parameters that must be set per LCH in relation to uplink data transmission operations may be included in LogicalChannelConfig. In relation to uplink data transmission operations, a combination of at least one of the following parameters may be included in LogicalChannelConfig.

[0075] [LCP ​​restriction related parameters]

[0076] - allowedServingCells: The allowedServingCells parameter can indicate a list of serving cells to which uplink data (UL MAC SDUs) coming from the corresponding LCH can be transmitted (mapped), and can be used in the LCP process to select an LCH to transmit data using each UL grant (i.e., an LCH selection operation). If the allowedServingCells parameter is set (included), uplink data (UL MAC SDUs) coming from the corresponding LCH can be mapped (transmitted) only to the serving cells indicated by the allowedServingCells parameter. On the other hand, if the allowedServingCells parameter is not set (included), uplink data (UL MAC SDUs) coming from the corresponding LCH can be mapped (transmitted) to any serving cell.

[0077] - allowedCG-List: The allowedCG-List parameter can indicate a list of Configured grant settings to which the uplink data (UL MAC SDUs) coming from the corresponding LCH can be transmitted (mapped), and can be used in the LCP process to select an LCH to transmit data using each UL grant (i.e., LCH selection). If the allowedCG-List parameter is set (included), the uplink data (UL MAC SDUs) coming from the corresponding LCH can only be mapped (transmitted) to the Configured grant indicated by the allowedCG-List parameter. If the allowedCG-List parameter is set (included) and the list size is '0' (i.e., the sequence size is 0), the uplink data (UL MAC SDUs) coming from the corresponding LCH cannot be mapped (transmitted) to any Configured grant settings. On the other hand, if the allowedCG-List parameter is not set (included), uplink data (UL MAC SDUs) coming from the corresponding LCH can be mapped (transmitted) to any configured grant setting. The above restriction can be applied only if the corresponding UL grant is a configured grant.

[0078] - allowedHARQ-mode: The allowedHARQ-mode parameter can indicate the allowed HARQ mode (Mode A or Mode B) of the HARQ process mapped to the corresponding LCH, and can be used in the operation of selecting the LCH on which data will be transmitted using each UL grant during the LCP process (i.e., the LCH selection operation). If the allowedHARQ-mode parameter is not set (included), there may be no restrictions on the HARQ mode of the HARQ process mapped to the corresponding LCH.

[0079] - allowedPHY-PriorityIndex: The allowedPHY-PriorityIndex parameter can indicate the PHY-priority index value (p0 or p1) of the dynamic grant on which the uplink data (UL MAC SDUs) coming from the corresponding LCH can be transmitted (mapped), and can be used in the operation of selecting the LCH on which data will be transmitted using each UL grant during the LCP process (i.e., the LCH selection operation). If the allowedPHY-PriorityIndex parameter is set (included) and the dynamic grant has a PHY-priority index, the uplink data (UL MAC SDUs) coming from the corresponding LCH can be mapped (transmitted) only to the dynamic grant that indicates the same value as the PHY-priority index indicated (set) by the allowedPHY-PriorityIndex parameter. On the other hand, if the allowedPHY-PriorityIndex parameter is not set (included), uplink data (UL MAC SDUs) coming from the corresponding LCH can be mapped (transmitted) to any dynamic grant. The above restriction can be applied only when the corresponding UL grant is a dynamic grant.

[0080] - allowedSCS-List: The allowedSCS-List parameter can indicate a list of numerologies (i.e., subcarrier spacings) on which the uplink data (UL MAC SDUs) coming from the corresponding LCH can be transmitted (mapped), and can be used in the LCP process to select an LCH to transmit data using each UL grant (i.e., LCH selection). If the allowedSCS-List parameter is set (included), the uplink data (UL MAC SDUs) coming from the corresponding LCH can be mapped (transmitted) only with the numerology indicated by the allowedSCS-List parameter. On the other hand, if the allowedSCS-List parameter is not set (included), the uplink data (UL MAC SDUs) coming from the corresponding LCH can be mapped (transmitted) with any numerology.

[0081] - maxPUSCH-Duration: The maxPUSCH-Duration parameter can indicate the maximum PUSCH duration of the UL grant on which the uplink data (UL MAC SDUs) coming from the corresponding LCH can be transmitted (mapped), and can be used in the operation of selecting the LCH on which data will be transmitted using each UL grant during the LCP process (i.e., the LCH selection operation). If the maxPUSCH-Duration parameter is set (included), the uplink data (UL MAC SDUs) coming from the corresponding LCH can be mapped (transmitted) only to the UL grant that provides the PUSCH duration that is equal to or less than the PUSCH duration indicated (configured) by the maxPUSCH-Duration parameter. On the other hand, if the maxPUSCH-Duration parameter is not set (included), the uplink data (UL MAC SDUs) coming from the corresponding LCH can be mapped (transmitted) to the grant that provides any PUSCH duration.

[0082] - configuredGrantType1Allowed: The configuredGrantType1Allowed parameter can indicate whether the uplink data (UL MAC SDUs) coming from the corresponding LCH can be transmitted (mapped) to the configured grant type 1, and can be used in the operation of selecting an LCH to transmit data using each UL grant during the LCP process (i.e., the LCH selection operation). If the configuredGrantType1Allowed parameter is set (included) or the terminal does not support the lcp-Restriction operation, the uplink data (UL MAC SDUs) coming from the corresponding LCH can be transmitted (mapped) to the configured grant type 1. Otherwise, the uplink data (UL MAC SDUs) coming from the corresponding LCH cannot be transmitted (mapped) to the configured grant type 1.

[0083] [LCP ​​resource allocation related parameters]

[0084] - Priority: The Priority parameter can indicate the priority of the corresponding LCH as an integer value from 1 to 16, and can be used in the operation of allocating transmission resources to LCHs (resource allocation operation) during the LCP process.

[0085] - prioritisedBitRate: The prioritisedBitRate parameter can indicate the prioritisedBitRate value of the corresponding LCH, and can be used in the operation of allocating transmission resources to LCHs (resource allocation operation) during the LCP process. More specifically, the prioritisedBitRate parameter can be used to calculate the Bj value and bucket size of each LCH. In the present disclosure, Bj can mean a parameter defined as the size of the uplink transmission resource (or the size of the MAC SDU) expected to be allocated to the LCH.

[0086] - bucketSizeDuration: The bucketSizeDuration parameter can indicate the bucketSizeDuration value of the corresponding LCH, and can be used in the resource allocation operation to allocate transmission resources to LCHs during the LCP process. More specifically, the bucketSizeDuration parameter can be used to calculate the bucket size of each LCH.

[0087] [SR transmission related parameters]

[0088] - schedulingRequestID: The schedulingRequestID parameter can indicate a scheduling request (SR) configuration applied to the corresponding LCH. Note that one or more SR configurations can be provided within MAC-CellGroupConfig per MAC cellgroup, and each SR configuration can have a unique ID. The schedulingRequestID parameter can indicate one of the SR configurations described above.

[0089] - logicalChannelSR-DelayTimerApplied: The logicalChannelSR-DelayTimerApplied parameter can indicate whether the SR transmission delay timer (logicalChannelSR-DelayTimer) is applied to the corresponding LCH. If logicalChannelSR-DelayTimer is not configured in BSR-Config, the logicalChannelSR-DelayTimerApplied parameter can be set to 'false'.

[0090] - logicalChannelSR-Mask: The logicalChannelSR-Mask parameter can control SR triggering for the corresponding LCH when Configured grant type 1 or 2 is set. If the logicalChannelSR-Mask parameter is set to 'true', this may mean that SR masking is set for the corresponding LCH. When SR masking is set, the UE may not immediately transmit a Scheduling Request and may wait for the configured grant even if BSR or DSR is triggered for the corresponding LCH but there is no UL grant to transmit it.

[0091] The parameters within Logical Channel Config can be described in the specification as shown in Table 1 below.

[0092]

[0093]

[0094] In step 1d-14, data requiring uplink transmission may be generated within the terminal (1d-01). When new transmittable UL data is generated, BSR may be triggered if one or more of the following two conditions are satisfied (Regular).

[0095] - Condition 1: When UL data arrives on a logical channel with a higher priority than any logical channel that already has UL data available for transmission.

[0096] - Condition 2: If there is no other logical channel that already has transmittable UL data in the LCG to which the logical channel to which the UL data arrived belongs.

[0097] The above operation can be described in the standard as shown in Table 2 below.

[0098]

[0099] In step 1d-16, if BSR was triggered in step 1d-14 and logicalChannelSR-DelayTimer is not running, the terminal (1d-01) can trigger a Scheduling request (SR) if at least one of the following conditions is satisfied.

[0100] - Condition 1: When there are no UL-SCH resources available for new transmission.

[0101] - Condition 2: When the MAC entity has configured uplink grant and Regular BSR is triggered for the LCH with logicalChannelSR-Mask set to 'false'.

[0102] - Condition 3: If the available UL-SCH resources for new transmission do not satisfy the LCP mapping restriction set on the LCH that triggered the BSR.

[0103] The above operation can be described in the standard as shown in Table 3 below.

[0104]

[0105] When SR is triggered by the above conditions, the terminal can transmit SR according to the SR setting set for the LCH that triggered BSR (the SR setting indicated by the schedulingRequestId parameter in steps 1d-12) (more specifically, using PUCCH resources for SR transmission determined according to the SR setting).

[0106] In step 1d-18, the base station (1d-03) can transmit DCI including UL grant to the terminal (1d-01) in response to the Scheduling Request transmitted in step 1d-16. The terminal can configure a MAC PDU to be transmitted using the UL grant resources received from the base station. At this time, the terminal can perform an LCP (Logical Channel Prioritization) operation in the manner described in the embodiment of FIG. 1e below to select data to be included in the MAC PDU (i.e., to determine which LCH data to allocate the UL grant resources to).

[0107] In step 1d-20, the terminal can transmit a BSR MAC CE to the base station using the UL grant resources received in step 1d-18. If the LCP performed on the UL grant received in step 1d-18 indicates that all UL data waiting for transmission can be transmitted, the BSR MAC CE is canceled and step 1d-20 may not be performed.

[0108] In step 1d-22, the base station (1d-03) can transmit to the terminal a DCI including a UL grant of a size required by the terminal based on the BSR MAC CE transmitted by the terminal (1d-01) in step 1d-20. The terminal can configure a MAC PDU to be transmitted using the UL grant resources received from the base station. At this time, the terminal can perform an LCP (Logical Channel Prioritization) operation in the manner described in the embodiment of FIG. 1e below to select data to be included in the MAC PDU (i.e., to determine which LCH data to allocate the UL grant resources to).

[0109] In step 1d-25, the terminal can transmit the UL data waiting for transmission to the base station using the UL grant resources received in step 1d-22. Additional UL grant allocation and UL data transmission can then occur.

[0110] In step 1d-26, delay-critical UL data may occur within the terminal and DSR transmission may be triggered. More specifically, the terminal may trigger DSR for an LCG if the minimum remaining time (i.e., the time remaining until the PDCP discardTimer expires) of all packets (PDCP SDUs) waiting to be transmitted in an LCG for which DSR transmission was configured by LCG-DSR-Config in step 1d-12 becomes less than the remainingTimeThreshold value and no DSR has been triggered for the LCG since the last transmitted DSR.

[0111] The above operation can be described in the standard as shown in Table 4 below.

[0112]

[0113] Note that DSR can include the minimum remaining time of all packets (PDCP SDUs) waiting for transmission in LCG units and the total amount of delay-critical UL data.

[0114] In step 1d-28, if DSR is triggered in step 1d-14, but there are no UL-SCH resources that can actually transmit DSR and there is no pending SR triggered by the existing DSR procedure, the terminal (1d-01) can trigger SR.

[0115] The above operation can be described in the standard as shown in Table 5 below.

[0116]

[0117] When SR is triggered by the above conditions, the terminal can transmit SR according to the SR setting set for the LCH that triggered DSR (the SR setting indicated by the schedulingRequestId parameter in steps 1d-12) (more specifically, using PUCCH resources for SR transmission determined according to the SR setting).

[0118] In step 1d-30, the base station (1d-03) can transmit DCI including UL grant to the terminal (1d-01) in response to the Scheduling Request transmitted in step 1d-28. The terminal can configure a MAC PDU to be transmitted using the UL grant resources received from the base station. At this time, the terminal can perform an LCP (Logical Channel Prioritization) operation in the manner described in the embodiment of FIG. 1e below to select data to be included in the MAC PDU (i.e., to determine which LCH data to allocate the UL grant resources to).

[0119] In step 1d-32, the terminal may transmit a DSR MAC CE to the base station using the UL grant resources received in step 1d-30. However, if one or more of the following conditions are met, the DSR may be canceled and step 1d-32 may not be performed.

[0120] - Condition 1: All SDUs associated with the DSR are discarded.

[0121] - Condition 2: A MAC PDU containing all SDUs associated with the DSR is transmitted.

[0122] - Condition 3: A MAC PDU containing a DSR MAC CE including delay information for all SDUs associated with the DSR is transmitted.

[0123] The above operation can be described in the standard as shown in Table 6 below.

[0124]

[0125] In step 1d-34, the base station (1d-03) can transmit to the terminal a DCI including a UL grant of a size required by the terminal based on the DSR MAC CE transmitted by the terminal (1d-01) in step 1d-32. The terminal can configure a MAC PDU to be transmitted using the UL grant resources received from the base station. At this time, the terminal can perform an LCP (Logical Channel Prioritization) operation in the manner described in the embodiment of FIG. 1e below to select data to be included in the MAC PDU (i.e., to determine which LCH data to allocate the UL grant resources to).

[0126] In step 1d-38, the terminal can transmit the UL data waiting for transmission to the base station using the UL grant resources received in step 1d-34. Additional UL grant allocation and UL data transmission can then occur.

[0127] FIG. 1e illustrates an example of a Logical Channel Prioritization (LCP) operation of a terminal for uplink data transmission according to one embodiment of the present disclosure.

[0128] Referring to FIG. 1e, when a terminal is allocated a UL grant from a base station, the terminal can calculate the size of uplink data (Transmit Block size or MAC PDU size) (1e-02) that can be transmitted using the UL grant. Thereafter, the MAC layer of the terminal can perform an LCP (Logical Channel Prioritization) operation to determine in which order to fill the UL data (1e-03, 1e-04, 1e-05) waiting to be transmitted in each LCH into the MAC PDU of the calculated size (in other words, to determine in which order to allocate uplink transmission resources to each logical channel (hereinafter referred to as LCH)).

[0129] When performing a new transmission, the MAC layer of the terminal can select LCHs for transmitting data using the corresponding UL grant for each UL grant. More specifically, when performing a new transmission, the MAC layer of the terminal can select one or more LCHs that satisfy the conditions given by the LCP restriction-related parameters (e.g., allowedServingCells, etc.) set by the base station on an LCH basis in steps 1d-12 of FIG. 1d for each UL grant. The LCH selection operation can be described in the specification as shown in Table 7 below.

[0130]

[0131] After LCHs for data transmission via the corresponding UL grant are selected according to the operation in Table 7, the MAC layer can perform resource allocation for the selected LCHs based on LCP resource allocation-related parameters (e.g., priority, etc.) set by the base station on an LCH basis in steps 1d-12 of FIG. 1d. The specific resource allocation process can be described step by step as follows.

[0132] 1. Among the selected LCHs, uplink resources can be allocated in descending order of priority for LCHs having a Bj value greater than 0. If the PBR (Prioritized Bit Rate) value of a specific LCH is set to 'infinity', the MAC entity can allocate resources for all data that can be transmitted within the LCH before satisfying the PBR values ​​of LCHs with lower priorities than the corresponding logical channel. At this time, the Bj value is a value calculated for each LCH before performing LCP, and can be calculated based on the prioritizedBitRate (PBR) and bucketSizeDuration (BSD) set for each LCH. At this time, the Bj value can be understood as the size of the uplink transmission resources expected to be allocated to each LCH (in other words, the size of the MAC SDU expected to be provided to each LCH).

[0133] 2. For each LCH, the Bj value can be reduced by the sum of the MAC SDU sizes processed in step 1.

[0134] 3. If uplink transmission resources remain, resources can be allocated in descending priority order for all selected LCHs, regardless of their Bj values, until the UL grant or data to be transmitted for the selected LCH is exhausted. LCHs with the same priority value can be allocated resources equally (or equally).

[0135] Resource allocation behavior can be described in the specification as shown in Table 8 below.

[0136]

[0137] According to one embodiment, the process of a terminal performing LCP can be described in more detail through example (1e-10).

[0138] This example describes a procedure in which a terminal receives a UL grant for uplink data transmission and performs LCP to configure a MAC PDU (1e-02) to be transmitted through the UL grant. At this time, LCH A, LCH B, and LCH C are LCHs in the terminal that are waiting to transmit data on the uplink. Among them, LCH B and LCH C may contain delay-critical data (1e-08, 1e-09) whose transmission waiting delay time is long and whose time is running out until the discardTimer expires. According to the LCH selection operation in the LCP procedure, only LCH A and LCH B may be selected as LCHs for resource allocation, and LCH C may be excluded from the LCHs for resource allocation. Thereafter, the MAC layer of the terminal may allocate uplink transmission resources to LCHs (LCH A and LCH B) whose Bj values ​​are calculated to be greater than 0 among the LCHs selected in the LCH selection process. For reference, in this embodiment, the Bj values ​​(Bj_a, BJ_b, Bj_c) of each LCH are expressed as the same, but in reality, the values ​​may be calculated differently for each LCH. Transmission resource allocation may be performed in descending order of the priority of each LCH (in other words, ascending order of the priority value), and when the priorities of the LCHs are the same, the resource allocation priority may be determined according to the terminal implementation. In this example, although the priority values ​​of LCH A and LCH B are the same at 2, resource allocation may be performed for LCH A first in the order in which the LCHs are set by the terminal implementation, and then resource allocation may be performed for LCH B and LCH C in that order. More specifically, resource allocation may be performed for UL data (1e-03) waiting for LCH A first, as much as Bj_a. Afterwards, since there is more space left on the MAC PDU, resource allocation may be performed for UL data (1e-04) waiting for LCH B.However, in this example, resource allocation is performed only for some of the UL data (1e-04) waiting in LCH B, and the LCP operation may end afterward because there are no remaining resources.

[0139] When LCP is performed based on the existing logical channel configuration (LogicalChannelConfig given to the terminal in step 1d-12 of FIG. 1d), delay-critical data (UL data 1e-08 and 1e-09, which belong to LCH B and LCH C respectively and whose remaining time until discardTimer expiration is less than the network configuration threshold) may be pushed down in the LCP process, experience high delay, and eventually be discarded due to discardTimer expiration. Therefore, the present invention proposes a method to improve the logical channel configuration (LogicalChannelConfig) and some LCP operations so that delay-critical data transmission can be performed on time (i.e., delay-aware scheduling can be supported), as shown in FIGS. 1f, 1g, 1h, and 1i.

[0140] FIG. 1f illustrates a signaling procedure between a terminal and a base station for performing delay-aware scheduling with enhanced logical channel setup in a next-generation mobile communication system according to an embodiment of the present disclosure.

[0141] Referring to FIG. 1f, a terminal (1f-01) can report UE capability information related to delay-aware scheduling (hereinafter referred to as delay-aware scheduling) to a base station (1f-03). The base station can set variables related to the delay-aware scheduling operation for the terminal based on the UE capability information reported by the terminal. When uplink data is generated, the terminal can transmit a BSR (Buffer Status Report) to request a UL grant (uplink transmission resource) required for uplink data transmission. At this time, if the terminal does not have a UL grant for transmitting the BSR, the terminal can transmit a Scheduling Request to request a UL grant for BSR transmission. Thereafter, the base station transmits a DCI including UL grant information to the terminal based on the BSR transmitted by the terminal, and the terminal can transmit uplink data using the UL grant. If the UL grant resources allocated by the base station to the terminal are insufficient, transmission of uplink data that the terminal must transmit may be delayed. When delay-critical data occurs, the terminal can transmit a DSR to report the transmission delay status of uplink data to the base station. At this time, delay-critical UL data can mean a PDCP SDU whose remaining time is less than the network configuration threshold (remainingTimeThreshold). At this time, if the terminal does not have a UL grant for sending a DSR, the terminal can transmit a Scheduling Request to request a UL grant for DSR transmission. Based on the DSR received from the terminal, the base station transmits a DCI containing UL grant information to the terminal, and the terminal can transmit uplink data using the UL grant.Through the DSR reporting operation, the base station can perform a certain level of delay-aware scheduling by identifying the transmission delay status of uplink data waiting to be transmitted within the terminal. The specific signaling operations between the terminal (1f-01) and the base station (1f-03) for the described operations are as follows.

[0142] In step 1f-10, the terminal (1f-01) and the base station (1f-03) may exchange at least one of the terminal capability information described below in relation to delay-aware scheduling (hereinafter referred to as delay-aware scheduling).

[0143] * delayStatusReport: New terminal capability information may be defined to indicate whether the terminal supports DSR (Delay Status Report). The terminal capability information may be reported per UE and may not be a mandatory support function. In addition, FDD-TDD differentiation and FR1-FR2 differentiation may not be required. Note that DSR may include the minimum remaining time (i.e., the time remaining until the PDCP discardTimer expires) of all packets (PDCP SDUs) waiting for transmission per LCG and the total amount of delay-critical UL data. Alternatively, DSR may optionally include the minimum remaining time and the total amount of delay-critical UL data. In this case, delay-critical UL data may mean PDCP SDUs whose remaining time is less than a network-configured threshold (remainingTimeThreshold). DSR may be used by the terminal to provide the base station with information about the transmission delay time of uplink transmission data.

[0144] * delayAwareScheduling: New terminal capability information may be defined to indicate whether the terminal supports the following operations / functions. However, individual terminal capability information variables may be defined for each of the following operations, or separate terminal capability information variables may be defined for each combination of at least one of the following operations / functions.

[0145] - Setting and applying separate LCP resource allocation related parameters (e.g. priority2-rXY, prioritisedBitRate2-rXY, bucketSizeDuration2-rXY) that can be applied (used) when delay-critical data occurs in LCH per LCH unit.

[0146] - Set and apply separate LCP restriction-related parameters (e.g., allowedServingCells2-rXY, allowedCG-List2-rXY, allowedHARQ-mode, allowedPHY-PriorityIndex2-rXY, allowedSCS-List2-rXY, maxPUSCH-Duration2-rXY, configuredGrantType1Allowed2-rXY) that can be applied (used) when delay-critical data occurs in LCH per LCH unit.

[0147] - Apply a separate Scheduling Request setting (schedulingRequestId2-rXY) that can be applied (used) when delay-critical data occurs in the LCH (or MAC Cellgroup).

[0148] - When delay-critical data occurs in an LCH (or MAC Cellgroup unit), the LCP restriction given by logicalChannelSR-Mask is not applied to the LCH.

[0149] Terminal capability information can be reported on a per-UE basis and may not be a mandatory feature. Furthermore, FDD-TDD differentiation and FR1-FR2 differentiation may not be required. Terminals supporting delay-aware scheduling (or delay-aware LCP) may be subject to additional constraints, such as the need to support the delayStatusReport feature. Additionally, terminals supporting delay-aware scheduling (or delay-aware LCP) must support the ability to recognize PDU sets and PDU set importance (PSI) for UL XR traffic.

[0150] In step 1f-12, the base station (1d-03) may transmit an RRCReconfiguration message including DSR configuration and delay-aware scheduling-related logical channel configuration information to the terminal (1d-01). Some of the information described below may be included in the RRCReconfiguration message.

[0151] * LCG-DSR-Config: This may refer to configuration information including the ID (Logical Channel Group ID) of the LCG for which DSR is set and the remainingTimeThreshold value to be used in the LCG. The terminal can trigger DSR when the minimum value of the remaining time (i.e., remaining time) of all packets (SDUs) waiting for transmission in the LCG for which DSR is set becomes less than the remainingTimeThreshold value set for the LCG.

[0152] To support DSR configuration for multiple LCGs, an AddModList containing multiple LCG-DSR-Configs and a ReleaseList containing multiple LCG-IDs can be set.

[0153] * LogicalChannelConfig: This may refer to configuration information related to the logical channel (LCH) corresponding to each RLC bearer. In particular, parameters that must be set per LCH in relation to uplink data transmission operations may be included in LogicalChannelConfig. In relation to uplink data transmission operations, a combination of at least one of the following parameters may be included in LogicalChannelConfig.

[0154] [LCP ​​restriction related parameters]

[0155] - allowedServingCells: The allowedServingCells parameter can indicate a list of serving cells to which uplink data (UL MAC SDUs) coming from the corresponding LCH can be transmitted (mapped), and can be used in the LCP process to select an LCH to transmit data using each UL grant (i.e., an LCH selection operation). If the allowedServingCells parameter is set (included), uplink data (UL MAC SDUs) coming from the corresponding LCH can be mapped (transmitted) only to the serving cells indicated by the allowedServingCells parameter. On the other hand, if the allowedServingCells parameter is not set (included), uplink data (UL MAC SDUs) coming from the corresponding LCH can be mapped (transmitted) to any serving cell.

[0156] - allowedCG-List: The allowedCG-List parameter can indicate a list of Configured grant settings to which the uplink data (UL MAC SDUs) coming from the corresponding LCH can be transmitted (mapped), and can be used in the LCP process to select an LCH to transmit data using each UL grant (i.e., LCH selection). If the allowedCG-List parameter is set (included), the uplink data (UL MAC SDUs) coming from the corresponding LCH can be mapped (transmitted) only to the Configured grant indicated by the allowedCG-List parameter. If the allowedCG-List parameter is set (included) and the list size is '0' (i.e., the sequence size is 0), the uplink data (UL MAC SDUs) coming from the corresponding LCH cannot be mapped (transmitted) to any Configured grant settings. On the other hand, if the allowedCG-List parameter is not set (included), uplink data (UL MAC SDUs) coming from the corresponding LCH can be mapped (transmitted) to any configured grant setting. The above restriction can be applied only when the corresponding UL grant is a configured grant.

[0157] - allowedHARQ-mode: The allowedHARQ-mode parameter can indicate the allowed HARQ mode (Mode A or Mode B) of the HARQ process mapped to the corresponding LCH, and can be used in the operation of selecting the LCH on which data will be transmitted using each UL grant during the LCP process (i.e., the LCH selection operation). If the allowedHARQ-mode parameter is not set (included), there may be no restrictions on the HARQ mode of the HARQ process mapped to the corresponding LCH.

[0158] - allowedPHY-PriorityIndex: The allowedPHY-PriorityIndex parameter can indicate the PHY-priority index value (p0 or p1) of the dynamic grant on which the uplink data (UL MAC SDUs) coming from the corresponding LCH can be transmitted (mapped), and can be used in the operation of selecting the LCH on which data will be transmitted using each UL grant during the LCP process (i.e., the LCH selection operation). If the allowedPHY-PriorityIndex parameter is set (included) and the dynamic grant has a PHY-priority index, the uplink data (UL MAC SDUs) coming from the corresponding LCH can be mapped (transmitted) only to the dynamic grant that indicates the same value as the PHY-priority index indicated (set) by the allowedPHY-PriorityIndex parameter. On the other hand, if the allowedPHY-PriorityIndex parameter is not set (included), uplink data (UL MAC SDUs) coming from the corresponding LCH can be mapped (transmitted) to any dynamic grant. The above restriction can be applied only when the corresponding UL grant is a dynamic grant.

[0159] - allowedSCS-List: The allowedSCS-List parameter can indicate a list of numerologies (i.e., subcarrier spacings) on which the uplink data (UL MAC SDUs) coming from the corresponding LCH can be transmitted (mapped), and can be used in the LCP process to select an LCH to transmit data using each UL grant (i.e., LCH selection). If the allowedSCS-List parameter is set (included), the uplink data (UL MAC SDUs) coming from the corresponding LCH can be mapped (transmitted) only with the numerology indicated by the allowedSCS-List parameter. On the other hand, if the allowedSCS-List parameter is not set (included), the uplink data (UL MAC SDUs) coming from the corresponding LCH can be mapped (transmitted) with any numerology.

[0160] - maxPUSCH-Duration: The maxPUSCH-Duration parameter can indicate the maximum PUSCH duration of the UL grant on which the uplink data (UL MAC SDUs) coming from the corresponding LCH can be transmitted (mapped), and can be used in the operation of selecting the LCH on which data will be transmitted using each UL grant during the LCP process (i.e., the LCH selection operation). If the maxPUSCH-Duration parameter is set (included), the uplink data (UL MAC SDUs) coming from the corresponding LCH can be mapped (transmitted) only to the UL grant that provides the PUSCH duration that is equal to or less than the PUSCH duration indicated (configured) by the maxPUSCH-Duration parameter. On the other hand, if the maxPUSCH-Duration parameter is not set (included), the uplink data (UL MAC SDUs) coming from the corresponding LCH can be mapped (transmitted) to the grant that provides any PUSCH duration.

[0161] - configuredGrantType1Allowed: This parameter can indicate whether uplink data (UL MAC SDUs) coming from the corresponding LCH can be transmitted (mapped) to Configured grant type 1, and can be used in the operation of selecting an LCH to transmit data using each UL grant during the LCP process (i.e., LCH selection operation). If the configuredGrantType1Allowed parameter is set (included) or the terminal does not support the lcp-Restriction operation, uplink data (UL MAC SDUs) coming from the corresponding LCH can be transmitted (mapped) to configured grant type 1. Otherwise, uplink data (UL MAC SDUs) coming from the corresponding LCH cannot be transmitted (mapped) to configured grant type 1.

[0162] [LCP ​​resource allocation related parameters]

[0163] - Priority: The Priority parameter can indicate the priority of the corresponding LCH as an integer value from 1 to 16, and can be used in the operation of allocating transmission resources to LCHs (resource allocation operation) during the LCP process.

[0164] - prioritisedBitRate: The prioritisedBitRate parameter can indicate the prioritisedBitRate value of the corresponding LCH, and can be used in the operation of allocating transmission resources to LCHs (resource allocation operation) during the LCP process. More specifically, the prioritisedBitRate parameter can be used to calculate the Bj value and bucket size of each LCH.

[0165] - bucketSizeDuration: The bucketSizeDuration parameter can indicate the bucketSizeDuration value of the corresponding LCH, and can be used in the resource allocation operation to allocate transmission resources to LCHs during the LCP process. More specifically, the bucketSizeDuration parameter can be used to calculate the bucket size of each LCH.

[0166] [SR transmission related parameters]

[0167] - schedulingRequestID: The schedulingRequestID parameter can indicate a scheduling request (SR) configuration applied to the corresponding LCH. Note that one or more SR configurations can be provided within MAC-CellGroupConfig per MAC cellgroup, and each SR configuration can have a unique ID. The schedulingRequestID parameter can indicate one of the SR configurations described above.

[0168] - logicalChannelSR-DelayTimerApplied: The logicalChannelSR-DelayTimerApplied parameter can indicate whether the SR transmission delay timer (logicalChannelSR-DelayTimer) is applied to the corresponding LCH. If logicalChannelSR-DelayTimer is not configured in BSR-Config, the logicalChannelSR-DelayTimerApplied parameter can be set to 'false'.

[0169] - logicalChannelSR-Mask: The logicalChannelSR-Mask parameter can control SR triggering for the corresponding LCH when Configured grant type 1 or 2 is set. If the logicalChannelSR-Mask parameter is set to 'true', this may mean that SR masking is set for the corresponding LCH. When SR masking is set, the UE may not immediately transmit a Scheduling Request and may wait for the configured grant even if BSR or DSR is triggered for the corresponding LCH but there is no UL grant to transmit it.

[0170] - SR-MaskDisabledForDelay: When the SR-MaskDisabledForDelay parameter exists, if delay-critical data exists in the LCH, the UE can regard the value of logicalChannelSR-Mask as false for the LCH. Even if the value of logicalChannelSR-Mask is set to 'true' for a specific LCH (even if SR masking is configured), if delay-critical data exists in the LCH, the UE can transmit SR immediately without waiting for the configured grant. By doing so, the UE can quickly transmit SR triggered by the LCH containing delay-critical data and receive the UL grant for transmitting the delay-critical data sooner.

[0171] The parameters within the Logical Channel Config can be described in the specification as shown in Table 9 below.

[0172]

[0173]

[0174] Additionally, when delay-critical data exists in the LCH (in other words, when delay-critical data is included in packets waiting to be transmitted in the buffer of the LCH), applicable LCP resource allocation related parameters (e.g., priority2-rXY, prioritisedBitRate2-rXY, bucketSizeDuration2-rXY) can be included in the Logical Channel Config separately from the existing parameters. When the parameters are set for a specific LCH and delay-critical data exists in the LCH, the new parameters (e.g., priority2-rXY, prioritisedBitRate2-rXY, bucketSizeDuration2-rXY) can be used in the LCP process instead of the previously set LCP resource allocation related parameters (e.g., priority, prioritisedBitRate, bucketSizeDuration) for the LCH. More specifically, for a specific LCH, the priority value set to the existing variable (priority) may be '3' and the priority value set to the new variable (priority2-rXY) may be '1'. At this time, if there is no delay-critical data in the LCH (hereinafter referred to as the 'default state'), the priority value for the LCH may be applied as '3' in the LCP process. Conversely, if there is delay-critical data in the LCH, the priority value for the LCH may be applied as '1' in the LCP process, thereby allowing it to be scheduled with a higher priority than in the default state.

[0175] For reference, the new variable (priority2-rXY) can indicate the priority value to be used for the LCH when there is delay-critical data as an integer value from 1 to 16. Alternatively, the new variable (priority2-rXY) can indicate the priority value to be used for the LCH when there is delay-critical data as a difference value from the existing variable (priority) value set for the LCH. For example, if the value indicated by the existing variable (priority) is '5', the new variable (priority2-rXY) value can be set to '-3', thereby indicating the priority value to be used for the LCH when there is delay-critical data as '2'. In this way, if a new variable (priority2-rXY) indicates a priority value to be used for the LCH when delay-critical data occurs as a difference value from the existing variable (priority) value set for the LCH, the new variable can be set on a logical channel basis (including within the logical channel config.) or a MAC Cell group basis (including within the MAC cell group config.). If LCP resource allocation related parameters that can be applied when delay-critical data exists are introduced (e.g., priority2-rXY, prioritisedBitRate2-rXY, bucketSizeDuration2-rXY), the parameters can be described in the specification as in Table 10.

[0176]

[0177] In another embodiment, when delay-critical data exists, applicable LCP resource allocation related parameters (e.g., priority2-rXY) may be applied only to delay-critical data, and existing resource allocation related parameters (e.g., priority) may be used for general data that is not delay-critical data. In this case, the LCP resource allocation variables applied to delay-critical data and general data may be different for the same LCH, and therefore, a separate resource allocation procedure for transmitting delay-critical data only in the LCP process may be introduced as described in Table 22 of FIG. 1g below.

[0178] Additionally, when delay-critical data exists in the LCH (i.e., when delay-critical data is included among the packets waiting to be transmitted in the buffer of the LCH), applicable LCP restriction related parameters (e.g., allowedServingCells2-rXY, allowedCG-List2-rXY, allowedHARQ-mode, allowedPHY-PriorityIndex2-rXY, allowedSCS-List2-rXY, maxPUSCH-Duration 2-rXY, configuredGrantType1Allowed2-rXY) may be included in the Logical Channel Config separately from the existing parameters. When new parameters are set for a specific LCH and delay-critical data exists in the LCH, the new parameters may be applied / used for the LCH in one of the following two options.

[0179] * Option 1: Instead of the existing LCP restriction-related parameters (e.g., allowedServingCells, allowedCG-List-r16, allowedHARQ-mode-r17, allowedPHY-PriorityIndex-r16, allowedSCS-List, maxPUSCH-Duration, configuredGrantType1Allowed) that were set for all data transmitted through the LCH, new parameters that can be applied when delay-critical data exists can be applied in the LCP process.

[0180] * Option 2: New parameters can be applied during the LCP process only for delay-critical data among the data transmitted through the LCH. And for data that is not delay-critical data (hereinafter, general data), the previously set LCP restriction-related parameters can be applied during the LCP process. In this case, the LCP restriction rules applied to delay-critical data and general data may be different for the same LCH, and therefore, a separate LCH selection procedure (Selection of logical channels for delay-critical data) for transmission of delay-critical data only during the LCP process can be introduced as described in Table 20 of Figure 1g below.

[0181] Additionally, Option 2 can be subdivided into Option 2-1 and Option 2-2 below, depending on how LCP restrictions are applied to delay-critical data when no new parameters are set.

[0182] - Option 2-1: If no new parameters are set, it can be assumed that there are no separate restrictions on delay-critical data.

[0183] - Option 2-2: If new parameters are not set, existing LCP restriction-related parameters can be applied to delay-critical data.

[0184] If new LCP restriction-related parameters are introduced that can be applied when delay-critical data exists in Option 1, the parameters can be described in the specification as shown in Table 11 below.

[0185]

[0186]

[0187] If new LCP restriction-related parameters are introduced that can be applied when delay-critical data exists in Option 2, they can be described in the specification as shown in Table 12 below. For ease of explanation, Table 12 includes only an example for the allowedServingCells2-rXY parameter. (Other parameters can also be described in the specification in a similar manner to Table 12 below.)

[0188]

[0189] As described above, by setting LCP restriction-related parameters that can be applied separately when delay-critical data exists in an LCH unit, different LCP restrictions can be applied to the same LCH depending on the presence or absence of delay-critical data. More specifically, if the existing variable (allowedServingCells) for a specific LCH is set so that data coming down to the LCH can only be transmitted to serving cell 1, the data of the LCH cannot be transmitted using the UL grant coming down from another serving cell 2. However, if the new variable (allowedServingCells2-rXY) is set so that data coming down to the LCH can be transmitted through both serving cell 1 and serving cell 2 when delay-critical data exists, the data of the LCH can be transmitted using the UL grants coming from both cells. Therefore, when delay-critical data exists, the transmission delay time of data coming down from the LCH is reduced, and the delay-critical data can be transmitted faster than before.

[0190] Alternatively, if a specific LCH contains delay-critical data, the UE may be configured not to perform LCH restriction operations for the LCH (either by invalidating all LCH restriction-related parameters or by invalidating some of the LCH restriction-related parameters). A new directive to configure / activate the above-described operations may be configured on a per-LCH basis (included in LogicalChannelConfig), per-MAC cellgroup basis (included in MAC-CellGroupConfig), or per-LCG basis (included in MAC-CellGroupConfig).

[0191] Additionally, when delay-critical data exists in the LCH (i.e., when delay-critical data is included among the packets waiting to be transmitted in the buffer of the LCH), a Scheduling Request (SR) setting (e.g., schedulingRequestId2-rXY) that can be applied / used can be included in the Logical Channel Config separately from the existing Scheduling Request setting (schedulingRequestId) for the LCH. If a new SR setting is included in the Logical Channel Config for a specific LCH and delay-critical data exists in the LCH, the new SR setting can be valid for the LCH. The new SR setting can be described in the specification as shown in Table 13 below.

[0192]

[0193] When an existing SR setting (schedulingRequestId) and a new SR setting (schedulingRequestId2-rXY) are set together for a specific LCH and delay-critical data exists in the LCH, when SR transmission is triggered for the LCH, the terminal can determine which SR setting to use in one of the following options.

[0194] * Option 1: The terminal can use the SR setting indicated by the new SR setting (schedulingRequestId2-rXY).

[0195] * Option 2: It can be left to the terminal implementation to decide which SR setting to use.

[0196] * Option 3: You can use SR settings that allow SR to be transmitted (or arrive) sooner.

[0197] When delay-critical data occurs in a corresponding LCH, the terminal can more quickly secure UL grant resources for transmitting delay-critical data by transmitting SR using a valid SR configuration (schedulingRequestId2-rXY) only when delay-critical data exists for a specific LCH as described above. More specifically, the base station can reduce SR transmission delay time by indicating SR transfer resources set in a BWP with a larger SCS (Subcarrier Spacing) (i.e., shorter symbol and slot lengths) than the SR configuration resources indicated by the existing SR configuration with a valid SR configuration (schedulingRequestId2-rXY) only when delay-critical data exists. In addition, if the UE transmits SR using an SR configuration (schedulingRequestId2-rXY) that is valid only when delay-critical data exists for the LCH, the base station can recognize that the UE has delay-critical data to transmit and provide a UL grant that can transmit the delay-critical data right away (in other words, a UL grant that is large enough to transmit other UL data along with the BSR or DSR). For reference, in general, when the UE requests a UL grant to the base station using an existing SR resource configured for a specific LCH, the base station can only provide a UL grant that is large enough to send the BSR or DSR. In this case, the UE can re-request UL grant resources for transmitting the delay-critical data by sending the BSR or DSR using the UL grant, and the base station can provide the necessary UL grant based on this.

[0198] At this time, multiple SR transmission configurations can be used as a method for the terminal to additionally inform the base station of the amount of UL grant requested through SR transmission. More specifically, multiple sections indicating the UL grant size that the terminal wishes to request can be defined, and the base station can provide the terminal with an SR transmission configuration corresponding to each section. The terminal can calculate the required UL grant size based on the amount of UL data waiting to be transmitted, and then transmit the SR using the SR transmission configuration corresponding to the section. The base station can determine the size of the UL grant required by the terminal based on the SR transmission configuration used by the terminal for SR transmission, and provide the terminal with a UL grant of the required size.

[0199] Additionally, in embodiments of the present disclosure, one of the following options may be used as a criterion for determining the presence or absence of delay-critical data in each LCH.

[0200] * Option 1: If there is an SDU for which the remaining time until the PDCP discardTimer expiration for the LCH is less than the base station-configured threshold (e.g., remainingTimeThre), it can be determined that delay-critical data exists in the LCH. The base station-configured threshold can be set per LCH (included in LogicalChannelConfig), per MAC cellgroup (included in MAC-CellGroupConfig), or per LCG (included in MAC-CellGroupConfig). Alternatively, the threshold value (remainingTimeThreshold-r18) included when configuring DSR per LCG can be applied / used for the LCHs belonging to the LCG.

[0201] * Option 2: If the LCG to which the LCH belongs was reported in the most recently transmitted DSR, it can be determined that delay-critical data exists in the LCH.

[0202] Additionally, in the embodiment of FIG. 1g, a directive (e.g., delayAwareScheduling-rXY) for setting and activating an operation to give priority to resource allocation for delay-critical data in LCP resource allocation operation as described in Table 22 may be included in the RRCReconfiguration message. The directive may be set on an LCH basis (included in LogicalChannelConfig), a MAC cellgroup basis (included in MAC-CellGroupConfig), or a LCG basis (included in MAC-CellGroupConfig). In addition, instead of introducing the directive, if DSR is set for a specific LCG, it may be interpreted that an operation to give priority to resource allocation for delay-critical data in LCP resource allocation operation is set and activated for the LCG.

[0203] At step 1f-14, data requiring uplink transmission may be generated within the terminal (1f-01). When new transmittable UL data is generated, (Regular) BSR may be triggered if one or more of the following two conditions are satisfied.

[0204] - Condition 1: When UL data arrives on a logical channel with a higher priority than any logical channel that already has UL data available for transmission.

[0205] - Condition 2: If there is no other logical channel that already has transmittable UL data in the LCG to which the logical channel to which the UL data arrived belongs.

[0206] The above operation can be described in the standard as shown in Table 14 below.

[0207]

[0208] At step 1f-16, the terminal (1f-01) can trigger a Scheduling request (SR) if BSR was triggered at step 1f-14, logicalChannelSR-DelayTimer is not running, and at least one of the following conditions is satisfied.

[0209] - Condition 1: When there are no UL-SCH resources available for new transmission.

[0210] - Condition 2: When the MAC entity has configured uplink grant and Regular BSR is triggered for the LCH with logicalChannelSR-Mask set to 'false'.

[0211] - Condition 3: If the available UL-SCH resources for new transmission do not satisfy the LCP mapping restriction set on the LCH that triggered the BSR.

[0212] The above operation can be described in the standard as shown in Table 15 below.

[0213]

[0214] When SR is triggered by the above conditions, the terminal can transmit SR according to the SR setting (indicated by the schedulingRequestId parameter of steps 1f-12) set for the LCH that triggered BSR (more specifically, using PUCCH resources for SR transmission determined according to the SR setting).

[0215] In step 1f-18, the base station (1f-03) can transmit DCI including UL grant to the terminal in response to the Scheduling Request transmitted by the terminal (1f-01) in step 1f-16. The terminal can configure a MAC PDU to be transmitted using the UL grant resources received from the base station. At this time, the terminal can perform an LCP (Logical Channel Prioritization) operation in the manner described in the embodiment of FIG. 1g to select data to be included in the MAC PDU (i.e., to determine which LCH data to allocate the UL grant resources to).

[0216] In step 1f-20, the terminal can transmit a BSR MAC CE to the base station using the UL grant resources received in step 1f-18. If all the UL data waiting for transmission can be transmitted as a result of performing LCP for the UL grant received in step 1f-18, the BSR MAC CE is canceled and steps 1f-20 may not be performed.

[0217] In step 1f-22, the base station (1f-03) can transmit to the terminal a DCI including a UL grant of a size required by the terminal based on the BSR MAC CE transmitted by the terminal (1f-01) in step 1f-20. The terminal can configure a MAC PDU to be transmitted using the UL grant resources received from the base station. At this time, the terminal can perform an LCP (Logical Channel Prioritization) operation in the manner described in the embodiment of FIG. 1g to select data to be included in the MAC PDU (i.e., to determine which LCH data to allocate the UL grant resources to).

[0218] In step 1f-25, the terminal can transmit the UL data waiting for transmission to the base station using the UL grant resources received in step 1f-22. Additional UL grant allocation and UL data transmission can then occur.

[0219] In step 1f-26, delay-critical UL data may occur within the terminal and DSR transmission may be triggered. More specifically, the terminal may trigger DSR for an LCG if the minimum remaining time (i.e., the time remaining until the PDCP discardTimer expires) of all packets (PDCP SDUs) waiting to be transmitted in an LCG for which DSR transmission is configured by LCG-DSR-Config in step 1f-12 becomes less than the remainingTimeThreshold value and no DSR has been triggered for the LCG since the last transmitted DSR.

[0220] The above operation can be described in the standard as shown in Table 16 below.

[0221]

[0222] Note that DSR can include the minimum remaining time of all packets (PDCP SDUs) waiting for transmission in LCG units and the total amount of delay-critical UL data.

[0223] In step 1f-28, if the terminal (1d-01) has a DSR triggered in step 1d-14, but there are no UL-SCH resources that can actually transmit the DSR and there is no pending SR triggered by the existing DSR procedure, the terminal can trigger the SR.

[0224] The above operation can be described in the standard as shown in Table 17 below.

[0225]

[0226] When SR is triggered by the above conditions, the terminal can transmit SR according to the SR setting set for the LCH that triggered DSR (the SR setting indicated by the schedulingRequestId or schedulingRequestId2 parameter in steps 1f-12) (more specifically, using PUCCH resources for SR transmission determined according to the SR setting).

[0227] In step 1f-30, the base station (1f-03) can transmit DCI including UL grant to the terminal (1f-01) in response to the Scheduling Request transmitted in step 1f-28. The terminal can configure a MAC PDU to be transmitted using the UL grant resources received from the base station. At this time, the terminal can perform an LCP (Logical Channel Prioritization) operation in the manner described in the embodiment of FIG. 1g to select data to be included in the MAC PDU (i.e., to determine which LCH data to allocate the UL grant resources to). If, in step 1f-28, the UE transmits SR using an SR configuration that is available only when delay-critical data exists in the corresponding LCH (an SR configuration indicated by the schedulingRequestId2 parameter), in step 1f-30, the base station may provide the UE with a UL grant that allows it to transmit delay-critical data right away (i.e., a UL grant large enough to transmit other UL data together with the BSR or DSR). In this case, steps 1f-32 and 1f-34 are omitted, and in step 1f-38, the UE may reduce transmission delay by transmitting the DSR triggered in step 1f-26 together with the delay-critical data.

[0228] In step 1f-32, the terminal may transmit a DSR MAC CE to the base station using the UL grant resources received in step 1f-30. However, if one or more of the following conditions are met, the DSR may be canceled and step 1f-32 may not be performed.

[0229] - Condition 1: All SDUs associated with the DSR are discarded.

[0230] - Condition 2: A MAC PDU containing all SDUs associated with the DSR is transmitted.

[0231] - Condition 3: A MAC PDU containing a DSR MAC CE including delay information for all SDUs associated with the DSR is transmitted.

[0232] The above operation can be described in the standard as shown in Table 18 below.

[0233]

[0234] In step 1f-34, the base station (1d-03) can transmit to the terminal a DCI including a UL grant of a size required by the terminal based on the DSR MAC CE transmitted by the terminal (1f-01) in step 1f-32. The terminal can configure a MAC PDU to be transmitted using the UL grant resources received from the base station. At this time, the terminal can perform an LCP (Logical Channel Prioritization) operation in the manner described in the embodiment of FIG. 1g below to select data to be included in the MAC PDU (i.e., to determine which LCH data to allocate the UL grant resources to).

[0235] In step 1f-38, the terminal can transmit the UL data that was waiting to be transmitted to the base station using the UL grant resources received in step 1f-34 (or step 1f-30). Additional UL grant allocation and UL data transmission can then occur.

[0236] FIG. 1g illustrates an example of a Logical Channel Prioritization (LCP) operation of a terminal to support delay-aware scheduling for uplink data transmission in a next-generation mobile communication system according to an embodiment of the present disclosure.

[0237] Referring to FIG. 1g, when a terminal is allocated a UL grant from a base station, the terminal can calculate the size of uplink data (Transmit Block size or MAC PDU size) (1g-02) that can be transmitted using the UL grant. Thereafter, the MAC layer of the terminal can perform an LCP (Logical Channel Prioritization) operation to determine in which order to fill the UL data (1g-03, 1g-04, 1g-05) waiting for transmission in each LCH into the MAC PDU of the calculated size (in other words, to determine in which order to allocate uplink transmission resources to each logical channel (hereinafter referred to as LCH)).

[0238] When performing a new transmission, the MAC layer of the terminal can select LCHs for transmitting data using the corresponding UL grant for each UL grant. More specifically, when performing a new transmission, the MAC layer of the terminal can select one or more LCHs that satisfy the conditions given by the LCP restriction-related parameters (e.g., allowedServingCells, etc.) set by the base station on an LCH basis in step 1f-12 of FIG. 1f for each UL grant. The LCH selection operation can be described in the specification as shown in Table 19 below.

[0239]

[0240] Additionally, as described in step 1f-12 of FIG. 1f, new parameters related to LCP restriction that can be applied when delay-critical data exists in the LCH are set, and the new parameters can be applied only to delay-critical data among the data transmitted through the LCH during the LCP process. In this case, the LCP restriction rules applied to delay-critical data and general data may be different for the same LCH, and therefore, a separate LCH selection procedure (Selection of logical channels for delay-critical data) for transmitting delay-critical data only during the LCP process can be described in the specification as shown in Table 20 below.

[0241]

[0242] After LCHs for transmitting data through the corresponding UL grant are selected through the operations in Table 19 or Table 20, the MAC layer can perform resource allocation for the selected LCHs based on LCP resource allocation-related parameters (e.g., priority, priority2-rXY, etc.) set by the base station on an LCH basis in step 1f-12 of FIG. 1f. The specific resource allocation process can be described step by step as follows.

[0243] 1. In the LCH selection process, uplink resources can be allocated in descending order of priority for LCHs among the selected LCHs with Bj values ​​greater than 0. If the PBR (Prioritized Bit Rate) value of a specific LCH is set to 'infinity', the MAC entity can allocate resources for all data that can be transmitted within the LCH before satisfying the PBR values ​​of LCHs with lower priorities than the logical channel. At this time, the Bj value is a value calculated for each LCH before performing LCP, and can be calculated based on the prioritizedBitRate (PBR) and bucketSizeDuration (BSD) set for each LCH. At this time, the Bj value can be understood as the size of the uplink transmission resources expected to be allocated to each LCH (in other words, the size of the MAC SDU expected to be provided to each LCH).

[0244] 2. For each LCH, the Bj value can be reduced by the sum of the MAC SDU sizes processed in step 1.

[0245] 3. If uplink transmission resources remain, resources can be allocated in descending priority order for all selected LCHs, regardless of the Bj value of each LCH, until the UL grant or data to be transmitted for that LCH is exhausted. LCHs with the same priority value can be allocated resources fairly (or equally).

[0246] Resource allocation behavior can be described in the specification as shown in Table 21 below.

[0247]

[0248] The process of a terminal performing LCP according to one embodiment of the present disclosure can be described in more detail through an example (1g-10).

[0249] This example describes a procedure in which a terminal receives a UL grant for uplink data transmission and performs LCP to configure a MAC PDU (1g-02) to be transmitted through the UL grant. At this time, there are LCHs, LCH A, LCH B, and LCH C, on which data to be transmitted on the uplink within the terminal are waiting. Among these, LCH B and LCH C contain delay-critical data (1g-08, 1g-09) whose transmission waiting delay time is long and for which there is not much time left until the discardTimer expires.

[0250] Depending on the LCH selection operation within the LCP procedure, LCH A, LCH B, and LCH C may all be selected as LCHs for resource allocation. For reference, in the embodiment of Fig. 1e, LCH C is excluded according to the LCH selection operation within the LCP procedure. At this time, the existing LCP restriction-related parameter (e.g., allowedServingCells) set for LCH C is used / applied for the LCH selection operation. However, in this embodiment, a new LCP restriction-related parameter (e.g., allowedServingCells2-rXY) to be used when delay-critical data exists may be set for LCH C separately from the existing LCP restriction-related parameter. Therefore, a new parameter (allowedServingCells2-rXY) to be used when delay-critical data exists, rather than the existing parameter (e.g., allowedServingCells), may be applied / used for the LCP restriction operation for LCH C, resulting in a different result in which LCH C is also selected as an LCH for resource allocation.

[0251] Afterwards, the MAC layer of the terminal can allocate uplink transmission resources to the LCHs (LCH A, LCH B) whose Bj values ​​are calculated to be greater than 0 among the LCHs selected in the LCH selection process. For reference, in this embodiment, the Bj values ​​(Bj_a, BJ_b, Bj_c) of each LCH are expressed in the same order, but in reality, the values ​​may be calculated differently for each LCH. Transmission resource allocation can be performed in descending order of the priority of each LCH (in other words, ascending order of the priority value), and when the priorities of the LCHs are the same, the resource allocation priority can be determined according to the terminal implementation. In this example, the existing priority values ​​of LCH A and LCH B are the same as 2, but a separate priority2-rXY parameter value applied when there is delay-critical data for LCH B can be set to 1. In the example, since there is delay-critical data (1g-08) in LCH B, 1 can be applied / used as the priority value of LCH B in the LCP process. Therefore, resource allocation for LCH B can be performed before resource allocation for LCH A. For reference, in the embodiment of Fig. 1e, since the existing priority values ​​of LCH A and LCH B are the same as 2, resource allocation is performed for LCH A first in the order in which the LCHs are set by the terminal implementation, and then resource allocation is performed for LCH B, so that delay-critical data (1e-08) waiting to be transmitted in LCH B could not be transmitted. However, in the present embodiment, based on the improved logical channel setting in step 1f-12 of Fig. 1f, the priority value of LCH B is applied / used differently in the LCP process depending on the presence or absence of delay-critical data, so that the priority of LCH B having delay-critical data (1g-08) can be higher than that of LCH A.In the case of LCH B and LCH C, since the priority value applied to both LCHs in the LCP process is the same as 1, resource allocation can be performed first for LCH B and then for LCH C in the order in which the LCHs are set by the terminal implementation. More specifically, resource allocation can be performed for Bj_b of UL data (1g-04) waiting in LCH B first. Afterwards, resource allocation can be performed for UL data (1g-05) waiting in LCH C because there is more space left in the MAC PDU. However, in this example, resource allocation is performed only for some of the UL data (1e-04) waiting in LCH B, and the LCP operation can be terminated afterward because there are no resources left.

[0252] In conclusion, in this embodiment, based on the improved logical channel setting in step 1f-12 of Fig. 1f, LCP restriction-related parameters and LCP resource allocation-related parameters are applied / used differently depending on the presence or absence of delay-critical data, thereby increasing the resource allocation priority for delay-critical data (1g-08 and 1g-09) in the LCP process. As a result, unlike the result in the embodiment of Fig. 1e, delay-critical data transmission can be performed on time.

[0253] Additionally, the resource allocation method described in Table 21 can be improved to preferentially allocate transmission resources to delay-critical data.

[0254] 1. When the delayAwareScheduling directive is set (for LCHs with Bj values ​​greater than 0 among the LCHs selected during the LCH selection process), the MAC entity may allocate resources for all delay-critical data that can be transmitted within the LCH before satisfying the PBR values ​​of LCHs with lower priorities than the corresponding logical channel.

[0255] 2. For each LCH, the Bj value can be reduced by the sum of the MAC SDU sizes processed in step 1.

[0256] 3. Among the selected LCHs, uplink resources may be allocated in descending order of priority for LCHs having a Bj value greater than 0. If the PBR (Prioritized Bit Rate) value of a specific LCH is set to 'infinity', the MAC entity may allocate resources for all data that can be transmitted within the LCH before satisfying the PBR values ​​of LCHs with lower priorities than the logical channel. At this time, the Bj value is a value calculated for each LCH before performing LCP, and can be calculated based on the prioritizedBitRate (PBR) and bucketSizeDuration (BSD) set for each LCH. At this time, the Bj value can be understood as the size of the uplink transmission resource expected to be allocated to each LCH (in other words, the size of the MAC SDU expected to be provided to each LCH).

[0257] 4. For each LCH, the Bj value can be reduced by the sum of the MAC SDU sizes processed in step 3.

[0258] 5. If uplink transmission resources remain, resources can be allocated to all selected LCHs in descending priority order, regardless of their Bj values, until the UL grant or data to be transmitted on the selected LCH is exhausted. LCHs with the same priority value can be allocated resources equally (or equally).

[0259] Resource allocation behavior can be described in the specification as shown in Table 22 below.

[0260]

[0261] As described above, the terminal operation of preferentially allocating resources to delay-critical data can be set through an indicator (e.g., delayAwareScheduling) set by the base station in step 1f-12 of FIG. 1f.

[0262] FIG. 1h is a flowchart of terminal operations performing delay-aware scheduling operations according to one embodiment of the present disclosure.

[0263] In step 1h-03, the terminal may transmit its capability information to the base station. This capability information may include indicator information indicating whether it supports delay-aware scheduling (hereinafter referred to as "delay-aware scheduling") related operations. More specifically, the terminal may configure the capability information as described in step 1f-10 of FIG.

[0264] In step 1h-05, the terminal can receive logical channel configuration information related to DSR settings and delay-aware scheduling from the base station. More specifically, the delay-aware scheduling-related settings can be configured and included in the RRCReconfiguration message, as described in step 1f-12 of FIG. 1f.

[0265] In step 1h-07, delay-critical UL data may be generated within the terminal, triggering DSR transmission. More specifically, DSR transmission may be triggered when the conditions described in step 1f-26 of FIG. 1f are satisfied.

[0266] In step 1h-09, if there is no UL-SCH resource capable of transmitting the DSR triggered in step 1h-07 and there is no pending SR (Scheduling Request) triggered by the existing DSR procedure, the UE can trigger the SR. If the SR is triggered by the above conditions, the UE can transmit the SR according to the SR configuration set for the LCH that triggered the DSR (the SR configuration indicated by the schedulingRequestId or schedulingRequestId2 parameter in step 1f-12 of FIG. 1f) (more specifically, using the PUCCH resource for SR transmission determined according to the corresponding SR configuration). More specifically, if the UE receives multiple SR configurations for the corresponding LCH, a method for determining an SR transmission configuration to be used for SR transmission is as described in step 1f-12 of FIG. 1f, and the SR transmission can be performed as described in step 1f-28 of FIG. 1f.

[0267] In step 1h-11, the UE may receive a DCI including a UL grant from the base station in response to the SR transmitted in step 1h-09. At this time, the UE may perform a Logical Channel Prioritization (LCP) operation as described in the embodiment of FIG. 1g to select data to be included in the MAC PDU (i.e., to determine which LCH's data to allocate UL grant resources to). If in step 1h-07, the UE transmits an SR using an SR configuration that is available only when delay-critical data exists in the corresponding LCH (an SR configuration indicated by the schedulingRequestId2 parameter), in step 1h-11, the UE may be provided with a UL grant from the base station that can transmit delay-critical data right away (i.e., a UL grant that is large enough to transmit other UL data together with a BSR or DSR). In this case, steps 1h-13 and 1h-15 are omitted, and in step 1h-17, the terminal can reduce the transmission delay time by transmitting the DSR triggered in step 1h-07 and delay-critical data together.

[0268] In step 1h-13, the terminal can transmit a DSR MAC CE to the base station using the UL grant resources received in step 1h-11.

[0269] In step 1h-15, the terminal may receive a DCI including a UL grant from the base station in response to the DSR transmitted in step 1h-13. At this time, the terminal may perform a Logical Channel Prioritization (LCP) operation as described in the embodiment of FIG. 1g to select data to be included in the MAC PDU (i.e., to determine which LCH data to allocate UL grant resources to).

[0270] In step 1h-17, the terminal can transmit the UL data that was waiting to be transmitted to the base station using the UL grant resource received in step 1h-15 (or step 1h-11).

[0271] FIG. 1i is a flowchart of a base station operation performing a delay-aware scheduling operation according to one embodiment of the present disclosure.

[0272] In step 1i-03, the base station may receive terminal capability information from the terminal. The capability information may include indicator information indicating whether the terminal supports delay-aware scheduling (hereinafter referred to as "delay-aware scheduling") related operations. More specifically, the terminal may configure the terminal capability information as described in step 1f-10 of FIG.

[0273] In step 1i-05, the base station can provide the terminal with logical channel configuration information related to DSR settings and delay-aware scheduling. More specifically, the delay-aware scheduling-related settings can be configured and included in the RRCReconfiguration message, as described in step 1f-12 of FIG. 1f.

[0274] In step 1i-09, the base station can receive a Scheduling Request (SR) to request a UL grant from the terminal.

[0275] In step 1i-11, the base station can transmit DCI including a UL grant to the terminal in response to the SR received in step 1i-09. At this time, in order to determine the size of the UL grant to be provided to the terminal, the base station can refer to which SR configuration (e.g., one of the SR configurations indicated by the schedulingRequestId or schedulingRequestId2 parameter in step 1f-12 of FIG. 1f) the terminal used. More specifically, if the terminal used the SR configuration indicated by the existing schedulingRequestId parameter in step 1i-09, the base station can determine that UL data to be transmitted has occurred within a specific LCH / LCG within the terminal, but that it is not delay-critical data. In this case, the base station can provide the terminal with a UL grant of a size sufficient for the terminal to transmit a BSR. On the other hand, if the UE uses the SR configuration indicated by the new schedulingRequestId2 parameter in step 1i-09, the base station can determine that delay-critical data has occurred in a specific LCH / LCG in the UE. In this case, the base station can provide the UE with as large an UL grant as possible so that the UE can quickly transmit the delay-critical data together with the DSR. Alternatively, as described in step 1f-12 of Fig. 1f, if the base station provides multiple SR configurations to the UE in order to receive a more accurate report of the required UL grant size from the UE through the SR, and if the SR is received through the PUCCH resource indicated by one of the SR transmission configurations in step 1i-09, the base station can determine the required UL grant size of the UE through the SR transmission configuration resource used by the UE.If the base station provides a UL grant of a size sufficient for the terminal to transmit delay-critical data, such as in one of the described methods, steps 1i-13 and 1i-15 below are omitted, and the base station can receive delay-critical data from the terminal in time in step 1i-17.

[0276] At step 1i-13, the base station can receive DSR MAC CE from the terminal.

[0277] In step 1i-15, the base station can transmit a DCI containing a UL grant to the terminal in response to the DSR received in step 1i-13. At this time, the base station can use the data size and delay time information contained in the DSR received in step 1i-13 to calculate / determine the size and timing of the UL grant required by the terminal.

[0278] At step 1i-17, the base station can receive UL data that was waiting to be transmitted from the terminal.

[0279] FIG. 2 is a block diagram illustrating the internal structure of a terminal according to one embodiment of the present disclosure.

[0280] Referring to FIG. 2, the terminal may include an RF (Radio Frequency) processing unit (2-10), a baseband processing unit (2-20), a storage unit (2-30), and a control unit (2-40). Of course, the present invention is not limited to the above example, and the terminal may include fewer or more components than those illustrated in FIG. 2. The RF processing unit (2-10) may perform functions for transmitting and receiving signals through a wireless channel, such as signal band conversion and amplification. That is, the RF processing unit (2-10) may up-convert a baseband signal provided from the baseband processing unit (2-20) into an RF band signal and transmit the same through an antenna, and down-convert an RF band signal received through the antenna into a baseband signal. For example, the RF processing unit (2-10) may include a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a digital to analog convertor (DAC), an analog to digital convertor (ADC), etc. In Fig. 2, only one antenna is illustrated, but the terminal may have multiple antennas. In addition, the RF processing unit (2-10) may include multiple RF chains. Furthermore, the RF processing unit (2-10) may perform beamforming. For beamforming, the RF processing unit (2-10) may adjust the phase and magnitude of each signal transmitted and received through multiple antennas or antenna elements. In addition, the RF processing unit (2-10) may perform MIMO (multi-input multi-output) and may receive multiple layers when performing a MIMO operation. The RF processing unit (2-10) can perform reception beam sweeping by appropriately setting multiple antennas or antenna elements under the control of the control unit (2-40), or adjust the direction and beam width of the reception beam so that the reception beam is in cooperation with the transmission beam.

[0281] The baseband processing unit (2-20) can perform a conversion function between a baseband signal and a bit stream according to the physical layer specifications of the system. For example, when transmitting data, the baseband processing unit (2-20) can generate complex symbols by encoding and modulating a transmission bit stream. In addition, when receiving data, the baseband processing unit (2-20) can restore the reception bit stream by demodulating and decoding the baseband signal provided from the RF processing unit (2-10). For example, in the case of following the OFDM (orthogonal frequency division multiplexing) method, when transmitting data, the baseband processing unit (2-20) can generate complex symbols by encoding and modulating a transmission bit stream, map the complex symbols to subcarriers, and then configure OFDM symbols through an inverse fast Fourier transform (IFFT) operation and a cyclic prefix (CP) insertion. In addition, when receiving data, the baseband processing unit (2-20) divides the baseband signal provided from the RF processing unit (2-10) into OFDM symbol units, restores signals mapped to subcarriers through FFT (fast Fourier transform) operation, and then restores the received bit string through demodulation and decoding.

[0282] The baseband processing unit (2-20) and the RF processing unit (2-10) can transmit and receive signals as described above. The baseband processing unit (2-20) and the RF processing unit (2-10) may be referred to as a transmitter, a receiver, a transceiver, or a communication unit. Furthermore, at least one of the baseband processing unit (2-20) and the RF processing unit (2-10) may include a plurality of communication modules to support a plurality of different wireless access technologies. In addition, at least one of the baseband processing unit (2-20) and the RF processing unit (2-10) may include different communication modules to process signals of different frequency bands. For example, the different wireless access technologies may include wireless LAN (e.g., IEEE 802.11), a cellular network (e.g., LTE), etc. Additionally, different frequency bands may include super high frequency (SHF) (e.g., 2.NRHz, NRhz) bands and millimeter wave (mm wave) (e.g., 60GHz) bands. The terminal may transmit and receive signals with the base station using the baseband processing unit (2-20) and the RF processing unit (2-10), and the signals may include control information and data.

[0283] The storage unit (2-30) can store data such as basic programs, application programs, and setting information for the operation of the terminal. In particular, the storage unit (2-30) can store information related to a second access node that performs wireless communication using a second wireless access technology. In addition, the storage unit (2-30) can provide the stored data upon request from the control unit (2-40). In addition, the storage unit (2-30) may be configured with multiple memories. According to one embodiment, the storage unit (2-30) may store a program for performing the split bearer operation method of the present disclosure.

[0284] The control unit (2-40) can control the overall operations of the terminal. For example, the control unit (2-40) can transmit and receive signals through the baseband processing unit (2-20) and the RF processing unit (2-10). In addition, the control unit (2-40) can record and read data in the storage unit (2-40). For this purpose, the control unit (2-40) can include at least one processor. For example, the control unit (2-40) can include a communication processor (CP) that performs control for communication and an application processor (AP) that controls upper layers such as application programs. In addition, at least one component within the terminal can be implemented as a single chip. In addition, according to one embodiment of the present disclosure, the control unit (2-40) can include a multi-connection processing unit (2-42) that performs processing for operating in a multi-connection mode.

[0285] FIG. 3 is a block diagram showing the configuration of a base station according to one embodiment of the present disclosure.

[0286] Referring to FIG. 3, the base station may include an RF processing unit (3-10), a baseband processing unit (3-20), a backhaul communication unit (3-30), a storage unit (3-40), and a control unit (3-50). Of course, the present invention is not limited to the above example, and the base station may include fewer or more components than the configuration illustrated in FIG. 3.

[0287] The RF processing unit (3-10) can perform functions for transmitting and receiving signals through a wireless channel, such as signal band conversion and amplification. That is, the RF processing unit (3-10) can up-convert a baseband signal provided from the baseband processing unit (3-20) into an RF band signal and transmit it through an antenna, and down-convert an RF band signal received through the antenna into a baseband signal. For example, the RF processing unit (3-10) can include a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a DAC, an ADC, etc. In Fig. 3, only one antenna is illustrated, but the base station can have multiple antennas. In addition, the RF processing unit (3-10) can include multiple RF chains. Furthermore, the RF processing unit (3-10) can perform beamforming. For beamforming, the RF processing unit (3-10) can adjust the phase and magnitude of each signal transmitted and received through multiple antennas or antenna elements. The RF processing unit (3-10) can perform a downlink MIMO operation by transmitting one or more layers. The RF processing unit (3-10) can perform reception beam sweeping by appropriately setting multiple antennas or antenna elements under the control of the control unit, or can adjust the direction and beam width of the reception beam so that the reception beam is in coordination with the transmission beam.

[0288] The baseband processing unit (3-20) can perform a conversion function between a baseband signal and a bit stream according to the physical layer specifications of the first wireless access technology. For example, when transmitting data, the baseband processing unit (3-20) can generate complex symbols by encoding and modulating a transmission bit stream. In addition, when receiving data, the baseband processing unit (3-20) can restore the reception bit stream by demodulating and decoding the baseband signal provided from the RF processing unit (3-10). For example, in the case of OFDM, when transmitting data, the baseband processing unit (3-20) can generate complex symbols by encoding and modulating a transmission bit stream, map the complex symbols to subcarriers, and then configure OFDM symbols through IFFT operation and CP insertion. In addition, when receiving data, the baseband processing unit (3-20) divides the baseband signal provided from the RF processing unit (3-10) into OFDM symbol units, restores the signals mapped to subcarriers through FFT operation, and then restores the received bit string through demodulation and decoding. The baseband processing unit (3-20) and the RF processing unit (3-10) can transmit and receive signals as described above. Accordingly, the baseband processing unit (3-20) and the RF processing unit (3-10) may be referred to as a transmitting unit, a receiving unit, a transceiver unit, a communication unit, or a wireless communication unit. The base station can transmit and receive signals with the terminal using the baseband processing unit (3-20) and the RF processing unit (3-10), and the signals may include control information and data.

[0289] The backhaul communication unit (3-30) can provide an interface for communicating with other nodes within the network. That is, the backhaul communication unit (3-30) can convert a bit string transmitted from a primary base station to another node, such as an auxiliary base station or core network, into a physical signal, and can convert a physical signal received from another node into a bit string.

[0290] The storage unit (3-40) can store data such as basic programs, application programs, and configuration information for the operation of the base station. In particular, the storage unit (3-40) can store information on bearers assigned to connected terminals, measurement results reported from connected terminals, etc. In addition, the storage unit (3-40) can store information that serves as a judgment criterion for whether to provide or terminate multiple connections to the terminal. In addition, the storage unit (3-40) can provide the stored data at the request of the control unit (3-50). The storage unit (3-40) can also store a program for performing the split bearer operation method of the present disclosure.

[0291] The control unit (3-50) can control the overall operations of the base station. For example, the control unit (3-50) can transmit and receive signals through the baseband processing unit (3-20) and the RF processing unit (3-10) or through the backhaul communication unit (3-30). In addition, the control unit (3-50) can record and read data in the storage unit (3-40). For this purpose, the control unit (3-50) can include at least one processor. In addition, at least one component of the base station can be implemented as a single chip. In addition, at least one component of the base station can be implemented as a single chip. In addition, each component of the base station can operate to perform the embodiments of the present disclosure described above.

[0292] The methods according to the embodiments described in the claims or specification of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software.

[0293] When implemented in software, a computer-readable storage medium storing one or more programs (software modules) may be provided. The one or more programs stored in the computer-readable storage medium are configured for execution by one or more processors within an electronic device. The one or more programs may include instructions that cause the electronic device to execute methods according to the embodiments described in the claims or specification of the present disclosure.

[0294] These programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, read only memory (ROM), electrically erasable programmable read only memory (EEPROM), magnetic disc storage device, compact disc ROM (CD-ROM), digital versatile discs (DVDs) or other forms of optical storage device, magnetic cassette. Or, they may be stored in a memory configured as a combination of some or all of these. In addition, each configuration memory may be included in multiple numbers.

[0295] Additionally, the program may be stored on an attachable storage device that is accessible via a communication network, such as the Internet, an intranet, a local area network (LAN), a wide local area network (WLAN), a storage area network (SAN), or a combination thereof. Such a storage device may be connected to a device performing an embodiment of the present disclosure via an external port. Additionally, a separate storage device on the communication network may be connected to a device performing an embodiment of the present disclosure.

[0296] In the specific embodiments of the present disclosure described above, components included in the invention are expressed singularly or plurally, depending on the specific embodiment presented. However, the singular or plural expressions are selected to suit the presented situation for convenience of explanation, and the present disclosure is not limited to singular or plural components. Even components expressed in plural may be composed of singular elements, or even components expressed in singular may be composed of plural elements.

[0297] While the detailed description of this disclosure has described specific embodiments, it should be understood that various modifications are possible without departing from the scope of this disclosure. Therefore, the scope of this disclosure should not be limited to the described embodiments, but should be defined not only by the scope of the claims described below, but also by equivalents thereof.

Claims

1. A method performed by a terminal in a wireless communication system, A step of receiving, from a base station, an RRC (radio resource control) message including DSR (delay status report) setting information and logical channel setting information for resource allocation according to the priority of the logical channel; A step for identifying whether DSR is triggered based on delay-critical data, which is a PDCP SDU (packet data convergence protocol service data unit) whose remaining time until the expiration of the discard timer of an LCG (logical channel group) is less than a threshold value included in the DSR configuration information; A step of transmitting DSR to the above base station; A step of receiving a first UL (uplink) grant from the base station in response to the DSR transmission; and a step of identifying the priority of each logical channel; and A step of generating a MAC PDU (medium access control protocol data unit) based on the first UL grant and the priority of each logical channel is included. A method wherein the priority of each logical channel is changed depending on whether delay-critical data is included based on the logical channel configuration information.

2. In paragraph 1, The step of identifying whether the above DSR is triggered is as follows: A method for identifying a trigger of a DSR when delay critical data occurs and a DSR has not been triggered for the LCG since a previous DSR transmission.

3. In paragraph 1, Logical channel configuration information is: A method comprising first configuration information that is applied when the logical channel includes delay-critical data and second configuration information that is applied when the logical channel does not include delay-critical data.

4. In paragraph 1, the method, A step of transmitting an SR (scheduling request) to the base station to request a second UL grant for the DSR transmission; and A step of receiving the second UL grant from the base station, The step of transmitting the above DSR is: A method for transmitting the DSR using resources allocated through the second UL grant.

5. In paragraph 1, A method wherein the above logical channel setting information further includes information for controlling SR triggering for each logical channel and information for indicating whether to apply the information for controlling SR triggering when each logical channel includes the delay-critical data.

6. In paragraph 1, The above logical channel setting information is A method comprising at least one of serving cell restriction information, configured grant restriction information, dynamic grant restriction information, HARQ (hybrid automatic repeat request) mode restriction information, subcarrier spacing restriction information, and PUSCH (physical uplink shared channel) interval restriction information applied for data transmission of the logical channel including the delay-critical data.

7. A method performed by a base station in a wireless communication system, A step of transmitting, to a terminal, an RRC (radio resource control) message including DSR (delay status report) setting information and logical channel setting information for resource allocation according to the priority of the logical channel; A step of receiving, from the terminal, a DSR triggered based on delay-critical data, which is a PDCP SDU (packet data convergence protocol service data unit) in which the remaining time until the expiration of a discard timer of an LCG (logical channel group) is less than a threshold value included in the DSR configuration information; A step of transmitting a first UL (uplink) grant to the terminal in response to the DSR transmission; and Including a step of receiving a MAC PDU (medium access control protocol data unit) generated based on the first UL grant and the priority of each logical channel, A method wherein the priority of each logical channel is changed depending on whether delay-critical data is included based on the logical channel configuration information.

8. In paragraph 7, Logical channel configuration information is: A method comprising first configuration information that is applied when the logical channel includes delay-critical data and second configuration information that is applied when the logical channel does not include delay-critical data.

9. In paragraph 7, the method, A step of receiving an SR (scheduling request) for requesting a second UL grant for the DSR from the terminal; and A step of transmitting the second UL grant to the terminal, The step of receiving the above DSR is: A method for receiving the DSR using resources allocated through the second UL grant.

10. In paragraph 7, A method wherein the above logical channel setting information further includes information for controlling SR triggering for each logical channel and information for indicating whether to apply the information for controlling SR triggering when each logical channel includes the delay-critical data.

11. In paragraph 7, The above logical channel setting information is A method comprising at least one of serving cell restriction information, configured grant restriction information, dynamic grant restriction information, HARQ (hybrid automatic repeat request) mode restriction information, subcarrier spacing restriction information, and PUSCH (physical uplink shared channel) interval restriction information applied for data transmission of the logical channel including the delay-critical data.

12. In a terminal in a wireless communication system, a transceiver; and A controller coupled to the above transceiver, wherein the controller comprises: Receives an RRC (radio resource control) message from a base station, including DSR (delay status report) configuration information and logical channel configuration information for resource allocation according to the priority of the logical channel, Identify whether DSR is triggered based on delay-critical data, which is a PDCP SDU (packet data convergence protocol service data unit) whose remaining time until expiration of the discard timer of the LCG (logical channel group) is less than the threshold value included in the DSR configuration information. To the above base station, transmit DSR, From the above base station, a first UL (uplink) grant is received in response to the DSR transmission, Identify the priority of each logical channel, It is configured to generate a MAC PDU (medium access control protocol data unit) based on the first UL grant and the priority of each logical channel, A terminal in which the priority of each logical channel is changed depending on whether delay-critical data is included or not based on the logical channel configuration information.

13. In paragraph 12, The above control unit, A terminal configured to identify a trigger of a DSR when delay critical data occurs and a DSR has not been triggered for the LCG since a previous DSR transmission.

14. In a base station in a wireless communication system, a transceiver; and A controller coupled to the above transceiver, wherein the controller comprises: Transmits to the terminal an RRC (radio resource control) message including DSR (delay status report) configuration information and logical channel configuration information for resource allocation according to the priority of the logical channel, Receive a DSR triggered based on delay-critical data, which is a PDCP SDU (packet data convergence protocol service data unit) whose remaining time until expiration of a discard timer of an LCG (logical channel group) is less than a threshold value included in the DSR configuration information, from the terminal; To the above terminal, transmit a first UL (uplink) grant in response to the above DSR transmission, It is configured to receive a MAC PDU (medium access control protocol data unit) generated based on the first UL grant and the priority of each logical channel, A base station, wherein the priority of each logical channel is changed depending on whether delay-critical data is included or not based on the logical channel configuration information.

15. In paragraph 14, Logical channel configuration information is: A base station including first configuration information that is applied when the logical channel includes delay-critical data and second configuration information that is applied when the logical channel does not include delay-critical data.

Images