Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L47/00—Traffic control in data switching networks
  • H04L47/10—Flow control; Congestion control
  • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
  • H04L47/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W28/00—Network traffic management; Network resource management
  • H04W28/02—Traffic management, e.g. flow control or congestion control
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W28/00—Network traffic management; Network resource management
  • H04W28/02—Traffic management, e.g. flow control or congestion control
  • H04W28/10—Flow control between communication endpoints
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L45/00—Routing or path finding of packets in data switching networks
  • H04L45/38—Flow based routing
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W40/00—Communication routing or communication path finding
  • H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update

Definitions

• the present invention relates to methods, computer program products and apparatuses enabling symmetric bearer enforcement.
• QoS Quality of Service
• QoS Quality of Service
• IP Internet Protocol
• 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.
• 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.
• PDN Packet Data Network
• 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 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.
• 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).
• TS23.401 with reference to e.g.
• TCP Transmission Control Protocol
• DSCP Differentiated Service Code Point
• IPv6 Internet Protocol version 6
• 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.
• 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.
• uplink traffic mapping i.e. not send any dynamic filter modifications.
• 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.
• an apparatus as defined in claim 1 1 and a method as defined in claim 31 there is provided an apparatus as defined in claim 1 1 and a method as defined in claim 31 .
• 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.
• 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 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,
• the network e.g. mobile gateway and/or a mobility management entity, MME
• MME mobility management entity
• any transport protocol can be supported, i.e. TCP, UDP, SCTP, etc..
• 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.
• 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.
• a respective bearer of the access network, i.e. radio or other wireless access network
• UDP User Datagram Protocol
• SCTP Stream Control Transmission Protocol
• a flow is constituted by e.g. a transmission of packets between two endpoints using the same set of source/destination ports.
• 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.
• 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.
• the application logic, software or an instruction set is maintained on any one of various conventional computer-readable media.
• 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, LTETM, 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.
• 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.
• device e.g. terminal
• device e.g. terminal
• transmitting of data This is done in order to keep the explanation simple and understandable.
• a corresponding device e.g. terminal or network device
• a receiving and sending capability e.g. terminal or network device
• 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 .
• the packet core network entity may limit flow-based bearer mapping to specific bearers only.
• a conceptual implementation of an example embodiment is as described herein below with reference to Fig. 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.
• that entity/functionality detects the application type(s) of the data flows and the required QoS for the flow(s).
• the entity/functionality maps packet data flow(s) to corresponding dedicated bearers and/or a default bearer.
• 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.
• 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.
• the UE is configured to automatically learn which flows have been mapped into the bearer by the packet core, even without any signaling interaction.
• 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.
• 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.
• TCP or UDP
• 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.
• NAT Network Address Translation
• 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.
• One option is to rely on downstream packet marking as received by the UE, and return the same marking in upstream direction.
• the DSCP received in a downstream packet flow is copied into upstream packets of that same flow.
• a simple, DSCP-based filter can be used in uplink and downlink direction.
• 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.
• 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):
• a lookup in the flow table is performed.
• the packet is directly forwarded.
• the bearer mapping of the flow must be checked and updated if necessary.
• 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.
• a lookup in the flow table is performed.
• 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.
• DoS Denial of Service
• Each entry of the TCP flow table contains the following information:
• IP protocol e.g. TCP, UDP
• IPv6 IP protocol
• 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.
• TFT entries per bearer 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).
• FIG. 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 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.
• 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
• 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.
• a timeout parameter per connection/flow is represented by the variables x, y, z, respectively, for the different flows.
• 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.
• a control unit of the apparatus e.g. forming part of a terminal
• TCP Transmission Control Protocol
• UDP User Datagram Protocol
• 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.
• 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.
• 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.
• a timeout parameter i.e. the expiration timer, is set and entered into the table entry.
• the packet is forwarded to a higher layer protocol stack at the terminal. After executing S48, the procedure ends, as shown in step S49.
• 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.
• step S43 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).
• TCP FIN flow termination control packet
• 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.
• the UE has a packet for UL transmission to the client using a particular packet data flow.
• step S62 the lookup table is consulted.
• step S64 it is checked whether the flow (e.g. based on the flows local/remote ports) is known/present in the table.
• step S64 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.
• 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.
• TCP FIN flow termination control packet
• 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.
• QoS Quality of Service
• 3GPP 3 rd Generation Partnership Project
• PDP Packet Data Protocol
• TFT Traffic Flow Templates
• IP Internet Protocol
• PDN Packet Data Network
• CDN Content Delivery Network
• TCP Transmission Control Protocol
• DSCP Differentiated Service Code Point
• IPv6 Internet Protocol version 6
• eNB evolved NodeB
• QCI quality of service class identifier
• MME Mobility management entity
• PCRF Policy and charging rules function
• SCTP Stream Control Transmission Protocol
• DSP Digital Signal Processor
• 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.
• a corresponding apparatus for uplink transmission is proposed as well as respective corresponding methods and computer program products.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Mobile Radio Communication Systems (AREA)

Priority Applications (1)

Applications Claiming Priority (1)

Publications (1)

Family

ID=46125463

Family Applications (1)

Country Status (1)

Cited By (8)

Citations (4)

• 2012
  • 2012-05-23 WO PCT/EP2012/059531 patent/WO2013174422A1/fr not_active Ceased

Patent Citations (4)

Similar Documents

Legal Events