Patent Description:
Networking architectures have grown increasingly complex in communications environments, particularly mobile wireless environments. For example, network providers have developed architectures in which a communication network can include both 3rd Generation Partnership Project networks, such as Long Term Evolution (LTE) networks, and wireless local area networks (WLANs), such as Wi-Fi, can each be accessed by user equipment (UE) having multi-mode communication capabilities. 3GPP Release <NUM> (Rel-<NUM>) Technical Specifications define several integrated LTE-WLAN interworking architectures including LTE-WLAN Aggregation (LWA), LTE WLAN Radio Level Integration with Internet Protocol Security (IPSec) Tunnel (LWIP), and Radio Access Network (RAN) Controlled LTE-WLAN Interworking (RCLWI). Currently, LWIP is defined as using a bearer switch to route IP flows between LTE and WLAN communication links, which causes LWIP interworking architectures to be at a disadvantage over LWA interworking architectures that provide for aggregating IP flows over both LTE and WLAN links. Accordingly, there are significant challenges in aggregating IP flows over LTE and WLAN links for LWIP interworking architectures.

<CIT> describes a method of handing off between a cellular network and a Wi-Fi network. A cellular base station of the cellular network is caused to collect information related to the cellular network. A Wi-Fi access point of the Wi-Fi network is caused to collect information related to the Wi-Fi network, wherein the cellular base station and the Wi-Fi access point are co-located. The information related to the cellular network and the information related to the Wi-Fi network are used collectively for determining whether to handoff traffic of a user equipment from a cellular air interface of the cellular network to a Wi-Fi air interface of the Wi-Fi network, or vice versa.

Shankar et al describes the performance of loose coupling, tight coupling and hybrid coupling interworking architectures in terms of metrics like throughput, media access delay and load through simulation, using OPNET <NUM> in "<NPL>. <CIT> refers to methods for implementing a converged gateway and an architecture associated with this gateway, by providing data segregation based on criteria that may be specified in an operator-provided policy using a technique similar to Deep Packet Inspection and a policy-based assignment with flow mobility provided by an IP Flow Mobility.

A method is provided and includes
determining a first routing metric associated with a first communication network, wherein the first routing metric identifies a capability of the first communication network to handle an Internet Protocol (IP) flow for a user equipment (UE); determining a second routing metric associated with a second communication network, wherein the second routing metric identifies a capability of the second communication network to handle the IP flow for the UE and wherein the second routing metric is different from the first routing metric; and routing the IP flow for the UE using the first communication network or the second communication network based, at least in part, on the first routing metric and the second routing metric.

Determining the first routing metric can include at least one of: determining at least one of uplink throughput, uplink signal strength information, and uplink signal quality information for the UE for the first communication network; determining at least one of downlink throughput, downlink signal strength information, and downlink signal quality information for the UE for the first communication network; and determining a load associated with the first communication network. Determining the second routing metric can include at least one of: determining at least one of uplink throughput, uplink signal strength information, and uplink signal quality information for the UE for the second communication network; determining at least one of downlink throughput, downlink signal strength information, and downlink signal quality information for the UE for the second communication network; and determining at least one of a load and a channel utilization associated with the second communication network.

In some cases routing the IP flow for the UE can include: calculating a first normalized routing metric based on the first routing metric divided by a sum of the first routing metric and the second routing metric; calculating a second normalized routing metric based on the second routing metric divided by the sum of the first routing metric and the second routing metric; setting at least one threshold value based on the larger of the first normalized routing metric or the second normalized routing metric; and calculating a hash of an IP flow tuple value associated with the IP flow for the UE. In some cases, the routing can further include: selecting either the first communication network or the second communication network to receive the IP flow based on a comparison between the hash of the IP flow tuple value and the at least one threshold value; and routing the IP flow toward a Radio Frequency (RF) communication node of the first communication network or toward a RF communication node of the second communication network based on the selecting.

In some cases, the first communication network can be a 3rd Generation Partnership Project (3GPP) network and the second communication network can be a wireless local area network (WLAN) comprising an Internet Protocol (IP) Security Gateway. In some instances, the method can be performed by unequal cost multipath (UCMP) routing logic configured for a Radio Access Network (RAN), the RAN comprising a plurality of 3GPP Radio Frequency (RF) communication nodes and a plurality of WLAN RF communication nodes. In some instances, the UCMP routing logic can be configured for each of the plurality of 3GPP RF communication nodes. In other instances, the UCMP routing logic can be configured external to the plurality of 3GPP RF communication nodes.

Turning to <FIG> is a simplified block diagram illustrating a communication system <NUM> to facilitate unequal cost multipath (UCMP) routing in a network environment according to one embodiment of the present disclosure. In one embodiment, the configuration illustrated in <FIG> may be tied to a Wireless Local Area Network (WLAN) and 3rd Generation Partnership Project (3GPP) architecture such as, for example, an Evolved-Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN). The E-UTRAN architecture, generally referred to as 4th Generation (<NUM>)/Long Term Evolution (LTE) architecture, can interface with an Evolved Packet System (EPS) core, generally referred to as the Evolved Packet Core (EPC). Typically, E-UTRA is described in reference to the air-interface for LTE radio access. Alternatively, the depicted architecture can be applicable to other environments equally such as, for example, 5th Generation (<NUM>) architectures and/or virtualized architectures such as, for example, a virtualized RAN (vRAN) architecture.

3GPP Technical Specifications, such as, for example, 3GPP Release <NUM> (Rel-<NUM>), define interworking between LTE access networks and WLAN access networks for different interworking architectures including LTE-WLAN Aggregation (LWA), LTE WLAN Radio Level Integration with Internet Protocol Security (IPSec) Tunnel (LWIP), and Radio Access Network (RAN) Controlled LTE-WLAN Interworking (RCLWI). In one embodiment, the configuration of communication system <NUM> can represent a LWIP interworking architecture.

As referred to herein in this Specification, the term 'plane' can refer to a separation of traffic that can traverse a network. Three planes can typically be found in communication networks including: a data-plane, a control-plane and a management-plane. The data-plane typically carries user traffic, while the control-plane typically carries signaling traffic used to provide routing information for user traffic and the management-plane, a subset of the control plane, typically carries administrative traffic. As referred to herein in this Specification, the terms 'user-plane', 'data-plane' and 'user data-plane' can be used interchangeably.

As referred to herein in this Specification, the terms 'virtual machine', 'virtualized network function' and 'virtualized network functionality' can encompass an emulation of a computer system and/or computing platform operating based on the computer architecture and functions of a real or hypothetical computer, with particular embodiments involving specialized hardware, software, or a combination of both. In various embodiments, a virtualized network function (VNF), a virtual machine (VM), a virtualized network function component (VNFC), virtualized functionality and/or any virtualized network controller, element, module, aggregator, combinations thereof or the like as described herein may execute via a hypervisor-based virtualization or a container-based virtualization of a server (e.g., blade server, rack server, stand-alone server) using the server's hardware (e.g., processor and memory element) and/or operating system for a given virtualized network environment. In some embodiments, a Physical Network Function (PNF) may be referenced. A PNF is typically associated with a hardware radio head, which can be configured with one or more transmitters and receivers (and other associated hardware and/or software functionality) to facilitate over-the-air (OTA) Radio Frequency (RF) communications.

The example architecture of <FIG> for communication system <NUM> includes a user operating user equipment (UE) <NUM>, a WLAN access network <NUM>, a 3GPP access network <NUM>, an Evolved Packet Core (EPC) <NUM> and one or more packet data network(s) <NUM>. WLAN access network <NUM> can include a WLAN communication node <NUM>, a WLAN controller <NUM> and a LWIP Security Gateway (SeGW) <NUM>. 3GPP access network can include a 3GPP communication node <NUM>, which can be configured with a protocol stack <NUM> and a LWIP controller <NUM>. LWIP controller <NUM> can be configured with UCMP logic <NUM>. EPC <NUM> can include a Mobility Management Entity (MME) <NUM>, a serving gateway (SGW) <NUM> and a packet data network (PDN) gateway (PGW) <NUM>.

UE <NUM> can interface with each respective WLAN communication node <NUM> and/or 3GPP communication node <NUM> simultaneously or separately via a respective OTA RF communication link with each respective node <NUM>, <NUM>. The communication link between UE <NUM> and 3GPP communication node <NUM> is typically referred to as a 'Uu' interface. The communication link between UE <NUM> and WLAN communication node <NUM> is typically referred to as a Wireless Medium (WM) interface. For 3GPP communication node <NUM>, protocol stack <NUM> can interface with LWIP controller <NUM> including UCMP logic <NUM> and LWIP controller <NUM> can further interface with MME <NUM> and SGW <NUM> of EPC <NUM>. Within EPC <NUM>, MME <NUM> can further interface with SGW <NUM>, which can further interface with PGW <NUM>. PGW <NUM> can further interface with one or more packet data network(s) <NUM>. For WLAN access network <NUM>, WLAN communication node <NUM> can interface with WLAN controller <NUM>, which can further interface with LWIP SeGW <NUM>. LWIP SeGW <NUM> can further interface with LWIP controller <NUM> via an interface typically referred to as an 'Xw' interface.

Each of the elements of <FIG> may couple to one another through simple interfaces or through any other suitable connection (wired or wireless), which provides a viable pathway for network communications. As referred to herein, a physical (wired or wireless) interconnection or interface can refer to an interconnection of one element or node with one or more other element(s), while a logical interconnection or interface can refer to communications, interactions and/or operations of elements with each other, which can be directly or indirectly interconnected, in a network environment.

Additionally, any one or more of these elements may be combined or removed from the architecture based on particular configuration needs. Communications in a network environment are referred to herein as 'messages', 'messaging' and/or 'signaling', which may be inclusive of packets. Generally, signaling is referred to in reference to control-plane or management-plane packets while messaging can be referred to in reference to control-plane, management-plane or data-plane packets exchanged for communications at the application level.

A packet is a formatted unit of data and can contain both control information (e.g., source and destination address, etc.) and data, which is also known as payload. In some embodiments, control information can be included in one or more header(s) and/or one or more trailer(s) for each packet of an IP flow. Messages can be sent and received according to any suitable communication protocols. Suitable communication protocols can include a multilayered scheme such as the Open Systems Interconnection (OSI) Model, or any derivations or variants thereof.

The terms 'data', 'information', 'parameters' and variations thereof as used herein can refer to any type of binary, numeric, voice, video, textual or script data or information or any type of source or object code, or any other suitable data or information in any appropriate format that can be communicated from one point to another in electronic devices and/or networks. Additionally, signaling, messages, requests, responses, replies, queries, etc. are forms of network traffic and, therefore, may comprise one or more packets.

A 'protocol layer' or a 'layer', as referred to herein, can be any layer in a multilayered scheme that facilitates communications between layers, such as, for example, the OSI Model, using one or more communication protocols. A set of one or more interconnected layer(s) can be referred to herein as a 'protocol stack'. In some embodiments, a protocol stack may include only one layer.

In various embodiments, communication system <NUM> can represent a series of points or nodes of interconnected communication paths (wired or wireless) for receiving and transmitting packets of information that propagate through communication system <NUM>. In various embodiments, communication system <NUM> can be associated with and/or provided by a single network operator or service provider and/or multiple network operators or service providers. In various embodiments, communication system <NUM> can include and/or overlap with, in whole or in part, one or more packet data network(s) (e.g., one or more packet data network(s) <NUM>). Communication system <NUM> may offer communicative interfaces between various elements of communication system <NUM> and may be associated with any local area network (LAN), wireless local area network (WLAN), metropolitan area network (MAN), virtual private network (VPN), Radio Access Network (RAN), virtual local area network (VLAN), enterprise network, Intranet, extranet, or any other appropriate architecture or system that facilitates communications in a network environment.

In various embodiments, communication system <NUM> may implement user datagram protocol/Internet Protocol (UDP/IP) connections and/or transmission control protocol/IP (TCP/IP) communication language protocol in particular embodiments of the present disclosure. However, communication system <NUM> can alternatively implement any other suitable communication protocol, interface and/or standard, proprietary and/or non-proprietary, for transmitting and receiving messaging and/or signaling. Other protocols, interfaces and/or communication standards that can be used in communication system <NUM> can include 3GPP Diameter-based protocols, Remote Authentication Dial-In User Service (RADIUS) protocols, Authentication, Authorization and Accounting (AAA) signaling, a Terminal Access controller access-control system (TACACS), TACACS+, Proxy Mobile IP version <NUM> (PMIPv6), Proxy Mobile IP version <NUM> (PMIPv4), Extensible Messaging and Presence Protocol (XMPP), General Packet Radio Service (GPRS) Tunneling Protocol (GTP) (version <NUM> or version <NUM>), Generic Route Encapsulation (GRE), Ethernet over GRE (EoGRE), etc. In various embodiments, AAA signaling can include signaling exchanges facilitated via Diameter, RADIUS, Extensible Messaging and Presence Protocol (XMPP), Simple Object Access Protocol (SOAP), SOAP over Hypertext Transfer Protocol (HTTP), Representational State Transfer (REST), combinations thereof or the like. In some embodiments, secure communications can be facilitated using TCP/IP Secure Sockets Layer (SSL) communications.

WLAN access network <NUM> may provide a WLAN-based (or, more generally, a non-3GPP-based) communications interface between UE <NUM> and EPC <NUM> via WLAN communication node <NUM>, WLAN controller <NUM> and LWIP SeGW <NUM> that interfaces with LWIP controller <NUM> including UCMP logic <NUM>. In various embodiments, WLAN access network <NUM> may include access networks such as an Institute of Electrical and Electronic Engineers (IEEE) <NUM> Wi-Fi access network and/or a WiGig access network, which can include a Hotspot <NUM> access networks, and/or a <NUM> Worldwide Interoperability for Microwave Access (WiMAX) access network.

In various embodiments, WLAN communication node <NUM> can be configured with one or more transmitter(s), receiver(s), processor(s), controller(s), memory element(s), storage, etc. to facilitate OTA RF communications (e.g., <NUM> Wi-Fi, Hotspot <NUM>, etc.) between UE <NUM> and WLAN communication node <NUM>. In some cases, a WLAN communication node <NUM> can be referred to as a WLAN access point (AP). In various embodiments, any WLAN communication node (e.g., WLAN communication node <NUM>) deployed in communication system <NUM> can be configured as Wi-Fi AP, a Wi-Fi Hotspot <NUM> AP, WiMAX AP, combinations thereof or any other WLAN communication node as may be defined by IEEE standards, Wi-Fi Alliance® standards, IETF standards, combinations thereof or the like.

In various embodiments, WLAN controller <NUM> may be responsible for system wide wireless LAN functions, such as security policies, intrusion prevention, RF management, Quality of Service (QoS) functions, and/or mobility functions for WLAN access network <NUM> and one or more WLAN communication nodes. Although only one WLAN communication node <NUM> is illustrated in the example architecture shown in <FIG>, it should be understood that WLAN access network can include multiple WLAN communication nodes.

Communications between UE <NUM> and the 3GPP access network via WLAN communication node <NUM> and WLAN controller <NUM> can be facilitated by a LWIP tunnel <NUM> as shown in <FIG>. LWIP tunnel <NUM> can facilitate the establishment of a UE specific IP Security (IPSec) tunnel, shown in <FIG> as LWIP IPSec tunnel <NUM>, to carry uplink (UL) and downlink (DL) IP flows between UE <NUM> and LWIP SeGW <NUM>. As referred to herein in this Specification, an IP flow can refer to a sequence of packets that can be identified using either <NUM>-tuple packet header information or <NUM>-tuple packet header information for each packet of a flow. Header information can be referred to as header fields. A <NUM>-tuple packet header identifies a source IP address, a destination IP address, a source port, a destination port and a transport protocol for a packet. A <NUM>-tuple packet header identifies a source-IP address and a destination IP address for a packet.

During registration (e.g., power-on, initialization, re-initialization) of WLAN communication node <NUM> within WLAN access network <NUM>, LWIP IPSec tunnel <NUM> can be established via LWIP SeGW <NUM> to protect communications between a given UE (e.g., UE <NUM>) and LWIP SeGW <NUM>. Generally, IPSec can use cryptographic security services to protect communications over IP networks. IPSec can support network-level peer authentication, data origin authentication, data integrity, data confidentiality (encryption), and replay protection. Implementation of IPSec can be based on Internet Engineering Task Force (IETF) standards.

3GPP access network <NUM> may provide a 3GPP-based communications interface between UE <NUM> and EPC <NUM>. In various embodiments, 3GPP access network <NUM> may include access networks such as a Global System for Mobile Communications (GSM), General Packet Radio Services (GPRS), Enhanced Data Rates for GSM (EDGE) radio access network (GERAN), generally referred to as a 2nd Generation (<NUM>) access network; a Universal Mobile Telecommunications System (UMTS) Terrestrial radio access network (UTRAN), High Speed Packet Access (HSPA/HSPA+), generally referred to as a 3rd Generation (<NUM>) access network; and/or a E-UTRAN, which can include a <NUM>, LTE/LTE-Advanced (LTE-A)/LTE-Advanced Pro and/or <NUM> New Radio (NR) access network.

In various embodiments, 3GPP communication node <NUM> can be configured with one or more transmitter(s), receiver(s), processor(s), controller(s), memory element(s), storage, etc. to facilitate OTA RF communications (e.g., <NUM>, <NUM>, etc.) between UE <NUM> and 3GPP communication node <NUM>. In various embodiments, protocol stack <NUM> can include a number of layers including, but not limited to, a Radio Resource Control (RRC) layer, a user data-plane GTP (GTP-U) layer, a Packet Data Convergence Protocol (PDCP) layer, a Radio Link Control (RLC) layer, a Medium Access Control (MAC) layer and/or a physical (PHY) layer. In various embodiments, any 3GPP communication node (e.g., 3GPP communication node <NUM>) deployed in communication system <NUM> can be configured as an evolved Node B (eNodeB or eNB), a Home eNode B (HeNB), a Node B (NodeB), a Home NodeB (HNB), a Base Station System (BSS) combinations thereof or any other 3GPP communication node as may be defined by 3GPP standards.

In some embodiments, one or more protocol layers of 3GPP communication node <NUM> can be realized using protocol stack <NUM> and/or LWIP controller <NUM>, which may or may not be configured as part of 3GPP communication node <NUM>. For example, a vRAN deployment can facilitate a virtualized realization of functionality provided by protocol layers of protocol stack <NUM> and/or LWIP controller <NUM> using one or more VNFs/VNFCls and/or PNFs. Generally, a virtualized realization can refer to a logical decomposition of 3GPP access network functionality across one or more sets or groups of VNFs/VNFCls and/or PNFs.

For example, in one embodiment, a particular vRAN decomposition may be configured such that functionality for the PHY layer or part of the PHY layer of the protocol stack can be implemented using a PNF configured as the RF termination point for a 3GPP communication node. Functionality for other protocol layers of the 3GPP communication node such as the RRC layer, the GTP-U layer, the PDCP layer, the RLC layer and the MAC layer can be implemented using one or more sets of VNFs/VNFCls, which can be instantiated via servers or, more generally, compute nodes that can provided via one or more physical or cloud-based data centers that may or may not be at geographically different locations from the PNF and/or one or more other protocol layers for the 3GPP communication node. Further, LWIP controller functionality, including UCMP logic functionality, can be implemented using one or more sets of VNFs/VNFCls, which can also be instantiated via compute nodes that can be provided via one or more physical or cloud-based data centers that may or may not be at geographically different locations from each other, the protocol layers of the 3GPP communication node and/or the PNF for the 3GPP communication node. Thus, in some embodiments, functionality for LWIP controller <NUM> can be implemented separate from the PHY layer of 3GPP communication node <NUM>.

LWIP controller <NUM> including UCMP logic <NUM> can be configured to provide routing of one or more UE IP flow(s) using WLAN access network <NUM> or 3GPP access network <NUM> based, at least in part, on various WLAN-based metrics associated with WLAN access network <NUM> and various LTE-based metrics associated with 3GPP access network <NUM>. In particular, UCMP logic <NUM> can perform UCMP load balancing across the access networks to facilitate offloading and/or onboarding of one or more data radio bearer (DRB) of a given UE (e.g., UE <NUM>) according to WLAN metrics for the WLAN access network <NUM> and E-UTRAN metrics for the 3GPP access network <NUM> such that one access network may be loaded more or less than the other access network.

As referred to herein, the terms '3GPP access network', 'E-UTRAN', 'LTE' or 'LTE access network' can be used interchangeably to refer to various metrics (e.g., LTE metrics or E-UTRAN metrics), links (e.g., LTE link or E-UTRAN link), features, etc. that can be defined or provided via 3GPP access network <NUM>; however, this is not meant to limit the broad scope of the present disclosure. It should be understood that the term '3GPP access network' can refer to any access network architecture (e.g., <NUM>, <NUM>, etc.) that may be defined by 3GPP as discussed for various embodiments described herein.

A DRB or, more generally, a 'bearer', can refer to a path, channel, tunnel or the like through which communications can be exchanged between two endpoints for a particular service, session, application, etc. (e.g., for an IP flow). Typically, bearers are referred to in association to communications exchanged between a UE and one or more elements or nodes of an EPC (e.g., EPC <NUM>) for LTE architectures.

As referred to herein in this Specification, the terms 'metric', 'routing metric' or 'cost metric' can refer to a Key Performance Indicator (KPI) that can be used to characterize the capability of a particular access network to handle IP flows for one or more UE. During operation in various embodiments as described herein, metrics for each access network can be utilized by UCMP logic <NUM> to provide UCMP load balancing between the access networks. In various embodiments, various metrics that can be associated with WLAN access network <NUM> and/or 3GPP access network <NUM> can include, but not be limited to: load, channel utilization, resource utilization, signal strength, signal quality, throughput, error rate, combinations and/or variations thereof or the like.

The metrics for each access network can vary over time such that routing of IP flows across each access network can be varied according to the metrics for each access network. UCMP can be contrasted with Equal Cost Multipath (ECMP) routing, which enables the modulus (k) of a hash of IP headers to be used to distribute flows between k equal cost paths between two endpoints. UCMP is a routing technique that provides for load balancing flows across a number of unequal cost paths between two endpoints (e.g., between a UE and an PDN) such that the load balancing is performed according to a different routing metric applicable to each path, where metrics are typically associated with some routing protocol.

As applied to communication system <NUM>, UCMP logic <NUM> can facilitate load balancing of UE flow(s) across WLAN access network <NUM> and 3GPP access network <NUM> in a dynamic manner depending on the metrics associated with each access network. In one embodiment, UCMP logic <NUM> can perform modulo (MOD) hashing operations on the IP flow tuple (e.g., <NUM>-tuple, <NUM>-tuple, etc.) of each packet of an IP flow to ensure that all packets for a flow are handled by a same access technology; thus, avoiding out of sequence packet arrivals within one particular flow. A routing metric, which can be referred to herein using the label 'Metric-i' for each 'i-th' access network of an N number of access networks where {<NUM>≤i<N} can be normalized using the equation (Metric-i)/(ΣMetrics), where the value ΣMetrics is the sum all routing metrics for all available N access networks. The normalized routing metric can be multiplied by a Weighting Factor (WF) to calculate an effective normalized weight, which can indicate a given access network's capability to handle IP flows. A value for the WF can be selected to weight the distribution of IP flows in proportion to the normalized routing metrics in order to load balance IP flows across access networks having unequal routing costs. For example, for embodiments in which normalized routing metrics are calculated between <NUM> and <NUM>, a WF of <NUM> can be selected to determine an effective normalized weight of each routing metric Metric-i for each i-th access network.

A hash value (HV) for each IP flow tuple of each packet of an IP flow can be calculated using an equation HV(IP flow tuple) = HASH(IP flow tuple) MOD WF, where HASH(IP flow tuple) represents the hash of an IP flow tuple according to a given hashing function, which can be configured for UCMP logic <NUM>. In various embodiments, a hashing function can be any function that can be used to map input data to output data of a fixed size. In various embodiments, different hashing function types can be configured for UCMP logic <NUM> depending on the size (e.g., number of bits) of flow tuple fields and/or the number of flow tuple fields to be used for hashing operations under the constraint that a hash function type returns a same output hash value for same input values (e.g., is deterministic). A resultant hash value calculated for each IP flow tuple of each packet of a given IP flow can be compared against a threshold value or ranges of threshold values associated with normalized routing metrics for a number of access networks to select an access network to which to route packets for the IP flow.

In various embodiments, the IP flow tuple used for the hashing can use <NUM>-tuple information, <NUM>-tuple information or any other information that can be assumed to remain constant for each packet of an IP flow such that the hash of the IP flow tuple for each packet remains unchanged across all packets for the IP flow. Additional details related to UCMP load balancing for routing IP flows in accordance with various embodiments of communication system <NUM> are described below.

Before detailing further features of communication system <NUM>, certain contextual information is provided to understand different features of LWA and LWIP interworking architectures. Such information is offered earnestly and for teaching purposes only and, therefore, should not be construed in a way to limit the broad applications and teachings of the present disclosure.

The 3GPP LWIP interworking architecture, as currently defined in 3GPP Specifications, uses a bearer switch to route flows between WLAN and LTE communication links (e.g., access networks). This puts such LWIP architecture at a disadvantage over LWA, which provides for the ability to aggregate flows over WLAN and LTE communication links. In particular, LWA interworking architectures use PDCP sequence numbers for packets traversing WLAN and LTE links to enable any re-ordering that may need to be performed before passing the packets to higher layers. Current 3GPP specifications for LWIP interworking architectures do not provide for sequence numbering and 3GPP has not defined any approach for link aggregation.

In accordance with at least one embodiment, communication system <NUM> is configured to overcome the aforementioned shortcomings of current 3GPP LWIP interworking architecture by facilitating UCMP routing to load balance UE IP flow(s) across WLAN access network <NUM> and 3GPP access network <NUM> according to routing metrics determined for each access network. Thus, communication system <NUM> can provide a Layer <NUM> (L3) based approach to link aggregation that can be applied to LWIP interworking architectures.

During operation in at least one embodiment, LWIP controller <NUM> via UCMP logic <NUM> can facilitate load balancing flows between WLAN access network <NUM> and 3GPP access network <NUM> according to metrics determined for each access network. Interface Xw between LWIP SeGW <NUM> and LWIP controller <NUM> can facilitate the exchange of data-plane and control-plane communications between WLAN access network <NUM> and 3GPP access network <NUM>. Metrics for each access network can be determined based on various instrumentation communications with LWIP controller <NUM>. As referred to herein, the term 'instrumentation' can refer to reports, measurements, calculations, combinations thereof or the like that can be used by LWIP controller to determine WLAN metrics for WLAN access network <NUM> and E-UTRAN metrics for 3GPP access network <NUM>.

LWIP instrumentation, which can include WLAN instrumentation and E-UTRAN instrumentation, can be sent to LWIP controller <NUM> for the controller to determine one or more downlink (e.g., from WLAN to UE) and uplink (e.g., from UE to WLAN) metrics for WLAN access network <NUM> and one or more downlink and uplink metrics for 3GPP access network <NUM>.

In various embodiments, WLAN instrumentation can include different types of instrumentation including: WLAN aggregate instrumentation that can be based on aggregate information, reports, calculations or the like associated with multiple communications using a particular WLAN communication node; WLAN individual instrumentation that can be based on individual information, reports, calculations or the like associated with an individual UE communication; and/or RRC WLAN instrumentation that can be based on information, reports, calculations or the like associated with a given UE (e.g., UE <NUM>) that is communicated to LWIP controller <NUM> via the 3GPP access network <NUM>. Per 3GPP specifications, the E-UTRAN is operable to trigger RRC measurements by a UE for the WLAN access network, including signal strength and channel quality information. In various embodiments, WLAN instrumentation information or parameters can include, but not be limited to: Basic Service Set (BSS) Load, Hotspot <NUM> (HS2. <NUM>) Wireless Area Network (WAN) metrics as defined by HS2. <NUM> guidelines, channel utilization, WLAN signal strength information, WLAN signal quality information, uplink metrics calculated by a given UE, measured uplink UE throughput, BSS Identifier(s) (BSSID(s), Service Set Identifier(s) (SSID(s)), Homogenous Extended SSID(s) (HESSID(s), combinations thereof or the like.

Typically, a HS2. <NUM> deployment is a type of WLAN communication network configured by a Hotspot operator and a Hotspot service provider where the operator deploys and operates the network and the service provider provides network services and operates the AAA infrastructure to authenticate subscribers. During operation for a HS2. <NUM> network, a given UE (e.g., UE <NUM>) can query an Access Network Query Protocol (ANQP) server using one or more Generic Advertisement Service (GAS) query frames and can receive one or more ANQP element(s) in response. The UE can recover information from the ANQP element(s) that can aid the UE in network selection (e.g., selecting a WLAN communication to which to attach), association and authentication with the HS2. <NUM> network. In at least one embodiment as prescribed by HS2. <NUM> guidelines, WAN metrics can include a WAN metrics Hotspot <NUM> ANQP element, which can include information about a WAN link that connects a WLAN communication node to the Internet such as, for example, Link status (e.g., Link up, Link down, Link in test state); WAN link symmetry, which indicates whether a link speed is the same in the uplink and downlink (e.g., symmetric or asymmetric); Downlink speed, which is nominal in kilobits per second (kbps); Uplink speed (nominal in kbps); Downlink load and/or Uplink load (e.g., BSS load); and/or Load Measurement Duration, which is the time interval over which a WAN interface device (e.g., a WLAN AP or edge router) averages its load measurement.

In various embodiments, WLAN signal strength information can include Received Signal Strength Indicator (RSSI), Received Channel Power Indicator (RCPI), combinations thereof or other similar signal strength information. In at least one embodiment, WLAN access network <NUM> can be configured to signal to LWIP controller <NUM> the signal strength experienced by a particular UE for the WLAN access network. In various embodiments, the signaling from WLAN access network <NUM> can be performed on a periodic basis, on an event-driven basis (e.g., re-association, movement, etc.), on a flow basis, combinations thereof or the like.

In various embodiments, E-UTRAN instrumentation information or parameters for 3GPP access network <NUM> can include UE-reported downlink Channel Quality Information (CQI), downlink signal strength measurement information, downlink signal quality information, uplink UE throughput, uplink UE signal strength, uplink metrics calculated by a given UE, and/or quality information, combinations thereof or the like. In at least one embodiment, E-UTRAN signal strength measurement information can include Reference Signal Received Power (RSRP) as measured and reported by a given UE. In at least one embodiment, E-UTRAN signal quality information can include Reference Signal Received Quality (RSRQ). As defined in 3GPP TS <NUM>, RSRP is the linear average over the power contributions of resource elements for resource blocks (RBs) that carry cell-specific reference signals (CRS) within a considered measurement frequency bandwidth. RSRQ is defined as the ratio of the number (N) of RBs of the E-UTRA carrier RSSI measurement bandwidth (e.g., the system bandwidth) multiplied by the RSRP divided by the RSSI, generally expressed as '(N * RSRP)/RSSI'.

LWIP controller <NUM> can determine downlink metrics for each access network according to metric functions that operate on the instrumentation received for each access network. In various embodiments, different downlink metric functions can be configured for LWIP controller <NUM> that can be used to calculate downlink WLAN metrics and downlink E-UTRAN metrics for each access network based on received instrumentation. Downlink WLAN metric functions can be configured for LWIP controller <NUM> that can be used to derive a WLAN cost or routing metric for WLAN access network <NUM>. For example, in at least one embodiment a downlink WLAN metric can be represented as: downlink WLAN metric = Function (WLAN aggregate instrumentation, WLAN individual instrumentation, RRC WLAN instrumentation).

Downlink E-UTRAN metric functions can also be configured for LWIP controller <NUM> that can be used to derive an E-UTRAN routing metric for 3GPP access network <NUM>. For example, in at least one embodiment a downlink E-UTRAN metric can be represented as downlink E-UTRAN metric = Function (various E-UTRAN instrumentation [e.g., reported CQI, reported measurement values, etc.]).

Consider additional example details regarding WLAN metrics and E-UTRAN metrics that can be configured for LWIP controller <NUM> and UCMP logic <NUM> in accordance with various embodiments. To provide more details on the types of metrics that can be provided in various embodiments of communication system <NUM>, it is useful to consider the type of metrics that 3GPP deployments often use to balance traffic across two LTE carriers in Carrier Aggregation (CA) mode (e.g., between a <NUM> megahertz (MHz) carrier and a <NUM> carrier). Such metrics are defined in 3GPP TS <NUM>, which provides details on eNodeB measurements regarding Physical Resource Block (PRB) utilization, Received Random Access Preambles, number of active UEs, packet delay, packet loss, scheduled IP throughput and data volume. Note that many of these metrics can be generalized, which can be valuable for making intelligent decisions regarding load balancing across LTE carriers in CA mode.

For instance, PRB usage can represent a percentage of the PRBs used on each carrier over a defined period of time. Regardless of whether a carrier is <NUM>, <NUM> or <NUM> in BW, the PRB usage metric can provide a measure of the loading on a given carrier. Using such a metric, UCMP logic <NUM> can attempt to move IP flows from a high PRB usage carrier to a low PRB usage carrier.

Similarly, scheduled IP throughput metrics can represent measures of experienced user throughput on a given carrier. Wider bandwidth (BW) carriers will naturally support a higher load while maintaining a same user experienced throughput compared to lower BW carriers. So again, this metric could be used to move IP flows from carriers with lower experienced user throughput to a carrier with higher user experienced throughputs in accordance with various embodiments.

For the WLAN access network <NUM>, equivalent WLAN metrics can be defined that parallel those provided in 3GPP TS <NUM>. For instance, since Wi-Fi does not currently implement OFDMA, a channel occupancy metric could be defined as provided in Equation <NUM> (Eq. <NUM>), below: <MAT>.

For Eq. <NUM>, 'CO(T)' can be equal to the percentage of time that a channel is occupied over a given period 'T'; 'CO1(T)' can be equal to the number of nine (<NUM>) microsecond (µs) slots where the channel was occupied over the period T; and 'S(T)' can be equal to the total number of <NUM> slots over the period T. In at least one embodiment, a WLAN metric as provided in Eq. <NUM> would be equivalent to PRB utilization for LTE and thus could be by UCMP logic <NUM> to provide for load balancing IP flows between 3GPP access network <NUM> and WLAN access network <NUM> for an LWIP session for a given UE.

Similarly, a downlink IP throughput metric for WLAN access network <NUM> could be defined as provided in Equation <NUM> (Eq. <NUM>), below: <MAT>.

For Eq. <NUM>, 'ThpTimeDI' (e.g., throughput time downlink) can represent a downlink Transmit Opportunity (TXOP) interval defined by times T1 and T2 such that ThpTimeDl = T1 - T2 (in milliseconds (ms)) where T1 is a point in time after T2 when a TXOP data burst was transmitted, as acknowledged by a given client (e.g., UE) and T2 is point in time when a TXOP begins after a MAC Protocol Data Unit (MPDU) becomes available for transmission and 'ThpVolDl' (e.g., throughput volume downlink) is equal to a volume of a data burst, excluding any data transmitted a slot when the buffer emptied (e.g., so only full slots can be considered).

A given UE (e.g., UE <NUM>) is responsible for calculating uplink metrics for each access network with which it is in communication. During operation, for example, UE <NUM> can determine an uplink WLAN metric for WLAN access network <NUM> and an uplink E-UTRAN metric for 3GPP access network <NUM> and can send the instrumentation for each access network (e.g., the uplink metrics for each access network) to LWIP controller <NUM>.

In various embodiments, an uplink WLAN metric calculated by UE <NUM> can be based on HS2. <NUM> recovered information, which can include BSS load and/or channel utilization, WLAN signal and quality information, and/or measured uplink WLAN throughput, combinations thereof or the like. In various embodiments, an uplink E-UTRAN metric calculated by UE <NUM> can be based on LTE signal strength and quality information, and/or measured LTE throughput, combinations thereof or the like.

Based on the various metrics determined for each access network, UCMP logic <NUM> can perform load balancing for an LWIP capable UE (e.g., UE <NUM>) to load balance one or more IP flow(s) for the UE across WLAN access network <NUM> and 3GPP access network <NUM>. Thus, communication system <NUM> can provide a system and method for using UCMP techniques for aggregating WLAN and LTE links in LWIP architectures. In at least one embodiment, the solution provided communication system <NUM> can provide for the ability to offer aggregated service for LWIP compared with 3GPP standards-based functionality but without the need for providing re-ordering of PDCP sequence numbers, as is defined for LWA architectures.

In various embodiments, UE <NUM> can be associated with any electronic device wishing to initiate a flow in communication system <NUM> via some network. In at least one embodiment, UE <NUM> can be configured to facilitate simultaneous WLAN connectivity and 3GPP connectivity within communication system <NUM>. The terms 'UE', 'mobile device', 'end device', 'user', 'subscriber' or variations thereof can be used herein in this Specification interchangeably and are inclusive of devices used to initiate a communication, such as a computer, an electronic device such as an Internet of Things (IoT) device, etc., a personal digital assistant (PDA), a laptop or electronic notebook, a cellular telephone, an IP phone, an electronic device having cellular and/or Wi-Fi connection capabilities, a wearable electronic device or any other device, component, element, or object capable of initiating voice, audio, video, media, or data exchanges within communication system <NUM>. UE <NUM> may also be inclusive of a suitable interface to a human user such as a microphone, a display, a keyboard, or other terminal equipment.

UE <NUM> may also be any device that seeks to initiate a communication on behalf of another entity or element such as a program, application, a database, or any other component, device, element, or object capable of initiating an exchange within communication system <NUM>. Within communication system <NUM>, IP addresses (e.g., for UE <NUM> or any other element in communication system <NUM>) can be assigned using Dynamic Host Configuration Protocol (DHCP), Stateless Address Auto-configuration (SLAAC), during default bearer activation processes, or any suitable variation thereof. IP addresses used within communication system <NUM> can include IP version <NUM> (IPv4) and/or IP version <NUM> (IPv6) IP addresses.

In various embodiments, a subscriber associated with a given UE can be identified using one or more identifiers such as, for example, an International Mobile Subscriber Identity (IMSI) or a Temporary IMSI (T-IMSI). An IMSI for a given subscriber is typically stored on a Subscriber Identity Module (SIM) (e.g., a SIM card) within the subscriber's UE.

In various embodiments, MME <NUM> can provide tracking area list management, idle mode UE tracking, bearer activation and deactivation, serving gateway and packet data network gateway selection for UEs and authentication services. In at least one embodiment, MME <NUM> may be in communication with a Home Subscriber Server (not shown), which may include one or more databases containing user-related and subscription-related information. An HSS may perform functionalities such as mobility management, call and session establishment support, user authentication and access authorization. In various embodiments, SGW <NUM> may route and forward user data packets (e.g., flows) and may also act as the mobility anchor for the user plane during inter-eNodeB handovers and as the anchor for mobility between LTE and other 3GPP technologies. In various embodiments, PGW <NUM> may provide IP connectivity access network (IP-CAN) session connectivity from a given UE (e.g., UE <NUM>) to external packet data network(s) <NUM> by being the point of exit and entry of IP flows for the UE. In various embodiments, EPC <NUM> can include various additional elements and/or nodes as may be defined by 3GPP standards including, but not limited to: Authentication, Authorization and Accounting (AAA) elements, Policy and Charging Rules Functions (PCRFs), Mobile Switching Centers (MSCs), Serving GPRS Support Nodes (SGSNs), Gateway GPRS Support Nodes (GGSNs) to facilitate the exchange of data to and from one or more PDNs for one or more UEs. These network elements are also not shown in order to illustrate other features of communication system <NUM>. In various embodiments, one or more PDN(s) <NUM> can include the Internet, an IP Multimedia Subsystem (IMS), an enterprise network, operator IP services, combinations thereof or the like.

Turning to <FIG> are a simplified interaction diagram <NUM> illustrating example details that can be associated with providing UCMP routing in an LWIP network environment in accordance with one example embodiment of the present disclosure. The embodiment of <FIG> includes UE <NUM>, WLAN communication node <NUM>, LWIP SeGW <NUM>, 3GPP communication node <NUM>, LWIP controller <NUM> including UCMP logic <NUM> and SGW <NUM>.

During operation, as shown in <FIG>, a set of operations (<NUM>) can be performed using LWIP procedures in order to associate UE <NUM> with WLAN access network <NUM> and establish an LWIP IPSec tunnel between UE <NUM> and LWIP SeGW <NUM>. Operations <NUM> assume that UE <NUM> is attached to 3GPP communication node <NUM>. At <NUM>, 3GPP communication node <NUM> sends an RRC Connection Reconfiguration message to UE <NUM> requesting UE <NUM> to report WLAN measurements and information (e.g., signal strength, quality, SSID information, BSSID information, BSS load, etc.) for the WLAN access network. At <NUM>, UE <NUM> responds with an RRC Connection Reconfiguration Complete message indicating that it has modified its RRC connection configuration. At <NUM>, UE <NUM> sends its WLAN measurements to 3GPP communication node <NUM>.

At <NUM>, 3GPP communication node <NUM> sends UE <NUM> a RRC Connection Reconfiguration message indicating a WLAN mobility set (e.g., one or more WLAN identifiers such as BSSID, SSID and/or HESSID). At <NUM>, UE <NUM> sends a RRC Connection Reconfiguration Complete message to 3GPP communication node <NUM> indicating receipt and storage of the WLAN mobility set. At <NUM>, UE <NUM> performs a WLAN association with WLAN communication node <NUM>. As prescribed by IEEE <NUM>, association procedures carried out between a UE and a WLAN AP are used to establish an AP/UE mapping that enables UE invocation of system services. Association differs from authentication in that authentication generally refers to the process where an entity's identity is authenticated, typically by providing evidence that it holds a specific digital identity such as an identifier and corresponding credentials. Completion of UE association typically follows a successful authentication of the UE with a WLAN AP.

Upon completion of the WLAN association, UE <NUM> sends 3GPP communication node <NUM> a WLAN Connection Status Report message at <NUM> confirming association to WLAN access network <NUM>. At <NUM>, 3GPP communication node <NUM> via LWIP controller <NUM> sends UE <NUM> a RRC Connection Reconfiguration message including IPSec parameters that allow UE <NUM> to establish a DRB over LWIP with LWIP controller <NUM>. As per 3GPP TS <NUM>, the RRC Connection Reconfiguration message can include the following syntax as shown in TABLE <NUM>, below, to provide for setting-up a DRB over LWIP:
<IMG>.

The LWIP-Config-<NUM> message is used to setup (or release) a DRB over LWIP. In some embodiments, an additional parameter, 'DRB-toAdd', can be included in the RRC Connection Reconfiguration message that can be used to indicate if a LWIP DRB is to be used for uplink flows only, downlink flows only or for both uplink and downlink flows, or if E-UTRAN is to be used (e.g., no flows are to be sent over WLAN). Although in some cases a LWIP DRB may be established and the DRB-toAdd parameter may indicate that E-UTRAN is to be used for uplink and downlink flows, establishment of the LWIP DRB can facilitate using the LWIP DRB at a later time, if needed (e.g., another RRC Connection Reconfiguration message can be sent indicating to use the LWIP DRB for certain IP flows).

At <NUM>, UE <NUM> and 3GPP communication node <NUM> perform a set-up of a DRB over LWIP. Upon setting up the LWIP DRB, UE <NUM> sends 3GPP communication node <NUM> a RRC Connection Reconfiguration Complete message at <NUM>. As shown at <NUM>, LWIP IPSec tunnel <NUM> is established between UE <NUM> and LWIP SeGW <NUM>, which interfaces with LWIP controller <NUM>. Continuing to <FIG>, instrumentation operations (<NUM>) can be used to signal WLAN instrumentation and E-UTRAN instrumentation to LWIP controller <NUM>. At <NUM>, WLAN communication node <NUM> can signal WLAN instrumentation to LWIP controller <NUM>. At <NUM>, 3GPP communication node <NUM> can signal E-UTRAN instrumentation to LWIP controller <NUM>. At <NUM>, 3GPP communication node <NUM> can signal WLAN instrumentation as measured by UE <NUM> (e.g., as received at <NUM>) to LWIP controller <NUM>. At <NUM>, LWIP controller can calculate a downlink E-UTRAN metric according to an E-UTRAN downlink metric function that uses the received E-UTRAN instrumentation and can calculate a downlink WLAN metric according to a WLAN downlink metric function that uses the received WLAN instrumentation. Although only downlink instrumentation is illustrated in <FIG>, in various embodiments, uplink instrumentation can also be sent to LWIP controller <NUM> from UE <NUM> via WLAN communication node <NUM> and 3GPP communication node <NUM> in order for the LWIP controller <NUM> to calculate an uplink WLAN metric and an uplink E-UTRAN metric for each access network according to a metric function configured for each access network.

Downlink packet operations (<NUM>) are shown for the embodiment of <FIG> assuming that a downlink packet destined for UE <NUM> is received, as shown at <NUM> by LWIP controller <NUM>. Upon receiving a downlink packet for UE <NUM>, LWIP controller <NUM> via UCMP logic <NUM> can perform UCMP load balancing at <NUM> using the downlink E-UTRAN metric and the downlink WLAN metric calculated at <NUM> to select an access network to use for routing the packet to UE <NUM>.

Consider one operational example in which a first routing metric for a first access network is calculated as <NUM> and a second routing metric for a second access network is calculated as <NUM>. A first normalized routing metric for the first access network can be calculated as <NUM>/<NUM> = <NUM>, which can be multiplied by a WF <NUM> to determine an effective normalized weight of <NUM> for routing IP flows to the first access network. A second normalized routing metric for the second access network can be calculated as <NUM>/<NUM> = <NUM>, which can be multiplied by a WF <NUM> to determine an effective normalized weight of <NUM> for routing IP flows to the first access network. Thus, a proportionate number of IP flows can be routed to the first access network over the second access network according to a ratio of <NUM>:<NUM>. For the present operational example involving two access networks, a threshold value can be set to a value based on the larger of the effective normalized weights of the access networks (e.g., <NUM>) and the HV of each IP flow tuple (e.g., HV(IP flow tuple) = HASH(IP flow tuple) MOD WF) can be compared against the threshold value to determine whether to select the first or the second access network to receive an IP flow.

A first range for selecting the first access network to receive an IP flow can be mapped to a relationship such that when HV(IP flow tuple) ≤ <NUM>, packets for an IP flow can routed to the first access network. A second range for selecting the second access network to receive an IP flow can be mapped to a relationship such that when HV(IP flow tuple) > <NUM>, packets for an IP flow can be routed to the second access network. Thus, based on the hash value for a given IP flow tuple for a given IP flow, UCMP logic <NUM> can, in various embodiments, perform a comparison between the hash value for the given IP flow tuple and one or more threshold values or ranges of threshold values such that each packet of the IP flow can be routed to a same access network when multiple access networks having unequal costs are available to receive IP flows. For the present operational example, the first access network would receive a proportionate number of flows over the second access network according to a ratio of <NUM>:<NUM>.

Consider another example involving three available access networks in which the first access network is determined to have a first effective normalized weight of <NUM>, a second access network is determined to have a second effective normalized weight of <NUM> and a third access network is determined to have a third effective normalized weight of <NUM> where IP flows can be routed in a proportion of <NUM>:<NUM>:<NUM> across the access networks. In this example, a first example range for selecting the first access network to receive IP flows can be expressed as HV(IP flow tuple) ≤ <NUM>; a second range for selecting the second access network to receive IP flows can be expressed as <NUM> < HV(IP flow tuple) ≤ <NUM>; and a third range for selecting the third access network to receive IP flows can be expressed as HV(IP flow tuple) > <NUM>, where the limits for each range can represent threshold values for selecting an appropriate access network to receive IP flows.

Referring again to <FIG>, if UCMP logic <NUM> selects WLAN access network <NUM> to handle the downlink IP flow for UE <NUM>, the operations can continue to <NUM> at which LWIP controller <NUM> via UCMP logic <NUM> routes the IP flow (e.g., routes packets for the flow) to LWIP SeGW <NUM>, which forwards the flow to WLAN communication node <NUM>, which forwards the flow to UE <NUM>. However, if UCMP logic <NUM> selects 3GPP access network <NUM> to handle the downlink IP flow for UE <NUM>, the operations can continue to <NUM> at which LWIP controller <NUM> via UCMP logic <NUM> routes the flow to UE <NUM>. Thus, as shown in the embodiment of <FIG>, communication system <NUM> can facilitate the aggregation of IP flows over WLAN and E-UTRAN links using UCMP load balancing.

Referring to <FIG> is a simplified flow diagram illustrating example operations <NUM> that can be associated with providing UCMP routing in an LWIP network environment in accordance with one claimed embodiment of the present disclosure. The operations can begin at <NUM> at which LWIP controller <NUM> receives WLAN instrumentation for a WLAN access network (e.g., WLAN access network <NUM>) for a given UE (e.g., for UE <NUM>). At <NUM>, the operations can include LWIP controller <NUM> receiving 3GPP access network instrumentation for a 3GPP access network (e.g., 3GPP access network <NUM>) for the given UE.

At <NUM>, the operations can include LWIP controller <NUM> determining at least one WLAN routing metric associated with the WLAN access network. In at least one embodiment, the LWIP controller <NUM> can determine at least one uplink WLAN metric and at least one downlink WLAN metric associated with the WLAN access network. At <NUM>, the operations can include LWIP controller <NUM> determining at least one 3GPP routing metric associated with the 3GPP access network. In at least one embodiment, the LWIP controller <NUM> can determine at least one uplink 3GPP access network metric and at least one downlink 3GPP access network metric associated with the 3GPP metric.

At <NUM>, the operations can include LWIP controller <NUM> via UCMP logic <NUM> routing one or more IP flows for the UE using the WLAN access network or the 3GPP access network based on the WLAN routing metric and the 3GPP routing metric and the operations can end. In various embodiments, a hash value of a given IP flow tuple (e.g., <NUM>-tuple, <NUM>-tuple, etc.) for each packet of an IP flow for the UE can be calculated and compared against one or more threshold values or ranges of threshold values associated with the effective normalized weight of each of a number of access network routing metrics such that each packet of the IP flow can be routed to a same access network thereby providing UCMP load balancing across the access networks.

Referring to <FIG> are simplified block diagrams illustrating example details that can be associated with various example embodiments of communication system <NUM>. In particular, <FIG> illustrate various examples associated with implementing an LWIP controller and UCMP logic in various potential embodiments of communication system <NUM>.

Referring to <FIG> is a simplified block diagram illustrating example details that can be associated with 3GPP communication node <NUM> in accordance with one potential embodiment of communication system <NUM>. As shown in the embodiment of <FIG>, 3GPP communication node <NUM> can include protocol stack <NUM>, LWIP controller <NUM>, at least one processor <NUM>, at least one memory element <NUM>, at least one storage <NUM> and instrumentation logic <NUM>. LWIP controller <NUM> can include UCMP logic <NUM> and a network interface unit <NUM>. Protocol stack <NUM> can include a PDCP layer <NUM>, an RLC layer <NUM>, a MAC layer <NUM> and a PHY layer <NUM>. PDCP layer can interface with LWIP controller <NUM> and RLC layer <NUM>. RLC layer can further interface with MAC layer <NUM> and MAC layer can further interface with PHY layer <NUM>. PHY layer <NUM> can further interface with UE <NUM>, also shown in <FIG>. UE <NUM> is also shown in the embodiment of <FIG>.

In at least one embodiment, at least one processor <NUM> is at least one hardware processor configured to execute various tasks, operations and/or functions of 3GPP communication node <NUM> as described herein. At least one memory element <NUM> and/or storage <NUM> can be configured to store data, information, software and/or instructions associated with the 3GPP communication node <NUM>. For example, in various embodiments, at least one memory element <NUM> and/or storage <NUM> can be configured to store one or more of: WLAN instrumentation; 3GPP (e.g., E-UTRAN) instrumentation; any instrumentation associated with an access network and/or user equipment; metric functions, information and/or calculations; interface information (e.g., tunnel information, IP address information, UE identifying information, etc.); logic; any other data, information, software and/or instructions as discussed for various embodiments described herein (e.g., UCMP logic <NUM> and/or instrumentation logic <NUM> can, in some embodiments, be stored in at least one memory element <NUM> and/or storage <NUM>); combinations thereof or the like.

In various embodiments, instrumentation logic <NUM> can include instructions that, when executed (e.g., by at least one processor <NUM>) cause 3GPP communication node <NUM> to signal of 3GPP (e.g., E-UTRAN) instrumentation to LWIP controller <NUM>. In various embodiments, UCMP logic <NUM> can include instructions that, when executed (e.g., by at least one processor <NUM>), cause LWIP controller <NUM> to perform one or more operations including, but not limited to: receiving instrumentation from various access networks (e.g., WLAN access network <NUM> and 3GPP access network <NUM>); calculating various metrics for the access networks according to various metric functions; calculating normalized routing metrics; calculating effective normalized weights for access networks; hashing IP flow tuples; and load balancing UE IP flow(s) across networks according to the various metrics calculated and/or received from one or more UE. In at least one embodiment, UCMP logic <NUM> can include instructions that, when executed, cause LWIP controller <NUM> to access a 3GPP Operations, Administration and Management (OAM) system (not shown) to obtain E-UTRAN instrumentation and/or metrics for a 3GPP access network.

In various embodiments, network interface unit <NUM> enables communication between LWIP controller <NUM>, a 3GPP communication node protocol stack (e.g., protocol stack <NUM>), an LWIP SeGW (e.g., LWIP SeGW <NUM>) and one or more elements of an EPC (e.g., MME <NUM> and SGW <NUM> of EPC <NUM>) and/or any other elements that may be configured for communication system <NUM>. In some embodiments, network interface unit <NUM> can be configured with one or more Ethernet driver(s), Fibre Channel driver(s), controller(s), etc. or other similar network interface driver(s) and/or controller(s) to enable communications for LWIP controller <NUM> within communication system <NUM>.

In various embodiments, packetized DRBs for an IP flow can be received in a downlink data scenario by PDCP layer <NUM>, which can operate on the flow as PDCP Service Data Units (SDUs) and can generate PDCP Protocol Data Units (PDU) to output to RLC layer <NUM>. In one embodiment, PDCP layer <NUM> can apply encryption and/or other addressing and/or control information to the packets based on control signaling received from a Radio Resource Control (RRC) layer (not shown) configured for protocol stack <NUM>. RLC layer <NUM> can operate on PDCP PDUs as RLC SDUs and can generate RLC PDUs to output to MAC layer <NUM>. In one embodiment, RLC layer <NUM> can concatenate and segment higher layer PDCP PDUs into pre-derived packetized data blocks that can be passed to MAC layer <NUM>. MAC layer <NUM> can operate on the RLC PDUs as MAC SDUs and can generate MAC PDUs (MPDUs) to send to PHY layer <NUM> containing data and/or control information or, more generally, resources allocated to a given UE (e.g., UE <NUM>) across time and frequency domains. In various embodiments, MAC layer <NUM> can perform scheduling operations for scheduling transmissions, managing hybrid automatic repeat-request (HARQ) operations, combinations thereof or the like. In various embodiments, PHY layer <NUM> can interface with and/or include one or more receiver(s), transmitter(s) and antenna(s) (not shown) to enable OTA communications with one or more UE. In various embodiments, PHY layer <NUM> can perform one or more operations including, but not limited to: Forward Error Correction (FEC), Modulation (e.g., QAM, <NUM>-QAM, <NUM>-QAM, etc.), antenna mapping operations for Multiple Input Multiple Output (MIMO) functions, Inverse Fast Fourier Transform (IFFT), cyclic prefix (CP) functions, and/or parallel/serial (P/S) Common Public Radio Interface (CPRI) encoding for full CPRI or compressed CPRI functions, combinations thereof or the like.

Referring to <FIG> is a simplified block diagram illustrating example details that can be associated with a split configuration of a 3GPP communication node <NUM> and an LWIP controller <NUM> in accordance with one potential embodiment of communication system <NUM>. For the embodiment of <FIG>, 3GPP communication node <NUM> can be any 3GPP communication node that may be deployed in a 3GPP access network (e.g., 3GPP access network <NUM>) that may be configured to signal 3GPP (e.g., E-UTRAN) instrumentation to a LWIP controller (e.g., LWIP controller <NUM>). Further for the embodiment of <FIG>, LWIP controller <NUM> can be a network element that can be configured separate from 3GPP communication node <NUM>. UE <NUM> is also shown in the embodiment of <FIG>.

As shown in the embodiment of <FIG>, 3GPP communication node <NUM> can include at least one processor <NUM>, at least one memory element <NUM>, at least one storage <NUM>, instrumentation logic <NUM>, a network interface unit <NUM> and a protocol stack <NUM>. Protocol stack <NUM> can include a PHY layer <NUM>, a MAC layer <NUM>, an RLC layer <NUM> and a PDCP layer <NUM>, each of which can perform operations as discussed for various embodiments described herein. LWIP controller <NUM> can include at least one processor <NUM>, at least one memory element <NUM>, at least one storage <NUM>, UCMP logic <NUM> and a network interface unit <NUM>.

In at least one embodiment, at least one processor <NUM> is at least one hardware processor configured to execute various tasks, operations and/or functions of 3GPP communication node <NUM>. At least one memory element <NUM> and/or storage <NUM> can be configured to store data, information, software and/or instructions associated with the 3GPP communication node <NUM>. For example, in various embodiments, at least one memory element <NUM> and/or storage <NUM> can be configured to store one or more of: 3GPP (e.g., E-UTRAN) instrumentation collected, received, determined and/or calculated by 3GPP communication node <NUM>; any other instrumentation associated with a 3GPP access network and/or received from user equipment; interface information (e.g., tunnel information, IP address information, UE identifying information, etc.); logic; any other data, information, software and/or instructions as discussed for various embodiments described herein (e.g., instrumentation logic <NUM> can, in some embodiments, be stored in at least one memory element <NUM> and/or storage <NUM>); combinations thereof or the like.

In various embodiments, instrumentation logic <NUM> can include instructions that, when executed (e.g., by at least one processor <NUM>) cause 3GPP communication node <NUM> to signal of 3GPP (e.g., E-UTRAN) instrumentation to LWIP controller <NUM>. In various embodiments, network interface unit <NUM> enables communication between a 3GPP communication node <NUM> and LWIP controller <NUM> and/or any other elements that may be configured for communication system <NUM> (e.g., other 3GPP communication nodes via an X2 interface). In some embodiments, network interface unit <NUM> can be configured with one or more Ethernet driver(s), Fibre Channel driver(s), controller(s), etc. or other similar network interface driver(s) and/or controller(s) to enable communications for 3GPP communication node <NUM>.

In at least one embodiment, at least one processor <NUM> of LWIP controller <NUM> is at least one hardware processor configured to execute various tasks, operations and/or functions of LWIP controller <NUM>. At least one memory element <NUM> and/or storage <NUM> can be configured to store data, information, software and/or instructions associated with the LWIP controller <NUM>. For example, in various embodiments, at least one memory element <NUM> and/or storage <NUM> can be configured to store one or more of: WLAN instrumentation; 3GPP (e.g., E-UTRAN) instrumentation; any other instrumentation associated with an access network and/or received from user equipment; metric functions, information and/or calculations; interface information (e.g., tunnel information, IP address information, UE identifying information, etc.); logic; any other data, information, software and/or instructions as discussed for various embodiments described herein (e.g., UCMP logic <NUM> can, in some embodiments, be stored in at least one memory element <NUM> and/or storage <NUM>); combinations thereof or the like.

In various embodiments, UCMP logic <NUM> can include instructions that, when executed (e.g., by at least one processor <NUM>), cause LWIP controller <NUM> to perform one or more operations including, but not limited to: receiving instrumentation from various access networks (e.g., WLAN access network <NUM> and 3GPP access network <NUM>); calculating various metrics for the access networks according to various metric functions; calculating normalized routing metrics; calculating effective normalized weights for access networks; hashing IP flow tuples; and load balancing UE IP flow(s) across access networks according to the various metrics calculated and/or received from one or more UE. In at least one embodiment, UCMP logic <NUM> can include instructions that, when executed, cause LWIP controller <NUM> to access a 3GPP Operations, Administration and Management (OAM) system (not shown) to obtain E-UTRAN instrumentation and/or metrics for a 3GPP access network.

Referring to <FIG> is a simplified block diagram illustrating example details that can be associated with WLAN communication node <NUM> in accordance with one potential embodiment of communication system <NUM>. As illustrated in the embodiment of <FIG>, WLAN communication node <NUM> can include at least one processor <NUM>, at least one memory element <NUM>, at least one storage <NUM>, instrumentation logic <NUM>, a network interface unit <NUM>, at least one transmitter <NUM>, at least one receiver <NUM> and at least one antenna <NUM>. In various embodiments, at least one transmitter <NUM>, at least one receiver <NUM> and at least one antenna <NUM> can be configured to enable OTA communications with one or more UE (e.g., UE <NUM>).

In at least one embodiment, at least one processor <NUM> is at least one hardware processor configured to execute various tasks, operations and/or functions of WLAN communication node <NUM>. At least one memory element <NUM> and/or storage <NUM> can be configured to store data, information, software and/or instructions associated with the WLAN communication node <NUM>. For example, in various embodiments, at least one memory element <NUM> and/or storage <NUM> can be configured to store one or more of: WLAN individual instrumentation collected, received, determined and/or calculated by WLAN communication node <NUM> for a particular UE communication; WLAN aggregate instrumentation collected, received, determined and/or calculated by WLAN communication node for multiple communications; any other instrumentation associated with a WLAN access network and/or received from user equipment; interface information (e.g., tunnel information, IP address information, UE identifying information, etc.); logic; any other data, information, software and/or instructions as discussed for various embodiments described herein (e.g., instrumentation logic <NUM> can, in some embodiments, be stored in at least one memory element <NUM> and/or storage <NUM>); combinations thereof or the like.

In various embodiments, instrumentation logic <NUM> can include instructions that, when executed (e.g., by at least one processor <NUM>) cause WLAN communication node <NUM> to signal of WLAN individual instrumentation to a LWIP controller (e.g., LWIP controller <NUM> of <FIG> or LWIP controller <NUM> of <FIG>) via a corresponding WLAN controller (e.g., WLAN controller <NUM>) and LWIP SeGW (e.g., LWIP SeGW <NUM>). In various embodiments, network interface unit <NUM> enables communication between WLAN communication node <NUM>, a WLAN controller, a LWIP SeGW, an LWIP controller and/or any other elements that may be configured for communication system <NUM>. In some embodiments, network interface unit <NUM> can be configured with one or more Ethernet driver(s), Fibre Channel driver(s), controller(s), etc. or other similar network interface driver(s) and/or controller(s) to enable communications for WLAN communication node <NUM>.

Referring to <FIG> is a simplified block diagram illustrating example details that can be associated with WLAN controller <NUM> in accordance with one potential embodiment of communication system <NUM>. As illustrated in the embodiment of <FIG>, WLAN controller <NUM> can include at least one processor <NUM>, at least one memory element <NUM>, at least one storage <NUM>, and a network interface unit <NUM>. In at least one embodiment, WLAN controller <NUM> can include instrumentation logic <NUM>.

In at least one embodiment, at least one processor <NUM> is at least one hardware processor configured to execute various tasks, operations and/or functions of WLAN controller <NUM>. At least one memory element <NUM> and/or storage <NUM> can be configured to store data, information, software and/or instructions associated with the WLAN controller <NUM>. For example, in various embodiments, at least one memory element <NUM> and/or storage <NUM> can be configured to store one or more of: any instrumentation associated with a WLAN access network and/or received from user equipment; interface information (e.g., tunnel information, IP address information, UE identifying information, etc.); logic; any other data, information, software and/or instructions as discussed for various embodiments described herein (e.g., instrumentation logic <NUM> can, in some embodiments, be stored in at least one memory element <NUM> and/or storage <NUM>); combinations thereof or the like.

In various embodiments, instrumentation logic <NUM> can include instructions that, when executed (e.g., by at least one processor <NUM>) cause WLAN controller <NUM> to signal of WLAN instrumentation to a LWIP controller (e.g., LWIP controller <NUM> of <FIG> or LWIP controller <NUM> of <FIG>) via a corresponding LWIP SeGW (e.g., LWIP SeGW <NUM>) for WLAN instrumentation and/or metrics collected from one or more WLAN communication nodes and/or from a RAN Management System or the like. In various embodiments, network interface unit <NUM> enables communication between WLAN controller <NUM>, an LWIP SeGW, an LWIP controller and/or any other elements that may be configured for communication system <NUM>. In some embodiments, network interface unit <NUM> can be configured with one or more Ethernet driver(s), Fibre Channel driver(s), controller(s), etc. or other similar network interface driver(s) and/or controller(s) to enable communications for WLAN controller <NUM>.

In regards to the internal structure associated with communication system <NUM>, each of respective UE <NUM>, LWIP SeGW <NUM>, MME <NUM>, SGW <NUM>, and PGW <NUM> can also include a respective at least one processor, a respective at least one memory element, a respective at least one storage, a respective network interface unit, respective logic, combinations thereof or the like to facilitate UCMP routing in an LWIP network environment. Hence, appropriate software, hardware and/or algorithms are being provisioned for communication system <NUM> in order to facilitate operations as described for various embodiments discussed herein to facilitate UCMP routing in an LWIP network environment.

In various example implementations, UE <NUM>, WLAN communication node <NUM>, WLAN controller <NUM>, LWIP SeGW <NUM>, 3GPP communication node <NUM> (as shown in <FIG> and <FIG>) and <NUM> (as shown in <FIG>), LWIP controller <NUM> (as shown in <FIG> and <FIG>) and <NUM> (as shown in <FIG>), MME <NUM>, SGW <NUM> and/or PGW <NUM> discussed for various embodiments described herein can encompass network appliances, routers, servers, switches, gateways, bridges, loadbalancers, firewalls, processors, modules, radio receivers/transmitters or any other suitable device, component, element, or object operable to exchange information that facilitates or otherwise helps to facilitate various operations as described for various embodiments discussed herein in a network environment (e.g., for networks such as those illustrated in <FIG>). In various embodiments, one or more of UE <NUM>, WLAN communication node <NUM>, WLAN controller <NUM>, LWIP SeGW <NUM>, 3GPP communication node <NUM> (as shown in <FIG> and <FIG>) and <NUM> (as shown in <FIG>), LWIP controller <NUM> (as shown in <FIG> and <FIG>) and <NUM> (as shown in <FIG>), MME <NUM>, SGW <NUM> and/or PGW <NUM> discussed herein can include software (or reciprocating software) that can coordinate in order to achieve operations associated with providing UCMP routing in an LWIP network environment as discussed herein and may include any suitable algorithms, hardware, software, components, modules, clients, interfaces, and/or objects that facilitate the operations thereof. This may be inclusive of appropriate algorithms, communication protocols, interfaces and/or standards, proprietary and/or non-proprietary that allow for the effective exchange of data or information.

In various embodiments, UE <NUM>, WLAN communication node <NUM>, WLAN controller <NUM>, LWIP SeGW <NUM>, 3GPP communication node <NUM> (as shown in <FIG> and <FIG>) and <NUM> (as shown in <FIG>), LWIP controller <NUM> (as shown in <FIG> and <FIG>) and <NUM> (as shown in <FIG>), MME <NUM>, SGW <NUM> and/or PGW <NUM> discussed herein may keep information in any suitable memory element [e.g., random access memory (RAM), read only memory (ROM), an erasable programmable read only memory (EPROM), application specific integrated circuit (ASIC), etc.], software, hardware, or in any other suitable component, device, element, and/or object where appropriate and based on particular needs. Any of the memory items discussed herein should be construed as being encompassed within the broad term 'memory element'. Information being tracked or sent to UE <NUM>, WLAN communication node <NUM>, WLAN controller <NUM>, LWIP SeGW <NUM>, 3GPP communication node <NUM> (as shown in <FIG> and <FIG>) and <NUM> (as shown in <FIG>), LWIP controller <NUM> (as shown in <FIG> and <FIG>) and <NUM> (as shown in <FIG>), MME <NUM>, SGW <NUM> and/or PGW <NUM> discussed herein could be provided in any database, register, control list, cache, storage and/or storage structure: all of which can be referenced at any suitable timeframe. Any such storage options may also be included within the broad term 'memory element' as used herein. Any of potential processing elements, controllers, managers, logic and/or machines described herein can be construed as being encompassed within the broad term 'processor'. In various embodiments, each of UE <NUM>, WLAN communication node <NUM>, WLAN controller <NUM>, LWIP SeGW <NUM>, 3GPP communication node <NUM> (as shown in <FIG> and <FIG>) and <NUM> (as shown in <FIG>), LWIP controller <NUM> (as shown in <FIG> and <FIG>) and <NUM> (as shown in <FIG>), MME <NUM>, SGW <NUM> and/or PGW <NUM> discussed herein can also include suitable interfaces for receiving, transmitting, and/or otherwise communicating data or information in a network environment.

Note that in certain example implementations, operations as outlined herein to facilitate UCMP routing in an LWIP network environment may be implemented by logic encoded in one or more tangible media, which may be inclusive of non-transitory tangible media and/or non-transitory computer readable storage media (e.g., embedded logic provided in an ASIC, in digital signal processing (DSP) instructions, software [potentially inclusive of object code and source code] to be executed by a processor, or other similar machine, etc.). In some of these instances, a memory element and/or storage [as shown in <FIG>] can store data, software, code, instructions (e.g., processor instructions), logic, parameters, combinations thereof or the like used for operations described herein. This includes memory elements and/or storage being able to store data, software, code, instructions (e.g., processor instructions), logic, parameters, combinations thereof or the like that are executed to carry out operations described herein. A processor (e.g., a hardware processor) can execute any type of instructions associated with data to achieve the operations detailed herein. In one example, a processor [as shown in <FIG>] can transform an element or an article (e.g., data, information) from one state or thing to another state or thing. In another example, operations outlined herein may be implemented with logic, which can include fixed logic, hardware logic, programmable logic, digital logic, etc. (e.g., software/computer instructions executed by a processor) and/or one or more the elements identified herein could be some type of a programmable processor, programmable digital logic (e.g., a field programmable gate array (FPGA), a DSP processor, an EPROM, a controller, an electrically erasable PROM (EEPROM) or an ASIC that includes digital logic, software, code, electronic instructions, or any suitable combination thereof.

Note that in this Specification, references to various features (e.g., elements, structures, nodes, modules, components, logic, steps, operations, characteristics, etc.) included in 'one embodiment', 'example embodiment', 'an embodiment', 'another embodiment', 'certain embodiments', 'some embodiments', 'various embodiments', 'other embodiments', 'alternative embodiment', and the like are intended to mean that any such features are included in one or more embodiments of the present disclosure, but may or may not necessarily be combined in the same embodiments. Note also that a module, engine, client, controller, function, logic or the like as used herein this Specification, can be inclusive of an executable file comprising instructions that can be understood and processed on a computer, processor, compute node, combinations thereof or the like and may further include library modules loaded during execution, object files, system files, hardware logic, software logic, or any other executable modules.

It is also important to note that the operations and steps described with reference to the preceding FIGURES illustrate only some of the possible scenarios that may be executed by, or within, the communication system <NUM>. Some of these operations may be deleted or removed where appropriate, or these steps may be modified or changed considerably without departing from the scope of the discussed concepts. In addition, the timing of these operations may be altered considerably and still achieve the results taught in this disclosure. The preceding operational flows have been offered for purposes of example and discussion. Substantial flexibility is provided by the system in that any suitable arrangements, chronologies, configurations, and timing mechanisms may be provided without departing from the teachings of the discussed concepts.

Note that with the examples provided above, as well as numerous other examples provided herein, interaction may be described in terms of one, two, three, or four network elements. However, this has been done for purposes of clarity and example only. In certain cases, it may be easier to describe one or more of the functionalities by only referencing a limited number of network elements. It should be appreciated that communication system <NUM> (and its teachings) are readily scalable and can accommodate a large number of components, as well as more complicated/sophisticated arrangements and configurations. Accordingly, the examples provided should not limit the scope or inhibit the broad teachings of communication system <NUM> as potentially applied to a myriad of other architectures.

As used herein, unless expressly stated to the contrary, use of the phrase 'at least one of', 'one or more of' and 'and/or' are open ended expressions that are both conjunctive and disjunctive in operation for any combination of named elements, conditions, or activities. For example, each of the expressions 'at least one of X, Y and Z', 'at least one of X, Y or Z', 'one or more of X, Y and Z', 'one or more of X, Y or Z' and 'A, B and/or C' can mean any of the following: <NUM>) X, but not Y and not Z; <NUM>) Y, but not X and not Z; <NUM>) Z, but not X and not Y; <NUM>) X and Y, but not Z; <NUM>) X and Z, but not Y; <NUM>) Y and Z, but not X; or <NUM>) X, Y, and Z. Additionally, unless expressly stated to the contrary, the terms 'first', 'second', 'third', etc., are intended to distinguish the particular nouns (e.g., element, condition, module, activity, operation, etc.) they modify. Unless expressly stated to the contrary, the use of these terms is not intended to indicate any type of order, rank, importance, temporal sequence, or hierarchy of the modified noun. For example, 'first X' and 'second X' are intended to designate two X elements that are not necessarily limited by any order, rank, importance, temporal sequence, or hierarchy of the two elements. As referred to herein, 'at least one of' and 'one or more of' can be represented using the '(s)' nomenclature (e.g., one or more element(s)).

Claim 1:
A method comprising:
receiving (<NUM>, <NUM>), at a long term evolution wireless local area networks radio level integration with internet protocol security tunnel, LWIP, (<NUM>) controller (<NUM>) in a first communication network (<NUM>), first instrumentation for a user equipment, UE, for the first communication network;
receiving (<NUM>, <NUM>), at the LWIP controller and from a second communication network (<NUM>), second instrumentation for the UE for the second communication network;
determining (<NUM>, <NUM>), using the LWIP controller and the first instrumentation, a first routing metric associated with the first communication network (<NUM>), wherein the first routing metric identifies a capability of the first communication network to handle an Internet Protocol (IP) flow for the UE (<NUM>);
determining (<NUM>, <NUM>), using the LWIP controller and the second instrumentation, a second routing metric associated with the second communication network (<NUM>), wherein the second routing metric identifies a capability of the second communication network to handle the IP flow for the UE and wherein the second routing metric is different from the first routing metric; and
routing (<NUM>) the IP flow for the UE using the first communication network (<NUM>) or the second communication network (<NUM>) based, at least in part, on the first routing metric and the second routing metric,
wherein first instrumentation and second instrumentation each refer to reports, measurements, calculations, or combinations thereof.