WO2018171868A1

WO2018171868A1 - Controlling downstream flow of data packets via a ran

Info

Publication number: WO2018171868A1
Application number: PCT/EP2017/056700
Authority: WO
Inventors: Robert Skog; Marcus IHLAR
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2017-03-21
Filing date: 2017-03-21
Publication date: 2018-09-27

Abstract

A network node (100), referred to as Automatic Rate Flow Manager (ARFM), for controlling a downstream flow of data packets to one or more mobile terminals (104) via a Radio Access Network (103) (RAN) is provided. The ARFM comprises a network interface for receiving the data packets from a packet-switched network (101, 102), and processing means being operative to determine a destination cell of the RAN for each data packet, to separate the received data packets into different cell buffers, one for each destination cell, and, for each destination cell, separate the data packets into different queues, one for each flow, de-queue the data packets in accordance with estimated bitrates of data connections between the network node (100) and the destination mobile terminals (104), and forward the de-queued data packets to the destination mobile terminals (104). Thereby, an artificial bottleneck is created at the ARFM (100), reflecting an available downstream path capacity in the network. Advantageously, queue-buildup is thereby limited to the ARFM (100), rather than downstream from the ARFM (100), e.g., in the RAN (103).

Description

CONTROLLING DOWNSTREAM FLOW OF DATA PACKETS VIA A RAN Technical field The invention relates to a network node for controlling a downstream flow of data packets to one or mobile terminals via a Radio Access Network (RAN), a method of controlling a downstream flow of data packets to one or more mobile terminals via a RAN, a corresponding computer program, and a corresponding computer program product.

Background

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. This applies in particular to cellular mobile networks, referred to as RANs.

One way of achieving this is to use Active Queue Management (AQM). In Internet routers, AQM is the practice of intelligently dropping network packets inside a buffer associated with a network interface when the buffer becomes full or gets close to becoming full. The dropping of data packets is often done to reduce overall congestion in the network. The task of dropping packets is performed by a network scheduler, using various algorithms such as Random Early Detection (RED) (S. Floyd and

V. Jacobson, "Random Early Detection Gateways for Congestion

Avoidance", IEEE/ACM Transactions on Networking, volume 1 , pages 397- 413, 1993), Explicit Congestion Notification (ECN) ("The Addition of Explicit Congestion Notification (ECN) to IP", Internet Engineering Task Force (IETF) RFC 3168, 2001 ), or Controlled Delay (CoDel) (K. Nichols and V. Jacobson, "Controlling queue delay", Queue, volume 10, pages 20-34, ACM, 2012), which are known in the art. 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-based queue management has been developed as an

improvement over traditional AQM. Such algorithms separate flows into different queues and attempt to preserve isolation between different flows, thereby reducing the risk of an aggressive flow taking precedence over, "starving out", a less aggressive flow. As an example, Flow-Queue CoDel (FQ-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 ("The FlowQueue-CoDel Packet Scheduler and Active Queue

Management Algorithm", IETF Internet-Draft draft-ietf-aqm-fq-codel-06, 2016).

AQM is typically deployed at potential bottlenecks in the network.

These bottlenecks include host operating systems, internet routers, 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.

The use of a Transport Control Protocol (TCP) proxy is an alternative to improve network utilization as well as mitigate network congestion. TCP proxies typically improve network utilization by using specifically tuned Congestion Control Algorithms (CCAs) that perform well in RANs. 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. 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 the TCP 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.

An operator's radio network is frequently deployed with different radio access technologies, i.e., a is a combination of different types of RANs, such as Global System for Mobile Communications (GSM), Universal Mobile

Telecommunications System (UMTS), Long Term Evolution (LTE), and next- generation radio access technologies colloquially termed "5G", each radio- access technology having different characteristics. Operators can

configure/tune their RANs in different ways, e.g., using AQM in LTE radio base stations. However, the resulting differences in radio characteristics will have an impact on the characteristics of a transport protocol which is used for transmitting data over the RAN, such as TCP, in particular in the downlink. For instance, an origin server such as a web server located on the Internet, serving mobile terminals 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.

Summary

It is an object of the invention to provide an improved alternative to the above techniques and prior art.

More specifically, it is an object of the invention to provide an improved flow-control of downstream data packets transmitted to one or mobile terminals receiving the data packets via a RAN. These and other objects of the invention are achieved by means of different aspects of the invention, as defined by the independent claims. Embodiments of the invention are characterized by the dependent claims.

According to a first aspect of the invention, a network node for controlling a downstream flow of data packets to one or more mobile terminals is provided. The one or more mobile terminals receive the data packets via a RAN. The network node comprises at least one network interface and processing means. The at least one network interface is configured to receive the data packets from a packet-switched network, such as the Internet. The processing means is operative to determine a destination cell of the RAN for each of the received data packets, and to separate the received data packets into different cell buffers, one for each destination cell. The destination cell is a cell of the RAN through which a destination mobile terminal of the one or more mobile terminals, to which the data packet is destined, accesses the RAN. The processing means is further operative, for each destination cell, i.e., for each cell buffer, to separate the data packets into different queues, one for each flow, de-queue the data packets, and to forward the de-queued data packets to the destination mobile terminals. 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 estimated bitrates of data connections between the network node and the destination mobile terminals accessing the RAN. The de-queued data packets are forwarded by means of the at least one network interface.

According to a second aspect of the invention, a method of controlling a downstream flow of data packets to one or more mobile terminals is provided. The one or more mobile terminals receive the data packets via a RAN. The method is performed by a network node and comprises receiving the data packets from a packet-switched network, such as the Internet, determining a destination cell of the RAN for each of the received data packets, and separating the received data packets into different cell buffers, one for each destination cell. The destination cell is a cell of the RAN through which a destination mobile terminal of the one or more mobile terminals, to which the data packet is destined, accesses the RAN. The method further comprises, for each destination cell, i.e., for each cell 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 destination mobile terminals. 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 estimated bitrates of data connections between the network node and the destination mobile terminals accessing the RAN.

According to a third aspect of the invention, a computer program is provided. The computer program comprises computer-executable

instructions for causing a device to perform the method according to an embodiment of the second aspect of the invention, when the computer- executable instructions are executed on a processing unit comprised in the device.

According to a fourth aspect of the invention, a computer program product is provided. The 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 mobile terminals via a RAN can be achieved by means of a network node operating as Automatic Rate Flow Manager (ARFM), which is described herein. The ARFM is a single ingress (entry) and egress (exit) point for mobile terminals accessing the RAN through a certain cell 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 the 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. In the prior art, 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 mobile terminal at an upstream location, the build-up of queues at potential bottlenecks downstream from the ARFM, e.g., in the operator network or the RAN, is avoided.

By separating received data packets based on their respective destination cell, i.e., the cell of the RAN through which the mobile terminal to which a data packet is destined accesses the RAN, the different flows carrying data packets are grouped based on destination cell. Embodiments of the invention allow the mobile terminals within a destination cell to utilize the available bandwidth in situations when there is no or little congestion in the destination cell and capacity is limited by channel quality or the like.

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 mobile terminals, as is the case for mobile terminals receiving data packets via a RAN, or via 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 mobile terminals have separate scheduling queues.

According to an embodiment of the invention, the data packets are dequeued at bitrates which are substantially equal to the estimated bitrates for the destination mobile terminals. Optionally, the bitrate of the data connection between the network node and each mobile terminal may be estimated by the network node. For instance, the bitrate may be estimated by measuring the rate of acknowledgements pertaining to a transport protocol used by the mobile terminal, correlated with the amount of data packets sent to the mobile terminal. Alternatively, 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.

According to an embodiment of the invention, the data packets may be de-queued using a weighted scheduler, based on a type of traffic carried by a flow. The priorities, or weights, used by the scheduler may, e.g., be configured in accordance with a policy decided by an operator of the network node. The type of traffic carried by a flow may, e.g., be determined based on a source IP address of data packets carried by the flow.

According to an embodiment of the invention, the data packets are dequeued in accordance with a maximum queueing delay. Thereby, the sending rate per flow can be regulated. The maximum queueing delay may be configured by an operator of the network node.

Even though advantages of the invention have in some cases been described with reference to embodiments of the first aspect of the invention, corresponding reasoning applies to embodiments of other aspects of the invention.

Further objectives of, features of, and advantages with, the invention will become apparent when studying the following detailed disclosure, the drawings, and the appended claims. Those skilled in the art realize that different features of the invention can be combined to create embodiments other than those described in the following. Brief description of the drawings

The above, as well as additional objects, features and advantages of the invention, will be better understood through the following illustrative and non-limiting detailed description of embodiments of the invention, with reference to the appended drawings, in which:

Fig. 1 shows possible deployment points for the network node for controlling a downstream flow of data packets to one or more mobile terminals via a RAN, in accordance with embodiments of the invention.

Fig. 2 schematically illustrates controlling a downstream flow of data packets to one or more mobile terminals via a RAN, in accordance with embodiments of the invention.

Fig. 3 shows a sequence diagram illustrating controlling a downstream flow of data packets to one or more mobile terminals via a RAN, 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 mobile terminals via a RAN, 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 mobile terminals via a RAN, in accordance with another embodiment of the invention.

Fig. 6 shows a flow chart illustrating a method of controlling a downstream flow of data packets to one or more mobile terminal via a RAN, in accordance with embodiments of the invention.

All the figures are schematic, not necessarily to scale, and generally only show parts which are necessary in order to elucidate the invention, wherein other parts may be omitted or merely suggested. Detailed description

The invention will now be described more fully herein after with reference to the accompanying drawings, in which certain embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

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 mobile terminal 104, such as a mobile phone, a smartphone, a tablet, or a UE. In Fig. 1 , four mobile terminals 104 ("MT A", "MT B", "MT C", and "MT D") are illustrated accessing RAN 103 through two different cells 105 ("Cell 1 " and "Cell 2"). 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. 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). Alternatively, the 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. In the prior art, bottlenecks may, e.g., build up in radio access nodes of the RAN 103 due to limitations in air- interface capacity.

In the following, the operation of ARFM 100 is described in more detail with reference to Fig. 2, which schematically illustrates the flow of

downstream data packets 201 from left to right. Data packets 201 reaching ARFM 100 from an upstream source, such as the Internet or any other external packet-switched network 101 , are separated into different cell buffers 210 and 220 based on their respective destination cell 105 of

RAN 103, i.e., based on the cell through which the destination mobile terminal, to which a data packet is addressed, accesses RAN 103. For instance, as is illustrated in Fig. 1 , the destination cell 105 for mobile terminals 104 "MT A" and "MT B" is "Cell 1 ", and the destination cell 105 for mobile terminals 104 "MT C" and "MT D" is "Cell 2". It will be appreciated that, whereas in Figs. 1 and 2 four mobile terminals 104 and two cells 105 are illustrated, embodiments of the invention are not limited to a specific number of mobile terminals 104 or cells 105. Data packets 201 received from the upstream network are addressed to one of mobile terminals 104. Each mobile terminal 104 may, e.g., be a mobile phone, a smartphone, a tablet, or a UE.

The respective path capacity (herein also referred to as bandwidth), more specifically the bitrate, from ARFM 100 to each of mobile terminals 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 mobile terminals 104. If TCP is used as a transport protocol, the acknowledgement received from mobile terminals 104 are signaled by means of the ACK flag.

The flow of data packets 201 within ARFM 100 is regulated on a per- cell basis, taking the path capacity estimated for each mobile terminal 104 into account. This is achieved by creating artificial bottlenecks 213, one for each mobile terminal 104. As a consequence, a queue will build up at the artificial bottleneck 213, i.e., at ARFM 100, if the downstream path between ARFM 100 and destination mobile terminal 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 .

For cell buffers 210 and 220, i.e., for each destination cell 105, the data packets are separated into different queues 212 based on which flow they belong to. In the present context, 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. In Fig. 2, each mobile terminal 104 is illustrated as receiving two flows ("MT A" and "MT C": downward diagonal pattern and upward diagonal pattern, respectively; "MT B" and "MT D":

horizontal pattern and vertical pattern, respectively). Data packets are dequeued 213 on a per-flow basis, using either a fair or weighted scheduler, and forwarded downstream to RAN 103, for subsequent transmission to mobile terminals 104, with bitrates which are substantially equal to estimated bitrates for each mobile terminal 104. As a consequence of creating an artificial bottleneck 213 for each mobile terminal 104 at an upstream location, the build-up of queues at potential bottlenecks downstream from ARFM 100, e.g., in the operator network 102 or the RAN 103, is avoided.

Embodiments of the invention simplify deployment of AQM since only a single node, ARFM 100, is sufficient to manage the entire network downstream from the point of deployment. In contrast to a conventional TCP proxy, 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. Advantageously, 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.

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.

Since the buffering of data packets is limited to ARFM 100, high- priority traffic is likely to be scheduled by a scheduler of RAN 103 without any further delay, if data packets are de-queued using a weighted scheduler based on traffic type. Flows with lower priority may experience a delay at ARFM 100, due to buffering in one of cell buffers 210 and 220, which may trigger an AQM response with a dropped packet or an ECN. The type of traffic which is carried by a flow may, e.g., be determined based on the source IP address of a data packet which is received by ARFM 100 from an upstream packet-switched network 101 or 102. This is the case since the source IP address identifies the origin of a data packet, e.g., a web server or a server providing a media stream. Advantageously, ARFM 100 may maintain a database for associatively storing information pertaining to traffic type and source IP address. The traffic type of a flow may, e.g., by any one of, but is not limited to: web traffic, video traffic, voice traffic, chat traffic, bulk download, streamed media, and so forth.

Advantageously, the solution described herein allows all mobile terminals in a destination cell to maximize their utilization of the available bandwidth when there is no or little congestion in the destination cell. In case of congestion in the destination cell, prioritized flows may experience an increased capacity as compared to lower-priority flows.

ARFM 100 may be deployed in networks where path characteristics may differ considerably between connections to different mobile

terminals 104, as may be the case for mobile terminals receiving data packets via a RAN 103, or via different RANs with different radio

characteristics and/or radio access technologies. A typical example of such a network is 3GPP-type of network in which different mobile terminals have separate scheduling queues.

In the following, embodiments of the invention are elucidated in further detail with reference to Fig. 3, which shows a signaling diagram 300 illustrating controlling a downstream flow of data packets to one or more mobile terminals 104 via RAN 103. In particular, it is described how

ARFM 100 separates received data packets into different cell buffers 210 and 220, based on their respective destination cell 105.

As is illustrated in Fig. 3, a mobile terminal 104 transmits a

request 301 to RAN 103. Request 301 may, e.g., be a HyperText Transfer Protocol (HTTP) request for retrieving a resource, such as a HyperText Markup Language (HTML) file or the like. Request 301 comprises, among other information, an identifier of mobile terminal 104 ("MT ID"), e.g., the IP address of mobile terminal 104, which is included as source IP address in a TCP header of request 301 , or any other identifier which may be used for addressing mobile terminal 104, such as the International Mobile Subscriber Identity (IMSI) the or International Mobile Equipment Identity (IMEI).

In response to receiving request 301 , a network node of RAN 103, e.g., a PGW or PDN-GW, identifies 302 the destination cell 105 through which mobile terminal 104 accesses RAN 103, e.g., one of "Cell 1 " and "Cell 2" illustrated in Fig. 1 , and forwards request 301 upstream as

request 303. In addition to the identifier of mobile terminal 104 ("MT ID"), request 303 further comprises an identifier of the destination cell 105

("Cell ID") through which mobile terminal 104 accesses RAN 103. The identifier of the destination cell, "Cell ID", may, e.g., be comprised in a

Network Service Header (NSH) encapsulating request 301 ("Network Service Header", IETF Internet-Draft, draft-ietf-sfc-nsh-12, February 23, 2017).

Alternatively, the identifier of the destination cell may be comprised in an HTTP header or HTTP payload of request 303, in the TCP Options field of a TCP header of request 303, or in a U DP header of request 303. Request 303 is intercepted by ARFM 100 which extracts the information identifying mobile terminal 104 and the destination cell 105 from request 303 and associatively stores 304 the extracted information, i.e., "MT ID" and "Cell ID", in a database. Preferably, this database is maintained by ARFM 100, but may alternatively be an external database maintained by, e.g., a subscriber database such as a Home Location Register (HLR) or the like. In addition to storing 304 the association between "MT ID" and "Cell ID", ARFM 100 forwards request 303 as request 305 to an upstream packet- switched network (PS network), e.g., an external packet-switched

network 101 or an operator's packet-switched network 102. Request 305 may, e.g., be routed to an origin server in packet-switched network 101/102, e.g., a web server, from which the resource requested by mobile terminal 104 may be retrieved. Request 305 may, or may not, comprise the identifier of the destination cell 105, "Cell ID".

When a response 31 1 is received by ARFM 100 from packet-switched network 101/102, e.g., an HTML response from an origin server, ARFM 100 determines a destination cell 105 of RAN 103 through which destination mobile terminal 104, to which the data packet is destined, accesses

RAN 103. The destination cell 105 may, e.g., be determined based on a respective destination IP address of each data packet, in Fig. 3 illustrated as "MT ID". This is the case since the destination IP address of a data packet, which may, e.g., be comprised in TCP header of the data packet, identifies the destination mobile terminal 104 of the data packet.

More specifically, ARFM 100 determines the destination cell 105 by retrieving 312 the cell identifier ("Cell ID") which is associated with a respective destination IP address ("MT ID") of a data packet from the database. Based on the destination cell 105 which is determined 312 for each data packet, the data packets are separated 313 into different cell buffers 210 and 220, and subsequently further separated 314 into different flow queues 212, one for each flow. Then, ARFM 100 de-queues 315 the data packets in each flow in accordance with estimated bitrates of data connections between ARFM 100 and the destination mobile terminals 104 accessing RAN 103, and forwards the de-queued data packets as response 316 to RAN 103, which

subsequently transmits the data packets as response 317 to their respective destination mobile terminals 104.

As an alternative to receiving information identifying the destination cell 105 through which mobile terminal 104 access RAN 103 by means of in- band signaling, e.g., via request 303, one may also envisage embodiments of the invention which are based on out-of-band signaling. For instance, an embodiment of ARFM 100 may be operative to request the identifier of the destination cell 105 ("Cell ID") from a network node of RAN 103, e.g., a PGW or PDN-GW, based on an identifier of destination mobile terminal 104

("MT ID").

An embodiment of ARFM 100 is preferably deployed as an ingress node at an entry point to a network, e.g., an entry point of RAN 103 or an operator network 102, as is illustrated in Fig. 1 . Downstream data

packets 201 which are received from an external packet-switched

network 101 , or an operator's packet-switched network 102, are routed via ARFM 100 where they are separated into different cell buffers 210 and 220, one for each destination cell 105, and separated into different queues 212, one for each flow (as defined by the packet's 5-tuple (source IP address, destination IP address, source port number, destination port number, protocol number).

Then, for each destination cell 105, an artificial bottleneck 213 is created by de-queueing data packets 201 in accordance with an estimated capacity of the data connections between ARFM 100 and the respective destination mobile terminal 104 in the destination cell 105. To this end, 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 destination mobile terminal 104.

The capacity or bandwidth, i.e., the available bitrate between

ARFM 100 and a mobile terminal 104, may be estimated based on measurements of the capacity of the downstream path towards the respective mobile terminal 104. For instance, the path capacity may be estimated by measuring the rate of TCP (or other transport protocol) acknowledgements correlated to the amount of downstream data

packets 201 sent to a destination mobile terminal 104.

Additionally, or alternatively, explicit feedback information from a bottleneck in the network, such as a radio base station or any other network node, 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 may be realized by regulating the de-queuing rate of the individual flows 212. As a result, queues will build up in ARFM 100 if the path between an upstream source 101 or 102 and ARFM 100 has a higher capacity than the path from ARFM 100 to destination mobile terminal 104. Within each cell buffer, data packets 201 are de-queued using a flow scheduler at a rate which matches 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).

In order to regulate the sending rate per flow (from source 101 ), each flow 212 can individually be managed by AQM. This may be achieved by utilizing a maximum queueing delay. When the maximum queuing delay is reached, the ARFM can either drop the data 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 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.

In Fig. 4, an embodiment 400 of network node 100 for controlling a downstream flow of data packets to one or more mobile terminals via a RAN is illustrated. Network node 400 comprises at least one network interface 401 ("Nl"), 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 an external packet-switched network, an operator packet-switched network, or the RAN. In particular, network interface 401 is configured to receive data packets from a packet-switched network. 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.

In particular, network node 400 is operative, for each of the received data packets, to determine a destination cell of the RAN through which a destination mobile terminal of the one or more mobile terminals, to which the data packet is destined, accesses the RAN, and to separate the received data packets into different cell buffers, one for each destination cell. Network node 400 is further operative, for each destination cell, to separate the data packets into different queues, one for each flow, and to de-queue the data packets in accordance with estimated bitrates of data connections between network node 400 and the destination mobile terminals accessing the RAN, and to forward the de-queued data packets, by means of network

interface 401 , to the destination mobile terminals.

Preferably, network node 400 is operative to determine the destination cell of the RAN based on a respective destination IP address of each data packet. For instance, network node 400 may be operative to receive a message comprising an IP address of a mobile terminal and an identifier of a cell through which the mobile terminal accesses the RAN from a network node of the RAN, and associatively store the IP address and the cell identifier in a database. Network node 400 is further operative to determine the destination cell of the RAN by retrieving the cell identifier which is associated with a respective destination IP address of a data packet from the database.

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.

In Fig. 5, an alternative embodiment 500 of network node 100 for controlling a downstream flow of data packets to one or more mobile terminals via the RAN is illustrated. Network node 500 comprises at least one network interface 501 ("Nl"), a cell module 502, a queue module 503, and a scheduler 504.

Network interface 501 enables network node 500 to communicate with other network nodes or networks, such as an external packet-switched network, an operator packet-switched network, or the RAN. In particular, network interface 501 is configured to receive data packets from a packet- switched network. Cell module 502 is configured to determine, for each of the received data packets, a destination cell of the RAN through which a destination mobile terminal of the one or more mobile terminals, to which the data packet is destined, accesses the RAN. Queue module 502 is configured to separate the received data packets into different cell buffers, one for each destination cell. Queue module 502 is further configured, for each destination cell, to separate the data packets into different queues, one for each flow. Scheduler 504 is configured to de-queue the data packets in accordance with estimated bitrates of data connections between network node 500 and the destination mobile terminals accessing the RAN, and to forward the dequeued data packets, by means of network interface 501 , to destination mobile terminals.

Preferably, cell module 502 is configured to determine the destination cell of the RAN based on a respective destination IP address of each data packet. For instance, cell module 502 may be configured to receive, from a network node of the RAN, a message comprising an IP address of a mobile terminal and an identifier of a cell through which the mobile terminal accesses the RAN, and to associatively store the IP address and the cell identifier in a database. Cell module 502 is further configured to determine the destination cell of the RAN by retrieving the cell identifier which is associated with a respective destination IP address of a data packet from the database.

Network interface 501 , cell module 502, queue module 503, and scheduler 504, may further be configured 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 401 and 501-504, 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. In Fig. 6, embodiments 600 of the method of controlling a downstream flow of data packets to one or more mobile terminals via a RAN are illustrated. Embodiments of method 600 may be performed by a network node which is preferably deployed as an ingress node at an entry point of one of the RAN and an operator network. Method 600 comprises

receiving 603 the data packets from a packet-switched network and, for each of the received data packets, determining 604 a destination cell of the RAN through which a destination mobile terminal of the one or more mobile terminals, to which the data packet is destined, accesses the RAN.

Method 600 further comprises separating 605 the received data packets into different cell buffers, one for each destination cell. Method 600 further comprises separating 606, for each destination cell, the data packets into different queues, one for each flow, de-queueing 607 the data packets in accordance with estimated bitrates of data connections between the network node and the destination mobile terminals accessing the RAN, and

forwarding 608 the de-queued data packets to the destination mobile terminals.

Optionally, the data packets are de-queued 607 at bitrates which are substantially equal to the estimated bitrates for the destination mobile terminals.

Optionally, the data packets are de-queued 607 using a weighted scheduler, based on a type of traffic carried by a flow.

Optionally, method 600 further comprises estimating the bitrate of the data connection between the network node and each of the mobile terminals. For instance, the bitrate may be estimated by measuring the rate of acknowledgements pertaining to a transport protocol used by a mobile terminal, correlated with the amount of data packets sent to the mobile terminal. Alternatively, the bitrate may be estimated based on feedback information received from a downstream network node. Optionally, the data packets are de-queued 607 in accordance with a maximum queueing delay.

Preferably, the destination cell of the RAN is determined based on a respective destination IP address of each data packet. For instance, method 600 may further comprise receiving, from a network node of the RAN, a message comprising an IP address of a mobile terminal and an identifier of a cell through which the mobile terminal accesses the RAN, and associatively storing the IP address and the cell identifier in a database. The determining 604 a destination cell of the RAN comprises retrieving the cell identifier which is associated with a respective destination IP address of a data packet from the database.

It will be appreciated that method 600 may comprise additional, or modified, steps in accordance with what is described throughout this disclosure. An embodiment of method 600 may be implemented as software, such as computer program 604, to be executed by a processing unit comprised in a network node, e.g., a proxy, whereby the network node becomes operative to perform in accordance with embodiments of the invention described herein.

The person skilled in the art realizes that the invention by no means is limited to the embodiments described above. On the contrary, many modifications and variations are possible within the scope of the appended claims.

Claims

1 . A network node (100; 400; 500) for controlling a downstream flow of data packets (201 ) to one or more mobile terminals (104) via a Radio Access Network (103), RAN, the network node comprising:

at least one network interface (401 ; 501 ) configured to receive the data packets from a packet-switched network (101 , 102), and

processing means (402-404; 502, 503) being operative to:

for each of the received data packets, determine a destination cell (105) of the RAN through which a destination mobile terminal of the one or more mobile terminals, to which the data packet is destined, accesses the RAN,

separate the received data packets into different cell

buffers (210, 220), one for each destination cell, and

for each destination cell:

separate the data packets into different queues (212), one for each flow,

de-queue (213) the data packets in accordance with estimated bitrates of data connections between the network node and the destination mobile terminals accessing the RAN, and

forward the de-queued data packets, by means of the at least one network interface, to the destination mobile terminals.

2. The network node according to claim 1 , the processing means being operative to de-queue the data packets at bitrates which are

substantially equal to the estimated bitrates for the destination mobile terminals.

3. The network node according to claim 1 or 2, the processing means being operative to de-queue the data packets using a weighted scheduler, based on a type of traffic carried by a flow.

4. The network node according to any one of claims 1 to 3, the processing means being further operative to, for each mobile terminal, estimate the bitrate of the data connection between the network node and the mobile terminal.

5. The network node according to claim 4, the processing means being operative to estimate the bitrate by measuring the rate of

acknowledgements pertaining to a transport protocol used by the mobile terminal, correlated with the amount of data packets sent to the mobile terminal.

6. The network node according to claim 4, the processing means being operative to estimate the bitrate based on feedback information received from a downstream network node.

7. The network node according to claim 6, wherein the feedback information is received from a Radio Resource Management, RRM, node of the RAN.

8. The network node according to any one of claims 1 to 7, the processing means being operative to de-queue the data packets in accordance with a maximum queueing delay.

9. The network node according to any one of claims 1 to 8, wherein the network node is deployed as an ingress node at an entry point of one of the RAN (103) and an operator network (102).

10. The network node according to any one of claims 1 to 9, the processing means being operative to determine the destination cell of the RAN based on a respective destination Internet Protocol, IP, address of each data packet.

1 1 . The network node according to claim 10, the processing means being further operative to:

receive, from a network node of the RAN, a message comprising an IP address of a mobile terminal and an identifier of a cell through which the mobile terminal accesses the RAN, and

associatively store the IP address and the cell identifier in a database, the processing means being operative to determine the destination cell of the RAN by retrieving the cell identifier which is associated with a respective destination IP address of a data packet from the database.

12. The network node according to any one of claims 1 to 1 1 , wherein each flow is defined by a 5-tuple comprising: source Internet Protocol, IP, address, destination IP address, source port number, destination port number, and protocol number.

13. A method (600) of controlling a downstream flow of data packets (201 ) to one or more mobile terminals (104) via a Radio Access Network (103), RAN, the method being performed by a network node (100; 400) and comprising:

receiving (603) the data packets from a packet-switched

network (101 ),

for each of the received data packets, determining (604) a destination cell of the RAN through which a destination mobile terminal of the one or more mobile terminals, to which the data packet is destined, accesses the RAN,

separating (605) the received data packets into different cell buffers (210, 220), one for each destination cell, and

for each destination cell:

separating (606) the data packets into different queues (212), one for each flow,

de-queueing (607) the data packets in accordance with estimated bitrates of data connections between the network node and the destination mobile terminals accessing the RAN, and

forwarding (608) the de-queued data packets to the destination mobile terminals.

14. The method according to claim 13, wherein the data packets are de-queued at bitrates which are substantially equal to the estimated bitrates for the destination mobile terminals.

15. The method according to claim 13 or 14, wherein the data packets are de-queued using a weighted scheduler, based on a type of traffic carried by a flow.

16. The method according to any one of claims 13 to 15, further comprising, for each mobile terminal, estimating the bitrate of the data connection between the network node and the mobile terminal.

17. The method according to claim 16, wherein the bitrate is estimated by measuring the rate of acknowledgements pertaining to a transport protocol used by the mobile terminal, correlated with the amount of data packets sent to the mobile terminal.

18. The method according to claim 16, wherein the bitrate is estimated based on feedback information received from a downstream network node.

19. The method according to claim 18, wherein the feedback information is received from a Radio Resource Management, RRM, node of the RAN (103).

20. The method according to any one of claims 13 to 19, wherein the data packets are de-queued in accordance with a maximum queueing delay.

21 . The method according to any one of claims 13 to 20, wherein the network node is deployed as an ingress node at an entry point of one of the RAN (103) and an operator network (102).

22. The method according to any one of claims 13 to 21 , wherein the destination cell of the RAN is determined (604) based on a respective destination Internet Protocol, IP, address of each data packet.

23. The method according to claim 22, further comprising:

receiving (601 ), from a network node of the RAN, a message comprising an IP address of a mobile terminal and an identifier of a cell through which the mobile terminal accesses the RAN, and

associatively storing (602) the IP address and the cell identifier in a database,

wherein the determining (604) a destination cell of the RAN comprises retrieving the cell identifier which is associated with a respective destination IP address of a data packet from the database.

24. The method according to any one of claims 13 to 23, wherein each flow is defined by a 5-tuple comprising: source Internet Protocol, IP, address, destination IP address, source port number, destination port number, and protocol number.

25. A computer program (404) comprising computer-executable instructions for causing a device to perform the method according to any one of claims 13 to 24, when the computer-executable instructions are executed on a processing unit (402) comprised in the device.

26. A computer program product comprising a computer-readable storage medium (403), the computer-readable storage medium having the computer program (404) according to claim 25 embodied therein.