Abstract:
A method is presented of transporting data packets over a telecommunications transport network. The data packets are carried by a plurality of bearers. For each of the bearers, independently of the other bearers, bandwidth profiling is applied to the data packets of the bearer to designate as ‘green’ data packets that are conformant with a predetermined maximum Information Rate for the bearer. One or more data packets is buffered for up to a predetermined maximum ‘green’ buffer time, during which if transporting the data packet would not cause the maximum information rate of the bearer to be exceeded, the data packet is designated as a ‘green’ data packet. The data packets are forwarded for transporting over the transport network. If there is insufficient bandwidth available in the transport network to transport all data packets, data packets that are not designated as ‘green’ data packets are discarded, so as not to be transported through the transport network.

Description:
TECHNICAL FIELD 
     The present invention relates to improvements in the handling of data communications transmitted across a transport network. 
     BACKGROUND 
     A transport network (TN) is used to carry data signals between a Radio Base Station (RBS), such as a NodeB or an eNodeB in 3G Long-Term Evolution (LTE) networks, and a Serving gateway (S-GVV) or Packet Data Network gateway (PDN-GW). With the rapid growth of digital data telecommunications following the introduction of 3G and 4G technology, TNs may frequently act as bottlenecks in the overall data transport process. Thus, various systems and methods have been proposed for improving or prioritising the way that data packets are transported by the bearers. 
     Service differentiation in the Radio Access Network (RAN) is one supplementary means for more efficiently handling high volumes of traffic. As a simple example, using service differentiation a higher bandwidth share can be provided for a premium service, and in this way the overall system performance can be improved. As another example, a heavy service such as p2p traffic, can be down-prioritized. Implementing such service differentiation methods requires integration into the Quality of Service (QoS) concept of LTE and Universal Mobile Telecommunications System (UMTS) technology. Details of the QoS concept for LTE can be found in the 3 rd  Generation Project Partnership (3GPP) Technical Specification TS 23.410. The main idea of this concept is that services with different requirements use different bearers. 
     Service differentiation can be applied for both guaranteed bit-rate (GBR) and non-GBR traffic. The present disclosure is concerned only with non-GBR traffic. 
       FIG. 1  illustrates schematically a TN between an eNodeB  104  and a S-GW  106  for the LTE example. This shows non-GBR data packets  120 , that include packets  120   a  of a first bearer that relate to a first service provided by a first server  110 , and packets  120   b  of a second bearer that relate to a second service provided by a second server  112 . These data packets  120  are destined for user equipment such as UE  102  at the other side of the TN, where the arriving data packets are handled by a scheduler  114  and eNodeB  104 . In addition to the non-GBR data packets, the TN also handles synchronization data and voice or other GBR traffic, as shown, and which has a strict priority above non-GBR traffic but which is not a concern of the present disclosure. The bandwidth available for sending the non-GBR traffic is shared between the bearers, but when there is congestion so that there is insufficient bandwidth for the TN to handle all the non-GBR traffic, then some data packets have to be dropped (shown as RED dropped packets in the Figure). The problem that is addressed below concerns a mechanism for deciding which non-GBR data packets should be dropped. 
     The bandwidth share of a Bearer cannot be controlled by the RAN, and so instead the sharing of bandwidth between the Bearers is currently mainly determined by the application level protocols, the service used and the user behaviour. In the current LTE solution for non-GBR traffic, as shown in  FIG. 1 , the traffic flow through the TN bottleneck is handled by the application level Transmission Control Protocol (TCP). For the High-Speed Downlink Packet Access (HSDPA) protocol there are two approaches to handling TN congestion. One is a rate-based solution where service differentiation can be applied. The problem with this solution is that it is not compatible with TCP congestion control. Therefore separate queues need to be implemented in the TN for HSDPA and LTE traffic. The other approach is an Active Queue Management (AQM) based congestion control (ABCC) for HSDPA as described in which the application level TCP is notified about TN congestion and can then be used to resolve the TN congestion. This solution has the advantage in that it is essentially compatible with LTE. However, there are architectural limitations, particularly as it requires communication between the nodes that are sharing the same TN bottleneck. 
     Currently there is no common solution that provides efficient Bearer level service differentiation. The existing approaches all suffer from limitations as described above. Even if equal sharing between bearers, rather than service differentiation, was desired some mechanism would be needed to avoid very unfair situations arising. This unfairness is illustrated below. Currently, in a RAN TN-limited case, where resource sharing between users (bearers) is based on a per-TCP flow (as currently applied in LTE) very unfair bandwidth sharing between users can result. This unfairness can be demonstrated with reference to the illustration of  FIG. 2 . 
     The left-hand part of  FIG. 2  illustrates how bandwidth is shared between two bearers in a RAN TN. One bearer is handling the traffic of a single aggressive user with several (in this example 4) parallel TCP flows, while another bearer is handling the traffic of a normal user with a single TCP flow. In this case, the aggressive user effectively throttles the TN by taking up the majority of the available bandwidth. In this Radio limited case a Uu scheduler guarantees the required fairness among bearers as each user is essentially assigned the proper bandwidth, meaning that the aggressive user&#39;s access rate is effectively limited. Just for comparison, the right-hand part of  FIG. 2 , illustrates what occurs in an Asymmetric Digital Subscriber Line (ADSL). 
     Note that for the case of internet access, with a large user aggregation the capacity of the aggregation is much greater than the peak rate of a user, and so this does not present a serious problem because many aggressive users would be needed. However, this situation may change with increasing access rates, giving rise to similar unfairness problems. 
     As  FIG. 2  shows, without a service differentiation method the bandwidth share depends on the nature of the services being used (e.g. typically a p2p service uses many parallel TCP flows), which is in direct contrast to what the operator wants (i.e. to provide premium services with a higher bandwidth share than low priority services). 
     The present invention has been conceived with the foregoing in mind. 
     SUMMARY 
     According to a first aspect, there is provided a method of transporting data packets over a telecommunications transport network. The data packets are carried by a plurality of bearers. For each of the bearers, independently of the other bearers, bandwidth profiling is applied to the data packets of the bearer to designate as ‘green’ data packets that are conformant with a predetermined maximum Information Rate for the bearer. One or more data packets is buffered for up to a predetermined maximum ‘green’ buffer time, during which if transporting the data packet would not cause the maximum information rate of the bearer to be exceeded, the data packet is designated as a ‘green’ data packet. The data packets are forwarded for transporting over the transport network. If there is insufficient bandwidth available in the transport network to transport all data packets, data packets that are not designated as ‘green’ data packets are discarded, so as not to be transported through the transport network. 
     According to a second aspect there is provided a telecommunications network entity configured to receive data packets of a plurality of bearers prior to forwarding the data packets for transport over a transport network, TN. The network entity comprises a bandwidth profiler configured to apply bandwidth profiling to the data packets of a bearer independently of the other bearers, and to designate as ‘green’ data packets that are conformant with a predetermined maximum Information Rate of the bearer. The bandwidth profiler further comprises a buffer for buffering one or more data packets for up to a predetermined maximum ‘green’ buffer time. The profiler is configured to designate a data packet in the buffer as a ‘green’ data packet if transporting the data packet would not cause the maximum information rate of the bearer to be exceeded. 
     It is an advantage that, by employing ‘color’ profiling to teach bearer and including per-bearer buffering to the profiling, a more deterministic and accurate sharing of resources is achieved. Also, shorter TN buffering is needed. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a schematic illustration showing how service differentiation is applied in existing TNs involving an LTE architecture. 
         FIG. 2  is a schematic illustration comparing bandwidth sharing between bearers in a TN and in an ADSL. 
         FIG. 3  is a schematic illustration of a TN employing bandwidth profiling for each bearer. 
         FIG. 4  is a schematic illustration of a TN employing bandwidth profiling and buffering for each bearer. 
         FIG. 5  is a flow diagram illustrating the process steps according to one embodiment. 
         FIG. 6  shows two graphs comparing bandwidth resource sharing over time for six bearers in a TN, both with and without bandwidth profiling of each bearer. 
     
    
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
     The embodiments described herein apply per-Bearer bandwidth profiling to control resource sharing among Bearers carrying different services. The embodiments employ a ‘color’ profiling scheme of the type described by The Metro Ethernet Forum in http://metroethernetforum.org/PDF_Documents/Bandwidth-Profiles-for-Ethernet-Services.pdf. In this scheme, packets, or frames, are assigned a color (green, yellow, or red) according to whether they are conformant with the bandwidths as specified in a Service Level Agreement (SLA). Essentially: packets assigned ‘green’ are conformant and are delivered in accordance with the SLA specification; packets assigned ‘yellow’ are out-of profile, but may be delivered if there is bandwidth available, for example because they are conformant with some specified excess bandwidth requirements; and packets assigned red are out-of profile and immediately discarded. Thus, for the present purposes, as shown in  FIG. 3 , the color assigned by the profiler is propagated to the TN bottleneck and it is used to determine which packets (i.e. ‘yellow’ packets) may be dropped at the TN bottleneck if there is insufficient bandwidth. It will be appreciated that the ‘colors’ are simply a convenient label that is applied to differentiate the packets in the profiler. 
     To implement the color profiling scheme described by the Metro Ethernet Forum a Committed Information Rate (CIR) is specified, and additionally an Excess Information Rate (EIR) may be specified. These profile rates are enforced through an algorithm referred to as a ‘token bucket’, which reservoir referred to as a ‘bucket’ of bytes referred to as ‘tokens’. As data packets arrive, provided the number of tokens (bytes) in the ‘green’ bucket exceeds the byte size of the packet, it is colored ‘green’. The number of ‘green’ tokens in the bucket is decremented by an amount that corresponds to the ‘green’ packet size. ‘Green’ tokens are replenished in the ‘green’ bucket at a rate determined by the specified CIR, and hereafter referred to as the ‘green’ rate. If there are insufficient tokens in the ‘green’ bucket, the packet is either colored ‘yellow’, or if an EIR has been specified, it is passed to a ‘yellow’ bucket where in the same way the packet is either colored ‘yellow’ if there are sufficient ‘yellow’ tokens in the bucket, or is otherwise colored red and discarded. The number of ‘yellow’ tokens is decremented in the same way, and the ‘yellow’ tokens in the ‘yellow’ bucket are replenished at a rate determined by the specified EIR. 
     Referring to  FIG. 3 , where the example is shown of an LTE system with two bearers  402 ,  404  each carrying data packets between a PDN-GW  406  and an eNodeB  408  via a S-GW  410  and through a TN  412 . The Bearers  402 ,  404  are designated S5/S8 bearers  402   a ,  404   a  between the PDN-GW  406  and the S-GW  410 , S1 bearers  402   b ,  404   b  from the S-GW  410  over the TN  412 , and radio bearers  402   c ,  404   c  beyond the eNodeB  408 . Each Bearer is assigned a bandwidth profiler—profiler  414  for bearer  402  and profiler  416  for bearer  404 . In this example, the profilers  414 ,  416  are located in the S-GW  410 , but this is not a requirement. The profiling can be implemented in any node where per-Bearer handling and coloring is possible. 
     Each of the bearers has an assigned QoS Class Identifier (QCI) and an associated predefined ‘green’ rate (CIR) and bucket size. In this example there is no EIR specified, and so there is no ‘yellow’ rate or ‘yellow’ bucket—i.e. a two-color (green-yellow) profiler is used for each Bearer. However, it would be perfectly possible for the profilers  414 ,  416  to be 3-colour profiler, in which case each profiler would include an additional ‘yellow’ bucket, and a ‘yellow’ rate (EIR) at which ‘yellow’ tokens arrive would be specified. Packets that were not colored ‘green’ would be passed to the ‘yellow’ bucket, and then any packets that did not conform with the specified EIR would be colored ‘red’ and discarded. 
     The bucket size and ‘green’ rate at which rate the green tokens arrive into the buckets for each of the Bearers (and, if used the ‘yellow’ rates) are set by the operator. Operators may take account of a variety of available information in order to set the ‘green’ rate for a particular bearer. This may be based, at least in part, on the available service information of the Bearer (roughly speaking the QoS requirement of the Bearer, which in the case of LTE is coded in the QCI value). Thus, a predefined green rate may be assigned for a given QCI value. When setting the ‘green’ rates, the operator may also take into account of various information, for example: (i) information about the service(s) and subscriptions; (ii) information about the TN; and (iii) information about traffic. 
     Packets of each Bearer  402 ,  404  that conform with the bearer&#39;s profiler  414 ,  416  are marked as conformant packets  418  (i.e. designated ‘green’) and packets that do not conform are marked as non-conformant packets  420  (i.e. designated ‘yellow’). Because, in this example, there are no ‘yellow’ buckets all data packets that are not colored ‘green’ by the profilers  414 ,  416  are designated ‘yellow’ (and thus there are no ‘red’ packets). For example, assume that the ‘green rate’ is 5 Mbps for a Bearer and the bitrate of this Bearer is about 7.5 Mbps. In this case, approximately ⅓ of the packets of the Bearer will be assigned to ‘yellow’. 
     The TN  412  bottleneck active queue management can then use the color information marked in the data packets when choosing which packets to drop when there is insufficient bandwidth (congestion). The first packets to be dropped will be the ‘yellow’ packets  420 . In other words a ‘color aware’ dropping of data packets is used in TN bottleneck queue. 
     When the profiler  414 ,  416  designates a Packet as either ‘green’ or ‘yellow’, this means that the packet is marked with the conformance information in such a way it can be used at the TN bottleneck buffer(s). For example the Drop Eligibility (DEI) bit of the packet&#39;s Ethernet frame, or the Differentiated Services Control Point (DSCP) field in the IP header could be used to indicate if a packet has been designated as ‘green’ or ‘yellow’. Other mechanisms might also be used. In some cases additional mapping might be needed, for example to fill in the DEI bit based on the DSCP value. The only requirement is that the color information that is assigned to the packets of a Bearer by the profiler must be kept by the packets up until the TN bottleneck so as to be available for the color aware dropping of packets. 
     The color profiling based Traffic Management (TM) described above serves to improve the sharing of resources in the TN. Profiling is used to improve the fairness of resource sharing between services, by controlling which packets are dropped before the TN. Thus the bitrate of each radio bearer (RB) is controlled by the dropping of ‘yellow’ packets. However, this approach is only effective, in terms of the fairness of the resource sharing, if the TN bottleneck is large enough. Therefore, to enhance the effectiveness of the profiling, when there are insufficient ‘green’ tokens for an incoming packet the packet is held in a buffer until sufficient additional ‘green’ tokens arrive. To control the buffering delay a limit (maximum waiting time) is placed on how long the packet is allowed to be held in the buffer, and also a limit (maximum queue length) is placed on the total size, or number of packets in the buffer. 
     In the simplest embodiment, the EIR is infinity, i.e. there is no ‘yellow’ bucket and so all packets are either coloured ‘green’ or ‘yellow’. If the maximum waiting time of the first packet placed in the buffer has elapsed before sufficient ‘green’ tokens arrive in the bucket, then the first packet is colored ‘yellow’ and passed to the TN entry point, where it will either be allowed over the TN or dropped (depending on the bandwidth available in the TN). Similarly, when an incoming packet arrives, if the maximum queue length is exceeded then the first (i.e. oldest) packet is designated as a ‘yellow’ packet and passed to the TN entry point, where it will either be allowed over the TN or dropped. If the maximum queue length is specified in terms of a number of packets, then the incoming packet is simply placed in the buffer queue. If the maximum queue length is specified as a maximum total size of packets (in bytes), then, provided the departure of the oldest packet from the buffer queue has released enough space for it, the incoming packet is stored in the queue; otherwise the next oldest packet in the queue is designated as ‘yellow’ and passed to the TN entry point. 
     An example of the above method is shown and described here with reference to  FIG. 4 . This depicts the same color profiling arrangement for a TN  412  as shown in  FIG. 3 , and equivalent features have the same reference numerals. However, in this instance, for each of the profilers  414 ,  416  of the respective bearers  402 ,  404  there is a buffer  422 ,  444  through which the incoming data packets pass. For each bearer buffering is used, as described above, to wait for green tokens to arrive before colouring to yellow for up to a maximum waiting time (e.g. 200 ms) and for up to a maximum number of packets (e.g. 20) or a maximum size of the packets in the buffer queue (e.g. data packets that can be carried by an Ethernet frame are typically between 570 and 1500 bytes, which could be used to set a maximum total size based on a projected average number of packets in the queue). The buffers  422 ,  424  need to be implemented wherever (i.e. in whichever node) that the profilers  414 ,  416  are implemented. As shown in  FIG. 4  the buffers  422 ,  424  are implemented in the S-GW, or site switch  410 . However, this could also be done in the PDN-GW in the case of an LTE architecture, or, in the case of HSDPA, in the RNC or GGSN. 
     Note that the additional per-Bearer buffering is used in addition to the TN buffering (where a common buffer is used for buffering all the data packets of all of the Bearers prior to sending them across the TN). A number of factors may be considered when setting the per-Bearer buffer size, for example: the TN buffer length, RTT, delay requirement of the Bearer, and bucket size for coloring. For example, a larger buffer might be used for a download-oriented bearer and a very short buffer (or no buffering at all) for delay-sensitive bearers. 
       FIG. 5  is a flow diagram illustrating the procedure that is followed in a profiler of a bearer, in an embodiment that has both ‘green’ and ‘yellow’ buckets. Three parameters are specified, namely:
         Queue size, specified either in bytes, or as a maximum number of packets—this sets a maximum limit for the queue of packets that are buffered waiting for green or yellow tokens;   max_waiting_time_for_green_token—this is the maximum waiting time for ‘green’ tokens in the ‘green’ buffer;   max_waiting_time_for_yellow_token—this is the maximum waiting time for yellow tokens, and in this example it includes the waiting time for green tokens as well (i.e. it is the aggregated waiting time). For example assume that the maximum waiting time for green tokens is 50 ms and for yellow tokens is 100 ms, then when a packet arrives it waits maximum 50 ms for green tokens but if during the 50 ms not enough green tokens arrive then it can wait a further 50 ms in the ‘yellow’ buffer for ‘yellow’ tokens.       

     In the method there are three events where an action is taken:
         at packet arrivals;   at arrival of new tokens in the bucket—the number of available tokens can be updated periodically, e.g. every 10 ms, or can be updated when a certain size of the tokens is reached e.g. 1.5 Kbyte (equivalent to 10 ms for a CIR of 1.2 Mbps); and   at buffer queue update (dropping of old packets).       

     Referring to  FIG. 5 , at step  501  a new packet arrives at the bearer profiler. At step  502  a determination is made as to whether there are enough ‘green’ tokens in the bucket for the incoming packet, and whether the ‘green’ buffer queue is empty. If the answer is yes, then the procedure continues directly to step  520 , where the packet is designated as ‘green’ and passed immediately to the TN. If not, then at step  503  the packet is passed to the buffer queue. 
     At step  504  a determination is made as to whether there is enough space in the buffer queue for the incoming packet (i.e. would adding the packet to the queue exceed the maximum queue size?). If the answer is ‘yes’ then the oldest packet (or if necessary the oldest two or more packets) are discarded (dropped from the buffer queue) at step  505 , so that the incoming packet can be fitted into the queue without exceeding the predefined maximum queue size. For example if the maximum queue size is 100 Kbytes and there are already 99 Kbytes of packets in the queue when a new 1.5 Kbyte packet arrives, then one or more packets must be dropped (from the front of the queue, i.e. oldest packets) until there is space for this 1.5 Kbyte packet. Note that this is a ‘first-in-first-out’ (FIFO) scheme, but other queuing schemes are also possible as an option, e.g. Random Early Discard or Tail Dropping). Once there is space for the incoming packet then the packet is put into the buffer queue and a time stamp is added for the packet (step  506 ). 
     At step  507  the number of ‘green’ tokens in the ‘green’ bucket is updated. This may be triggered by the arrival of a new ‘green’ token, or may be a periodic update of the tokens in the bucket. If at this stage the buffer queue had been empty, then the newly arrived tokens would simply be placed into the bucket. However, in the procedure illustrated in  FIG. 5  the queue is not empty and so, at step  508  a check is made as to whether there are enough ‘green’ tokens in the bucket to enable delivery of one or more packets from the queue. In that case, starting with the oldest packets, as many packets as possible are colored ‘green’ and delivered from the queue by proceeding to step  520 . At the same time the number of ‘green’ tokens in the bucket is decremented by the amount corresponding to the size of the delivered packets. 
     If, at step  508 , there are not enough ‘green’ tokens to deliver any packets from the buffer queue, then at step  509  a check is made of the time stamps of packets in the ‘buffer queue, and when a packet is not older than the “max_waiting_time_for_green_token” the procedure loops back to step  507 . As shown in  FIG. 5 , this is a ‘running’ check performed every time the process reaches this point. However, this could alternatively be implemented as a periodical check, in which case step  509  would only be implemented periodically, and would otherwise be skipped with the procedure looping back to step  507 . 
     At step  509 , if a packet in the queue is older than the “max_waiting_time_for_green_token” then the procedure continues to step  511 , to determine if the packet might be colored ‘yellow’. 
     At step  510  the number of ‘yellow’ tokens in the ‘yellow’ bucket is updated. This may be triggered by the arrival of a new ‘yellow’ token, or may be a periodic update of the tokens in the bucket. Then, at step  511  a check is made as to whether there are enough ‘yellow’ tokens in the bucket to enable delivery of one or more packets from the queue. In that case, starting with the oldest packets in the queue, as many packets as possible are colored ‘yellow’ and delivered from the queue by proceeding to step  521 . At the same time the number of ‘yellow’ tokens in the bucket is decremented by the amount corresponding to the size of the delivered packets. 
     If, at step  511 , there are not enough yellow tokens, then at step  512  the question is asked as to whether there are now green tokens in the bucket, but no packets waiting in the buffer that are younger than the “max_waiting_time_for_green_token”. If there are, then the first packet in the queue can be re-colored to ‘green’ by passing to step  520 , even though the packet has been waiting in the buffer queue for longer than would normally be permitted for a ‘green’ packet. 
     If, at step  511 , there are not enough ‘yellow’ tokens to deliver any packets from the buffer queue, and at step  512  no packets were re-colored to ‘green’, then at step  513  a check is made of the time stamps of packets in the buffer queue, and when a packet is not older than the “max_waiting_time_for_yellow_token” the procedure loops back to step  510 . 
     If at step  513  a packet is found to be older than the “max_waiting_time_for_yellow_token” then at step  514  the packet is dropped, which in this case means it is discarded (colored red). Note that the discarding of the packet occurs because during the maximum waiting time for ‘yellow’ tokens (which includes the maximum waiting time for ‘green tokens’) neither enough green nor enough yellow tokens arrived for the packet to be delivered to the TN. 
       FIG. 6  shows two graphs from simulations that illustrate the potential gain that can be realized with the per-bearer buffering as described above. In the upper graph profiling is used without buffering (as shown and described above in  FIG. 3 ), whereas in the lower graph profiling is used with per-bearer buffering method (maximum waiting time 200 ms, maximum queue size 20 IP packets). The results relate to a 10 Mbps TN bottleneck and 3 bearers with 2.6 Mbps green rate (Gold users) and 3 bearers with 0.6 Mbps green rate (Bronze users). A very large yellow rate is applied for all bearers. The TN bottleneck uses color aware dropping of packets as described. The graphs show that including per-bearer buffering to the profiling results in more deterministic and accurate resource sharing. 
     Further advantages of the method described above are that shorter TN buffering is needed. Also, the advanced profiling and buffering result in higher TN utilization. As  FIG. 6  shows, with buffering there is more stable resource sharing. Also, buffering can result in a better balance between TN utilization and queuing delay.