Patent Description:
In order to improve throughput and resilience to access network failure DSL resources of access links provided by different residential routers can be bundled.

Such an approach is described by <NPL>. In this paper, a communication system comprising a plurality of DSL routers and an access aggregation point (AAP) as a termination point of a backbone network or the Internet is described, which is able to bundle DSL resources of neighboring DSL routers, which are connected to each other via so-called community links. The community links are based on Wi-Fi or Powerline Communication technology. A Multipath Transmission Control Protocol (MPTCP) module and a Quality of Service (QoS) module is implemented on each DSL router to transfer a TCP session into a MPTCP session with multiple sub-streams to ensure that capacity of available paths can be bundled. The QoS module is used to ensure bandwidth fairness between TCP traffic of the own DSL router and TCP traffic of neighbouring DSL routers which passes through the own DSL router due to the access bundling mechanism. This is achieved by putting TCP traffic of the own DSL router into a higher priority queue and TCP traffic of the neighboring DSL routers into a lower priority queue. However, a mechanism is implemented in each DSL router, which guarantees, that a very low bandwidth is assigned to the TCP traffic of neighboring DSL routers to keep the connection of neighboring traffic via the own DSL router alive. Document <CIT> discloses queue-based packet classification in MPTCP scenarios. Document <CIT> discloses a method of applying TFCP control functions on a UDP flow which is transmitted over an MPTCP connection between a residential gateway with hybrid access and a server.

It is an object of the present invention to provide a data traffic control device, a residential router comprising such a data traffic control device, an operator network device comprising such a data traffic control device and a telecommunication system, which allow for an improved control of different traffic transmitted by them to enhance a data throughput and resilience in particular in case of an access network failure.

The technical problem cited above is solved by a residential router of claim <NUM>, an operator network device according to claim <NUM> and a telecommunication system according to claim <NUM>.

The invention is described below in detail in connection with accompanying drawings, wherein.

Referring now to <FIG>, an exemplary telecommunication system <NUM> is shown. It is in particular adapted to control different data traffic and which may bundle access links of different residential routers <NUM>, <NUM>. n for improving data throughput and resilience to access network failure in particular by transmitting uplink traffic via different residential routers, e.g. residential routers <NUM> and <NUM>. n, to a termination point <NUM> and vice versa downlink traffic from the termination point <NUM> to a plurality of residential routers, e.g. residential router <NUM> and <NUM>. In the exemplary telecommunication system <NUM> only two residential routers are depicted, but in practice more than two residential routers are deployed.

The exemplary residential routers <NUM> and <NUM>. n described below may be considered as a conventional DSL router with additional functions. Therefore, residential router <NUM> may comprise at least one first access interface <NUM>, wherein residential router <NUM>. n may comprise at least one first access interface <NUM>. The first access interfaces <NUM> and <NUM>. n can be implemented as xDSL access interfaces each including a physical xDSL connector.

The exemplary telecommunication system <NUM> may include at least two customer networks <NUM> and <NUM>, wherein customer network <NUM> includes the residential router <NUM>. n and at least one user terminal <NUM>, which can be connected to a terminal interface <NUM>. n of residential router <NUM>. For example, the terminal interface <NUM>. n may comprise a physical connector, e.g. an Ethernet-based connector or a Wi-Fi-based connector. It is noted, that a plurality of communication interfaces can be implemented on the residential router <NUM>.

Similar, customer network <NUM> may include the residential router <NUM> as well as at least one user terminal <NUM>, which can be connected to a terminal interface <NUM> of the residential router <NUM>. For example, the terminal interface <NUM> may comprise a physical connector, e.g. an Ethernet-based connector or a Wi-Fi-based connector. It is noted, that a plurality of terminal interfaces can be implemented on the residential router <NUM>. The user terminal <NUM> and the user terminal <NUM> can be implemented as a PC, a mobile phone or any other user device. It should be noted, that the residential routers <NUM> and <NUM>. n may be connected to each other via a community link <NUM> to form a residential router community. With other words: The residential router <NUM> and the residential router <NUM>. n are assigned to different customers or customer networks <NUM> and <NUM>, respectively. A plurality of such residential routers can be interconnected to form a meshed residential router community.

Therefore, residential router <NUM> comprises a second access interface <NUM>, called community interface, which is configured to receive data packets, which may be called non-local data packets, from and to transmit data packets, which may be called local data packets, to another residential router, for example residential router <NUM>. n Similar, residential router <NUM>. n comprises a first access interface <NUM>. n, called community interface, which is configured to receive non-local data packets from and transmit local data packets to another residential router, for example residential router <NUM>. It is noted, that local data packets may define a first data traffic, wherein non-local data packets may define a second data traffic. Each of the community interfaces <NUM> and <NUM>. n can comprise a physical connector based e.g. on a Wi-Fi or Powerline Communication technology, so that the community link <NUM> can be realized as a WiFi-based or Powerline Communication based connection.

The residential router <NUM> may be configured to select local data packets provided by user terminal <NUM> and transmit them via its second access interface <NUM> and the community link <NUM> to the residential router <NUM>. n which may be configured to transmit these local data packets selected by the residential router <NUM> as non-local data packets to the termination point <NUM>. To do this the residential router <NUM> may use, for example the IP address of the residential router <NUM>. In a similar manner, residential router <NUM>. n may be configured to select local data packets provided by user terminal <NUM> and transmit them via its second access interface <NUM>. n and the community link <NUM> to the residential router <NUM>, which may be configured to transmit these local data packets selected by the residential router <NUM>. n as non-local data packets to the termination point <NUM>. To do this the residential router <NUM>. n may use, for example the IP address of the residential router <NUM>.

Both, residential router <NUM> and residential router <NUM>. n are connected to a first access network <NUM> via the first access interfaces <NUM>. n and <NUM>, respectively, to transmit and receive data traffic in form of data packets. In the present case, the first access network <NUM> is a fixed access network, namely an xDSL access network.

A third access interface <NUM>. n may be optionally implemented on residential router <NUM>. n, wherein a third access interface <NUM> can be optionally implemented on residential router <NUM>. For example, each of the third access interfaces <NUM> and <NUM>. n may be implemented each as a physical cellular WAN-based access interface, such as an LTE- based access interface. As a result, the exemplary residential routers <NUM> and <NUM>. n may be configured to get access to the termination point <NUM> and a data network <NUM>, respectively, also via a mobile radio access network <NUM>, which may be a LTE-based access network. The data network <NUM> is preferably the Internet.

It is to be noted, that with respect to residential routers <NUM> and <NUM>. n a first data traffic, which includes local data packets, relates to a data traffic, which is generated by a user terminal and transmitted by the residential router which the user terminal is connected to, wherein a second data traffic, which includes non-local data packets, is generated by a user terminal connected to a first residential router, wherein the second data traffic is transmitted from the first residential router to another residential router to be transmitted via the access network <NUM> and/or <NUM>. For example: Data traffic or data packets generated by the user terminal <NUM>, which shall be transmitted via the xDSL-based access interface <NUM> and/or the LTE-based access interface <NUM> to the termination point <NUM> are called first data traffic and local data packets, respectively. Data traffic or data packets generated by the user terminal <NUM>, forwarded via community access interface <NUM>. n to communication interface <NUM> of the residential router <NUM> and then transmitted by the residential router <NUM> via access interface <NUM> and/or access interface <NUM> to the termination point <NUM> are referred to as second data traffic and non-local data packets, respectively.

As shown in <FIG> the termination point <NUM> terminates the fixed access network <NUM> and, if used, the mobile radio access network <NUM>. The termination point <NUM> operates preferably as an access aggregation point, which can belong to or be connected to a backbone network <NUM> or the data network <NUM> and thus to an operator providing the respective services and functions. Therefore, the termination point <NUM>, which is preferably implemented as a device or a physical server including software, can be called an operator network device.

Referring now to <FIG>, the exemplary residential router <NUM> is described in detail. It should be noted, that both, residential router <NUM> and residential router <NUM>. n shown in <FIG> and <FIG> can be identically or similar implemented. Thus, the following illustration of residential router <NUM> may also be applicable to residential router <NUM>. n, which, however, is illustrated in <FIG> in a different way.

In <FIG>, the terminal interface <NUM>, the community interface <NUM>, also called second access interface, the LTE-based access interface <NUM>, also called the third access interface, and the xDSL-based access interface <NUM>, also called the first access interface, are depicted by way of example. As shown in <FIG> the user terminal <NUM> can be connected to the terminal interface <NUM>.

Furthermore, the residential router <NUM> comprises a data memory or data memory system <NUM> and at least one control unit <NUM> connectable to the data memory <NUM>. The control unit <NUM> can be implemented as a micro controller or micro processor.

It should be noted, that the first access interface <NUM>, the data memory <NUM> and the at least one control unit <NUM> define a data traffic control device.

The first, second and third instructions can be stored on the data memory <NUM> or in a separate data memory (not shown) of the residential router <NUM>.

For example, a priority <NUM> is assigned to the first transmission queue <NUM>, the lowest priority <NUM> is assigned to transmission queue <NUM> and the highest priority is assigned to transmission queue <NUM>. This guarantees, that if meta data packets, i.e. third data traffic, local data packets, i.e. first data traffic, and non-local data packets, i.e. second data traffic, are stored on the data memory <NUM> in the respective transmission queues, the meta data packets are transmitted first, followed by the local data packets and finally by the non-local data packets. The meta data packets may include signaling information configured to establish multipath connections and/or signaling information to establish VPN tunnel connections. The meta data packets are preferably generated and provided by the residential router <NUM>.

The first instructions may be part of a software module <NUM>, which may be configured to identify, if executed by the control unit <NUM>, first data traffic, i.e. local data packets generated by the user terminal <NUM>, second data traffic, i.e. non-local data packets generated for example by user terminal <NUM> and third data traffic, i.e. meta data packets provided by the residential router <NUM> and, according to a chosen implementation, to assign to each data packet of the first, second and third data traffic in dependence of its traffic class the respective priority, so that each data packet can be stored under control of the control unit <NUM> in the respective transmission queue. This step is known as enqueueing. The traffic classes refer to first data traffic, i.e. local data packets, second data traffic, i.e. non-local data packets and third data traffic, i.e.meta data packets.

The second and third instructions may be part of a further software module <NUM>, which may be further configured to perform, if executed by the control unit <NUM>, a traffic shaping to limit, for example, the data transmission rate with respect to the DSL access interface <NUM> to preferably 16Mbps.

A multipath transport protocol instance <NUM> can be installed on the residential router <NUM>. The control <NUM> unit may be configured to execute the multipath transport protocol instance on the first data traffic, i.e. local data packets received at the terminal interface <NUM> and/or on the third data traffic, i.e. meta data packets to decide in dependence of at least one predefined transmission rule, whether the local data packets and/or the meta data packets are to be transmitted via the first access interface <NUM> and/or via the second access interface <NUM>. This can be achieved, for example, by labeling each data packet of the first and third data traffic with a respective identification, indicating the respective community access interface <NUM> and/or xDSL-based access interface <NUM>. It should be noted, that in the preferred embodiment the second data traffic, i.e. non-local data packets, are only transmitted via the xDSL access network <NUM>.

It is to be noted, that the multipath transport protocol instance <NUM> can be based on the Multipath Transmission Control Protocol (MPTCP), wherein the multipath capable data packets can be TCP data packets. The at least one predefined transmission rule can be based on a path cost metric and/or a round trip time associated to the access interfaces used and/or or any other rule to select an access interface, for example xDLS-based access interface <NUM> and/or community interface <NUM> and/or LTE-based access interface <NUM> for transmitting the local data packets and/or meta data packets. Furthermore, it is noted that the multipath transport protocol instance <NUM> may comprise a multipath scheduler, e.g. a known MPTCP scheduler as well as a known TCP-MPTCP converter. The TCP-MPTCP converter is configured to convert an uplink TCP session, initiated by the user terminal <NUM> into a MPTCP session and to convert a downlink MPTCP session received at the residential router <NUM> into a TCP session destined for the user terminal <NUM>.

In order to process multipath capable local data packets or non-multipath capable local data packets received, for example, from the user terminal <NUM> or another user device at the terminal interface <NUM>, a data traffic separation module <NUM> can be installed on the residential router <NUM>. It should be noted, that the data traffic separation module <NUM> may comprise a data traffic separation algorithm. Thus, the control unit <NUM> may be further configured to execute the data traffic separation algorithm to determine whether the local data packets received at the terminal interface <NUM> are multipath capable local data packets or non-multipath capable local data packets. Furthermore, the data traffic separation algorithm <NUM> may be configured to cause, if executed by the control unit <NUM>, the residential router <NUM> to store, in dependence of a chosen implementation, the detected non-multipath capable local data packets on the data memory <NUM> in the first transmission queue <NUM>, wherein the detected multipath capable local data packets are forwarded to and processed by the multipath transport protocol instance <NUM>.

In order to enhance data throughput and resilience of the telecommunication system <NUM>, the third access interface <NUM> as mentioned above, can be implemented on the residential router <NUM>, which is configured to transmit and/or receive local data packets, and/or meta data packets and/or non-local data packets, i.e. first, second and/or third data traffic, via the second access network <NUM>. The control unit <NUM> is configured to execute the multipath transport protocol instance <NUM> on the local data packets received at the terminal interface <NUM> and/or on the meta data packets to decide in dependence of at least one predefined transmission rule, whether the local data packets and/or the meta data packets are to be transmitted via the xDSL-based access interface <NUM> and/or the community access interface <NUM> and/or the LTE-based access interface <NUM>.

The control unit <NUM> may be configured.

The first instructions are further configured to store, if executed by the control unit <NUM>, only these local data packets of the first data traffic, which are to be transmitted via the first (xDSL-based) access interface <NUM>, on the data memory <NUM> in the first transmission queue <NUM> and/or only these meta data packets of the third data traffic, which are to be transmitted via the first (xDSL-based) access interface <NUM>, on the data memory <NUM> in the third transmission queue <NUM>.

The fourth instructions may be part of a software module <NUM>, which may be configured to identify, if executed by the control unit <NUM>, local data packets generated by the user terminal <NUM> and meta data packets provided by the residential router <NUM> and, according to a chosen implementation, to assign to each data packet of the first and third data traffic the respective priority in dependence of its traffic class and in dependence of the access interface to be used, so that each data packet, i.e. local or meta data packet, can be stored under control of the control unit <NUM> in the respective transmission queue <NUM>, <NUM> or <NUM>.

It is to be noted, that the access interface to be used by a respective data packet can be selected and assigned to the respective data packet by the multipath transport protocol instance <NUM>, which operates in this case as an access classifier.

The fifth and sixth instructions may be part of a further software module <NUM>. In a preferred embodiment, the fifth instructions are configured to read out, if executed by the control unit <NUM>, the data memory <NUM> with respect to the fourth, fifth and sixth transmission queue <NUM>-<NUM> with an adjustable data rate, e.g. 50Mbps. Preferably, the sixth instructions are configured to cause, if executed by the control unit, the control unit <NUM> and the residential router <NUM>, respectively, to transmit the local data packets stored on the data memory <NUM> in the fourth transmission queue <NUM> and/or the fifth transmission queue <NUM> and the meta data stored on the data memory <NUM> in the sixth transmission queue <NUM> completely via the second (community) access interface <NUM>, if the second access interface <NUM> is currently able to transmit data at the adjustable data rate. In this case, the software module <NUM> can be considered to operate as a traffic shaper and a dequeueing module.

In addition, an access de-multiplexer <NUM> can be implemented on the residential router <NUM>, which is configured to distribute the meta data packets and/or the first local data packets and/or the second local data packets according to the respective access interface selected by the multipath transport protocol instance <NUM> and assigned to the respective data packet.

As mentioned above, the data traffic separation module <NUM> may comprise a data traffic separation algorithm, which can be installed on the residential router <NUM>. Thus, the control unit <NUM> may be further configured to execute the data packet separation algorithm to determine whether the local data packets received at the terminal interface <NUM> are multipath capable local data packets or non-multipath capable local data packets. Furthermore, residential router <NUM> may be configured to store, in dependence of a chosen implementation, the detected non-multipath capable local data packets on the data memory <NUM> in the first transmission queue <NUM> as shown in <FIG>, or in the fourth transmission queue <NUM> or in the fifth transmission queue <NUM>. For example, non-multipath capable local data packets can be sent from data traffic separation module <NUM> via link <NUM> to software module <NUM> which causes, if executed by the control unit <NUM>, the residential router <NUM> to store the detected non-multipath capable local data packets in the first transmission queue <NUM>.

It is to be noted, that meta data packets may include signaling information configured to establish multipath connections and/or VPN tunneling connections between the residential router <NUM> and the operator network device <NUM>. Therefore, a VPN tunneling software module <NUM> executable by the control unit <NUM> may be installed on the residential router <NUM>. The VPN tunneling software module <NUM> is configured to encapsulate, in a known manner, data packets to be transmitted via the first access interface <NUM> and/or the third access interface <NUM>. Instead of establishing a tunnel connection between the residential routers <NUM> and <NUM>. n and the operator network device <NUM> their IP addresses may be used for communication between them.

It is to be noted, that the residential router <NUM> can be configured to perform a traffic classification in that a specific information can be put into the header of each data packet to be transmitted. The specific information may include a source and/or destination IP address, a port address or any other header information or extension helping the router <NUM> in identifying a data packet as a meta data packet, a local data packet or a non-local data packet, i.e. in identifying first, second and third data traffic.

Referring now to <FIG>, the exemplary residential router <NUM>. n is described in detail. In particular, residential router <NUM>. n differs from residential router <NUM> in that it uses three transmission queues instead of six transmission queues. However, as already mention above, residential routers <NUM> and <NUM>. n can be implemented in a similar or identical way.

In <FIG>, the terminal interface <NUM>. n, the community interface <NUM>. n, also called the second access interface, the exemplary LTE-based access interface <NUM>. n, also called the third access interface, and the exemplary xDSL access interface <NUM>. n, also called the first access interface, are depicted by way of example. As shown in <FIG> the user terminal <NUM> can be connected to the terminal interface <NUM>.

Furthermore, the residential router <NUM>. n may comprise a data memory or data memory system <NUM>. n and at least one control unit <NUM>. n connectable to the data memory <NUM>. The control unit <NUM>. n can be implemented as a micro controller or micro processor. The control unit <NUM>. n may be configured.

It should be noted, that the first (xDSL-based) access interface <NUM>. n, the data memory <NUM>. n and the at least one control unit <NUM>. n may define a data traffic control device. The first, second and third instructions can be stored on the data memory <NUM>. n or in a separate data memory (not shown) of the residential router <NUM>.

For example, a priority <NUM> is assigned to the first transmission queue <NUM>. n, the lowest priority <NUM> is assigned to transmission queue <NUM>. n and the highest priority is assigned to transmission queue <NUM>. This guarantees, that if meta data packets, i.e. third data traffic, local data packets, i.e. first data traffic, and non-local data packets, i.e. second data traffic, are stored on the data memory <NUM>. n in the respective transmission queues, the meta data packets are transmitted first, followed by the local data packets and finally by the non-local data packets. The meta data packets may include signaling information configured to establish multipath connections and/or signaling information to establish VPN tunnel connections. The meta data packets are preferably generated and provided by the residential router <NUM>.

The first instructions may be part of a software module <NUM>. n, which may be configured to identify, if executed by the control unit <NUM>. n, first data traffic, i.e. local data packets, generated by the user terminal <NUM>, second data traffic, i.e. non-local data packets generated, for example, by user terminal <NUM> and third data traffic, i.e. preferably meta data packets provided by the residential router <NUM>. n and, according to a chosen implementation, to assign to each data packet of the first, second and third data traffic the respective priority in dependence of its traffic class, so that each data packet can be stored under control of the control unit <NUM>. n in the respective transmission queue. This step is known as enqueueing. The traffic classes preferably refer to first data traffic, i.e. local data packets, second data traffic, i.e. non-local data packets, and third data traffic, i.e. meta data packets.

The second and third instructions may be part of a further software module <NUM>. n, which may be further configured to perform, if executed by the control unit <NUM>. n, a traffic shaping to limit, for example, the data transmission rate with respect to the DSL access interface <NUM>. n to preferably 16Mbps.

A multipath transport protocol instance <NUM>. n can be installed on the residential router <NUM>. The control unit <NUM>. n may be configured to execute the multipath transport protocol instance <NUM>. n on the first data traffic, i.e. local data packets received at the terminal interface <NUM>. n and/or on the third data traffic, i.e. preferably meta data packets to decide in dependence of at least one predefined transmission rule, whether the local data packets and/or the meta data packets are to be transmitted via the first (xDSL-based) access interface <NUM>. n and/or via the second (community) access interface <NUM>. This can be achieved, for example, by labeling each data packet of the first and third data traffic with a respective identification, indicating the respective access interface <NUM>. n and/or <NUM>. It should be noted, that in the preferred embodiment the second data traffic, i.e. non-local data packets, are only transmitted via the xDSL access network <NUM>.

It is to be noted, that the multipath transport protocol instance <NUM>. n can be based on the Multipath Transmission Control Protocol (MPTCP), wherein the multipath capable data packets can be TCP data packets. The at least one predefined transmission rule can be based on a path cost metric and/or a round trip time associated to the access interfaces used and/or any other rule to select an access interface, for example xDSL-based access interface <NUM>. n and/or community interface <NUM>. n and/or LTE-based access interface <NUM>. n for transmitting the local data packets and/or meta data packets. Furthermore, it is noted that the multipath transport protocol instance <NUM>. n may comprise a multipath scheduler, e.g. a known MPTCP scheduler as well as a known TCP-MPTCP converter. The TCP-MPTCP converter is configured to convert an uplink TCP session, initiated by the user terminal <NUM> into a MPTCP session and to convert a downlink MPTCP session received at the residential router <NUM>. n into a TCP session destined for the user terminal <NUM>.

In order to enhance data throughput and resilience of the telecommunication system <NUM>, the third (LTE-based) access interface <NUM>. n as mentioned above, can be implemented on the residential router <NUM>. n, which is configured to transmit and/or receive local data packets, and/or meta data packets and/or non-local data packets, i.e. first, second and/or third data traffic, via the second access network <NUM>. The control unit <NUM>. n may be configured to execute the multipath transport protocol instance <NUM>. n on the local data packets, i.e. first data traffic, received at the terminal interface <NUM>. n and/or on the meta data packets, i.e. third data traffic, to decide in dependence of at least one predefined transmission rule, whether the local data packets and/or the meta data packets are to be transmitted via the first (xDSL-based) access interface <NUM>. n and/or the second (community) access interface <NUM>. n and/or the third (LTE-based) access interface <NUM>.

The first instructions are further configured to store, if executed by the control unit <NUM>. n, the local data packets of the first data traffic, which are to be transmitted via the first (xDSL-based) access interface <NUM>. n, and/or the local data packets of the first data traffic, which are to be transmitted via the second (community) access interface <NUM>. n, and/or the local data packets of the first data traffic, which are to be transmitted via the third (LTE-based) access interface <NUM>. n on the data memory <NUM>. n in the first transmission queue <NUM>. n and, if available, the meta data packets of the third data traffic, which are to be transmitted via the first (xDSL-based) access interface <NUM>. n, and/or the meta data packets of the third data traffic, which are to be transmitted via the second access interface <NUM>. n, and/or the meta data packets of the third data traffic, which are to be transmitted via the third access interface <NUM>. n on the data memory <NUM>. n in the third transmission queue <NUM>.

Moreover, the first instructions may be configured to identify, if executed by the control unit <NUM>. n, local data packets generated by the user terminal <NUM> and meta data packets provided by the residential router <NUM>. n and, according to a chosen implementation, to assign to each data packet of the first and third data traffic the respective priority in dependence of its traffic class and in dependence of the access interface to be used, so that each data packet, i.e. a local data packet or a meta data packet, can be stored under control of the control unit <NUM>. n in the respective transmission queue <NUM>. n or <NUM>.

It is to be noted, that the access interface to be used by a respective data packet can be selected and assigned to the respective data packet by the multipath transport protocol instance <NUM>. n, which operates in this case as an access classifier.

The second instructions may be configured to read out, if executed by the control unit <NUM>. n, the data memory <NUM> with respect to the first transmission queue <NUM>. n storing local data packets and the third transmission queue <NUM>. n storing meta data packets with an adjustable data rate, e.g. 50Mbps. Preferably, the third instructions are configured to cause, if executed by the control unit <NUM>. n, the residential router <NUM>. n, to transmit the local data packets stored in the first transmission queue <NUM>. n and the meta data stored in the third transmission queue <NUM>. n completely via the second access interface <NUM>. n, if the second (community) access interface <NUM>. n is currently able to transmit data at the adjustable data rate. In this case, the software module <NUM>. n can be considered to operate as a traffic shaper and a dequeueing module.

In addition, an access de-multiplexer can be implemented on the residential router <NUM>, which is configured to distribute the meta data packets and/or the local data packets according to the respective access interface selected by the multipath transport protocol instance <NUM>. n and assigned to the respective data packet. The access de-multiplexer may be included in the software module <NUM>.

In order to process multipath capable local data packets and non-multipath capable local data packets received from the user terminal <NUM> at the terminal interface <NUM>. n a data traffic separation module <NUM>. n may be installed on the residential router <NUM>. The data traffic separation module <NUM>. n may be configured to determine whether the data packets received at the terminal network interface <NUM>. n are multipath capable data packets, i.e. multipath capable data traffic, or non-multipath capable data packets, i.e. non-multipath capable data traffic. In particular, the data traffic separation module <NUM>. n may be configured to cause with respect to non-multipath capable data traffic the residential router <NUM>. n to bypass the multipath transport instance <NUM>. n and to transmit according a chosen implementation the detected non-multipath capable data packets via the first access interface <NUM>. n or the second access <NUM>. n or the third access interface <NUM>. Preferably, non multipath capable data packets are stored in the first transmission queue <NUM>. Furthermore, the data traffic separation module <NUM>. n may be configured to cause, if executed by the control unit <NUM>. n, the residential router <NUM>. n to forward multipath capable local data packets to the multipath transport protocol instance <NUM>. n for further processing.

For example, non-multipath capable local data packets can be sent from data traffic separation module <NUM>. n to software module <NUM>. n which causes, if executed by the control unit <NUM>. n, the residential router <NUM>. n to store the detected non-multipath capable local data packets in the first transmission queue <NUM>.

It is to be noted, that meta data packets may include signaling information configured to establish multipath connections and/or VPN tunneling connections between the residential router <NUM>. n and the operator network device <NUM>. Therefore, a VPN tunneling software module <NUM>. n executable by the control unit <NUM>. n may be installed on the residential router <NUM>. The VPN tunneling software module <NUM>. n is configured to encapsulate, in a known manner, data packets to be transmitted via the first (xDSL-based) access interface <NUM>. n and/or the third (LTE-based) access interface <NUM>. Instead of establishing tunnel connection between the residential router <NUM>. n and the operator network device <NUM> their IP addresses may be used for communication between them.

It is to be noted, that the residential router <NUM>. n can be configured to perform a traffic classification in that a specific information can be put into the header of each data packet to be transmitted. The specific information may include a source and/or destination IP address, a port address or any other header information or extension helping the router <NUM>. n in identifying a data packet as a meta data packet, a local data packet or a non-local data packet, i.e. in identifying first, second and third data traffic.

Referring now to <FIG>, which depicts a block diagram of the exemplary operator network device <NUM> in detail.

The operator network device <NUM> includes a first access interface <NUM> terminating a first access network, which is, for example, the DSL-based access network <NUM>. Optionally, a second access interface <NUM> may be implemented on the operator network device <NUM>, wherein the second access interface <NUM> terminates a second access network, in the present case the mobile radio access network <NUM>. Moreover, a network interface <NUM> may be implemented on the operator network device <NUM> which can be connected to the Internet <NUM> and in particular to an application server <NUM> located in the Internet <NUM>.

It is to be noted, that the first access interface <NUM> can be a physical or virtual xDSL-based access interface and the second access interface <NUM> can be a physical or a virtual cellular WAN-based-based access interface, in particular a LTE-based access interface. The operator network device <NUM> is adapted to control different data traffic to be transmitted to at least one residential router, e.g. the residential routers <NUM> and/or 60n. In addition, a data memory <NUM> and at least a control unit <NUM>, e.g. a micro controller or micro processor, is implemented on the network device <NUM>. The control unit <NUM> is configured.

The first, second and third instructions can be stored on the data memory <NUM> or on a separate data memory (not shown) of the network device <NUM>.

For example, a priority <NUM> is assigned to the first transmission queue <NUM>, the lowest priority <NUM> is assigned to transmission queue <NUM> and the highest priority <NUM> is assigned to transmission queue <NUM>. This guarantees, that meta data packets, first local data packets and second local data packets are stored on the data memory <NUM> in different transmission queues. The meta data packets are transmitted first, followed by the first local data packets and finally by the second local data packets. Meta data packets may include signaling information configured to establish multipath connections and/or to establish VPN tunnel connections via the fixed access network <NUM> or the mobile radio access network <NUM>.

The first instructions may be part of a software module <NUM>, which may be configured to identify, if executed by the control unit <NUM>, first local data packets destined for the residential router <NUM>, second local data packets also destined for the residential router <NUM>, but to be routed via the residential router <NUM>. n to the residential router <NUM>, and meta data packets provided by the network device <NUM> and, optionally, to assign to each data packet in dependence of its traffic class the respective priority, so that each data packet of the first, second and third data traffic can be stored in the respective transmission queue. This step is known as enqueueing. The traffic classes preferably refer to first and second local data packets and meta data packets, i.e. to first, second and third data traffic.

The second and third instructions may be part of a further software module <NUM>, which may be further configured to perform, if executed by the control unit <NUM>, a traffic shaping to limit, for example, the data transmission rate with respect to the DSL access interface <NUM>.

In order to enhance data throughput and resilience of the telecommunication system <NUM> the operator network device <NUM> may comprise the second access interface <NUM>, e.g. the LTE-based access interface, which is configured to communicate via a second access network, e.g. the LTE-based access network <NUM> with at least one residential router, e.g. the residential router <NUM> and/or the residential router <NUM>.

Furthermore, a multipath transport protocol instance <NUM> may be installed on the operator network device <NUM>. The control unit <NUM> is further configured to execute the multipath transport protocol instance on the first local data packets, i.e. the first data traffic, and/or the second local data packets, i.e. the second data traffic, and/or on the meta data packets, i.e. the third data traffic, to decide in dependence of at least one predefined transmission rule, whether the first local data packets and/or the second local data packets and/or the meta data packets are to be transmitted via the first (xDSL-based) access interface <NUM> and/or the second (LTE-based) access interface <NUM>. This can be achieved, for example, by labeling each data packet of the first, second and third data traffic with a respective identification, indicating the xDSL-based access interface <NUM> or the LTE-based access interface <NUM>.

In addition, an access de-multiplexer can be implemented on the operator network device <NUM>, which is configured to distribute the meta data packets and/or the first local data packets and/or the second local data packets to the respective access interface <NUM> and/or <NUM> selected by the multipath transport protocol instance <NUM>. The access de-multiplexer may be included in the software module <NUM>.

It is to be noted, that the multipath transport protocol instance <NUM> can be based on the Multipath Transmission Control Protocol (MPTCP), wherein the multipath capable data packets can be TCP data packets. The at least one predefined transmission rule can be based on a path cost metric and/or a round trip time associated to the access interfaces used and/or to any other rule to select an access interface, for example access interface <NUM> and/or access interface <NUM> for transmitting first and/or second local data packets and/or meta data packets. Furthermore, it is noted that the multipath transport protocol instance <NUM> may comprise a multipath scheduler, e.g. a known MPTCP scheduler as well as a known TCP-MPTCP converter. The TCP-MPTCP converter is configured to convert an uplink TCP session received from the Internet <NUM> into a MPTCP session and to convert a MPTCP session received at the access interface <NUM> and/or at the access interface <NUM> into a TCP session destined for the Internet <NUM>.

In order to process multipath capable local data packets and non-multipath capable local data packets received from the Internet <NUM> at the network interface <NUM> a data traffic separation module <NUM> may be installed on the operator network device <NUM>. The data traffic separation module <NUM> may be configured to determine whether the data packets received at the network interface <NUM> are multipath capable data packets, i.e. multipath capable data traffic, or non-multipath capable data packets, i.e. non-multipath capable data traffic. In particular, the data traffic separation module <NUM> may be configured to cause with respect to non-multipath capable data traffic the operator network device <NUM> to bypass the multipath transport instance <NUM> and to transmit the detected non-multipath capable data packets via the first access interface <NUM> or the second access <NUM> according to a chosen implementation. Furthermore, the data traffic separation algorithm <NUM> may be configured to cause, if executed by the control unit <NUM>, the operator network device <NUM> to forward multipath capable local data packets via link <NUM> to the multipath transport protocol instance <NUM> for further processing as illustrated above.

It should be noted that the data traffic separation module <NUM> as well as the data traffic separation modules <NUM> and <NUM>. n are preferably located on layer <NUM> of the ISO OSI reference model. Therefore, data traffic separation module <NUM>, <NUM> and <NUM>. n, respectively, are configured to identify data packets as multipath capable or non-multipath capable data packets in dependence of the transport layer protocol used to transmit the respective data packet.

It is to be noted, that the operator network device <NUM> can be configured to perform a traffic classification in that a specific information can be put into the header of each data packet to be transmitted. The specific information may include a source and/or destination IP address, a port address or any other header information or extension helping the operator network device in classifying a data packet as a meta data packet, a first local data packet or a second local data packet, i.e. in classifying first, second and third data traffic. For example, the operator network device <NUM> can be informed of the current workload of each access interface of the residential routers <NUM> and <NUM>. n and decide thereon which data packets, which are not meta data packets, are to be handled as first or second local data packets.

Furthermore, the operator network device <NUM> and the control unit <NUM>, respectively, may be configured to execute a VPN tunnel software module <NUM> installed on the operator network device <NUM> to establish, for example, a VPN tunnel <NUM> from access interface <NUM> via the DSL access network <NUM> to the residential router <NUM>.

Now the operation of the exemplary telecommunication system <NUM> of <FIG> is illustrated in connection with some exemplary scenarios.

It is assumed, that both user terminal <NUM> and user terminal <NUM> are configured to generate TCP data packets. It is further assumed, that residential router <NUM>. n is about to transmit at least some data packets provided by user terminal <NUM> and to be transmitted via the operator network device <NUM> to the Internet <NUM> via the community link <NUM> to residential router <NUM>. These data packets are considered as non-local data packets by residential router <NUM>. Furthermore, it is assumed that local data packets provided by the user terminal <NUM> and meta data packets provided by the residential router <NUM> are to be transmitted via the operator network device <NUM> to the Internet <NUM>. In addition, it is assumed, that residential router <NUM> and in particular the MPTCP instance <NUM> know, that the DSL access interface <NUM> is the cheapest access interface and currently available to transmit all data packets.

As a result, the local TCP data packets received at terminal interface <NUM> are forwarded by the data packet separation module <NUM> via path <NUM> to the MPTCP instance <NUM>. Now, the control unit <NUM> may cause, if executing the MPTCP instance <NUM> and the software module <NUM> on the local TCP data packets received at terminal interface <NUM> and on the meta data packets, the residential router <NUM> to store the local TCP data packets in the transmission queue <NUM> and the meta data packets in transmission queue <NUM>. In addition, the residential router <NUM> and preferably software module <NUM> is configured to identify the data packets provided by user terminal <NUM> and received at the community interface <NUM> as non-local data packets and to store these non-local data packets in transmission queue <NUM>. These functions can be performed by the control unit <NUM> when executing the software module <NUM>. Next, the residential router <NUM> may establish a VPN tunnel <NUM> from access interface <NUM> via the DSL access network <NUM> to the operator network device <NUM> by executing VPN tunnel software module <NUM> and transmit at first the meta data packets stored in transmission queue <NUM>, later on the local data packets stored in transmission queue <NUM> and finally the non-local data packets stored in the transmission queue <NUM> to the operator network device <NUM> via the VPN tunnel <NUM>. The operator network <NUM> is configured to forward the local data packets and the non-local data packets in a proper way to the Internet <NUM>.

Now it is assumed, that operator device <NUM> stores data to be sent to residential routers. For example, first local data packets destined for the residential router <NUM> are stored in transmission queue <NUM>, second local data packets destined for the residential router <NUM>. n, but to be routed via residential router <NUM> to residential router <NUM>. n are stored in transmission queue <NUM> and meta data packets are stored in transmission queue <NUM>. It is to be noted, that all local data packets have been received from the Internet <NUM> at network interface <NUM> and identified and classified by the operator network device <NUM> as first local data packets and second local data packets. Next, the operator network device <NUM> may establish a VPN tunnel <NUM> from access interface <NUM> via the DSL access network <NUM> to the residential router <NUM> by executing VPN tunnel software module <NUM>. Later on, operator network device <NUM> transmits first the meta data packets stored in transmission queue <NUM>, second the first local data packets stored in transmission queue <NUM> and finally the second local data packets stored in the transmission queue <NUM> to residential router <NUM>. The residential router <NUM> is configured to forward the second local data packets destined for the residential router <NUM>. n via the community link <NUM> to the residential router <NUM>.

Now it is assumed, that DSL access interface <NUM> of residential router <NUM> is overloaded or defect, user terminal <NUM> is about to transmit TCP data packets to the residential router <NUM> and meta data packets are provided by the residential router <NUM>, which are to be transmitted via the operator network device <NUM> to the Internet <NUM>. In addition, it is assumed that residential router <NUM> and in particular the MPTCP instance <NUM> know, that the DSL access interface is currently not able to transmit further data packets or data packets at all.

As a result, the local TCP data packets received at terminal interface <NUM> are forwarded by the data packet separation module <NUM> via path <NUM> to the MPTCP instance <NUM>. Now the control unit <NUM> may cause, if executing the MPTCP instance <NUM> and the software module <NUM> on the local TCP data packets provided by user terminal <NUM> and on the meta data packets, the residential router <NUM> to store selected first local TCP data packets in the transmission queue <NUM>, selected second local TCP data packets in transmission queue <NUM> and the meta data packets in transmission queue <NUM>. In dependence of the implementation and current traffic measurements MPTCP instance <NUM> may decide that the selected first data packets shall be transmitted via community interface <NUM>, the selected second data packets shall be transmitted via LTE-based access interface <NUM> and the meta data packets shall be transmitted via the community interface <NUM> and/or the LTE-based access interface <NUM>. Next, the residential router <NUM> may establish a VPN tunnel <NUM> from LTE-based access interface <NUM> via the LTE access network <NUM> to the operator network device <NUM> by executing VPN tunnel software module <NUM> and transmit first the meta data packets stored in transmission queue <NUM> via community interface <NUM> and/or LTE access interface <NUM>, the selected first second the local data packets stored in transmission queue <NUM> via community interface <NUM> and finally the selected second data packets stored in the transmission queue <NUM> via the LTE access interface <NUM> to the operator network device <NUM>. The residential router <NUM>. n is configured to transmit the meta data packets and the selected first data packets received from residential router <NUM> for example via its first (xDSL-based) access interface <NUM>. n to the operator network <NUM>.

At least some of the preferred aspects illustrated above are now summarized in connection with the <FIG>.

A data traffic control device for controlling different data traffic is provided, which may comprise the following features:.

According to a second exemplary aspect a residential router <NUM> for controlling different data traffic is provided, which may comprise the following features:.

For example, the first data traffic may be referred to local data traffic provided by the residential user terminal <NUM> connectable to the residential router <NUM>, the second data traffic may be referred to non-local data traffic provided by the other residential router <NUM>. n and the third data traffic may be referred to meta data traffic provided by the residential router <NUM>.

In order to increase data throughput and resilience a multipath transport protocol instance <NUM> may be installed on the residential router <NUM>, wherein the control unit <NUM> may be further configured to execute the multipath transport protocol instance <NUM> on the first data traffic received at the terminal interface <NUM> and/or on the third data traffic to decide in dependence of at least one predefined transmission rule, whether the first data traffic and/or the third data traffic are each to be transmitted via the first access interface <NUM> and/or the second access interface <NUM>.

In particular, the control unit <NUM> may be configured to.

execute the multipath transport protocol instance <NUM> on the third data traffic to decide in dependence of at least one predefined transmission rule, whether the third data traffic shall be transmitted via the first access interface <NUM> or the second access interface <NUM>, or whether some of the data packets of the third data traffic shall be transmitted via the first access interface <NUM>, whereas other data packets of the third data traffic shall be transmitted via the second access interface <NUM>.

In order to improve data throughput and resilience a third access interface <NUM> may be implemented on the residential router <NUM>, wherein the third access interface <NUM> is configured to transmit data traffic via a second access network <NUM>, wherein the control unit <NUM> may be further configured to execute the multipath transport protocol instance <NUM> on the first data traffic received at the terminal interface <NUM> and/or on the third data traffic to decide in dependence of at least one predefined transmission rule, whether the first data traffic and/or the third data traffic are each to be transmitted via the first access interface <NUM> and/or the second access interface <NUM> and/or the third access interface <NUM>.

the first instructions may be configured to cause, if executed by the control unit <NUM>, the residential router <NUM> to store only the data packets of the first data traffic, which are to be transmitted via the first access interface <NUM>, on the data memory <NUM> in the first transmission queue <NUM> and/or only the data packets of the meta data packets, which are to be transmitted via the first access interface <NUM>, on the data memory <NUM> in the third transmission queue <NUM>.

Preferably, the fifth instructions may be configured to cause, if executed by the control unit <NUM>, the residential router <NUM> to read out the data memory <NUM> with respect to the fourth transmission queue <NUM>, the fifth transmission queue <NUM> and the sixth transmission queue <NUM> with an adjustable data rate, and wherein the sixth instructions may be configured to cause, if executed by the control unit <NUM>, the residential router <NUM> to transmit the data packets of the first data traffic stored on the data memory <NUM> in the fourth transmission queue <NUM> and/or the fifth transmission queue <NUM> and the data packets of the third data stored on the data memory <NUM> in the sixth transmission queue <NUM> completely via the second access interface <NUM>, if the second access interface <NUM> is currently able to transmit data at the adjustable data rate.

A data traffic separation module <NUM> may be installed on the residential router <NUM>, which is configured to determine whether the first data traffic is a multipath capable data traffic or a non-multipath capable data traffic.

Preferably, the data traffic separation module <NUM> is configured to cause the residential router <NUM> to bypass the multipath transport protocol instance <NUM> and to store the detected the non-multipath capable first data traffic on the data memory <NUM> in the first transmission queue <NUM> or the fourth transmission queue <NUM> or the fifth transmission queue <NUM>, wherein the detected multipath capable first data traffic are forwarded to the multipath transport protocol instance <NUM>.

Preferably, the first access interface <NUM> is an xDSL-based or fiber physical interface, wherein the second access interface <NUM> can be a Wi-Fi or Powerline Communication based physical interface, and wherein the third access interface (<NUM>), if implemented or activated, can be a cellular WAN based physical interface.

Preferably, the highest priority is assigned to the third transmission queue <NUM> and to the sixth transmission queue (<NUM>), if implemented, whereas the lowest priority is assigned to the second transmission queue <NUM> and to the fifth transmission queue (<NUM>), if implemented.

An operator network device <NUM> for controlling different data traffic is provided, which comprises a data traffic control device as set forth above and a network interface <NUM> configured to be connected to a data network <NUM>. The operator network device <NUM> is configured to transmit the data traffic to at least one residential router <NUM>, <NUM>.

In particular, the first access interface <NUM> is configured to communicate via the first access network <NUM> with at least one residential router <NUM>, <NUM>. n, wherein the control unit <NUM> is configured.

In order to improve data throughput and resilience.

In order to increase flexibility of the operator network device a data traffic separation module <NUM> may be installed on the operator network device <NUM>, which is configured to determine whether the first and/or second data traffic received at the network interface <NUM> are a multipath capable data traffic or a non-multipath capable data traffic and wherein the data traffic separation module <NUM> may be further configured to cause the operator network device <NUM> to bypass the multipath transport instance <NUM> and to transmit the non-multipath capable data traffic via the first access interface <NUM> or the second access interface <NUM>.

Preferably, the highest priority is assigned to the third transmission queue <NUM>, whereas the lowest priority is assigned to the second transmission queue <NUM>.

A telecommunication system <NUM> is provided, which may comprise the following features:.

Preferably, the residential router <NUM> may be configured to.

Furthermore the residential router <NUM> may be configured to.

Preferably, a VPN tunneling algorithm <NUM> is installed on the residential router <NUM>, wherein the control unit <NUM> is configured to execute the VPN tunneling algorithm <NUM> to establish a tunnel connection <NUM> via the first access interface <NUM> and/or a tunnel connection <NUM> the third access interface <NUM> to an operator network device <NUM> as depicted in <FIG>.

Preferably, the third data traffic may carry meta data, which may comprise signaling information configured to establish single path or multipath connections and/or signaling information configured to establish VPN tunnel connections <NUM>, <NUM>, <NUM>, <NUM>.

Preferably, an xDSL modem and/or a fiber modem is implemented in the residential router <NUM>.

Preferably, the control unit <NUM> of the operator network device <NUM> may be further configured to.

Preferably, the at least one predefined transmission rule used by the residential router <NUM>, the residential router and the operator network device <NUM> is based on a path cost metric or the round trip time associated with the respective access interface. This allows the residential router <NUM> and/or the operator network device <NUM> to select, for example, the cheapest access interface, e.g. the first access interface <NUM> and <NUM>, respectively, to transmit the first, second and/or third data traffic.

Preferably, the multipath transport protocol instance <NUM> and <NUM>, respectively, may be based on the multipath transmission control protocol (MPTCP) and the multipath capable data traffic may comprise TCP data packets.

Claim 1:
A residential router (<NUM>) for controlling different data traffic, the residential router (<NUM>) comprising:
- a terminal interface (<NUM>) configured to receive first data traffic from a residential user terminal (<NUM>),
- a second access interface (<NUM>) configured to receive second data traffic from another residential router (<NUM>.n), wherein the residential router (<NUM>) and the other residential router (<NUM>.n) are assigned to different customers (<NUM>, <NUM>), and
- a data traffic control device for controlling different data traffic, the data traffic control device comprising:
- a first access interface (<NUM>; <NUM>.n; <NUM>) configured to transmit data traffic via a first access network (<NUM>),
- a data memory (<NUM>; <NUM>.n; <NUM>),
- at least one control unit (<NUM>; <NUM>.n; <NUM>) configured
i) to execute first instructions, stored on the data traffic control device, to store, on the data memory (<NUM>; <NUM>.n; <NUM>), the first data traffic in a first transmission queue (<NUM>; <NUM>.n; <NUM>), the second data traffic in a second transmission queue (<NUM>; <NUM>.n; <NUM>) and third data traffic including meta data packets in a third transmission queue (<NUM>, <NUM>.n; <NUM>), wherein different priorities are assigned to the first, second and third transmission queue,
ii) to execute second instructions, stored on the data traffic control device, to read out the first data traffic, the second data traffic and the third data traffic stored on the data memory (<NUM>; <NUM>.n; <NUM>) according to the priority assigned to the first transmission queue (<NUM>; <NUM>.n; <NUM>), the second transmission queue (<NUM>; <NUM>.n; <NUM>) and the third transmission queue (<NUM>; <NUM>.n; <NUM>), and
iii) to execute third instructions, stored on data traffic control device, to transmit, via the first access interface (<NUM>; <NUM>.n, <NUM>), the first data traffic, the second data traffic and the third data traffic in the order as read out, wherein the first data traffic, the second data traffic and the third data traffic each comprise a plurality of data packets.