Abstract:
A method is provided of transporting data packets over a telecommunications transport network. The data packets are carried by a plurality of bearers, each carrying data packets that relate to different ones of a plurality of services. In the method bandwidth profiling is applied to the data packets of each bearer, independently of the other bearers, to identify and mark the data packets of each of the bearers that are conformant with a predetermined maximum information rate for the bearer. The data packets are forwarded for transport through the transport network, wherein, if there is insufficient bandwidth available in the transport network to transport all data packets, data packets not identified by the profiling as being conformant are discarded, so as not to be transported through the transport network.

Description:
TECHNICAL FIELD 
       [0001]    The present invention relates to improvements in the handling of data communications transmitted across a transport network. 
       BACKGROUND 
       [0002]    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). A TN may be operated by a mobile network operator or by a third party transport provider. In the latter case there would be a Service Level Agreement, SLA, between the mobile and transport operators. 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. 
         [0003]    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. When a User Equipment (UE) attaches to the network a default-bearer is established (typically a best-effort service). However, if the UE invokes services having different QoS parameters then a dedicated bearer is established for each service. This is shown schematically in  FIG. 1  for an LTE network architecture and traffic flows to/from the Application/Service layer  100  of a network—for example an IP Multimedia Subsystem (IMS) network. In  FIG. 1 , there are two Unicast Evolved Packet System (EPS) bearers each carrying traffic (i.e. data packets) in both directions: up-loaded traffic sent from a User Entity (UE)  102  with a Radio Bearer to an eNodeB  104 , then with a 51 Bearer over a TN to a Serving Gateway (SGVV)  106 , and then with a S5/S8 Bearer to a PDN-GW  108 ; and downloaded traffic in the reverse direction. A similar concept would apply with UMTS network architecture, details of which can be found in “3G Evolution, HSPA and LTE for Mobile Broadband” by Erik Dahlman, Sefan Parkvall, Johan Skold and Per Beming, Academic Press, Elseveir, ISBN 9780123745385. 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. 
         [0004]      FIG. 2  illustrates schematically in more detail the TN between the eNodeB  104  and the SGW  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 arises is how to decide which non-GBR data packets should be dropped. 
         [0005]    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. 2 , the traffic flow through the TN bottleneck is handled by the application level Transmission Control Protocol (TCP), which deals with congestion by setting the packet throughput according to the available bandwidth. If packet losses start to occur, then the TCP reduces the speed at which packets are delivered to the TN, while after successful packet forwarding the speed is increased gradually. However some greater level of control can be achieved using a sophisticated QoS solution in the TN where different types of non-GBR traffic are put into different queues and a differentiation scheme, such as Weighted Fair Queuing (WFQ) applied between these queues. This provides a degree of service differentiation between different service types of non-GBR traffic at an aggregate level, but not at a per-Bearer level. 
         [0006]    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. In this solution 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, and can be used together with a Relative Bitrate (RBR) manager. However, there are architectural limitations, particularly as it requires communication between the nodes that are sharing the same TN bottleneck. 
         [0007]    Considering congestion control and resource sharing from a more general point of view, there are three approaches that might be considered, in addition to the profiling based approach proposed herein. These include window-based solutions, rate-based solutions and hierarchical scheduling solutions. Briefly these are as follows. 
         [0008]    In a window-based solution, control of resource sharing between bearers to provide a fair share for each bearer is a very difficult problem to implement. For example the LTE may use the TCP so that the bandwidth share of a Bearer is determined based on, e.g. the number of parallel TCP flows and the TCP RTT (round-trip delay time). 
         [0009]    Rate-based solutions require use of a sophisticated (i.e. complex) algorithm to provide good performance (e.g. high utilization). In addition to this they require a shaping (i.e. 
         [0010]    buffering) capability to enforce the calculated bitrate and also signaling between the bitrate enforcement point and the congestion detection point. The HSDPA flow-control described above is an example of a rate-based solution. 
         [0011]    In a Hierarchical scheduling solution, for example, a hierarchical scheduler is used in the edge node to emulate the TN bottleneck. For example, with a single TN bottleneck with 10 Mbps, then a 10 Mbps shaper is used in the edge node to avoid TN congestion. This solution supports only a single edge network and requires knowledge of the capacity of all potential TN bottleneck links and the TN topology. 
         [0012]    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. 3 . 
         [0013]    The left-hand part of  FIG. 3  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 
         [0014]    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. 3 , illustrates what occurs in an Asymmetric Digital Subscriber Line (ADSL). 
         [0015]    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. 
         [0016]    As  FIG. 3  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). 
         [0017]    The present invention has been conceived with the foregoing in mind. 
       SUMMARY 
       [0018]    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, each carrying data packets that relate to different ones of a plurality of services. In the method bandwidth profiling is applied to the data packets of each bearer, independently of the other bearers, to identify and mark the data packets of each of the bearers that are conformant with a predetermined maximum information rate for the bearer . The data packets are forwarded for transport through the transport network, wherein , if there is insufficient bandwidth available in the transport network to transport all data packets, data packets not identified by the profiling as being conformant are discarded, so as not to be transported through the transport network. 
         [0019]    According to a second aspect, there is provided a network entity of a telecommunications network that provides data packets for transport through a transport network. The data packets are carried by a plurality of bearers, the bearers each carrying data packets that relate to different ones of a plurality of services. The network entity is configured to apply bandwidth profiling to the data packets of each of the bearers, independently of the other bearers, to identify data packets that are conformant with a predetermined maximum information rate for the bearer. The network entity forwards the data packets to the transport network, including an indication in each of the data packets as to whether it is a conformant data packet or is not conformant. 
         [0020]    Embodiments overcome the aforementioned problems of bandwidth resource sharing, such as preventing an aggressive user from It is an advantage that the sharing of bandwidth between Bearers is more RAN-controlled. Also because the bandwidth profilers are implemented per-Bearer, without the need for any interaction between the different Bearer, there is flexibility as to where (i.e. in which network entity) the bandwidth profilers are implemented. 
         [0021]    Another advantage is that the operator can set the rates for the different bearers. This means that operators can prioritise certain non-GBR traffic, and downgrade other traffic as being of lower priority. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0022]      FIG. 1  is a schematic illustration showing how service differentiation is applied in existing TNs involving an LTE architecture. 
           [0023]      FIG. 2  is a schematic illustration showing more detail of the TN of  FIG. 1 . 
           [0024]      FIG. 3  is a schematic illustration comparing bandwidth sharing between bearers in a TN and an ADSL. 
           [0025]      FIG. 4  is a schematic illustration of a TN employing bandwidth profiling for each bearer. 
           [0026]      FIG. 5  shows two graphs comparing bandwidth usage over time for two bearers in a TN both with and without bandwidth profiling of each bearer. 
       
    
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
       [0027]    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, in the embodiment described below with reference to  FIG. 4 , 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. 
         [0028]    To implement the color profiling scheme described by the Metro Ethernet Forum a 
         [0029]    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 consists of a ‘bucket’ of bytes referred to as ‘tokens’. As data packets arrive, provided the number of tokens 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. 
         [0030]    Referring to  FIG. 4 , 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 . Each of the bearers has an assigned QoS Class Identifier (which will be explained in more detail below) 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. 
         [0031]    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. For LTE, coloring can be done in the S-GW or in the PDN-GW or in the site switch. Although not shown in  FIG. 4 , the site switch contains transport devices (e.g. Ethernet switch and routers belonging to the mobile operator) and connects the S-GW or PDN-GW to the TN. For HSDPA, coloring could be done in the RNC or in the GGSN, for example. 
         [0032]    Packets of each Bearer  402 ,  404  that conform with the bearer&#39;s profiler  414 ,  416  are marked as conformant packets  418  (i.e. assigned ‘green’) and packets that do not conform are marked as non-conformant packets  420  (i.e. assigned ‘yellow’). Because there are no ‘yellow’ buckets all data packets that are not colored ‘green’ by the profilers  414 ,  416  are assigned ‘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 
         [0033]    Bearer is about 7.5 Mbps. In this case, approximately ⅓ of the packets of the Bearer will be assigned to ‘yellow’. 
         [0034]    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. 
         [0035]    In the example described, a two-color (green-yellow) profiler is used for each Bearer. 
         [0036]    The bucket size and ‘green’ rate at which rate the green tokens arrive into the buckets for each of the Bearers are set by the operator. When the profiler  414 ,  416  assigns a Packet 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 
         [0037]    Differentiated Services Control Point (DSCP) field in the IP header could be used to indicate if a packet has been assigned ‘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. 
         [0038]    For example, in an LTE system such as that shown in  FIG. 4 , the per-Bearer level coloring could be done in the PDN-GW  406  (rather than in the S-GW  410  as shown). 
         [0039]    From the PDN-GW  406  the packets go to the S-GW  410  and from the S-GW  410  to the TN  412 . The TN  412  may comprise a Mobile Back-Haul (MBH—not shown) where the color information is used. If the PDN-GW  406  and the S-GW  410  are connected by an Ethernet connection, then the PDN-GW  406  can use the DEI bit of the Ethernet frame (packet) to signify the color assigned to the packet. The S-GW  410  reads out the DEI bit of incoming packets and when these packets leave the S-GW  410  towards MBH the DEI bit of the outgoing packets are set accordingly. Alternatively, if the DSCP field of the IP packet is used to signify the color assigned to the packet at the PDN-GW  406 , then the S-GW  410  reads out the value in the DSCP field and uses it to fill in the DEI bit of the outgoing Ethernet frames sent to the MBH. 
         [0040]    Although described above in relation to LTE architecture, the method can be applied equally well in a HSDPA or a common TN (common between LTE and HSDPA). It can also be applied to TNs operating with multiple RBSs (e.g. NodeBs and eNodeBs) sharing the same TN bottleneck. For this common transport there is no requirement for any direct communication between nodes. Each node may be provided with a separate ‘green’ rate table (see below) or the green rates may be harmonized across the different technologies and nodes. For example a Bearer serving a given service may always get (e.g.) a 1 Mbps ‘green’ rate independently whether it uses LTE or HSDPA. Also, in a more sophisticated embodiment, the profilers may include a ‘yellow’ bucket, with a specified ‘yellow’ rate (equivalent to the EIR described above) at which ‘yellow’ tokens arrive. In that case packets that non-conformant with both the ‘green’ and ‘yellow’ rates, are assigned red packets and will be discarded (i.e. not transported over the TN). 
         [0041]    Operators may take account of a variety of available information in order to set the ‘green’ rate (and, if used, the ‘yellow’ 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. This may be implemented by means of a table that maps the requirement of the Bearer (e.g. based on the QCI value assigned to the Bearer) into a ‘green’ rate value (as shown in  FIG. 4 ). This table may be essentially static (i.e. not frequently updated) and may also include default values (e.g. where the QCI value assigned to the bearer does not correspond to a QCI value in the table). 
         [0042]    When configuring the table, the operator may 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. These are discussed in more detail below. Note that how much detail is provided in the table—e.g. how many different QCIs are used and the ‘green’ rates assigned to them—is basically the operator&#39;s decision and may depend on various factors such as business models, knowledge about subscribers, the network, etc. 
         [0043]    1) A priori information about service and subscription. This information is used to define the Bearer category. Subscription information may be used, for example, to define a different QCI for a premium service/user than for a normal service/user. Another example might be to define different QCIs for Laptop users and Smartphone users. The subscription information might include a guaranteed throughput value, which can then be used to determine a ‘green’ rate. As long as the sum of the ‘green’ rates over a TN bottleneck is smaller than the TN bottleneck speed, this setting will guarantee the given ‘green’ rate. 
         [0044]    One or more properties of the service may also be used. For example, a different QCI may be defined for a delay sensitive service. Also, a particular QCI may be defined for a p2p service. 
         [0045]    2) A priori information about the TN. The operator may take account of capacity information. If the capacity of the bottleneck is known then this information can be used in the determination of green rates. For example, for a 10 Mbps TN the ‘green’ rate would only be up to 10 Mbps, but for a higher capacity TN higher green rates can be used. Also, if the operator knows the TN topology then this information can be taken into account. For example, when many NodeBs and eNodeBs share the TN bottleneck, then the operator can chose to apply smaller ‘green’ rates. 
         [0046]    3) A priori information about traffic. The operator may use information about the typical traffic mix, and where the fairness of the shared resource needs improvement. For example, where the operator has information that shows there to be unfair access caused by a few, more aggressive, parallel Bearers, then the ‘green’ rates can be set to restrict the rates of the aggressive bearers to improve the fairness. 
         [0047]    Also, the operator may decide to use a different table (or provide different ‘green’ rate values in the table) at different times of the day and/or week. For example different ‘green’ rates may be applied at busy periods compared with other times. 
         [0048]      FIG. 5  illustrates the results of some simulations that show the benefits of the per-Bearer profiling described above. In  FIG. 5 , the top graph illustrates the share of bandwidth in a TN between an aggressive user using 10 TCP flows, and a normal user using 1 TCP flow, and without any per-Bearer bandwidth profiling. The capacity of the TN is 10 Mbps, and as can be seen, the majority of this is taken up by the aggressive user, leaving little bandwidth available for the normal user. The lower graph in  FIG. 5  illustrates the share of bandwidth for the same two users, but where bandwidth profiling with a ‘green’ rate of 5 Mbps has been applied to both users. In this case there may be assumed to be a ‘target’ bandwidth share of 50% of the available bandwidth for each user. Although this is not quite realized, it can be seen that the bandwidth taken up by the aggressive user (below the line on the graph) and by the normal user (above the line) is a much fairer split. 
         [0049]    As  FIG. 5  shows, the application of the per-bearer bandwidth profiling results in a much fairer share of TN resources. Moreover, this bandwidth sharing between Bearers is under the control of the RAN. The concept is, by its nature, also applicable to a common RAN scenario, in addition to the LTE or HSDPA scenarios described. The bandwidth profilers can be implemented per-Bearer without any interaction between different Bearers or the profilers, and therefore it is flexible where (i.e. in which node) the bandwidth profilers are placed. 
         [0050]    A major advantage is the ability that the operator has in setting the ‘green’ rates for the different bearers. This means that operators can prioritise certain non-GBR traffic, and downgrade other traffic as being of lower priority. 
         [0051]    An additional advantage is the possibility to provide bandwidth guarantees to certain users where special conditions arise. Also, if for some reason a mis-configuration of the profilers arises, the system can be configured to revert to current methods of resource sharing (e.g. relying on the TCP).