WO2019232540A1 - Optimization across mobile networks - Google Patents

Abstract

Optimization of network selection across a plurality of mobile networks. In an embodiment, first and second parameters, representing a value of incremental capacity as a function of load, are received for a first network and second network, respectively. In addition, load information is received for both networks. Then, it is determined whether or not to hand over mobile devices from a sector of the first network to a sector of the second network based on the first and second parameters and the load information. When it is determined to perform a hand over, the hand over is triggered by modifying hand-over parameters within the first network.

Description

OPTIMIZATION ACROSS MOBILE NETWORKS

CROSS-REFERENCE TO RELATED APPLICATIONS

[1] This application claims priority to U.S. Provisional Patent App. No. 62/679,680, filed on June 1, 2018, and U.S. Provisional Patent App. No. 62/809,403, filed on February 22, 2019, which are both hereby incorporated herein by reference as if set forth in full.

BACKGROUND

[2] Field of the Invention

[3] The embodiments described herein are generally directed to mobile networks, and, more particularly, to optimization of network selection across a plurality of mobile networks.

[4] Description of the Related Art

[5] In most cases today, mobile or wireless service for smartphones and other wireless devices (collectively referred to herein as“mobile devices”) is provided by utilizing a network that is owned and operated by the same company that provides the service to the end user’s device. Sometimes, the service provider to the end users has a wholesale agreement with a network owner-operator. Typically, in these cases, each specific mobile device is provisioned to use the network owned by the seller of the wholesale mobile access.

[6] In cases where the mobile device moves outside the coverage area of the primary network (e.g., referred to as the“home network” or Home Public Land Mobile Network (HPLMN)) and cannot use the primary network for obtaining mobile connectivity or data service, the mobile device may“roam” to another network (e.g., referred to as the“roaming network” or Visited Public Land Mobile Network (VPLMN)). Typical roaming agreements mandate that the roaming network accept the connection and provide the needed data capacity. However, the amount of network resources provided to the roaming mobile device may be, at least to some degree, at the discretion of the roaming network, based on some parameter settings its operator may control.

[7] Normally the mobile devices are programmed to always look for the home network signal first and, if a connection can be made, use the home network. This is typically a good strategy for the owner of the home network, who in most cases is also the service provider, because the cost of roaming is normally relatively high compared to the cost of using the home network - especially, since the marginal cost of using the service provider’s own existing network is typically very low. Roaming costs are normally based on pre-negotiated flat rates for each unit of network capacity (for example megabytes (MBs)) used by the mobile devices that are roaming.

[8] Roaming mechanisms were developed to make sure mobile devices will have coverage and an opportunity to connect when outside of their home network coverage area. In some cases, roaming steering solutions have been devised to manage which of the possible roaming partner networks a mobile device connects to when it does not have access to its home network. Roaming rates and the mobile device’s selection of a roaming network do not typically take into account the amount of network resources required from the roaming target network, nor the availability or the current state of utilization of the resources of the roaming target network.

[9] However, there can be very high variability in the amount of network resources required to provide a given amount of data to a mobile device. The biggest factor for determining the amount of resources needed is the signal-to-noise ratio (SNR) of the connection between the network node (e.g., a cell sector radio) and the mobile device. The SNR determines the efficiency of the data encoding that can be used in the communication. In a Long-Term Evolution (LTE) network, the encoding rate is selected automatically (e.g., using Link Adaptation) for each connection, and good systems can get relatively close to the theoretical maximum, which is determined by the Shannon-Hartley Theorem, a key element of information theory.

[10] The encoding rate determines the speed of communication of information over the connection. In today’s wireless communications, the practical speeds for connections to mobile devices can vary considerably. A factor of twenty between a good signal (e.g., in open space close to the cell tower) and a poor, but still useable, signal (e.g., inside a building at the cell edge) is not unusual. Given that the cost of building and operating most mobile and wireless networks are largely fixed, it makes sense to think of the duration of time of tying up the radio network resource as a good metric for measuring the resources used and for determining the cost of network use. Even though several connections are typically served simultaneously, and the resource blocks of airtime are allocated automatically among a number of mobile devices, it still comes down to the time a network radio is used (busy) to serve a specific mobile device. Since the utility from the mobile device’s perspective can be measured by the amount of data received, the encoding efficiency directly determines the actual unit cost of providing the utility to the device.

[11] In addition to the cost of providing the utility, the connection encoding rate has a direct impact on the quality of the end user’s experience, at least in terms of the connection speed on the mobile device. Since speed can be improved in a multi-user network by allocating more resources (e.g., network resource blocks) to a particular mobile device, the end user’s experience and the cost of the connection are interrelated. However, both the cost and the quality of service (QoS) improve when the signal is better and the encoding rate is higher.

[12] Another factor to consider in the actual cost of expending network resources to serve a particular mobile device is the opportunity cost of the resources. Most networks have been built to provide a certain amount of total radio-access-network-data capacity from each network node. Depending on the protocol and the network type (e.g., 2G, 3G, 4G, LTE, Wi- Fi™, etc.) and the number of mobile devices that are utilizing the network node at a given time, in some situations there may be under-utilized resources that cannot improve the QoS to the devices served. In other situations, diverting resources to a new mobile device may have an impact on the QoS of the mobile devices that are already connected to the node. In today’s roaming solutions, these kinds of value trade-offs are usually not considered.

[13] Roaming solutions today are intended to only function when the mobile device is in a situation where it may lose connection with its home network. Additionally, in today’s mechanisms for making roaming decisions for mobile devices or in charging for the capacity used by roaming devices, the current network load or the opportunity cost for the network resources provided by the target roaming partner network are not taken into account.

[14] There are some solutions that are designed to balance the load within the network of a mobile-network operator. Balancing may take place across different frequency bands in a given cellular sector or it may be across different radio access technologies (RATs). In certain situations, load balancing may also be possible across different cell sectors in the same network. This would be the case when a certain location with active mobile devices can be served by multiple cells at a certain location. These solutions generally have relatively simple objectives, for example, to balance the load evenly across frequency bands or to avoid load levels in any sector or frequency band that exceed a certain limit. They do not generally consider the value trade-offs between avoiding load in certain sectors (e.g., that may be more expensive or difficult to upgrade) or the differences in the value of providing a good user experience to some subset of subscribers that may be paying a premium for their subscriptions. These load-balancing systems are sometimes referred to as self-organizing or self-optimizing networks (SONs). They may react to an outage of a cell sector or to a sudden increase of load in a certain area of a network. Sometimes SON systems include the ability to reconfigure the antenna systems, for example, by changing the antenna tilt electronically. [15] There are also systems for affecting the choice of the roaming partner in situations when the device does not have home-network coverage and may have more than one roaming partner from which to choose. These solutions may rely on Subscriber Identity Module (SIM) card-based mechanisms to steer the roaming partner selection, or they may use network-side controls. These roaming steering solutions are designed to only affect the roaming network choice when the home network coverage may not continue to be available or is inadequate.

SUMMARY

[16] Accordingly, systems, methods, and non-transitory computer-readable media are disclosed for optimized network selection across a plurality of mobile networks.

[17] In an embodiment, a method is disclosed that comprises using at least one hardware processor of a server to: receive first parameters representing a value of incremental capacity as a function of a load within a first sector of a first network; receive second parameters representing a value of incremental capacity as a function of a load within a second sector of a second network, wherein the second network is different than the first network, and wherein the second sector overlaps the first sector; receive first load information representing a load within the first sector; receive second load information representing a load within the second sector; determine whether or not to hand over one or more mobile devices, within an overlap area of the first sector and the second sector, from the first sector of the first network to the second sector of the second network based on the first parameters, the second parameters, the first load information, and the second load information; and, when determining to hand over one or more mobile devices from the first sector to the second sector, modifying values of hand-over parameters within the first network to trigger the hand over of the one or more mobile devices from the first sector to the second sector. The first network may be operated by a first operator and the first parameters may be received from the first operator, and the second network may be operated by a second operator, that is different than the first operator, and the second parameters may be received from the second operator.

[18] Modifying values of hand-over parameters within the first network to trigger the hand over of the one or more mobile devices may comprise: determining a number of mobile devices to hand over from the first sector to the second sector; and modifying the values of the hand-over parameters so as to trigger a hand over of the determined number of mobile devices from the first sector to the second sector.

[19] Modifying values of hand-over parameters within the first network may comprise including a network identifier of the second network and a physical cell identifier of the second sector in a configuration message transmitted by the first network to the one or more mobile devices. Modifying values of hand-over parameters within the first network may further comprise setting a cell individual offset (CIO) parameter for the second sector. The method may further comprise adjusting the CIO parameter for the second sector based on the determined number of mobile devices. Adjusting the CIO parameter may comrpise increasing the CIO parameter to increase the number of mobile devices to be handed over, and decreasing the CIO parameter to decrease the number of mobile devices to be handed over. Modifying the values of hand-over parameters within the first network may comprise adjusting an A3 offset of the first sector. Adjusting the A3 offset may comprise increasing the A3 offset to reduce the number of mobile devices to be handed over, and decreasing the A3 offset to increase the number of mobile devices to be handed over. Modifying the values of hand-over parameters within the first network may further comprise adjusting a cell individual offset (CIO) parameter for one or more other sectors within the first network. Modifying the values of hand-over parameters within the first network may comprise adjusting one or both of an event Al threshold and an event A2 threshold in the first sector.

[20] The first load information may be received from a self-optimizing network (SON) system of the first network via an application programming interface (API), and the second load information may be received from a SON system of the second network via an API. The first load information may be received in periodic intervals from the first network, and the second load information may be received in periodic intervals from the second network. Determining whether or not to hand over one or more mobile devices may comprise determining to hand over one or more mobile devices when the load within the first sector exceeds a load threshold.

[21] The value of incremental capacity in the first parameters may comprise a buy price, and the value of incremental capacity in the second parameters may comprise a sell price.

[22] Modifying values of hand-over parameters within the first network to trigger the hand over of the one or more mobile devices from the first sector to the second sector may comprise, over two or more iterations: modifying the values of the hand-over parameters; subsequently receiving first load feedback representing the load within the first sector after the modification of the values of the hand-over parameters; subsequently receiving second load feedback representing the load within the second sector after the modification of the values of the hand-over parameters; and determining whether or not to perform another one of the two or more iterations based on the first parameters, the second parameters, the first load feedback, and the second load feedback. The two or more iterations may be performed until the value of incremental capacity as a function of the first load feedback equals the value of incremental capacity as a function of the second load feedback. In a second one of the two or more iterations, following a first one of the two or more iterations, the values of the hand-over parameters may be modified in proportion to one or both of a difference in the first load information from the first load feedback or a difference in the second load information from the second load feedback.

[23] The method may further comprise using the at least one hardware processor to track data capacity in the second network that is consumed by the one or more mobile devices in association with the value of incremental capacity in one or both of the first parameters and the second parameters.

[24] The method may be embodied in executable software modules of a processor- based system, such as a server, and/or in executable instructions stored in a non-transitory computer-readable medium.

BRIEF DESCRIPTION OF THE DRAWINGS

[25] The details of the present invention, both as to its structure and operation, may be gleaned in part by study of the accompanying drawings, in which like reference numerals refer to like parts, and in which:

[26] FIG. 1 illustrates an example infrastructure, in which one or more of the processes described herein, may be implemented, according to an embodiment;

[27] FIG. 2 illustrates an example processing system, by which one or more of the processed described herein, may be executed, according to an embodiment;

[28] FIG. 3 illustrates the relationship of functions and physical components in the disclosed system, according to an embodiment;

[29] FIG. 4 illustrates a situation in two overlapping networks, according to an embodiment;

[30] FIG. 5 illustrates an example of a call flow in a network handover scenario, according to an embodiment; [31] FIG. 6 illustrates the relationship between network performance and distance and load, according to an embodiment;

[32] FIG. 7A and 7B illustrate the value of incremental capacity to a network operator, according to an embodiment;

[33] FIG. 8 A and 8B illustrate values of capacity, according to an embodiment;

[34] FIG. 9 illustrates example thresholds and offsets, according to an embodiment; and

[35] FIG. 10 illustrates values of incremental capacity, according to an embodiment.

DETAILED DESCRIPTION

[36] In an embodiment, systems, methods, and non-transitory computer-readable media are disclosed for optimized network selection across a plurality of mobile networks. After reading this description, it will become apparent to one skilled in the art how to implement the invention in various alternative embodiments and alternative applications. However, although various embodiments of the present invention will be described herein, it is understood that these embodiments are presented by way of example and illustration only, and not limitation. As such, this detailed description of various embodiments should not be construed to limit the scope or breadth of the present invention as set forth in the appended claims.

[37] 1. System Overview

[38] 1.1. Infrastructure

[39] FIG. 1A illustrates an example system for bandwidth exchange, according to an embodiment. Embodiments of the system enable service providers for mobile devices and network service providers of home or alternative networks to manage network selection for the mobile devices and conduct micro-commerce on bandwidth or data connectivity, based on one or more parameters pertaining to the characteristics of the available connections to alternative wireless networks and the current situation of the network and device operations.

[40] The bandwidth exchange may be implemented as a bandwidth exchange (BX) platform 110 (e.g., one or more servers) which hosts and/or executes one or more of the various functions, processes, methods, and/or software modules described herein. Platform 110 may comprise dedicated servers, or may instead comprise cloud instances, which utilize shared resources of one or more servers. These servers or cloud instances may be collocated and/or geographically distributed.

[41] Platform 110 may be communicatively connected via one or more networks (e.g., the Internet) to a home network 150 (e.g., a cellular network) and one or more alternative networks 160 (e.g., a cellular roaming network or Wi-Fi™ network) - either of which may provide communication between platform 110 and one or more mobile devices 170 (also referred to herein as“user equipment” (UE)). Home network 150 may comprise a cellular network, and alternative network 160 may comprise a cellular network or a non-cellular network (e.g., a Wi-Fi™ network). A cellular network may utilize 2G (e.g., GSM, GPRS, EDGE, iDEN, TDMA, CDMA), 3G (e.g, CDMA2000, 1X-EVDO, WCDMA, UMTS, HSPA), 4G (e.g., LTE, LTE-A), 5G, and/or the like, whereas a non-cellular network may utilize, for example, one or more of the family of 802.11 standards from The Institute of Electrical and Electronic Engineers (IEEE), or other non-cellular network standards. Home network 150 may be operated by a mobile network operator (MNO), a mobile virtual network operator (MVNO), or a wireless service provider. Alternative network 160 may be operated by a MNO, a MVNO, or a wireless service provider, or may be a free Wi-Fi™ service (e.g., a home Wi-Fi™ network, a Wi-Fi™ service provided by a city library, a business, etc.), or a paid Wi-Fi™ service (e.g., offered by an Internet service provider). While only one home network 150, one alternative network 160, and one UE 170 are illustrated, it should be understood that platform 110 may communicate with any number of home networks, alternative networks, access points, and UEs. In addition, UEs 170 may comprise any type or types of computing devices capable of wireless communication, including without limitation, laptop computers, tablet computers, smart phones or other mobile phones, servers, game consoles, televisions, set-top boxes, electronic kiosks, point-of-sale terminals, Automated Teller Machines, and the like.

[42] Each UE 170 (also referred to herein as a“wireless device” or“mobile device”) may comprise a first radio system, a second radio system, a client software application (e.g., a BX application), and a local database. Each UE 170 may be configured to turn on or off one or both of the first and second radio systems independently of each other. The first radio system uses a first wireless communication protocol (e.g., a protocol used for a cellular network) to wirelessly connect to an access point (e.g., a cellular base station providing or otherwise serving one or more sectors of a cellular network), which provides access to home network 150 or alternative network 160. The second radio system uses a second wireless communication protocol (e.g., Wi-Fi™) to wirelessly connect to an access point (e.g., a Wi- Fi™ access point), which provides access to alternative network 160. It should be understood that the first wireless communication protocol may be different from the second wireless communication protocol.

[43] Platform 110 may comprise web servers which host one or more websites and/or web services. In embodiments in which a website is provided, the website may comprise one or more user interfaces, including, for example, webpages generated in HyperText Markup Language (HTML) or other language. Platform 110 transmits or serves these user interfaces in response to requests from user systems (e.g., of MNOs). In some embodiments, these user interfaces may be served in the form of a wizard, in which case two or more user interfaces may be served in a sequential manner, and one or more of the sequential user interfaces may depend on an interaction of the user or user system with one or more preceding user interfaces. The requests to platform 110 and the responses from platform 110, including the user interfaces, may both be communicated through one or more networks, which may include the Internet, using standard communication protocols (e.g., Hypertext Transfer Protocol (HTTP), HTTP Secure (HTTPS), etc.). These user interfaces or web pages may comprise a combination of content and elements, such as text, images, videos, animations, references (e.g., hyperlinks), frames, inputs (e.g., textboxes, text areas, checkboxes, radio buttons, drop-down menus, buttons, forms, etc.), scripts (e.g., JavaScript), and the like, including elements comprising or derived from data stored in one or more databases that are locally and/or remotely accessible to platform 110.

[44] In embodiments in which a web service is provided, platform 110 may receive requests from one or more external systems, and provide responses in extensible Markup Language (XML) and/or any other suitable or desired format. In such embodiments, platform 110 may provide an application programming interface (API) which defines the manner in which the external systems (e.g., an application executed on a UE 170, server, or other device) may interact with the web service. Thus, the external systems, can define their own user interfaces, and rely on the web service to implement or otherwise provide the backend processes, methods, functionality, storage, etc., described herein. For example, in such an embodiment, a client application (e.g., BX application comprising proposal engine 120D, selection engine 130D, and/or accounting engine 140D) executing on one or more UEs 170 may interact with a server application executing on platform 110 to execute one or more or a portion of one or more of the various functions, processes, methods, and/or software modules described herein. The client application may be“thin,” in which case processing is primarily carried out server-side by the server application on platform 110. Alternatively, the client application may be“thick,” in which case processing is primarily carried out client-side by the external system. It should be understood that the client application may perform an amount of processing, relative to the server application on platform 110, at any point along this spectrum between“thin” and“thick,” depending on the design goals of the particular implementation. In any case, the software described herein, which may wholly reside on either platform 110 or UEs 170, or be distributed between platform 110 and UEs 170, can comprise one or more executable software modules that implement one or more of the processes, methods, or functions described herein.

[45] The BX market can be formed by agreements with wireless operators/service providers and/or individual wireless device users, as well as with a number of individuals or companies that own or control alternative radio access resources. The BX market may be implemented by combinations of a proposal engine 120, a selection engine 130, and an accounting engine 140. Proposal engine 120 and accounting engine 140 may reside in (e.g., be executed as software modules by a processor of) platform 110, home network 150, alternative network 160 (e.g., a processor of an access point of alternative network 160), and/or UE 170. Selection engine 130 may reside on platform 110 and/or EGE 170.

[46] 1.1.1 Proposal Engine

[47] In an embodiment, proposal engine 120 provides access or a reference to the terms and conditions 122 for using a particular connection or connections. In particular, each proposal engine 120 is associated with an alternative network 160 and provides selection engine 130 with information about the connection to the alternative network 160. This information may include the terms and conditions 122, as well as detailed information about the characteristics of the connection to the alternative network 160. For example, the information provided by proposal engine 120, as terms and conditions 122, may include one or more of the following parameters:

[48] (1) Price(s) of using the connection, which may vary according to the time of day or the day of month or year, and which may change dynamically in response to the current demand from other selection engines 130.

[49] (2) Level of security available for using the connection.

[50] (3) Historical data about bandwidth, data rate, throughput, packet loss, stability, jitter, and/or other performance characteristics of the connection. Selection engine 130 may use this data, but may have EGE 170 conduct its own tests to determine the bandwidth and/or other performance characteristics of the connection (e.g., jitter, packet delays of retransmissions during the connection, etc.), and makes its own determination about the quality of the connection.

[51] (4) Sponsorship for or promotions related to the connection (e.g., websites or specific promotions available or required through the connection). For example, some connections may be sponsored by advertisers. In that case, the nature of the products being advertised and/or the frequency and obtrusiveness of the advertisements may be communicated by proposal engine 120 to selection engine 130, such that selection engine 130 may consider the connection based on this information. Some end users may be interested in advertisements on certain topics (e.g., topics close to the end users’ hearts), but may wish to avoid connections which will require advertisements on other topics or certain undesired topics.

[52] (5) Quality of the connection (e.g., Internet connection provided through the connection); and/or

[53] (6) Special instructions from the operator of home network 150 and/or the end user of UE 170.

[54] The set of parameters used in the selection process will depend on the complexity of the given proposal engine 120 and selection engine 130. For example, a less sophisticated selection engine 130 may only be capable of selecting a connection based on signal strength and price. However, a more sophisticated selection engine 130 may be capable of considering more information and alternatives in the terms and conditions 122, provided by a proposal engine 120, to thereby increase its capabilities.

[55] Other information, pertaining to terms and conditions 122 of using an access point, may be relevant. For example, some access points may belong to a network of hotspots controlled by a wireless operator or wireless Internet Service Provider (ISP) that offers fixed-fee or other special pricing to subscribers of their services. If the end user of UE 170 is a subscriber to such a hotspot network, terms and conditions 122 would normally be stored in proposal engine 120D, and the hotspot access point would provide information identifying that it belongs to the hotspot network (for example in its SSID). Alternatively or additionally, proposal engine 120 (e.g., proposal engine 120C) for the access point may provide the indication that the access point belongs to the hotspot network.

[56] There may be special information transmitted by the UE’s home network 150. For example, from the home-network operator’s point of view, the desirability to offload a UE 170 to alternative network 160 may depend on the load within the sector (e.g., on the cellular tower) of home network 150 to which UE 170 is connected. To manage the connections in an optimal way, BX platform 110 may instruct selection engine 130 for a UE 170 in a particular sector of home network 150 and/or at a particular time to seek the lowest price alternative even when a connection to home network 150 is available (e.g., if the load on that sector is above a threshold).

[57] Proposal engine 120 may be implemented as a module on an access point of alternative network 160 (e.g., proposal engine 120C), elsewhere within alternative network 160, and/or on BX platform 110. A proposal engine 120, associated with an access point, provides information about that access point (e.g., the availability, connectivity services provided, and/or other information) to UEs 170 (e.g., to selection engine(s) 130 associated with each UE 170). This information may include the terms and conditions, including the price, of using connectivity through the access point, and may include detailed information about the characteristics of the connection to alternative network 160 provided by the access point. Implementations of proposal engine 120 may vary depending on the sophistication and capabilities of the access point, the organization or individual that owns or controls the access point, and/or the technical and business arrangements that provide the connectivity (e.g., Internet connectivity) for the access point.

[58] In some implementations or scenarios, a proposal engine 120, associated with an access point, may reside outside the access point (e.g., on another computing device in alternative network 160 or on BX platform 110). This allows access points that can only broadcast their Service Set Identifiers (SSIDs) and/or unique identifiers (e.g., a Basic SSID (BSSID), Media Access Control (MAC) address, etc.) to be used in the bandwidth exchange market to provide connectivity services to UEs 170.

[59] Selection engines 130 of UEs 170 that can receive the beacons of an access point can obtain the terms and conditions and other information from BX platform 110, using the identifying information (e.g., SSID, a BSSID, MAC address, or other unique identifier) of the access point as a reference. This may be facilitated by including, in the SSID of the access point, an indication or information about its participation in alternative network 160 (e.g., by including a specific character string in the SSID). Thus, selection engine 130 may check for the terms and conditions for a given access point without having to go through lists of participating access points’ identifiers. In an embodiment, BX platform 110 may periodically download unique identifiers (e.g., BSSIDs MAC addresses, etc.), SSIDs, locations, associated terms and conditions, and/or any other information about participating access points to alternative network 160 that are located in the vicinity of the current location of UE 170. This expedites access to the relevant terms and conditions, and makes it possible to have this information available at UE 170, even in situations where UE 170 does not have an open data connection to the Internet or BX platform 110 (e.g., EE 170 is not able to see a cellular access point or is a Wi-Fi™ only device). The current location of the EE 170 can be obtained from a GPS system, if available, or by having the access point transmit identifiers of access points in its range (e.g., regardless of whether or not the access points are registered with BX platform 110) and having BX platform 110 correlate these access point identifiers to a database of access point locations. If the location of a EE 170 is constantly changing (e.g., because EE 170 is moving in a vehicle), BX platform 110 can extend the range of access points, to include in the list of access points transmitted to EE 170, in the direction of the EE’s movement. The downloads may be scheduled to happen at regular intervals or they may be scheduled to take place every time a EE 170 has network access (possibly establishing a minimum interval between downloads). This enables EEs 170 that only have one radio system (e.g., Wi-Fi™ radio system) to utilize the bandwidth exchange.

[60] In an embodiment, a EE 170 may trigger or request information about available access points (e.g., access points not already configured for use by EE 170) from BX platform 110. For example, EE 170 may provide its current location to BX platform 110. In response, BX platform 110 may compile one or more access points (e.g., a list of access points within the vicinity of the EE’s current location and/or available for use by EE 170) that have been registered to provide connectivity services in alternative network 160. BX platform 110 may provide this list (e.g., via a download over home network 150 or alternative network 160) to EE 170. The list may include, for each access point, one or more of the following:

[61] (1) Party that is offering the connectivity service.

[62] (2) Offered price that can be used in all circumstances, for at least a minimum time period (e.g., few minutes), until EE 170 can connect to BX platform 110 to get an updated price. This allows EE 170 to connect to alternative network 160, even when EE 170 is a Wi-Fi™ only device or when conditions make it impractical to get a current price over home network 150 (e.g., due to congestion or EE 170 being out of coverage of home network 150). The offered price may be specific to EE 170, a type of EE 170, the end user of EE 170, a class of end users, a time of day, a day of week or month, and/or the like. BX platform 110 can be aware of the attributes of EE 170, and may tailor the offered price in accordance with those attributes.

[63] (3) Sponsor(s). A sponsor is a party that pays for the connectivity services. For example, a cellular or Internet service provider may pay for services made available to its subscribers, a business (e.g., coffee shop, online gaming provider, etc.) may pay for services made available to its patrons, and/or the like.

[64] The list of access points, provided by BX platform 110, may include information for a number of access points within a certain radius (e.g., ten miles) of the current location of UE 170 or a location specified by the end user of UE 170 (e.g., via a user interface). Selection engine 130D of EE 170 may scan for available access points and compare the connectivity options provided by the visible access points based on rules and policies 132. This comparison may include measuring the performance characteristics (e.g., signal strengths, data speed) of one or more visible access points. Selection engine 130D combines the information from BX platform 110 with the measured performance characteristics to make a selection of a connection. For example, rules and policies 132 may provide that: (1) if the performance characteristic (e.g., signal strength) is above a threshold (e.g., set to indicate adequate performance) for two or more visible access points, select the access point offering the lowest price; and (2) if the performance characteristic (e.g., signal strength) is below the threshold for all of the visible access points, select the access point having the highest signal strength. Once a connection has been established, it may be reevaluated, according to rules and policies 132, if the performance characteristic falls below a set threshold or at regular intervals. In the case that intervals are used, the intervals may be static or may depend on the price of the current connection or any other parameter known to EE 170.

[65] When a EE 170 establishes a new connection, one or more communications on the previously existing connection may be transferred to the new connection, prior to termination of the previously existing connection. In other words, EE 170 may associate communication with the access point supporting the new connection and disassociate the communication with the access point supporting the previously existing connection. In addition, EE 170 may send a usage report for the previously existing connection (e.g., once it has been terminated, assuming it is registered with BX platform 110) to BX platform 110 over the new connection. BX platform 110 may store this usage report for billing, payment, analysis, and/or other purposes.

[66] In an embodiment, an access point of alternative network 160 may execute a proposal engine 120C that stores the terms and conditions 122 for using the services provided by the access point, along with other information, and provide these terms and conditions 122 and/or other information directly over the wireless link to a selection engine 130D of each EE 170 that requests to receive them. This can be done using the 802. l lu standard, if both devices are capable of using this protocol. A multi-round, two-way negotiation (or an auction) about terms and conditions 122 may be automatically carried out between UE 170 and the access point of alternative network 160. In this case, the access point may offer a price, UE 170 may counter with a lower price, the policies in the access point may enable it to offer another price based on the counter offer, and so on and so forth. In some environments, a subset of access points may have internal proposal engines 120C, while another subset of access points rely on proposal engines within alternative network 160 or on BX platform 110 (i.e., proposal engine 120A).

[67] Terms and conditions 122 may have short periods of validity, and connectivity may be re-negotiated at specific intervals, as situations in terms of need and available capacity will constantly vary. In the event that an access point is managed by proposal engine 120A on BX platform 110, terms and conditions 122 for that access point, including the validity periods for terms and conditions 122, may be automatically downloaded to UEs 170. In the event that the access point is managed by proposal engine 120A and UE 170 is managed by selection engine 130A on BX platform 110, terms and conditions 122, including their validity periods, may be made available to both proposal engine 120 A and selection engine 130A. In some implementations, BX platform 110 can instruct a UE 170 to immediately terminate a connection with an access point and/or temporarily or permanently block UE 170 from attempting to connect to that access point.

[68] 1.1.2 Selection Engine

[69] A UE 170 that participates in the BX market may have the ability to establish multiple wireless connections and/or change one or more wireless connections. For simplicity a system that utilizes both Wi-Fi™ and cellular wireless connections is described, but different implementations can use any combination of these and other available wireless technologies. Selection engine 130 (e.g., selection engine 130A and/or selection engine 130D) manages this connectivity for UEs 170 through a connection between each UE 170 and BX platform 110. Selection engine 130 bases its operation on rules and policies 132 (e.g., rules and policies 132A and/or rules and policies 132D) that have been set by the wireless operator and/or the end-user of UE 170. In some implementations, there is a selection engine 130 on both UE 170 and BX platform 110. These two selection engines 130A and 130D operate in tandem using the rules and policies 132A and 132D, respectively. In some cases, rules and policies 132A are controlled by the operator, and rules and policies 132D are controlled by the user. There can be a set of default rules and policies 132, so that the user does not need to do anything to begin participating in the BX market.

[70] In an embodiment, selection engine 130D and rules and policies 132D, together with information about access points to alternative network 160 within the sector or other vicinity of UE 170, may be downloaded to UE 170, and subsequently used to make an initial decision of whether or not to establish a connection to alternative network 160, even when no other network connection is available. This initial decision may be based on a set of rules and policies 132D that is simpler and less dynamic, for example, than rules and policies 132A. Once a connection to BX platform 110 and selection engine 130A can be established, selection engine 130A can use rules and policies 132A (e.g., together with additional information, such as price, performance characteristics, etc.) to revisit and possibly revise the initial selection. Rules and policies 132A may be updated more frequently than rules and policies 132D. In the event that the initial selection is revisited and revised to abandon the connection based on rules and policies 132A, there may be a minimum time period that must elapse before the connection is severed, in order to avoid the negative user experience that may result from a momentary connection.

[71] EE 170 may comprise mobile equipment (ME), a user identity module, and a BX application (e.g., a client application executed by a processor of EE 170) stored in the memory of the device (e.g., along with other applications). Each EE 170 that participates in the bandwidth exchange may have the ability to establish multiple wireless connections, for example, via multiple technologies (e.g., 2G, 3G, 4G/LTE, 5G, Wi-Fi™, Bluetooth™, mobile satellite service, and/or any other wireless radio access). Selection engine 130 manages the connectivity available to EE 170.

[72] In an embodiment, selection engine 130 can operate independently of EE 170 on any system (e.g., platform 110) that communicates with a standard authentication server. Alternatively, selection engine 130 may operate as a cooperative combination of functions executed on EE 170, platform 110, and the authentication server. When the selection engine 130 for a given EE 170 is executed on platform 110, the selection engine 130 may manage the EE’s connections through a network connection (e.g., through home network 150 or alternative network 160). Selection engine 130 may base its management operation on rules and policies 132. Rules and policies 132 may be set by the home network operator, alternative network operator, and/or the end user of EE 170.

[73] In an embodiment, a selection engine 130A is executed by a platform 110 and a selection engine 130D is executed by EE 170. In this case, selection engines 130A and 130D may operate in tandem using both rules and policies 132A, stored on platform 110, and rules and policies 132D, stored on UE 170. Rules and policies 132A may be controlled by the home and/or alternative network providers, whereas rules and policies 132D may be controlled at the discretion of the end user of UE 170. A default set of rules and policies 132D may be provided, so that the user does not need to do anything to activate the system.

[74] Rules and policies 132 control which of the connection(s), available to a UE 170, will be selected at any given time. The level of sophistication and complexity in the selection process of selection engine 130 may vary for different implementations. For example, one or more of the following parameters may be considered during the selection process:

[75] (1) Price and/or other terms and conditions for using the services offered by an access point of alternative network 160 (i.e., the ask price). These may be provided by proposal engine 120. The ask price may be specific to a particular access point or group of access points, and may depend on a number of factors, including the time of day, day of the week or month, dynamic network operating parameters (e.g., load), and/or any other information available to proposal engine 120. The ask price may also depend on the characteristics and parameters associated with UE 170 (e.g., the service provider of home network 150). The ask price may also depend on the buyer of the wireless services (e.g., the end user of UE 170 or service provider of home network 150). For example, if the end user of UE 170 has a subscription with a certain service provider (e.g., cable broadband service provider) and the particular access point of alternative network 160 belongs to a network of the service provider or an affiliate or partner of the service provider (e.g., a provider of hotspots), the ask price for that particular end user may be zero. The ask price for other end users, who do not have such a subscription, may be non-zero.

[76] (2) Price and/or other terms and conditions offered by the buyer for using services of an access point of alternative network 160 (i.e., the bid price). The bid price may depend on a number of factors, including the time of day, day of the week or month, dynamic network operating parameters (e.g., load) of home network 150, information about UE 170, the end user’s contract with a service provider of home network 150, the end user’s association with other organization(s), and/or any other information available to selection engine 130.

[77] (3) Quality of the signal from the access point providing the connection, based on a measurement of signal strength (e.g., received signal strength indication (RSSI), signal-to-noise ratio (SNR), signal-to-interference-plus-noise ratio (SINR)) or any other relevant parameter that may be detected by each radio system of UE 170 for which a connection is available.

[78] (4) Level of security available for using the connection.

[79] (5) Traffic load on the network providing the connection (e.g., physical resource block usage, peak or busy-hour traffic, etc.).

[80] (6) Throughput capacity of the connection.

[81] (7) Reliability (e.g., packet loss) of the connection.

[82] (8) Latency and jitter of the connection.

[83] (9) Bandwidth, or any other specific characteristic of connectivity, needed by each application executing or to be executed on UE 170.

[84] (10) Specific application, executing on UE 170, that is requesting or using the services provided by the access point of alternative network 160.

[85] (11) Specific service (e.g., website being accessed) to which UE 170 (e.g., an application executing on UE 170) is requesting access.

[86] (12) Sponsorship for or promotions related to the connection (e.g., websites or specific promotions available or required through the connection);

[87] (l3) Buyer(s) for the service. For a specific service, the service provider of home network 150 may be requesting access to the service, but the buyer may be a sponsor of the service, such as a company that provides access to data services when a specific application is being executed in the foreground or is the main active application on UE 170. The buyer could also be the service provider of home network or the end user of UE 170. Each potential buyer of a particular service may have a different bid price.

[88] (14) Acceptability, to an application or the end user, of a delay in transmitting data from UE 170 to the network or transmitting data from the network to UE 170. For example, an application provider or end user may specify an acceptable delay for a data transmission in terms of a time that may elapse between the request to transmit the data and the actual transmission of the data. Thus, an end user could specify that a delay of one hour is acceptable for uploading photographs to a website (e.g., social media site). In this case, selection engine 130 may wait up to one hour to see if a free or cheap connection (i.e., zero price or price below a certain threshold) becomes available for the upload. If the one hour elapses without such a connection becoming available, selection engine 130 may then select a connection with a higher cost (i.e., non-zero price or price above the certain threshold). Different acceptable delays may be set for different cost levels or other characteristics of the connection (e.g., terms and conditions other than price). [89] (15) Estimated drain on battery power in UE 170 resulting from use of the connection.

[90] (16) Speed, reliability, or other performance characteristics of any alternative connection available to EGE 170 (e.g., a connection that EGE 170 is currently using or has used in the past). For example, if the data transfer speed of a connection, provided to EGE 170 by the mobile network operator with whom the end user has an agreement, falls below a set threshold, the selection decision may be affected. As another example, if EGE 170 is connected to an access point of alternative network 160, but the data transfer speed, packet loss, or other performance characteristic falls below a set threshold, a prior selection decision could be revisited using this information about the existing connection.

[91] (17) Result of a speed test or other performance test of a connection. EGE 170 may conduct a speed test or other performance test of its connection to an access point at any time (e.g., immediately after initially establishing the connection). The performance test may be based on observing the data access speed of another application that is communicating over the connection, or it may comprise a speed test that is specifically initiated by EGE 170 to check the quality of a new connection immediately after establishing the connection. If the result of the test indicates that the tested performance characteristic (e.g., speed) is below a set threshold (which may depend on EGE 170 and/or applications using the connection), selection engine 130 may reverse the decision to select the particular access point and/or network for the connection and select a new access point and/or network. In an implementation, the performance test utilizes criteria that include the data transmission speed observed immediately before connecting to a new access point. For example, the decision to connect may be reversed if the data transmission speed is not higher than the speed observed before connecting to the new access point.

[92] (18) Geographic location of EGE 170.

[93] (19) Radio (e.g., cellular base station) to which EGE 170 is connected.

[94] (20) Information about the movement of EGE 170, as determined, for example, from motion sensors or accelerometers on EGE 170 or from tracking Global Positioning System (GPS) data collected by EGE 170.

[95] (21) Special instructions, for example, from the network operator(s), EGE 170 end users, and/or access point operator(s).

[96] In some instances, some of the connection alternatives may have lower cost or be free. For example, one or more access points of alternative network 160 may be sponsored by a business that provides free wireless access in exchange for acceptance of commercial messages and advertising. Free access to certain websites or services may be provided by certain companies (e.g., gaming companies) or by certain applications (e.g., gaming applications). Service providers or vendors may sponsor connectivity that allows the end user to visit the provider’s or vendor’s website to make purchases. Other access points may offer lower cost or free connectivity, but require the right to collect location-based information of the end user or may require responses from the end user to survey(s). One example of collecting useful location-based information would be to collect the GPS location of UEs 170 at specific intervals (e.g., to measure the speed of traffic flows on roads and freeways). This could be a commitment by the end user of UE 170 that would be valid, even when UE 170 is connected through home network 150, and which could earn privileges to use alternative network 160 as a form of compensation.

[97] Selection engine 160 may select which data connection to use for each of the applications executing on UE 170. In one embodiment, these selections are performed on a real-time, moment-to-moment basis, using the rules and policies 132 and current information about each available connection (e.g., price and/or other parameters listed above). This information may be available directly from the access point, for example, by using the 802. l lu communication standard, or it may be obtained from BX platform 110 based on a reference system.

[98] In an embodiment, selection engine 130 uses rules and polices 132, set by the operator of BX platform 110 and/or the end user of UE 170, that authorizes the use of connections based on a combination of two main parameters: the speed or other performance characteristic of the connection that is currently available to UE 170 from home network 150; and the cost of an alternative connection available to UE 170 through alternative network 160. Rules and policies 132 may have thresholds for the performance characteristic and the cost. The thresholds may be tiered. For example, selection engine 130 may offload a UE 170 from home network 150 to alternative network 160 under either of the following tiered conditions: a) offload a UE 170 from home network 150 to alternative network 160 to increase its data speed that is below 5 Mbps for up to fifty cents per time period; b) offload a UE 170 from home network 150 to alternative network 160 to increase its data speed that is below 1 Mbps for a price of up to two dollars per time period; and so on and so forth.

[99] In an embodiment in which selection engine 130 is at least primarily hosted on BX platform 110, UE 170 will send the set of selection parameters to selection engine 130A on BX platform 110, and selection engine 130A will return to UE 170, the identifying information and necessary authentication information for connecting to a connectivity provider that will provide the selected connection.

[100] In an alternative embodiment in which selection engine 130 is at least primarily hosted on UE 170, selection engine 130D on UE 170 will use the available selection parameters (e.g., from proposal engine 120) to make the selection of an access point through which it will establish a connection. EE 170 may then communicate this information to BX platform 110 and responsively receive the authentication information that will enable the connection. The authentication information can be transmitted and/or exchanged using a protocol (e.g., 802. lx, Extensible Authentication Protocol (EAP), etc.) that is the same or different from the protocol used in communication.

[101] In an embodiment, selection engine 130 compares the ask price and bid price, which may both depend on a number of parameters as described above. If the ask price (e.g., plus a possible commission or other compensation for the operator of BX platform 110) is lower than the bid price, selection engine 130 establishes a clearing price for the connectivity service. This price may be a price per byte transmitted, price per time of connectivity, or any other unit of pricing. The clearing price is then applied by accounting engine 140 to establish the necessary payments and settlements between the buyer and the seller of the connectivity service.

[102] Once a connection is selected, selection engine 130 may provide, to EE 170, any information that is necessary to establish the connection through the selected access point. This information may include authentication and authorization information. The authentication and authorization information may include wireless passphrases or passwords, account identification information and passwords, credentials for an access control gateway, detailed information about how to post a user name and password to a captive portal, digital certificates, and/or other access control tokens and parameters. Selection engine 130 controls these authentication and authorization elements, which may be stored in encrypted form in a database of selection engine 130A and/or 130D. If the authentication and authorization elements are stored in selection engine 130D on EE 170, the elements may be downloaded together with other information about the access points in the vicinity of EE 170. These authentication and authorization elements may have expiration times and may be refreshed at regular intervals. The authentication and authorization elements are made available to the EE’s connection functions only at the time of connection and are subsequently erased from the EE’s memory. The end user will not have any access or visibility to the authentication or authorization information, used by selection engine 130, except in implementations or scenarios in which the end user must manually provide such information to connection functions of UE 170.

[103] In an embodiment, based on the connection selections and measured data traffic through each connection, UE 170 generates a detailed record on the actual use of each connection to alternative network 160, utilizing accounting engine 140. At intervals, accounting engine 140 transmits the usage record to BX platform 110, including identifying information of UE 170 and/or the end user and identifying information of each of the access points that provided each used connection. The usage record may also identify the selected buyer of each connection, include the negotiated price for each connection, indicate the terms and conditions in force at the time the connection was used, and/or include connection parameters. The reporting of connection parameters can be performed in any manner. For example, the reporting can be performed using the Remote Authentication Dial-In User Service (RADIUS) or Diameter protocol standard for mobile devices, Wireless Roaming Intermediary Exchange (WRIX), or another standard for access, authorization, and accounting to keep track of usage by UEs 170.

[104] The usage record may also include usage data in the form of numbers of sent and received data bytes, time duration of the connection, and/or any other measure of usage. The usage data may also include information about the application(s) that were using the connection, websites or other resources that were accessed by the application(s) during use, and/or parameters of the connectivity service, such as the connection speed, jitter, latency, and/or other performance characteristics. The usage data for alternative network 160 may be collected by UE 170 (e.g., using accounting engine 140D), and communicated to BX platform 110 to be used for payment and billing (e.g., to sponsors of wireless connectivity).

[105] In an embodiment, the operating system (e.g., Android™, iOS™, Microsoft Windows™, etc.) in UE 170 enables use of connections to alternative network 160 by any application and regardless of the websites or resources that are accessed. In this case, UE 170 may execute a specific browser that is controlled by or interfaced with accounting engine 140 to control and limit the resources that can be accessed. The browser may also include or be interfaced with a module that keeps track of the resources accessed (e.g., websites visited) and stores the number of bytes (or other measure) used for each resource accessed. This information can then later be used by accounting engine 140 to allocate usage per resource. In this manner, third parties (e.g., gaming providers), web stores, or content providers can sponsor or provide end users with free or reduced-cost access to their products and services on the web. The tracking may cover any and all available access points and networks, and the stored usage data can be used by BX platform 110 to accumulate the costs to the sponsors according to the sponsorship arrangements.

[106] BX platform 110 may collect other statistics from UEs 170, such as the location of each UE 170, and the signal quality, throughput, speed, or availability of access points to home network 150 (e.g., cell tower identifiers) and/or alternative network 160 at each location and/or at specific times. BX platform 110 may use these statistics to compile useful information about the quality of connections in various locations and/or at specific times, and infer the need for data capacity or report time-of-use data and historical trends. Such reports could be sold to wireless network operators, or made available (possibly for a fee or in the form of a marketing campaign) to owners of access points of alternative network 160, potential future owners of access points of alternative network 160, or residents or owners of buildings and other structures in the vicinity of each location for which usage data has been collected. The information from the reports could be used by the operators and owners to make decisions about pricing or adding capacity in the form of registering existing access points with BX platform 110, installing new access points, and/or adding new alternative networks. These actions would provide an opportunity to the owners of buildings or access points to participate in the bandwidth exchange market.

[107] In an embodiment, selection engine 130 may use several different radio connections simultaneously. The connections may be selected individually for different applications running on UE 170 or may be aggregated to provide a higher total data transmission capability for a single application. In other words, UE 170 can“pool” resources to increase the overall data transmission speed.

[108] Selection engine 130 may use a combination of information to implement the rules and policies 132 for selecting connectivity. For example, selection engine 130 may be aware of the connections provided directly by the wireless operator using home network 150 and may be familiar with the connectivity through access points that have been configured for a given UE 170 by the end user (e.g., access points at the user’s home, office, and/or other locations where free connectivity is available to the end user). However, in BX platform 110, real-time information about connectivity is available from proposal engines 120C, residing in third-party access points of alternative network 160, or elsewhere in alternative network 160 at a location from which it can be accessed by selection engine 130. In order to participate in providing connectivity through alternative network 160, each access point must have a proposal engine 120 or provide a reference to a proposal engine 120. [109] 1.1.3 Accounting Engine

[110] Regardless of the level of sophistication supported by proposal engines 120 and selection engines 130, over time, each UE 170 will use connections through different access points. In order to keep track of the actual usage of each connection, and to provide information for compensation and settlements within the bandwidth exchange market, each UE 170 is covered by a local accounting engine (e.g., accounting engine 140D) or server- based (e.g., cloud-based) accounting engine 140 (e.g., accounting engine 140A).

[111] In an embodiment, accounting engine 140 keeps track of the usage of connections by UE 170 and reports it to platform 110. Specifically, accounting engine 140 keeps track of the usage of alternative network connections by each UE 170, as well as the specific terms and conditions 122 established between the proposal engine 120 and selection engine 130 for each specific usage of alternative network connections by the UE 170. Accounting engine 140 collects and provides this data to platform 110, which utilizes the data to implement the micro-commerce and reward and incentivize all participants in the bandwidth exchange market.

[112] As a minimum condition for participating in the bandwidth exchange market, each UE 170 may be required to execute an accounting engine 140 (e.g., accounting engine 140D) or be covered by at least one accounting engine 140 (e.g., accounting engine 140A) associated with the alternative network. In a split implementation, accounting engine 140 may comprise one module executing on UE 170 and another module executing on a server of the alternative network access provider. In this case, platform 110 may receive usage reports from the module on UE 170 and/or the module on the server of the alternative network access provider. In at least some instances, platform 110 will receive usage reports from both modules, which provides an opportunity to audit the usage reports from both UE 170 and the alternative network access provider to ensure that the usage is being accurately reported.

[113] To the extent the capability is available, access points may include an accounting engine 140C that can collect information about the usage of data capacity by each UE 170. If such records are collected and made available to BX platform 110, they may be recompiled and used to verify the usage records provided by the accounting engines 140D in UEs 170. In an embodiment, BX platform 110 automatically logs into the administrator’s interface of registered access points (e.g., using credentials provided by the access point owners during initial registration with BX platform 110), in order to retrieve usage reports that indicate the usage of connectivity by each participating UE 170. This capability may be utilized in at least a subset of access points to provide a useful auditing function and ensure that the reporting by the accounting engines of UEs 170 (e.g., accounting engines 140A and/or 140D) is accurate.

[114] 1.1.4 Bandwidth Exchange Platform

[115] In an embodiment, BX platform 110 manages all the information for implementing the micro-commerce between home network providers, alternative network access providers, owners of access points, and the end users of wireless devices. Management of the exchange may include: managing messaging and/or instructions for transferring or swapping UEs 170 between home network 150 and alternative network 160; managing terms and conditions 122; managing usage records 142; and providing billing and payment services to all parties. As discussed elsewhere herein, BX platform 110 may be implemented as software modules executing on one or more dedicated servers or in the cloud.

[116] 1.2. Example Processing Device

[117] FIG. 2 illustrates an example wired or wireless system 200 that may be used in connection with various embodiments described herein. For example system 200 may be used as or in conjunction with one or more of the mechanisms, processes, methods, or functions (e.g., to store and/or execute one or more software modules of the application) described herein, and may represent components of platform 110, access points of home network 150 and/or alternative network 160, UEs 170, and/or other processing devices described herein. System 200 can be a wireless device, a server, a conventional personal computer, or any other processor-enabled device that is capable of wired or wireless data communication. Other computer systems and/or architectures may be also used, as will be clear to those skilled in the art.

[118] System 200 preferably includes one or more processors, such as processor 210. Additional processors may be provided, such as an auxiliary processor to manage input/output, an auxiliary processor to perform floating-point mathematical operations, a special-purpose microprocessor having an architecture suitable for fast execution of signal processing algorithms (e.g., digital-signal processor), a slave processor subordinate to the main processing system (e.g., back-end processor), an additional microprocessor or controller for dual or multiple processor systems, and/or a coprocessor. Such auxiliary processors may be discrete processors or may be integrated with processor 210. Examples of processors which may be used with system 200 include, without limitation, the Pentium® processor, Core i7® processor, and Xeon® processor, all of which are available from Intel Corporation of Santa Clara, California.

[119] Processor 210 is preferably connected to a communication bus 205. Communication bus 205 may include a data channel for facilitating information transfer between storage and other peripheral components of system 200. Furthermore, communication bus 205 may provide a set of signals used for communication with processor 210, including a data bus, address bus, and/or control bus (not shown). Communication bus 205 may comprise any standard or non-standard bus architecture such as, for example, bus architectures compliant with industry standard architecture (ISA), extended industry standard architecture (EISA), Micro Channel Architecture (MCA), peripheral component interconnect (PCI) local bus, standards promulgated by the Institute of Electrical and Electronics Engineers (IEEE) including IEEE 488 general-purpose interface bus (GPIB), IEEE 696/S- 100, and/or the like.

[120] System 200 preferably includes a main memory 215 and may also include a secondary memory 220. Main memory 215 provides storage of instructions and data for programs executing on processor 210, such as one or more of the functions and/or modules discussed herein. It should be understood that programs stored in the memory and executed by processor 210 may be written and/or compiled according to any suitable language, including without limitation C/C++, ava, avaScript, Perl, Visual Basic, .NET, and the like. Main memory 215 is typically semiconductor-based memory such as dynamic random access memory (DRAM) and/or static random access memory (SRAM). Other semiconductor- based memory types include, for example, synchronous dynamic random access memory (SDRAM), Rambus dynamic random access memory (RDRAM), ferroelectric random access memory (FRAM), and the like, including read only memory (ROM).

[121] Secondary memory 220 may optionally include an internal medium 225 and/or a removable medium 230. Removable medium 230 is read from and/or written to in any well- known manner. Removable storage medium 230 may be, for example, a magnetic tape drive, a compact disc (CD) drive, a digital versatile disc (DVD) drive, other optical drive, a flash memory drive, and/or the like.

[122] Secondary memory 220 is a non-transitory computer-readable medium having computer-executable code (e.g., disclosed software modules) and/or other data stored thereon. The computer software or data stored on secondary memory 220 is read into main memory 215 for execution by processor 210. [123] In alternative embodiments, secondary memory 220 may include other similar means for allowing computer programs or other data or instructions to be loaded into system 200. Such means may include, for example, a communication interface 240, which allows software and data to be transferred from external storage medium 245 to system 200. Examples of external storage medium 245 may include an external hard disk drive, an external optical drive, an external magneto-optical drive, and/or the like. Other examples of secondary memory 220 may include semiconductor-based memory, such as programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable read-only memory (EEPROM), and flash memory (block-oriented memory similar to EEPROM).

[124] As mentioned above, system 200 may include a communication interface 240. Communication interface 240 allows software and data to be transferred between system 200 and external devices (e.g. printers), networks, or other information sources. For example, computer software or executable code may be transferred to system 200 from a network server (e.g., platform 110) via communication interface 240. Examples of communication interface 240 include a built-in network adapter, network interface card (NIC), Personal Computer Memory Card International Association (PCMCIA) network card, card bus network adapter, wireless network adapter, Universal Serial Bus (USB) network adapter, modem, a wireless data card, a communications port, an infrared interface, an IEEE 1394 fire-wire, and any other device capable of interfacing system 200 with a network (e.g., network(s) 120) or another computing device. Communication interface 240 preferably implements industry-promulgated protocol standards, such as Ethernet IEEE 802 standards, Fiber Channel, digital subscriber line (DSL), asynchronous digital subscriber line (ADSL), frame relay, asynchronous transfer mode (ATM), integrated digital services network (ISDN), personal communications services (PCS), transmission control protocol/Internet protocol (TCP/IP), serial line Internet protocol/point to point protocol (SLIP/PPP), and so on, but may also implement customized or non-standard interface protocols as well.

[125] Software and data transferred via communication interface 240 are generally in the form of electrical communication signals 255. These signals 255 may be provided to communication interface 240 via a communication channel 250. In an embodiment, communication channel 250 may be a wired or wireless network (e.g., network(s) 120), or any variety of other communication links. Communication channel 250 carries signals 255 and can be implemented using a variety of wired or wireless communication means including wire or cable, fiber optics, conventional phone line, cellular phone link, wireless data communication link, radio frequency (“RF”) link, or infrared link, just to name a few.

[126] Computer-executable code (e.g., computer programs, such as the disclosed application, or software modules) is stored in main memory 215 and/or secondary memory 220. Computer programs can also be received via communication interface 240 and stored in main memory 215 and/or secondary memory 220. Such computer programs, when executed, enable system 200 to perform the various functions of the disclosed embodiments as described elsewhere herein.

[127] In this description, the term“computer-readable medium” is used to refer to any non-transitory computer-readable storage media used to provide computer-executable code and/or other data to or within system 200. Examples of such media include main memory 215, secondary memory 220 (including internal memory 225, removable medium 230, and external storage medium 245), and any peripheral device communicatively coupled with communication interface 240 (including a network information server or other network device). These non-transitory computer-readable media are means for providing executable code, programming instructions, software, and/or other data to system 200.

[128] In an embodiment that is implemented using software, the software may be stored on a computer-readable medium and loaded into system 200 by way of removable medium 230, EO interface 235, or communication interface 240. In such an embodiment, the software is loaded into system 200 in the form of electrical communication signals 255. The software, when executed by processor 210, preferably causes processor 210 to perform one or more of the processes and functions described elsewhere herein.

[129] In an embodiment, EO interface 235 provides an interface between one or more components of system 200 and one or more input and/or output devices. Example input devices include, without limitation, sensors, keyboards, touch screens or other touch-sensitive devices, biometric sensing devices, computer mice, trackballs, pen-based pointing devices, and/or the like. Examples of output devices include, without limitation, other processing devices, cathode ray tubes (CRTs), plasma displays, light-emitting diode (LED) displays, liquid crystal displays (LCDs), printers, vacuum fluorescent displays (VFDs), surface- conduction electron-emitter displays (SEDs), field emission displays (FEDs), and/or the like. In some cases, an input and output device may be combined, such as in the case of a touch panel display (e.g., in a smartphone, tablet, or other mobile device).

[130] System 200 may also include optional wireless communication components that facilitate wireless communication over a voice network and/or a data network (e.g., in the case of user system 130). The wireless communication components comprise an antenna system 270, a radio system 265, and a baseband system 260. In system 200, radio frequency (RF) signals are transmitted and received over the air by antenna system 270 under the management of radio system 265.

[131] In an embodiment, antenna system 270 may comprise one or more antennae and one or more multiplexors (not shown) that perform a switching function to provide antenna system 270 with transmit and receive signal paths. In the receive path, received RF signals can be coupled from a multiplexor to a low noise amplifier (not shown) that amplifies the received RF signal and sends the amplified signal to radio system 265.

[132] In an alternative embodiment, radio system 265 may comprise one or more radios that are configured to communicate over various frequencies. In an embodiment, radio system 265 may combine a demodulator (not shown) and modulator (not shown) in one integrated circuit (IC). The demodulator and modulator can also be separate components. In the incoming path, the demodulator strips away the RF carrier signal leaving a baseband receive audio signal, which is sent from radio system 265 to baseband system 260.

[133] If the received signal contains audio information, then baseband system 260 decodes the signal and converts it to an analog signal. Then the signal is amplified and sent to a speaker. Baseband system 260 also receives analog audio signals from a microphone. These analog audio signals are converted to digital signals and encoded by baseband system 260. Baseband system 260 also encodes the digital signals for transmission and generates a baseband transmit audio signal that is routed to the modulator portion of radio system 265. The modulator mixes the baseband transmit audio signal with an RF carrier signal, generating an RF transmit signal that is routed to antenna system 270 and may pass through a power amplifier (not shown). The power amplifier amplifies the RF transmit signal and routes it to antenna system 270, where the signal is switched to the antenna port for transmission.

[134] Baseband system 260 is also communicatively coupled with processor 210, which may be a central processing unit (CPU). Processor 210 has access to data storage areas 215 and 220. Processor 210 is preferably configured to execute instructions (i.e., computer programs, such as the disclosed application, or software modules) that can be stored in main memory 215 or secondary memory 220. Computer programs can also be received from baseband processor 260 and stored in main memory 210 or in secondary memory 220, or executed upon receipt. Such computer programs, when executed, enable system 200 to perform the various functions of the disclosed embodiments. [135] 2. Process Overview

[136] Embodiments of processes for optimization of network selection across a plurality of mobile networks will now be described in detail. It should be understood that the described processes may be embodied in one or more software modules that are executed by one or more hardware processors (e.g., server application, client application, and/or a distributed application comprising a combination of server and client applications), which may be executed wholly by processor(s) of platform 110, wholly by processors of an access point or a server or gateway within home network 150 and/or alternative network 160, wholly by processor(s) of UEs 170, or may be distributed across any combination of two or more of these devices. The described process may be implemented as instructions represented in source code, object code, and/or machine code. These instructions may be executed directly by the hardware processor(s), or alternatively, may be executed by a virtual machine operating between the object code and the hardware processors.

[137] Alternatively, the described processes may be implemented as a hardware component (e.g., general-purpose processor, integrated circuit (IC), application-specific integrated circuit (ASIC), digital signal processor (DSP), field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, etc.), combination of hardware components, or combination of hardware and software components. To clearly illustrate the interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps are described herein generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled persons can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the invention. In addition, the grouping of functions within a component, block, module, circuit, or step is for ease of description. Specific functions or steps can be moved from one component, block, module, circuit, or step to another without departing from the invention.

[138] In an embodiment, the decision to have a mobile device roam to an alternative network can be made based on the network load and the signal conditions for each specific device and on the value of the capacity for both the home network and the alternative (possibly visited) network at the time of the connection decision. In some cases, network operators can enter simple parameters describing the value of incremental capacity for specific parts of the network or the value of a better user experience for a particular set of mobile devices. The system will automatically determine what kind of distribution of devices across the available networks best meets the objectives of the network service and the mobile service providers. In some embodiments, it will also automatically control the connection decisions of the mobile devices to achieve the intended distribution of load and mobile devices across the sectors of two or more alternative networks. In some cases, the system may be used to conduct trade on connectivity or on data transfer capacity between owners or operators of different network resources or between owners and operators of mobile service providers and network service providers.

[139] In an embodiment, network selection decisions are based on the actual use of network resources and the quality of the current user connection and the same parameters for the potential alternative connection. The selection decision also takes into account the load and opportunity cost of the available networks and value of incremental capacity for mobile service providers and network operators.

[140] The systems and methods described herein are generally referred to as the BxMarket (sometimes abbreviated BX in the following), as implemented by BX platform 110. Embodiments of BX can make it possible for service providers of wireless mobile devices and network service providers (in some cases of home or roaming networks) to manage network selections of the devices and conduct (micro)-commerce on connectivity, bandwidth, or data transfer capacity. This commerce can be conducted based on a number of parameters pertaining to the characteristics of connections available to alternative wireless networks and the current situation of the network and device operation.

[141] BX extends to the optimization of wireless networks across boundaries. These boundaries may include the ownership and control systems of the network and the types of network radio access technology (RAT) ranging from Wi-Fi™ to 2G, 3G, 4G, LTE, 5G, and/or the like.

[142] It is relatively easy to demonstrate that expanding the realm of resources and distributing devices across networks where optimization can take place will provide additional efficiencies in resource use in wireless communications. This is usually the case in all optimization situations. In some cases, the BX solution may expand the realm of optimization from a single mobile operator network to two or more separate overlapping networks. Detailed study of the effects of optimizing across existing overlapping networks, which had already been optimized within their own boundaries, shows that this broader optimization can double the total combined capacity and dramatically improve the speeds of service that the individual mobile devices experience. [143] Another benefit of the BX solution is that it allows the network operators and mobile service providers to define the value and cost parameters for incremental capacity, and the optimization will reflect these granular preferences.

[144] The key functions necessary for the optimization include: (i) ability to measure or estimate the load and signal conditions in the various parts of the participating networks; (ii) means of controlling the network selection of mobile devices 170; and (iii) incorporating the value parameters of the network service providers into the network selection of mobile devices 170.

[145] Means of measuring or estimating the load and signal conditions are readily available in existing network management systems and in the operating systems of most mobile devices 170. One set of means for estimating signal conditions and controlling the network selection of mobile devices 170 based on utilizing software on the mobile devices 170 and the SIM card functions has been disclosed in U.S. Patent App. No. 15/845,410, filed on December 18, 2017, which is hereby incorporated herein by reference as if set forth in full. In the following, an alternative mechanism for this estimating and control and for managing the load distribution by value parameters are explained. Furthermore, the method and means of incorporating the respective values of incremental capacity of network and mobile service providers is disclosed.

[146] As explained above, many mobile network control systems already have sophisticated internal load balancing mechanisms. Examples include the network control mechanism described in the 3GPP standard for cellular networks and the mechanisms described in the 802.11 standard for managing load in Wi-Fi™ networks. Additional optimization functions are available in the various SON systems. The BX optimization method takes advantage of the existing widely deployed mechanisms and adds a layer of optimization that may include trade-offs of value across boundaries between networks and sets of mobile devices 170. It may also be extended to actual commerce and trading of access to network resources or local data transfer capacity between network and mobile service providers.

[147] FIG. 3 illustrates the relationship of functions and physical components in the BX solution, according to an embodiment. Notably, however, the BX functions extend into the current systems of SON solutions and to the existing network control solutions in networks that are in its scope of optimization by adding or changing the parameters that these systems use. Before getting into the details of the solution, the following discusses what the objectives for optimum selection of roaming devices are when seeking to balance load across sectors in the most economical way.

[148] FIG. 4 displays a situation in two overlapping networks, Network A and Network B, according to an embodiment. Let us assume that Sector Al has a higher load than desirable and user experience of mobile devices 170 connected to it has deteriorated. User experience and the average data transfer speed in a cell sector depends on the average load level: the higher the load, the lower the average speeds. In this sense, there is“value” for decreasing the load in Sector Al because the average user experience will improve. A monetary manifestation of this value can be seen in the network capacity upgrade investments made by the mobile service providers that operate and maintain their own networks.

[149] The speed and user experience situation is worst at the edge of Sector Al in Area Al, since mobile devices 170 in this area have the poorest signal. Notably, mobile devices 170 in this area are also the most“expensive” to serve in terms of network resources, since they have slower connections and getting the same amount of data to them takes up a higher amount of time and network resource blocks than mobile devices 170 that are in good signal conditions. The difference in an LTE network can be up to fifty-fold and in many network implementations is routinely more than twenty-fold between cell center and edge. Removing load of mobile devices 170 in Area Al would provide the most effective relief of load in Sector Al, because their data needs are the most“expensive“ to satisfy in terms of radio resources. In other words, they consume more resource blocks per megabyte of data transfer.

[150] The diagram in FIG. 4 simplifies the situation for clarity by assuming that the signal quality, and therefore the data transmission efficiency, depends only on the distance from the antenna. In reality other factors, like the terrain, buildings, the specific location of the device, the antenna, and the RF front end of the mobile device 170 have an impact on the signal quality, specifically the signal to noise ratio. Therefore, interpreting the Area Al as being determined by the actual signal quality is the intent of FIG. 4.

[151] The other network shown on the diagram is Network B with three sectors Bl, B2 and B3. Considering that the signal fades with distance, there is going to be a good signal area in the vicinity of the cell antennas. This is shown in FIG. 4 as Area B2. In accordance with the simplified way of illustration described above, this area is approximately a circle with the cell antenna locations in the center. This is assuming that the transmission powers and antennas and their tilt angles in each sector are identical. Also in this case, the comment about simplification and the effect of terrain, buildings, and antennas applies. In addition, the shapes of the areas would be more complex and determined by the actual signal conditions. This good signal area represents the part of the cell Sectors Bl to B3 where the efficiency of serving mobile devices 170 is at its highest. Good signal corresponds to better encoding and faster speeds, with fewer resource blocks (in LTE protocol) needed to provide a given amount of data transmission.

[152] Considering a situation where Sector Al is at a higher load than desirable, and sectors B 1 to B3 are at a load level where additional load would not cause an unacceptable decline in user experience, it would be desirable to move the connection and thereby the associated load of some mobile devices 170 in Sector Al to Sectors Bl to B3. To be more precise than just referring to a“higher load than desirable” or an“acceptable decline,” there is a value and a cost associated with every incremental change in load. There is a complex non-linear relationship between load and network performance, and the value of incremental speed is also non-linear. These aspects are discussed later herein.

[153] Usually, serving mobile devices 170 that are“home” on Network A by a visited network (Network B) is done for coverage reasons when devices roam from one network to another. In this case, roaming would be done for load balancing and for the purpose of using existing resources more efficiently. Therefore, this will sometimes be referred to as “economic roaming”.

[154] Considering the specific resource efficiency described above, the most resource- economical way of achieving the load reduction in Sector Al (and creation of value) would be to move some of mobile devices 170 with a poor signal in Area Al away from the sector and allow those mobile devices 170 to be served by Network B. This would create the maximum load reduction (and value) in relation to the number of transferred connections and total data demand served by the alternative network.

[155] To further optimize this scenario, the subset of these mobile devices 170 that can have a good signal on Network B may be moved. This would result in absorption of the additional data transfer need with the minimum increase of the resource load in Network B (cost) since the demand from mobile devices 170 with a better signal can be served with fewer resources. As can be seen from FIG. 4, this would be the mobile devices in Network A that are in the area that is an intersection of Areas Al and B2. This area is denoted with the label Optimum Zone in FIG. 4.

[156] It is possible that sectors Bl to B3 may have different load levels, and therefore, the incremental load from mobile devices 170 coming from Network A may have a different effect on the user experience in each of these sectors. This can be thought of as a different “cost” for the target. Cost in this context can be thought of as an adverse effect on the mobile devices 170 of the users of Network B, since most of the actual cost of the networks and their operation are fixed costs not affected by the load. In these cases, the optimal distribution of mobile devices 170 on Network A in Area Al, between sectors B2 and B3, in the illustration in FIG. 4 would be different. The signal level (in Network B) at which it would be best to receive a roaming mobile device 170 from Area Al would also be different for Sectors B2 and B3. It could even be possible that Sector Bl would be the best to receive some of the Sector Al mobile devices 170 if its load would be much smaller than Sectors B2 and B3.

[157] As noted above, the concepts of cost and value in the sense of a change in the network speed experienced by mobile-device users have direct counterparts in the financial value. This is evidenced by the network investments made to maintain acceptable load levels in wireless networks. In reality, the relation of network load reduction through the kind of economic roaming described herein to the actual financial value is quite complex. First, the relationship of network load to the average speed experienced by mobile devices 170 is non linear and complicated. Therefore, value of incremental changes inherently depends on the existing load levels. Second, the economic roaming can be seen as an alternative to a network capacity upgrade. The cost of the upgrade depends on a number of factors like the availability of additional spectrum, local factors like availability of cell sites, cost of backhaul, and/or the like. Furthermore, the value of maintaining a good user experience may vary across different network user groups or locations.

[158] One of the key characteristics of the BX solution is to provide network and mobile service providers with means of expressing the value of incremental changes in network load and optimize the outcome for participants in economic roaming based on these value expressions. Before discussing the details of this part of the BX solution, the network-based mechanism for controlling the economic roaming activity will be explained. For this discussion, the concept of trading and related trading parameters will be needed.

[159] Trading refers to providing and consuming data transfer capacity across network boundaries. In other words, when a mobile device 170 from Network A roams to network B as part of economic roaming and utilizes resources from network B, a trade takes place. In this case, Network A is buying capacity from Network B, which is selling that capacity to Network A.

[160] As indicated above, Network A receives value from economic roaming, and there is a cost to Network B from it in this example. Whether a trade should occur depends on the cost and value opportunity in each opportunity to trade. This is controlled by trading parameters that may depend on trading conditions and the value and cost expressions discussed above. Moving the connection of a mobile device 170 in Network A to Network B in this context represents a trade.

[161] 2.1. Mechanism for Controlling Devices’ Network Selection

[162] The mechanics of a connection transfer for economic roaming purposes can be thought of as an extension to the set of normal handovers that take place when mobile devices 170 move though an area covered by several cell sectors or when the load needs to be balanced between different parts of the network across RAT or frequency band boundaries. In the BX solution, the parameters for the handovers are adjusted by the BxMarket that translates the trading conditions to specific changes to the handover instruction parameters used in normal network operations.

[163] FIG. 5 illustrates an example of a call flow in a network handover scenario, and shows the key interfaces and actions that BxMarket (e.g., operating on BX platform 110) utilizes to achieve the optimum load distribution across two separate networks, according to an embodiment. What is discussed above is a system that has the ability to alter typical single-network handovers to multi-network handovers by monitoring the network and trading conditions at the sector level. BX platform 110 is capable of communicating with multiple wireless networks to receive their trading parameters. These trading parameters are translated into a series of control channel parameter change recommendations that temporarily alter handover behavior at the sector level. Often, these parameter changes initiated by BxMarket will include, without limitation, measurement offsets and system and cell identification information of bandwidth trading partners.

[164] Trading parameters include but are not limited to sector/cell loading, such as a metric called Physical Resource Block (PRB) Occupation or Transmission Time Interval (TTI) Utilization, and pricing. Pricing (or buyer value parameters) is a user-settable parameter and includes buy price and sell price (or seller value parameters) that depend on the sector loading. These can be set so that certain geographic areas are more likely or less likely to trade, or trading likelihood can be altered by time of day, or any other number of settable parameters.

[165] As described above, BX platform 110 can make it possible for service providers to buy or sell bandwidth. To this end, BX platform 110 must communicate with multiple networks. In an embodiment, BX platform 110 does not share load information between networks. BX platform 110 uses the load information to make recommendations, and then sends the recommendations to the relevant networks. One embodiment of this technique is via an interface with SON equipment. Another embodiment of this is for BX platform 110 to directly communicate with the network management systems (or the entity which contains load information in that network) of multiple networks. An interface for providing the parameters changes from BxMarket to the SON or network management system must also be present.

[166] In an embodiment in which BX platform 110 is interfaced to SON equipment, it may utilize a specific application programming interface (API), functioning as a“plug-in” piece of software which provides additional functionality to the SON systems of each participating network. This API enables BX platform 110 to receive loading and other key performance indicator (KPI) information from participating alternative networks. In this case, BX platform 110 would directly interface with SON equipment.

[167] 2.2. Example

[168] In an environment in which BX platform 110 is connected to two or more LTE networks, the alternative networks would offer their load information in frequent intervals to BX platform 110. At the same time, BX platform 110 would be monitoring loading conditions on primary (home or native) network 150. When a load threshold is passed in a sector of primary network 150, BX platform 110 would run the exchange algorithms using the loading and pricing information of alternative networks 160 for the cell sectors in alternative networks 160 that are overlapping and could be serving the devices in the highly loaded sector in primary network 150. This algorithm will take into account the trading parameters provided to BX platform 110 (e.g., which includes pricing of incremental load at various load levels, etc.). The result of these algorithms is a parameter change instruction that will go to the native network cells of home network 150 that are over the threshold loading condition. For example, the parameter changes would go to PLMN (e.g., a combination of the mobile country code (MCC) and MCC which uniquely identifies the Mobile Network Operator) and PCID (Physical Cell Identity - the ID of a sector) or CGI (Global Cell Identity) of the partner network, as well as cell individual offsets (CIO) for these new neighbors for example via a Radio Resource Control (RRC) Reconfiguration message and/or various System Information Blocks (SIBs). Also included may be changes to the A3- offset cell and event A2 thresholds. Hysteresis, filter coefficients, time to trigger and other handover parameters may be included as well. Once these parameters are sent in the sectors/cells that are candidates for buying, UEs 170 will naturally look for the partner cells, and would go to those cells if the signal conditions are adequate considering the offset values of the parameters.

[169] In a real mobile network, mobile devices 170 move around and individual connection parameters change over time. Also load levels and demand for data change with time. To provide an opportunity for constantly adjusting the optimization regarding which mobile devices 170 are connected to primary network 150 or various cell sectors of alternative networks 160, a mechanism is provided for a steady return stream of mobile devices 170 from alternative networks 160 back to primary network 150. This way there will be a continuous stream of optimization decisions regarding transferring connections to alternative network 160, and these decisions will take into account the changing parameters.

[170] Since the load conditions are measured frequently (by the SON system or network management system) and these updated parameters are used in making subsequent trading decisions and parameter adjustments, there is a feedback loop from the effects of optimization to the new optimization actions. This will provide stability and results in improved achievement of the objectives of the optimization mechanism.

[171] 2.3. Connection of Economic Values to Trading Decisions

[172] The concepts of value and the objectives of the optimization have been discussed above. The following will discuss how the value parameters of various network operators can be expressed and translated into the respective offset parameters to affect the load transfer between networks.

[173] First, the nature of the dependency of the network performance, for an individual connection, on the distance from the cell sector radio and of the load in the cell sector should be explained. FIG. 6 illustrates this relationship, according to an example. The highly nonlinear relationship of performance in terms of speed can be clearly seen from the graphs. The maximum speed is set by the radio access technology. For example, for LTE it is 60 megabits per second. The other two factors are clearly dependent on the cell sector selection of the mobile device, assuming the mobile device’s location and the load levels in the possible serving sectors are fixed. Optimizing in this kind of environment is complex as there are constraints regarding where mobile devices 170 and cell sector radios are, and there is a feedback mechanism where moving load from one sector to another will change the efficiency of data transfer because of the load factor.

[174] In general, the value of capacity is related to the load factor in FIG. 6. Notably, the load in FIG. 6 refers to the average load over an extended period in time. There are significant instantaneous swings in the load as the demands form individual mobile devices 170 come and go. Every time the load (e.g., measured in PRB occupation in an LTE network) exceeds 100%, there will be a drop in throughput speed for all users, because, at that point, the radio resources begin to divide time slots among users, thereby decreasing connection speed for all users. When these brief periods in which the load exceeds 100% become more frequent, the average load over a longer period grows, and the average speed and responsiveness of the individual connections decreases.

[175] If the load over a longer period is very high and the speeds become low, there is a second mechanism that will make the situation even worse. Many protocols (e.g., TCP/IP) will try to deliver lost data packets through a retransmission mechanism and this causes a cascade effect, in which the congestion drives itself.

[176] In the reasonable range of load levels from 10% to 80%, the value of additional capacity and the ability to decrease the load varies. If the speed for individual mobile devices 170 is already better than lOMbits/s, the incentive to improve it is smaller than if the speed is less than 5Mbits/s. FIG. 7A illustrates a possible relationship of the value of incremental capacity as a function of the current load level, according to an embodiment. In other words, the value of decreasing the load as a function of the load.

[177] It should be noted that the absolute value of incremental capacity may vary by sector. For example, it may be relatively easy and not very costly to add capacity in some sectors if additional channels are available, since all accessible spectrum has not been deployed. Whereas in other sectors, the value may be much higher, since adding capacity would involve new towers and densification at a high cost. Therefore, there is a number of value graphs pertaining to different kinds of sectors, but essentially all of the same form. This is shown in FIG. 7B.

[178] The graphs in FIGS. 7A and 7B are illustrative of the value of incremental capacity to the network operator. A similar graph may be constructed to illustrate the value of capacity from the perspective of giving up capacity from a network, in other words the value for selling. While it can be argued that, in a rational mind, the values for receiving or giving up capacity should be equal, it is not realistic to assume that rational minds will prevail. It is more likely that a mobile operator would not be willing to sell capacity from sectors that are at less than 60% PRB occupation levels. FIG. 8A illustrates that case.

[179] Different participants in the mutual optimization of the network use may also have different value graphs based on their commercial objectives and market strategies. Some may value higher speeds more, others may value lower costs more, and yet other participants may just be selling capacity. Their graph may not have the high peak when approaching the 100% utilization. FIG. 8B has an example of what a neutral host LTE network service provider value graph might look like.

[180] The actual speed experienced by mobile devices 170 also depends on the signal quality as shown in the equation in FIG. 6. The value of improving a speed of a mobile device 170 is obviously higher in poor signal conditions. For that reason, it is desirable that the speed of mobile devices 170 in poorer signal conditions is improved first when access to additional resources is available.

[181] There are two ways to improve the speed of a mobile device 170 in this situation: lower the load in the cell sector, or move the device into another sector where it can have a more favorable combination of the distance and load factors. An ideal solution will use both of these methods in a way that the throughput speeds of the slowest data connections are improved more effectively than speeds of mobile devices 170 that already have a reasonably good connection. Allocation of resources in an optimum way within a cell sector is already handled by the so-called scheduler function, which decides when and how frequently each data connection is serviced using the available (PRB) resources. The solution described herein adds new means to achieve the objective of improving and equalizing the user experience by using resources across network boundaries.

[182] A method of combining the value input of graphs in FIGS. 7A-8B with the mechanism of adjusting the configuration message parameters in cellular networks, based on the trading parameters and values of capacity for the various networks within the scope of the optimization, will now be described.

[183] In the situation in FIG. 4, Sector Al was at high load, and there were overlapping Sectors Bl to B3 that had lower loads. Assume that both network operators have entered their values for buying and selling data transfer capacity in their networks, and the value graphs look like the ones presented in FIG. 8A.

[184] Normally, in Network A, the configuration messages to mobile devices 170 in Sector Al would not include the network identifier (PLMN), the physical cell ID (PCID), and the radio frequency channel indicator (eARFCN) of the Network B’s Sectors Bl to B3. However, in an embodiment, the load levels of Sector Al and Sectors Bl to B3 are provided to BX platform 110 from the SON system or other network management system, and BX platform 110 combines them with the value inputs for these sectors provided to it a priori and updated as necessary. The instructions for including these parameters for some of the cells in Network B as well as specific offset parameters in the configuration message are provided depending on the values of the load levels and the configuration parameters programmed into BX platform 110.

[185] Some of the parameters in the reconfiguration messages sent to mobile devices 170 entering each cell in a mobile network are being used for the intra-network handover management and can be adjusted by a SON system to do automatic load balancing between neighboring cells. It is therefore important that any changes made in these parameters are made in a way that does not adversely affect these functions. The parameters relating to the cell sectors in Network B are not used for any other purposes than managing intra-network traffic. Therefore, BX platform 110 can set these parameters without concern of affecting internal functions of Network A.

[186] It is important to include the offset parameters for the new Network B cell sectors in the first messages where these sectors are included. For example, normally including the PLMN and the PCID of sector Bl without any offset values would result in a number of mobile devices 170 from Sector Al initiating handovers to sector Bl instead of other neighboring sectors in Network A. This is because the signal strengths close to the Network B cell site may be much higher than the signal levels in the neighboring sectors of Al. Normally, the handover process is initiated when the serving cell signal drops below the signal in the neighboring cell - both adjusted using the offsets (the A3 offset and the cell individual offset (CIO)) - for that neighboring cell.

[187] By including a large negative offset as the CIO for all of the sectors in network B that are included in the updated configuration message, the number of handovers initiated to network B cells can be limited. It may be possible to also control the number of handovers by the setting of the so-called event A2 and Al thresholds. This could be used to limit the number of devices that engage in the measurement and signal comparison for handover initiation purposes at all. FIG. 9 illustrates example thresholds and offsets, according to an embodiment.

[188] When the CIO’s of network B cells are adjusted up from the initially high negative value (e.g., for LTE, the CIO range is from -24dB to +24dB), the number of mobile devices 170 for which the offset-adjusted signal level comparison triggers a handover to Network B cells will increase. It is by controlling these CIOs that BX platform 110 can control the amount of traffic that will be moved from each cell in Network A to each cell in Network B.

[189] Additionally, in case the target traffic amount is not achieved by just setting the CIOs for Network B cells, it is possible to also adjust the so-called trigger parameter A3 offset. It is normally set at a level where only mobile devices 170 with a poor signal close to the edge of the sector will trigger measurement report messages for a handover to a different sector. This is what essentially defines the cell edge in FIG. 4. In case there is a need to change the number of mobile devices transferring to Network B, BX platform 110 can also change the A3 offset. A negative change (i.e., lowering the offset) would further increase the number of mobile devices 170 for which the signal level comparison will trigger the transfer. A positive change (i.e., increasing the offset) would reduce the number of mobile devices 170 for which the signal level comparison will trigger the transfer. This may be desirable, for example, in cases in which the maximum negative offset in Network B CIOs still results in more handovers than are wanted. In order to keep the change of A3 offset from affecting the internal Network A handovers between neighboring cells, the Network A CIOs for neighboring cells should be changed by the same amount. This leaves the relative values unchanged, and therefore, the intra-network handovers will not be affected.

[190] As used herein, signal level can mean any available signal parameter that indicates the quality or strength of the connection that can be achieved. These metrics may include, without limitation: Signal to Noise Ratio (SNR); Signal to Interference plus Noise Ratio (SINR); Channel Quality Indicator (CQI); Reference Signal Received Quality (RSRQ); Reference Signal Received Power (RSRP); and/or Received Signal Strength Indicator (RSSI).

[191] FIG. 9 illustrates the effect of the A3 offset and the incremental changes in the CIOs using the same graphical representation for signal quality discussed in conjunction with FIG. 4. The result of these incremental parameter changes is that some mobile devices 170 will initiate the handover procedure from Sector Al to Bl or B2 by sending measurement report messages to the network. This sets off the process described in FIG. 5. The target cells still have an opportunity to decline the handover request. However, normally that mechanism is not needed since the number of mobile devices 170 transferring between networks is controlled by adjusting the parameters that initiate the handovers.

[192] As devices execute the handover procedure, the load in sector Al will decrease, and the load in sectors B 1 and B2 will increase. Notably, the demand (and therefore the load) leaving Sector Al comes from an area with a poor signal and, after the handover is complete, this same demand is subsequently served by a strong signal in Sectors Bl and B2. This causes an increase in load on Sectors Bl and B2. However, simulation has shown that this increase in load on Sectors Bl and Bl is significantly less that the sector load cause by the devices in poor signal of Al. Therefore, the load decrease in sector Al is higher than the total load increase in Sectors Bl and B2 when considered in terms of network resources (e.g., PRBs needed to satisfy the load in LTE networks). This is a very desirable characteristic of this mechanism, both from the efficient use of resources perspective and from the perspective of improving user experiences.

[193] This same process can be illustrated in terms of the value graphs for sectors Al and Bl and B2. Initially, the load in sector Al is very high, illustrated by point 1 in FIG. 10. The loads in Sectors Bl and B2 are relatively low. For clarity, only the events in sector Bl are shown in FIG. 10. The initial load level in Sector Bl is shown by point 2. Each of these load points in each sector corresponds to a specific value. The relationship of load to value is provided by the value graphs for buying and selling, which are inputs to BX platform 110. In this case, the buying value for Sector Al is much higher than the selling value for Sector Bl.

[194] Based on this value difference, BX platform 110 will introduce incremental changes to the CIOs of sectors Bl and other sectors that are known to overlap in coverage with sector Al and that belong to networks that are interested in participating in this cross- network optimization and have provided the value inputs to BX platform 110. If needed, changes can also be introduced to A3 offset for Sector A. In this case, similar changes would be made to the Network A CIOs to keep the change from affecting the internal network A functions.

[195] The result of the incremental increase in Sector Bl offset is that mobile devices 170 from Sector Al hand over to Sector Bl. The load moves down for Sector Al and up for Sector Bl. The system will wait for the load levels to stabilize and to get load feedback from both networks.

[196] Based on the new load levels, new parameter adjustments will be made in the parameters for the sectors. This results in further load changes until the feedback results in parameter values where the equilibrium value level has been achieved and the load levels have stabilized at level corresponding to this value point represented by points 3 and 4 in FIG. 10.

[197] For each buy and sell value step in this process, there is a value difference D. The trading price point for each of the steps and for the capacity actually consumed by mobile devices 170, originally from Network A that have been handed over to Network B, can be calculated. In this illustration, the price point is simply the midpoint between the selling and buying value for each step. The price can be a result of a more complex calculation, for example, giving different weight to each component of value or including commissions or fees. BX platform 110 keeps track of the values and prices for each step change in each sector and received time-stamped (e.g., RADIUS) records of the data capacity consumed to reconcile the trades in a settlement statement.

[198] The sizes of the initial parameter adjustments can be made proportional to the differences in the initial and subsequent load differences. The whole system can be made adaptive so that it will learn the appropriate and optimum parameter settings and the sizes of the adjustments needed to achieve the optimum equilibrium for various load situations in each part of the participating networks. In addition, the system can be tuned in advance to set the initial CIOs for each of the overlapping Network B sectors for each of the sectors in network A. This is one way to assign priorities for which of the Network B sectors will be engaged first in receiving the handovers from Sector Al when the load level exceeds the threshold for initiating trading. These initial CIO values can be set, for example, based on calculations or measurements of signal conditions of Sector Al in each of the overlapping sectors in network B. This method can be used, for example, if it is necessary to introduce overlapping sectors one at a time in a sequence to control the number of mobile devices 170 that will be handed over to Network B.

[199] 2.4. Applications

[200] Applications of this concept are numerous and are certainly not limited to the applications listed here. With new licensed, unlicensed, or shared spectrum, networks will benefit from this concept by adding the new spectrum channels or network ID as a potential handover option. Some examples of situations in which this could be done are 3.5 GHz (shared spectrum) and unlicensed bands, such as 5 GHz.

[201] There are markets all around the world in which two or more operators could work cooperatively to densify their networks with this concept. It is reasonably common that MNOs prioritize where their next network investment for upgrade will go. In cases in which upgrades are needed for either capacity or coverage, two or more networks could utilize this technique to improve both capacity and coverage, thereby postponing the need for new capital investment in continuously growing data demand situations. Even in areas where the sites of two MNOs are co-located, but capacity or spectrum limited, the BX concept and technique can drastically postpone the need for additional capital investment and meet data demand growth by better optimization.

[202] The present description introduces a number of novel methods and techniques to optimize the use of wireless data networks, including, without limitation, a system for automatically optimizing the use of two or more overlapping wireless data networks by mobile devices, by establishing the value of incremental capacity for each network cell sector as a function of the current load level in each network and directing devices that can be served by more than one cell sector in the two or more different networks to utilize connections to the cell sectors that can serve them in a way that will to achieve the load distribution that provides the lowest overall cost by modifying the values of the existing handover control parameters in the standard compliant network management and self- optimizing network systems in a way that causes the appropriate number of devices and thereby the right amount of demand to be handed over to the cell sectors that can serve the demand at the lowest cost.

[203] The above description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles described herein can be applied to other embodiments without departing from the spirit or scope of the invention. Thus, it is to be understood that the description and drawings presented herein represent a presently preferred embodiment of the invention and are therefore representative of the subject matter which is broadly contemplated by the present invention. It is further understood that the scope of the present invention fully encompasses other embodiments that may become obvious to those skilled in the art and that the scope of the present invention is accordingly not limited.

[204] Combinations, described herein, such as“at least one of A, B, or C,”“one or more of A, B, or C,”“at least one of A, B, and C,”“one or more of A, B, and C,” and“A, B, C, or any combination thereof’ include any combination of A, B, and/or C, and may include multiples of A, multiples of B, or multiples of C. Specifically, combinations such as“at least one of A, B, or C,”“one or more of A, B, or C,”“at least one of A, B, and C,”“one or more of A, B, and C,” and“A, B, C, or any combination thereof’ may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, and any such combination may contain one or more members of its constituents A, B, and/or C. For example, a combination of A and B may comprise one A and multiple B’s, multiple A’s and one B, or multiple A’s and multiple B’s.

Claims

CLAIMS What is claimed is:

1. A method comprising using at least one hardware processor of a server to: receive first parameters representing a value of incremental capacity as a function of a load within a first sector of a first network;

receive second parameters representing a value of incremental capacity as a function of a load within a second sector of a second network, wherein the second network is different than the first network, and wherein the second sector overlaps the first sector;

receive first load information representing a load within the first sector;

receive second load information representing a load within the second sector;

determine whether or not to hand over one or more mobile devices, within an overlap area of the first sector and the second sector, from the first sector of the first network to the second sector of the second network based on the first parameters, the second parameters, the first load information, and the second load information; and,

when determining to hand over one or more mobile devices from the first sector to the second sector, modifying values of hand-over parameters within the first network to trigger the hand over of the one or more mobile devices from the first sector to the second sector.

2. The method of Claim 1, wherein the first network is operated by a first operator and the first parameters are received from the first operator, and wherein the second network is operated by a second operator, that is different than the first operator, and the second parameters are received from the second operator.

3. The method of Claim 1, wherein modifying values of hand-over parameters within the first network to trigger the hand over of the one or more mobile devices comprises: determining a number of mobile devices to hand over from the first sector to the second sector; and

modifying the values of the hand-over parameters so as to trigger a hand over of the determined number of mobile devices from the first sector to the second sector.

4. The method of Claim 3, wherein modifying values of hand-over parameters within the first network comprises including a network identifier of the second network and a physical cell identifier of the second sector in a configuration message transmitted by the first network to the one or more mobile devices.

5. The method of Claim 4, wherein modifying values of hand-over parameters within the first network further comprises setting a cell individual offset (CIO) parameter for the second sector.

6. The method of Claim 5, wherein the method further comprises adjusting the CIO parameter for the second sector based on the determined number of mobile devices.

7. The method of Claim 6, wherein adjusting the CIO parameter comprises increasing the CIO parameter to increase the number of mobile devices to be handed over, and decreasing the CIO parameter to decrease the number of mobile devices to be handed over.

8. The method of Claim 3, wherein modifying the values of hand-over parameters within the first network comprises adjusting an A3 offset of the first sector.

9. The method of Claim 8, wherein adjusting the A3 offset comprises increasing the A3 offset to reduce the number of mobile devices to be handed over, and decreasing the A3 offset to increase the number of mobile devices to be handed over.

10. The method of Claim 8, wherein modifying the values of hand-over parameters within the first network further comprises adjusting a cell individual offset (CIO) parameter for one or more other sectors within the first network.

11. The method of Claim 3, wherein modifying the values of hand-over parameters within the first network comprises adjusting one or both of an event Al threshold and an event A2 threshold in the first sector.

12. The method of Claim 1, wherein the first load information is received from a self-optimizing network (SON) system of the first network via an application programming interface (API), and wherein the second load information is received from a SON system of the second network via an API.

13. The method of Claim 1, wherein the first load information is received in periodic intervals from the first network, and wherein the second load information is received in periodic intervals from the second network.

14. The method of Claim 1, wherein determining whether or not to hand over one or more mobile devices comprises determining to hand over one or more mobile devices when the load within the first sector exceeds a load threshold.

15. The method of Claim 1, wherein the value of incremental capacity in the first parameters comprises a buy price, and wherein the value of incremental capacity in the second parameters comprises a sell price.

16. The method of Claim 15, wherein modifying values of hand-over parameters within the first network to trigger the hand over of the one or more mobile devices from the first sector to the second sector comprises, over two or more iterations:

modifying the values of the hand-over parameters;

subsequently receiving first load feedback representing the load within the first sector after the modification of the values of the hand-over parameters;

subsequently receiving second load feedback representing the load within the second sector after the modification of the values of the hand-over parameters; and

determining whether or not to perform another one of the two or more iterations based on the first parameters, the second parameters, the first load feedback, and the second load feedback.

17. The method of Claim 16, wherein the two or more iterations are performed until the value of incremental capacity as a function of the first load feedback equals the value of incremental capacity as a function of the second load feedback.

18. The method of Claim 16, wherein in a second one of the two or more iterations, following a first one of the two or more iterations, the values of the hand-over parameters are modified in proportion to one or both of a difference in the first load information from the first load feedback or a difference in the second load information from the second load feedback.

19. The method of Claim 1, further comprising using the at least one hardware processor to track data capacity in the second network that is consumed by the one or more mobile devices in association with the value of incremental capacity in one or both of the first parameters and the second parameters.

20. A system comprising: at least one hardware processor; and

one or more software modules that are configured to, when executed by the at least one hardware processor,

receive first parameters representing a value of incremental capacity as a function of a load within a first sector of a first network,

receive second parameters representing a value of incremental capacity as a function of a load within a second sector of a second network, wherein the second network is different than the first network, and wherein the second sector overlaps the first sector,

receive first load information representing a load within the first sector, receive second load information representing a load within the second sector, determine whether or not to hand over one or more mobile devices, within an overlap area of the first sector and the second sector, from the first sector of the first network to the second sector of the second network based on the first parameters, the second parameters, the first load information, and the second load information, and, when determining to hand over one or more mobile devices from the first sector to the second sector, modifying values of hand-over parameters within the first network to trigger the hand over of the one or more mobile devices from the first sector to the second sector.

21. A non-transitory computer-readable medium having instructions stored therein, wherein the instructions, when executed by a processor, cause the processor to:

receive first parameters representing a value of incremental capacity as a function of a load within a first sector of a first network;

receive second parameters representing a value of incremental capacity as a function of a load within a second sector of a second network, wherein the second network is different than the first network, and wherein the second sector overlaps the first sector;

receive first load information representing a load within the first sector;

receive second load information representing a load within the second sector;

determine whether or not to hand over one or more mobile devices, within an overlap area of the first sector and the second sector, from the first sector of the first network to the second sector of the second network based on the first parameters, the second parameters, the first load information, and the second load information; and, when determining to hand over one or more mobile devices from the first sector to the second sector, modifying values of hand-over parameters within the first network to trigger the hand over of the one or more mobile devices from the first sector to the second sector.