WO2013174422A1

WO2013174422A1 - Methods, computer program products and apparatuses enabling symmetric bearer enforcement

Info

Publication number: WO2013174422A1
Application number: PCT/EP2012/059531
Authority: WO
Inventors: Thomas Theimer; Jari Olavi LEHTONEN; Christian Ruppelt
Original assignee: Nokia Siemens Networks Oy
Priority date: 2012-05-23
Filing date: 2012-05-23
Publication date: 2013-11-28

Abstract

The present invention proposes, with regard to a downlink reception, an apparatus, comprising a control unit configured to receive at least one downlink packet data flow on a respective bearer, detect the bearer on which the downlink packet data flow is received, maintain a traffic flow table for the plurality of packet data flows, which includes at least an identification of each flow and an identification of a bearer mapped to each flow, and control transmission of corresponding uplink packet data flows, wherein a corresponding uplink data flow is assigned to the same bearer as the respective downlink packet flow, based on the mapping maintained in the traffic flow table. Also, a corresponding apparatus for uplink transmission is proposed as well as respective corresponding methods and computer program products.

Description

DESCRIPTION

Title

Methods, computer program products and apparatuses enabling symmetric bearer enforcement

Field of the invention

The present invention relates to methods, computer program products and apparatuses enabling symmetric bearer enforcement.

Background

Mobile data transmission and data services are constantly making progress. With the increasing penetration of such services, mobile network operators need effective tools and solutions to monetize mobile broadband services. One of these tools is QoS (QoS = Quality of Service) differentiation, through which the mobile operator has the possibility to create service packages that offer differentiated performance to subscribers and/or applications executed by/for the subscribers, taking effect in particular when the network is congested. QoS is thus particularly related to (cell) load management and application aware traffic management within (e.g. cellular) communication networks.

3GPP/3GPP2 (3GPP = 3^rd Generation Partnership Project) standards have defined extensive QoS capabilities that rely on network-initiated dedicated bearers (or secondary PDP contexts) (PDP = Packet Data Protocol) with specific QoS characteristics. Traffic that needs to be prioritized must be mapped to a dedicated bearer with suitable QoS characteristics, both in downlink (DL) and in uplink (UL) direction. In the existing architecture, this is accomplished by assigning TFT filter templates (TFT = Traffic Flow Templates) containing one or several packet filters (multi-field classifiers). These must specify IP addresses (IP = Internet Protocol) and port numbers of packet flows to be mapped into a bearer. Existing traffic flow mapping into bearers is e.g. described in document 3GPP TS23.401 , with reference to e.g. Figure 4.7.2.2-1 . TFTs can be assigned during bearer creation, and can also be modified during the lifetime of a bearer. For dynamic application detection and differentiation, it is clear that TFTs will need to be modified dynamically to reflect the application being used at the moment.

The basic QoS concepts are the same in 3G/HSPA (HSPA = High Speed Packet Access), LTE™ (LTE = Long Term Evolution) and 3GPP2 network architectures. Therefore, this invention applies to all bearer-based mobile network generations as well as those providing for support for secondary PDP contexts, which is improving in 3G terminals and networks as well. 3GPP has designed the QoS architecture for specific use cases such as voice and multimedia calls, where dedicated bearers reflect media flows of relatively long duration (at least some 10s of seconds in average). Many Internet-based applications have similar characteristics and session duration, for example video streaming using progressive download, where a video is represented by a large file that is progressively downloaded by the client. In order to prioritize the video packet flow, a bearer modification needs to be signaled by the PDN gateway (PDN = Packet Data Network) in order to update the TFT in uplink direction. An example scenario for such Bearer modification procedure without bearer QoS update is shown e.g. in document 3GPP TS23.401 , with reference to e.g. its Figure 5.4.3-1 .

Some Internet applications, however, exhibit a very dynamic flow-level behavior, such that they open a large number of packet flows to different destinations in a short time interval. An important example application is regular web browsing, where a web page has many embedded objects coming from a variety of sources (web servers, advertisement servers, CDNs (CDN = Content Delivery Network), partners, etc). Configuring dynamic TFT modifications through the signaling procedure described above is not a practical option here, because the signaling overhead is very large and many of the objects are quite small (just a few packets). As disclosed in TS23.401 , with reference to e.g. its Figure 5.4.3-1 , several network elements are involved in order to modify an LTE™ bearer, which also means that some latency is involved until a transaction propagates from PDN gateway towards a terminal such as a UE (UE = user equipment) and back. In many cases, the packet flow may already be terminated by the time the signaling procedure has been completed.

As an example, consider the home page of a newspaper, e.g. at www.newspaper.com. Such a page has a lot of embedded pictures and e.g. Java™ scripts. A normal client terminal such as a personal computer (PC) needs a total of 49 TCP (TCP = Transmission Control Protocol) connections to load all content from e.g. 25 different servers. This is quite a typical example for a multi-media web page with rich embedded content. Most of the objects are actually less than 5 kB (kilo Bytes) in size, so they would need a maximum of 4 packets to be sent.

An alternative approach would be to configure a filter that triggers on http port 80 (HTTP = HyperText Transfer Protocol), ignoring the locally assigned ports and individual TCP connections. Unfortunately, this option does not work, because nowadays too many applications are based on http: e.g. video streaming, file down-loads, sometimes even peer-to-peer implementations all use http port 80. Therefore, this simple approach does not offer sufficient accuracy.

Hence, a new concept is required to enable a flexible application flow mapping to bearers.

A readily available solution to avoid too frequent bearer modifications and TFT filter updates is so-called packet tagging, e.g. using the DSCP field (DSCP = Differentiated Service Code Point) in the IP header (or the flow label in case of IPv6) (IPv6 = Internet Protocol version 6). In such scenario, a traffic detection function performs dynamic application detection and/or classification (e.g. using deep packet inspection, DPI, techniques) and then use the DSCP to indicate to the PDN gateway in/on which bearer the packet should be carried (Figure 1 ). Only a small set of DSCPs are needed, one for each dedicated bearer type that is available per UE. Fig. 1 shows that a client 1 offers an application via a packet core network 2 and a network transceiver device, such as an evolved NodeB, eNB denoted by 3, of an access network, towards a terminal such as a UE denoted by 4. The core network, i.e. a functionality located at the core network 2, classifies the application data packets and the respective packet flows and performs packet marking/tagging. A static filter (functionality) at the core network side 2 maps the respective tagged/marked packet flows to a plurality of bearers for delivery via the access network (represented by the eNB 3) to the terminal UE 4. The plurality of bearers comprises a default bearer and one or more dedicated bearers which are dedicated for a respective application and/or service type (QoS) required by the application(s) and the associated packet data flows. Figure 1 shows, as an example, two dedicated bearers of quality of service class identifiers (QCI = QoS Class Identifier) QCI7 and QCI9, while the default bearer is assigned QCI8.

Though such solution may work well for downstream traffic, the problem is that it does not work for uplink traffic, because uplink traffic flows rely on a per-flow filter that must be signaled and updated frequently.

Assuming that network congestion would only affect downstream traffic, it may be acceptable to ignore uplink traffic mapping, i.e. not send any dynamic filter modifications. As a consequence, uplink traffic would remain inside the (uplink) default bearer, and there would be unidirectional use of dedicated bearers for downstream traffic only. This could be an intermediate solution, though not an optimum solution. However, such solution does not prioritize upstream traffic, and therefore it will not address those use cases that rely on uplink performance.

Namely, even if many use cases generate mostly downstream traffic (such as web browsing), uplink performance is still an important factor because congestion can lead to starvation of TCP acknowledgements, and this will also affect downlink TCP performance (see RFC 3449) (RFC = Request for Comments of the Internet Engineering Taskforce, IETF). Hence, there is still a need to find a solution that will prioritize downstream and upstream packet flows in a consistent way.

Thus, there is still a need to further improve such systems.

Summary

Various aspects of examples of the invention are set out in the claims. According to a first aspect of the present invention, there is provided an apparatus as defined in claim 1 and a method as defined in claim 21.

Further refinements thereof are as set out in the respective dependent claims.

According to a second aspect of the present invention, there is provided an apparatus as defined in claim 1 1 and a method as defined in claim 31 .

Further refinements thereof are as set out in the respective dependent claims.

According to a third aspect of the present invention, there is provided a computer program product comprising computer-executable components which, when the program is run on a computer, are configured to implement and/or carry out the above method aspect(s).

The above computer program product/products may be embodied as a computer-readable storage medium.

Thus, performance improvement is based on methods, devices and computer program products enabling, according to at least one or more embodiments: - a flexible application flow mapping to bearers without creating any signaling overhead for bearer modifications, and thus keeping the signaling load on a low level,

- a solution for uplink and downlink such that each dedicated bearer will only need a simple filter rule that matches one or several DSCPs;

- that there is no need for any dynamic filter updates (neither uplink nor downlink) as new applications are detected,

- that the classification is attached to the packet, and therefore provides an inband signaling mechanism to enable flexible application mappings without any signaling overhead,

- a UE feature potentially to be standardized which enables better QoS support, - the feature to be implemented can be controlled (i.e. enabled or disabled) on a bearer signaling procedure level,

- improved capability for application-based traffic differentiation;

- to limit the amount of changes to the network (e.g. mobile gateway and/or a mobility management entity, MME), as the majority of the functionality is located and implemented (decentralized) within the terminals, and

- that amendments to the operating system are not necessary according to at least exemplary embodiments,

- any transport protocol can be supported, i.e. TCP, UDP, SCTP, etc..

Brief description of drawings

For a more complete understanding of example embodiments of the present invention, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:

FIGURE 1 illustrates dynamic packet tagging and downlink traffic flow mapping as a starting scenario;

FIGURE 2 illustrates a signaling diagram according to an exemplary basic embodiment of the present invention;

Figure 3 illustrates an example of a traffic flow table maintained at least at a terminal UE;

Figure 4 illustrates an example of a flowchart from a terminal's perspective when receiving, in DL, packet data flows from a network side;

Figure 5 illustrates an example of a flowchart from a terminal's perspective when transmitting, in UL, packet data flows to a network side; and Fig. 6 illustrates a basic block circuit diagram of a terminal UE in which embodiments of the present invention are implemented.

Description of exemplary embodiments

Example aspects of the invention will be described herein below.

Generally, the invention is implemented in a communication network in which data are transmitted in units of packets within packet flows using bearers, and where a respective bearer (of the access network, i.e. radio or other wireless access network) fulfils a certain QoS requirement. The present invention is neither limited to specific communication networks, nor to specific types of packet flows within such networks. That is, the packet flows can be based on the TCP protocol or alternatively also on the UDP protocol (UDP = User Datagram Protocol) or SCTP (Stream Control Transmission Protocol).

Note that for the purpose of the present description, a flow is constituted by e.g. a transmission of packets between two endpoints using the same set of source/destination ports.

Also, the method, devices and computer program products presented herein are generally applicable to any applications, the application data of which are carried in packet flows, such as multimedia applications, video or voice applications, data downloading or streaming, web page access, or others, or a combination thereof, or the like. Other systems can benefit also from the principles presented herein as long as they have identical or similar properties in terms of the packet data flows and/or bearers used for carrying those flows.

Note that embodiments of the present invention may be implemented in software, hardware, application logic or a combination of software, hardware and application logic. The software, application logic and/or hardware generally resides on a module or unit, or chipset or apparatus associated to a device, i.e. mounted/inserted or mountable/insertable to or configured as a part of such a device.

In an example embodiment, the application logic, software or an instruction set is maintained on any one of various conventional computer-readable media. In the context of this document, a "computer-readable medium" may be any media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer or smart phone, or user equipment.

The present invention relates in particular but without limitation to mobile communications, for example to environments under WCDMA, LTE™, UMTS (universal mobile telecommunication system), or any other bearer based communication scenario, and can advantageously be implemented in user equipments or smart phones, or personal computers connectable to such networks. That is, it can be implemented as/in chipsets/modules/units/apparatuses to connected devices, and/or modems thereof.

If desired, the different functions discussed herein may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the above- described functions may be optional or may be combined.

In particular, it is noted that device (e.g. terminal) related aspects are described on one hand in relation to receiving of data and on the other hand in relation to transmitting of data. This is done in order to keep the explanation simple and understandable. Though, it is of course to be understood that a corresponding device (e.g. terminal or network device) has a receiving and sending capability. Hence, both such aspects, although described herein distinctly, are of course simultaneously present in a single device.

According to at least an exemple embodiment of the invention, consistent usage of dedicated bearers in both directions of a packet flow, i.e. UL and DL is enforced. To this end, the packet core network (entity) is configured /arranged to detect applications and to map packets correctly into dedicated bearers for downstream transmission, as it was described above with reference to Figure 1 . According to an option, the packet core network entity may limit flow-based bearer mapping to specific bearers only. A conceptual implementation of an exemple embodiment is as described herein below with reference to Fig. 2.

As shown in Figure 2, a client 1 in step/stage S20 sends application data flows (based on TCP or UDP or the like) to a packet core network (entity) 2. In a step/stage S21 , that entity/functionality detects the application type(s) of the data flows and the required QoS for the flow(s). In step/stage S22, the entity/functionality maps packet data flow(s) to corresponding dedicated bearers and/or a default bearer. In a step/stage S23, the mapped packet data flows are then forwarded on the assigned bearers (e.g. dedicated bearers #a and #b, default bearer #c) to a destination such as a terminal or user equipment UE 4.

Also, the client 1 or core network 2 signals (not shown) to the UE that dynamic flow monitoring and symmetric bearer enforcement is requested for one or more bearers, thus triggering corresponding monitoring/detection activities related to such bearer(s) by the terminal UE.

Once packets are arriving at the UE "inside" a dedicated bearer, the UE is configured to automatically learn which flows have been mapped into the bearer by the packet core, even without any signaling interaction. To this end, the terminal UE 4 in a step/stage S24 detects the incoming packet data flow(s) carried per (dedicated/default) bearer and analyses/inspects them, e.g. based on the DSCPs contained therein.

In order to do that, the UE keeps a traffic flow table, where all active traffic flows are recorded. For instance, the table lists all active TCP (or UDP) connections/flows that have been opened by the client through this PDN connection. When a flow has been moved to a dedicated bearer, the table entry will be extended to list the dedicated bearer assigned to the flow. This creates an implicit binding between traffic flows and bearers that is established automatically based on observing downlink packets. To this end, the terminal UE 4 in a step/stage S25 maintains (and/or generates or updates, depending on the prevailing circumstances) a traffic flow table based on the detection. Once the implicit bearer mapping is known, it is useable to map uplink packets to the correct bearer. To this end, the terminal UE 4 in a step/stage S26 maps uplink packet flow(s) to the corresponding bearer based on the binding retrieved from the traffic flow table. Thereafter, the uplink packets associated to the received downlink packets are sent in a step/stage S27 on the corresponding (dedicated/default) bearer.

This procedure is called symmetric bearer enforcement.

The ability to track TCP and also UDP flows is quite well-known from NAT (NAT = Network Address Translation) and firewall implementations. These are also tracking packet flows, in order to dynamically configure pinholes or NAT entries for each of the flows. Existing principles and concepts for dynamic handling of flows, flow tables and timeouts can be reused here. There are several ways how the enforcement of symmetric bearer usage can be implemented in a UE. A high-level requirement is to ensure symmetric usage of bearers by packet flows in uplink and downlink direction.

Two implementation alternatives (options 1 and 2) are described below:

Option 1 ):

One option is to rely on downstream packet marking as received by the UE, and return the same marking in upstream direction. In other words, the DSCP received in a downstream packet flow is copied into upstream packets of that same flow. In such case, a simple, DSCP-based filter can be used in uplink and downlink direction. However, this option is not necessarily recommendable under all circumstances, because it would require a modification of the TCP stack to copy the DSCP field per TCP connection (and a similar behavior for UDP). The TCP stack is part of the operating system, and in many cases outside of the control of the network operator or device manufacturer. There is also a risk that internal interfaces may not allow control over DSCP settings. Nonetheless, in case such amendments to the operating system are acceptable, the above still represents a feasible solution.

Option 2):

An alternative implementation option is to enhance the mobile network driver software for the 3G or LTE™ packet interface, which is located below the TCP/IP stack. This is usually a closed environment, often running on a dedicated processor, and not easily accessible by users. An additional benefit is that here we can use bearer signaling to control the enforcement procedure. As we are working at the driver level, any transport protocol can be supported (incl. SCTP (SCTP = Stream Control Transmission Protocol) and others). Hence, this represents at least one exemple of an option (with some advantages compared to option 1 ) above) so that this is described in more detail below.

In relation to this concept, transport-layer packet flows are tracked. At least TCP support is assumed, but in some cases also UDP flows may be in use by some applications. U DP support and support for other protocols such as SCTP is optional.

The algorithm and/or method is applicable for any transport protocol, and consists e.g. of the following steps or processing stages (described with reference to TCP as an example):

When a downstream packet is received by the UE, a lookup in the flow table is performed. When the flow is already known, the packet is directly forwarded. The bearer mapping of the flow must be checked and updated if necessary. When the flow is unknown, a new flow entry is created. The entry includes also a reference to the dedicated bearer from which the packet has been received.

Each packet (sent or received) resets the flow timeout for that particular flow, enabling an inactivity timeout. When an uplink packet is sent by the UE, a lookup in the flow table is performed. When the flow is already known, the packet is directly forwarded into the bearer specified by the flow table entry. If the flow is known, but the bearer is not specified, the default bearer will be used. If the flow is unknown, a new flow entry is created. As the correct bearer is not yet known, the default bearer is used.

Flow table entries are removed from the table either based on an inactivity timeout or by monitoring TCP control packets that are used to terminate TCP connections (e.g. TCP FI N). RFC 5382 recommends rather long timeouts for TCP NAT pinholes, to ensure that flow state is not removed prematurely. For example according to example embodiments of the invnetion, however, it is recommendable to apply much shorter timeouts in the order of 5 to 10 minutes, because the flow state can actually be recovered very quickly, and there is no disruption of the TCP flow even if a flow entry is lost. UDP timeouts can be even shorter, they are typically 30 to 60 seconds.

To prevent network-based DoS attacks, the UE optionally is configured to implement a very short timeout for flows that have been initiated from the network side. If the UE does not respond quickly, the flow should be removed. The UE also needs to ensure that the maximum flow table size is not exceeded. Note that deep-packet inspection in the core network may also be able to detect and prevent such DoS (DoS = Denial of Service) attacks.

To optimize the flow table usage and downlink performance, it is possible to apply the algorithm to specific dedicated bearers only. In that case, all flows using the default bearer do not need to be monitored at all. Only dedicated bearers for which dynamic flow detection has been requested by the core network need to activate dynamic flow monitoring.

Each entry of the TCP flow table contains the following information:

1. Remote IP address

2. IP protocol (e.g. TCP, UDP), or the equivalent for IPv6

3. Local and remote ports

4. Local bearer id

5. Timeout

Note that the table entries are very similar to TFT filter entries, except for the timeout. The algorithm can actually be viewed as an inband control mechanism for dynamic management of TFT filters, that operates in addition to and on top of the existing mechanism which is controlled by signaling procedures.

There is a limited number of TFT entries per bearer that can be configured via signaling. This limit does not apply to flow table entries. A UE generally is configured to support a sufficiently large number of flow entries, in the order of some 100s of flows which could be needed, e.g. for web browsing as an example of an application. The exact number also depends on how much "intelligence'Vprocessing capability is used to detect the termination of TCP connections. The core network is enabled to signal to the UE that dynamic flow monitoring and symmetric bearer enforcement is requested for a bearer. The details of how this can be signaled are not affecting the present invention as such. Possible options are some extensions of bearer signaling protocols, or a specific filter definition that would otherwise have no effect on regular bearers or UEs that do not support this procedure (e.g. specifying a filter with an invalid remote address, such as 0.0.0.0 or 255.255.255.255).

Although the above description focused on an algorithm aspect, it is to be understood that the algorithm is configurable to corresponding hardware or implemented as software code loaded to a processor.

Figure 6 shows a basic block circuit diagram of a terminal UE in which embodiments of the present invention are implemented. The terminal UE 4 comprises a interface, Tx/Rx, cf. numeral 43, for transmission to / reception from a network transceiver device e.g. eNB and/or via the eNB to/from other network entities as such. The interface is bidirectional connected to a control module such as a processor, e.g. a digital signal processor, DSP, or ASIC (ASIC = application specific integrated circuit), CPU (central processing unit), or the like, denoted by numeral 42. The control module is bidirectional connected to a memory module MEM, denoted by numeral 41 . The memory module can be any type of memory to which data can be written and from which data can be read, e.g. a Flash memory, RAM (Random Access Memory), or also EPROM (Electrically Programmable Read Only Memory). The memory module is configured to store at least the traffic flow table maintained by the terminal. Thus, the memory module can be a separate memory module or a partition of a memory module storing also other user/control data associated to the terminal UE 4. Other memory modules may be present, too, in the terminal.

Examples of the invention can be embodied in an apparatus or unit of the terminal UE, e.g. denoted by numeral 40, comprising at least the modules 42 and 41 above.

Figure 3 illustrates an example of a traffic flow table maintained at least at a respective terminal UE. The table contains, per client, the active connections or packet data flows, the assigned bearers, and a "timeout parameter". Note that in general it is distinguished between a timeout as such (a constant value), and an expiration timer as a timeout parameter that must be maintained per flow. Each flow must have its own expiry, and the flow table contains primarily the expiration timer that is updated for each packet. A respective client (i.e. source of packet data flows received at the UE) is identified by its I P address and protocol type used (e.g. TCP, UDP, SCTP, or other). The active connection is identified by local and remote ports of respective flows #a, #b, #c. The assigned bearers are identified by the bearer I Ds of a default and/or designated bearers, e.g. I D#b, ID#c, I D#a. And a timeout parameter per connection/flow is represented by the variables x, y, z, respectively, for the different flows. Note that the timeout parameter value (denoted by x, y, z, in Fig.3) represented by the expiration timer can be the same for all flows, but can also be different. Note that in assigning the flow timeout parameter value of the expiration timer, a control unit of the apparatus (e.g. forming part of a terminal) is configured to choose the timeout parameter depending on the protocol used (e.g. TCP, or UDP, etc), or depending on the initiator (or origin) of the flow creation (i.e. whether a flow was initiated to be created by a UE for transmission or created by an external entity for transmission), or both. Thus, those values may be different for different transport protocols. The respective expiration timer is set/or reset with each packet that is received (in DL) or sent (in U L) in the respective flow. The above outlined data entries are present per client, i.e. client #1 , client #n having active connection(s) to the terminal.

Figure 4 illustrates at least an example of a flowchart from a terminal's perspective when receiving, in DL, packet data flows from a network side.

The flow starts in a step S40, e.g. upon receipt of a symmetric bearer enforcement request for one or more bearers from a client/network entity. Then, in a step S41 , the terminal UE receives DL packet(s) for the flow(s). In a step S42, the UE looks-up the flow table maintained in a memory at the UE.

In a step S43, it is checked whether that flow is known/present in the table (i.e. whether a corresponding entry for that flow exists in the table). If not, the algorithm branches to a step S46. In S46, a new flow table entry is created for the flow and a reference/binding to the bearer carrying the flow is written into the table entry. In a step S47, a timeout parameter, i.e. the expiration timer, is set and entered into the table entry. In a step S48, the packet is forwarded to a higher layer protocol stack at the terminal. After executing S48, the procedure ends, as shown in step S49. Note that timeout/expiration timer expiry can be based on a countdown or an upward counting, the counting steps can be clock cycles of a processor clock, or absolute time values, or the like. It could be a timer interrupt or some other solution. It can be independent of packet reception.

Then, if this is a second (or further packet) carried on that flow, the check in S43 will reveal that the flow is known in the table (YES in S43) and corresponding table entries are already present. In this instance, the algorithm/flow in S43 will branch to step S44. In step S44 it is checked whether the packet received is a flow termination control packet such as TCP FIN (in case of TCP as transport protocol underlying the flow). If so (YES in S44), the algorithm advances to S50 (flow is removed from flow table) and further to S48, i.e. the packet is forwarded to a higher layer protocol stack (and finally to the application).

However, if not (NO in S44), in a next step S45 there is verified the bearer mapping of the flow and the flow table is updated if necessary. Then, responsive to the new packet received, in step S47 the timeout parameter/expiration timer is reset, and the remaining steps S48 ff are executed.

Figure 5 illustrates at least an example of a flowchart from a terminal's perspective when transmitting, in UL, packet data flows to a network side.

The flow starts in a step/stage S60, e.g. upon receipt of a symmetric bearer enforcement request for one or more bearers from a client/network entity and/or upon a preceding receipt of a DL packet on a flow. In a step S61 , the UE has a packet for UL transmission to the client using a particular packet data flow.

In a step S62, the lookup table is consulted. In step S64, it is checked whether the flow (e.g. based on the flows local/remote ports) is known/present in the table.

If not (NO in S64), the algorithm advances to step S67. If known/present (YES in S64), step S64 will reveal that the flow associated to the packet is known/present in the table (YES in S64). Then, the algorithm proceeds to S63.

In S63 it is checked whether the packet received is a flow termination control packet such as TCP FIN (in case of TCP as transport protocol underlying the flow). If so (YES in S63), the algorithm advances to S70 (flow is removed from flow table, and packet is forwarded) and from there further to S65.

However, if not (NO in S63), in a next step S65 it is verified whether a bearer is already specified for the known flow. If no bearer is specified (NO in S65), the algorithm proceeds to S67, where the packet is forwarded to a default bearer. Then, the packet is sent to the lower layers for transmission. If a bearer is already specified (YES in S65), the algorithm proceeds to S66, where the packet is forwarded to the bearer specified in the flow table and the flow table is updated in terms of timeout/expiration timer being reset. Then, the packet is sent to lower layers for transmission. After steps/stages S66 and S67, the algorithm ends, as shown in S69.

Although various aspects of the invention are set out in the independent claims, other aspects of the invention comprise other combinations of features from the described embodiments and/or the dependent claims with the features of the independent claims, and not solely the combinations explicitly set out in the claims.

It is also noted herein that while the above describes example embodiments of the invention, these descriptions should not be viewed in a limiting sense. Rather, there are several variations and modifications which may be made without departing from the scope of the present invention as defined in the appended claims.

List of acronyms and abbreviations as used herein above: QoS = Quality of Service 3GPP = 3^rd Generation Partnership Project PDP = Packet Data Protocol

UL = Uplink

DL = Downlink

TFT = Traffic Flow Templates

IP = Internet Protocol

HSPA = High Speed Packet Access

LTE = Long Term Evolution

PDN = Packet Data Network

CDN = Content Delivery Network

UE = user equipment

PC = Personal Computer

TCP = Transmission Control Protocol

HTTP = HyperText Transfer Protocol

DSCP = Differentiated Service Code Point

IPv6 = Internet Protocol version 6 eNB = evolved NodeB

QCI = quality of service class identifier

DPI = Deep Packet Inspection

RFC = Request for Comments of the IETF

IETF = Internet Engineering TaskForce

UDP = User Datagram Protocol

NAT = Network Address Translation

DoS = Denial of service

MME = Mobility management entity PCRF = Policy and charging rules function SCTP = Stream Control Transmission Protocol DSP = Digital Signal Processor, ASIC = Application Specific Integrated Circuit RAM = Random Access Memory,

EPROM = Electrically Programmable Read Only Memory UMTS = Universal Mobile Telecommunication System

Claims

What is claimed is:

1. An apparatus, comprising a control unit configured to receive at least one downlink packet data flow on a respective bearer, detect the bearer on which the downlink packet data flow is received, maintain a traffic flow table for the plurality of packet data flows, which includes at least an identification of each flow and an identification of a bearer mapped to each flow, and control transmission of corresponding uplink packet data flows, wherein a corresponding uplink data flow is assigned to the same bearer as the respective downlink packet flow, based on the mapping maintained in the traffic flow table.

2. An apparatus according to claim 1 , wherein the control unit is further configured to receive a trigger signal activating the control unit.

3. An apparatus according to claim 1 , wherein the control unit is further configured, to maintain the traffic flow table, to check, upon receipt of a packet flow on a bearer, whether the packet flow is known as present in the traffic flow table.

4. An apparatus according to claim 3, wherein the control unit is further configured, if the packet flow is not known as present, to create a new traffic flow table entry for that flow and the bearer on which it is carried, and if the packet flow is known as present, to verify the bearer mapping for the packet flow based on the traffic flow table.

5. An apparatus according to claim 4, wherein the control unit is further configured to, if the bearer mapping for the packet flow could not be verified from the traffic flow table entries, update the traffic flow table in terms of the detected bearer.

6. An apparatus according to claim 4, wherein the control unit is further configured to, check whether a packet received in the known packet flow is a flow termination control packet, and if so, to remove the flow entry from the traffic flow table.

7. An apparatus according to any of claims 3 to 6, wherein the control unit is further configured to, assign a flow timeout parameter to the respective traffic flow in the traffic flow table in response to each received packet of a flow.

8. An apparatus according to claim 7, wherein the control unit is further configured to, in assigning the flow timeout parameter, set the timeout parameter for a newly created flow, and reset the timeout parameter for a known flow.

9. An apparatus according to claim 7 or 8, wherein the control unit is further configured to, in assigning the flow timeout parameter, set the timeout parameter depending on at least one of the protocol used and an initiator of the flow.

10. An apparatus according to any of claims 7 to 9, wherein the control unit is further configured to, upon expiration of the timeout parameter, remove the corresponding flow entry from the traffic flow table.

1 1 . An apparatus, comprising a control unit configured to prepare at least one uplink data packet for transmission in an uplink packet data flow on a bearer, maintain a traffic flow table for a plurality of packet data flows, which includes at least an identification of each downlink packet flow and an identification of a bearer mapped to each downlink packet flow, and control transmission of uplink data packets in corresponding uplink data flows, wherein a corresponding uplink data flow is assigned to the same bearer as a respective downlink packet flow, based on the mapping maintained in the traffic flow table.

12. An apparatus according to claim 1 1 , wherein the control unit is further configured, to maintain the traffic flow table, to check, upon preparation of a packet for transmission in an uplink packet data flow on a bearer, whether the packet flow is known as present in the traffic flow table.

13. An apparatus according to claim 12, wherein the control unit is further configured to, if the bearer mapping for the packet flow in the traffic flow table does not reveal a bearer assigned to that flow, assign a default bearer for that flow

14. An apparatus according to claim 12, wherein the control unit is further configured to, if the bearer mapping for the packet flow in the traffic flow table does reveal a bearer assigned to that flow, assign the bearer specified in the traffic flow table for that flow.

15. An apparatus according to claim 12, wherein the control unit is further configured to, check whether a packet for transmission in the known packet flow is a flow termination control packet, and if so, to remove the flow entry from the traffic flow table.

16. An apparatus according to any of claims 12 to 15, wherein the control unit is further configured to, assign a flow timeout parameter to the respective traffic flow in the traffic flow table in response to each packet of a flow prepared for transmission.

17. An apparatus according to claim 16, wherein the control unit is further configured to, in assigning the flow timeout parameter, set the timeout parameter for a newly created flow, and reset the timeout parameter for a known flow.

18. An apparatus according to claim 16 or 17, wherein the control unit is further configured to, in assigning the flow timeout parameter, set the timeout parameter depending on at least one of the protocol used and an initiator of the flow.

19. An apparatus according to any of claims 16 to 18, wherein the control unit is further configured to, upon expiration of the timeout parameter, remove the corresponding flow entry from the traffic flow table.

20. An apparatus according to any of claims 1 to 10, further comprising an apparatus according to any of claims 1 1 to 19.

21 . A method, comprising receiving at least one downlink packet data flow on a respective bearer, detecting the bearer on which the downlink packet data flow is received, maintaining a traffic flow table for the plurality of packet data flows, which includes at least an identification of each flow and an identification of a bearer mapped to each flow, and controlling transmission of corresponding uplink packet data flows, wherein a corresponding uplink data flow is assigned to the same bearer as the respective downlink packet flow, based on the mapping maintained in the traffic flow table.

22. A method according to claim 21 , further comprising receiving an activating trigger signal.

23. A method according to claim 21 , further comprising, for maintaining the traffic flow table, checking, upon receipt of a packet flow on a bearer, whether the packet flow is known as present in the traffic flow table.

24. A method according to claim 23, further comprising, if the packet flow is not known as present, creating a new traffic flow table entry for that flow and the bearer on which it is carried, and if the packet flow is known as present, verifying the bearer mapping for the packet flow based on the traffic flow table.

25. A method according to claim 24, further comprising, if the bearer mapping for the packet flow could not be verified from the traffic flow table entries, updating the traffic flow table in terms of the detected bearer.

26. A method according to claim 24, further comprising checking whether a packet received in the known packet flow is a flow termination control packet, and if so, removing the flow entry from the traffic flow table.

27. A method according to any of claims 23 to 26, further comprising assigning a flow timeout parameter to the respective traffic flow in the traffic flow table in response to each received packet of a flow.

28. A method according to claim 27, further comprising, for assigning the flow timeout parameter, setting the timeout parameter for a newly created flow, and resetting the timeout parameter for a known flow.

29. A method according to claim 27 or 28, further comprising, for assigning the flow timeout parameter, setting the timeout parameter depending on at least one of the protocol used and an initiator of the flow.

30. A method according to any of claims 27 to 29, further comprising, upon expiration of the timeout parameter, removing the corresponding flow entry from the traffic flow table.

31 . A method, comprising preparing at least one uplink data packet for transmission in an uplink packet data flow on a bearer, maintaining a traffic flow table for a plurality of packet data flows, which includes at least an identification of each downlink packet flow and an identification of a bearer mapped to each downlink packet flow, and controlling transmission of uplink data packets in corresponding uplink data flows, wherein a corresponding uplink data flow is assigned to the same bearer as a respective downlink packet flow, based on the mapping maintained in the traffic flow table.

32. A method according to claim 31 , further comprising, for maintaining the traffic flow table, checking, upon preparation of a packet for transmission in an uplink packet data flow on a bearer, whether the packet flow is known as present in the traffic flow table.

33. A method according to claim 32, further comprising, if the bearer mapping for the packet flow in the traffic flow table does not reveal a bearer assigned to that flow, assigning a default bearer for that flow

34. A method according to claim 32, further comprising, if the bearer mapping for the packet flow in the traffic flow table does reveal a bearer assigned to that flow, assigning the bearer specified in the traffic flow table for that flow.

35. A method according to claim 32, further comprising, checking whether a packet for transmission in the known packet flow is a flow termination control packet, and if so, removing the flow entry from the traffic flow table.

36. A method according to any of claims 32 to 35, further comprising, assigning a flow timeout parameter to the respective traffic flow in the traffic flow table in response to each packet of a flow prepared for transmission.

37. A method according to claim 36, further comprising, in assigning the flow timeout parameter, setting the timeout parameter for a newly created flow, and resetting the timeout parameter for a known flow.

38. A method according to claim 36 or 37, further comprising, in assigning the flow timeout parameter, setting the timeout parameter depending on at least one of the protocol used and an initiator of the flow.

39. A method according to any of claims 36 to 38, further comprising, upon expiration of the timeout parameter, removing the corresponding flow entry from the traffic flow table.

40. A method according to any of claims 21 to 30, further comprising a method according to any of claims 31 to 39.

41 . A computer program product comprising computer-executable components which, when the program is run on a computer, are configured to perform the method steps according to any of claims 21 to 40.