LU92843B1

LU92843B1 - Network Management System

Info

Publication number: LU92843B1
Application number: LU92843A
Authority: LU
Inventors: Thomas Engel; Miroslaw Kantor; Gaston Ormazabal; Radu State
Original assignee: Univ Luxembourg
Priority date: 2015-10-06
Filing date: 2015-10-06
Publication date: 2017-05-02

Abstract

In a mobile computing network, a mobile computing device receives encapsulated packet information and identifies the information as belonging to 5 one or more flows. A network interface may be selected to receive the information for any one particular flow based on a set of criteria which includes network characteristics

Description

NETWORK MANAGEMENT SYSTEM

TECHNICAL FIELD

Embodiments of the invention relate to a network management system and, in particular, a network management system for mobile computing devices.

BACKGROUND

Modern smart phones have numerous network interfaces over which they can receive data. However, when switching from one interface to another, the entire network must be re-established. This can be particularly disruptive for applications such streaming video and sound where the switch can result in the stream having to be restarted.

Furthermore, the different networks corresponding to the different interfaces have very different characteristics. For example, wireless connectivity is often fast and cheap whereas connectivity via the cellular network can be slower and more costly.

Several approaches (e.g., MIPv4, MIPv6, HIP) have been proposed to address IP mobility problem. However, these architectures rely on the existence of central servers that anchor the IP address used by the mobile node (MN) and, thus, imply several limitations: a) sub-optimal routing: mobile nodes are anchored at a central entity that leads to artificially long data forwarding route paths causing supplementary delays; b) scalability problems: core networks are dimensioned to support peak data traffic; c) reliability: the central entity/core network is a single point of potential failure; d) lack of fine granularity of the mobility management service. Additionally, as the existing mobility management schemes with poor scalability are deployed in fixed network devices (e.g., 3GPP deploys ΡΜΙΡνβ in S-GW and P-GW), it is difficult to quickly update existing protocols, add new functions or introduce and implement a new mobility management protocol. M. Bonola, S. Salsano, "Per-application Mobility Management: Performance Evaluation of the UPMT Solution", 7th International Wireless Communications and Mobile Computing Conference, IWCMC 2011, 5-8 July 2011, Istanbul discloses the establishment of tunnels to assist in switching application-specific data flows. However, the disclosed device is unable to take into account network characteristics when switching interfaces.

SUMMARY OF THE INVENTION

An embodiment of the invention relates to a mobile computing device comprising: one or more applications; a plurality of network interfaces for connecting to corresponding networks and receiving packet information sent across said networks, wherein each of said interfaces is adapted to receive encapsulated packet information forming one or more flows, each flow being associated with a corresponding application; a network interface selector for selecting one of said plurality of network interfaces to establish a current network connection; a network selection criteria log for storing a plurality of criteria used when selecting a network, including flow-specific criteria; wherein said network interface selector selects one of said plurality of network interfaces based at least on the flow-specific criteria stored in said network selection criteria log.

Flow specific criteria may include network characteristics such as network type, available bandwidth, cost, availability as well as application-specific characteristics such as priority, timing information. Since embodiments of the invention are able to switch flow based on the criteria a correlation can be made between the application specifics and network characteristics. This allows the user to determine under what circumstances different interfaces can be used.

For this reason, and since the criteria may include system information such as available battery power, CPU load, available memory etc., a correlation between the flow characteristics and the available system resources can be made. This helps to ensure that the interface selection is optimised for the available resources.

The criteria may further comprise one or more of: application information, location information; cognitive geographical information; network information; security information; and system information.

The application information may include application identification, resource requirements, timing, display resolution, rendering quality, or any other application characteristics.

One or more of the criterion may be user-specified.

At least one criterion may have at least one parameter.

The encapsulated packet information may be transported via a software defined network.

The packet information may be defined by the Internet Protocol and transported according to the Transfer Connect Protocol.

The network interface selector may be adapted to select a new interface for a new flow.

The network interface selector may be adapted to store said encapsulated packet information in one or more application specific queues for later delivery.

The network interface selector may be adapted to block a flow.

The mobile computing device may further comprise a tunnel manager for managing one or more tunnels for said encapsulated packet information, wherein each tunnel corresponds to a flow.

Each of said tunnels may be established by mapping a virtual IP address to a physical IP address. A further embodiment of the invention extends to a method of routing data in a mobile computing device, the device comprising: one or more applications; a plurality of network interfaces for connecting to corresponding networks and receiving packet information sent across said networks, wherein each of said interfaces is adapted to receive encapsulated packet information forming one or more flows, each flow being associated with a corresponding application; a network interface selector for selecting one of said plurality of network interfaces to establish a current network connection; a network selection criteria log for storing a plurality of criteria used when selecting a network, including flow-specific criteria; said method comprising having said network interface selector select one of said plurality of network interfaces based at least on the flow-specific criteria stored in said network selection criteria log.

The method may further comprise the step of transporting the encapsulated packet information via a software defined network.

The method may further comprise the step of selecting a new interface for a new flow.

The method may further comprise the step of storing said encapsulated packet information in one or more application specific queues for later delivery.

The method may further comprise the step of blocking a flow.

It is to be realised that multiple flows may be established simultaneously. A further embodiment of the invention extends to a method of transporting encapsulated packet information across a network comprising the steps of: using a tunnel manager to establish one or more tunnels for said encapsulated packet information; receiving said encapsulated packet information at a mobile computing device; and routing said information in the mobile computing device as herein described; wherein each tunnel corresponds to a flow.

Each of said tunnels may be established by mapping a virtual IP address to a physical IP address.

DESCRIPTION OF ACCOMPANYING FIGURES

Embodiments of the invention are described with reference to the accompanying schematic diagrams where:

Figure 1 illustrates a mobile computing device according an embodiment of the invention; and

Figure 2 is a protocol sequence diagram of an operation of an embodiment of the invention.

DESCRIPTION OF EMBODIMENTS

Figure 1 illustrates a mobile computing device 10 according to an embodiment of the invention. The device 10 comprises a plurality of applications 12 which have been specifically implemented for embodiments of the invention and are here termed ‘context aware applications’. An Application Programming Interface (API) 32 facilitates information transfer to and from the applications 12.

Embodiments of the invention are also capable of accommodating legacy applications 28. A socket proxy 30 translates data addressing between the API 32 and the legacy applications 28 by intercepting socket system calls.

In a further embodiment, the applications 12 and legacy applications 28 are implemented in a plurality of Virtual Machine Interfaces (VMIs).

The API communicates with a policy manager 20 which is described in greater detail below.

The mobile computing device 10 further comprises a Media Independent Handover client (MIH client) 16 which monitors and provides interface information about available networks. In this embodiment, the MIH client 16 determines the presence or absence of each network. In addition, the MIH client 16 determines Media Information Service (MIS) information useful for handover decisions within a geographical area. In this embodiment the MIS information comprises: available bandwidth, the type of network and cost and is provided by MIS server 19.

The mobile computing device 10 utilises a Software Defined Network (SDN). By using an SDN, embodiments of the invention are able to encapsulate the network information and provide application-specific routing, without interfering with the legacy TCP/IP routing. Therefore, embodiments of the invention can be implemented on existing hardware. No hardware upgrades are required.

The mobile computing device 10 of Figure 1 further comprises an SDN monitoring agent 18 responsible for monitoring and collecting per-flow parameters. In this embodiment the per-flow parameters comprise a tally of the number of sent/received packets, drop count and port statistics.

The local policy manager 20 is responsible for calculating local handover decisions. As described below, the handover decisions may be based on the policies specified by the user defining a context, and taking into account network-, user-, mobile computing device-, VMI- (where applicable), and application-specific performance and security aspects. In this embodiment, the local policy manager 20 is incorporated into the mobile computing device 10. In alternate embodiments however, the policy manager, or portions thereof, are remote from the device 10. This is particularly useful where the local policy manager requires intensive computing resources, for example, where decryption may be required.’

The SDN controller 22 is responsible for inserting flow rules to Open vSwitch 24 (see below) following the handover decision determined by the local policy manager 20, creating the tunnels, and exchanging the information related to an interface selection with an SDN domain controller. In this embodiment, the SDN controller 22 is incorporated into the mobile computing device 10. However, in an alternate embodiment, the SDN controller is implemented at a remote server.

The Open vSwitch 24 of mobile computing device 10 is a software-implemented OpenFlow switch and is responsible for monitoring and collecting flow-related parameters, as well as executing flow access control actions (handovers) as determined by the local policy manager 20 and translated into flow rules by the SDN controller 22 and/or an SDN domain controller.

The device 10 comprises three networking interfaces 26A, 26B and 26C. Each interface allows the device 10 to connect to a corresponding network. Networks 54A and 54B corresponding to interfaces 26A and 26B are illustrated in Figure 1. In this embodiment, interface 26A is a WiFi interface, 26B is a cellular radio interface and 26C is an Ethernet interface.

However, in further embodiments different interfaces may be provided. It is to be realised that the device 10 is capable of communicating through more than one interface simultaneously.

Smart control middleware design

The policy manager 20 comprises the following components. A queue manager 70; a service sharing manager 72; a security manager 74; a system manager 76; a data store 78; an SDN parameter manager 80; a location manager 82; a cognitive geographical manager 84; a network manager 86; and a flow manager 88. Each of these components connects to a policy engine 90.

The location 82, cognitive geographical 84, and system managers 76, along with the data store 78 have been adapted to the needs of the proposed system. These components, along with the SDN parameter and flow managers, provide relevant inputs (described below) to the policy engine (PE) 90. The operation of the remaining components of the policy manager 20 are known in the art and their operation is not further discussed herein (see, for example, A. Singh, G. Ormazabal, H. Schulzrinne, Y. Zou, P. Thermos, and S. Addepalli, “Unified Heterogeneous Networking Design”, in Proc. of Principles, Systems and Applications on IP Telecommunications (IPTComm Ί3), ACM, New York, NY, USA).

The location manager 82 determines the location of the mobile computing device 10 in a known manner. The security manager 74 determines networks and devices access credentials and policies, and end-to-end communications public/private key pairs. The system manager 76 determines system parameters such as CPU utilisation levels, available CPU bandwidth and battery usage, along with hypervisor and VMIs’ parameters to enable application-specific usage constraints, such as maximum bandwidth limit or battery utilisation (when applicable). The network manager 86, based on the information from the MIH client 16, maintains all active network interfaces and provides this information to the PE 90. The cognitive geographical manager 84 determines and provides context-aware information to the PE 90, along with recommendations for flow handovers resulting from performed prediction based on the history and context data related to network and location activity.

The flow manager 88 communicates with the local SDN controller 22 to request for flow handover execution, based on the decision taken by the PE 90. The SDN parameter manager 80 is determining and providing flow-related information provided by the SDN monitoring agent 18. The data store 78 provides a structured key-value repository for each manager, respectively.

The mobile computing device communicates with a corresponding node (CN) 52 in the manner described below. The CN 52 comprises a network interface 66 which communicates with network 68.

Figure 1 further illustrates a wide area network 50 to which the networks 54A, 54B and 68 connect. The networks 50, 54A, 54B and 68 consists of a core SDN/NFV-enabled network infrastructure, a heterogeneous OpenFlow (OF)-enabled access network environment (including all types of access technologies, both fixed and wireless ones), the device 10 and the CN 52. Although only a single mobile computing device 10 is illustrated, many more similar devices may be supported by the network 50.

Each of networks 54A, 54B and 68 comprise several collaborating OF-enabled domains, each of which contains a corresponding SDN domain controller 56A, 56B and 56C processing the events within the domain. The instantiation of the domain can include, e.g., a network under the same administration, or an access network realized in a single access technology.

The network 50 further comprises a Mobility Control Node (MCN) 60 and a Media Information Service (MIS) 62 and a Monitoring and Analytics Engine 64.

The MCN 60 is responsible for managing mobile device connectivity information and supporting per-flow mobility in inter-domain environment. The MIS 62 provides information about the characteristics of networks available in the geographical area near to the location of the device 10.

The SDN domain controller 56 communicates: (1) with the local SDN controller 22 of mobile computing device 10 attached to the OF-enabled switches belonging to the controlled domain, to coordinate the policy enforcement schemes and handover execution; (2) with other SDN domain controllers, through east/westbound interface, to coordinate a path setup for flows between device 10 and CN 52, (3) with OF-enabled domain switches, to setup a path for flows between the device 10 and domain egress node towards the CN 52; and (4) with a mobility control node (MCN) 90, through north-bound interface, to coordinate location information on communicating devices for computing inter-domain network path for flows.

Monitoring system design

Embodiments of the invention provide an SDN-based monitoring system, enabling measurement and collection of data, which provide an input to the policy manager. The monitoring system uses SDN features (controller-based monitoring) to collect flow-related information, e.g., flow data rate, port statistics, etc. The existing monitoring capabilities of SDN are not sufficient for gathering data in a wireless environment. Thus, the Open vSwitch functionality is extended to enable monitoring and collecting flow-related wireless statistics (such as RSSI and drop count). These statistics provide additional input to the policy engine 90, responsible for taking network selection decisions.

Policy-based control middleware design

The proposed system design enables improving the quality of the mobile user’s experience, by providing fine-grained, context-aware network access control, using network-, and user-defined policies, which are dynamically applied on a per-application basis.

Policy vector definition

The information determined by the queue manager 70, service sharing manager 72, security manager 74, system manager 76, SDN parameter manager 80, location manager 82, cognitive geographical manager 84, network manager 86 and flow manager 88 is stored in the data store 78 in the form of a policy vector.

The policy vector is used for taking a flow handover decision which depends on a number of factors related to network, user, terminal, application, and flow requirements and constraints.

For example, the policy vector instantiation could include the following parameters: flow identity (which is linked to the source application and the destination application), bandwidth, latency, data budget, signal strength, cost, location and time of day. Some parameters can be defined in a certain range, if necessary, and not only as binary values.

The decision regarding the handover is performed by the policy engine 90 and the policies are defined according to a semantically configurable policy-specification language, and stored locally in the data store 78. Therefore, in embodiments of the invention, the data store 78 acts as a network selection criteria log.

Taking handover decision

For optimal network connectivity, the attributes defined in policy vectors are constantly monitored. In case any of the attributes’ values exceed a threshold, the relevant attribute managers trigger their control event inputs to the policy engine 90 for processing, and network control enforcement. Events may result in changes in the state and the transmission behaviour of the physical, data link, and logical link layers or be used to predict state changes of these layers. Due to the nature of the events, event notifications are generated asynchronously. After receiving network event, the policy engine 90 queries the MIH client 16 asking for information on available networks, taking into account the device 10 location provided by the location manager 82, which can be used for handover. Following the request, the MIH client 16 starts scanning a wireless spectrum (for example) and responds with a list of the available networks together with the wireless access link dynamic parameters (e.g., signal strength, link speed, etc.). The device 10 can also use its currently active interface to inquire MIS about other available access networks in a geographical region, thus removing the need for scanning. In response the MIS server 19 provides information on the candidate networks, including their types and operators associated with them, roaming agreements between different operators, the cost of the connection, network security and QoS capabilities, actual addresses of network access points, and transmission speed supported by the access points.

Based on the input from the MIH client 16 and associated attribute managers, the policy engine 90 takes the flow handover decision evaluating the defined policy vectors against a set of prescribed policies. There can be three possible policy evaluation outcomes: network interface change for a new flow or handover of an existing flow, packet storage in application specific queues (queue manager 70) for later delivery if no network interface is selected, or new flow blocking if no suitable network interface is available.

In case the policy engine 90 took decision to make the flow (or group of flows) handover, the decision is communicated to the flow manager 88, which, in turn, sends a request to the local SDN controller 22, which initiates the process of the flow handover execution to the indicated physical interface at the device 10 by using tunnelling mechanisms.

It is to be realised then that the policy manager 20 working together with the local SDN controller and the Open vSwitch act together as a network interface selector in embodiments of the invention.

Creating per-application flow entries

The local SDN controller 22, through SDN Flow Manager, creates per-application flow entries in a flow table (not illustrated in Figure 1 ). It is also responsible for modification and removal of flow entries. Flow entry determines an action which should be taken on the matched packets. Identification of the application’s flows (with their corresponding VMIs, where appropriate) is here based on the 5-tuple of the IP parameters of the packets (flow id, IP source, IP destination, layer 4 source port, layer 4 destination port) which are destined for, or sent through, the API. To determine the appropriate action, the integration bridge examines the flow table and cross-checks its known tunnel interfaces to determine which logical interface should be used for egress traffic to assure that it will be transmitted through a selected physical interface. After selecting the tunnel, a flow entry is inserted to the flow table, which keeps the binding between the flow identifier and tunnel identifier, and a data-path is installed. After setting up a data-path for the flow, the local SDN controller sends to the SDN domain controller a virtual IP address which generates packets belonging to the flow, source IP address of the tunnel, and flow identifier. The information is forwarded to the MCN 90, which updates the existing binding entry with the received data, created during the device’s 10 attachment process, adding also a binding entry lifetime.

Appendix

As mentioned, the network is established over an SDN and tunnels are provided for the flows. This is generally known in the art, but the following discussion is included here for completeness. It should be noted that this discussion applies to an embodiment with VMIs, but is equally applicable to an embodiment operating without VMIs.

END-TO-END NETWORK CONNECTIV-ITY

In this discussion, the device 10 of Figure 1 is referred to as a mobile terminal (MMT), which is OpenFlow-enabled (OF-MMT). It is assumed that both OF-MMT and CN have implemented the same device architecture, as presented in Figure 1. OF-MMT is equipped with at least two physical interfaces enabling connection through different access networks. End-to-end path establishment between OF-MMT and respective CN VMIs, requires the following four tasks: OF-MMT device network attachment, physical network connectivity set up between OF-MMT and CN physical interfaces’, tunnel establishment between OF-MMT and CN configured VTEPs, and per-application flow entry creation in OF-MMT and CN flow tables, respectively.

The tasks are described in detail below. SDN network attachment

The network side is expected to detect an OF-MMT device attachment, through any of OF-enabled switch’s physical interfaces. Identification of the attached OF-MMT physical interface may be based on OF-MMT’s MAC address. Upon attachment detection, the OF-enabled switch notifies the SDN domain controller about the event by sending Packet-in message. Then, SDN Flow Manager proceeds with the SDN device authentication process by sending an authentication request to the candidate network SDN domain controller. The candidate network SDN domain controller, based on MAC layer credential data from Security Manager, performs the pre-authentication procedure between OF-MMT device and its service provider. To this end, the SDN security infrastructure (e.g., based on RADIUS, DIAMETER, etc.) may be used. Upon successful device authentication, the OF-MMT is attached to the network. Then, OF-MMT’s local SDN controller initiates DHCP request for an IP address for that physical OF-MMT interface. The network authentication process proceeds, and, upon successful authentication, a routable IP address is assigned to this interface. The SDN domain controller creates the corresponding binding cache entry consisting of the OF-MMT’s physical interface assigned routable IP address, its MAC address, identifier of the first-hop OF-enabled switch to which the physical interface is attached, and a binding lifetime. Subsequently, it forwards the binding cache entry to the MCN. SDN network connectivity management

The network architecture consists of several collaborating domains, each of which contains at least one SDN domain controller, as presented in Figure 1. Each OF-MMT’s physical interface is assumed to have assigned a routable IP address in its home domain, i.e., the network of the initial attachment. SDN domain controllers are used to compute and setup a network path between the first hop of an OF-enabled switch to which OF- MMT’s physical interface is attached, and the OF-enabled switch to which CN is connected. In the proposed architecture, the MCN keeps the OF-MMT and CN devices current locations information, respectively. In case the communicating devices are located in different administrative domains, it is necessary to use the device location information from the MCN to compute the inter-domain path between OF-MMT and CN. The OF-MMT home SDN domain controller is not able to compute such an inter-domain path, since it does not have the location information outside of its own controlled domain. Thus, the SDN domain controller needs to communicate, through east/westbound interface, with the neighbouring SDN do-main controllers to compute and setup network path towards CN. For inter-domain route distribution, traditional routing protocols, such as BGP and OSPF, may be leveraged and extended.

Host-based mobility - tunnel establishment

To provide connectivity between OF-MMT and CN devices’ VMIs, a VMI virtual interface is assigned a virtual IP address to identify the OF-MMT’s VMI at the CN. Existing tunnelling mechanisms are used to encapsulate the VMI’s virtual IP address tunnel with the physical interface routable IP address, assigned during the network attachment process, thus mapping virtual IP address to physical IP address seamlessly. Thus, inside the tunnels, the packets generated by the VMI’s applications use this virtual IP address as a source IP address. This address remains constant independently of any IP readdressing of the underlying OF-MMT’s physical interfaces. As a result, the OF-MMT’s physical interface IP stack, used to process the native transport packets, is hidden to the VMI’s applications. Consequently, flows can be switched between different physical access transport networks seamlessly, without affecting any active TCP sessions sourced by VMI’s applications. The advantage of the applied overlay tunnelling approach results in full decoupling of the real OF-MMT physical interfaces and the VMIs virtual interfaces. In the proposed architecture, the local SDN controller, through Tunnel Manager, performs all the tunnel management operations between OF-MMT and CN. It sets up a tunnel from each active OF-MMT physical interface to the CN, identified by the tunnel ID (TID), and associated with a virtual stream between VMIs. The OF-MMT’s physical interface routable IP address can be used as a source IP address of the tunnel. Typical tunnelling protocols that can be used include VXLAN, GRE, and others.

Per-application flow table

The SDN Flow Manager in the local SDN controller creates and installs per-application flow entries in flow tables, as well as modifies and removes flow entries. A flow entry specifies an action to be taken on the matched packets. The action results from the PE handover decision for that flow, determining the OF-MMT’s physical interface to be used for egress traffic. The PE Flow Manager communicates the flow handover decision to the SDN Flow Manager, which selects the physical tunnel, creates a binding between the flow identifier FID and the tunnel identifier TID, and installs the flow entry in the flow table, identified by the respective FID. After assigning the flow to the application data-path, based on the VMI’s virtual IP address, the local SDN controller sends to the SDN domain controller an update with the VMI virtual IP address, the physical source routable IP address of the tunnel, and the flow identifier. This information is also forwarded to the MCN, which updates the existing binding entry, created during the OF-MMT’s attachment process, adding also a binding entry lifetime.

Data transfer

The process of forwarding packets belonging to the flow is realized by the Open vSwitch kernel module, following the installed flow entry. The packets comprising the flow are encapsulated in the selected tunnel, and sent through OF-MMT’s physical interface towards the corresponding VMI in CN. In the network, the packets are transmitted through the network path, established by SDN domain controllers with MCN support.

PER-FLOW MOBILITY SYSTEM

Since identification of VMI’s flows, on a per application basis, can be based on the virtual IP address 5-tuple parameters defined for each application (Flow ID, IP source, IP destination, layer 4 source port, layer 4 destination port) adding more discrete granularity, in the proposed architecture each application flow can be handled separately, and flow handovers can be performed independently.

Seamless per-flow mobility

The proposed per-flow mobility system assumes that flow handovers are initiated by the PE and executed by the OF-MMT’s local SDN controller, with additional support from network infrastructure. The local SDN controller manages the associations between flows and tunnels, called flow bindings, to select the proper access technology to send the egress packets. The network-level component is required to manage and maintain OF-MMT’s physical IP addresses, as well as to route physical packets in which the flow is tunnelled. To perform a flow handover, a modified MIH protocol supporting SDN is leveraged to provide the network information triggers to the PE to make the per-flow handover decision. Next, the decision is communicated to the Flow Manager, which in turn sends the request to the local SDN controller, for the flow handover execution to a new physical interface. Following the request, the local SDN controller performs two operations: it establishes a tunnel between OF-MMT and CN endpoints, which goes through the selected new physical interface, and makes the new flow-tunnel association; and updates the flow entry in the flow table, replacing the old flow with the new flow. As a consequence, the flow sourced by the VMI application is switched between different physical access networks seamlessly, without affecting the active TCP session over the virtual IP address stack, which remained unchanged.

Network-assisted flow mobility management

The MCN maintains updated identifier-to-location mapping binding entries (virtual IP address to physical IP address), and acts as a common rendezvous point, when both nodes (OF-MMT and CN) are moving concurrently. It also supports the computation of the network path between mobile devices located in different domains. When an OF-MMT moves across administrative domains, resulting in a new IP address acquisition for each new domain, the relevant identifier-to-location mapping in MCN binding cache needs to be updated. The task of the MCN, in cooperation with the first-hop OF-enabled switch, and the SDN domain controller, is to handle the conversion between the OF-MMT’s VMI virtual IP address, flow identifier, and its currently assigned routable IP address. Each OF-enabled switch notifies the SDN domain controller, upon attachment detection of an OF-MMT device, to keep a dynamically updated binding between flow identifiers and routable IP addresses. Thus, when an OF-MMT moves to a new domain, the new routable IP address is assigned to the relevant physical interface. Based on the existing mapping, the SDN domain controllers communicate with each other (through east/westbound interfaces), and with the MCN (through northbound interface) to coordinate the setup of the new network path between the new OF-MMT location and CN, in which the application flow will be encapsulated. The binding update protocol is currently not specified, and is the subject for further research.

Exemplary flow sequence for per-flow mobility management system

The flow sequence below describes in detail the steps to establish end-to-end network connectivity between OF-MMT and CN devices’ VMIs for an LTE network, followed by the PE initiated flow handover to a Wi-Fi network. Portions of this flow sequence are illustrated in Figure 2.

1. The OF-MMT is assumed to be initially connected to an LTE

network, and an IP address has been obtained in a secure manner. The CN has implemented the same device architecture as the OF-MMT, and VMIs have been assigned the corresponding virtual IP addresses. 2. The virtual IP address, associated with the VMI’s virtual interface, identifies the OF-MMT’s VMI at the CN, regardless of the particular tunnel through which the traffic is received. 3. The VMI’s generated packets for each application are identified by the Flow ID based on the 5-tuple of the virtual IP parameters (Flow ID, IP source, IP destination, layer 4 source port, layer 4 destination port), affording a fine-grained level of granularity on a per application basis. 4. The local SDN controller, through Tunnel Manager, sets up a tunnel, identified by the tunnel ID (TID), from the OF-MMT’s LTE physical interface to the CN. The OF-MMT’s LTE interface routable IP address is used as a source address of the tunnel. 5. A network path between the routable IP addresses of the OF-MMT’s LTE interface and CN is established. Two different procedures can be executed, depending on the location of CN: • If the routable IP address of CN’s physical interface is in the same domain, the intra-domain path setup procedure is applied: - The LTE network SDN domain controller computes the network path between OF-MMT’s LTE interface and CN. - The LTE network SDN domain controller sets up network path installing the flow rules in the OF-enabled switches. • If the IP address of CN’s physical interface is in a different domain, the inter-domain path setup procedure is performed: - The LTE network SDN domain controller queries MCN for CN location information. - The MCN responds with the ordered set of SDN domain controllers managing the domains towards CN. - The LTE network SDN domain controller communicates with the first SDN domain controller on the list through east/westbound interface to coordinate setting up the network path towards CN. - The process from step above is repeated until the complete end-to-end network path between OF-MMT and CN is established. 6. The SDN Flow Manager makes a binding between the flow and the newly established tunnel by creating and installing a flow entry in the flow table at the Open vSwitch. 7. The local SDN controller notifies the LTE network SDN domain controller about the just created flow-tunnel association. The notification update includes: VMI’s virtual IP address, the physical source IP address of the tunnel, and the flow identifier. 8. The LTE network SDN domain controller, which keeps an existing binding entry, created during OF-MMT’s LTE interface attachment process, is now updated with the flow-tunnel association. 9. The LTE network SDN domain controller also forwards the same notification update on the flow-tunnel association to the MCN. 10. The process of forwarding VMI’s application packets is realized by the Open vSwitch kernel module, following the installed flow data-path: • The packets comprising the VMI’s flow are encapsulated and transmitted through the selected tunnel, and consequently through the OF-MMT’s LTE physical interface towards the corresponding VMI in CN. • In the native transport network the packets are transmitted through the native network path between OF-MMT and CN, established by SDN domain controllers with MCN support. 11. The PE is constantly monitoring the parameters from the various managers, as defined in application-specific policy-vectors, stored in the data store. In this example one of the defined attributes (e.g., received radio signal power) falls below the configured predefined threshold.

The binding entry consists of an assigned routable IP address, MAC address of LTE’s physical interface, and OF-enabled switch identifier, along with a physical port to which OF-MMT’s LTE interface is attached. 12. The PE queries MIH client asking for information on nearby networks, taking into account the OF-MMT’s location provided by the location manager. MIH client starts scanning wireless spectrum and responds with a list of the available networks. Additional wireless access link dynamic parameters such as link speed, network type, connection cost, network security and QoS capabilities, may be also provided if MIS is enabled. 13. The PE queries also other attribute managers, e.g., SDN Parameter Manager for flow-related statistics, System Manager for OF-MMT and VMI’s system performance parameters, etc. 14. The PE evaluates the policy vector against the defined policies and takes decision for the flow handover execution to a selected candidate

Wi-Fi network. 15. The PE flow handover decision is communicated to the PE Flow

Manager. 16. The PE Flow Manager triggers the local SDN controller to start OF-MMT device attachment procedure to the candidate Wi-Fi SDN network.

17. The local SDN controller initiates the SDN authentication phase by sending an authentication request to the candidate Wi-Fi network SDN domain controller. Upon successful OF-MMT device authentication, OF-MMT is attached to the Wi-Fi SDN network.

18. The local SDN controller initiates DHCP request for an IP address from the candidate Wi-Fi network. 19. The DHCP request is intercepted by the candidate Wi-Fi network SDN domain controller, which forwards it to the network authenticator. The network authenticator, in turn, requests Wi-Fi network WPA credentials (user name and password) which are supplied by OF-MMT’s Security Manager. 20. Upon successful network authentication, the candidate Wi-Fi network SDN domain controller forwards the re-quest to DHCP server which assigns a routable IP address to the OF-MMT’s Wi-Fi physical interface. 21. A new binding entry is created in the candidate Wi-Fi network SDN domain controller including the Wi-Fi’s physical interface MAC address, and the assigned IP address, along with an OF-enabled switch identifier, and a Wi-Fi interface port of attachment. 22. The local SDN controller, through the tunnel manager, creates a Wi-Fi originated tunnel, going through the OF-MMT’s Wi-Fi physical interface, encapsulating the virtual IP address, associated with VMI’s virtual interface (identifying the OF-MMT’s VMI at the CN, once again regardless of the particular tunnel through which the traffic is received). 23. The SDN Flow Manager creates an association between the WiFi originated tunnel and a new Wi-Fi flow. 24. The local SDN controller sends update, to the Wi-Fi network SDN domain controller notifying the just created association between the WiFi originated tunnel and the flow. 25. The Wi-Fi network SDN domain controller also forwards the notification update on the new flow-tunnel association to the MCN. 26. Once the new Wi-Fi flow-tunnel association is created, the PE Flow Manager sends the request for the flow handover execution to the local SDN controller. 27. The OF-MMT’s SDN Flow Manager executes the flow switching from the LTE originated flow to the new Wi-Fi originated flow just by updating the existing flow entry with the new Wi-Fi flow. 28. The virtual IP address encapsulated packets comprising the flow start transmission through the selected Wi-Fi originated tunnel, egressing from the OF-MMT’s Wi-Fi physical interface towards the corresponding VMI in CN. 29. The flow has been switched between LTE and Wi-Fi networks, but since the virtual IP address identifying the OF-MMT’s VMI at the corresponding CN’s VMI has remained unchanged, the active TCP session sourced by the VMI’s application has not been affected. 30. Since the VMI’s flow identification is based on the 5-tuple (Flow ID, IP source, IP destination, layer 4 source port, layer 4 destination port), the association of sub-flows (ports) with specific applications achieves a high level of handover granularity. This affords the capability of switching single flows, group of flows, and individually selected flows.

Claims

1. Mobile Computereinrichtung, Folgendes umfassend: eine oder mehrere Anwendungen; eine Vielzahl von Netzschnittstellen zum Anschließen an entsprechende Netze und zum Empfangen von Paketinformation, die über die Netze gesendet wird, worin jede der Schnittstellen dazu angepasst ist, eingekapselte Paketinformation zu empfangen, die einen oder mehrere Flüsse formt, wobei jeder Fluss mit einer entsprechenden Anwendung assoziiert ist; einen Netzschnittstellen-Selektor zum Auswählen einer der Vielzahl von Netzschnittstellen, um eine gegenwärtige Netz Verbindung aufzubauen; ein Protokoll für Netzauswahlkriterien zum Speichern einer Vielzahl von Kriterien, die verwendet werden, wenn ein Netz ausgewählt wird, einschließlich flussspezifischer Kriterien; worin der Netzschnittstellen-Selektor eine der Vielzahl von Netzschnittstellen auf der Basis mindestens der flussspezifischen Kriterien auswählt, die im Protokoll für Netzauswahlkriterien gespeichert sind.A mobile computing device, comprising: one or more applications; a plurality of network interfaces for connecting to respective networks and for receiving packet information sent over the networks, wherein each of the interfaces is adapted to receive encapsulated packet information forming one or more flows, each flow associated with a respective application is; a network interface selector for selecting one of the plurality of network interfaces to establish a current network connection; a network selection criteria protocol for storing a plurality of criteria used when selecting a network, including flow-specific criteria; wherein the network interface selector selects one of the plurality of network interfaces based on at least the flow-specific criteria stored in the network selection criteria protocol.

2. Mobile Computereinrichtung nach Anspruch 1, worin die Kriterien außerdem eine oder mehrere von Folgenden umfassen: Anwendungsinformation, Standortinformation, kognitive geographische Information, Netzinformation, Sicherheitsinformation und S y steminformation.2. The mobile computing device of claim 1, wherein the criteria further comprises one or more of: application information, location information, cognitive geographic information, network information, security information, and system information.

3. Mobile Computereinrichtung nach Anspruch 1 oder Anspruch 2, worin die Kriterien mindestens ein benutzerspezifisches Kriterium einschließen.3. Mobile computing device according to claim 1 or claim 2, wherein the criteria include at least one user-specific criterion.

4. Mobile Computereinrichtung nach einem der vorhergehenden Ansprüche, worin die Kriterien ein Kriterium einschließen, das mindestens einen Parameter hat.A mobile computing device according to any one of the preceding claims, wherein the criteria include a criterion having at least one parameter.

5. Mobile Computereinrichtung nach einem der vorhergehenden Ansprüche, worin die eingekapselte Paketinformation über ein softwaredefiniertes Netz transportiert wird.A mobile computing device as claimed in any one of the preceding claims, wherein the encapsulated packet information is transported over a software defined network.

6. Mobile Computereinrichtung nach einem vorhergehenden Anspruch, worin die Paketinformation durch das Intemetprotokoll definiert ist und gemäß dem Übertragungsverbindungsprotokoll (TCP) transportiert wird.A mobile computing device as claimed in any preceding claim, wherein the packet information is defined by the internet protocol and carried according to the communication link protocol (TCP).

7. Mobile Computereinrichtung nach einem vorhergehenden Anspruch, worin der Netzschnittstellen-Selektor dazu angepasst ist, eine neue Schnittstelle für einen neuen Fluss auszuwählen.The mobile computing device of any preceding claim, wherein the network interface selector is adapted to select a new interface for a new flow.

8. Mobile Computereinrichtung nach einem vorhergehenden Anspruch, worin der Netzschnittstellen-Selektor dazu angepasst ist, die eingekapselte Paketinformation in eine oder mehrere anwendungsspezifische Warteschlangen zur späteren Übermittlung zu speichern.A mobile computing device according to any preceding claim, wherein the network interface selector is adapted to store the encapsulated packet information in one or more application specific queues for later transmission.

9. Mobile Computereinrichtung nach einem der vorhergehenden Ansprüche, worin der Netzschnittstellen-Selektor dazu angepasst ist, einen Fluss zu blockieren.The mobile computing device of any of the preceding claims, wherein the network interface selector is adapted to block a flow.

10. Mobile Computereinrichtung nach einem der vorhergehenden Ansprüche, außerdem einen Tunnel-Manager umfassend, um einen oder mehrere Tunnel für die eingekapselte Paketinformation zu verwalten, worin jeder Tunnel einem Fluss entspricht.The mobile computing device of any one of the preceding claims, further comprising a tunnel manager for managing one or more tunnels for the encapsulated packet information, wherein each tunnel corresponds to a flow.

11. Mobile Computereinrichtung nach Anspruch 10, worin jeder der Tunnel durch Abbilden einer virtuellen IP-Adresse auf eine physikalische IP-Adresse aufgebaut wird.The mobile computing device of claim 10, wherein each of the tunnels is constructed by mapping a virtual IP address to a physical IP address.

12. Verfahren zum Routen von Daten in einer mobilen Computereinrichtung, wobei die Einrichtung umfasst: eine oder mehre Anwendungen; eine Vielzahl von Netzschnittstellen zum Anschließen an entsprechende Netze und zum Empfangen von Paketinformationen, die über die Netze gesendet werden, worin jede der Schnittstellen dazu angepasst ist, eingekapselte Paketinformation zu empfangen, die einen oder mehrere Flüsse formt, wobei jeder Fluss mit einer entsprechenden Anwendung assoziiert ist; einen Netzschnittstellen-Selektor zum Auswählen von einer der Vielzahl von Netzschnittstellen, um eine gegenwärtige Netzverbindung aufzubauen; ein Protokoll für Netzauswahlkriterien zum Speichern einer Vielzahl von Kriterien, die verwendet werden, wenn ein Netz ausgewählt wird, einschließlich flussspezifischer Kriterien; wobei das Verfahren den Netzschnittstellen-Selektor eine der Vielzahl von Netzschnittstellen auswählen lässt, mindestens auf den im Protokoll für Netzauswahlkriterien gespeicherten flussspezifischen Kriterien basierend.12. A method of routing data in a mobile computing device, the device comprising: one or more applications; a plurality of network interfaces for connecting to respective networks and for receiving packet information sent over the networks, wherein each of the interfaces is adapted to receive encapsulated packet information forming one or more flows, each flow associated with a respective application is; a network interface selector for selecting one of the plurality of network interfaces to establish a current network connection; a network selection criteria protocol for storing a plurality of criteria used when selecting a network, including flow-specific criteria; the method having the network interface selector select one of the plurality of network interfaces based at least on the flow-specific criteria stored in the network selection criteria protocol.

13. Verfahren nach Anspruch 12, worin die Kriterien außerdem eine oder mehrere von Folgenden umfassen: Anwendungsinformation, Standortinformation, kognitive geographische Information, Netzinformation, Sicherheitsinformation und Systeminformation.13. The method of claim 12, wherein the criteria further comprises one or more of: application information, location information, cognitive geographic information, network information, security information, and system information.

14. Verfahren nach Anspruch 12 oder Anspruch 13, worin die Kriterien mindestens ein benutzerspezifiziertes Kriterium einschließen.14. The method of claim 12 or claim 13, wherein the criteria include at least one user-specified criterion.

15. Verfahren nach einem der Ansprüche 12 bis 14, worin die Kriterien ein Kriterium mit mindestens einem Parameter einschließen.15. The method of claim 12, wherein the criteria include a criterion with at least one parameter.

16. Verfahren nach einem der Ansprüche 12 bis 15, worin die eingekapselte Paketinformation über ein softwaredefiniertes Netz transportiert wird.The method of any one of claims 12 to 15, wherein the encapsulated packet information is transported over a software defined network.

17. Verfahren nach einem der Ansprüche 12 bis 16, worin die Paketinformation durch das Intemetprotokoll definiert ist und gemäß dem Übertragungsverbindungsprotokoll (TCP) transportiert wird.A method according to any one of claims 12 to 16, wherein the packet information is defined by the internet protocol and carried according to the communication link protocol (TCP).

18. Verfahren nach einem der Ansprüche 12 bis 17, außerdem den Schritt des Auswählens einer neuen Schnittstelle für einen neuen Fluss umfassend.The method of any one of claims 12 to 17, further comprising the step of selecting a new interface for a new flow.

19. Verfahren nach einem der Ansprüche 12 bis 18, außerdem den Schritt des Speichems der eingekapselten Paketinformation in eine oder mehrere anwendungsspezifische Warteschlangen zur späteren Übermittlung umfassend.The method of any of claims 12 to 18, further comprising the step of storing the encapsulated packet information in one or more application-specific queues for later transmission.

20. Verfahren nach einem der Ansprüche 12 bis 19, außerdem den Schritt des Blockierens eines Flusses umfassend.The method of any one of claims 12 to 19, further comprising the step of blocking a flow.

21. Verfahren zum Transportieren von eingekapselter Paketinformation über ein Netz, folgende Schritte umfassend: Verwenden eines Tunnel-Managers zum Aufbauen eines oder mehrerer Tunnel für die eingekapselte Paketinformation; Empfangen der eingekapselten Paketinformation an einer mobilen Computereinrichtung; und Routen der Information in der mobilen Computereinrichtung gemäß einem der Ansprüche 12 bis 20; worin jeder Tunnel einem Fluss entspricht.21. A method for transporting encapsulated packet information over a network, comprising the steps of: using a tunnel manager to establish one or more tunnels for the encapsulated packet information; Receiving the encapsulated packet information at a mobile computing device; and routing the information in the mobile computing device according to one of claims 12 to 20; where each tunnel corresponds to a river.

22. Verfahren nach Anspruch 21, worin jeder der Tunnel durch Abbilden einer virtuellen IP-Adresse auf eine physikalische IP-Adresse aufgebaut wird.22. The method of claim 21, wherein each of the tunnels is established by mapping a virtual IP address to a physical IP address.