Electronic device and method for controlling congestion in wireless communication system

Abstract

According to an embodiment, a method performed by a device of a central unit (CU) comprises an operation of receiving, through a transceiver, a message indicating a transmission state of downlink data from a distributed unit (DU) connected to the CU. The method comprises an operation of determining, on the basis of the message, a probability that an explicit congestion notification (ECN) field is displayed as a specified value indicating congestion. The method comprises an operation of marking an ECN field of at least one packet from among packets, which are transmitted from the CU to the DU, with the specified value, according to the probability.

Description

Electronic device and method for controlling congestion in wireless communication systems

[0001] The present disclosure relates to a wireless communication system. More specifically, the present disclosure relates to an electronic device and method for controlling congestion in a wireless communication system.

[0002] L4S (low latency, low loss, scalable throughput) is a technology designed to mitigate queuing delay issues that can arise in network equipment deployed end-to-end between servers (e.g., application servers) and clients. When L4S is applied, low latency performance for Internet protocol flows can be guaranteed without compromising throughput performance.

[0003] The above information may be provided as background art to aid in understanding the present disclosure. No claim or determination is made as to whether any of the above is applicable as prior art related to the present disclosure.

[0004] According to one embodiment, a device of a central unit (CU) may include a transceiver, at least one processor including processing circuitry, and one or more storage media, and may include a memory for storing instructions. The instructions, when individually or collectively executed by the at least one processor, may cause the device to receive, through the transceiver, a message indicating a transmission status of downlink data from a distributed unit (DU) connected to the CU. The instructions, when individually or collectively executed by the at least one processor, may cause the device to determine, based on the message, a probability that an explicit congestion notification (ECN) field will be marked with a specified value indicating congestion. The instructions, when individually or collectively executed by the at least one processor, may cause the device to mark an ECN field of at least one packet among packets transmitted from the CU to the DU with the specified value, according to the probability.

[0005] According to one embodiment, a method performed by a device of a central unit (CU) may include receiving, through a transceiver, a message indicating a transmission status of downlink data from a distributed unit (DU) connected to the CU. The method may include determining, based on the message, a probability that an explicit congestion notification (ECN) field will be marked with a designated value indicating congestion. The method may include marking, based on the probability, an ECN field of at least one packet among packets transmitted from the CU to the DU with the designated value.

[0006] According to one embodiment, a non-transitory computer-readable storage medium may store one or more programs. The one or more programs may include instructions that, when executed by a processor of an electronic device of a central unit (CU), cause the electronic device to receive, through a transceiver, a message indicating a transmission status of downlink data from a distributed unit (DU) connected to the CU. The one or more programs may include instructions that, when executed by the processor of the electronic device, cause the electronic device to determine, based on the message, a probability that an explicit congestion notification (ECN) field will be marked with a designated value indicating congestion. The one or more programs may include instructions that, when executed by the processor of the electronic device, cause the electronic device to mark, with the designated value, an ECN field of at least one of packets transmitted from the CU to the DU, based on the probability.

[0007] Figures 1a and 1b illustrate examples of wireless communication systems.

[0008] Figure 2a shows examples of control planes (C-planes).

[0009] Figure 2b shows examples of user planes (U-planes).

[0010] Figures 3a, 3b, and 3c illustrate examples of function split according to a communication protocol.

[0011] Figure 4 shows an example of signaling between a central unit (CU) and a distributed unit (DU).

[0012] Figure 5 illustrates an example in which information about a DU is transmitted to a CU.

[0013] Figure 6 illustrates an example of the operation of a CU for performing ECN marking.

[0014] Figure 7 shows the ECN marking probability according to buffering delay.

[0015] Figures 8a and 8b illustrate examples of information transmitted to the core network.

[0016] Figure 9 is a flowchart of the operation of an electronic device for performing marking of an ECN field.

[0017] The terms used in this disclosure are used only to describe specific embodiments and may not be intended to limit the scope of other embodiments. The singular expression may include plural expressions unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as commonly understood by those of ordinary skill in the art described in this disclosure. Terms defined in general dictionaries among the terms used in this disclosure may be interpreted as having the same or similar meaning in the context of the relevant technology, and shall not be interpreted in an idealized or overly formal sense unless explicitly defined in this disclosure. In some cases, even if a term is defined in this disclosure, it cannot be interpreted to exclude embodiments of the present disclosure.

[0018] The various embodiments of the present disclosure described below illustrate a hardware-based approach as an example. However, since the various embodiments of the present disclosure include techniques utilizing both hardware and software, the various embodiments of the present disclosure do not exclude a software-based approach.

[0019] In the following description, terms referring to signals (e.g., signal, information, message, signaling), terms referring to data types (e.g., list, set, subset), terms for operational states (e.g., step, operation, procedure), terms referring to data (e.g., packet, user stream, information, bit, symbol, codeword), terms referring to resources (e.g., symbol, slot, subframe, radio frame, subcarrier, resource element (RE), resource block (RB), bandwidth part (BWP), occasion), terms referring to channels, terms referring to network entities, terms referring to components of devices, etc. are examples for convenience of description. Therefore, the present disclosure is not limited to the terms described below, and other terms having equivalent technical meanings may be used. In addition, the terms '...bu', '...gi', '...mul', '...che', etc. used below may mean at least one shape structure or a unit that processes a function.

[0020] In addition, in the present disclosure, expressions such as "more than" or "less than" may be used to determine whether a specific condition is satisfied or fulfilled, but this is merely a description for expressing an example and does not exclude descriptions such as "more than" or "less than." A condition described as "more than" may be replaced with "more than," a condition described as "less than" may be replaced with "less than," and a condition described as "more than and less than" may be replaced with "more than and less than." In addition, hereinafter, "A" to "B" mean at least one of elements from A (including A) to B (including B). hereinafter, "C" and / or "D" mean at least one of "C" or "D," that is, including {"C", "D", "C" and "D"}.

[0021] Although the present disclosure describes various embodiments using terms used in some communication standards (e.g., 3rd Generation Partnership Project (3GPP), European Telecommunications Standards Institute (ETSI), extensible radio access network (xRAN), open-radio access network (O-RAN), etc.), these are merely examples for explanation. The various embodiments of the present disclosure can be easily modified and applied to other communication systems.

[0022] Figures 1a and 1b illustrate examples of wireless communication systems.

[0023] Referring to Fig. 1a, Fig. 1a illustrates a base station (101) and a terminal (120) as some of the nodes utilizing a wireless channel in a wireless communication system. Although Fig. 1a illustrates only one base station, the wireless communication system may further include other base stations identical or similar to the base station (101).

[0024] The base station (101) is a network infrastructure that provides wireless access to the terminal (120). The base station (101) has coverage defined based on the distance at which a signal can be transmitted. In addition to the base station, the base station (101) may be referred to as an 'access point (AP)', 'eNodeB (eNB)', '5th generation node', 'next generation nodeB (gNB)', 'wireless point', 'transmission / reception point (TRP)', or other terms having equivalent technical meanings.

[0025] The terminal (120) is a device used by a user and communicates with the base station (101) via a wireless channel. The link from the base station (101) to the terminal (120) is referred to as a downlink (DL), and the link from the terminal (120) to the base station (101) is referred to as an uplink (UL). In addition, although not shown in FIG. 1A, the terminal (120) and another terminal may communicate with each other via a wireless channel. At this time, the link between the terminal (120) and another terminal (device-to-device link, D2D) is referred to as a sidelink, and the sidelink may be used interchangeably with the PC5 interface. In some other embodiments, the terminal (120) may be operated without the involvement of a user. According to one embodiment, the terminal (120) is a device that performs machine type communication (MTC) and may not be carried by the user. Additionally, according to one embodiment, the terminal (120) may be an NB (narrowband)-IoT (internet of things) device.

[0026] The terminal (120) may be referred to as a terminal, or other terms such as 'user equipment (UE),' 'customer premises equipment (CPE),' 'mobile station,' 'subscriber station,' 'remote terminal,' 'wireless terminal,' 'electronic device,' or 'user device,' or other terms having equivalent technical meanings.

[0027] The base station (101) can perform beamforming with the terminal (120). The base station (101) and the terminal (120) can transmit and receive wireless signals in a relatively low frequency band (e.g., FR 1 (frequency range 1) of NR). In addition, the base station (101) and the terminal (120) can transmit and receive wireless signals in a relatively high frequency band (e.g., FR 2 (or, FR 2-1, FR 2-2, FR 2-3), FR 3 of NR), millimeter wave (mmWave) band (e.g., 28 GHz, 30 GHz, 38 GHz, 60 GHz)). In order to improve channel gain, the base station (101) and the terminal (120) can perform beamforming. Here, the beamforming can include transmission beamforming and reception beamforming. The base station (101) and the terminal (120) can provide directionality to a transmission signal or a reception signal. To this end, the base station (101) and the terminal (120) can select serving beams through a beam search or beam management procedure. After the serving beams are selected, subsequent communication can be performed through resources that have a QCL relationship with the resource that transmitted the serving beams.

[0028] The terminal (120) may be configured with cells of the base station (101) and carrier aggregation (CA). CA technology is a technology that increases the frequency usage efficiency of the terminal (120) and the base station (101) by connecting the terminal to a group of homogeneous wireless communication cells having a common radio resource control entity and simultaneously using frequency resources on component carriers of each cell located in different frequency bands for signal transmission and reception. The cells configured for CA may include one PCell (primary cell) and one or more SCells (secondary cells).

[0029] Referring to FIG. 1B, a terminal (120) may be configured in dual connectivity (DC) using a first base station (101-1) and a second base station (101-2). DC technology is a technology that increases frequency utilization efficiency by allowing a terminal to simultaneously connect to two independent heterogeneous or homogeneous wireless communication cell groups having separate radio resource control entities, and to use frequency resources on component carriers of cells within each cell group located in different frequency bands for signal transmission and reception. The terminal (120) is a technology for connecting to two different radio resource entities (e.g., a first base station (101-1), a second base station (101-2)) and using radio resources allocated by each radio resource entity. In MR-DC, a UE (e.g., terminal 120) in a radio resource control (RRC) connected state (i.e., RRC_CONNCETED) can be configured to utilize radio resources provided by two independent schedulers. Each scheduler can be located in an NG-RAN node (e.g., a first base station (101-1), a second base station (101-2)). Here, one node is a master node (MN) and the other node is a secondary node (SN). The MN and SN are connected via a network interface, and the MN can be connected to a core network. The SN may or may not be connected to the core network.

[0030] The MN may provide a master cell group (MCG). The MN, in addition to the MN, may be referred to as an M-NODE or an M-NG-RAN node. The MCG may include one or more cells. The MCG may include a PCell (primary cell). The MCG may include multiple aggregated cells. The MCG may include a PCell and one or more secondary cells (SCells). The SN may provide a secondary cell group (SCG). The SN, in addition to the SN, may be referred to as an S-NODE or an S-NG-RAN node. The SCG may include one or more cells. The SCG may include multiple aggregated cells. Like the MCG, the SCG may include a PCell and / or an SCell. A cell functioning as a PCell within the SCG may be referred to as a PSCell (primary secondary cell). The secondary cell group may include a PSCell and one or more SCells. Hereinafter, the term "SpCell" (special cell) may be used to encompass PCell and PSCell. "SpCell" refers to the primary cell of an MCG or SCG. In other words, an MCG SpCell refers to a PCell, and an SCG SpCell refers to an SCell.

[0031] The possible types of DC can be defined as follows:

[0032] 1) EN-DC: Dual connectivity in which the eNB is connected to the evolved packet core (EPC), and the UE is connected to the eNB acting as an MN and the gNB acting as an SN. Here, the gNB may be referred to as an en-gNB, and the en-gNB may or may not be connected to the EPC.

[0033] 2) NGEN-DC: Dual connectivity in which the eNB is connected to the 5GC (5G core), and the terminal is connected to the eNB operating as an MN and the gNB operating as an SN. Here, the eNB may be referred to as ng-eNB.

[0034] 3) NE-DC: Dual connectivity in which the gNB is connected to the 5GC, and the terminal is connected to the gNB operating as an MN and the eNB operating as an SN. Here, the eNB may be referred to as ng-eNB.

[0035] 4) NR-DC: Dual connectivity, where gNBs are connected to 5GCs, and the UE is connected to a gNB that acts as an MN and a gNB that acts as an SN. NR-DC can also be used when a UE is connected to a single gNB that acts as both an MN and SN and configures both an MCG and an SCG.

[0036] The terminal (120) can support MR (multi-radio)-DC. The terminal (120) can be connected to a first base station (101-1) and a second base station (101-2). The first base station (101-1) is an MN, and the second base station (101-2) is an SN, and can be connected to the terminal. With the CA (carrier aggregation) provided by each base station, the DC technology can provide higher data rates. The first base station (101-1) and the second base station (101-2), as MN and SN, respectively, can transmit downlink traffic to the terminal (120) or receive uplink traffic from the terminal (120).

[0037] Figure 2a shows examples of control planes (C-planes).

[0038] Referring to FIG. 2a, in the C-plane, the UE (110) and the AMF (235) can perform NAS (non-access stratum) signaling. In the C-plane, the UE (110) and the gNB (120) can perform communication according to protocols specified in the RRC layer, the PDCP layer, the RLC layer, the MAC layer, and the PHY layer, respectively.

[0039] The main functions of the RRC layer may include at least some of the following functions:

[0040] - Broadcasting of AS (Access Stratum) and NAS-related system information

[0041] - Paging initiated by 5GC (5G Core) or NG-RAN (Next Generation-Radio Access network)

[0042] - Establishment, maintenance and release of RRC connection between UE and NG-RAN, including control over RLC, MAC and PHY, specifically:

[0043] - Adding, modifying, and disabling carrier aggregation

[0044] - Add, modify and disable dual connectivity between NR or E-UTRA and NR.

[0045] - Security features including key management;

[0046] - Setup, configuration, maintenance, and release of SRB (Signaling Radio Bearer) and DRB (Data Radio Bearer).

[0047] - Movement features including:

[0048] - Handover and context transfer;

[0049] - UE cell selection and reselection and cell selection and reselection control;

[0050] - Inter-RAT mobility.

[0051] - QoS (quality of service) management function;

[0052] - UE measurement reporting and reporting control;

[0053] - Detection and recovery of radio link failures

[0054] - Sending messages from / to UE to / from NAS.

[0055] The main functions of the PDCP layer may include at least some of the following functions:

[0056] - Header compression and decompression (ROHC only)

[0057] - User data transfer function

[0058] - In-sequence delivery of upper layer PDUs

[0059] - Out-of-sequence delivery of upper layer PDUs

[0060] - PDCP PDU reordering for reception

[0061] - Duplicate detection of lower layer SDUs

[0062] - Retransmission function (Retransmission of PDCP SDUs)

[0063] - Encryption and decryption functions (Ciphering and deciphering)

[0064] - Timer-based SDU discard in uplink.

[0065] The main functions of the RLC layer may include at least some of the following functions:

[0066] - Data transfer function (Transfer of upper layer PDUs)

[0067] - In-sequence delivery of upper layer PDUs

[0068] - Out-of-sequence delivery of upper layer PDUs

[0069] - ARQ function (Error Correction through ARQ)

[0070] - Concatenation, segmentation and reassembly of RLC SDUs

[0071] - Re-segmentation of RLC data PDUs

[0072] - Reordering of RLC data PDUs

[0073] - Duplicate detection function

[0074] - Protocol error detection

[0075] - RLC SDU discard function

[0076] - RLC re-establishment function

[0077] The MAC layer can be connected to multiple RLC layer devices configured in one terminal, and the main functions of the MAC can include at least some of the following functions.

[0078] - Mapping between logical channels and transport channels

[0079] - Multiplexing / demultiplexing of MAC SDUs

[0080] - Scheduling information reporting function

[0081] - Error correction through HARQ

[0082] - Priority handling between logical channels of one UE

[0083] - Priority handling between UEs by means of dynamic scheduling

[0084] - MBMS service identification function

[0085] - Transport format selection function

[0086] - Padding function

[0087] The physical layer can perform operations such as channel coding and modulating upper layer data, converting it into OFDM symbols and transmitting it over a wireless channel, or demodulating and channel decoding OFDM symbols received over a wireless channel and transmitting them to the upper layer.

[0088] Figure 2b shows examples of user planes (U-planes).

[0089] Referring to FIG. 2b, in the U-plane, the UE (110) and the gNB (120) can perform communication according to protocols specified in each of the SDAP layer, PDCP layer, RLC layer, MAC layer, and PHY layer. For the PDCP layer, RLC layer, MAC layer, and PHY layer, excluding the SDAP layer, the description for FIG. 2a may be referred to.

[0090] The SDAP layer can provide QoS flows for 5GC. A single SDAP protocol entity can be configured for each individual PDU session, and the SDAP layer's functionality can include at least some of the following functions:

[0091] - Mapping between QoS flows and data radio bearers;

[0092] - Display QoS flow ID (QFI) in both DL and UL packets.

[0093] Figures 3a, 3b, and 3c illustrate examples of function split according to communication protocols. A base station (e.g., base station (101) of Figure 1a) may operate as an eNB or gNB depending on the radio access technology (RAT) provided. For example, the base station may be referred to as an NG-RAN node. The base station may be implemented in a distributed deployment according to a central unit (CU) configured to perform functions of upper layers of an access network (e.g., packet data convergence protocol (PDCP), radio resource control (RRC)) and a distributed unit (DU) configured to perform functions of lower layers.

[0094] Referring to FIG. 3A, in the control plane, the CU (310) may be connected to one or more DUs (e.g., DU (320)) and may be responsible for functions of a higher layer than the DU. For example, the CU (310) may be responsible for functions of the RRC layer (311) and the PDCP layer (312). The CU (310) may transmit or receive messages to or from the DU (320) through the F1 interface (340). In the control plane, the DU (320) may be responsible for functions of the RLC layer (321), the MAC layer (322), and the PHY layer (323). For a description of the functions of the RRC layer (311) of the CU (310), reference may be made to the description of the RRC layer of FIG. 2A. For a description of the functions of the PDCP layer (312) of the CU (310), reference may be made to the description of the PDCP layer of FIG. 2A. For a description of the functions of the RLC layer (321) of the DU (320), reference may be made to the description of the RLC layer of FIG. 2A. For a description of the functions of the MAC layer (322) of the DU (320), reference may be made to the description of the MAC layer of FIG. 2A. For a description of the functions of the PHY layer (323) of the DU (320), reference may be made to the description of the PHY layer of FIG. 2A. The DU (320) may perform an operation of channel coding and modulating upper layer data through the physical layer (323), converting it into an OFDM symbol and transmitting it through a wireless channel, or demodulating and channel decoding an OFDM symbol received through a wireless channel and transmitting it to a higher layer.

[0095] Referring to FIG. 3b, in the user plane, a CU (310) may be connected to one or more DUs (e.g., DU (320)) and may be responsible for functions of a higher layer than the DU. For example, the CU (310) may be responsible for functions of the SDAP layer (361) and the PDCP layer (362). The CU (310) may transmit messages to or receive messages from the DU (320) through the F1 interface (350) (e.g., F1-U). The CU (310) may be referred to as a node hosting a PDCP entity for the PDCP layer (362) in terms of performing functions for the PDCP layer (362). The DU (320) may be referred to as a node that interacts with the node hosting the PDCP entity for flow control. In the user plane, the DU (320) may be responsible for the functions of the RLC layer (371), the MAC layer (372), and the PHY layer (373). For a description of the functions of the SDAP layer (361) of the CU (310), reference may be made to the description of the SDAP layer in FIG. 2B. For a description of the functions of the PDCP layer (362) of the CU (310), reference may be made to the description of the PDCP layer in FIG. 2B. For a description of the functions of the RLC layer (321) of the DU (320), reference may be made to the description of the RLC layer in FIG. 2B. For a description of the functions of the MAC layer (322) of the DU (320), reference may be made to the description of the MAC layer in FIG. 2B. For a description of the functions of the PHY layer (323) of the DU (320), reference may be made to the description of the PHY layer in FIG. 2B.

[0096] Referring to FIG. 3C, an example of the protocol layers of the user plane in dual connectivity is illustrated. Different DUs (e.g., DU 320 and DU 330) may be connected to a single CU (310). DU (330) may include an RLC entity for an independent RLC layer (381) and a MAC entity for a MAC layer (382), separate from DU (320). DU (330) may also provide a UE (e.g., terminal (120)) with an access network distinct from the access network of DU (320). From the UE perspective, two separate MAC entities (e.g., a first MAC entity for the MAC layer (372) and a second MAC entity for the MAC layer (382)) may represent dual connectivity for the UE.

[0097] Although FIGS. 3A, 3B, and 3C illustrate that a DU (e.g., DU (320)) is responsible for a physical layer (e.g., physical layer (323), physical layer (373)), embodiments of the present disclosure are not limited thereto. According to an implementation example, the DU (320) may perform some functions of the physical layer (high PHY), and an RU connected to the DU (320) may be responsible for the remaining functions of the physical layer (low PHY). In addition, as an example, a DU (digital unit) may be included in a DU (distributed unit) (320) according to a distributed deployment implementation of a base station. As a non-limiting example, a DU (digital unit) may also refer to an entity that includes a CU and a DU (distributed unit) in a structure in which a CU, a DU (distributed unit), and an RU are deployed in that order.

[0098] Figure 4 illustrates an example of signaling between a central unit (CU) and a distributed unit (DU). Figure 4 illustrates examples of messages on the F1 interface (350) (e.g., F1-U) between a CU (310) and a DU (320) in the user plane (U-plane). The same reference numerals used in the following specification may indicate the same description.

[0099] Referring to FIG. 4, CU (310) can transmit a status message (410) to DU (320).

[0100] 1. Sending status messages

[0101] The CU (310) may transmit a status message (410) to the DU (320) via the F1 interface (350) (e.g., F1-U). In one embodiment, the status message (410) may be used to provide downlink data delivery status (DDDS) to the CU (310). The procedure for transmitting the status message (410) may enable the CU (310) to control the downlink user data flow of each data radio bearer (DRB) by providing feedback from the DU (320) to the CU (310). The procedure for transmitting the status message (410) may be used to provide feedback from the DU (320) to the CU (310) to allow the CU (310) to control the successful delivery of downlink control data. As a non-limiting example, the DU (320) may also transmit uplink user data of a related data radio bearer to the CU (310) via a status message (410). In this case, the data radio bearer of the uplink user data and the radio bearer of the status message (410) may be associated with the same protocol data unit (PDU).

[0102] The status message (410) may include various information. For example, in RLC AM (acknowledged mode), the status message (410) may include the highest NR PDCP PDU sequence number that has been successfully and sequentially delivered to the UE among the PDCP PDUs received from the CU (310). Here, retransmitted NR PDCP PDUs may be excluded from the PDUs. For example, the status message (410) may include information about a desired buffer size for the corresponding data radio bearer or multicast / broadcast service radio bearer (MRB). The desired buffer size may be indicated in bytes. For example, the status message (410) may optionally include information about a desired data rate associated with a specific data radio bearer configured for the UE or MRB. The desired data rate may be indicated in bytes. The value indicated in bytes above may represent the amount of data transmitted per unit time (e.g., 1 second). For example, the status message (410) may include information about NR-U packets that have been declared "lost" and have not yet been reported to the CU (310) within the status message (410) (e.g., a downlink data forwarding status (DDDS) frame of Table 1). For example, the status message (410) may include information about the NR PDCP PDU sequence number associated with the highest NR-U sequence number among the retransmitted NR PDCP PDUs successfully delivered to the UE in the order of NR-U sequence numbers, if a retransmitted NR PDCP PDU has been delivered.For example, the status message (410) may include information about the NR PDCP PDU sequence number associated with the highest NR-U sequence number among the retransmitted NR PDCP PDUs transmitted to the lower layer in the order of NR-U sequence numbers when a retransmitted NR PDCP PDU is transmitted to the lower layer. For example, the status message (410) may include information about the highest NR PDCP PDU sequence number transmitted to the lower layer among the NR PDCP PDUs received from the CU (310). Here, the retransmitted NR PDCP PDU may be excluded from the PDUs. For example, in RLC AM, the status message (410) may include information about the NR PDCP PDU sequence number that was successfully delivered to the UE out of order among the NR PDCP PDUs received from the CU (310). Here, the retransmitted NR PDCP PDU may be excluded from the PDUs.

[0103] The status message (410) may be triggered based on an event. For example, when the DU (320) detects successful random access channel (RACH) access of a UE (e.g., terminal (120)) to the corresponding data radio bearer, the DU (320) may transmit the status message (410) to the CU (310). The CU (310) may initiate downlink data transmission before receiving the status message (410). For example, the status message (410) may have the following format, referred to as a downlink data forwarding status (DDDS) frame.

[0104]

[0105] Referring to Table 1, when the status message (410) is the last downlink status report, the status message (410) may include a separate indicator (e.g., Final Frame Ind.). Upon receiving the indicator, the CU (310) may consider that no further UL or DL ​​data transmission is expected between the DU (320) and the terminal (120). The status message (410) may include a detected indicator of a radio link outage or radio link resume for the relevant data radio bearer. For example, a specific value of a parameter (e.g., "Cause Value") may indicate a radio link outage (e.g., a value of '1' of the parameter indicates a radio link outage) or a radio link resume (e.g., a value of '2' of the parameter indicates a radio link resume). For example, through the value of the above parameter, a wireless link interruption or wireless link resumption can be indicated by both the downlink and the uplink, by the downlink only, or by the uplink only.

[0106] Referring to Table 1, 'Desired buffer size for the data radio bearer' can indicate the requested buffer size in bytes for the related data radio bearer. 'Desired buffer size for the data radio bearer' is a 4-octet structure, and is 0 to 2. 32 -1 value. For example, 'Desired Data Rate' represents the amount of data in bytes desired to be received during a specific time period (e.g., 1 second). 'Desired Data Rate' is a 4-octet structure, and can be 0 to 2. 32 It can have a value of -1.

[0107] The CU (310) can receive a status message (410) from the DU (320). The CU (310) can determine a desired buffer size (e.g., 'Desired buffer size for the data radio bearer') and a data rate (e.g., 'Desired Data Rate') as the amount of data to be transmitted from the CU (310). If the value of the desired buffer size is 0, the CU (310) can stop data transmission of the corresponding bearer. If the value of the desired buffer size is greater than 0, the CU (310) can transmit data up to the amount of data indicated by the desired buffer size per bearer. For example, the data may include data to be retransmitted. The above data may include, in addition to the retransmitted data, new data starting from the last "highest successfully delivered NR PDCP sequence number" (e.g., 'Highest successfully delivered NR PDCP Sequence Number') for RLC AM or starting from the last "highest transmitted NR PDCP sequence number" (e.g., 'Highest transmitted NR PDCP Sequence Number') for RLC UM. The value of the requested data rate indicates the amount of data desired to be received for about 1 second. Information about the requested buffer size and information about the requested data rate may be valid until the next status message is received.

[0108] 2. Transmission of user data

[0109] DU (320) can transmit user data (420) to CU (310). The purpose of the transmission procedure of user data (420) is to provide NR-U specific sequence number information when transmitting user data (420) carrying DL NR PDCP PDU from CU (310) to DU (320). In downlink, NR user plane protocol instance using the transmission procedure of user data (420) can be associated with only a single radio bearer. CU (310) can assign consecutive NR-U sequence numbers to each transmitted NR-U packet. A retransmitted NR PDCP PDU must be assigned a new NR-U sequence number. CU (310) can inform DU (320) whether this NR-U packet is a retransmission of an NR PDCP PDU. The CU (310) may also instruct the DU (320) to discard all NR PDCP PDUs up to and including the defined DL discard NR PDCP PDU SN or to discard one or more downlink NR PDCP PDU blocks.

[0110] For example, user data (420) may have the following format.

[0111]

[0112] Referring to Table 2, for example, 'NR-U Sequence Number' represents the NR-U sequence number allocated by CU (310). 'NR-U Sequence Number' is a 3-octet structure, and is 0 or more and 2 24 -1 value. For example, 'DL discard NR PDCP PDU SN' can indicate the SN when PDUs up to NR PDCP PDU SN are discarded. 'DL discard NR PDCP PDU SN' is a 3-octet structure, 0 to 2. 18It can have a value of -1. For example, 'DL discard Number of blocks' represents the downlink blocks to be discarded. 'DL discard Number of blocks' is a 1-octet structure and can have a value greater than or equal to 1 and less than or equal to 244. For example, 'DL discard NR PDCP PDU SN start' represents the starting SN of the block to be discarded, and 'Discarded Block size' represents the number of PDCP PDUs to be discarded from the starting SN.

[0113] In FIG. 4, NR PDCP PDU is described as an example as a downlink packet, but the embodiments of the present disclosure are not limited thereto. PDCP PDUs on the W1 interface between eNB-DU and eNB-CU may also be applied to the embodiments of the present disclosure. In other words, downlink packets include PDCP PDUs in an LTE network, and CU (310) and DU (320) may correspond to eNB-CU and eNB-DU constituting an eNB, respectively. The following description of the F1 interface (350) (e.g., F1-U) may also be equally applied to the W1 interface between eNB-CU and eNB-DU.

[0114] According to one embodiment, a base station (e.g., base station (110) of FIG. 1A) may include an upper base station and a lower base station. The upper base station (e.g., CU (310)) may identify congestion in a lower base station (e.g., DU (320)). The upper base station may transmit information about the congestion of the lower base station to a core network (e.g., user plane function (UPF)) to reduce latency. In the following specification, technical features for an upper base station to identify congestion in a lower base station and transmit information about the congestion of the lower base station to a core network will be described. In the following specification, for convenience of explanation, the upper base station will be described as CU (310), and the lower base station will be described as DU (320). This is for convenience of explanation and is not limited thereto.

[0115] Figure 5 illustrates an example in which information about a DU is transmitted to a CU.

[0116] Referring to FIG. 5, a base station (e.g., base station (101) of FIG. 1A) of a wireless communication system for the long term evolution (LTE) standard and / or the new radio (NR) standard may support dual connectivity including EN-DC (E-UTRA (evolved universal terrestrial radio access)-NR dual connectivity) and / or NR-DC, or may be configured as a separate base station.

[0117] For example, a network element (NE) constituting a base station may include a CU (310), a DU (320), and / or a radio unit (RU) (not shown). For example, a CU (310) may be connected to one or more DUs (e.g., a DU (320)) and may be responsible for a function of a higher layer than the DU (320). For example, the CU (310) may be responsible for functions of the RRC (radio resource control) and PDCP (packet data convergence protocol) layers. The DU (320) and the RU (not shown) may be responsible for functions of lower layers.

[0118] For example, the CU (310) can manage the buffer of the DU (320) through flow control. The DU (320) can perform some functions (high PHY) of the RLC (radio link control), MAC (media access control), and PHY (physical) layers, and the RU (not shown) can be responsible for the remaining functions (low PHY) of the PHY layer.

[0119] In operation 510, the CU (310) may transmit downlink user data to the DU (320). For example, the downlink user data may include an NR PDCP PDU. For example, the downlink user data may include data for requesting a downlink data delivery status (DDDS) frame (hereinafter, DDDS frame). The downlink user data may include data for requesting auxiliary information.

[0120] In operation 520, the DU (320) may transmit a DDDS frame to the CU (310). The DDDS frame may include information regarding the status of downlink data received from the CU (310). For example, the DDDS frame may be an example of the status message (410) of FIG. 4.

[0121] For example, a DDDS frame may include information about a desired buffer size (DBS) and / or information about a lost NR-U sequence number. The DU (320) may request data to be received from the CU (310) by transmitting the desired buffer size information to the CU (310). The CU (310) may transmit a buffered packet to the DU (320) based on the desired buffer size information. In this case, if the size of the data buffered in the CU (310) is larger than the size of the data requested according to the desired buffer size information of the DU (320), the number of packets buffered in the CU (310) may increase. As the number of packets buffered in the CU (310) increases, packet delay (or buffering delay) may increase.

[0122] In operation 530, the DU (320) may transmit auxiliary information to the CU (310). For example, the auxiliary information may include link information. The link information may include, for example, at least one of channel quality information (CQI), hybrid automatic repeat request (HARQ) information, and / or power headroom report (PHR) information. For example, the auxiliary information may have the following format.

[0123]

[0124] According to the operation according to L4S, network congestion can be detected and explicit congestion notification (ECN) can be used to notify of it. For example, ECN marking can be performed by setting the CE (congestion experience) bit in the IP header (internet protocol header) to a designated value (e.g., '3') in proportion to the degree of congestion according to the proportional ECN marking (PEM) method. Network devices deployed in the E2E path can identify congestion and perform ECN marking according to the degree of congestion (or latency). The client can send information about the ratio of packets on which ECN marking was performed to all packets to the server. The server can reduce the transmission rate to alleviate congestion and reduce latency along the E2E path based on the information about the ratio of packets on which ECN marking was performed to all packets.

[0125] For example, ECN marking can be performed based on setting (or changing) the value of the ECN field included in the IP header. For example, the ECN field can be set to 2 bits. If the value of the ECN field is the first value (e.g., '00'), it can indicate that the IP packet does not use the ECN function. If the value of the ECN field is the first value (e.g., '01') or the second value (e.g., '10'), it can indicate that the TCP protocol also supports the ECN function. If the value of the ECN field is the third value (e.g., '11'), it can indicate that congestion has occurred. Hereinafter, performing ECN marking can mean setting (or changing) the value of the ECN field to the third value (or a specified value).

[0126] In mobile networks, the E2E path between servers (e.g., application servers) and clients typically accounts for a significant portion of latency. Therefore, introducing L4S to base stations can improve latency performance.

[0127] For example, in the above-described separated base station structure, the cause of delay occurring within the mobile communication network may mostly occur in the lower base station (e.g., DU (320) or RU (not shown)). For example, the cause of the delay may include at least one of a deterioration in the quality of the wireless network, an increase in the number of users, a scheduling delay due to an increase in data, and / or a lack of wireless resources.

[0128] In order to apply ECN marking of L4S, the IP header of the packet transmitted from the application must be modified. Therefore, ECN marking must be performed at the upper base station (e.g., CU (310)) before performing any operation (or processing) related to ciphering and / or integrity for the packet. Therefore, in order to apply probabilistic ECN marking (or PEM method), the upper base station (e.g., CU (310)) needs to obtain information affecting latency from the lower base station (e.g., DU (320)). For example, the information affecting latency may include a channel quality index (CQI), a modulation and coding scheme (MCS), and / or a scheduling delay value. The upper base station (e.g., CU (310)) may need to obtain the information affecting latency from the lower base station (e.g., DU (320)) through a DDDS frame and / or auxiliary information. If information affecting latency is transmitted via DDDS frames and / or auxiliary information, it can result in additional resource waste and increase the complexity of the ECN marking algorithm. Furthermore, the time required to acquire information affecting latency can make it difficult to achieve low latency.

[0129] Accordingly, in the following specification, technical features for identifying congestion based on at least one of DBS information received from DU (320) in CU (310), the number of packets buffered in CU (310), and / or buffering delay will be described. In addition, technical features for determining criteria for probabilistically performing ECN marking (or L4S) on packets and performing ECN marking according to the determined criteria for congestion mitigation and E2E latency reduction will be described below. In addition, when L4S is performed in an upper core network (e.g., UPF), technical features for performing ECN marking (or L4S) on packets in the core network will be described below.

[0130] Figure 6 illustrates an example of the operation of a CU for performing ECN marking.

[0131] Figure 7 shows the ECN marking probability according to buffering delay.

[0132] The terms '...bu', '...gi', '...mul', '...che', etc. used below may mean at least one shape structure or a unit that processes a function.

[0133] The CU (310) can identify (or track) DBS information received from the DU (320) and the amount of change in DBS. The CU (310) can perform ECN marking on packets based on the number of packets buffered in the CU (310) (or a buffer within the CU (310)) and the buffering delay. The CU (310) can secure E2E latency performance by using the number of buffered packets and the buffering delay for the ECN marking probability. Since the number of buffered packets and the buffering delay are directly used for calculating the ECN marking probability, the complexity of the implementation can be reduced.

[0134] According to one embodiment, when ECN marking is performed in a core network (e.g., UPF (610)), the CU (310) may transmit information about an ECN marking probability identified based on information obtained from the CU (310) or obtained information to the core network.

[0135] According to one embodiment, in a split base station structure, the DU (320) can request the size of acceptable data from the CU (310) using the DBS information included in the DDDS frame. For example, if congestion occurs in the DU (320), the size of the DBS can be reduced. The DU (320) transmits the DBS information to the CU (310), and the CU (310) can identify (or track) changes in the DBS value. The CU (310) can perform ECN marking based on the number of buffered packets in the CU (310) due to congestion of the DU (320), the increase rate of the number of buffered packets, and / or the buffering delay. Accordingly, low latency can be achieved in E2E. Hereinafter, the specific operation of the CU (310) for the above-described operation will be described.

[0136] Referring to FIG. 6, the CU (310) may include a buffer (601), an ECN marking unit (602), a PDCP stack (603), and / or an ECN marking decision unit (604). For example, the CU (310) may receive data through a core network (e.g., UPF (610)). The CU (310) may (temporarily) store the received data in the buffer (601). The CU (310) may transfer the stored data to the PDCP stack (603) to transmit the data stored in the buffer (601) to the DU (320). The CU (310) may transmit the data to the DU (320) through the PDCP stack (603). For example, the CU (310) may perform ECN marking on a packet regarding the data stored in the buffer (601) using the ECN marking unit (602). CU (310) can use ECN marking unit (602) to transfer packets on which ECN marking has been performed to PDCP stack (603) and transmit the packets to DU (320).

[0137] According to one embodiment, the CU (310) may perform probabilistic ECN marking based on the buffering delay of the CU (310). For example, the CU (310) may identify a buffering delay identified (or generated) in the PDCP stack (603). For example, the buffering delay may refer to the time from when data is stored in the buffer (601) to when the data is transmitted to the PDCP stack (603). This is exemplary, and the time points for measuring (or identifying) the buffering delay may be changed.

[0138] The ECN marking decision unit (604) can determine (or identify, calculate) the ECN marking probability using the buffering delay obtained from the PDCP stack (603). For example, the ECN marking decision unit (604) can determine the ECN marking probability based on the graph of FIG. 7.

[0139] Referring to FIG. 7, if the buffering delay is within the first interval (701), the CU (310) can identify that no congestion has occurred. If the buffering delay is within the first interval (701), the CU (310) can determine the ECN marking probability to be '0'. For example, the first interval (701) can have a buffering delay set between 0 and a first threshold value (th1). If the buffering delay is less than or equal to the first threshold value, the CU (310) can identify (or determine) that no congestion has occurred.

[0140] When the buffering delay is within the second section (702), the CU (310) can change the ECN marking probability according to the buffering delay. For example, the CU (310) can set the buffering delay and the ECN marking probability to be mapped 1 to 1. The second section (702) can be set between a first threshold value (th1) and a second threshold value (th2). The second section (702) can be set as a section that exceeds the first threshold value (th1) and is less than or equal to the second threshold value (th2). Within the second section (702), the buffering delay and the ECN marking probability can be set to have a linear relationship.

[0141] If the buffering delay is within the third interval (703), the CU (310) can identify that congestion is severe. If the buffering delay is within the third interval (703), the CU (310) can determine the ECN marking probability as '1'. For example, the third interval (703) can be set as an interval exceeding the second threshold value (th2).

[0142] The ECN marking probability according to the buffering delay illustrated in Fig. 7 is exemplary, and the ECN marking probability according to the buffering delay can be set in various ways.

[0143] Referring again to FIG. 6, the CU (310) can receive a DDDS frame from the DU (320). The DDDS frame can include DBS information (or a DBS value). The CU (310) can perform probabilistic ECN marking based on the DBS information.

[0144] For example, the CU (310) can set the DBS value in a state where no congestion occurs as a reference value. The CU (310) can determine the ECN marking probability according to the rate at which the DBS value decreases. For example, in an initial state where no congestion occurs, the DBS value can be x [Mbits] (e.g., 10 [Mbits]). The CU (310) can set the reference value to x [Mbits]. As congestion occurs, the DU (320) can request the CU (310) for a DBS value of y [Mbits] (e.g., 8 [Mbits]). The CU (310) ECN marking can be performed with a probability of (z is a constant) (e.g. 1-0.8z).

[0145] According to one embodiment, the CU (310) may perform probabilistic ECN marking based on the number of packets buffered in the CU (310) (or buffer (601)). The CU (310) may determine the ECN marking probability according to the excess ratio when the number of buffered packets exceeds a reference value based on the maximum value of the number of buffered packets in a state where no congestion occurs. For example, in a state where no congestion occurs, when the number of buffered packets is maintained between 0 and 100, but 120 packets are instantaneously stored in the buffer (601), the ECN marking probability may be determined according to the following mathematical equation.

[0146]

[0147] Referring to Equation 1, p is the ECN marking probability. min(a,b) is a function that outputs the smaller value between a and b. x is a constant.

[0148] According to one embodiment, the CU (310) can obtain information about the ECN marking probability determined in the DU (320) from the DU (320). The CU (310) can also determine the ECN marking probability based on the information about the ECN marking probability determined in the DU (320). For example, the information about the ECN marking probability determined in the DU (320) can be transmitted through auxiliary information (e.g., auxiliary information (530) of FIG. 5). For example, the information about the ECN marking probability can include uplink congestion information (UL congestion information) and / or downlink congestion information (DL congestion information). The uplink congestion information can indicate the ECN marking probability for an uplink packet. The downlink congestion information can indicate the ECN marking probability for a downlink packet.

[0149] As described above, the CU (310) can perform probabilistic ECN marking using at least one of DBS information, the number of buffered packets, and / or buffering delay. In the above-described embodiment, the ECN marking probability according to each of DBS information, the number of buffered packets, and buffering delay has been described, but this is for convenience of explanation, and the ECN marking probability can be determined according to at least some of DBS information, the number of buffered packets, and / or buffering delay.

[0150] Although the above-described embodiment has described an example in which the CU (310) determines the ECN marking probability based on at least one of DBS information, the number of buffered packets, and / or buffering delay, the CU (310) may transmit the DBS information, the number of buffered packets, and / or the buffering delay to the core network, and the ECN marking probability may be determined in the core network (e.g., UPF (610). According to an embodiment, the CU (310) may also transmit the ECN marking probability to the core network.

[0151] In the following Figures 8a and 8b, examples of ECN marking probability and / or information for determining ECN marking probability being transmitted to the core network will be described.

[0152] Figures 8a and 8b illustrate examples of information transmitted to the core network.

[0153] Referring to FIG. 8a, the CU (310) can transmit DBS information (801), information on buffering delay (802), and / or information on the number of buffered packets (803) received from the DU (320) to the core network (e.g., UPF (601)).

[0154] For example, DBS information (801) may be composed of N1 octets. DBS information (801) may be indicated in units of bytes through N1 octets. Information (802) about buffering delay may be composed of N2 octets. Information (802) about buffering delay may be indicated in units of [ms] (milliseconds) through N2 octets. Information (803) about the number of buffered packets may be composed of N3 octets. Information (803) about the number of buffered packets may be indicated in units of integers through N3 octets.

[0155] Referring to FIG. 8b, the CU (310) can transmit information (804) about an ECN marking probability obtained based on DBS information (801), information about buffering delay (802), and / or information about the number of buffered packets (803) to the core network.

[0156] For example, information on ECN marking probability (804) can be expressed as an interval between 0 and 1, which can be expressed as M octets. An interval between 0 and 1 It can be divided into a plurality of probability intervals that are discrete in size. For example, the CU (310) can determine a probability interval closest to the determined ECN marking probability among the plurality of probability intervals, and configure information (804) on the ECN marking probability corresponding to the determined probability interval.

[0157] According to one embodiment, the information illustrated in FIG. 8a (e.g., DBS information (801), information on buffering delay (802), and / or information on the number of buffered packets (803) received from DU (320)) and the information illustrated in FIG. 8b (e.g., information on ECN marking probability (804)) may be transmitted together to the core network. According to an embodiment, at least some of the information illustrated in FIG. 8a and the information illustrated in FIG. 8b may be transmitted to the core network.

[0158] For example, when L4S is applied in the core network, the core network can identify an ECN marking probability value to respond to congestion occurring in the RAN (e.g., DU (320) and RU (220)). As an example, the core network can determine the ECN marking probability based on at least some of the information illustrated in FIG. 8a. As an example, the core network can identify the ECN marking probability based on the information illustrated in FIG. 8b.

[0159] According to one embodiment, at least some of the information illustrated in FIG. 8A and FIG. 8B may be included in a GTP-U (general packet radio system tunneling protocol-user plane) packet header transmitted to the core network. According to one embodiment, when there is no uplink traffic, at least some of the information illustrated in FIG. 8A and FIG. 8B may be included in a dummy GTP-U packet. The dummy GTP-U packet may be transmitted to the core network.

[0160] For example, a GTP-U header may have the following format:

[0161]

[0162] 2) This field shall only be evaluated when indicated by the PN flag set to 1.

[0163] 3) This field shall only be evaluated when indicated by the E flag set to 1.

[0164] 4) This field shall be present if and only if any one or more of the S, PN and E

[0165] As a non-limiting example, the network-protocol data unit (N-PDU) number field and / or the Next Extension Header Type field may be omitted within the GTP-U header.

[0166] Figure 9 is a flowchart of the operation of an electronic device for performing marking of an ECN field.

[0167] Referring to FIG. 9, in operation 910, an electronic device (e.g., CU (310)) may receive a message indicating a downlink data delivery status from a DU (e.g., DU (320)). For example, the message indicating the downlink data delivery status may include at least one of the DDDS frame (520) of FIG. 5 and / or the auxiliary information (530) of FIG. 5. As an example, the message indicating the downlink data delivery status may include at least some or all of the information in Table 1. The message indicating the downlink delivery status may include information about a desired buffer size. As an example, the message indicating the downlink data delivery status may include at least some or all of the information in Table 3. For example, the message indicating the downlink data delivery status may include uplink congestion information identified in the DU and / or downlink congestion information identified in the DU. For example, the uplink congestion information identified in the DU may indicate a probability that the ECN field for the uplink packet identified in the DU will be marked with a designated value indicating congestion. For example, the downlink congestion information identified in the DU may indicate a probability that the ECN field for the downlink packet identified in the DU will be marked with a designated value indicating congestion. The probabilities based on the uplink congestion information identified in the DU and / or the downlink congestion information identified in the DU may be identified in the DU. The probabilities may be distinguished from the probabilities that the ECN field for the downlink packet identified in the CU will be marked with a designated value indicating congestion.

[0168] At operation 920, the electronic device may determine a probability that the ECN field will be marked with a specified value indicating congestion based on a message indicating a forwarding status of downlink data.

[0169] According to one embodiment, an electronic device may obtain information about a requested buffer size based on a message indicating a transmission status of downlink data. For example, the electronic device may obtain information about the requested buffer size based on a received message. For example, the electronic device may obtain information about the requested buffer size by identifying information about the requested buffer size included in the received message. For example, information about the requested buffer size may be related to the downlink data processing capability of a DU. Information about the requested buffer size may be related to the size of downlink data that the DU requests from a CU. A larger requested buffer size may indicate lower network congestion for the DU. A smaller requested buffer size may indicate higher network congestion for the DU.

[0170] For example, based on information about the requested buffer size, the electronic device can identify a ratio of the requested buffer size based on the information about the requested buffer size to a reference requested buffer size in a normal state. Based on the ratio, the electronic device can determine a probability that the ECN field will be marked with a specified value indicating congestion.

[0171] For example, an electronic device can track changes in the requested buffer size. Based on the changes in the requested buffer size, the electronic device can predict (or identify) network congestion for a DU. The electronic device can determine the probability that the ECN field will be marked with a specified value indicating congestion, such that the decrease in the requested buffer size is proportional.

[0172] According to one embodiment, the electronic device may determine the probability that the ECN field will be displayed with a specified value indicating congestion based on delay information regarding a buffer of the electronic device. For example, the electronic device may identify delay information regarding a buffer contained in a memory of the electronic device. Based on the identified delay information, the electronic device may determine the probability that the ECN field will be displayed with a specified value indicating congestion.

[0173] For example, an electronic device may identify a delay time based on delay information. The delay time may be related to the length of the time interval between a first time a packet received from another device for a user plane function is stored in a buffer of the electronic device and a second time the packet is transmitted to the DU.

[0174] The electronic device may determine, based on a delay time within a first range (e.g., the first section (701) of FIG. 7), that the probability that the ECN field will be marked with a designated value indicating congestion is 0. The electronic device may determine, based on identifying that the delay time is within the first range, that the probability that the ECN field will be marked with a designated value indicating congestion is 0.

[0175] The electronic device may determine, based on a delay time within a second range (e.g., the second section (702) of FIG. 7), a probability that the ECN field will be displayed with a designated value indicating congestion, with a probability corresponding to the delay time. The electronic device may determine, based on identifying that the delay time is within the first range, a probability that the ECN field will be displayed with a designated value indicating congestion, with a probability corresponding to the delay time.

[0176] The electronic device may determine a probability that the ECN field will be marked with a designated value indicating congestion as 1 based on a delay time within a third range (e.g., the third section (703) of FIG. 7). The electronic device may determine a probability that the ECN field will be marked with a designated value indicating congestion as 1 based on identifying that the delay time is within the third range.

[0177] For example, an electronic device can predict (or identify) network congestion for a DU based on the magnitude of the delay. The electronic device can determine the probability that the ECN field will be marked with a specified value indicating congestion, proportional to the delay.

[0178] According to one embodiment, the electronic device may determine the probability that the ECN field will be displayed with a specified value indicating congestion based on the number of packets stored in the buffer of the electronic device. For example, the electronic device may identify the number of packets stored in a buffer contained in the memory of the electronic device. The electronic device may determine the probability that the ECN field will be displayed with a specified value indicating congestion based on the number of packets stored in the buffer.

[0179] For example, an electronic device may monitor the number of packets buffered within the electronic device. Based on the number of packets buffered within the electronic device, the electronic device may predict (or identify) network congestion for a DU. The electronic device may determine the probability that the ECN field will be displayed with a specified value indicating congestion, proportional to the increase in the number of buffered packets.

[0180] According to one embodiment, the electronic device can determine a probability that the ECN field will be marked with a specified value indicating congestion based on at least one of information about the requested buffer size, delay information about the buffer, and / or the number of packets stored in the buffer.

[0181] In operation 930, the electronic device may mark the ECN field of at least one packet among the packets transmitted from the CU to the DU with a designated value. For example, the electronic device may mark the ECN field of at least one packet among the packets transmitted from the CU to the DU with a designated value based on a probability that the ECN field is marked with a designated value indicating congestion. As an example, the electronic device may set a ratio of at least one packet to the packets with the designated probability.

[0182] According to one embodiment, the operation of marking the ECN field with a designated value may be performed by another device for user plane functionality (e.g., UPF (610) of FIG. 6). For example, the electronic device may transmit, to the other device for user plane functionality, information about a probability that the ECN field will be marked with a designated value indicating congestion. For example, the electronic device may transmit, to the other device for user plane functionality (e.g., UPF (610) of FIG. 6), at least one of information about a requested buffer size, delay information about the buffer, and / or the number of packets stored in the buffer. The other device may determine, based on at least one of the information about the requested buffer size, delay information about the buffer, and / or the number of packets stored in the buffer, the probability that the ECN field will be marked with a designated value indicating congestion.

[0183] According to one embodiment, a communication device configured to perform functions of a central unit (CU) may include a transceiver, at least one processor including processing circuitry, and one or more storage media, and a memory storing instructions. The instructions, when individually or collectively executed by the at least one processor, may cause the communication device to receive, through the transceiver, a message indicating a forwarding status of downlink data from a distributed unit (DU) connected to the CU. The instructions, when individually or collectively executed by the at least one processor, may cause the communication device to determine, based on the message, a probability that an explicit congestion notification (ECN) field will be marked with a specified value indicating congestion. The instructions, when individually or collectively executed by the at least one processor, may cause the communication device to mark an ECN field of at least one packet among packets transmitted from the CU to the DU with the specified value, according to the probability.

[0184] In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the communication device to obtain information about a requested buffer size based on the message. The instructions, when individually or collectively executed by the at least one processor, may cause the communication device to determine, based on the information about the requested buffer size, a probability that the ECN field will be marked with the designated value indicating congestion.

[0185] In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the communication device to identify a ratio of the requested buffer size to a normal reference requested buffer size based on information about the requested buffer size for the DU. The instructions, when individually or collectively executed by the at least one processor, may cause the communication device to determine the probability based on the ratio.

[0186] In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the communication device to identify a number of packets stored in a buffer included in the memory. The instructions, when individually or collectively executed by the at least one processor, may cause the communication device to determine the probability based on a ratio of the number of packets stored in the buffer to a reference value.

[0187] In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the communication device to identify delay information regarding a buffer contained in the memory. The instructions, when individually or collectively executed by the at least one processor, may cause the communication device to determine the probability based on the delay information.

[0188] In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the communication device to identify a delay time according to the delay information. The delay time may be related to the length of a time interval between a first time at which a packet received from another device for a user plane function is stored in the buffer and a second time at which the packet is transmitted to the DU.

[0189] In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the communication device to determine the probability as '0' based on the delay time being within a first range. The instructions, when individually or collectively executed by the at least one processor, may cause the communication device to determine the probability as a probability corresponding to the delay time based on the delay time being within a second range. The instructions, when individually or collectively executed by the at least one processor, may cause the communication device to determine the probability as '1' based on the delay time being within a third range.

[0190] In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the communication device to obtain information about a requested buffer size based on the message. The instructions, when individually or collectively executed by the at least one processor, may cause the communication device to transmit information about the requested buffer size to another device for a user plane function. The probability that the ECN field will be marked with the specified value may be determined by the other device based on the information about the requested buffer size.

[0191] In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the communication device to transmit information about the probability that the ECN field will be marked with the specified value to another device for user plane functionality.

[0192] In one embodiment, the message may include information about another probability that the ECN field identified in the DU will be marked with the specified value indicating congestion.

[0193] According to one embodiment, the CU may be associated with a packet data convergence protocol (PDCP) layer. The DU may be associated with a radio link layer (RLC) layer and a medium access control (MAC) layer.

[0194] According to one embodiment, a method performed by a communication device configured to perform functions of a central unit (CU) may include receiving, through a transceiver, a message indicating a transmission status of downlink data from a distributed unit (DU) connected to the CU. The method may include determining, based on the message, a probability that an explicit congestion notification (ECN) field will be marked with a designated value indicating congestion. The method may include marking, based on the probability, an ECN field of at least one packet among packets transmitted from the CU to the DU with the designated value.

[0195] In one embodiment, the method may include an operation of obtaining information about a requested buffer size based on the message. The method may include an operation of determining, based on the information about the requested buffer size, a probability that the ECN field will be displayed with the specified value indicating congestion.

[0196] In one embodiment, the method may include an operation of identifying a ratio of the requested buffer size to a normal reference requested buffer size based on information about the requested buffer size for the DU. The method may include an operation of determining the probability based on the ratio.

[0197] According to one embodiment, the method may include an operation of identifying the number of packets stored in a buffer included in the memory. The method may include an operation of determining the probability based on a ratio of the number of packets stored in the buffer to a reference value.

[0198] In one embodiment, the method may include an operation of identifying delay information regarding a buffer included in the memory. The method may include an operation of determining the probability based on the delay information.

[0199] According to one embodiment, the method may include an operation of identifying a delay time according to the delay information. The delay time may be related to the length of a time interval between a first time point at which a packet received from another device for a user plane function is stored in the buffer and a second time point at which the packet is transmitted to the DU.

[0200] In one embodiment, the method may include an operation of determining the probability as '0' based on the delay time within a first range. The method may include an operation of determining the probability as a probability corresponding to the delay time based on the delay time within a second range. The method may include an operation of determining the probability as '1' based on the delay time within a third range.

[0201] In one embodiment, the method may include an operation of obtaining information about a requested buffer size based on the message. The method may include an operation of transmitting information about the requested buffer size to another device for a user plane function. The probability that the ECN field will be displayed with the specified value may be determined by the other device based on the information about the requested buffer size.

[0202] In one embodiment, the method may include transmitting information about the probability that the ECN field will be represented by the specified value to another device for user plane functionality.

[0203] According to one embodiment, the CU may be associated with a packet data convergence protocol (PDCP) layer. The DU may be associated with a radio link layer (RLC) layer and a medium access control (MAC) layer.

[0204] According to one embodiment, a non-transitory computer-readable storage medium may store one or more programs. The one or more programs may include instructions that, when executed by at least one processor of a communication device configured to perform functions of a central unit (CU), cause the communication device to receive, through a transceiver, a message indicating a forwarding status of downlink data from a distributed unit (DU) connected to the CU. The one or more programs may include instructions that, when executed by the at least one processor of the communication device, cause the communication device to determine, based on the message, a probability that an explicit congestion notification (ECN) field will be marked with a designated value indicating congestion. The one or more programs may include instructions that, when executed by the at least one processor of the communication device, cause the communication device to mark, with the designated value, an ECN field of at least one packet among packets transmitted from the CU to the DU, based on the probability.

[0205] According to the above-described embodiment, in the split base station structure, a lower base station (e.g., DU (320)) can transmit a DDDS frame to an upper base station (e.g., CU (310)). The lower base station can request the size of data that the lower base station can accept using the DBS included in the DDDS frame. The upper base station can identify whether congestion occurs at the lower base station. If congestion occurs at the lower base station, the size of the DBS can be reduced. If congestion occurs at the lower base station, the number of packets buffered at the upper base station can be increased. If congestion occurs at the lower base station, the buffering delay of the upper base station can be increased. Accordingly, the upper base station can determine the ECN marking probability based on at least one of the size of the DBS, the number of buffered packets, and / or the buffering delay. According to the above-described embodiment, low latency can be provided in E2E.

[0206] For one or more embodiments, at least one of the components described in one or more of the preceding drawings may be configured to perform one or more operations, techniques, processes, and / or methods as described herein. For example, a processor (e.g., a baseband processor) described herein with respect to one or more of the preceding drawings may be configured to operate according to one or more examples described herein. For another example, circuitry associated with a user equipment (UE), a base station, a network element, and the like, as described above with respect to one or more of the preceding drawings, may be configured to operate according to one or more examples described herein.

[0207] Any of the embodiments described above may be combined with any other embodiment (or combination of embodiments) unless explicitly stated otherwise. The foregoing description of one or more implementations provides examples and descriptions, but is not intended to be exhaustive or limit the scope of the embodiments to the precise forms disclosed. Modifications and variations are possible in light of the above teachings or may be learned from practicing various embodiments.

[0208] The various embodiments of this document and the terminology used therein are not intended to limit the technical features described in this document to specific embodiments, but should be understood to include various modifications, equivalents, or substitutes of the embodiments. In connection with the description of the drawings, similar reference numerals may be used for similar or related components. The singular form of a noun corresponding to an item may include one or more of the items, unless the context clearly indicates otherwise. In this document, each of the phrases "A or B", "at least one of A and B", "at least one of A or B", "A, B, or C", "at least one of A, B, and C", and "at least one of A, B, or C" can include any one of the items listed together in the corresponding phrase among those phrases, or all possible combinations thereof. Terms such as "first," "second," or "first" or "second" may be used merely to distinguish one component from another, and do not limit the components in any other respect (e.g., importance or order). When a component (e.g., a first component) is referred to as "coupled" or "connected" to another component (e.g., a second component), with or without the terms "functionally" or "communicatively," it means that the component can be connected to the other component directly (e.g., wired), wirelessly, or through a third component.

[0209] The term "module" used in various embodiments of this document may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit. A module may be an integral component, or a minimum unit or part of such a component that performs one or more functions. For example, according to one embodiment, a module may be implemented in the form of an application-specific integrated circuit (ASIC).

[0210] Various embodiments of the present document may be implemented as software including one or more instructions stored in a storage medium (e.g., memory (820)) readable by a machine (e.g., DU (320), an electronic device operating as DU (320)). For example, a processor of the machine (e.g., DU (320), an electronic device operating as DU (320)) may call at least one instruction among the one or more instructions stored from the storage medium and execute it. This enables the machine to operate to perform at least one function according to the at least one called instruction. The one or more instructions may include code generated by a compiler or code executable by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. Here, 'non-transitory' simply means that the storage medium is a tangible device and does not contain signals (e.g., electromagnetic waves), and the term does not distinguish between cases where data is stored semi-permanently or temporarily on the storage medium.

[0211] 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.

[0212] 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 to be executed by one or more processors in an electronic device. The one or more programs include instructions that cause the electronic device to execute methods according to embodiments described in the claims or specification of the present disclosure. The one or more programs may be provided as a computer program product. The computer program product may be traded between a seller and a buyer as a commodity. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., compact disc read only memory (CD-ROM)), or may be distributed online (e.g., downloaded or uploaded) via an application store (e.g., Play Store™) or directly between two user devices (e.g., smart phones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily created in a device-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.

[0213] 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 devices, compact disc-ROM (CD-ROM), digital versatile discs (DVDs) or other forms of optical storage devices, magnetic cassettes, or may be stored in memories formed by a combination of some or all of these. In addition, each configuration memory may include multiple copies.

[0214] 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 area network (WAN), a storage area network (SAN), or a combination thereof. Such a storage device may be connected to a device implementing 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 implementing an embodiment of the present disclosure.

[0215] In the specific embodiments of the present disclosure described above, components included in the disclosure 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. Components expressed in plural may be composed of singular elements, or components expressed in singular may be composed of plural elements.

[0216] According to embodiments, one or more of the components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (e.g., modules or programs) may be integrated into a single component. In such a case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by the corresponding component among the plurality of components prior to the integration. According to embodiments, the operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

[0217] Meanwhile, although the detailed description of the present disclosure has described specific embodiments, it is obvious that various modifications are possible within the scope of the present disclosure.

Claims

1. In a communication device configured to perform the functions of a CU (central unit), Transmitter and receiver; At least one processor comprising processing circuitry; and comprising one or more storage media, and including a memory storing instructions; The above instructions, when individually or collectively executed by the at least one processor, A message indicating the transmission status of downlink data is received from a DU (distributed unit) connected to the above CU through the transceiver, Based on the above message, determine the probability that the ECN (explicit congestion notification) field will be marked with a specified value indicating congestion, Causing the communication device to mark the ECN field of at least one packet among packets transmitted from the CU to the DU with the specified value, according to the above probability. Communication device.

2. In the first paragraph, when the instructions are individually or collectively executed by the at least one processor, Based on the above message, obtain information about the requested buffer size, further causing the communication device to determine the probability that the ECN field will be marked with the specified value indicating congestion based on the information about the requested buffer size; Communication device.

3. In the second paragraph, when the instructions are individually or collectively executed by the at least one processor, Based on the information about the requested buffer size for the above DU, identify the ratio of the requested buffer size to the reference requested buffer size in the normal state, Further causing the communication device to determine the probability based on the above ratio, Communication device.

4. In the first paragraph, when the instructions are individually or collectively executed by the at least one processor, Identify the number of packets stored in the buffer contained in the above memory, Further causing the communication device to determine the probability based on a ratio of the number of said packets stored in said buffer to a reference value. Communication device.

5. In the first paragraph, when the instructions are individually or collectively executed by the at least one processor, Identify delay information about the buffer contained in the above memory, Further causing the communication device to determine the probability based on the delay information; Communication device.

6. In the fifth paragraph, when the instructions are individually or collectively executed by the at least one processor, Further causing the communication device to identify the delay time according to the above delay information, The above delay time is, The length of the time interval between the first time point at which a packet received from another device for user plane function is stored in the buffer and the second time point at which the packet is transmitted to the DU, Communication device.

7. In the sixth paragraph, when the instructions are individually or collectively executed by the at least one processor, Based on the above delay time within the first range, the probability is determined as '0', Based on the delay time within the second range, the probability is determined as a probability corresponding to the delay time, Further causing the communication device to determine the probability as '1' based on the delay time within the third range. Communication device.

8. In the second paragraph, when the instructions are individually or collectively executed by the at least one processor, Based on the above message, obtain information about the requested buffer size, further causes information about the above requested buffer size to be transmitted to another device for user plane functions, The probability that the above ECN field will be displayed as the above specified value is Based on the information about the above requested buffer size, which is determined by the other device, Communication device.

9. In the first paragraph, when the instructions are individually or collectively executed by the at least one processor, further causing the ECN field to transmit information about the probability that said ECN field will be represented by said specified value to another device for user plane functionality; Communication device.

10. In paragraph 1, the message, Further including information about another probability that the ECN field identified in the above DU will be marked with the above specified value indicating congestion. Communication device.

11. In the first paragraph, the CU, Associated with the PDCP (packet data convergence protocol) layer, The above DU is, Associated with the RLC (radio link layer) layer and the MAC (medium access control) layer, Communication device.

12. A method performed by a communication device configured to perform the functions of a CU (central unit), An operation of receiving, through a transceiver, a message indicating a transmission status of downlink data from a DU (distributed unit) connected to the above CU; Based on the above message, an operation for determining a probability that the ECN (explicit congestion notification) field will be marked with a specified value indicating congestion; and An operation of marking an ECN field of at least one packet among packets transmitted from the CU to the DU with the specified value, according to the above probability. method.

13. In the 12th paragraph, the method, An operation for obtaining information about the requested buffer size based on the above message; and Further comprising an operation of determining, based on information about the requested buffer size, the probability that the ECN field will be marked with the designated value indicating congestion; method.

14. In the 13th paragraph, the method, An operation of identifying a ratio of the requested buffer size to a normal state reference requested buffer size based on information about the requested buffer size for the DU; and Further including an operation of determining the probability based on the above ratio, method.

15. In a non-transitory computer-readable storage medium storing one or more programs, the one or more programs, when executed by at least one processor of an electronic device configured to perform functions of a CU (central unit), Receive, through a transceiver, a message indicating the transmission status of downlink data from a DU (distributed unit) connected to the above CU, Based on the above message, determine the probability that the ECN (explicit congestion notification) field will be marked with a specified value indicating congestion, Including instructions causing the electronic device to perform marking of an ECN field of at least one packet among packets transmitted from the CU to the DU with the specified value, according to the probability. A non-transitory computer-readable storage medium.

Images