WO2017059932A1 - Commande de flux descendant de paquets de données vers un ou plusieurs clients - Google Patents

Commande de flux descendant de paquets de données vers un ou plusieurs clients Download PDF

Info

Publication number
WO2017059932A1
WO2017059932A1 PCT/EP2015/079128 EP2015079128W WO2017059932A1 WO 2017059932 A1 WO2017059932 A1 WO 2017059932A1 EP 2015079128 W EP2015079128 W EP 2015079128W WO 2017059932 A1 WO2017059932 A1 WO 2017059932A1
Authority
WO
WIPO (PCT)
Prior art keywords
data packets
client
network
network node
bitrate
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2015/079128
Other languages
English (en)
Inventor
Thomas EDWALL
Robert Skog
Marcus IHLAR
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of WO2017059932A1 publication Critical patent/WO2017059932A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/621—Individual queue per connection or flow, e.g. per VC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/60—Queue scheduling implementing hierarchical scheduling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/765—Media network packet handling intermediate

Definitions

  • the invention relates to a network node for controlling a downstream flow of data packets to one or more clients, a method of controlling a downstream flow of data packets to one or more clients, a corresponding computer program, and a corresponding computer program product.
  • Network operators have a need of protecting their networks from congestion, as well as ensuring that the performance of the network is as good as possible.
  • AQM Active Queue Management
  • RED Random Early Detection
  • AQM has been an active area of research for decades, and IETF RFC 7567 recommends AQM as a best practice. Deployment of AQM has been hampered by the need of specific and complex tuning for different types of networks.
  • Flow-Queue CoDel is a state-of-the-art AQM scheme that combines a "zero-tuning AQM" with flow-based scheduling. It is currently being standardized by the IETF [IETF Internet-Draft draft-ietf-aqm-fq-codel-01 ].
  • AQM is typically deployed at potential bottlenecks in the network. These bottlenecks include host operating systems, internet routers, Radio Access Network (RAN) nodes, and other types of network equipment. If AQM functionality is deployed at multiple locations in the network, i.e., a distributed deployment, any update of AQM functionality throughout a network is costly and complex.
  • RAN Radio Access Network
  • TCP proxy Transport Control Protocol
  • CCAs Congestion Control Algorithms
  • Fairness between different flows is achieved by utilizing the same type of congestion control for all flows.
  • TCP proxies also have the possibility to accelerate flows by splitting the connection in two connections, a first leg between the upstream end-point of the TCP connection (the TCP server) and the proxy, and a second leg between the proxy and the downstream end-point of the TCP connection (the TCP client). This leads to tighter feedback loops by making TCP ramp up its sending speed faster.
  • TCP proxies A problem with TCP proxies is that the enhanced congestion control only is beneficial for flows with a lifetime which is sufficiently long to leave TCP's slow-start phase. Another problem is that transport flows other than TCP, such as Quick User Datagram Protocol (UDP) Internet Connections (QUIC), are not handled by the TCP proxy. Adding support for new protocols is complicated by end-to- end encryption of communication sessions which is commonly used between server and client via the proxy.
  • UDP Quick User Datagram Protocol
  • QUIC Quick User Datagram Protocol
  • GSM Global System for Mobile Communications
  • UMTS Universal Mobile Telecommunications System
  • LTE Long Term Evolution
  • 5G next- generation radio access technologies
  • a web server located on the Internet serving mobile users located in different parts of the RAN and accessing the operator network through different radio-access technologies, will have to cater for these differences in order to support as good Quality of Experience (QoE) as possible.
  • QoE Quality of Experience
  • a network node for controlling a downstream flow of data packets to one or more clients.
  • the one or more clients may, e.g., be mobile terminals or User Equipments (UEs) receiving the data packets over a RAN.
  • the network node comprises at least one network interface and processing means.
  • the at least one network interface is arranged for receiving the data packets from a packet-switched network, such as the Internet.
  • the processing means is operative to separate the received data packets into different session buffers, one for each client.
  • the received data packets are separated based on a respective destination Internet Protocol (IP) address of each data packet.
  • IP Internet Protocol
  • the processing means is further operative, for each client, i.e., for each session buffer, to separate the data packets into different queues, one for each flow, de-queue the data packets, and forward the de-queued data packets to the client.
  • Each flow may be defined by a 5-tuple comprising source IP address, destination IP address, source port number, destination port number, and protocol number.
  • the data packets are de-queued in accordance with an estimated bitrate of a data connection between the network node and the client.
  • the de-queued data packets are forwarded by means of the at least one network interface.
  • a method of controlling a downstream flow of data packets to one or more clients is provided.
  • the method is performed by a network node and comprises receiving the data packets from a packet-switched network, such as the Internet, and
  • the method further comprises, for each client, i.e., for each session buffer, separating the data packets into different queues, one for each flow, de-queueing the data packets, and forwarding the de-queued data packets to the client.
  • Each flow may be defined by a 5-tuple comprising source IP address, destination IP address, source port number, destination port number, and protocol number.
  • the data packets are de-queued in accordance with an estimated bitrate of a data connection between the network node and the client.
  • a computer program comprises computer-executable instructions
  • a computer program product comprises a computer- readable storage medium which has the computer program according to the third aspect of the invention embodied therein.
  • the invention makes use of an understanding that an improved flow- control of downstream data packets which are transmitted to one or more clients can be achieved by means of a network node operating as Automatic Rate Flow Manager (ARFM), which is described herein.
  • ARFM Automatic Rate Flow Manager
  • the ARFM is a single ingress (entry) and egress (exit) point for a certain client and may, e.g., be deployed between an external packet-switched network, such as the Internet, and an entry point of an operator network or a RAN.
  • the ARFM attempts to reflect an available path capacity in the network to ensure that queue-buildup is preferably limited to the point in the network where the ARFM is deployed, rather than further down the path, i.e., downstream from the ARFM.
  • bottlenecks may, e.g., build up in radio access nodes of the RAN due to limitations in air-interface capacity. As a consequence of creating an artificial bottleneck for each client at an upstream location, the build-up of queues at potential bottlenecks
  • the ARFM simplifies deployment of AQM in an operator network since a single node is sufficient to manage the entire network downstream from the point of deployment.
  • the ARFM may advantageously be deployed in networks where path characteristics may differ considerably between connections to different clients, such as mobile terminals or UEs receiving data over a RAN, or different RANs having different radio characteristics and/or radio access technologies.
  • a typical example of such a network is 3GPP-type of network in which different clients have separate scheduling queues.
  • the data packets are de- queued at a bitrate which is substantially equal to the estimated bitrate for each client.
  • the bitrate of the data connection between the network node and the client may be estimated, for each client, by the network node.
  • the bitrate may be estimated by measuring the rate of acknowledgements pertaining to a transport protocol used by the client, correlated with the amount of data packets sent to the client.
  • the bitrate may be estimated based on feedback information received from a downstream network node, e.g., a Radio Resource Management (RRM) node of a RAN, such as a Base Station Controller (BSC) in a GSM network, a Radio Network Controller (RNC) in a UMTS network, an eNodeB in an LTE network, or a corresponding RRM node in a 5G network.
  • a Radio Resource Management (RRM) node of a RAN such as a Base Station Controller (BSC) in a GSM network, a Radio Network Controller (RNC) in a UMTS network, an eNodeB in an LTE network, or a corresponding RRM node in a 5G network.
  • RRM Radio Resource Management
  • BSC Base Station Controller
  • RNC Radio Network Controller
  • the data packets may be de-queued using a fair scheduler or a weighted scheduler, in accordance with a policy decided by an operator of the network node.
  • the data packets are de- queued in accordance with a maximum queueing delay.
  • the maximum queueing delay may be configured by an operator of the network node.
  • Fig. 1 shows possible deployment points for the network node for controlling a downstream flow of data packets to one or more clients, in accordance with embodiments of the invention.
  • Fig. 2 illustrates flow-control of downstream data packets, in accordance with embodiments of the invention.
  • Fig. 3 shows a flow chart illustrating a method of controlling a downstream flow of data packets to one or more clients, in accordance with embodiments of the invention.
  • Fig. 4 shows a network node for controlling a downstream flow of data packets to one or more clients, in accordance with an embodiment of the invention.
  • Fig. 5 shows a network node for controlling a downstream flow of data packets to one or more clients, in accordance with another embodiment of the invention.
  • the solutions disclosed herein utilize a network node 100, herein referred to as Automatic Rate Flow Manager (ARFM), as a single ingress (entry) and egress (exit) point for a certain client 104, such as a mobile terminal or a UE.
  • the ingress/egress point may, e.g., be the default routing between a packet router of the RAN 103 or an operator network 102, such as the Gateway General Packet Radio Service (GPRS) Support Node (GGSN) or the Packet Data Network Gateway (PGW or PDN-GW), and an external packet-switched network 101 , such as the Internet.
  • GPRS Gateway General Packet Radio Service
  • GGSN Gateway General Packet Radio Service
  • PGW Packet Data Network Gateway
  • An example deployment of the ARFM is illustrated in Fig. 1 , in which the ARFM 100 is located between an external packet-switched network 101 and an entry point of an operator network 102 (illustrated in diagram 1 10).
  • ARFM 100 may be located at an entry point of a RAN 103 (illustrated in diagram 120). As a further alternative, ARFM 100 may be deployed at the Gi interface of a 3GPP network.
  • ARFM 100 attempts to reflect an available path capacity in the downstream network to ensure that queue buildup is mainly limited to the point in the network where ARFM 100 is deployed, rather than further down the path, i.e., downstream from ARFM 100.
  • bottlenecks may, e.g., build up in radio access nodes of the RAN 103 due to limitations in air- interface capacity.
  • operation of ARFM 100 is described in more detail with reference to Fig. 2, which illustrates the flow of downstream data packets 201 from left to right.
  • an upstream source such as the Internet or any other external packet-switched network 101
  • Fig. 2 two clients 104, "client A” and “client B” are illustrated, but embodiments of the invention controlling the flow of downstream data packets 201 to any number of clients 104 maybe
  • Data packets 201 received from the upstream network are addressed to either client A 104 (downward and upward diagonal pattern in Fig. 2) or client B 104 (horizontal and vertical pattern in Fig. 2).
  • Each client 104 may, e.g., be a mobile terminal or a UE.
  • the respective path capacity (herein also referred to as bandwidth), more specifically the bitrate, from ARFM 100 to each of the clients 104 is estimated, preferably regularly or continuously. This may, e.g., be achieved by correlating the amount of sent data segments with corresponding acknowledgements received from clients 104. If TCP is used as a transport protocol, the acknowledgement received from clients 104 are signaled by means of the ACK flag .
  • the flow of data packets 201 within ARFM 100 is regulated on a per- client basis so as to match the path capacity estimated for each client 104. This is achieved by creating artificial bottlenecks, one for each client 104. As a consequence, a queue will build up at an artificial bottleneck if the downstream path between ARFM 100 and client 104 has a lower capacity than the upstream path, between ARFM 100 and the source of the data packets, i.e., the external packet-switched network 101 .
  • each client 104 For each client 104, the data packets are separated into different queues 212 based on which flow they belong to. Each flow is defined by its 5-tuple, i.e., source IP address and port number, destination IP address and port number, and the protocol used for the flow.
  • each client 104 is illustrated as receiving two flows (client A: downward diagonal pattern and upward diagonal pattern, respectively; client B: horizontal pattern and vertical pattern, respectively).
  • Data packets are de-queued 213, using either a fair or weighted scheduler, and forwarded downstream to the clients 104, with a bitrate which is substantially equal to the estimated bitrate for each
  • Embodiments of the invention simplify deployment of AQM in an operator network since a single node, ARFM 100, is sufficient to manage the entire network downstream from the point of deployment.
  • ARFM 100 can ensure flow-fairness and flow-isolation for all types of traffic entering the network, in particular both TCP- and UDP-based traffic.
  • short-lived flows may experience an increased responsiveness due to the scheduling on flow level. For example, a Domain Name System (DNS) response does not have to share a queue with a TCP download of bulk data.
  • DNS Domain Name System
  • ARFM 100 The purpose of ARFM 100 is to reduce buffering of data packets 201 in nodes without AQM or with sub-optimal AQM. This is achieved by creating an artificial bottleneck at a desired location in the network in a controlled manner, thereby preventing bottlenecks from arising at locations downstream from the ARFM, such as in RAN 103, or shifting existing bottlenecks from a downstream location in the network to ARFM 100.
  • ARFM 100 may be deployed in networks where path characteristics may differ considerably between connections to different clients 104, such as mobile terminals or UEs receiving data over a RAN 103 or different RANs having different radio characteristics and/or radio access technologies.
  • clients 104 such as mobile terminals or UEs receiving data over a RAN 103 or different RANs having different radio characteristics and/or radio access technologies.
  • a typical example of such a network is 3GPP-type of network in which different clients have separate scheduling queues.
  • Method 300 is performed by a network node, such as ARFM 100, and comprises receiving 301 data packets 201 from a packet-switched
  • Method 300 further comprises, for each client 104, separating 305-307 data packets 201 into different queues 212, one for each flow, de-queueing 308-309 data packets 201 in accordance with an estimated bitrate of a data connection between ARFM 100 and client 104, and forwarding 310 de-queued data packets 201 to client 104.
  • ARFM 100 is deployed as an ingress node at an entry point to a network, e.g., an entry point of a RAN 103 or a network 102 of an operator, as is illustrated in Fig. 1 .
  • Downstream data packets 201 received from an external packet- switched network 101 are routed via ARFM 100 where they are
  • a corresponding session buffer does not yet exists, e.g., because a new client 104 has accessed RAN 103, a new buffer 21 1 is created 303 for the session of the new client.
  • data packets 201 are separated 305-307 into different queues 212 based on the packets' 201 5- tuple (source IP address, destination IP address, source port number, destination port number, protocol number). Data packets 201 with the same 5-tuple are referred to as a flow. If 305 a corresponding flow queue does not yet exists, e.g., because a client 104 has started using a new protocol, a new queue 212 is created 306.
  • an artificial bottleneck 213 is created by de-queueing 308-309 data packets 201 in accordance with an estimated capacity of the data connection between ARFM 100 and the respective client 104.
  • the bandwidth of each artificial bottleneck 213, i.e., its bitrate, is adjusted so as to create a bottleneck of substantially the same capacity/bandwidth as that of the connection between ARFM 100 and the respective client 104.
  • the capacity or bandwidth i.e., the available bitrate between
  • ARFM 100 and a client 104 may be estimated based on measurements of the capacity of the downstream path towards the respective client 104.
  • the path capacity may be estimated by measuring the rate of TCP (or other transport protocol) acknowledgements correlated to the amount of sent downstream data packets 201 .
  • explicit feedback information from a bottleneck in the network may also serve as input for path capacity estimation.
  • Such information may, e.g., be received from a BSC, an RNC, an eNodeB, a corresponding RRM node of a 5G network, or any other network node handling RRM tasks.
  • the estimates serve as input to a Proportional-lntegral-Derivative (PID) controller (or similar) which generates the artificial bottleneck capacity by adjusting parameters of the queue scheduler accordingly. More specifically, the artificial bottleneck 213 is realized by regulating the de-queuing rate of the individual flows 212.
  • PID Proportional-lntegral-Derivative
  • queues will build up in ARFM 100 if the path between an upstream source 101 and ARFM 100 has a higher capacity than the path from ARFM 100 to the destination, i.e., client 104.
  • Data packets 201 within a session are de-queued using a flow scheduler at a rate matching the measured downstream path capacity.
  • the scheduling can either be fair or weighted, based on policy decided by the operator (e.g., to give precedence to a certain flow).
  • each flow 212 can individually be managed by AQM. This may be achieved by utilizing a maximum queueing delay.
  • the ARFM can either drop the data packet packet to make the sender slow down, or de-queue the data packet earlier than in accordance with the estimated bitrate.
  • the maximum queuing delay (per flow) may be decided based on policy and may be configured by the operator of
  • ARFM 100 The ARFM 100.
  • the solution described herein may be implemented in a network node suitable for routing data packets between different networks or network entities, such as a proxy. Embodiments of such a network node are described in the following, with reference to Figs. 4 and 5.
  • Network node 400 comprises at least one network interface 401 , and processing means comprising at least one processor 402 and memory 403, coupled by interconnects.
  • Network interface 401 enables network node 400 to communicate with other network nodes or networks, such as external packet-switched network 101 , operator network 102, or RAN 103.
  • network interface 401 is arranged for receiving data packets 201 from packet-switched network 101 .
  • Processor 402 may, e.g., be a general purpose processor.
  • Memory 403 is a computer-readable storage medium, such as a Random Access Memory (RAM), a Flash memory, or any other type of non-transitory computer-readable storage medium.
  • Memory 403 contains computer-executable instructions 404, i.e., a computer program, which, when executed on processor 402 implement the functionality described herein.
  • the computer-executable 402 instructions may also be embodied in a transitory computer-readable medium such as a signal or carrier wave, and may be downloaded over a network.
  • network node 400 is operative to separate received data packets 201 into different session buffers 21 1 , one for each client 104, based on a respective destination IP address of each data packet 201 , and, for each client 104, separate data packets 201 into different queues 212, one for each flow.
  • Network node 400 is further operative to de-queue data packets 201 in accordance with an estimated bitrate of a data connection between network node 400 and client 104, and forward the de-queued data packets 201 , by means of network interface 401 , to client 104.
  • Network node 400 may further be operative to perform alternative or additional steps in accordance with embodiments of the invention described herein, and may additionally include further components for providing additional functionality, including any functionality described herein and/or any functionality necessary to support the solution described herein.
  • Network node 500 comprises at least one network
  • interface 501 enables network node 500 to communicate with other network nodes or networks, such as external packet-switched network 101 , operator network 102, or RAN 103.
  • network interface 501 is arranged for receiving data packets 201 from a packet-switched network 101 .
  • Queue module 502 is arranged for separating the received data packets 201 into different session buffers 21 1 , one for each client 104, based on a respective destination IP address of each data packet 201 .
  • Queue module 502 is further arranged for, for each client 104, separating data packets 201 into different queues 212, one for each flow.
  • Scheduler 503 is arranged for de-queueing data packets 201 in accordance with an estimated bitrate of a data
  • Network interface 501 may further be arranged to perform alternative or additional steps in accordance with embodiments of the invention described herein, and may additionally include further components for providing additional functionality, including any functionality described herein and/or any functionality necessary to support the solution described herein.
  • Modules 501-503, as well as any additional modules comprised in network node 500 may be implemented by any kind of electronic circuitry, e.g., any one, or a combination of, analogue electronic circuitry, digital electronic circuitry, and processing means executing a suitable computer program.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention concerne un nœud de réseau (100), appelé gestionnaire de débit automatique (ARFM), pour commander un flux descendant de paquets de données vers un ou plusieurs clients (104) d'un réseau d'accès radio (RAN)(103). L'ARFM comprend une interface de réseau pour recevoir les paquets de données à partir d'un réseau à commutation par paquets (101), et des moyens de traitement servant à séparer les paquets de données reçus dans différents tampons de session, un pour chaque client (104), sur la base d'une adresse de protocole Internet (IP) de destination respective de chaque paquet de données et, pour chaque client (104), séparer les paquets de données dans différentes files d'attente, une pour chaque flux, retirer de la file d'attente les paquets de données en fonction d'un débit binaire estimé d'une connexion de données entre le nœud de réseau (100) et le client (104), et acheminer les paquets de données retirés de la file d'attente vers le client (104). Ainsi, un goulot d'étranglement artificiel est créé au niveau de l'ARFM (100), reflétant une capacité de voie descendante (103) disponible dans le réseau. Avantageusement, l'accumulation de files d'attente est ainsi limitée à l'ARFM (100), plutôt qu'en aval (103) de l'ARFM (100).
PCT/EP2015/079128 2015-10-07 2015-12-09 Commande de flux descendant de paquets de données vers un ou plusieurs clients Ceased WO2017059932A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201562238209P 2015-10-07 2015-10-07
US62/238,209 2015-10-07

Publications (1)

Publication Number Publication Date
WO2017059932A1 true WO2017059932A1 (fr) 2017-04-13

Family

ID=54834852

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2015/079128 Ceased WO2017059932A1 (fr) 2015-10-07 2015-12-09 Commande de flux descendant de paquets de données vers un ou plusieurs clients

Country Status (1)

Country Link
WO (1) WO2017059932A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018171868A1 (fr) * 2017-03-21 2018-09-27 Telefonaktiebolaget Lm Ericsson (Publ) Commande de flux descendant de paquets de données par l'intermédiaire d'un ran

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012114328A1 (fr) * 2011-02-21 2012-08-30 Celtro Ltd. Système et procédé pour une gestion de file d'attente active par flux sur un réseau à commutation par paquet
US20140098668A1 (en) * 2012-10-04 2014-04-10 Verizon Patent And Licensing Inc. Tcp flow control optimized for networks having radio segments
EP2764747A1 (fr) * 2011-10-04 2014-08-13 Telefonaktiebolaget LM Ericsson (PUBL) Gestion d'encombrement dans une station de base d'un réseau mobile

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012114328A1 (fr) * 2011-02-21 2012-08-30 Celtro Ltd. Système et procédé pour une gestion de file d'attente active par flux sur un réseau à commutation par paquet
EP2764747A1 (fr) * 2011-10-04 2014-08-13 Telefonaktiebolaget LM Ericsson (PUBL) Gestion d'encombrement dans une station de base d'un réseau mobile
US20140098668A1 (en) * 2012-10-04 2014-04-10 Verizon Patent And Licensing Inc. Tcp flow control optimized for networks having radio segments

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
K. NICHOLS; V. JACOBSON: "Queue", vol. 10, 2012, ACM, article "Controlling queue delay", pages: 20 - 34
S. FLOYD; V. JACOBSON: "Random Early Detection Gateways for Congestion Avoidance", IEEE/ACM TRANSACTIONS ON NETWORKING, vol. 1, 1993, pages 397 - 413

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018171868A1 (fr) * 2017-03-21 2018-09-27 Telefonaktiebolaget Lm Ericsson (Publ) Commande de flux descendant de paquets de données par l'intermédiaire d'un ran

Similar Documents

Publication Publication Date Title
US12255816B2 (en) Packet transmission system and method
EP2698028B1 (fr) Distribution de trafic prenant en charge la qualité d'expérience dans des réseaux cellulaires
CN105706415B (zh) 针对实时视频应用的用于路由器的基于体验质量的队列管理
US20180242191A1 (en) Methods and devices in a communication network
KR102021451B1 (ko) 사용자 평면 인사이트에 기초하는 스루풋 안내
WO2016091298A1 (fr) Mise à jour de politiques de qualité de service (qos) spécifiques à un flux sur la base d'informations rapportées à partir d'une station de base
US10715453B2 (en) Method and network node for congestion management in a wireless communications network
US20240056885A1 (en) Multi-access traffic management
CN103299675A (zh) 用于tcp依赖的流控制的自适应相对比特率管理器
WO2017059932A1 (fr) Commande de flux descendant de paquets de données vers un ou plusieurs clients
WO2018171868A1 (fr) Commande de flux descendant de paquets de données par l'intermédiaire d'un ran
WO2017105300A1 (fr) Nœud de réseau et agencement d'analytique et procédés exécutés par celui-ci pour fournir un service à un dispositif sans fil
Morawski et al. Probabilistic Packet Scheduler for Multipath Data Transfer in Highly Variable Delay Conditions

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15805545

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15805545

Country of ref document: EP

Kind code of ref document: A1