Patent Application
20150117205
This application claims benefit of European patent application no. EP13190945.9, filed 30 Oct. 2013, the disclosure of which is incorporated herein by reference in its entirety.
Embodiments of the present disclosure generally relate to controlling sending rates in a communications network. More particularly, embodiments disclosed herein relate to methods performed in a network node for controlling sending rates from said network node. Furthermore, embodiments of the present disclosure are also directed to a corresponding network node.
In the field of data and telecommunication the demand for sending larger and larger amounts of data is ever increasing. The demand for streaming movies, music, games etc. steady increases as the communication channels increase their capacity of sending or transmitting data. Even if development over recent years has been fast and the capacity in the different communication channels has doubled many times, there are still bottlenecks due to the large amount of data that is communicated. This leads to more frequent occurrences of network congestion when the offered traffic is higher than what for example a Radio Access Network, RAN, is able to fulfill. It is today also common with new services, which may lead to situations where new requirements have to be introduced in the network very quickly in respect of a new Quality of Experience, QoE. In this situation operators will need efficient and flexible tools by which they can share and control the RAN capacity and maximize the QoE for their users.
In the current 3rd Generation Partnership Project (3GPP) a Quality of Service, QoS,
is based on a bearer mechanism, e.g. as described in 3GPP TS 23.401 section 4.7.2. Traffic that requires differentiated QoS treatment is classified into bearers. For each bearer, the QoS Class Identifier, QCI, parameter determines the basic QoS treatment. A few other parameters, such as the Maximum BitRate, MBR, Guaranteed BitRate, GBR, User Equipment, UE, or Access Point Name, APN, specific Aggregate Maximum BitRate, AMBR and Allocation and Retention Priority, ARP parameters can further influence the QoS applied to the bearer traffic.
The bearer based QoS has some limitations which has so far prevented its wide adoption. One limitation is that for 3rd Generation, 3G, the network based QoS mechanism requires the release-7 of the Network Initiated Dedicated Bearer, NIDB, support, which has so far not yet materialized in terminal equipment. Even though new NIDB enabled terminals may come out, it may take a few years before they reach a sufficiently high penetration for operators to make efficient use of the feature.
As another limitation, the QoS parameters as currently defined do not provide a predictable QoE in case of congestions in the communications network. The GBR and MBR parameters only apply to GBR bearers while most of the traffic currently is routed goes over non-GBR bearers. The AMBR parameter only allows enforcement of a maximum over several bearers which is not flexible enough to specify congestion behavior.
There can be many proprietary parameters based on the QCI which are set in the RAN. However, operators typically have equipment from multiple vendors in their network, which makes it difficult to manage vendor specific parameter settings, typically via the Operations and Maintenance, O&M, system. With proprietary QoS mechanisms, it is hard for the operator to provide a predictable user experience.
There are two common ways of defining and signaling desired resource demands to a bottleneck in the communications network. A bottleneck is a location in the communications network that experiences congestion, for example a location where a single or limited number of components or resources affect the capacity or performance of the communications network.
The first common way is to pre-signal/pre-configure the desired resource sharing rules for a given traffic aggregate, such as a flow or a bearer, to a bottleneck node prior to the arrival of the actual traffic. The bottleneck node may then implement the handling of the traffic aggregates based on these sharing rules, e.g. uses scheduling to accomplish the desired resource sharing. Examples of these pre-signaling/pre-configuration methods are e.g. the bearer concept of 3GPP [3GPP TS 23.401], SIRIG [3GPP TS 23.060 section 5.3.5.3], or Resource Reservation Protocol. RSVP, [RFC2205].
The second common way is to mark packets with drop precedence, which marks the relative importance of the packets compared to each other. Packets of higher drop precedence are to be dropped before packets of lower drop precedence. An example for such method is DiffServ Assured Forwarding, AF, within a given class [RFC2597].
It is an open issue how to signal service policies to different resource bottlenecks, including both transport bottlenecks and radio links. The term service policy in this document denotes instructions on how the available resources at a packet scheduler shall distribute the available, primarily transmission, resources among the packets of various packet flows arriving to the scheduler. The term “resource sharing rules” is used in the same meaning. In the case of radio links, the service policy also needs to define how a terminal dependent radio channel overhead should affect the resource sharing. Such a scheme for signaling should preferably be simple, versatile and fast to adapt to the actual congestion situation.
Pre-signaling/pre-configuration solutions can describe a rich set of different resource sharing policies. However, these policies have to be configured in advance of actual traffic at all bottlenecks, which limits the flexibility of policies, and the pre-configuration of a large number of resource sharing policies also requires resources at each node in order to maintain the polices, which may be costly. Furthermore, the polices have to be signaled before the first packet of the flow arrives, which adds a setup delay and overhead before the first packet can be delivered. In addition, these solutions usually require traffic handling on a per aggregate/flow basis, e.g., separate queues per traffic aggregate/flow and implement a per traffic aggregate/flow resource sharing mechanism. While it in some cases is possible to realize this, e.g. with per bearer handling over air interface, in other cases this puts additional complexity to the system, e.g. over RAN Transport Network, TN bottlenecks or within bearer differentiation.
The drop precedence marking solutions, as mentioned above, are limited by the interpretation of drop precedence, leading to a limited non-flexible handling of the packets in the communications network.
Furthermore in the transport network of a 3GPP Long-Term Evolution, LTE, High Speed Downlink Packet Access, HSDPA, or WiFi system, the support of packet drop precedence is very limited. Either there are only a few drop precedence levels or drop precedence is not supported at all in the transport network. However, the support of several drop precedence levels and in parts of the system is advantageous in order to support end-to-end service policies and congestion control.
In the transport network, which typically operates in the network layer, there is one method available to signal drop precedence, namely the Differentiated Services Code Point, DSCP, field in the IP header. DSCP defines 3 drop precedence levels; low drop, medium drop and high drop. It is possible to define more drop precedence levels by using several DSCPs. However, this would not be supported by all equipments in the transport network and it might also allocate too many of the DSCPs.
Thus, there is a need for a method for controlling sending rates from a network node depending on the congestion state of in the transport network.
An object of embodiments herein is to provide a method for controlling sending rates in a communications network depending on the congestion state in a transport network.
The object may be achieved by a method performed by a network node. The method comprises receiving a data packet from a transport network. The received data packet comprises information about a packet drop precedence value and an Explicit Congestion Notification, ECN, flag, comprising information about congestions in the transport network. The method further comprises dropping received data packets in the network node, in response to that the ECN flag indicates that there is a congestion in the transport network and based on the packet drop precedence value. The packet drop precedence value may be indicated in the RAN or IP header.
In various embodiments the method further comprises reading, for each data packet, the RAN or IP header to determine the packet drop precedence value, comparing the read packet drop precedence value with a threshold and forwarding data packets having a packet drop precedence value below the threshold and dropping data packets having a packet drop precedence value above the threshold.
In other embodiments the dropping of received packets in the network node may be equally distributed among the available sending bearers of the network node.
Furthermore the ECN flag may be set by an ECN capable router in the transport network and may comprise two bits, which are set to 11 for indicating congestion in the transport network.
A further object of embodiments herein is to provide a network node for controlling sending rates in a communications network depending on the congestion state in a transport network. The network node comprises a communication interface arranged for wireless communication with a transport network, a processor, a memory storing a software package comprising computer program code which, when run in the processor, causes the network to receive a data packet from the transport network, said data packet comprising information about a packet drop precedence value and an Explicit Congestion Notification, ECN, flag, comprising information about congestions in the transport network; and drop received data packets in the network node, in response to an indication by the ECN flag that there is congestion in the transport network and based on the packet drop precedence value. The packet drop precedence value may be indicated in the RAN or IP header.
In various embodiments the network node may be further caused to read, for each data packet, the RAN or IP header to determine the packet drop precedence value, compare the read packet drop precedence value with a threshold; and forwarding data packets having a packet drop precedence value below the threshold and dropping data packets having a packet drop precedence value above the threshold. The drop of the received data packets may be equally distributed among the available sending bearers of the network node.
Taking into account the state of the transport network, i.e. if there are any congestions or not, is advantageous in order to support end-to-end service polices and congestion control and will also extend the number of drop precedence levels in the transport network.
These and other aspects, features and advantages of embodiments of the present disclosure will be apparent and elucidated from the following description of various embodiments, reference being made to the accompanying drawings, in which:
In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular components, elements, techniques, etc. in order to provide a thorough understanding of the exemplifying embodiments. However, it will be apparent to one skilled in the art that the exemplifying embodiments may be practiced in other manners that depart from these specific details. In other instances, detailed descriptions of well-known methods and elements are omitted so as not to obscure the description of the example embodiments. The terminology used herein is for the purpose of describing the example embodiments and is not intended to limit the embodiments presented herein.
The communications network 2 in
The PGW 10 provides connectivity to external Packet Data Networks, PDNs, e.g. Internet, to the UE 50 by being the point of exit and entry of traffic for the UE 50. The UE 50 may have simultaneous connectivity with more than one PGW 10 for accessing multiple PDNs. Typically the PGW 10 performs one or more of the following; policy enforcement, packet filtering for each user, charging support, lawful interception and packet screening. Another key role of the PGW 10 is to act as the anchor for mobility between 3GPP and non-3GPP technologies such as Worldwide Interoperability for Microwave Access, WiMAX, and 3GPP2 (Code Division Multiple Access, CDMA, 1X and Enhanced Voice-Data Only, EvDO). In a General Packet Radio Service, GPRS, network the equivalent of the PGW 10 is the Gateway GPRS Support Node, GGSN, and is responsible for the interworking between the GPRS network and external packet data networks, like the Internet and X.25 networks.
The ECN aware router 60 is a router that supports explicit congestion notification in order to propagate ECN signals. The ECN signals or ECN flag is carried in the Internet Protocol, IP, header, such as the GPRS Tunneling Protocol for User Plane GTP-U or the Control And Provisioning of Wireless Access Points, CAPWAP, packet from the transport layer to the user plane layer at eNB 20 or AP 40. ECN is an extension of the IP and Transmission Control Protocol, TCP, protocols, as described in “The Addition of Explicit Congestion Notification (ECN) to IP” [RFC 3168] and depending on its settings indicates if there is congestion in the transport network. The ECN flag normally comprises two bites and if the bits are set to 10 or 01 it indicates that there is no congestion in the transport network and if they are set to 11 it indicates that congestion is encountered in the transport network. ECN is an optional feature and is mainly useful at the user plane layer when the TCP endpoints including the UE are capable to use it. The TCP receiver of the ECN signals echoes the congestion indication to the TCP sender which should reduce its transmission rate. ECN may however also be extended to User Datagram Protocol, UDP, traffic as described in Explicit Congestion Notification (ECN) for Real Time Protocol, RTP over UDP [RFC 6679].
With help of
If the ECN-aware router does not experience or encounter congestion the ECN bits will not be changed. Furthermore, the ENC functionality will also be activated on the eNB, NB or the AP which then will read the ECN bits from the CAPWAP, S1-U and Iub packets, respectively.
In
Furthermore, the data packet also comprises an ECN flag carrying information about congestions in the transport network. Now when the data packets are arriving at for example the eNB 20 (as the network node) the eNB will first read the ECN bits. If the ECN bits are set to 10 or 01 the data packets will be forwarded regardless of their internal and/or external drop precedence value. Thus, both data packets with high respectively low drop precedence will be forwarded with the same probability. However, data packets arriving at eNB 20 and having ECN bits set to 11 will be handled re handled based on their internal and/or external drop precedence value. For example, CAPWAP, S1-U or Iub packets with low drop precedence values have a higher probability to be forwarded while CAPWAP, S1-U or Iub packets with high drop precedence values have a lower probability to be discarded or dropped. This is illustrated in
Turning back to
Turning to
Thus, it is believed that different embodiments have been described thoroughly for purpose of illustration and description. However, the foregoing description is not intended to be exhaustive or to limit example embodiments to the precise form disclosed. Thus, modifications and variations are possible in light of the above teachings or may be acquired from practice of various alternatives to the provided embodiments. The examples discussed herein were chosen and described in order to explain the principles and the nature of various example embodiments and its practical application to enable one skilled in the art to utilize the example embodiments in various manners and with various modifications as are suited to the particular use contemplated. The features of the embodiments described herein may be combined in all possible combinations of methods, apparatus, modules, systems, and computer program products. It should be appreciated that any of the example embodiments presented herein may be used in conjunction, or in any combination, with one another.
It should be noted that the word “comprising” does not necessarily exclude the presence of other elements or steps than those listed and the words “a” or “an” preceding an element do not exclude the presence of a plurality of such elements. It should further be noted that any reference signs do not limit the scope of the example embodiments, that the example embodiments may be implemented at least in part by means of both hardware and software, and that several “means”, “units” or “devices” may be represented by the same item of hardware.
The various example embodiments described herein are described in the general context of method steps or processes, which may be implemented in one aspect by a computer program product, embodied in a computer-readable medium, including computer-executable instructions, such as program code, and executed by computers in networked environments. A computer-readable medium may include removable and non-removable storage devices including, but not limited to, Read Only Memory (ROM), Random Access Memory (RAM), compact discs (CDs), digital versatile discs (DVD), etc. Generally, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps or processes.
| Number | Date | Country | Kind |
|---|---|---|---|
| 13190945.9 | Oct 2013 | EP | regional |
