Network node and method for congestion indication of a data stream

Abstract

Embodiments herein relate to, for example, a method performed by network node (130) for handling packets of a data stream over a link, wherein the network node is configured to perform a congestion indication procedure. The network node (130) marks one or more packets of the data stream with a congestion experienced indication according to a marking function. The marking function omits a dependency between a bitrate of the data stream and a resulting queue delay at a steady state of the bitrate of the data stream.

Description

[0001] NETWORK NODE AND METHOD PERFORMED THEREIN

[0002] TECHNICAL FIELD

[0003] Embodiments herein relate to a network node, and a method performed therein for communication. Furthermore, a computer program and a computer readable storage medium are also provided herein. In particular, embodiments herein relate to congestion in a communication network.

[0004] BACKGROUND

[0005] In a typical communication network, user equipments (UE), also known as communication devices, wireless communication devices, mobile stations, stations (STA) and / or wireless devices, communicate via for example an access network (AN) such as a radio access network (RAN) with one or more core networks (CN). The RAN covers a geographical area which is divided into service areas or cell areas, with each service area or cell area being served by radio network node such as an access node e.g. a Wi-Fi access point or a radio base station (RBS), which in some networks may also be called, for example, a NodeB, a gNodeB, or an eNodeB. The service area or cell area is a geographical area where radio coverage is provided by the radio network node. The radio network node operates on radio frequencies to communicate over an air interface with the UEs within range of the radio network node. The radio network node communicates over a downlink (DL) to the UE and the UE communicates over an uplink (UL) to the radio network node.

[0006] A Universal Mobile Telecommunications System (UMTS) is a third generation telecommunications network, which evolved from the second generation (2G) Global System for Mobile Communications (GSM). The UMTS terrestrial radio access network (UTRAN) is essentially a RAN using wideband code division multiple access (WCDMA) and / or High-Speed Packet Access (HSPA) for communication with user equipment. In a forum known as the Third Generation Partnership Project (3GPP), telecommunications suppliers propose and agree upon standards for present and future generation networks and UTRAN specifically, and investigate enhanced data rate and radio capacity. In some RANs, e.g. as in UMTS, several radio network nodes may be connected, e.g., by landlines or microwave, to a controller node, such as a radio network controller (RNC) or a base station controller (BSC), which supervises and coordinates various activities of the plural radio network nodes connected thereto. The RNCs are typically connected to one or more core networks.

[0007] Specifications for the Evolved Packet System (EPS) have been completed within the 3GPP and this work continues in the coming 3GPP releases, such as 5G, for example New Radio (NR), and beyond networks. The EPS comprises the Evolved Universal Terrestrial Radio Access Network (E-UTRAN), also known as the Long-Term Evolution (LTE) radio access network, and the Evolved Packet Core (EPC), also known as System Architecture Evolution (SAE) core network. E-UTRAN / LTE is a 3GPP radio access technology wherein the radio network nodes are directly connected to the EPC core network. As such, the Radio Access Network (RAN) of an EPS has an architecture comprising radio network nodes connected directly to one or more core networks.

[0008] With the 5G technologies such as NR, focus is on a set of features such as the use of very many transmit- and receive-antenna elements that makes it possible to utilize beamforming, such as transmit-side and receive-side beamforming. Transmit-side beamforming means that the transmitter can amplify the transmitted signals in a selected direction or directions, while suppressing the transmitted signals in other directions. Similarly, on the receive-side, a receiver can amplify signals from a selected direction or directions.

[0009] Typical wireless networks of today, supporting 4G and earlier releases are mainly optimized for mobile broadband (MBB) and voice services. MBB traffic can be very throughput demanding but is in general not latency sensitive. For example, non-realtime streaming services handle long latency by using large buffers which efficiently hide the latency jitter through the network, still resulting in a good end user experience. In later releases of 4G, but especially in 5G, also other types of services have come in focus. Examples of these new services are ultra-reliable low latency communication (URLLC) services, typically targeting industrial applications, and gaming services. Within 3GPP standardization, features are developed to support these new URLLC services and use cases.

[0010] Tele-operated driving is one latency sensitive use case, but gaming is probably a more common application example, including multi-user gaming, augmented reality (AR), virtual reality (VR) as well as gaming with and without rendering. To satisfy the end user quality experience for these applications, the end-to-end (E2E) latency must be considered. That is, in addition to provide low latency through the RAN, latency through the CN and all the way to the application server (sender) and / or client (receiver) needs to be considered. With an edge cloud deployment of the application, the impact of latency from the CN and between the network and the application, can be reduced.

[0011] Another quality-of-service (QoS) aspect to consider for latency sensitive services is reliability, measured as the probability of delivering the traffic within a specified time duration, i.e., fulfilling the latency requirement. The reliability is tightly coupled with the latency requirements, since without a latency requirement, the traffic can always be delivered by using sufficiently many retransmissions. Reliability is thus a very important criteria when tuning networks for latency sensitive traffic.

[0012] Another parameter to be considered when certain QoS levels are to be ensured for a given service is the availability of resources. Ensuring that resources are available at the time when the service needs them ensures prompt data exchange and it reduces the number of failures for a given bearer communication process.

[0013] MBB traffic is handled on best-effort basis and strives to minimize the time to complete a data transfer e.g., a download of data file or a web page. Both use case examples can be categorized as discontinuous data transfers which benefit from a very high bitrate to limit the time to completion.

[0014] Another category is a continuous data transfer, such as audio or video streaming. These services are bitrate limited and require a stable bitrate at the receiver (client) side for a satisfactory user experience. Today, most of these types of applications or services can adapt their bitrate if the throughput over the transport medias changes. These changes are typically caused by variations in load or quality of the shared transport media, especially common when using wireless transport.

[0015] To cater for these bitrate variations, non-realtime (RT) streaming services often utilize large buffers and a feedback loop between a receiver and a sender which efficiently hides the latency jitter through the network, and still resulting in a good end user experience. In principle this implies that the continuous data transfer service is transformed into a discontinuous data transfer service, using intermittent transmissions of data bursts with very high, but varying, bitrate. Playback of buffered data with a stable bitrate at the receiver side enables a good end user experience. The principles for the buffered mode streaming are shown in Fig. 1 and Fig. 2. The lengths of the bursts in Fig. 1 differ to illustrate variations of the transmission media load / quality. Fig. 1 shows a principle for bursty transmissions used for non-RT streaming and Fig. 2 shows protocol principle for bursty transmissions. Thus, step 1 in Fig. 2 is performed in an application server and the application server transmits a data burst. The application client in step 2 sends feedback when buffer HL is reached. That is, the buffer level has reached HL , which initiates the feedback transmission indicating buffer queue above a set level. In step 3, the application server stops sending data transmissions. The application client then in step 4 sends feedback indicating that buffer has reached buffer level LoThr. That is, the buffer level has goes down to LoThr, which indicates that transmission may be initiated again. Thus, the thresholds referred to here is the buffer level on the receiver side for non- RealTime transmissions. The receiver typically stores 10thof seconds of data it its local buffers and only requests new data when these large buffers are getting low e.g. less than 10s. In real time transmission one cannot afford to have any receiver side buffer and it needs to be kept at a minimum. Also buffers in the network need to be kept at a minimal level.

[0016] Real time streaming services are of the continuous data transfer category with demands for a stable bitrate, but they must also consider the E2E latency. Thus, they cannot enjoy the benefits from the bursty transmissions with large buffers at the receiver side as for non-real time streaming services. Common application examples for this category are real time video conferencing, multi-user gaming, Augmented Reality (AR), or VR. To satisfy the end user quality experience for these applications, the E2E latency must be considered. Even though these applications are within the same category, the actual bitrate demand can differ between different applications.

[0017] In 4G and 5G mobile wireless networks, the scheduler in the eNB or gNB controls the allocation of shared radio resources used as a shared transport media to and / or from a UE in a cell. In general, there is little difference between different scheduling algorithms at low system load, i.e. , when only one or a few users have data waiting for transmission at each scheduling instant. However, at high load or at congestion, the choice of scheduling algorithm becomes important to be able to satisfy the QoS requirement for each data flow. Several different scheduling algorithms may be employed such as round robin, resource fair, proportional fair, delay based or maximum rate.

[0018] The QoS models defined in 4G and 5G networks categorize the data flows as either guaranteed bit rate (GBR) flows or as non-GBR flows. Each flow has a QoS profile including QoS parameters / characteristics which are used as input for the scheduler. MBB with its best-effort approach is mapped to a non-GBR flow, without any information about bitrate demands in the QoS parameters. However, the profile for the GBR flows includes a parameter for the minimum bitrate, see section 5.7.2.5 in System architecture for the 5G System, 3GPP TS 23.501 V17.10.0, and voice service is the most common example in this category. E2E congestion control allows for all involved nodes to signal congestion to the source. The signalling may be explicit or implicit by simply dropping packets which is detected by the source and then the source adapts its rate to the weakest link. Active Queue Management (AQM) is often used in combination with E2E rate adaptation to reduce latency jitter for long-lived transfers caused by bursty sources, see Rate adaptation, Congestion Control and Fairness: A Tutorial, JEAN-YVES LE BOLIDEC, Ecole Polytechnique Fed'erale de Lausanne (EPFL).

[0019] One example of E2E congestion control and AQM is L4S. Thus, one way to manage latency, specifically queue delays, in E2E data flows is to make use of L4S Low Latency, Low Loss, Scalable throughput (L4S), see “Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture”, RFC9330 https: / / datatracker.ietf.org / doc / rfc9330 / . Any node serving an L4S capable data flow may set the Explicit Congestion Notification (ECN) bits in the IP header for the flow if congestion is experienced. The receiving client collects the congestion statistics, such as ECN statistics, and transmits this back as feedback to the corresponding sending server. Based on the reported congestion information, the sending server application adapts its data rate to maintain low queue delays and short E2E latency. Thus, congestion indications are set in the forward direction, collected by the client (receiver) and sent in a feedback protocol to the server (sender).

[0020] Packets are marked “congested” already when queue delays are low which gives a prompt reaction to small signs of congestion, allowing the end hosts to implement scalable congestion control where the transmission rate (or congestion window) is changed proportional to a fraction of congestion-marked packets out of all packets. See also Fig. 3 and Fig. 4 illustrating the overall principle. Fig. 3 shows an L4S functionality overview and Fig. 4 shows a Congestion Experienced (CE) marking principle. In Fig. 3, step 1, the application server transmits data and indicates L4S capable flow in IP header. In step 2, if node delay increases an intermediate node may mark some IP packets as “congestion experienced”. The number of packets marked is proportional to the level of queue delay. In step 3, the application client collects congestion statistics and sends feedback to the application server. In step 4, the application server may adjust transmission rate or congestion window proportional to the fraction of congestion-marked packets. L4S thresholds are referring to the queue delay on an intermediate node and not the receiver side buffering.

[0021] L4S lets real-time critical data applications adapt their rate to the weakest link, providing minimal latency impact due to queue build up. The state-of-the-art L4S is typically triggered by thresholds in the transport node input queue and may be used to signal a congested situation. Given that most transport nodes have a fairly stable or slowly varying output rate it gives good results. For radio networks, the output rate variations over the wireless link may be more frequent than in traditional wired solutions which leads to sudden latency peaks even when L4S is used.

[0022] Regardless of which L4S approach, if it is based on real or virtual queue, CE markings and bitrate will reach steady state when two CE marked packets per Round Trip Time (RTT) is received by the receiver. Thus, data stream in steady state means that two CE marked packets per RTT is received by the receiver.

[0023] When a receiver receives less than two CE marked packets per RTT, the bitrate should increase and when it receives more than two CE marked packets bitrate should decrease. where a is the fraction of CE marked packets received per RTT and CWND is the congestion window, in packets, used on the sender side. If all packets are CE-marked then the CWND is reduced by 50%, plus one packet, and if two CE marked packets are received per RTT then the CWND is kept constant in steady state:

[0024] SUMMARY

[0025] As a part of developing embodiments herein one or more of the following problems were identified:

[0026] A network node implementing L4S is doing CE markings proportional to e.g., the measured queue delay. CE markings will start at a certain low threshold with a low percentage and continue to 100% CE at a high threshold. This will also result in that the steady state CE marking fraction p will be dependent on bitrate according to the CE marking function in Fig. 4. So, the lower the bitrate, the higher queue delay is required in order to achieve a CE marking fraction corresponding to two CE marked packets per RTT. The limit will be the rate of two packets per RTT which will mean 100% CE markings and thus the queue delay will be equal to the high threshold. The higher the bitrate will become the closer to the lower threshold the steady state queue delay will be. Regardless how the CE marking function is selected, as long as it is proportional to the queue delay then lower rates will get higher delays and longer RTT which is counterproductive. Fig. 5 shows how different rates will result in different queue delays in steady state. Here the lower CE marking threshold is selected to 4ms and the higher threshold is selected to 24ms. The bottleneck rate is changing from 2000 to 125 in steps, and it can clearly be seen that the lower the bitrate the higher the steady state queue delay will become.

[0027] An object herein is to handle congestion of a data stream in an efficient manner.

[0028] According to an aspect the object is achieved by providing a method performed by a network node for handling packets of a data stream over a link, wherein the network node is configured to perform a congestion indication procedure. The network node marks one or more packets of the data stream with a congestion experienced indication according to a marking function, wherein the marking function omits a dependency between a bitrate of the data stream and a resulting queue delay at a steady state of the bitrate of the data stream.

[0029] It is furthermore provided herein a computer program comprising instructions, which, when executed on at least one processor, cause the at least one processor to carry out any of the methods above, as performed by the network node. It is additionally provided herein a computer-readable storage medium, having stored thereon a computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any of the methods above, as performed by the network node.

[0030] According to another aspect a network node is herein provided to be configured to perform the methods herein. Thus, according to an aspect the object is achieved by providing a network node for handling packets of a data stream over a link, wherein the network node is configured to perform a congestion indication procedure. The network node is configured to mark one or more packets of the data stream with a congestion experienced indication according to a marking function, wherein the marking function omits a dependency between a bitrate of the data stream and a resulting queue delay at a steady state of the bitrate of the data stream.

[0031] Embodiments herein remove that the resulting queue delay is dependent on bitrate and that lower bitrate requires a higher queue delay in steady state when using a queue delay proportional CE marking policy, and , thus, embodiments herein handle congestion of a data stream in an efficient manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Embodiments will now be described in more detail in relation to the enclosed drawings, in which:

[0033] Fig. 1 is a schematic overview depicting graphs of prior art;

[0034] Fig. 2 is a schematic overview depicting a communication network according to prior art;

[0035] Fig. 3 is a schematic overview depicting a communication network according to prior art;

[0036] Fig. 4 is a schematic overview depicting graphs of prior art;

[0037] Fig. 5 is a schematic overview depicting graphs of prior art;

[0038] Fig. 6 is a schematic overview depicting a communication network according to embodiments herein;

[0039] Fig. 7 shows a combined flowchart and signalling scheme according to some embodiments herein;

[0040] Fig. 8 is a schematic flowchart depicting a method performed by a network node according to embodiments herein;

[0041] Fig. 9a is a schematic flowchart depicting a method performed by a network node according to some embodiments herein;

[0042] Fig. 9b is a schematic flowchart depicting a method performed by a network node according to some embodiments herein;

[0043] Fig. 9c is a schematic flowchart depicting a method performed by a network node according to some embodiments herein;

[0044] Fig. 9d is a schematic flowchart depicting a method performed by a network node according to some embodiments herein;

[0045] Fig. 9e is a schematic flowchart depicting a method performed by a network node according to some embodiments herein;

[0046] Fig. 10 is a schematic overview depicting a communication network according to embodiments herein;

[0047] Fig. 11 is a schematic overview depicting a graph of implementing some embodiments herein

[0048] Fig. 12 is a schematic overview depicting a graph of implementing some embodiments herein

[0049] Fig. 13 is a schematic overview depicting graphs of implementing some embodiments herein

[0050] Fig. 14 is a schematic overview depicting graphs of implementing some embodiments herein Fig. 15 is a schematic overview depicting graphs of implementing some embodiments herein

[0051] Fig. 16 is a schematic overview depicting graphs of implementing some embodiments herein

[0052] Fig. 17 is a schematic overview depicting graphs of implementing some embodiments herein; and

[0053] Fig. 18 is a block diagram depicting a network node according to embodiments herein;

[0054] DETAILED DESCRIPTION

[0055] Embodiments herein relate to communication networks in general. Fig. 6 is a schematic overview depicting a communication network 1. The communication network 1 comprises one or more ANs and one or more CNs. The communication network 1 may use a number of different technologies, such as wired or wireless technology, Wi-Fi, Long Term Evolution (LTE), LTE-Advanced, NR, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications / Enhanced Data rate for GSM Evolution (GSM / EDGE), Worldwide Interoperability for Microwave Access (WiMax), or Ultra Mobile Broadband (UMB), just to mention a few possible implementations.

[0056] In the communication network 1, wireless devices e.g. a user equipment (UE) 10 such as a mobile station, a non-access point (non-AP) STA, a STA, a wireless device and / or a wireless terminal, communicate via one or more AN, e.g. a RAN, to one or more CNs. It should be understood by those skilled in the art that “UE” is a non-limiting term which means any terminal, wireless communication terminal, internet of things (loT) capable device, Machine Type Communication (MTC) device, Device to Device (D2D) terminal, or node e.g. smart phone, laptop, mobile phone, sensor, relay, mobile tablets or even a base station communicating within a cell.

[0057] The communication network 1 comprises a radio network node 12 providing radio coverage over a geographical area 11 , e.g. a first service area or cell, of a first radio access technology (RAT), such as NR, LTE, UMTS, Wi-Fi or similar. The radio network node 12 may be a radio access network node such as radio network controller or an access point such as a wireless local area network (WLAN) access point or an Access Point Station (AP STA), an access controller, a base station, e.g. a radio base station such as a NodeB, an evolved Node B (eNB, eNodeB), a base transceiver station, Access Point Base Station, base station router, a transmission arrangement of a radio base station, a stand-alone access point or any other network unit capable of serving a UE within the service area served by the radio network node 12 depending e.g. on the first radio access technology and terminology used.

[0058] The communication network 1 may further comprise a number of network nodes providing network functions (NF) or actually instantiations of NFs also referred to as NF instances. The communication network 1 comprises a first network node 13, for example, a intermediate network node, and a second network node 14 such as server. More generically, there are endpoints such as a sender and a receiver and there are intermediate nodes, such as routers or e.g. gNBs. Any (or all) intermediate nodes may be L4S compliant and may implement embodiments herein.

[0059] The respective node may be a standalone server, a cloud-implemented server, a distributed server or processing resources in a server farm or same node. Embodiments herein may be implemented as physical bare metal, virtual or cloud native such as Kubernetes environment in, e.g., hyper-cloud networks.

[0060] According to embodiments herein a network node 130, such as an intermediate network node e.g., the first network node 13 or the radio network node 12, may mark packets using a marking function. The network node 130 handles packets of a data stream over a link of a path of the data stream. The network node 130 is configured to perform a congestion indication procedure, such as an early congestion indication procedure. Thus, the network node 130 may be an L4S compliant network node. The network node 130 marks one or more packets of the data stream with a congestion experienced indication according to a marking function, such as a CE marking function. The marking function omits a dependency between a bitrate of the data stream and a resulting queue delay at a steady state of the bitrate of the data stream. Thus, embodiments herein may separate the bitrate and the queue delay at the network node 130 to be unrelated for the marking function. Steady state is achieved when the rate of the data stream is stable and does not have any significant slope over time.

[0061] The network node 130 may: adapt a shape of the queue delay proportional marking function so that the same queue delay is achieved regardless of bitrate in steady state; set a steady state baseline marking fraction, such as a default marking fraction based on a base RTT and a lower threshold of number of marked packets, of the data stream and by this remove the dependency between the bitrate and resulting queue delay at steady state. Marking fraction herein meaning number of marked packets out of the received packets, and may also be referred to as marking level, marking rate, or rate of marking. By combining this with a queue delay proportional CE marking function, a rate independent queue delay may be achieved while keeping a responsiveness in the marking function due to link capacity changes and sudden queue delay peaks; and / or leverage on the properties of L4S to get a good measurement of the RTT of an L4S flow for intermediate nodes. If the sender is L4S compliant and is regulating its bitrate according to the principles herein, it is possible according to embodiments herein to accurately measure the RTT for an L4S flow.

[0062] It should be noted that a sending application such as the UE 10 or the second network node 14 may use direct calculation of a sender side CWND based on measured marking fraction denoted as alpha when a baseline CE marking fraction is used such as the steady state baseline CE marking fraction.

[0063] Fig. 7 is a combined flowchart and signalling scheme according to some alternative embodiments herein.

[0064] Action 701. The second network node 14, which may be an application server or similar, may transmit one or more packets of a data stream along a path to a receiver such as the UE 10. It should be noted that the sender may be the UE 10 and the receiver may be the second network node 14.

[0065] Action 702. The network node 130 marks one or more packets of the data stream with an early congestion indication. According to embodiments herein, the network node 130 marks one or more packets of the data stream with a congestion experienced indication according to a marking function, such as a CE marking function. The marking function omits a dependency between a bitrate of the data stream and a resulting queue delay at a steady state of the data stream.

[0066] Action 703. The network node 130 transmits the packets of the data stream towards a destination such as the UE 10.

[0067] Action 704. The destination such as a server or a UE may generate feedback based on the number of marked packets such as marking fraction of the data stream.

[0068] Action 705. The receiver sends the feedback to the sender such as the second network node 14.

[0069] Action 706. The sender such as the second network node 14 may modify or alter transmission rate or similar based on the feedback. Example embodiments of the method performed by the network node 130 for handling packets of the data stream over the link in the communication network 1 will now be described with reference to a flowchart depicted in Fig. 8. The actions do not have to be taken in the order stated below, but may be taken in any suitable order. Optional actions are marked with dashed boxes. The network node 130 is configured to perform a congestion indication procedure, such as L4S compliant network node.

[0070] Action 801. The network node 130 may determine RTT. The network node 130 may receive the RTT from another node or may determine the RTT of received packets.

[0071] Action 802. The network node 130 may obtain a link capacity (LC). The network node 130 may measure the link capacity and / or receive indication of the link capacity.

[0072] Action 803. The network node 130 may adjust a lower threshold, ThLow, of a queue delay for initiating the marking in a way so that the resulting queue delay is the same regardless of the targeted steady state bitrate also referred to as a targeted bitrate of the data stream at a steady state of the bitrate of the data stream.

[0073] RTT-rarget RTTgase q elayTarget

[0074] The marking function may define a marking fraction that is the same regardless of a link capacity and / or a target bitrate of the link carrying the one or more packets. The marking function may comprise a target RTT used for calculating a marking fraction when the bitrate of the data stream is in steady state and is expressed to be a baseline RTT plus a target queue delay, wherein the baseline RTT is the lowest possible RTT given no buffer build up along a path for the data stream. thl = qDelayTarget— thh p

[0075] RTT-arge— RTTBase+ qDelayTarget

[0076] Action 804. The network node 130 may receive one or more packets. Action 805. The network node 130 may determine a marking fraction. The network node 130 may determine the marking fraction based on the obtained link capacity or target rate and target RTT and / or the determined queue delay (f (qd)).

[0077] The marking function may use a baseline marking fraction per RTT of a path for the data stream.

[0078] The marking function may comprise aligning a target RTT for a baseline marking part to be a base RTT plus the lower threshold ThLow. A queue delay proportional part will have effect only when the target RTT is exceeded while keeping a constant steady state CE marking fraction which is independent of queue delay.

[0079] Action 806. The network node 130 may select the marking fraction. The network node 130 may select a suitable marking fraction, which is an example of a marking level, that should give a bitrate that is lower than the link capacity but still high enough to enable accurate measurement of the base RTT.

[0080] 2 P ~ RTTestLC k

[0081] Action 807. The network node 130 may detect the steady state of the data stream. Steady state is achieved when the rate of the flow is stable and does not have any significant slope over time. The measurement time to detect steady state is dependent on the jitter of the system and the system properties.

[0082] Action 808. The network node 130 may measure a rate of packets over a measurement time. The measurement time may be selected so it incorporates radio properties plus additional latency due to e.g., internet transport.

[0083] Action 809. The network node 130 may calculate a present RTT, in the steady state based on the measured rate and selected marking fraction. By marking with a stable known marking fraction the RTT can be calculated.

[0084] 2

[0085] 1X 2 1_ measured P rDt

[0086] Action 810. The network node 130 marks one or more packets of the data stream with a congestion experienced indication according to the marking function, such as a CE marking function. The marking function omits a dependency between a bitrate of the data stream and a resulting queue delay at a steady state of the data stream.

[0087] The marking function may comprise measuring number of incoming packets with markings and only add additional marking to one or more packets if an incoming marking fraction is lower than a calculated marking fraction.

[0088] The marking function may combine a baseline marking with a queue delay proportional marking term to keep responsiveness when the link capacity is changing resulting in one or more queue delay peaks.

[0089] Pmark ~ P ~ ^received

[0090] P CE~) = pmark+ f qd)

[0091] Example embodiments of the method performed by the network node 130 for handling packets of the data stream over the link in the communication network 1 will now be described with reference to a flowchart depicted in Fig. 9a. The actions do not have to be taken in the order stated below, but may be taken in any suitable order. Optional actions are marked with dashed boxes. The network node 130 is configured to perform a congestion indication procedure, such as being an L4S compliant network node.

[0092] Action 911. The network node 130 may determine RTT. The network node 130 may receive the RTT from another node or may determine the RTT based on received packets. Action 912. The network node 130 may obtain a link capacity. The network node 130 may measure the link capacity and / or receive indication of the link capacity.

[0093] Action 913. The network node 130 may adjust a lower threshold of a queue delay for initiating the marking in a way so that the resulting queue delay is the same for a targeted steady state marking fraction.

[0094] RTTTarget TSase ^ elay-Target

[0095] The marking function may comprise a target RTT used for calculating a marking fraction when the bitrate of the data stream is in steady state and is expressed to be a baseline RTT plus a target queue delay, wherein the baseline RTT is the lowest possible RTT given no buffer build up along a path for the data stream.

[0096] Action 914. The network node 130 marks one or more packets of the data stream with a congestion experienced indication according to a marking function, such as a CE marking function. The marking function omits a dependency between a bitrate of the data stream and a resulting queue delay at a steady state of the data stream. The marking function may define a marking fraction that gives a queue delay that is the same for the targeted steady state CE marking level p. The marking function may define a marking fraction that is the same regardless of a link capacity and / or a target bitrate of the link carrying the one or more packets.

[0097] P(CE) = / (qd)

[0098] Example embodiments of the method performed by the network node 130 for handling packets of the data stream over the link in the communication network 1 will now be described with reference to a flowchart depicted in Fig. 9b. The actions do not have to be taken in the order stated below, but may be taken in any suitable order. Optional actions are marked with dashed boxes. The network node 130 is configured to perform a congestion indication procedure, such as being an L4S compliant network node. Action 921. The network node 130 may determine RTT. The network node 130 may receive the RTT from another node or may determine the RTT based on received packets.

[0099] Action 922. The network node 130 may obtain a link capacity. The network node 130 may measure the link capacity, calculate the link capacity and / or receive indication of the link capacity.

[0100] Action 923. The network node 130 may determine marking fraction. The network node 130 may determine marking fraction based on the obtained link capacity, or target rate, and target RTT.

[0101] Action 924. The network node 130 marks one or more packets of the data stream with a congestion experienced indication according to the determined marking fraction. The marking function may comprise measuring number of incoming packets with markings and only add additional marking to one or more packets if an incoming marking fraction is lower than a calculated marking fraction.

[0102] Pmark=P ~ ^received

[0103] P(CE) = pmark where areceivedis the measured incoming marking fraction and pmarkis the additional applied marking fraction at the node.

[0104] Example embodiments of the method performed by the network node 130 for handling packets of the data stream over the link in the communication network 1 will now be described with reference to a flowchart depicted in Fig. 9c. The actions do not have to be taken in the order stated below, but may be taken in any suitable order. Optional actions are marked with dashed boxes. The network node 130 is configured to perform a congestion indication procedure, such as being an L4S compliant network node.

[0105] Action 931. The network node 130 may determine RTT. The network node 130 may receive the RTT from another node or may determine the RTT based on received packets.

[0106] Action 932. The network node 130 may obtain a link capacity. The network node 130 may measure the link capacity and / or receive indication of the link capacity. Action 933. The network node 130 may determine queue delay of one or more packets in the data stream.

[0107] Action 934. The network node 130 may determine marking fraction. The network node 130 may determine marking fraction based on the obtained link capacity, or target rate, and target RTT and the determined queue delay (f(qd)), being an extra term.

[0108] The marking function may combine a baseline marking with a queue delay proportional marking term to keep responsiveness when the link capacity is changing resulting in one or more queue delay peaks.

[0109] The marking function may comprise aligning a target RTT for a baseline marking part to be a base RTT plus ThLow. A queue delay proportional part will have effect only when the target RTT is exceeded while keeping a constant steady state CE marking fraction which is independent of queue delay.

[0110] Pmark ~ P ^received

[0111] P(CE) = Pmark + f(qd)

[0112] Action 935. The network node 130 marks one or more packets of the data stream with a congestion experienced indication according to a marking function, such as a CE marking function. The marking function omits a dependency between a bitrate of the data stream and a resulting queue delay at a steady state of the data stream. The marking function may comprise measuring number of incoming packets with markings and only add additional marking to one or more packets if an incoming marking fraction is lower than a calculated marking fraction.

[0113] Pmark ~ P ~ ^received

[0114] P(CE) — pmark

[0115] Where areceivedis the measured incoming marking fraction and pmarkis the additional applied marking fraction at the node. Example embodiments of the method performed by the network node 130 or another network node for handling packets of the data stream over the link in the communication network 1 will now be described with reference to a flowchart depicted in Fig. 9d. The actions do not have to be taken in the order stated below, but may be taken in any suitable order. Optional actions are marked with dashed boxes. The network node 130 is configured to perform a congestion indication procedure, such as being an L4S compliant network node.

[0116] Action 941. The network node 130 or another network node may select a marking fraction. The network node 130 or another network node may select a suitable CE marking fraction, which is an example of a marking fraction, that should give a bitrate that is lower than the link capacity but still high enough to enable accurate measurement of the base RTT.

[0117] 2

[0118] P~ RTTestLC k where p is the marking fraction, RTTest, is a rough estimate of the system RTT, LC is the link capacity and k is a constant between 0 and 1 which is the target link utilization.

[0119] Action 942. The network node 130 or another network node may detect a steady state of the data stream. Steady state is achieved when the rate of the flow is stable and does not have any significant slope over time. The measurement time to detect Steady State is dependent on the jitter of the system and the system properties.

[0120] Action 943. The network node 130 or another network node may measure a rate of packets over a measurement time (R). The measurement time may be selected so it incorporates this radio properties plus additional latency due to e.g., internet transport.

[0121] Action 944. The network node 130 or another network node may calculate a present RTT, in the steady state based on measured rate and selected marking fraction. By marking with a stable known CE marking fraction, the RTT can be calculated.

[0122] 2

[0123] 1X 2 1_ measured P rDt

[0124] Action 945. The network node 130 or another network node may provide the calculated RTT to another network node or to the network node 130 such as in actions 801 ,911 ,921, or 931. Example embodiments of the method performed by a sender node such as the second network node 14 for handling packets of the data stream over the link in the communication network 1 will now be described with reference to a flowchart depicted in Fig. 9e. The actions do not have to be taken in the order stated below, but may be taken in any suitable order. Optional actions are marked with dashed boxes. The sender node is configured to perform a congestion indication procedure, such as being anL4S compliant network node.

[0125] Action 951. The sender node may determine fraction of marking such as determine marking fraction or marking level of the data stream (a).

[0126] Action 952. The sender node may then determine CWND based on the determined fraction. The sender node may calculate the CWND based on the CE measured marking fraction (2 / alpha).

[0127] 2 CWND = - a

[0128] This may be enabled by the method in Figs. 9b and 9c.

[0129] Above in Fig. 3, the general principle for treatment of L4S capable data flows is shown, where congestion detection and marking are performed in the intermediate nodes. The corresponding system view including some embodiments herein also referred to as Enhanced CE marking approach for L4S, deployed in a 5G RAN and is illustrated in Fig. 10. The RAN has a radio interface (llu) towards the UE and connects to the 5G core network (5GC) over the NG interface.

[0130] The sender and the receiver can either be in the data network connected to the 5G network over the N6 interface or in the UE. The sender / receiver application on the UE side may be deployed in the UE itself or in any compute equipment using the UE for connectivity.

[0131] The 5G RAN may provide the congestion detection and marking using the embodiments herein for L4S. Based on reference signal measurements, the LC for each user is estimated. For downlink, the measured channel quality may be sent from the UE, e.g., using Channel State Information (CSI), while the LC for uplink may be measured in the RAN.

[0132] Embodiments herein may comprise a dynamic CE marking function. When using the CE marking function in Fig. 4 it is easily realized that the resulting queue delay will be different depending on the CE marking fraction at steady state. The CE marking fraction in steady state is dependent on the target RTT and the LC in the following way: where, RTTTarget, is the target Round Trip Time, LC is the Link Capacity, p is then calculated as the fraction of two CE marked packets over the target RTT and LC in packets per second.

[0133] Some embodiments herein may shape the CE marking function in Fig. 4 in an adapted way so that the steady state CE marking results in the same queue delayregardless of LC, and / or target rate. This may be achieved by, e.g., adjusting the lower threshold in a way so that the resulting queue delay is the same for the targeted steady state CE marking fraction p. The lower threshold, thl, may be calculated as: thl = qDelayTarget- thh p RTTTargeiRTTBase4- qDelayTargetwhere thl is the lower threshold, qDelayTarget, is the target queue delay, thh is the higher threshold and p is the CE marking fraction in steady state. Furthermore, the target RTT used for calculating the CE marking fraction when the bitrate of the data stream is in steady state can be expressed to be the baseline RTT plus the target queue delay, l.e. the baseline RTT is the lowest possible RTT given no buffer build up along the path. Note that this is an example how to adapt the shape of a CE marking function visualized in Fig. 4, and it will be different for different shapes of the CE marking function. Embodiments herein may be normalized around the steady state CE marking so that the Queue Delay remains the same regardless of the Link Capacity or target rate. The resulting CE marking function f(qd, LC) is visualized in Fig. 11 for different link capacities or target rates with a target Queue Delay of 10ms.

[0134] In Fig. 11 the graphs represent:

[0135] LC 16000 8000 4000 2000 1000 500 250 125

[0136] ThLow[s] 0.009917 0.009833 0.009667 0.009333 0.008667 0.007333 0.004667 -0.00067

[0137] LC is in packets per seconds and Thi_ow is in seconds.

[0138] Some embodiments herein may comprise a Baseline CE marking process. The baseline CE marking fraction, p, may be calculated as: where, RTTTarget, is the target Round Trip Time, LC, is the Link Capacity, p is then calculated as the fraction of two CE marked packets over the target RTT and the link capacity, LC, in packets per second. This baseline CE marking fraction is thus constant if the link capacity is constant. On the receiver side, the received CE marking fraction per RTT, a, will be higher the higher the RTT becomes. For example, if the real RTT becomes two times larger than the target RTT due to queue build up then a will still be constant and equal with the baseline CE marking fraction p and thus 4 packets per RTT is CE marked instead of 2 and the congestion control thus needs to lower the rate of packets to reduce the extra latency.

[0139] Example 1 Responsiveness to queue delay increase:

[0140] Example 1 shows a quite extreme scenario when the RTT is off by a factor of 2 while still having a quite modest response to the CE marking fraction.

[0141] This example also involves measuring of incoming CE markings. To enable that several nodes are implementing baseline CE marking according to the local bottleneck one may measure incoming CE markings and only add additional CE marking if the incoming CE marking is lower than the calculated p. So, if incoming CE markings exist, then additional marking should be made according to:

[0142] P ~ Plocal ~ ^received where piocaiis the calculated base CE marking for the local bottle neck and deceived is the measured incoming CE marking fraction. So, the total baseline CE marking solution that will allow multiple baseline CE marking nodes along a path will become:

[0143] The idea also involves combining this baseline CE marking with a queue delay proportional CE marking term to keep responsiveness when the link capacity is changing resulting in sudden queue delay peaks, f(.qd). The total CE marking probability then becomes:

[0144] P(CE) = p + f( d)

[0145] Or when incorporating the ideas from above: P(CE) = p + f qd,LC)

[0146] Where P(CE) is the CE marking probability, p is the steady state baseline CE marking over the target RTT and f(.qd) or f qd, LC), is the CE marking function of queue delay, qd, which is exemplified in Fig. 4. Also, by aligning the properties of f(qd) or f(qd, LC) with the target RTT, the queue delay proportional term can be selected to only have effect when the queue delay ends up above the target such as when transitions in link capacity occurs.

[0147] In the example below a linear f c / d) is used starting to CE mark at a Queue delay of ThLow By aligning the target RTT for the baseline CE marking part to be the base RTT plus the ThLow, the queue delay proportional part will have effect only when the target RTT is exceeded while keeping a constant steady state CE marking fraction which is independent of queue delay. The base RTT, RTTbase, is here the system RTT without any impact of extra queue delay, i.e. the shortest possible RTT for a given system.

[0148] Example 2. Aligned selection of CE marking thresholds and baseline CE marking fraction:

[0149] By following the principles in example 1 the system will always mark with the baseline CE marking fraction, p, but will also amplify the CE marking fraction with a queue delay proportional part when needed.

[0150] It should be noted that the RTT cannot be measured directly on an intermediate node using prior art. However, it may be estimated, just set or measured using the method outlined herein. The drawback of having an estimated RTT that is lower than the actual RTT will lead to lower link utilization. And if the estimated RTT is too high then additional queue delay will be seen. E.g. if the RTT is estimated to be half of the actual RTT, then one should expect around 50% link utilization. If it is estimated too high, then the queue delay proportional properties will take over.

[0151] According to some embodiments a measurement of RTT using L4S may be achieved, as shown in Fig. 9d. The embodiments involve the following steps:

[0152] 1. Marking fraction selection

[0153] 2. Steady state detection

[0154] 3. Rate measurement

[0155] 4. RTT calculation

[0156] Since 2 packets should be CE marked per RTT in steady state, a specific marking fraction directly corresponds to a specific packet rate given that the RTT is fixed: D — _ 2 p RTT where R is the resulting rate of packets and p is the fraction of CE marked packets and RTT is the Round-Trip-Time.

[0157] The above steps 1-4 may be taken at a beginning of a flow and / or at any time during a flow to calibrate the settings to match the environment and possibly changed conditions. For example, the RTT might need to be re-measured since the conditions have changed. The steps 1-4 above are described here in detail:

[0158] 1. Marking fraction Selection

[0159] The first step is to select a suitable CE marking fraction, that should give a bitrate that is lower than the link capacity but still high enough to enable accurate measurement of the base RTT. Base RTT is the lowest possible RTT for a flow without having impact from queue build up. E.g. In a 5G system it should be a flow that is close to fully ramped up and it should be free from e.g. scheduling requests in UL that would mean extra latency. Depending on system or node type it is possible to select a suitable marking fraction for RTT measurement with knowledge about the system properties. The marking fraction can be selected as:

[0160] 2

[0161] P~ RTTestLC k where p is the marking fraction, RTTest, is a rough estimate of the system RTT, LC is the link capacity and k is a constant between 0 and 1 which is the target link utilization. Example. Link Capacity is 2000 pkts / s and k is selected to 0.8 (80% link utilization) and RTTest, is chosen to 20ms, then the marking fraction p is:

[0162] 2 p = - = 0.0625

[0163] K0.02 * 2000 * 0.8

[0164] 2. Steady State Detection and 3. Rate measurement When a suitable CE marking fraction is selected, steady state may be detected. Steady state is achieved when the rate of the flow is stable and does not have any significant slope over time. The measurement time to detect Steady State is dependent on the jitter of the system and the system properties. E.g., for a 5G system this time should be longer than an RTT plus the jitter. For a 5G system it is not uncommon to see jitter in the order of 10ms and RTT numbers between 20-30ms due to the radio interface so in that case the measurement time should be selected so it incorporates this radio properties plus additional latency due to e.g., internet transport. This outlines the minimum time but in most cased it is more practical to choose a higher number. Continuing the Example from above, the input rate, R, was measured to 1500 packets / second after the input rate was kept stable for 500ms.

[0165] 4. Round Trip Time Calculation

[0166] Since the sender node is L4S compliant and the intermediate node is marking with a stable known CE marking fraction the RTT can be calculated as:

[0167] [RTT] _measured=2 / ( p R)

[0168] Continuing the example above, the RTT can be calculated as: [RTT] _measured=2 / ( 0,0625*1500)= 0.0213 i.e. the real RTT is 21.3ms and not the estimated 20.0ms.

[0169] Furthermore, as stated in Fig. 9e a sender node may perform a direct calculation of sender side CWND based on measured alpha.

[0170] Since the CE marking fraction is constant with the CE marking approach presented above in Figs. 9b-9c, a congestion control can directly calculate the CWND that fits the link capacity. Since marking is done based on two CE marked packets per RTT given the known link capacity on the intermediate node then it is possible to measure the CE marking fraction, a, and calculate the CWND directly on the sender side:

[0171] 2 CWND = - a

[0172] E.g. if the bottleneck is 1000 packets per second and target RTT is 24ms and regardless which rate the sender is sending the new CWND can be calculated given that there are enough packets per RTT to measure a correctly:

[0173] P

[0174] K= . — 77777 = 8.3% = a -> CWND =n= 24 pkts -> Rate = - 0.024 1000 0.083KRTTTarget

[0175] 24 = - = 1000 pkts / s

[0176] 0.024K' i.e. given that a can be measured exactly, then the exact CWND can also be calculated. All this can be done while keeping L4S compliancy.

[0177] When senders are doing direct calculation of CE marking, the CE marking function on the bottleneck node may also be capped upwards to make the effect of maximum CE marking the same relative to the link capacity LC (or target rate).

[0178] 2 Pmax ~ j~r

[0179] DTi Tl Target

[0180] P(CE) = MAX(f(qd,LC),pmax)

[0181] 100% CE marking then will mean a reduction of the target rate with a factor of 1 / n. In most cases LC is changing when CE marking peaks are observed, then the net result will be that max CE marking will mean a factor of 1 / n lower than the new link capacity. The resulting CE marking function f qd.LC), is visualized in Fig. 12 for different link capacities or target rates.

[0182] Prior art clearly shows how the resulting queue delay is dependent on bitrate and that lower bitrate requires a higher queue delay in steady state when using a queue delay proportional CE marking policy. When using the adaption of the shape of the queue delay proportional marking function so that the same queue delay is achieved regardless of bitrate in steady state; and set the steady state baseline marking fraction of the data stream and by this remove the dependency between the bitrate and resulting queue delay at steady state, in combination or standalone this dependency is completely removed.

[0183] Dynamic CE marking function advantages.

[0184] When introducing the dynamic CE marking function provided by this idea, the target queue delay can be kept regardless of the rate. The below steady state simulation is using the principles outlined in Example 2 with a base RTT and high threshold value for f(qd, LC) is set equally as in the simulation presented above, i.e.,

[0185] P(CE) = p + f(qd,LC)

[0186] RTTbase = 20

[0187] Queue DelayTarget= 4

[0188] T -High=20 RTTfargeiRTTbase "T Queue Delcty Tar get 24

[0189] Baseline CE marking advantages.

[0190] When introducing the fixed baseline CE marking provided by embodiments herein, the target queue delay can be kept regardless of the bitrate. The below steady state simulation is using the principles outlined in Example 2 with a base RTT and threshold values for f(.qd) is set equally as in the simulation presented above, i.e.

[0191] RTTbase = 20

[0192] ThLow= 4 High = 20

[0193] RTTrarget =RTTbase +ThLow = 24

[0194] LC = [ 2000, 1000, 500, 250, 125 ]

[0195] Fig. 14 shows steady state bitrate, queue delay and CE marking for the baseline CE marking combined with queue delay proportional CE marking, see Fig. 9c.

[0196] Comparing the simulation in Fig. 14 with the simulation without the idea in Fig. 5 there is a clear difference in queue delay. In the simulation of embodiments herein the queue delay stays flat at the target set by the lower threshold (=4ms) regardless of bitrate of the data stream in steady state while there is still responsiveness in the CE marking to allow for quick adaptation to the new link capacity when transitions happen.

[0197] Embodiments herein also significantly increase the regulation space by giving the sender the opportunity to accurately measure the CE marking fraction long before the data stream is fully ramped up. With existing queue-delay-based CE marking, it is only possible to judge the existence of a queue not how close to queue build up a flow of the data stream is.

[0198] Sensitivity to overestimated or underestimated Target RTT.

[0199] As mentioned above, the base RTT cannot be measured directly in intermediate nodes but may be estimated. Here in Fig. 15 is the example simulation in Fig. 14 but with 50% underestimated base RTT. So instead to 20ms base RTT, 10ms base RTT us used and the target RTT is set to the base RTT plus the lower threshold for the queue delay proportional part so the resulting Target RTT is set to 14ms instead of 24ms. All other parameters are identical to the simulation presented in Fig. 14. Since the target RTT is set to ~70 % of the base RTT, the resulting link utilization will be 70% and the resulting bitrate will become 1400 pkts / s instead of 2000 pkts / s, 750 pkts / s instead of 1000 pkts / s etc. Fig. 15 shows a simulation result with 50% underestimated base RTT

[0200] If the base RTT is instead overestimated with 50%, see Fig. 16, then the queue delay proportional properties takes over and the result will look more like what is presented in Fig. 5. Here in Fig. 16 is the example simulation in Fig. 14 but with 50% overestimated base RTT. So instead of 20ms base RTT, 30ms base RTT is used and the target RTT is set to the base RTT plus the lower threshold for the queue delay proportional part, so the resulting Target RTT is set to 34ms instead of 24ms. All other parameters are identical to the simulation presented in Fig. 14. But it should be noted that even with this large estimation error the results are significantly better than with only queue delay proportional marking. Fig. 16 shows a simulation result with 50% overestimated base RTT.

[0201] Advantages to measure RTT on intermediate nodes, see Fig. 9d.

[0202] Usually, a RTT is unknown on intermediate nodes and thus measures, actions or algorithms depending on the RTT cannot be used without doing more or less rough estimations or specific features on higher layer transport protocols. Embodiments herein allow for new methods and algorithms to be implemented on intermediate nodes running L4S since the RTT may be determined more accurately.

[0203] Advantages of direct calculation of CWND on L4S sender side, see Fig. 9e.

[0204] Given that the intermediate nodes start to CE mark with a baseline CE marking fraction as outlined above in Figs. 9b-9c, the applications may calculate the CWND directly and by that completely avoid the problems outlined in the summary. In Fig. 17 the simulation result is the same as in Fig. 14 but with direct calculation of CWND based on measured a. It can be seen that the resulting queue delay is completely flat except for in transitions between different rates. As discussed in Fig. 9c a queue delay dependent component may be added to further improve performance in transitions between different link capacities. Fig. 17 shows using a direct calculation of CWND on sender side based on measured marking fraction alpha. Fig. 18 shows a block diagram depicting the network node 130 for handling packets of the data stream over the link. The network node is configured to perform the congestion indication procedure such as an L4S procedure.

[0205] The network node 130 comprises a processing circuitry 1801 comprising one or more processors.

[0206] The network node 130 and / or the processing circuitry 1801 is configured to mark the one or more packets of the data stream with the congestion experienced indication according to the marking function. The marking function omits the dependency between the bitrate of the data stream and the resulting queue delay at the steady state of the bitrate of the data stream.

[0207] The network node 130 and / or the processing circuitry 1801 may be configured to adjust the lower threshold of the queue delay for initiating the marking in the way so that the resulting queue delay is the same regardless of the targeted steady state bitrate.

[0208] The marking function may comprise the target RTT used for calculating a marking fraction when the bitrate of the data stream is in steady state and is expressed to be a baseline RTT plus a target queue delay, wherein the baseline RTT is the lowest possible RTT given no buffer build up along a path for the data stream. The marking function may use the baseline marking fraction per RTT of the path for the data stream.

[0209] The marking function may comprise measuring the number of incoming packets with markings and only add additional marking to one or more packets if the incoming marking fraction is lower than the calculated marking fraction.

[0210] The marking function may combine the baseline marking with the queue delay proportional marking term to keep the responsiveness when the link capacity is changing resulting in the one or more queue delay peaks.

[0211] The marking function may comprise aligning the target RTT for the baseline marking part to be the base RTT plus the lower threshold ThLow.

[0212] The network node 130 and / or the processing circuitry 1801 may be configured to select the marking fraction; detect the steady state of the data stream; measure the rate of packets over the measurement time; and to calculate the present RTT in the steady state based on the measured rate and selected marking fraction.

[0213] The network node 130 further comprises a memory 1805. The memory 1805 comprises one or more units to be used to store data on, such as indications, RTT, marking fraction, lower threshold, queue delay, indications, reconfiguration, applications to perform the methods disclosed herein when being executed, and similar. The network node 130 comprises a communication interface 1806 comprising transmitter, receiver, transceiver and / or one or more antennas. Thus, it is herein provided the network node for handling packets of the data stream over the link in the communications network, wherein the network node comprises processing circuitry and a memory, said memory comprising instructions executable by said processing circuitry whereby said network node is operative to perform any of the methods herein.

[0214] The methods according to the embodiments described herein for the network node 130 are respectively implemented by means of e.g. a computer program product 1807 or a computer program product, comprising instructions, i.e. , software code portions, which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the network node 130. The computer program product 1807 may be stored on a computer-readable storage medium 1808, e.g. a universal serial bus (USB) stick, a disc or similar. The computer- readable storage medium 1808, having stored thereon the computer program product, may comprise the instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the network node 130. In some embodiments, the computer-readable storage medium may be a non-transitory or transitory computer-readable storage medium.

[0215] As will be readily understood by those familiar with communications design, that functions means or modules may be implemented using digital logic and / or one or more microcontrollers, microprocessors, or other digital hardware. In some embodiments, several or all of the various functions may be implemented together, such as in a single application-specific integrated circuit (ASIC), or in two or more separate devices with appropriate hardware and / or software interfaces between them. Several of the functions may be implemented on a processor shared with other functional components of a radio network node, for example.

[0216] Alternatively, several of the functional elements of the processing means discussed may be provided through the use of dedicated hardware, while others are provided with hardware for executing software, in association with the appropriate software or firmware. Thus, the term “processor” or “controller” as used herein does not exclusively refer to hardware capable of executing software and may implicitly include, without limitation, digital signal processor (DSP) hardware, read-only memory (ROM) for storing software, random-access memory for storing software and / or program or application data, and non-volatile memory. Other hardware, conventional and / or custom, may also be included. Designers of communications receivers will appreciate the cost, performance, and maintenance trade-offs inherent in these design choices.

[0217] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non- transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0218] It will be appreciated that the foregoing description and the accompanying drawings represent non-limiting examples of the methods and apparatus taught herein. As such, the apparatus and techniques taught herein are not limited by the foregoing description and accompanying drawings. Instead, the embodiments herein are limited only by the following claims and their legal equivalents.

[0219] References

[0220] 1. Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture, RFC9330 https: / / datatracker.ietf.org / doc / rfc9330 /

[0221] 2. Rate adaptation, Congestion Control and Fairness: A Tutorial, JEAN- YVES LE BOUDEC, Ecole Polytechnique Fed'erale de Lausanne (EPFL)

[0222] 3. System architecture for the 5G System, 3GPP TS 23.501 V17.10.0

[0223] 4. NR and NG-RAN Overall Description, 3GPP TS 38.300 V17.6.0

Claims

1. CLAIMS1 . A method performed by a network node (130) for handling packets of a data stream over a link, wherein the network node (130) is configured to perform a congestion indication procedure, and wherein the method comprises: marking (810) one or more packets of the data stream with a congestion experienced indication according to a marking function, wherein the marking function omits a dependency between a bitrate of the data stream and a resulting queue delay at a steady state of the bitrate of the data stream.

2. The method according to claim 1 , further comprising adjusting (803) a lower threshold of a queue delay for initiating the marking in a way so that the resulting queue delay is the same regardless of targeted steady state bitrate.

3. The method according to claim 2, wherein the marking function comprises a target round trip time, RTT, used for calculating a marking fraction when the bitrate of the data stream is in steady state and is expressed to be a baseline RTT plus a target queue delay, wherein the baseline RTT is the lowest possible RTT given no buffer build up along a path for the data stream.

4. The method according to any of the claims 1-3, wherein the marking function uses a baseline marking fraction per round trip time, RTT, of a path for the data stream.

5. The method according to any of the claims 1-4, wherein the marking function comprises measuring number of incoming packets with markings and only add additional marking to one or more packets if an incoming marking fraction is lower than a calculated marking fraction.

6. The method according to any of the claims 1-5, wherein the marking function combines a baseline marking with a queue delay proportional marking term to keep responsiveness when the link capacity is changing resulting in one or more queue delay peaks.

7. The method according to any of the claims 1-6, wherein the marking function comprises aligning a target round trip time, RTT, for a baseline marking part to be a base RTT plus a lower threshold, Th.Low.

8. The method according to any of the claims 1-7, further comprising: selecting (806) a marking fraction; detecting (807) the steady state of the data stream; measuring (808) a rate of packets over a measurement time; and calculating (809) a present round trip time, RTT, in the steady state based on the measured rate and selected marking fraction.

9. A computer program comprising instructions, which, when executed on at least one processor, cause the at least one processor to carry out the method according to any of the claims 1-8, as performed by the network node (130).

10. A computer-readable storage medium, having stored thereon a computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any of the claims 1-8, as performed by the network node (130).

11. A network node (130) for handling packets of a data stream over a link, wherein the network node (130) is configured to perform a congestion indication procedure, and wherein the network node is further configured to: mark one or more packets of the data stream with a congestion experienced indication according to a marking function, wherein the marking function omits a dependency between a bitrate of the data stream and a resulting queue delay at a steady state of the bitrate of the data stream.

12. The network node (130) according to claim 11 , wherein the network node (130) is configured to adjust a lower threshold of a queue delay for initiating the marking in a way so that the resulting queue delay is the same regardless of targeted steady state bitrate.

13. The network node (130) according to claim 12, wherein the marking function comprises a target round trip time, RTT, used for calculating a marking fraction when the bitrate of the data stream is in steady state and is expressed to be a baseline RTT plus a target queue delay, wherein the baseline RTT is the lowest possible RTT given no buffer build up along a path for the data stream.

14. The network node (130) according to any of the claims 11-13, wherein the marking function uses a baseline marking fraction per round trip time, RTT, of a path for the data stream.

15. The network node (130) according to any of the claims 11-14, wherein the marking function comprises measuring number of incoming packets with markings and only add additional marking to one or more packets if an incoming marking fraction is lower than a calculated marking fraction.

16. The network node (130) according to any of the claims 11-15, wherein the marking function combines a baseline marking with a queue delay proportional marking term to keep responsiveness when the link capacity is changing resulting in one or more queue delay peaks.

17. The network node (130) according to any of the claims 11-16, wherein the marking function comprises aligning a target round trip time, RTT, for a baseline marking part to be a base RTT plus a lower threshold ThLow.

18. The network node (130) according to any of the claims 11-17, wherein the network node is configured to: select a marking fraction; detect the steady state of the data stream; measure a rate of packets over a measurement time; and calculate a present round trip time, RTT, in the steady state based on the measured rate and selected marking fraction.

Images