WO2016027130A1

WO2016027130A1 - Identifying and controlling multipath traffic

Info

Publication number: WO2016027130A1
Application number: PCT/IB2014/064009
Authority: WO
Inventors: Dinand Roeland; Francisco ALCOBA GONZALEZ; Ibon Gochi Garcia
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2014-08-21
Filing date: 2014-08-21
Publication date: 2016-02-25

Abstract

The network operator identifies sub-flows of a multipath connection without employing the endpoints thereof. The identified sub-flows are correiated as a group, the network operator then controlling traffic on one or more of the correlated sub-flows.

Description

IDENTIFYING AND CONTROLLING MULTIPATH TRAFFIC

TECHNICAL FIELD

[0001] The present invention generally relates to networks, software and methods and, more particularly, to techniques for identifying and controlling multipath traffic independent from endpoints thereof.

BACKGROUND

[0002] In order to enable devices produced by various manufacturers to communicate wirelessly, international technical groups, such as the 3^rd Generation Partnership Project (3GPP), have developed standard specifications. A basic concept in one such specification, the 3GPP Evolved Packet Core (EPC) architecture is a Packet Data Network (PDN), which is a network that communicates with client devices (user equipment, UE) via data packets to provide various services. 3GPP's PDN is an Internet Protocol (IP) based network (although it can in principle be also a non-IP network, there are no such deployments). A PDN may be open, i.e., connected to the Internet, but it can also be a closed corporate network or an operator service network like an IP Multimedia Subsystem (IMS). A PDN has one or more names, each name represented in a string called the Access Point Name (APN). A PDN gateway (PDN- GW or PGW) is a functional node that provides access to one or more PDNs. The interface between the PGW and the PDN is called SGi.

[0003] When UE connects to the PDN, the UE is assigned an access channel to the PDN, which is a logical IP tunnel between the UE and PGW. Each PDN connection has an IPv4 address and/or an IPv6 prefix. A UE can set up multiple PDN connections, possibly to the same APN.

[0004] The access network between UE and the PGW may be a 3GPP access network or a non-3GPP access network (e.g., may be a Wireless Local Area Network, WLAN). For 3GPP access networks, the radio technology between UE and the PGW is defined by 3GPP (e.g., a Long-Term Evolution, LTE, standard). UE can set up one or more PDN connections over a 3GPP access, over a non-3GPP access, or over both.

[0005] Figure 1 illustrates a setup (reproduced from 3GPP TS 23.401 version 12.5.0) in which a 3GPP LTE Evolved Universal Terrestrial Access Network (E-UTRAN) 120 connects UE 110 to PDN 130 (which is labeled "Operator's IP Services"). User plane traffic is routed from network 120 to PDN gateway 125 via S5 interface 123, and from PDN gateway 125 to PDN 130 via SGi interface 127.

[0006] Figure 2 (reproduced from 3GPP TS 23.401 version 12.5.0) illustrates a setup in which a non-3GPP access network connects UE 210 to PDN 230. User plane traffic is routed via S2 type interface 223 to PDN gateway 225, and from PDN gateway 225 to PDN 230 via SGi interface 227.

[0007] UE can set up multiple PDN connections simultaneously, possibly via multiple accesses. For example, UE may have a PDN connection via LTE, and, simultaneously, another PDN connection via WLAN. Thus, traffic between UE and a PDN may be split into multiple paths, yielding a multipath connection between endpoints.

[0008] An extension to Transmission Control Protocol, TCP, called "multipath TCP" (MPTCP), is currently developed (standardized) by the International Engineer Task Force (IETF) (e.g., some recently discussed MPTCP issues are published in IETF Request for Comments, RFC, 6824, January 2013). Architectural guidelines for multipath TCP development are specified in IETF RFC 6182, published in March 2011. In IETF RFC 6182, "path" is defined as a sequence of links between a sender and a receiver, defined in IP context by a source and destination address pair.

[0009] Standard TCP/IP communication (without MPTCP) is restricted to a single path per connection. However, in many cases multiple paths exist between peers, e.g., in case one or both of the end devices are multi-home devices. A multi-home device is a device that has multiple IP interfaces and thereby multiple IP addresses, e.g., in case one or both of the end devices have connectivity via more than one access technology. For example, in a 3GPP multi-access scenario, a device (3GPP UE) may be connected via both a 3GPP access (such as GERAN, UTRAN, E-UTRAN) and a WLAN access simultaneously. The simultaneous use of these multiple paths for a TCP/IP connection enhances resource usage within the network and the user's experience through higher throughput and improved resilience to network failure. The use of MPTCP allows user traffic to be either routed only over one of the accesses or simultaneously over multiple accesses, enabling the traffic to be rerouted in a seamless fashion between accesses depending on coverage, radio link quality and other factors.

[0010] Figures 3A and 3B illustrate TCP and MPTCP protocol stacks,

respectively. Unlike a regular TCP illustrated in Figure 3A, when using MPTCP as in Figure 3B, data flow can be divided into one or more sub-flows. Since the same socket Application Programming Interface, API, is used, MPTCP is transparent (i.e., imposes no impact) to the application. MPTCP can distribute load on available interfaces, can increase bandwidth, and allows for seamless handover between two network access points.

[0011] The MPTCP stack schedules on a per-packet basis. Therefore, within a particular TCP session, a first packet may be scheduled to one (a first) sub-flow, and a second packet may be scheduled to another (a second) sub-flow. The scheduling algorithm not being pre-defined by IETF enables various designers to develop scheduling algorithms that take into account various parameters, such as the round-trip delay, static policies or external feedback.

[0012] MPTCP can either run end-to-end between endpoints as illustrated in Figure 4A or can be used up to a proxy between device and server as illustrated in Figure 4B. Using a proxy is an alternative to upgrading peers acting as servers to be able to provide MPTCP support. The proxy can perform traffic steering, which is of particular interest to a network operator when the proxy is part of the operator's network.

[0013] Traffic in a network overseen by an operator is subject to policy control and charging. Figure 5, which is reproduced from 3GPP TS 23.203 version 12.5.0, illustrates the 3GPP policy control and charging (PCC) architecture. All functional elements are defined and described in 3GPP TS 23.203. The Policy and Charging Rules Function (PCRF) 510 is the central controller. PCRF 510 sends rules to a Policy and Charging Enforcement Function (PCEF) 520, which actually enforces the rules. PCEF 520 may determine a policy-based action upon receiving a trigger, e.g., from an Application Function (AF) 530 or a Traffic Detection Function (TDF) 540. [0014] Interface Gx 550 between PCRF 510 and PCEF 520 manages PCEF's behavior through IP Connectivity Access Network (IP-CAN) sessions. The IP-CAN session is defined in 3GPP TS 23.203 as an association between UE and an IP network, which is identified by one IPv4 and/or an IPv6 prefix together with UE identity information, if available, and a PDN represented by a PDN ID (e.g., an APN). Thus, each IP-CAN session corresponds to a PDN connection. A PCC rule is a rule sent over an IP-CAN session from PCRF 510 to PCEF 520. Such a rule may include the following elements: (1) a name; (2) its applicability, which is a description of the traffic to which this rule applies, (e.g., basically a set of IP n-tuples with wildcards); (3) a policy defining what to do with the traffic to which this rule applies; and (4) charging

parameters.

[0015] The policy could be related (i) to gating status, defining whether traffic may pass (gate open) or not (gate closed), (ii) to the quality-of-service (QoS) class identifier (QCI), defining the QoS of the traffic, (iii) to uplink and downlink maximum bit rate (MBR), (iv) to uplink and downlink guaranteed bit rate (GBR), and/or (v) to the Allocation and Retention Priority (ARP).

[0016] Upon receiving a PCC rule, the PCEF may decide to set up or modify one or more bearers. A bearer uniquely identifies traffic that receives a common QoS treatment between UE and a PDN GW. Each PDN connection has at least one bearer, the default bearer. In addition to the default bearer, a PDN connection may have one or more dedicated bearers.

[0017] Most of the opportunities provided by MPTCP to policy/control traffic (routing, steering, balancing) require ownership (either implementation or configuration of the MPTCP stack) of the endpoints (e.g., device/client and server). However, more and more frequently over-the-top (OTT) service providers (like Apple) develop software (like Siri) that configures an MPTCP stack on the device and connects to a peer acting as server (or pool of servers) that also support MPTCP, implementing policy and control actions according to OTT requirements.

[0018] When the network operator does not configure and control MPTCP, the OTT application may use the access network resources is a way not optimal for the operator (e.g., in convergence fixed-mobile scenarios, by prioritizing sub-flows routed over the mobile access, which generally has a higher transmission cost per bit than fixed accesses) and may fail to take advantage of the status and capabilities of the different accesses available. In this case, most of the advantages introduced by MPTCP in terms of balancing and routing are iost without close integration of the OTT application with the underlying access networks.

[0019] Furthermore, the state-of-the-art in policy and control in both 3GPP and non-3GPP access networks works at TCP level (TCP flows), which, in case MPTCP is used, translates into policy and control actions over the MPTCP sub-flows. Current implementations of policy and control actions apply to datagrams (IP packets), flows (5- tupies using UDP, TCP or others), services (aggregation of 5-tupies) or bearers (IP- CAN sessions) but not to an MPTCP session (i.e., to a collection of MPTCP sub-flows).

[0020] It is desirable to enable network operators to apply policy and control actions to MPTCP sub-flows when the network operator does not configure and control MPTCP. SUMMARY

[0021] An objective of various embodiments is to enable the network operator to identify and control multipath sub-flows without employing endpoints thereof. One aspect is a transparent mechanism that identifies and correlates sub-flows by inspecting without altering or modifying traffic sent or received by the endpoints. Another aspect is related to the network operator using the acquired information (i.e., identifying and correlating the multipath sub-flows) to enforce traffic policy, control, routing, forwarding or others according to the access networks' status and characteristics. The manner of enforcing network's traffic policies is transparent in the sense that IP packets are not modified.

Although the consequences (like forcing the use of a predefined route for the sub-flows) are visible, they can be attributed to policy decisions similar to the sub-flows being treated independently.

[0022] According to an embodiment, there is a method related to a multipath connection between a first and a second endpoint. The method includes identifying a first sub-flow of the multipath connection based on information extracted from first sub-flow setup messages exchanged between the first endpoint and the second endpoint. The method further includes identifying a second sub-flow of the multipath connection, based on information extracted from second sub-flow setup messages exchanged between the first endpoint and the second endpoint. The method also includes creating a group of sub- flows related to the multipath connection and including the first and second sub-flows.

[0023] According to another embodiment, there is a controller of a network operator managing a network. The controller includes a first module configured to identify a first sub-flow of a multipath connection based on information extracted from first sub-flow setup messages exchanged between a first endpoint and a second endpoint via a first network device, and a second module configured to identify a second sub-flow of the multipath connection based on information extracted from second sub-flow setup messages exchanged between the first endpoint and the second endpoint via a second network device. The controller further includes a third module configured to create a group of sub- flows related to the multipath connection and including the first and second sub-flows.

[0024] According to another embodiment, there is a computer-readable medium storing computer-executable instructions which, when executed, implement a method related to a multipath connection between a first endpoint and a second endpoint in a packet data network. The method includes identifying a first sub-flow of the multipath connection based on information extracted from first sub-flow setup messages exchanged between the first endpoint and the second endpoint. The method further includes identifying a second sub-flow of the multipath connection based on information extracted from second sub-flow setup messages exchanged between the first endpoint and the second endpoint. The method also includes creating a group of sub-flows related to the multipath connection and including the first and second sub-flows.

BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate one or more embodiments and, together with the description, explain these embodiments. In the drawings:

[0026] Figure 1 illustrates UE connected to a PDN via a 3GPP network;

[0027] Figure 2 illustrates UE connected to a PDN via a non-3GPP network;

[0028] Figures 3A and 3B illustrate TCP and MPTCP protocol stacks, respectively;

[0029] Figure 4A illustrates an end-to-end MPTCP connection, and Figure 4B illustrates an MPTCP connection which uses an MPTCP-capable proxy;

[0030] Figure 5 illustrates the 3GPP PCC architecture;

[0031] Figure 6 is a diagram of a method according to an embodiment;

[0032] Figure 7 is flowchart of a method according to an embodiment;

[0033] Figure 8 illustrates the messages exchanged during an MPTCP session setup according to an embodiment;

[0034] Figure 9 illustrates the messages exchanged during an MPTCP session setup according to another embodiment;

[0035] Figure 10 illustrates the manner in which a policy controller makes policy decisions and how these policy decisions are implemented according to an

embodiment; and

[0036] Figure 11 is a block diagram of a policy controller according to an embodiment. DETAILED DESCRIPTION

[0037] The following description of the exemplary embodiments refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. The following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims. The following embodiments are discussed, for simplicity, with regard to the terminology and structure of a wireless network capable of MPTCP communication. However, it should be understood that the methods may be applied for other types of multipath protocols.

[0038] Reference throughout the specification to "one embodiment" or "an embodiment" means that a particular feature, structure or characteristic described in connection with an embodiment is included in at least one embodiment of the present invention. Thus, the appearance of the phrases "in one embodiment" or "in an

embodiment" in various places throughout the specification is not necessarily all referring to the same embodiment. Further, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments or claims.

[0039] The advantages that MPTCP use offers to OTT applications (robustness, cheap handovers, transparency with current technologies, etc.) render foreseeable rapid growth of OTT applications using MPTCP. The use of MPTCP also offers significant opportunities to network operators managing several access networks simultaneously (such as convergence scenarios in which the fixed access network overlaps the mobile access network). Network operators can use the mechanisms built into MPTCP to enforce policy such as routing without coordinating with OTTs or requiring subscribers to use specific software or applications. These advantages are not possible when using traditional TCP connections where inspecting the traffic (e.g., using a Traffic Detection Function, TDF, of the network operator) does not enable enforcing different routing policies without disrupting endpoint devices (i.e., the client and/or the server). MPTCP provides the framework within which MPTCP sub-flow information can be acquired and used.

[0040] Figure 6 schematically illustrates the manner in which the presence of MPTCP traffic traversing an operator's network is identified as a situation in which a third party (e.g., an OTT application) implements the MPTCP session in both endpoint devices 610 and 620. Device 610 (which may implement a service provided by the OTT

application) communicates via at least two MPTCP sub-flows 630 and 640 with peer device 620 (which may be an MPTCP proxy implemented by the OTT application residing on an external network like a PDN in a 3QPP architecture).

[0041] All sub-flows between device 610 and peer 620 may pass through the operator's network (which may include one or multiple access networks). The sub-flows may be routed over different access types: for example, sub-flow 630 may be routed over a 3GPP access like LTE, and sub-flow 640 may be routed over WLAN. The network operator deploys deep packet inspection (DPI) functions 633 and 643 that are capable of examining traffic (using shallow, deep, heuristic techniques or other). An example of a DPI function in a 3GPP architecture is a TDF. Furthermore, the network operator may deploy policy enforcement points (PEPs) 637 and 647 that are each able to enforce a specific policy on a specific sub-flow. In a 3GPP architecture, the PEP may be a PCEF, but could also be a function in the radio access network. The PEP and the DPI are controlled by a policy controller (PC) 650. An example of a PC in a 3GPP architecture is a PCRF. Note Figure 6 is a functional scheme. In one embodiment, the different functions PEP, DPI and PC may be co-located in the same node. In other embodiments, one or more of these functions may be distributed over multiple nodes.

[0042] In the context of a multipath connection between endpoints, according to one embodiment, there is a method performed by an operator of the network via which the endpoints are connected for identifying and coordinating sub-flows of the multipath connection. The multipath connection may be an MPTCP connection. As illustrated in the flowchart of Figure 7, the method includes identifying a first sub-flow of the multipath connection based on information extracted from first sub-flow setup messages exchanged between the endpoints, at 710. Further, the method includes identifying a second sub-flow of the multipath connection, based on information extracted from second sub-flow setup messages exchanged between the endpoints, at 720. Some mechanisms usable to identify one or more sub-flows are described in detail below. The method also includes creating a group of sub-flows related to the multipath connection and including the first and second sub-flows, at 730. Creating a group, which may be associated with a group identifier, makes it possible for the network operator to correlate traffic information related to the group.

[0043] Mechanisms usable by a network operator to identify MPTCP sub-flows and to encapsulate them (i.e., to create a group) are described in detail below. These mechanisms are transparent to the endpoints and do not require endpoints' intervention or participation so that, for example, service provided by the OTT via the MPTCP is not disrupted. The following mechanisms are based on inspecting fields of messages used to set up and operate the MPTCP. Thus, the information carried in these fields is extracted and used to correlate the sub-flows and by a different actor (i.e., the network operator, not the endpoints) than initially intended (i.e., these messages were designed for authentication and session management such as adding/removing sub-flows from the session).

[0044] Considering that the "single-homed device/client endpoint against single- homed server endpoinf is trivial, three more complex scenarios are discussed:

A. Plural address device/client endpoint (multi-homed) against a single address server endpoint (single-homed)

B. Plural address device/client endpoint (multi-homed) against plural address server endpoint (multi-homed) (generalization)

C. Single address device/client endpoint (single-homed) against plural address

server endpoint (multi-homed)

Here, it should be understood that "client and "server" terms are used only to indicate who initiates the connection and not a conventional service-related client/server relationship.

[0045] Figure 8 illustrates the messages exchanged during an MPTCP session in situation A in which the client/device endpoint 810 has two client/device addresses A1 and A2, while the server endpoint 820 includes only one server address B1. In this setup different DPIs, 830 and 840, are used for each access network (sub-flow) and a PC 850 coordinates the sub-flows. PEPs, 833 and 843, may be used to control traffic of the first and second sub-flow respectively, as discussed later. However, the method is usable with other setups in which, for example, a single DPI is located after the access networks and can inspect all traffic and coordinate the sub-flows. The use of a particular number of DPIs or coordination with a PC shown relative to the embodiments in Figures 6 and 8 are thus merely exemplary and, therefore, do not limit other embodiments. [0046] During a first phase, the TCP connection of a first sub-flow between address A1 and address B1 is set up. In the following description it is assumed that initiating a new TCP connection using MPTCP proceeds according to the rules described in RFC 6824 section 2.1. The procedure details are exemplary and are not intended to be limiting. The procedure is based on the existing 3-way handshake to set up an ordinary TCP connection. As part of the connection setup, endpoints exchange cryptographic information. RFC 6824 further defines that this information is unique per connection, and is sent in clear (i.e., unencrypted) during the TCP connection setup.

[0047] At 801 , DPI function 830 (which corresponds to DPI 633 in Figure 6) intercepts a TCP/IP SYN message sent from address A1 to address B1 , the message including option MP_CAPABLE with argument Key-A. DPI function 830 forwards this message to PC 850 (which corresponds to PC 650 in Figure 6). At 802, DPI function 830 intercepts a TCP/IP SYN ACK reply message sent from address B1 to address A1 , the message including option MP_CAPABLE with argument Key-B. Finally, at 803, DPI function 830 intercepts a TCP/IP ACK message sent from address A1 to address B1 , the message including option MP_CAPABLE and both Key-A and Key-B.

[0048] Further, during a second phase, the TCP connection of a second sub-flow between client/device address A2 and server address B1 is set up. Unlike in the case of setting up the first sub-flow when the messages included option MP_CAPABLE, the messages include option MP_JOIN when setting up the second sub-flow of the MPTCP, indicating that the sub-flow pertains to an existing connection.

[0049] At 804, DPI function 840 intercepts a TCP/IP SYN message sent from address A2 to address B1 , the message including option MP_JOIN with arguments Token-B and Random-A. DPI function 840 forwards this message to PC 850. Token-B is derived from Key-B using a cryptographic algorithm negotiated in the setup of the first sub- flow. The cryptographic algorithm does not use shared secrets or public key cryptography, being in fact a hashing function. Therefore, any host inspecting traffic (e.g., DPI 830 or PC 850) can obtain Token-B from Key-B (the same applies to obtaining Token-A from Key-A). Note that, due to the properties of the hashing algorithms, the reverse is not true (Key-B cannot be obtained from Token-B). Key-B is selected such that Token-B is unique within host B. If the hashing algorithm is SHA-1 (as in RFC 6824), then:

Token-B=SHA-1 (Key-B)

Token-A=SHA-1 (Key-A).

[0050] At 805, DPI function 840 intercepts a TCP/IP SYN ACK reply message sent from address B1 to address A2, the message including option MP_JOIN with arguments HMAC-B and Random-B.

[0051] According to RFC 6824, a Hash-based Message Authentication Code (which is a well-known cryptographic procedure that, again, does not require public key cryptography or the knowledge of a shared secret) is used to obtain HMAC-A and HMAC- B as follows:

HMAC-A = HMAC(Key=(Key-A+Key-B), Msg=(Random-A+Random-B)), and

HMAC-B - HMAC(Key=(Key-B+Key-A), Msg=(Random-B+Random-A)).

[0052] At 806, DPI function 840 intercepts a TCP/IP ACK message sent from address A2 to address B1 , the message including option MP_JOIN with argument HMAC-A. Another TCP/IP ACK message sent from address B1 to address A2 follows at 807.

[0053] In this context, DPI 830, which detects the MP_CAPABLE option, sends the 5-tuple of the first sub-flow (between A1 and B1), Key-A and Key-B to PC 850. Based on this information, PC 850 calculates Token-A and Token-B, and associates Key-A with Token-A and the first sub-flow.

[0054] Further DPI 840, which detects the MP_JOIN option, sends the 5-tuple of the second sub-flow (between A2 and B1) and Token-B to PC 850. Based on this information, PC 850 correlates Key-B with Token-B and the second sub-flow. PC 850 can then ascertain that the first sub-flow and the second sub-flow belong to the same MPTCP session. Specifically, since Key-B and Token-B are unique within host B, Key-B is sent to A1 from B1 in first sub-flow, Token-B=SHA-1 (Key-B), and Token-B is found in the second sub-flow to B1 , then the first sub-flow and the second sub-flow must belong to the same MPTCP session.

[0055] Furthermore, determining that the first sub-flow and the second sub-flow must belong to the same MPTCP session enables PC 850 to also determine that addresses A1 and A2 belong to the same host A. This conclusion may be obtained by the network operator in other ways, but if not known, this mechanism can derive the IP addresses assigned to a particular host from inspection of the MPTCP sub-flow setup messages.

[0056] Figure 9 illustrates the messages exchanged during an MPTCP session in situation B, in which the client/device endpoint 910 has two client/device addresses A1 and A2, and the server endpoint 920 has also two server addresses B1 and B2. Similar to Figure 8, the use of a particular number of DPIs or the coordination with a PC are merely exemplary and, therefore, do not limit other embodiments.

[0057] During a first phase, the TCP connection of a first sub-flow between address A1 and address B1 is set up in steps 901-903, similar to steps 801-803 described above. During a second phase, the TCP connection of a second sub-flow between client/device address A2 and server address B2 is set up in steps 904-907, similar to steps 804-807 described above.

[0058] In this situation, PC 950 cannot determine that addresses B1 and B2 are the same host B. Assume that host A communicates simultaneously to host C that has sent Key-C to host A, and Token-C=SHA-1(Key-C). Since host B and host C are different hosts picking their keys individually, there is a small chance that Token-B equals Token-C. The probability of such confusion occurring is so small it may be ignored.

[0059] The risk for incorrectly correlating two sub-flows can be lowered even more by examining the TCP header option "DSS" (Data Sequence Signal), which is a sequence number used on MPTCP level. Using this sequence number, the MPTCP stack can correctly combine payloads coming from different sub-flows such that an in-order delivery be achieved. For example, if the last data sequence number on the first sub-flow was X, when a second sub-flow is set up, if the first DSS option from that second sub-flow has a data sequence number smaller than X, then the sub-flows are not correlated.

[0060] Another way to lower the risk of incorrectly correlating two sub-flows is for DPI 930 to inspect yet another MPTCP option, the ADD_ADDR option. If in step 902, host B sends the option ADD_ADDR to inform host A that B2 is another address of host B, when host A later sets up a new sub-flow, DPI 930 will know that host B can be reached at either B1 or B2. Host A can select either of these addresses for the new sub-flow.

[0061] Upon identifying B2 to be a different address of the same Host B, DPI 930 sends the 5-tuple (including A2 and B2) and Token-B to PC 950. From all this information, PC 950 can ascertain that the first and second sub-flows belong to the same MPTCP session. Specifically, since Key-B and Token-B are unique within host B, Key-B is sent to A1 from B1 in the first sub-flow, Token-B=SHA-1 (Key-B), Token-B is found in the second sub-flow to B2, and then, in view of the above approaches to avoid potential confusion, there is enough certainty to say that B2 and B1 are addresses belonging to the same endpoint, then the first sub-flow and second sub-flow must belong to the same MPTCP session. Situation C is not detailed because most of the discussion above of situations A and B also applies to situation C.

[0062] Although the above scenarios discussed identifying and correlating a first and a second sub-flow of the same MPTCP, a third, fourth, etc., sub-flow may be identified as pertaining to the MPTCP and correlated in a manner similar to the way the second sub- flow was identified and correlated. Correlating sub-flows of the same MPTCP is important because traffic related to the MPTCP may then be transparently controlled by the network operator, without employing the endpoints. Looking back now to the method illustrated in Figure 7, creating the group of sub-flows related to the MPTCP at 730 makes it possible to apply mechanisms that enforce network's traffic policies on one or more of the sub-flows in the group.

[0063] Figure 10 illustrates the manner in which a policy controller, PC, 1050 makes policy decisions, and how these policy decisions are implemented according to an embodiment. As in Figure 6, a DPI function 1030 and a PEP 1033 operate along a first sub-flow, and a DPI function 1040 and a PEP 1043 operate along a second sub-flow belonging to the same MPTCP connection between endpoints 1010 and 1020. DPI functions 1030 and 1040 inspect the ongoing traffic. Upon detecting the first sub-flow, DPI 1030 informs PC 1050, and upon detecting the second sub-flow, DP1 1040 informs PC 1050. PC 1050 correlates the first and second sub-flows, mapping them to the MPTCP connection. Based on this correlation, PC 1050 makes policy decisions enforced by PEP 1033 for the first sub-flow and by PEP 1043 for the second sub-flow.

[0064] Policy decisions may be one or more of traffic steering, blocking,

downgrading, modify charging or reporting, etc. For example, if the access for the first sub-flow is LTE, and the access for the second sub-flow is WLAN, then PC 1050 may decide to prefer WLAN. The policy decision may be based on parameters like user subscription, pre-configured traffic routing rules, radio condition feedback, etc.

[0065] Once the policy decision has been made, PC 1050 sends rules to one or both PEPs, 1033 and 1043. The rules may include a description of the traffic on which the policy is to be enforced. Such description may be a list of packet n-tuples with wildcards describing the respective sub-flow.

[0066] One policy decision may be to downgrade sub-flow(s) in a session. PC 1050 may instruct PEP 1033 (or 1043) to lower the priority of the first (or the second) sub- flow within the MPTCP session (the sub-flows may be identified by their 5-tuple). The PC's decision may affect more than a single sub-flow. For example, a PC may decide (relative to a group of sub-flows with access on different types of networks) downgrading all sub-flows in a specific access network (e.g., LTE). This downgrading may be achieved, for example, if the PEP is a PCEF, and the PCEF sets up a bearer in the 3GPP access. Less traffic will then get through on that sub-flow in congestion situations, and given that the other sub-flows are on an access that is not congested, the MPTCP endpoints will automatically prefer the sub-flows on the other path(s) (access network), achieving the desired traffic steering/balancing transparently.

[0067] Implementing a downgrade could be achieved by changing the marking of the IP datagrams (e.g., Differentiated Services Code point, DSCP, if such a mechanism is used in the access networks), changing the priority on the radio (if the access network supports it) and/or others.

[0068] Another policy decision may be throttling one or more sub-flows. To implement such a decision, PC 1050 may instruct PEP 1033 (or 1043) to throttle a stream of packets of the traffic on the first (or second) sub-flow, to a specific maximum bandwidth. Such a throttling decision may affect one, several (e.g., all the sub-flows for a defined access type), or all the sub-flows.

[0069] Endpoints 1010 and 1020 detect the impact of this policy as the maximum available bandwidth in that sub-flow and channel additional traffic through one of the other sub-flows, achieving traffic steering/balancing without service disruption. A desired balance between utilization of both sub-flows can be obtained by managing the relative bandwidths.

[0070] Throttling is considered a transparent mechanism because the service is not interrupted, no additional cooperation from endpoints is requested (other than normal MPTCP balancing) and no sub-flow in the session is lost. [0071] Another policy decision may be blocking or resetting a sub-flow. PC 1050 may instruct PEP 1033 (or 1043) to block the first (or second) sub-flow in the session. All packets of the blocked sub-flow would then be discarded. Endpoints will detect this by not receiving packets (the endpoint which would have otherwise received the discarded packets) or TCP acknowledgements (the endpoint which submitted the discarded packets). The endpoints then schedule subsequent traffic on other sub-flows. If a PEP is a PCEF, then blocking traffic is possible with existing gating functionality. Examples of gating functionality include, but are not limited to: injecting upstream and downstream TCP segments with the RST flag set dropping all the packets in a 5-tuple, etc.

[0072] The effect of this blocking or resetting policy decision is considered semi- transparent because endpoints notice the blocking or resetting of one or more sub-flows, but the service will not be affected because other sub-flows in the session are used to convey it.

[0073] Yet another policy decision may forcefully implement traffic steering without the endpoints' collaboration. Each of the sub-flows of an MPTCP session is in itself a compliant TCP flow and, as such, implements known functionalities such as in-order delivery of payload, error control, congestion control, etc. As specified in RFC 675 published in 1974 and subsequent RFCs, these functionalities are based on the TCP header sequence and acknowledgment numbers.

[0074] MPCTP implements session level error control, congestion and in-order delivery of payload through equivalent numbers in the TCP options of the sub-flows. It is therefore possible for endpoints to apply state-of-the-art mechanisms for traffic injection to each of the sub-flows. Injecting payload to a TCP flow (or sub-flow in the case of MPTCP) requires, among other actions:

a) to append the injected payload to the TCP payload (after the header),

b) to adjust the sequence and acknowledgment numbers for all the TCP segments in the TCP flow (i.e., segment with the payload injected and all the subsequent segments to increase those numbers and make sure the client and the server recognize the injection), and

c) to recalculate the checksum of the segment containing the injection.

[0075] If for instance a PEP forwards all the sub-flows in an MPTCP session, the sub-flows having been identified as pertaining to the session, it is possible for the PEP to subtract payload from one sub-flow, and to inject that payload in a different sub-flow, thus achieving the desired steering/balancing. This mechanism is considered forceful steering since it does not require endpoints' collaboration. Unlike mechanisms relying on the endpoints choosing the sub-flow with the best available bandwidth to balance traffic, the network operator causes forceful steering by downgrading/upgrading, prioritizing or blocking sub-flows.

[0076] Forceful steering is considered transparent in the sense that all the sub- flows in the MPTCP session remain active and the service provided by the OTT remains unaltered, even though an endpoint does not receive the service traffic over the intended sub-flow but over another sub-flow chosen by the PEP (or TDF).

[0077] Assuming downstream traffic going from the server to the client and upstream traffic going from the client to the server, this mechanism can steer both downstream traffic to the client and upstream to the server. This mechanism cannot control on which sub-flow the traffic is directed, but can control on which sub-flow the traffic is received. To summarize, assuming a PEP has access to all the sub-flows in a session, upon reception of a downstream TCP segment on a sub-flow A, this PEP may, according to a policy decision that requires forceful steering, redirect a TCP segment on a sub-flow B of the same session by

1. removing the payload from the incoming TCP segment on sub-flow A

2. forwarding a new (injected) segment on sub-flow B with the volume of the payload added to the last known sequence number of sub-flow B (monitoring of sequence numbers on sub-flow B is required);

3. waiting for endpoint acknowledgement of receipt of the injected volume on sub-flow B, and forwarding that acknowledgement toward the other endpoint on sub-flow A where the acknowledgement number is increased by the volume of the payload subtracted from sub- flow A;

4. after 3,

• for every subsequent downstream segment on sub-flow A, decrease the sequence number by the volume of the payload subtracted from sub-flow A;

• for every subsequent upstream segment on sub-flow B, decrease the

acknowledgement number by the volume of the payload injected on sub-flow B;

• for every subsequent downstream segment on sub-flow B, increase the sequence number by the volume of the payload injected on sub-flow B; and

• for every subsequent upstream segment on sub-flow A, increase the

acknowledgement number by the volume of the payload injected on sub-flow B. [0078] Waiting for an upstream segment on sub-flow B to acknowledge receipt of the injected volume is necessary to cover packet loss on step 2 (injection of the volume from sub-flow A into sub-flow B). If the injected segment is lost, no increment/decrement is performed on any sub-flow after step 2. The remote endpoint will notice the traffic bss on sub-flow A (because volume is removed and sequence numbers decreased on sub- flow A), resending the segment and restarting the process.

[0079] Subtracting payload from segments on sub-flow A and injecting it to sub-flow B can be repeated for every segment on sub-flow A, achieving traffic balance or traffic steering. The volume for the payload of each segment subtracted/injected adds to the increase/decrease of sequence/acknowledgment numbers in each case. The same logic can be applied to upstream segments (device/client to server traffic). Acknowledgement and sequence numbers are symmetrical.

[0080] A PC 1100 configured to perform the above-described functionality may have the structure illustrated in Figure 11. PC 1100 includes a data processing unit 1102 having at least one processor (not shown) and connected to a memory 1104 (i.e., a non- transitory computer-readable medium configured to store executable codes and data), and an I/O interface 1106 configured to enable communication with DPI function(s) and PEP(s).

[0081] Data processing unit 1102 has:

• a first module, 1110, configured to identify a first sub-flow of a muttipath connection based on information extracted from first sub-flow setup messages exchanged between a first endpoint and a second endpoint via a first network device, • a second module 1120 configured to identify a second sub-flow of the multipath connection based on information extracted from second sub-flow setup messages exchanged between the first endpoint and the second endpoint via a second network device, and

• a third module 1130 configured to create a group of sub-flows related to the

multipath connection and including the first and second sub-flows.

[0082] It should be understood that this embodiment is illustrative and not intended to be limiting regarding the scope of identifying the first and/or second sub-flow(s). DPI function(s) that may be or not be performed by the controller detect that a message is an MPTCP sub-flow setup message, !f the DP! function is performed by another device than the controller, the device may extract relevant information and provide it to the controller or may forward a copy of the message to the controller. If the controller receives a copy of the message, it may then perform additional steps for identifying the first and second sub- flows (interpret keys, calculate tokens, etc.). Thus, the first and second modules being configured to identify sub-flows should be interpreted as covering a large spectrum of functionality from performing all the steps starting with inspecting the packets if DPIs are performed by the controller, to merely managing information provided by other network operator devices, which perform at least the DPI functions.

[0083] Data processing unit 1102 may further include:

• a fourth module, 1140, configured to receive first and second sub-flow setup

messages via interface 1106 from the network; • a fifth module, 1150, configured to include another sub-flow in the group of sub- flows upon identifying the sub-flow as related to the multipath connection based on information in additional sub-flow setup messages; and

• a sixth module, 1160 configured to generate and transmit traffic control

commands affecting traffic on at least one of the sub-flows in the group of sub- flows, to one or more policy enforcement points on one or more sub-flow routes through the network.

[0084] File Transfer Protocol (FTP) with MPTCP is an example illustrating the mechanisms explained above. If a user has a subscription to an over-the-top file backup service, the backup procedure is regularly run (e.g., once a day) and involves the transfer of large amounts of data. Such a backup session typically takes a relatively long time (e.g., about half an hour) and uses most of the upstream bandwidth. The network operator's DPI functions are configured to detect an ongoing backup. In this example, the backup service traffic includes multiple long-lasting FTP upload sessions. Each FTP session is a TCP session consisting of two MPTCP sub-flows, one sub-flow on access A and another sub-flow on access B. The DPIs have informed the PC of the ongoing backup and of the ongoing MPTCP sub-flows. Furthermore, the PC has a pre-configured policy that backup service traffic should preferably use access B. If, for example, the OTT schedules 10 Mbps via access A and no traffic via access B and the PC that receives regular input from the radio access networks is able to determine that access B is not congested, then the PC decides to limit the bandwidth of the MPTCP sub-flow over access A, effectively steering the traffic over to sub-flow B. The PC regularly re-evaluates the radio conditions of the accesses and may remove the bandwidth limitation on access A when access B becomes congested, effectively steering the traffic back to access A.

[0085] The described embodiments and other embodiments foreseeable based on this description provide network operators information and control over MPTCP sessions established outside the operated networks) the following advantages:

• improvements in reporting by identifying sub-flows pertaining to an MPTCP

session, e.g., using Packet Inspection techniques (either shallow, deep or heuristic);

• improvements in service classification and service awareness by assigning the same Service Identifier (sdf-id) to all sub-flows identified as pertaining to an MPTCP session (although only a subset of the MPTCP sub-flows may be identified);

• congestion management improvements by transparently downgrading (for instance by applying a restrictive QoS) one or more sub-flows in a specific access network (because of congestion, different transmission costs or others) while at the same time prioritizing (upgrading) one or more sub-flows on other access networks inviting the endpotnt(s) and the OTT to route traffic on the preferred access network;

• congestion management improvements by semi-transparently blocking (for

instance by injecting TCP reset packets that include a TCP RST flag) sub-flows on a specific access network, thus forcing the endpoint(s) and the OTT to route traffic according to the operator's preferences, while the service provided by the OTT continues undisrupted; and • general policy improvements by other policy or control actions that can benefit from the knowledge that a set of TCP flows (MPTCP sub-flows) are being correlated.

[0086] The disclosed embodiments methods and devices identify and control multipath traffic independent from endpoints thereof. It should be understood that this description is not intended to limit the invention. On the contrary, the exemplary embodiments are intended to cover alternatives, modifications and equivalents, which are included in the spirit and scope of the invention as defined by the appended claims.

Further, in the detailed description of the exemplary embodiments, numerous specific details are set forth in order to provide a comprehensive understanding of the claimed invention. However, one skilled in the art would understand that various embodiments may be practiced without such specific details.

[0087] As also will be appreciated by one skilled in the art, the exemplary embodiments may be embodied in a wireless communication device, a telecommunication network, as a method or in a computer program product. Accordingly, the exemplary embodiments may take the form of an entirely hardware embodiment or an embodiment combining hardware and software aspects. Further, the exemplary embodiments may take the form of a computer program product stored on a computer-readable storage medium having computer-readable instructions embodied in the medium. Any suitable computer-readable medium may be utilized, including hard disks, CD-ROMs, digital versatile disc (DVD), optical storage devices, or magnetic storage devices such as floppy disk or magnetic tape. Other non-limiting examples of computer-readable media include flash-type memories or other known memories. [0088] Although the features and elements of the present exemplary embodiments are described in the embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the embodiments or in various combinations with or without other features and elements disclosed herein. The methods or flow charts provided in the present application may be implemented in a computer program, software or firmware tangibly embodied in a computer-readable storage medium for execution by a specifically programmed computer or processor.

Claims

WHAT IS CLAIMED IS:

1. A method related to a multipath connection between a first endpoint (610) and a second endpoint (620), the method comprising:

identifying (710) a first sub-flow of the multipath connection based on information extracted from first sub-flow setup messages exchanged between the first endpoint and the second endpoint;

identifying (720) a second sub-flow of the multipath connection, based on information extracted from second sub-flow setup messages exchanged between the first endpoint and the second endpoint; and

creating (730) a group of sub-flows related to the multipath connection and including the first and second sub-flows.

2. The method of claim 1 , wherein the first messages are inspected to extract the information upon passing through a first network device and the second messages are inspected to extract the information upon passing through a second network device different from the first network device.

3. The method of claim 1 , further comprising:

including at least one third sub-flow in the group of sub-flows upon identifying the at least one third sub-flow as related to the multipath connection based on information extracted from additional sub-flow setup messages.

4. The method of claim 1 , controlling traffic on at least one sub-flow in the group of sub-flows, without employing the first endpoint and the second endpoint.

5. The method of claim 4, wherein the controlling of the traffic includes: changing traffic priority of the at least one of the sub-flows.

6. The method of claim 4, wherein the controlling of the traffic includes: altering bandwidth used by the at least one of the sub-flows.

7. The method of claim 4, wherein the controlling of the traffic includes: blocking the traffic on the at least one of the sub-flows.

8. The method of claim 7, wherein the blocking is achieved by inserting packets indicating the blocking into the traffic on the at least one of the sub-flows.

9. The method of claim 4, wherein the controlling of the traffic includes: redirecting packets from the at least one of the sub-flows to another one of the sub-flows in the group of sub-flows.

10. The method of claim 4, wherein the controlling of the traffic includes: sending a command to a policy enforcement point on a route of the at least one of the sub-flows, the command directing the policy enforcement point to alter a manner of forwarding the traffic on the at least one of the sub-flows.

11. The method of claim 4, wherein the controlling of the traffic includes: sending a command to a policy enforcement point on a route of the at least one of the sub-flows, the command directing the policy enforcement point to alter packets of the traffic on the at least one of the sub-flows.

12. The method of claim 1 , wherein the identifying and the creating operations are performed by a data processing unit (1102) including a processor.

13. The method of claim 1 , wherein at least one of the first endpoint and the second endpoint includes plural addresses.

14. The method of claim 1 , wherein the multipath connection is an Internet Engineering Task Force (IEFT) multipath Transmission Control Protocol (TCP) connection.

15. The method of claim 1 , wherein at least one of the first sub-flow and the second sub-flow is routed on a 3rd Generation Partnership Project, 3GPP, standardized network controlled by the network operator.

16. A controller (1100) of a network operator managing a network, comprising: a first module (1110) configured to identify a first sub-flow of a multipath connection based on information extracted from first sub-flow setup messages exchanged between a first endpoint and a second endpoint via a first network device; a second module (1120) configured to identify a second sub-flow of the multipath connection based on information extracted from second sub-flow setup messages exchanged between the first endpoint and the second endpoint via a second network device; and

a third module (1130) configured to create a group of sub-flows related to the multipath connection and including the first and second sub-flows.

17. The controller of claim 16, further comprising:

a fourth module configured to receive the first and the second sub-flow setup messages from deep packet inspection functions of the network.

18. The controller of claim 16, further comprising:

a fifth module configured to include at least one third sub-flow in the group of sub-flows upon identifying the at least one third sub-flow as related to the multipath connection based on information in additional sub-flow setup messages.

19. The controller of claim 16, further comprising:

a sixth module configured to generate and transmit traffic control commands affecting traffic on at least one of the sub-flows in the group of sub-flows, to one or more policy enforcement points on one or more sub-flow routes through the network.

20. The device of claim 19, wherein the traffic control commands do not employ the first endpoint and the second endpoint.

21. The controller of claim 19, wherein the traffic control commands request the one or more policy enforcement points to perform at least one of:

to change priority of traffic on the at least one of the sub-flows in the group of sub-flows,

to alter bandwidth used by the at least one of the sub-flows,

to block the traffic on the at least one of the sub-flows,

to redirect packets from the at least one of the sub-flows to another one of the sub-flows in the group of sub-flows;

to alter packets of the traffic on the at least one of the sub-flows; and

to alter a manner of forwarding the traffic on the at least one of the sub-flows.

22. A computer readable medium (1104) storing computer executable instructions, wherein the instructions, when executed by a computer, implement a method related to a multipath connection between a first endpoint and a second endpoint in a network, the method comprising: identifying (710) a first sub-flow of the multipath connection based on information extracted from first sub-flow setup messages exchanged between the first endpoint and the second endpoint;

23. The computer readable medium of claim 22, wherein the method further comprises:

24. The computer readable medium of claim 22, wherein the method further comprises:

controlling traffic on at least one sub-flow in the group of sub-flows without employing the first endpoint and the second endpoint.

25. The computer readable medium of claim 24, wherein the traffic on the at least one sub-flow is controlled by causing at least one of:

changing priority of the traffic on the at least one of the sub-flows; altering bandwidth used by the at least one of the sub-flows;

blocking the traffic on the at least one of the sub-flows;

redirecting packets from the at least one of the sub-flows to another one of the sub-flows in the group of sub-flows;

altering packets of the traffic on the at least one of the sub-flows; and altering a manner of forwarding the traffic on the at least one of the sub-flows.