WO2015147825A1

WO2015147825A1 - Systems and methods for reducing network signaling and congestion

Info

Publication number: WO2015147825A1
Application number: PCT/US2014/031966
Authority: WO
Inventors: Vivek Gupta; Necati Canpolat
Original assignee: Intel Corporation
Priority date: 2014-03-27
Filing date: 2014-03-27
Publication date: 2015-10-01
Also published as: TW201538009A; TWI569661B

Abstract

System, methods, and computer-readable media are disclosed for combating authentication aggressiveness by specifying eligibility criteria that must be met before a user device may be permitted to authenticate with a network such as a wireless local area network (WLAN). The eligibility criteria may relate to a mobility state of a user device, a number of previous failed authentication attempts, a signal strength associated with a location of a user device within a coverage area of a WLAN (e.g., a device on the periphery of the coverage area may have a weaker signal strength), a travel route taken by a user device, network overload or congestion conditions, and so forth. If a user device fails to meet eligibility criteria for authenticating with a network, a delay time period may be specified, upon the expiration of which, the user device may be permitted to attempt to once again authenticate with the network.

Description

SYSTEMS AND METHODS FOR REDUCING NETWORK SIGNALING AND

CONGESTION

BACKGROUND

Mobile network traffic has increased at an exponential pace over the past few years and is expected to continue increasing at a rapid pace in the coming years. This growth in mobile network traffic has been spurred on by a dramatic increase in the number and types of available mobile devices as well as by a proliferation in the number of deployed wireless access networks. As such, service providers must manage their networks efficiently in order to meet this ever- increasing customer demand for mobile communications bandwidth.

A consequence of this increased mobile network traffic may be an increase in the number and frequency of attempts by mobile devices to authenticate with various wireless access networks or core networks which may, in turn, lead to signaling overload and network congestion at network nodes. As a result, network node functions may become impaired, and mobile device authentication requests that should otherwise be granted may be blocked or denied thereby resulting in users being denied network access.

BRIEF DESCRIPTION OF THE DRAWINGS

The detailed description is set forth with reference to the accompanying drawings. In the drawings, the left-most digit(s) of a reference numeral identifies the drawing in which the reference numeral first appears. The use of the same reference numerals indicates similar or identical components; however, different reference numerals may be used to identify similar or identical components as well. Various embodiments may utilize element(s) and/or component(s) other than those illustrated in the drawings and some element(s) and/or component(s) may not be present in various embodiments. The use of singular terminology to describe a component or element may, depending on the context, encompass a plural number of such components or elements and vice versa.

FIGS. 1A-1C schematically depict various use cases to which one or more example embodiments of the disclosure may be applicable.

FIG. 2 schematically depicts an illustrative networked architecture in accordance with one or more example embodiments of the disclosure.

FIG. 3 is a schematic block diagram of an illustrative user device in accordance with one or more example embodiments of the disclosure. FIG. 4 is a schematic block diagram of an illustrative network node device in accordance with one or more example embodiments of the disclosure.

FIG. 5 is a schematic block diagram of an illustrative user profile in accordance with one or more example embodiments of the disclosure.

FIG. 6 is a process flow diagram of an illustrative method for controlling attempts by a user device to authenticate with a network in accordance with one or more embodiments of the disclosure.

FIG. 7 is a process flow diagram of another illustrative method for controlling attempts by a user device to authenticate with a network in accordance with one or more embodiments of the disclosure.

DETAILED DESCRIPTION

OVERVIEW

This disclosure relates to systems, methods, computer-readable or machine-readable media, techniques, and methodologies for controlling attempts by user devices such as mobile devices to associate or authenticate with wireless access networks. While example embodiments of the disclosure may be described in connection with Wi-Fi networks (or Wi-Fi hotspots more particularly), it should be understood by one of ordinary skill in the art that embodiments of the disclosure are applicable to any access network that utilizes at least a portion of the unlicensed radio spectrum for transmitting and receiving radio frequency signals. In addition to Wi-Fi based networks, another example of such a network is the Long-Term Evolution Unlicensed (LTE-U) network.

The number and types of mobile devices seeking to connect to wireless local access networks (WLANs) such as Wi-Fi networks continues to expand. Moreover, various seamless authentication techniques have been developed to allow for cellular-like roaming of mobile devices on WLANs. Such seamless authentication techniques may, for example, provide seamless connectivity and roaming between various WLAN service providers. In addition, such seamless authentication techniques may further allow for the seamless off-loading of network traffic from a cellular network to a WLAN. For example, a mobile device that is associated with a subscription with a particular cellular network provider (e.g., a 3^rd Generation Partnership Project (3 GPP) service provider) may be able to leverage that subscription to connect with various WLANs operated by operators that have established roaming agreements with the cellular network provider. One such seamless authentication implementation - the Wi-Fi Certified Passpoint program (also known as Hotspot 2.0) - is based on the Institute of Electrical and Electronics Engineers (IEEE) 802. l lu standard, which is a set of protocols that enable cellular-like roaming on WLANs. The 802. l lu standard provides for a variety of network discovery and selection services such as, for example, the discovery of suitable networks (pre-association) through the advertisement of access network type, roaming consortium, and venue information; Layer 2 transport of an advertisement protocol's frames between a mobile device and a network server prior to authentication (a wireless access point (AP) may be responsible for the relay of a mobile device's query to a server in the carrier's network and for delivering the server's response back to the mobile device); or query and response protocol services whereby a mobile device may discover a range of information such as a WLAN operator's domain name, roaming partners accessible via the WLAN along with the credential type and Extensible Authentication Protocol (EAP) method supported for authentication, Internet Protocol (IP) address availability, or other metadata to aid in network selection by the mobile device.

While seamless WLAN authentication implementations such as the Hotspot 2.0 implementation described above provide an advantage of reducing the use of cellular communications bandwidth and allowing for roaming between various WLAN networks, such techniques, coupled with the expanding set of mobile devices seeking wireless network connectivity and the increasing deployment of Wi-Fi hotspots, have resulted in a dramatic increase in the number of attempts from mobile devices to authenticate with access networks.

A recent joint effort by the Global System for Mobile Communications Association (GSMA) and the Wireless Broadband Alliance (WBA) has identified various use cases that may result in numerous repeated attempts by mobile devices to authenticate with Wi-Fi hotspots, a scenario that may be referred to herein as "authentication aggressiveness." For example, in a number of example scenarios, a mobile device may be present within the coverage area of a particular Wi-Fi hotspot and/or may traverse the coverage areas of numerous Wi-Fi hotspots over a relatively short period of time. In such example scenarios, the mobile device may automatically attempt to associate and authenticate with each such Wi-Fi hotspot. This authentication aggressiveness (potentially multiplied over numerous mobile devices) may result in signaling overload and network congestion at one or more wireless access network or core network nodes which may, in turn, disrupt or prevent network connectivity for mobile devices. Signaling overload or network congestion at one or more network nodes may result in a number of negative consequences such as, for example, the inability of users to connect to a Wi-Fi hotspot, the increased usage of cellular communications network bandwidth since network data that would otherwise have been off-loaded to one or more Wi-Fi hotspots is prevented from being off-loaded, and so forth.

FIGS. 1A-1C depict various scenarios that may lead to authentication aggressiveness, and which may, in turn, correspondingly result in signaling overload or network congestion at one or more network nodes of a wireless access network or core network.

FIG. 1A depicts an example scenario that may be associated with, for example, a community Wi-Fi hotspot deployment that includes multiple Wi-Fi hotspots. As used herein, the term "hotspot" may refer to a site location that offers network connectivity over a WLAN that includes one or more AP(s) having connectivity to an Internet Service Provider's (ISP) core network.

In the example scenario depicted in FIG. 1A, a vehicle 102 may travel along a route 106 that may pass through the coverage areas 110(1)-1 10(N) of multiple hotspots. Each hotspot may include one or more corresponding AP(s) (one of 108(1)-108(N)) capable of providing network connectivity to user devices within a corresponding coverage area (one of 110(1)-110(N)) of the hotspot. In accordance with one or more example embodiments of the disclosure, each AP and any associated stations (e.g., mobile devices) within the AP's coverage area may form a basic service set (BSS). Each BSS may be uniquely identified by a basic service set identification (BSSID) which, for a BSS operating in infrastructure mode, may be a Media Access Control (MAC) address of the AP of the BSS. In certain example embodiments, a set of two or more interconnected BSSs may form an extended service set (ESS). Each BSS forming part of the ESS may share the same SSID and security credentials such that the ESS appears as a single ESS to the logical link layer at any station associated with any particular BSS within the ESS.

Still referring to the example use case depicted in FIG. 1A, a user device 104 such as a mobile device may be provided in the vehicle 102. At the snapshot in time depicted in FIG. 1A, the mobile device 104 is illustratively depicted as being within the coverage area of the hotspot served by the AP 108(1). When in the coverage area 110(1) of AP 108(1), the mobile device 104 may attempt to automatically authenticate to AP 108(1). Thereafter, as the vehicle travels along the route 106, the mobile device 104 may attempt to automatically authenticate with each AP 108(2)- 108(N) as the device 104 moves within the corresponding coverage areas 1 10(2)- 1 10(N). Each AP 108(1)-108(N) and the corresponding hotspot that it forms part of may be operated by a particular operator or service provider, and in certain example embodiments, two or more APs 108(1)-108(N) may be operated by different operators or service providers.

As an illustrative and non-limiting example, the vehicle 102 may be traveling through a relatively densely populated metropolitan area that may include a high density of APs 108(1)- 108( ). As the vehicle 102 traverses the route 106 through the metropolitan area, the vehicle 102 may come to a halt at various times such as, for example, at a traffic light. During such moments when the vehicle 102 is stationary for a short period of time, the mobile device 104 may attempt to automatically authenticate with an AP (e.g., AP 108(1)) if the mobile device 104 is within the corresponding coverage area (e.g., 1 10(1)) of the AP. When the example scenario depicted in FIG. 1 A is considered across the multitude of vehicles and mobile devices that may be traversing through a densely populated metropolitan area at any given time, the potential signaling overload and network congestion effects of authentication aggressiveness caused by repeated authentication attempts by such devices becomes readily apparent.

FIG. IB depicts another example scenario that may result in authentication aggressiveness by mobile devices. FIG. IB depicts a public transport scenario in which a commuter train 112 or the like may pass through multiple stations along a particular route. The train 1 12 may be present at each station for only a short period of time. Train 112 is illustratively depicted in FIG. IB as being temporarily stopped at station 1 16. A hotspot having a coverage area 120 may be provided at the station 1 16. When the train 1 12 is stopped at the station 1 16, multiple mobile devices 1 14 in the train 112 may attempt to automatically authenticate with an AP 118 of the hotspot which may, in turn, result in signaling overload and network congestion. As the train 1 12 stops at each station along its travel path, the mobile devices 1 14 may similarly attempt to authenticate with a hotspot located at each such station. While a train 1 12 is illustratively depicted, the example scenario of FIG. IB is applicable to any public transport vehicle (e.g., a bus, van, etc.) that may traverse the coverage areas of multiple hotspots along a travel route.

FIG. 1C depicts yet another example scenario that may result in authentication aggressiveness. In the example scenario depicted in FIG. 1C, multiple mobile devices 128/130 (perhaps thousands) may be simultaneously present in a large public venue 122 such as a sports stadium or arena. In addition, multiple APs 124 may be deployed throughout the venue 122, with each AP 124 being associated with a hotspot having a corresponding coverage area 126. Any number of individuals (and thus any number of mobile devices 128/130 associated with such individuals) may be changing locations with the venue 122 at any given time. As a result, the mobile devices 128/130 may make repeated attempts to authenticate with any number of APs 124. Such authentication attempts may be made notwithstanding the possibility that individuals may not be seeking to operate their corresponding mobile devices 128/130 at that time. Depending on the location of a mobile device at any given point in time, the mobile device may be located well within the coverage area of a hotspot (e.g., mobile device 128), in which case, the signal strength of the connection to the AP may be strong, or the mobile device may be located at the periphery of the coverage area of a hotspot (e.g., mobile device 130), in which case, the signal strength of the connection to the AP may be relatively weak.

As an illustrative and non-limiting example, an individual that leaves his/her seat in the venue 122 to buy concessions may along the way pass through the coverage areas 126 of numerous hotspots, and as a result, a mobile device 128/130 associated with the individual may make repeated attempts to authenticate with an AP of each such hotspot. As another illustrative and non-limiting example, a mass of individuals may be simultaneously moving within the venue 122 during a particular time period (e.g., during halftime of a sporting contest), which may result in thousands of authentication attempts by mobile devices 128/130.

It should be appreciated that the example scenarios depicted in FIGS. 1A-1C are merely illustrative and not exhaustive of scenarios that may lead to authentication aggressiveness by user devices such as mobile devices. Other example scenarios may include, for example, pedestrians with associated mobile devices walking along city blocks of a metropolitan area that is densely populated with APs, shoppers browsing in a shopping complex populated with multiple APs, and so forth. More generally, any scenario in which mobile users (e.g., vehicles, pedestrians, etc.) may traverse the coverage areas of multiple hotspots or scenarios in which a large number of users are within the coverage areas of various hotspots may result in multiple, repeated attempts to authenticate with associated APs, and thus, may ultimately lead to signaling overload and network congestion.

In accordance with example embodiments of the disclosure, various measures may be taken to control authentication attempts by user devices and reduce the potential signaling overload and network congestion effects of authentication aggressiveness. Such measures may include, for example, determining whether to permit a mobile device to associate or authenticate with a hotspot based on device state information, network state information, user profile information, or the like.

The device state information may identify device characteristics or states and may include, for example, mobility state information that indicates a relative mobility of a user device in relation to a hotspot (e.g., relative speed of the user device in relation to an AP of the hotspot, average time spent within the coverage area of the hotspot, etc.); user device route information that indicates a predefined or predictive route traversed by a user device; user device connection information such as a received signal strength indication (RSSI) included in an association request received from a user device or information indicative of a number of previous failed connection attempts; and so forth. In certain example embodiments, the mobility state information may be used to determine the type(s) of AP(s) with which the user device may be permitted to authenticate. For example, the operator or service provider associated with a hotspot may specify various policies that dictate whether a user device is permitted to connect to a particular type of AP based on the user device's mobility state. In certain example embodiments, various ranges of relative speed of a user device with respect to an AP (or an AP's coverage area) and/or a measure of the time spent within the coverage area(s) of one or more APs may map to various mobility states, and each mobility state may, in turn, correspond to one or more types of AP information such as an SSID, an Organizationally Unique Identifier (OUI), a venue type, or the like. In certain example embodiments, a user device may only be permitted to authenticate to a particular type of AP if a relative speed of the user device meets or falls below a corresponding threshold value.

As a non-limiting example, a zero relative speed of a user device with respect to an AP (or AP coverage area) may map to a "stationary" mobility state according to which the user device may be permitted to authenticate with an AP regardless of type. As another non-limiting example, a relative speed of a user device that falls within the range of 1-4 mph may map to a "low" mobility state according to which the user device may be permitted to authenticate with APs of only a certain type (e.g., APs associated with community hotspot deployment). As yet another non-limiting example, a relative speed of a user device that is greater than 25 mph may map to a "high" mobility state according to which the user device may be prevented from authenticating with certain types of APs (e.g., APs associated with "shopping mall" hotspots or community deployed hotspots), but may be allowed to authenticate with "transport-based" APs (e.g., APs provided in train stations).

It should be appreciated that the above examples of mobility states and associated relative speed ranges are merely illustrative and not exhaustive. It should further be appreciated that various modifications or alternatives to the above examples of mobility states and associated mappings and authentication policies are within the scope of this disclosure. As a non-limiting example, a user device average speed that falls within the example range of 25-50 mph may map to a "vehicular mobility state," in which case, the user device may be permitted to authenticate with a particular AP type (e.g., an AP associated with a community hotspot deployment), but only after waiting a predetermined period of time. Such a policy may, for example, prevent a user device from attempting to authenticate when halted for a temporary period of time at a traffic light. As another non-limiting example, user device mobility state information may be assessed in conjunction with historical information associated with an AP to determine whether the device will be permitted to authenticate with the AP. For example, if historical information indicates that an AP is located in a high turnover location, that the average relative speed of user devices within the coverage area of the AP is above a certain threshold value, or the like, a user device may be required to have a lower mobility state or may be required to wait for a longer period of time to authenticate with the AP than may otherwise have been required based on the AP type alone.

As previously noted, the device state information associated with a user device may also include user device route information. An operator of a hotspot may specify policies that indicate whether a user device may be permitted to connect to the hotspot based on the user device route information. For example, an operator may obtain route information indicative of a predefined route to be taken by a user device and may proactively provide the route information and/or user device information (e.g., subscription information) to APs located along the predefined route. The user device route information may include origin, destination, and/or intermediary addresses in any suitable format, information identifying the mode of transportation, and so forth. The user device route information may be obtained from a Global Navigation Satellite System (GNSS) receiver provided in a vehicle or user device and configured to gather location information, from map software executing on an In-Vehicle Infotainment (IVI) system or a user device, or via alternate mechanisms such as from stored information on the user device (e.g., from an e-mail message, a travel itinerary, etc.).

Any given AP along the predetermined route may then either permit the user device to authenticate or may deny authentication if, for example, the wireless access network associated with that AP is congested or overloaded, or if, for example, the user device will only be present within the coverage area of the hotspot for a limited duration of time (e.g., an amount of time that meets or falls below an associated threshold). In certain example embodiments, if the operator of the hotspot has implemented some form of key caching or management (e.g., pairwise master key (PMK) caching, opportunistic key caching (OKC), Cisco centralized key management (CCKM), etc.), the AP may pre-authenticate the user device, thereby permitting the EAP/authentication phase to be skipped (e.g., 802. lx authentication). In certain example embodiments, historical route information or the like may be used to generate predictive travel route information for a user device. A hotspot operator may then enable fast re-authentication of a user device based on the predictive travel route information and/or the overload or congestion state of the hotspot. Fast re-authentication may be enabled using, for example, a key caching technique as described earlier.

As previously noted, the device state information associated with a user device may further include user device connection information. In certain example embodiments, the user device connection information may correspond to or otherwise indicate a received signal strength indication (RSSI) included in an association request received by an AP from a user device. In certain example embodiments, the AP may transmit a response to the user device denying association if the RSSI of the association request meets or falls below a threshold value. The response may further specify a delay time period for the user device to wait prior to again attempting association with the AP. In this manner, user devices that are located on the periphery of the coverage area of an AP or user devices that are only temporarily present within the coverage area may be prevented from associating with the AP. The RSSI thresholds values and delay times may be configurable on a per-AP, per-BSS, or per-ESS basis.

In still other example embodiments, the user device state information may include information (e.g., a counter) indicative of a number of failed authentications by the user device to a hotspot since the last successful authentication. The user device may then be prevented from authenticating with the hotspot if the counter meets or exceeds a threshold value. The user device may be prevented from authenticating for a predetermined period of time or until the counter is reset. The counter may be reset each time the user device successfully authenticates to the hotspot. In certain example embodiments, a respective counter may be provided that indicates the number of failed authentication attempts for each hotspot, while in other example embodiments, a counter may indicate failed authentication attempts for multiple hotspots.

In certain example embodiments, a user profile may be maintained for each user device that specifies one or more of the types of device state information described above. In certain example embodiments, the user profile may be included as an additional node in a subscription profile that includes various other metadata associated with a user device's network subscription (e.g., operator policies, methods for updating subscription information, home service provider information, subscription-related information, user credentials, etc.).

In certain example embodiments, at least a portion of the various techniques for controlling authentication aggressiveness disclosed herein may be implemented by any combination of software, hardware, or firmware provided on a user device in order to, for example, control whether an association request is transmitted to an AP. In certain other example embodiments, at least a portion of the various techniques for controlling authentication aggressiveness disclosed herein may be implemented in any combination of software, hardware, or firmware provided one or more network nodes in order to, for example, control whether a user device is permitted to authenticate with an AP or whether authentication is denied.

One or more illustrative embodiments of the disclosure have been described above. The above-described embodiments are merely illustrative of the scope of this disclosure and are not intended to be limiting in any way. Accordingly, variations, modifications, and equivalents of embodiments disclosed herein are also within the scope of this disclosure. The above-described embodiments and additional and/or alternative embodiments of the disclosure will be described in detail hereinafter through reference to the accompanying drawings. In addition, it should be appreciated that the example technical effects described above are merely illustrative and not exhaustive.

ILLUSTRATIVE ARCHITECTURE

FIG. 2 schematically depicts an illustrative networked architecture 200 in accordance with one or more example embodiments of the disclosure. The architecture 200 may include a hotspot that may include one or more wireless access point(s) (AP) 202 capable of providing wireless network connectivity to user device(s) 206(1 )-206(N) within an associated coverage area 204. While a single AP 202 is shown, it should be appreciated that multiple APs 202 may be provided that may form part of a BSS or ESS of an associated hotspot.

The AP 202 may be configured to communicate via one or more Wi-Fi and/or Wi-Fi direct protocols, as standardized by the IEEE 802.11 standards. In certain embodiments, the AP 202 may be configured to communicate via 2.4 GHz channels (e.g. 802.11b, 802.1 lg, 802.1 1η), 5 GHz channels (e.g. 802.1 1η, 802.1 lac), or 60 GHZ channels (e.g. 802.1 lad). However, it should be appreciated that the AP 202 may be configured to communicate via any frequency channels forming part of the unlicensed radio spectrum.

The AP 202 may be communicatively coupled to a wireless access gateway (WAG) 208 such as a Wi-Fi gateway. The AP 202 may be coupled to the WAG 208 via any number of backhaul communication links that may employ any type of mechanism for securing IP network data transmitted between the AP 202 and the WAG 208 including, but not limited to, the suite of security protocols known as Internet Protocol Security (IPsec), Layer 2 virtual private network (VPN) tunnels, Layer 3 VPN tunnels, or the like. The WAG 208 may be communicatively coupled to a gateway general packet radio service (GPRS) support node (GGSN) or a packet data network gateway (PGW) node 224 provided as part of a mobile core network 210. A GGSN 224 may be provided, for example, in connection with a second generation (2G) or third generation (3G) cellular communications network such as, for example, a digital cellular network that operates in accordance with protocols defined in the GSM standard. A PGW 224 may be provided, for example, in connection with a fourth generation (4G) cellular communications network such as, for example, a digital cellular network that operates in accordance with protocols defined in the 3^rd Generation Partnership Project (3 GPP) LTE standard. A GGSN 224 may operate in conjunction with a Serving GPRS Support Node (SGSN) (not shown) in order to provide Internet connectivity to mobile users. For example, the GGSN 224 may route incoming data traffic from mobile devices received via an SGSN to an appropriate network (e.g., the Internet 232). Conversely, the GGSN 224 may route data received from a network to mobile users via the GGSN 224. The GGSN 224 and the SGSN may together form the GPRS support nodes (GSN). The GGSN 224 may, alone or in combination with the SGSN, support any of variety of other services (e.g., Dynamic Host Configuration Protocol (DHCP) services).

In those embodiments in the which the mobile core network is a 4G digital cellular network, a PGW node 224 may be provided to, for example, act as an "anchor" for user plane mobility, filter user traffic for quality-of-service (QoS) differentiation among multiple packet flows, collect charging information and forward Charging Data Records (CDRs) to one or more Policy and Charging Enforcement Function (PCEF) / Policy Charging and Rules Function (PCRF) servers 228, allocate IP addresses to user devices, provide connectivity to packet data networks operated in accordance with non-3 GPP technologies, and so forth.

The mobile core network 210 may further include one or more mobile network authentication, authorization, and accounting (AAA) servers 226 that may store computer- executable code that responsive to execution may perform operations to authenticate user devices (e.g., user device 206(N)) for establishing connectivity with the AP 202 or with the mobile core network 210 via a mobile network infrastructure 212. The mobile network infrastructure 212 may include antennas and electronic communications equipment placed on radio masts, towers, or the like to create one or more cells capable of transmitting radio frequency signals to and from the mobile core network 210.

The AAA server(s) 226 may utilize any suitable protocol(s) for carrying out user authentication. In those example embodiments in which the mobile core network 210 is a GSM network, an example protocol may be EAP for GSM Subscriber Identity Module (EAP-SIM) according to which a SIM-based authentication algorithm may be executed between a client user device and the AAA server(s) 226 to authenticate the user device using a device SIM card. Another example protocol is the EAP Method for Universal Mobile Telecommunications System (UMTS) Authentication and Key Agreement (EAP-AKA) that provides for authentication and session key distribution using the UMTS Subscriber Identity Module (USIM). In those example embodiments in which the mobile core network 210 is a 3 GPP core network, yet another example protocol is the EAP-AKA' (AKA Prime) variant of EAP-AKA which may be used to provide user devices associated with subscriptions on non-3 GPP networks with access to a 3 GPP core network.

It should be appreciated that the various authentication protocols described above are merely illustrative and not exhaustive. Moreover, it should be appreciated that an EAP protocol (or other authentication protocol) may merely define formatting for EAP messages. Additional protocols may be provided that utilize EAP and define the manner in which EAP messages are encapsulated in the additional messages transmitted or formatted in accordance with the additional protocol.

The mobile core network 210 may further include one or more home location register (HLR) / Home Subscriber Server (HSS) datastores 230. HLR datastore(s) 230 may be provided in those example embodiments in which the mobile core network 210 is a GSM network. The HLR datastore(s) 230 may store information pertaining to each mobile device subscriber that is authorized to use the GSM mobile core network 210. More specifically, the HLR datastore(s) 230 may store information associated with each SIM card issued by an operator of the GSM mobile core network 210. Each SIM may have a unique identifier (e.g., an international mobile subscriber identity (ISMI)) that serves as a primary key for a corresponding HLR record. HSS datastore(s) 230 may be provided in those example embodiments in which the mobile core network 210 is a digital cellular network based on any of a variety of standards or mobile data services such as GPRS, CDMA2000, LTE, or the like. The HSS datastore(s) 230 may store subscription-related information (e.g., subscriber profiles). The mobile network AAA server(s) 226 may access the HLR/HSS datastore(s) 230 to perform subscriber-based authentication.

In those example embodiments in which a user device (e.g., user device 206(1)) that is attempting to authenticate with an AP (e.g., AP 202) is not associated with a subscription with the mobile core network 210, the user device may be authenticated via alternative mechanisms. For example, a back-end platform 214 may be provided that may include one or more network access servers 216 and one or more back-end AAA servers 218.

In certain example embodiments, a captive portal mechanism may be employed to authenticate a user device with the AP 202. The user device may automatically select the AP 202 for association based, for example, on a roaming agreement between the hotspot operator and the mobile core network operator. The user device may automatically provide authentication credentials via the captive portal, which may be received by the network access server(s) 216. The network access server(s) 216 may then transmit the credentials to the back- end AAA server(s) 218 using, for example, the Remote Authentication Dial In User Service (RADIUS) protocol to communicate with the back-end server(s) 218. The back-end AAA server(s) 218 may perform authentication processing to determine whether the credentials are valid, and if valid, may signal the WAG 208 to allow the user device to associate with the AP 202 and send and receive data. In certain example embodiments, the authentication processing performed in connection with the captive portal mechanism may be performed by the mobile network AAA server(s) 226.

In certain other example embodiments, authentication may occur via a non-seamless mechanism. For example, a user may open up a browser on a user device. The network access server(s) 216 may determine that the user is not currently authorized to associate with the AP 202 and may request authentication credentials from the user. The user may input the authentication credentials via the browser which may, in turn, be received by the network access server(s) 216 and transmitted to the back-end AAA server(s) 218 in accordance with the process described above.

In certain example embodiments, SIM-based authentication may involve direct authentication with the mobile network AAA server(s) 226 without use of the back-end AAA server(s) 218, while in other example embodiments, the same AAA server(s) may be used for both SIM-based and non-SIM authentications.

In addition, the architecture 200 may include one or more roaming networks 220. Each roaming network 220 may include one or more roaming hub AAA servers 222 configured to perform authentication processing for authenticating, for example, user devices having subscriptions with the roaming network(s) 220. The architecture 200 is further shown as including any number of additional WLAN(s) 234(1)-234(R) that may be communicatively coupled to the Internet 232 via an ISP core network or the like.

While the mobile core network 210, the hotspot served by the AP 202, and the hotspots 234(1)-0234(R) are illustratively depicted as providing connectivity to the Internet 232, it should be appreciated that the Internet is merely an example network and that connectivity may be provided to any suitable network including, but not limited to, any one or more different types of communications networks such as, for example, cable networks, public networks, private networks (e.g., frame-relay networks), other wireless networks, other cellular networks, telephone networks (e.g., a public switched telephone network), or any other suitable private or public packet-switched or circuit-switched networks. Further, the network(s) 232 may have any suitable communication range associated therewith and may include, for example, global networks (e.g., the Internet), metropolitan area networks (MANs), wide area networks (WANs), local area networks (LANs), or personal area networks (PANs). In addition, the network(s) 232 may include communication links and associated networking devices (e.g., link-layer switches, routers, etc.) for transmitting network traffic over any suitable type of medium including, but not limited to, coaxial cable, twisted-pair wire (e.g., twisted-pair copper wire), optical fiber, a hybrid fiber-coaxial (HFC) medium, a microwave medium, a radio frequency communication medium, a satellite communication medium, or any combination thereof.

Signaling overload or network congestion caused by authentication aggressiveness of user devices may impact any of a variety of network nodes. For example, the HSS/HLR datastore(s) 230 may be impacted which may, in turn, affect connectivity for subscribers of the mobile core network 210 as well as, potentially, hotspot connectivity for SIM based subscriptions. As another example, the mobile network AAA server(s) 226 may be impacted which may affect connectivity for user devices in either home or roaming conditions when authenticating using SIM credentials. As yet another example, the back-end AAA server(s) 218 may be impacted which may affect hotspot connectivity for users regardless of whether SIM-based or non-SIM authentication is employed. In other example scenarios, signaling overload or network congestion caused by authentication aggressiveness may impact Roaming Hub AAA server(s) 222, the WAG 208, and/or the AP 202 which may affect network connectivity for users on a roaming network, network connectivity for hotspot users in an area served by the WAG 208, and/or network connectivity for users associated with or attempting to associate with AP 202, respectively.

Protocols or policies disclosed herein for controlling authentication aggressiveness by user devices may be implemented at any suitable network node in the architecture 200. For example, such protocols or policies may be implemented at an AP (e.g., AP 202), at the WAG 208, on a user device (e.g., user device 206(1)), at one or more components of the mobile core network 210 (e.g., the mobile network AAA server(s) 226), at one or more components of the back-end platform 214 (e.g., the back-end AAA server(s) 218), or the like.

It should be understood by one or more ordinary skill in the art that the architecture 200 depicted in FIG. 2 is merely illustrative and not exhaustive and that variations, modifications, alternate configurations, and so forth are within the scope of this disclosure.

FIG. 3 is a schematic block diagram of an illustrative user device 302 in accordance with one or more example embodiments of the disclosure. The user device 302 may be capable of authenticating to a hotspot using EAP based authentication based on SIM credentials or non- EAP based authentication. The user device may include various hardware, software, and/or firmware components for controlling repeated attempts by user devices to authenticate with an AP of a hotspot. While certain components of the user device 302 may be described in the singular, it should be appreciated that multiple ones of any such components may be provided, and vice versa.

In an illustrative configuration, the user device 302 may include one or more processors (processor(s)) 312, one or more memory devices 314 (generically referred to herein as memory 314), one or more input/output ("I/O") interface(s) 316, one or more network interfaces 318, one or more sensors 320, one or more transceivers 322, and data storage 324. The user device 302 may further include a cellular antenna 304 for transmitting or receiving signals to/from a cellular network infrastructure (e.g., a mobile network infrastructure 212), an antenna 306 for transmitting or receiving Wi-Fi signals to/from an AP, an antenna 308 for receiving GNSS signals from a GNSS satellite, and one or more other antenna(s) 310 such as, for example, a Bluetooth antenna for transmitting or receiving Bluetooth signals, a Near Field Communication (NFC) antenna for transmitting or receiving NFC signals, and so forth. These various components will be described in more detail hereinafter.

The antennas 304, 306, 308, and 310 may include any suitable type of antenna depending, for example, on the communications protocols used to transmit or receive signals via the antennas 304, 306, 308, and 310. Non-limiting examples of suitable antennas may include directional antennas, non-directional antennas, dipole antennas, folded dipole antennas, patch antennas, multiple-input multiple-output (MIMO) antennas, or the like. The antennas 304, 306, 308, 310 may be communicatively coupled to one or more transceivers 322 or radio components to which or from which signals may be transmitted or received.

The cellular antenna 304 may be configured to transmit or receive signals in accordance with established standards and protocols, such as GSM, 3G standards (e.g., Universal Mobile Telecommunications System (UMTS), Wideband Code Division Multiple Access (W-CDMA), CDMA2000, etc.), 4G standards (e.g., LTE, WiMax, etc.), direct satellite communications, or the like.

The Wi-Fi antenna 306 may be configured to transmit or receive signals in accordance with established standards and protocols, such as IEEE 802.11 family of standards, including via 2.4 GHz channels (e.g. 802.1 1b, 802. l lg, 802.1 1η), 5 GHz channels (e.g. 802.11η, 802.1 lac), or 60 GHZ channels (e.g. 802. Had). In alternative example embodiments, the antenna 306 may be configured to transmit or receive radio frequency signals within the unlicensed portion of the radio spectrum.

The GNSS antenna 308 may be configured to receive GNSS signals from three or more GNSS satellites carrying time-position information to triangulate a position therefrom. The GNSS antenna 308 may be configured to receive GNSS signals from any current or planned GNSS such as, for example, the Global Positioning System (GPS), the GLONASS System, the Compass Navigation System, the Galileo System, or the Indian Regional Navigational System.

The transceiver 322 may include any suitable radio component(s) for, in cooperation with the antennas 304, 306, 308 or 310, transmitting or receiving radio frequency (RF) signals in the bandwidth and/or channels corresponding to the communications protocols utilized by the user device 302 to communicate with other devices. The transceiver 322 may include hardware, software, and/or firmware for modulating, transmitting, or receiving - potentially in cooperation with any of antennas 304, 306, 308, or 310 - communications signals according to any of the communications protocols discussed above including, but not limited to, one or more Wi-Fi and/or Wi-Fi direct protocols, as standardized by the IEEE 802.11 standards, one or more non- Wi-Fi protocols, or one or more cellular communications protocols or standards. The transceiver 322 may further include hardware, firmware, or software for receiving GNSS signals via, for example, the antenna 308. The transceiver 322 may include any known receiver and baseband suitable for communicating via the communications protocols utilized by the user device 302. The transceiver 322 may further include a low noise amplifier (LNA), additional signal amplifiers, an analog-to-digital (A/D) converter, one or more buffers, digital baseband, or the like.

The sensor(s) 320 may include any suitable type of sensing device such as, for example, inertial sensors, force sensors, thermal sensors, and so forth. Example types of inertial sensors may include accelerometers (e.g., MEMS-based accelerometers), gyroscopes, and so forth.

The memory 314 may include volatile memory (memory that maintains its state when supplied with power) such as random access memory (RAM) and/or non-volatile memory (memory that maintains its state even when not supplied with power) such as read-only memory (ROM), flash memory, and so forth. In various implementations, the memory 314 may include multiple different types of memory, such as various types of static random access memory (SRAM), various types of dynamic random access memory (DRAM), various types of unalterable ROM, and/or writeable variants of ROM such as electrically erasable programmable read-only memory (EEPROM), flash memory, and so forth. The memory 314 may include main memory as well as various forms of cache memory such as instruction cache(s), data cache(s), translation lookaside buffer(s) (TLBs), and so forth. Further, cache memory such as a data cache may be a multi-level cache organized as a hierarchy of one or more cache levels (LI, L2, etc.).

The data storage 324 may include removable storage and/or non-removable storage including, but not limited to, magnetic storage, optical disk storage, and/or tape storage. The data storage 324 may provide non-transient storage of computer-executable instructions and other data. The data storage 324 may include storage that is internal and/or external to the user device 302. The memory 314 and the data storage 324, removable and/or non-removable, are examples of computer-readable storage media (CRSM) as that term is used herein.

The data storage 324 may store computer-executable instructions that are loadable into the memory 314 and executable by the processor(s) 312 to cause various operations to be performed. The data storage 324 may additionally store data that may be copied to memory 314 for use by the processor(s) 312 during the execution of the computer-executable instructions. Moreover, output data generated as a result of execution of the computer-executable instructions by the processor(s) 312 may be stored initially in memory 314, and may ultimately be copied to data storage 324 for non-transient storage.

More specifically, the data storage 324 may store one or more operating systems (O/S) 326; one or more applications 328; one or more program modules or the like such as, for example, one or more location determination modules 330, one or more network association eligibility determination modules 332, and one or more network association/authentication modules 334; information or data such as, for example, eligibility information 336 and device state information 338; and so forth. The device state information 338 may include, for example, device mobility state information 340, device connection information 342, and device route information 344.

The location determination module(s) 330 may include computer-executable instructions that responsive to execution by one or more of the processor(s) 312 may cause any of a variety of operations to be performed related to determining a location of the user device 302, and potentially communicating the determined location to one or more wireless access network or core network nodes. The location determination module(s) 330 may be configured to determine the user device's 302 location from any of a variety of sources such as from GNSS signals received via antenna 308 and a GNSS receiver included in the transceiver(s) 322, from mobile network infrastructure 212 based triangulation, and/or from inertial sensors included among the sensor(s) 320, such as a MEMS-based multi-axis accelerometer.

According to certain example embodiments of the disclosure, computer-executable instructions of the location determination module(s) 330 may be executed to transmit location information to one or more nodes of an access network (e.g., an AP of a hotspot) or a core network (e.g., AAA server 226 of mobile core network 210). The location information may be transmitted as a location message including one or more data packets. Location messages may be transmitted by the user device 302 intermittently, such as at a predetermined frequency (e.g. every 2 seconds, every minute, etc.), a user selected frequency, and/or a network selected frequency.

The location information included in a location message may, in various example embodiments, include a set of spatial coordinates, a name of a place (e.g. neighborhood, zip code, building, etc.), or any other suitable identifier of a location of the user device 302. In example embodiments, the location information may be determined from GNSS signals and/or inertial sensors (e.g. accelerometers, gyroscopes, etc.) included among the sensor(s) 320. The location message may further include identifying information of the user device 302. For example, the identifying information may identify a subscription with a mobile communications network (e.g., the mobile core network 210, a roaming network 220, etc.). In example embodiments, the identifying information may be stored in the memory 314, data storage 324, and/or a SIM card of the user device 302 (if provided).

In certain example embodiments, the location determination module(s) 330 may further support functionality for identifying a planned route to be taken by the user device 302. The user device 302 may then communicate user device route information 344 indicative of planned routes to one or more network nodes. In still other example embodiments, the location determination module(s) 330 may support functionality for identifying predictive user device route information based on historical data indicative of historical routes traversed by the user device 302. The user device 302 may then communicate the predictive user device route information to one or more network nodes. As previously noted, planned or predictive user device route information 344 may be used to identify APs along the user device route. Subscriber information associated with the user device 302 may then be provided to APs along the device route such that the user device 302 may be permitted or prevented from authenticating with any particular AP based on the subscriber information and/or congestion or overloading conditions. In those embodiments in which the user device 302 is permitted to authenticate, predictive authentication utilizing, for example, key caching techniques may be performed.

The network association eligibility determination module(s) 332 may include computer- executable instructions that responsive to execution by one or more of the processor(s) 312 may cause operations to be performed for determining whether the user device 302 will be permitted to attempt to authenticate with an AP. The network association eligibility determination module(s) 332 may analyze the device state information 338 in relation to operator policies specified for controlling authentication aggressiveness in order to determine whether to permit the user device 302 to attempt to authenticate with any given AP. For example, the operator policies may specify eligibility information 336 (e.g., candidate mobility states for authenticating with a particular type of AP, threshold values, etc.) and associated eligibility criteria that the device state information must satisfy in order to be permitted to authenticate with an AP.

The network association/authentication module(s) 334 may include computer-executable instructions that responsive to execution by one or more of the processor(s) 312 may cause operations to be performed for authenticating and associating the user device with a hotspot (e.g., an AP of a hotspot). The network association/authentication module(s) 334 may support any of the authentication mechanisms described earlier.

As previously noted, the device state information 338 may include device mobility state information 340, device connection information 342, device route information 344, and so forth. The device mobility state information 338 may indicate a relative mobility of the user device 302 in relation to a hotspot (e.g., relative speed of the user device 302 in relation to an AP of the hotspot, average time spent within the coverage area of the hotspot, etc.). In certain example embodiments, the network association eligibility determination module(s) 332 may utilize the device mobility state information 340 to determine the type(s) of AP(s) with which the user device 302 may be permitted to authenticate. In certain example embodiments, various ranges of relative speed of the user device 302 with respect to an AP (or an AP's coverage area) and/or a measure of the time spent within the coverage area(s) of one or more hotspots may map to various mobility states, and each mobility state may, in turn, correspond to one or more types of APs.

In certain example embodiments, the user device 302 may only be permitted to authenticate to a particular type of AP if a relative speed of the user device 302 meets or falls below a corresponding threshold value for that type of AP. Further, in certain example embodiments, if the user device 302 is associated with certain mobility states (e.g., a vehicular mobility state corresponding to a particular range of speeds), the user device 302 may be permitted to authenticate with a particular AP type (e.g., an AP of a community hotspot deployment), but only after waiting a predetermined period of time. Further, in certain example embodiments, the network association eligibility determination module(s) 332 may be configured to assess device mobility state information 340 in conjunction with historical information associated with an AP to determine whether the device will be permitted to authenticate with the AP. For example, if historical information indicates that an AP is located in a high turnover location, that the average relative speed of user devices within the coverage area of the AP is above a certain threshold value (potentially specified in the eligibility information 336), or the like, the user device 302 may be required to have a lower mobility state or may be required to wait for a longer period of time to authenticate with the AP than may otherwise have been required based on the AP type alone.

As previously noted, the user device route information 344 may indicate a predefined or predictive route traversed by the user device 302. An operator of a hotspot may specify policies that indicate whether the user device 302 may be permitted to connect to the hotspot based on the user device route information 344. The location determination module(s) 330 may be configured to communicate the device route information 344 to one or more network nodes. A network node may then communicate the device route information 344 as well as subscriber information associated with the user device 302 to any given AP along a route specified in the device route information 344. Any such AP may then either permit the user device 302 to authenticate or may deny authentication if, for example, the hotspot associated with that AP is congested or overloaded, or if, for example, the user device 302 will only be present within the coverage area of the hotspot for a limited duration of time (e.g., an amount of time that meets or falls below an associated threshold). In certain example embodiments, if the operator of the hotspot has implemented some form of key caching or management, the AP may pre-authenticate the user device 302.

In certain example embodiments, the user device connection information 342 may correspond to or otherwise indicate a received signal strength indication (RSSI) included in an association request received by an AP from the user device 302. In certain example embodiments, the AP may transmit a response to the user device 302 denying association if the RSSI of the association request meets or falls below a threshold value 336. The response may further specify a delay time period for the user device 302 to wait prior to again attempting association with the AP. The delay time period may be stored on the user device 302 as part of the device connection information. In this manner, user devices that are located on the periphery of the coverage area of an AP or user devices that are only temporarily present within the coverage area may be prevented from associating with the AP. The device connection information 342 may optionally include information (e.g., a counter) indicative of a number of failed authentications by the user device 302 to a hotspot since the last successful authentication. The user device 302 may then be prevented from authenticating with the hotspot if the counter meets or exceeds a threshold value. The user device may be prevented from authenticating for a predetermined period of time or until the counter is reset. The counter may be reset each time the user device successfully authenticates to the hotspot.

Referring now to other illustrative components of the user device 302, the O/S 326 may be loaded into the memory 314 and may provide an interface between other application software executing on the user device 302 and hardware resources of the user device 302. More specifically, the O/S 326 may include a set of computer-executable instructions for managing hardware resources of the user device 302 and for providing common services to other application programs (e.g., managing memory allocation among various application programs). The O/S 326 may include any operating system now known or which may be developed in the future including, but not limited to, any server operating system, any mainframe operating system, or any other proprietary or non-proprietary operating system.

The application(s) 328 may include any suitable application executable, at least in part, on the user device 302. The application(s) 328 may include computer-executable instructions executable by one or more of the processor(s) 312 to provide any of a variety of types of functionality including, but not limited to, directional transmission and reception of wireless signals, task processing, web browsing, business task functionality, communications functionality, graphics processing functionality, word processing, publishing, spreadsheet functionality, database functionality, gaming functionality, multimedia functionality, or the like.

The processor(s) 312 may be configured to access the memory 314 and execute computer- executable instructions stored therein. For example, the processor(s) 312 may be configured to execute computer-executable instructions of the various program modules, applications, or the like of the user device 302 to cause or facilitate various operations to be performed in accordance with one or more embodiments of the disclosure. The processor(s) 312 may include any suitable processing unit capable of accepting digital data as input, processing the input data in accordance with stored computer-executable instructions, and generating output data.

The processor(s) 312 may include any type of suitable processing unit including, but not limited to, a central processing unit, a microprocessor, a Reduced Instruction Set Computer (RISC) microprocessor, a Complex Instruction Set Computer (CISC) microprocessor, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), a System-on-a-Chip (SoC), a digital signal processor (DSP), and so forth. Further, the processor(s) 312 may have any suitable microarchitecture design that includes any number of constituent components such as, for example, registers, multiplexers, arithmetic logic units, cache controllers for controlling read/write operations to cache memory, branch predictors, or the like. The microarchitecture design of the processor(s) 312 may be capable of supporting any of a variety of instruction sets.

The user device 302 may further include one or more input/output (I/O) interfaces 316 that may facilitate the receipt of input information by the user device 302 from one or more I/O devices as well as the output of information from the user device 302 to the one or more I/O devices. The I/O devices may include, for example, one or more user interface devices that facilitate interaction between a user and the user device 302 including, but not limited to, a display, a keypad, a pointing device, a control panel, a touch screen display, a remote control device, a microphone, a speaker, and so forth. The I O devices may further include, for example, any number of peripheral devices such as data storage devices, printing devices, and so forth.

The user device 302 may be configured to communicate with any of a variety of other systems, platforms, networks, devices, and so forth via one or more networks. For example, the user device 302 may include one or more network interfaces 318 that may facilitate communication between the user device 302 and any of the systems, networks, platforms, devices, or components of the system architecture 200.

FIG. 4 is a schematic block diagram of an illustrative network node device 402 in accordance with one or more example embodiments of the disclosure. The network node device 402 may correspond to any device forming part of the architecture 200 such as, for example, an AP (e.g., the AP 202), the WAG 208, a AAA server (e.g., back-end AAA server 218, mobile network AAA server 226, etc.), and so forth.

In an illustrative configuration, the network node device 402 may include one or more processors (processors )) 404, one or more memory devices 406 (generically referred to herein as memory 406), one or more input/output ("I/O") interface(s) 408, one or more network interfaces 410, and data storage 412. These various components will be described in more detail hereinafter.

The memory 406 may include any of types and/or configurations of memory described through reference to the memory 314 of the user device 302. In certain example embodiments, an amount of memory capacity of the network node device 402 may exceed that of the user device 302. Similarly, the data storage 412 may include any of the types of data storage described through reference to the data storage 324.

The data storage 412 may store computer-executable instructions that are loadable into the memory 406 and executable by the processor(s) 404 to cause various operations to be performed. The data storage 412 may additionally store data that may be copied to memory 406 for use by the processor(s) 404 during the execution of the computer-executable instructions. Moreover, output data generated as a result of execution of the computer-executable instructions by the processor(s) 404 may be stored initially in memory 406, and may ultimately be copied to data storage 412 for non-transient storage.

More specifically, the data storage 412 may store one or more operating systems (O/S) 414; one or more database management systems (DBMS 416); one or more applications, program modules or the like such as, for example, one or more network management module(s) 418 and one or more network association eligibility determination module(s) 420; information/data such as, for example, eligibility information 422 and user profile(s) 424; and so forth.

The network management module(s) 418 may include computer-executable instructions that responsive to execution by one or more of the processor(s) 404 may cause operations to be performed relating to authenticating user devices on a Wi-Fi hotspot or mobile core network, managing device connectivity, managing receipt of device state information, and so forth.

The network association eligibility determination module(s) 420 may include computer- executable instructions that responsive to execution by one or more of the processor(s) 404 may cause operations to be performed for determining whether a user device should be permitted to authenticate to a network such as a hotspot. The network association eligibility determination module(s) 420 may be configured to analyze information included in a user profile 424 associated with a user device (e.g., device state information, information indicative of whether fast re-authentication has been enabled for a device, association retry delay time periods for a user device, etc.) in relation to operator policies that may specify eligibility information 422 (e.g., candidate mobility states for a given type of AP, threshold values that must be met, etc.) and associated eligibility criteria for authenticating with a hotspot in order to determine whether to permit a user device to authenticate with the hotspot.

Referring now to FIG. 5, a schematic block diagram of an illustrative user profile 502 in accordance with one or more example embodiments of the disclosure is depicted. The example user profile 502 may associated with a particular user device that may or may not be associated with a subscription with a mobile communications network. Regardless of whether the user device is a subscriber device or a non-subscriber device, the user device may be configured to seamlessly authenticate with one or more hotspots operated by entities that have entered into roaming agreements with a mobile communications network operator. Information included in the user profile 502 for the user device may be assessed in conjunction with operator policies, network congestion or overload state, or the like to determine whether to permit the user device to authenticate to the operator's hotspot.

The example user profile 502 may include user device mobility state information 504

(which may correspond to at least a portion of the device mobility state information 340), user device location information 506, unsuccessful connection attempts information 508 (which may correspond to at least a portion of the device connection information 342), user device route information (which may correspond to at least a portion of the device route information 344), fast re-authentication information 512, and association retry delay information 514.

In certain example embodiments, the user profile 502 may be implemented as an additional node in a set of nodes that define a hotspot operator's subscription policy for a user device. Each of the example types of information that may form part of the user profile 502 may correspond to leaf nodes within the user profile node. Each of the leaf nodes may specify values for one or more data types such as, for example, Boolean data types, integer data types, floating-point data types, real-value data types, string data types, and so forth. As a non-limiting example, the device mobility state information 504 may specify a value indicative of the user device's current mobility state which may be based on, for example, the device's instantaneous or average relative speed in relation to an AP or an AP's coverage area. As another non-limiting example, the user device location information 506 may include string values indicative of a current or a historical location of the user device. As yet another non-limiting example, the user device route information 510 may specify string values indicative of predefined or predictive routes for the user device. As still another non-limiting example, the fast re-authentication information may include a Boolean value indicative of whether fast re-authentication is permitted for the user device. As still another non-limiting example, the association retry delay information 514 may specify a delay period that the user device must wait before attempting to authenticate with an AP.

It should be appreciated by one of ordinary skill in the art that the types of information shown in FIG. 5 are merely illustrative and not exhaustive. In addition, it should be appreciated by one of ordinary skill in the art that the node configuration discussed above is merely illustrative and not exhaustive and that the user profile information may be organized in accordance with any suitable configuration.

Referring again to FIG. 4, and in particular, other illustrative components of the network node device, the O/S 414 may be loaded into the memory 406 and may provide an interface between other application software executing on the network node device 402 and hardware resources of the network node device 402. More specifically, the O/S 414 may include a set of computer-executable instructions for managing hardware resources of the network node device 402 and for providing common services to other application programs (e.g., managing memory allocation among various application programs). The O/S 414 may include any operating system now known or which may be developed in the future including, but not limited to, any server operating system, any mainframe operating system, or any other proprietary or non-proprietary operating system. The DBMS 416 may be loaded into the memory 406 and may support functionality for accessing, retrieving, storing, and/or manipulating data stored in one or more of the datastores 426, data stored in the memory 406, and/or data stored in the data storage 412. The DBMS 416 may use any of a variety of database models (e.g., relational model, object model, etc.) and may support any of a variety of query languages. The datastore(s) 426 may include any suitable data repository including, but not limited to, databases (e.g., relational, object-oriented, etc.), file systems, flat files, distributed datastores in which data is stored on more than one node of a computer network, peer-to-peer network datastores, or the like. Any of the datastore(s) 426 may represent data in one or more data schemas. The datastore(s) 426 may store any of the data depicted as being stored in the data storage 412.

The processor(s) 404 may be configured to access the memory 406 and execute computer- executable instructions stored therein. For example, the processor(s) 404 may be configured to execute computer-executable instructions of the various program modules of the network node device 402 to cause or facilitate various operations to be performed in accordance with one or more embodiments of the disclosure. The processor(s) 404 may include any suitable processing unit capable of accepting digital data as input, processing the input data in accordance with stored computer-executable instructions, and generating output data.

The processor(s) 404 may include any of the types of processing units described through reference to the processor(s) 312 of the user device 302. In certain example embodiments, the processor(s) 404 may have increased processing power (e.g., more clock cycles) than the processor(s) 312. Further, the processor(s) 404 may have any suitable microarchitecture design that includes any number of constituent components such as, for example, registers, multiplexers, arithmetic logic units, cache controllers for controlling read/write operations to cache memory, branch predictors, or the like. The microarchitecture design of the processor(s) 404 may be capable of supporting any of a variety of instruction sets.

The network node device 402 may further include one or more input/output (I/O) interfaces 408 that may facilitate the receipt of input information by the network node device 402 from one or more I O devices as well as the output of information from the network node device 402 to the one or more I/O devices. The I/O devices may include, for example, one or more user interface devices that facilitate interaction between a user and the network node device 402 including, but not limited to, a display, a keypad, a pointing device, a control panel, a touch screen display, a remote control device, a microphone, a speaker, and so forth. The I/O devices may further include, for example, any number of peripheral devices such as data storage devices, printing devices, and so forth. The network node device 402 may be configured to communicate with any of a variety of other systems, platforms, networks, devices, and so forth via one or more networks. For example, the network node device 402 may include one or more network interfaces 410 that may facilitate communication between the network node device 402 and any of the systems, networks, platforms, devices, or components of the system architecture 200.

It should be appreciated that the program modules or applications depicted in FIG. 3 and 4 are merely illustrative and not exhaustive and that processing described as being supported by any particular module may alternatively be distributed across multiple modules or performed by a different module. In addition, various program module(s), script(s), plug-in(s), Application Programming Interface(s) (API(s)), or any other suitable computer-executable code hosted locally or remotely may be provided to support functionality provided by the program modules depicted in FIG. 3 or FIG. 4 and/or additional or alternate functionality. Further, functionality may be modularized differently such that processing described as being supported collectively by the collection of program modules depicted in FIG. 3 or FIG. 4 may be performed by a fewer or greater number of modules, or functionality described as being supported by any particular module may be supported, at least in part, by another module. In addition, program modules that support the functionality described herein may form part of one or more applications executable across any number of systems or devices of the system architecture 200 in accordance with any suitable computing model such as, for example, a client-server model, a peer-to-peer model, and so forth. In addition, any of the functionality described as being supported by any of the program modules depicted in FIG. 3 or FIG. 4 may be implemented, at least partially, in hardware and/or firmware across any number of devices.

It should further be appreciated that any illustrative component of the system architecture 200 (e.g., the user device 302 depicted in FIG. 3, the network node device depicted in FIG. 4, etc.) may include alternate and/or additional hardware, software, or firmware components beyond those described or depicted without departing from the scope of the disclosure. More particularly, it should be appreciated that software, firmware, or hardware components depicted as forming part any illustrative component are merely illustrative and that some components may not be present or additional components may be provided in various embodiments. While various illustrative program modules have been depicted as software modules stored in data storage, it should be appreciated that functionality described as being supported by the program modules may be enabled by any combination of hardware, software, and/or firmware. It should further be appreciated that each of the above-mentioned modules may, in various embodiments, represent a logical partitioning of supported functionality. This logical partitioning is depicted for ease of explanation of the functionality and may not be representative of the structure of software, hardware, and/or firmware for implementing the functionality. Accordingly, it should be appreciated that functionality described as being provided by a particular module may, in various embodiments, be provided at least in part by one or more other modules. Further, one or more depicted modules may not be present in certain embodiments, while in other embodiments, additional modules not depicted may be present and may support at least a portion of the described functionality and/or additional functionality. Moreover, while certain modules may be depicted and described as sub-modules of another module, in certain embodiments, such modules may be provided as independent modules or as sub-modules of other modules.

ILLUSTRATIVE PROCESSES

FIG. 6 is a process flow diagram of an illustrative method 600 for controlling attempts by a user device to authenticate with a network such as a Wi-Fi hotspot in accordance with one or more embodiments of the disclosure. In certain example embodiments, one or more operations of the method 600 may be performed responsive to execution of computer-executable instructions provided as part of the network association eligibility determination module(s) 332 of a user device 302. It should be appreciated, however, that any of the operations of the method 600 may be performed by another device or component of the system architecture 200. In addition, it should be appreciated that processing performed in response to execution of computer-executable instructions provided as part of an application, program module, or the like may be described herein as being performed by the application or the program module itself, by a device on which the application, program module, or the like is executing, or by a system that includes such a device. While the operations of the method 600 are described in the context of the illustrative system architecture 200, it should be appreciated that the method 600 may be implemented in connection with numerous other architectural and device level configurations.

At block 602, the network association eligibility determination module(s) 332 may determine a user device is within the coverage area of an AP. Thereafter, at block 604, the network association eligibility determination module(s) 332 may identify device state information associated with the user device and any corresponding operator-specified eligibility information and associated eligibility criteria. For example, device mobility state information indicative of a relative speed of the user device, threshold speed ranges for identifying a corresponding mobility state of the user device, and mappings between AP types and permitted mobility states may be identified. At block 606, the network association eligibility determination module(s) 332 may determine whether the device state information satisfies the eligibility criteria. The determination at block 606 may include analyzing the device state information in relation to the eligibility information to determine whether the eligibility criteria are satisfied. For example, at block 606, it may be determined whether the device's mobility state is a permitted mobility state for authenticating with the AP type.

In response to a positive determination at block 606, an association request message may be generated and transmitted to the AP at block 608. In response to a negative determination at block 606, the user device may refrain from generating the association request message at block 610. It should be appreciated that the network association eligibility determination module(s) 332 may assess any of a variety of other types of device state information (e.g., number of unsuccessful authentication attempts, association retry delay periods, etc.) to determine whether to generate the association request message or refrain from generating the message. It should further be appreciated that refraining from generating the association request message at block 610 may, in certain example embodiments, involve waiting for a specified delay period before generating the association request message.

FIG. 7 is a process flow diagram of another illustrative method 700 for controlling attempts by a user device to authenticate with a network such as a Wi-Fi hotspot in accordance with one or more embodiments of the disclosure. In certain example embodiments, one or more operations of the method 700 may be performed responsive to execution of computer-executable instructions provided as part of the network association eligibility determination module(s) 420 of a network node device 402. It should be appreciated, however, that any of the operations of the method 700 may be performed by another device or component of the system architecture 200. In addition, it should be appreciated that processing performed in response to execution of computer-executable instructions provided as part of an application, program module, or the like may be described herein as being performed by the application or the program module itself, by a device on which the application, program module, or the like is executing, or by a system that includes such a device. While the operations of the method 700 are described in the context of the illustrative system architecture 200, it should be appreciated that the method 700 may be implemented in connection with numerous other architectural and device level configurations.

At block 702, the network association eligibility determination module(s) 420 may identify a request received from a user device to authenticate with an AP. The request may be, for example, an association request message. At block 704, the network association eligibility determination module(s) 420 may identify user profile information associated with the user device, information including the request to authenticate, and/or operator-specified eligibility information and associated eligibility criteria. The user profile information may be retrieved from a subscription profile associated with the user device and may include any of the types of example information depicted in FIG. 5. Information included in the request (e.g., SIM information) may be used to identify the user profile information. In addition, information identified from the request may include an RSSI of the association request frame that is received. The eligibility information may identify mobility states that are permitted to authenticate with the AP; threshold values such as an RSSI threshold, a maximum number of permitted failed authentication attempts, or the like; and so forth.

At block 706, the network association eligibility determination module(s) 420 may determine whether the user profile information and/or the information included in the association request satisfies the eligibility criteria for authenticating with the AP. In response to a negative determination at block 706, the method 700 may proceed to block 710, and the user device may be prevented from authenticating with the AP. As a non-limiting example, the user device's mobility state may not be a permitted mobility state for the type of AP. As another non-limiting example, the RSSI of the association request frame may not satisfy a corresponding threshold for the AP. In certain example embodiments, the user device may be required to wait for a delay period before attempting to authenticate with the AP again such as, for example, when the RSSI is at or below a threshold value or when the mobility state is at or above a certain threshold.

On the other hand, in response to a positive determination at block 706, the method 700 may proceed to block 708 where a determination may be made as to whether network congestion or overload characteristics of a hotspot that includes the AP are such that the user is permitted to authenticate. In response to a negative determination at block 708, the method 700 may proceed to block 710, and the user device may be prevented from authenticating with the AP. For example, the user device may be prevented from authenticating if the hotspot is congested or overloaded, even in those scenarios in which the user profile information and/or information included in the association request otherwise indicates that the user device should be permitted to authenticate.

In response to a positive determination at block 708, a determination may be made at block

712 as to whether the user profile information indicates that fast re-authentication has been enabled for the user device. For example, the fast re-authentication information 512 included in the user profile may be assessed to determine whether fast re-authentication has been enabled for the user device. In response to a negative determination at block 712, the user device may be permitted to authenticate in accordance with an appropriate authentication protocol (e.g., an EAP based protocol, a non-EAP based protocol, etc.). In response to a positive determination at block 714, fast re-authentication of the user device may be performed utilizing, for example, a key caching technique including any of those previously described.

The operations described and depicted in the illustrative methods of FIGS. 6 and 7 may be carried out or performed in any suitable order as desired in various example embodiments of the disclosure. Additionally, in certain example embodiments, at least a portion of the operations may be carried out in parallel. Furthermore, in certain example embodiments, less, more, or different operations than those depicted in FIGS. 6 and 7 may be performed.

Although specific embodiments of the disclosure have been described, one of ordinary skill in the art will recognize that numerous other modifications and alternative embodiments are within the scope of the disclosure. For example, any of the functionality and/or processing capabilities described with respect to a particular device or component may be performed by any other device or component. Further, while various illustrative implementations and architectures have been described in accordance with embodiments of the disclosure, one of ordinary skill in the art will appreciate that numerous other modifications to the illustrative implementations and architectures described herein are also within the scope of this disclosure.

Certain aspects of the disclosure are described above with reference to block and flow diagrams of systems, methods, apparatuses, and/or computer program products according to example embodiments. It will be understood that one or more blocks of the block diagrams and flow diagrams, and combinations of blocks in the block diagrams and the flow diagrams, respectively, may be implemented by execution of computer-executable program instructions. Likewise, some blocks of the block diagrams and flow diagrams may not necessarily need to be performed in the order presented, or may not necessarily need to be performed at all, according to some embodiments. Further, additional components and/or operations beyond those depicted in blocks of the block and/or flow diagrams may be present in certain embodiments.

Accordingly, blocks of the block diagrams and flow diagrams support combinations of means for performing the specified functions, combinations of elements or steps for performing the specified functions, and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and flow diagrams, and combinations of blocks in the block diagrams and flow diagrams, may be implemented by special-purpose, hardware-based computer systems that perform the specified functions, elements or steps, or combinations of special-purpose hardware and computer instructions. Program modules, applications, or the like disclosed herein may include one or more software components including, for example, software objects, methods, data structures, or the like. Each such software component may include computer-executable instructions that, responsive to execution, cause at least a portion of the functionality described herein (e.g., one or more operations of the illustrative methods described herein) to be performed.

A software component may be coded in any of a variety of programming languages. An illustrative programming language may be a lower-level programming language such as an assembly language associated with a particular hardware architecture and/or operating system platform. A software component comprising assembly language instructions may require conversion into executable machine code by an assembler prior to execution by the hardware architecture and/or platform.

Another example programming language may be a higher-level programming language that may be portable across multiple architectures. A software component comprising higher- level programming language instructions may require conversion to an intermediate representation by an interpreter or a compiler prior to execution.

Other examples of programming languages include, but are not limited to, a macro language, a shell or command language, a job control language, a script language, a database query or search language, or a report writing language. In one or more example embodiments, a software component comprising instructions in one of the foregoing examples of programming languages may be executed directly by an operating system or other software component without having to be first transformed into another form.

A software component may be stored as a file or other data storage construct. Software components of a similar type or functionally related may be stored together such as, for example, in a particular directory, folder, or library. Software components may be static (e.g., pre- established or fixed) or dynamic (e.g., created or modified at the time of execution).

Software components may invoke or be invoked by other software components through any of a wide variety of mechanisms. Invoked or invoking software components may comprise other custom-developed application software, operating system functionality (e.g., device drivers, data storage (e.g., file management) routines, other common routines and services, etc.), or third-party software components (e.g., middleware, encryption, or other security software, database management software, file transfer or other network communication software, mathematical or statistical software, image processing software, and format translation software).

Software components associated with a particular solution or system may reside and be executed on a single platform or may be distributed across multiple platforms. The multiple platforms may be associated with more than one hardware vendor, underlying chip technology, or operating system. Furthermore, software components associated with a particular solution or system may be initially written in one or more programming languages, but may invoke software components written in another programming language.

Computer-executable program instructions may be loaded onto a special-purpose computer or other particular machine, a processor, or other programmable data processing apparatus to produce a particular machine, such that execution of the instructions on the computer, processor, or other programmable data processing apparatus causes one or more functions or operations specified in the flow diagrams to be performed. These computer program instructions may also be stored in a computer-readable storage medium (CRSM) that upon execution may direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement one or more functions or operations specified in the flow diagrams. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational elements or steps to be performed on the computer or other programmable apparatus to produce a computer- implemented process.

Additional types of CRSM that may be present in any of the devices described herein may include, but are not limited to, programmable random access memory (PRAM), SRAM, DRAM, RAM, ROM, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the information and which can be accessed. Combinations of any of the above are also included within the scope of CRSM. Alternatively, computer-readable communication media (CRCM) may include computer-readable instructions, program modules, or other data transmitted within a data signal, such as a carrier wave, or other transmission. However, as used herein, CRSM does not include CRCM.

Although embodiments have been described in language specific to structural features and/or methodological acts, it is to be understood that the disclosure is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as illustrative forms of implementing the embodiments. Conditional language, such as, among others, "can," "could," "might," or "may," unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments could include, while other embodiments do not include, certain features, elements, and/or steps. Thus, such conditional language is not generally intended to imply that features, elements, and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements, and/or steps are included or are to be performed in any particular embodiment.

A method for controlling authentication aggressiveness according to one or more example embodiments of the disclosure may include identifying, by a network association eligibility determination system comprising one or more network node devices comprising one or more computer processors, a request from a user device to associate with a network; identifying, by the network association eligibility determination system, information included in the request; identifying, by the network association eligibility determination system, stored user profile information associated with the user device; identifying, by the network association eligibility determination system, eligibility information and one or more eligibility criteria for associating with the network; determining, by the network association eligibility determination system, whether the one or more eligibility criteria are satisfied based at in part on the i) eligibility information and 2) at least a portion of the user profile information or at least a portion of the information included in the request; and determining, by the network association eligibility determination system, whether to permit the user device to associate with the network based at least in part on determining whether the one or more eligibility criteria are satisfied.

According to any of the example embodiments disclosed herein, the user profile information may include device mobility state information, and the eligibility information may include information indicative of a set of one or more candidate mobility states associated with the network. A method according to any of the example embodiments disclosed herein may further include determining, by the network association eligibility determination system, a mobility state associated with the user device based at least in part on the device mobility state information; and determining, by the network association eligibility determination system, that the mobility state associated with the device is not included in the set of one or more candidate mobility states, where it is determined that at least one eligibility criterion of the one or more eligibility criteria is not satisfied based at least in part on determining that the mobility state associated with the device is not included in the set of one or more candidate mobility states, and where it is determined that the user device is not permitted to associate with the network based at least in part on determining that the at least one eligibility criterion is not satisfied. A method according to any of the example embodiments disclosed herein may further include determining the mobility state associated with the user device by determining, by the network association eligibility determination system, a relative speed of the user device with respect to an access point (AP) of the network or a coverage area of the AP; identifying, by the network association eligibility determination system, stored information indicative of a mapping between one or more ranges of speeds to one or more corresponding mobility states; determining, by the network association eligibility determination system, that the relative speed of the user device falls within a particular range of speed; and identifying, by the network association eligibility determination system, a particular mobility state corresponding to the particular range of speed based at least in part on the mapping, where the mobility state associated with the user device may be the particular mobility state.

According to any of the example embodiments disclosed herein, the mobility state associated with the device may be a first mobility state. A method according to any of the example embodiments disclosed herein may further include determining, by the network association eligibility determination system, a second mobility state associated with the user device based at least in part on the device mobility state information; and determining, by the network association eligibility determination system, that the second mobility state associated with the device is included in the set of one or more candidate mobility states, where it is determined that the one or more eligibility criteria are satisfied based at least in part on determining that the second mobility state associated with the device is included in the set of one or more candidate mobility states, where it is determined that the user device is permitted to associate with the network based at least in part on determining that the one or more eligibility criteria are satisfied.

A method according to any of the example embodiments disclosed herein may include determining, by the network association eligibility determination system, that the second mobility state is associated with a range of speeds having a lower bound that exceeds a threshold value; determining, by the network association eligibility determination system, a delay time period responsive to determining that the second mobility state is associated with the range of speeds having a lower bound that exceeds the threshold value; and directing, by the network association eligibility determination system, transmission of an indication of the delay time period to the user device, where the user device may not be permitted to associate with the network until expiration of the delay time period.

According to any of the example embodiments disclosed herein, the user device may be a first user device. A method according to any of the example embodiments disclosed herein may further include receiving, the network association eligibility determination system, user device route information indicative of a travel route associated with a second user device; determining, by the network association eligibility determination system, one or more network overload or congestion characteristics associated with the network; and determining, by the network association eligibility determination system, whether to permit the second user device to associate with the network based at least in part on the one or more network overload or congestion characteristics.

According to any of the example embodiments disclosed herein, it may be determined that the second user device is permitted to associate with the network. A method according to any of the example embodiments disclosed herein may further include enabling, by the network association eligibility determination system, fast re-authentication of the second user device by the network; and pre-authenticating, by the network association eligibility determination system, the second user device with the network.

According to any of the example embodiments disclosed herein, fast re-authentication of the second user device may include utilizing a cached key to authenticate the second user device, where the key is cached at the network based at least in part on the pre-authenticating of the second user device with the network.

According to any of the example embodiments disclosed herein, the request may be an association request, the at least a portion of the information included in the request may include an indication of a signal strength of the request, and the eligibility information may include a threshold signal strength for associating with the network. A method according to any of the example embodiments disclosed herein, may include determining, by the network association eligibility determination system, that the signal strength of the request falls below the threshold signal strength for associating with the network, where it is determined that at least one eligibility criterion of the one or more eligibility criteria is not satisfied based at least in part on determining that the signal strength of the request falls below the threshold signal strength for associating with the network, and where it is determined that the user device is not permitted to associate with the network based at least in part on determining that the at least one eligibility criterion is not satisfied.

A method according to any of the example embodiments disclosed herein may include determining, by the network association eligibility determination system, that the user device is permitted to attempt to associate with the network after expiration of a delay time period.

According to any of the example embodiments disclosed herein, the user profile information may include a counter indicative of a number of unsuccessful attempts by the user device to authenticate with the network, and the eligibility information may include a threshold number of unsuccessful authentication attempts. A method according to any of the example embodiments disclosed herein may include determining, by the network association eligibility determination system, that the counter exceeds the threshold number of unsuccessful authentication attempts, wherein it is determined that at least one eligibility criterion of the one or more eligibility criteria is not satisfied based at least in part on determining that the counter exceeds the threshold number of unsuccessful authentication attempts, and wherein it is determined that the user device is not permitted to associate with the network based at least in part on determining that the at least one eligibility criterion is not satisfied.

A system for controlling authentication aggressiveness according to one or more example embodiments of the disclosure may include at least one memory storing computer-executable instructions; and at least one processor communicatively coupled to the at least one memory, where the at least one processor access the at least one memory and executes the computer- executable instructions to: identify a request from a user device to associate with a network; identify information included in the request; identify stored user profile information associated with the user device; identify eligibility information and one or more eligibility criteria for associating with the network; determine whether the one or more eligibility criteria are satisfied based at in part on the i) eligibility information and 2) at least a portion of the user profile information or at least a portion of the information included in the request; and determine whether to permit the user device to associate with the network based at least in part on determining whether the one or more eligibility criteria are satisfied.

According to any of the example embodiments disclosed herein, the user profile information may include device mobility state information, the eligibility information may include information indicative of a set of one or more candidate mobility states associated with the network, and the at least one processor may be further configured to execute the computer- executable instructions to: determine a mobility state associated with the user device based at least in part on the device mobility state information; and determine that the mobility state associated with the device is not included in the set of one or more candidate mobility states, where it is determined that at least one eligibility criterion of the one or more eligibility criteria is not satisfied based at least in part on determining that the mobility state associated with the device is not included in the set of one or more candidate mobility states, and where it is determined that the user device is not permitted to associate with the network based at least in part on determining that the at least one eligibility criterion is not satisfied. According to any of the example embodiments disclosed herein, the at least one processor may be configured to determine the mobility state associated with the user device by executing the computer-executable instructions to: determine a relative speed of the user device with respect to an access point (AP) of the network or a coverage area of the AP; identify stored information indicative of a mapping between one or more ranges of speeds to one or more corresponding mobility states; determine that the relative speed of the user device falls within a particular range of speed; and identify a particular mobility state corresponding to the particular range of speed based at least in part on the mapping, wherein the mobility state associated with the user device is the particular mobility state.

According to any of the example embodiments disclosed herein, the mobility state associated with the device may be a first mobility state, and the at least one processor may be further configured to execute the computer-executable instructions to: determine a second mobility state associated with the user device based at least in part on the device mobility state information; and determine that the second mobility state associated with the device is included in the set of one or more candidate mobility states, wherein it is determined that the one or more eligibility criteria are satisfied based at least in part on determining that the second mobility state associated with the device is included in the set of one or more candidate mobility states, and wherein it is determined that the user device is permitted to associate with the network based at least in part on determining that the one or more eligibility criteria are satisfied.

According to any of the example embodiments disclosed herein, the at least one processor may be configured to: determine that the second mobility state is associated with a range of speeds having a lower bound that exceeds a threshold value; determine a delay time period responsive to determining that the second mobility state is associated with the range of speeds having a lower bound that exceeds the threshold value; and direct transmission of an indication of the delay time period to the user device, wherein the user device is not permitted to associate with the network until expiration of the delay time period.

According to any of the example embodiments disclosed herein, the user device may be a first user device, and the at least one processor may be further configured to execute the computer-executable instructions to: receive user device route information indicative of a travel route associated with a second user device; determine one or more network overload or congestion characteristics associated with the network; and determine whether to permit the second user device to associate with the network based at least in part on the one or more network overload or congestion characteristics. According to any of the example embodiments disclosed herein, it may be determined that the second user device is permitted to associate with the network, and the at least one processor may be further configured to execute the computer-executable instructions to: enable fast re- authentication of the second user device by the network; and pre-authenticate the second user device with the network.

According to any of the example embodiments disclosed herein, fast re-authentication of the second user device may include utilizing a cached key to authenticate the second user device, and the key may be cached at the network based at least in part on the pre-authenticating of the second user device with the network.

According to any of the example embodiments disclosed herein, the request may be an association request, the at least a portion of the information included in the request may include an indication of a signal strength of the request, and the at least one processor may be further configured to execute the computer-executable instructions to: determine that the signal strength of the request falls below the threshold signal strength for associating with the network, and wherein it is determined that at least one eligibility criterion of the one or more eligibility criteria is not satisfied based at least in part on determining that the signal strength of the request falls below the threshold signal strength for associating with the network, and wherein it is determined that the user device is not permitted to associate with the network based at least in part on determining that the at least one eligibility criterion is not satisfied.

According to any of the example embodiments disclosed herein, the at least one processor may be further configured to execute the computer-executable instructions to: determine that the user device is permitted to attempt to associate with the network after expiration of a delay time period.

According to any of the example embodiments disclosed herein, the user profile information may include a counter indicative of a number of unsuccessful attempts by the user device to authenticate with the network, the eligibility information may include a threshold number of unsuccessful authentication attempts, and the at least one processor may be further configured to execute the computer-executable instructions to: determine that the counter exceeds the threshold number of unsuccessful authentication attempts, wherein it is determined that at least one eligibility criterion of the one or more eligibility criteria is not satisfied based at least in part on determining that the counter exceeds the threshold number of unsuccessful authentication attempts, and wherein it is determined that the user device is not permitted to associate with the network based at least in part on determining that the at least one eligibility criterion is not satisfied. According to one or more example embodiments disclosed herein, a system for controlling authentication aggressiveness may include a means for identifying a request from a user device to associate with a network; a means for identifying information included in the request; a means for identifying stored user profile information associated with the user device; a means for identifying eligibility information and one or more eligibility criteria for associating with the network; a means for determining whether the one or more eligibility criteria are satisfied based at in part on the i) eligibility information and 2) at least a portion of the user profile information or at least a portion of the information included in the request; and a means for determining whether to permit the user device to associate with the network based at least in part on determining whether the one or more eligibility criteria are satisfied.

According to any of the example embodiments disclosed herein, the user profile information may include device mobility state information, the eligibility information may include information indicative of a set of one or more candidate mobility states associated with the network, and system according to any of the example embodiments disclosed herein may further include a means determining a mobility state associated with the user device based at least in part on the device mobility state information; and a means for determining that the mobility state associated with the device is not included in the set of one or more candidate mobility states, wherein it is determined that at least one eligibility criterion of the one or more eligibility criteria is not satisfied based at least in part on determining that the mobility state associated with the device is not included in the set of one or more candidate mobility states, and wherein it is determined that the user device is not permitted to associate with the network based at least in part on determining that the at least one eligibility criterion is not satisfied.

A system according to any of the example embodiments disclosed herein, may further include a means for determining a relative speed of the user device with respect to an access point (AP) of the network or a coverage area of the AP; a means for identifying stored information indicative of a mapping between one or more ranges of speeds to one or more corresponding mobility states; a means for determining that the relative speed of the user device falls within a particular range of speed; and a means for identifying a particular mobility state corresponding to the particular range of speed based at least in part on the mapping, wherein the mobility state associated with the user device is the particular mobility state.

According to any of the example embodiments disclosed herein, the mobility state associated with the device may be a first mobility state. A system according to any of the example embodiments disclosed herein may further include a means for determining a second mobility state associated with the user device based at least in part on the device mobility state information; and a means for determining that the second mobility state associated with the device is included in the set of one or more candidate mobility states, wherein it is determined that the one or more eligibility criteria are satisfied based at least in part on determining that the second mobility state associated with the device is included in the set of one or more candidate mobility states, and wherein it is determined that the user device is permitted to associate with the network based at least in part on determining that the one or more eligibility criteria are satisfied.

A system according to any of the example embodiments disclosed herein may further include a means for determining that the second mobility state is associated with a range of speeds having a lower bound that exceeds a threshold value; a means for determining a delay time period responsive to determining that the second mobility state is associated with the range of speeds having a lower bound that exceeds the threshold value; and a means for directing transmission of an indication of the delay time period to the user device, wherein the user device is not permitted to associate with the network until expiration of the delay time period.

According to any of the example embodiments disclosed herein, the user device may be a first user device. A system according to any of the example embodiments disclosed herein may further include a means for receiving user device route information indicative of a travel route associated with a second user device; a means for determining one or more network overload or congestion characteristics associated with the network; and a means for determining whether to permit the second user device to associate with the network based at least in part on the one or more network overload or congestion characteristics.

According to any of the example embodiments disclosed herein, it may be determined that the second user device is permitted to associate with the network. A system according to any of the example embodiments disclosed herein, may further include a means for enabling fast re- authentication of the second user device by the network; and a means for pre-authenticating the second user device with the network.

According to any of the example embodiments disclosed herein, the request may be an association request, and the at least a portion of the information included in the request may include an indication of a signal strength of the request. A system according to any of the example embodiments disclosed herein, may further include a means for determining that the signal strength of the request falls below the threshold signal strength for associating with the network, where it is determined that at least one eligibility criterion of the one or more eligibility criteria is not satisfied based at least in part on determining that the signal strength of the request falls below the threshold signal strength for associating with the network, and wherein it is determined that the user device is not permitted to associate with the network based at least in part on determining that the at least one eligibility criterion is not satisfied.

A system according to any of the example embodiments disclosed herein may further include a means for determining that the user device is permitted to attempt to associate with the network after expiration of a delay time period.

According to any of the example embodiments disclosed herein the user profile information may include a counter indicative of a number of unsuccessful attempts by the user device to authenticate with the network, and the eligibility information may include a threshold number of unsuccessful authentication attempts. A system according to any of the example embodiments disclosed herein may further include a means for determining that the counter exceeds the threshold number of unsuccessful authentication attempts, where it is determined that at least one eligibility criterion of the one or more eligibility criteria is not satisfied based at least in part on determining that the counter exceeds the threshold number of unsuccessful authentication attempts, and where it is determined that the user device is not permitted to associate with the network based at least in part on determining that the at least one eligibility criterion is not satisfied.

One or more computer-readable media according to one or more example embodiments of the disclosure may store computer-executable instructions that when executed by one or more processors may cause operations to be performed that include identifying a request from a user device to associate with a network; identifying information included in the request; identifying stored user profile information associated with the user device; identifying eligibility information and one or more eligibility criteria for associating with the network; determining whether the one or more eligibility criteria are satisfied based at in part on the i) eligibility information and 2) at least a portion of the user profile information or at least a portion of the information included in the request; and determining whether to permit the user device to associate with the network based at least in part on determining whether the one or more eligibility criteria are satisfied.

According to any of the example embodiments disclosed herein, the user profile information may include device mobility state information, and the eligibility information may include information indicative of a set of one or more candidate mobility states associated with the network. According to any of the example embodiments disclosed herein, one or more computer-readable media may store computer-executable instructions that when executed by one or more processors may cause further operations to be performed that include determining a mobility state associated with the user device based at least in part on the device mobility state information; and determining that the mobility state associated with the device is not included in the set of one or more candidate mobility states, wherein it is determined that at least one eligibility criterion of the one or more eligibility criteria is not satisfied based at least in part on determining that the mobility state associated with the device is not included in the set of one or more candidate mobility states, and wherein it is determined that the user device is not permitted to associate with the network based at least in part on determining that the at least one eligibility criterion is not satisfied.

One or more computer-readable media according to any of the example embodiments disclosed herein may store computer-executable instructions that when executed by one or more processors may cause further operations to be performed to determine the mobility state associated with the user device by determining a relative speed of the user device with respect to an access point (AP) of the network or a coverage area of the AP; identifying stored information indicative of a mapping between one or more ranges of speeds to one or more corresponding mobility states; determining that the relative speed of the user device falls within a particular range of speed; and identifying a particular mobility state corresponding to the particular range of speed based at least in part on the mapping, where the mobility state associated with the user device is the particular mobility state.

According to any of the example embodiments disclosed herein, the mobility state associated with the device may be a first mobility state. One or more computer-readable media according to any of the example embodiments disclosed may store computer-executable instructions that when executed by one or more processors may cause further operations to be performed that include determining a second mobility state associated with the user device based at least in part on the device mobility state information; and determining that the second mobility state associated with the device is included in the set of one or more candidate mobility states, where it is determined that the one or more eligibility criteria are satisfied based at least in part on determining that the second mobility state associated with the device is included in the set of one or more candidate mobility states, and wherein it is determined that the user device is permitted to associate with the network based at least in part on determining that the one or more eligibility criteria are satisfied.

One or more computer-readable media according to any of the example embodiments disclosed herein may store computer-executable instructions that when executed by one or more processors may cause further operations to be performed including determining that the second mobility state is associated with a range of speeds having a lower bound that exceeds a threshold value; determining a delay time period responsive to determining that the second mobility state is associated with the range of speeds having a lower bound that exceeds the threshold value; and directing transmission of an indication of the delay time period to the user device, where the user device is not permitted to associate with the network until expiration of the delay time period.

According to any of the example embodiments disclosed herein, the user device may be first user device. One or more computer-readable media according to any of the example embodiments disclosed herein may store computer-executable instructions that when executed by one or more processors may cause further operations to be performed including receiving user device route information indicative of a travel route associated with a second user device; determining one or more network overload or congestion characteristics associated with the network; and determining whether to permit the second user device to associate with the network based at least in part on the one or more network overload or congestion characteristics.

According to any of the example embodiments disclosed herein, it may be determined that the second user device is permitted to associate with the network. One or more computer- readable media according to any of the example embodiments disclosed herein may store computer-executable instructions that when executed by one or more processors may cause further operations to be performed including enabling fast re-authentication of the second user device by the network; and pre-authenticating the second user device with the network.

According to any of the example embodiments disclosed herein the request may be an association request, at least a portion of the information included in the request may include an indication of a signal strength of the request, and the eligibility information may include a threshold signal strength for associating with the network. One or more computer-readable media according to any of the example embodiments disclosed herein may store computer- executable instructions that when executed by one or more processors may cause further operations to be performed including determining that the signal strength of the request falls below the threshold signal strength for associating with the network, where it is determined that at least one eligibility criterion of the one or more eligibility criteria is not satisfied based at least in part on determining that the signal strength of the request falls below the threshold signal strength for associating with the network, and where it is determined that the user device is not permitted to associate with the network based at least in part on determining that the at least one eligibility criterion is not satisfied.

One or more computer-readable media according to any of the example embodiments disclosed herein may store computer-executable instructions that when executed by one or more processors may cause further operations to be performed including determining that the user device is permitted to attempt to associate with the network after expiration of a delay time period.

According to any of the example embodiments disclosed herein, the user profile information may include a counter indicative of a number of unsuccessful attempts by the user device to authenticate with the network, and the eligibility information may include a threshold number of unsuccessful authentication attempts. One or more computer-readable media according to any of the embodiments disclosed herein may store computer-executable instructions that when executed by one or more processors may cause further operations to be performed including determining that the counter exceeds the threshold number of unsuccessful authentication attempts, where it is determined that at least one eligibility criterion of the one or more eligibility criteria is not satisfied based at least in part on determining that the counter exceeds the threshold number of unsuccessful authentication attempts, and wherein it is determined that the user device is not permitted to associate with the network based at least in part on determining that the at least one eligibility criterion is not satisfied.

In accordance with one or more example embodiments of the disclosure, one or more computer-readable media may store computer-executable instructions that when executed by one or more processors may cause operations to be performed including determining that a user device is within a coverage area of a wireless local area network (WLAN); identifying device state information associated with the user device; identifying eligibility information and one or more eligibility criteria for attempting to authenticate with the WLAN; determining, based at least in part on at least a portion of the device state information and the eligibility information, whether the one or more eligibility criteria are satisfied; and determining whether to generate and transmit an association request message to an access point (AP) of the WLAN based at least in part on whether the one or more eligibility criteria are satisfied.

In accordance with one or more example embodiments of the disclosure, a method for controlling authentication aggressive may include determining, by a user device comprising one or more computer processors, that the user device is within a coverage area of a wireless local area network (WLAN); identifying, by the user devie, device state information associated with the user device; identifying, by the user device, eligibility information and one or more eligibility criteria for attempting to authenticate with the WLAN; determining, by the user device and based at least in part on at least a portion of the device state information and the eligibility information, whether the one or more eligibility criteria are satisfied; and determining, by the user device, whether to generate and transmit an association request message to an access point (AP) of the WLAN based at least in part on whether the one or more eligibility criteria are satisfied.

In accordance with one or more example embodiments of the disclosure, a user device may include at least one memory storing computer-executable instructions; and at least one processor configured to access the at least one memory and execute the computer-executable instructions to: determine that the user device is within a coverage area of a wireless local area network (WLAN); identify device state information associated with the user device; identify eligibility information and one or more eligibility criteria for attempting to authenticate with the WLAN; determine, based at least in part on at least a portion of the device state information and the eligibility information, whether the one or more eligibility criteria are satisfied; and determine whether to generate and transmit an association request message to an access point (AP) of the WLAN based at least in part on whether the one or more eligibility criteria are satisfied.

In accordance with one or more example embodiments of the disclosure, a system for controlling authentication aggressiveness may include a means for determining that a user device is within a coverage area of a wireless local area network (WLAN); a means for identifying device state information associated with the user device; a means for identifying eligibility information and one or more eligibility criteria for attempting to authenticate with the WLAN; a means for determining, based at least in part on at least a portion of the device state information and the eligibility information, whether the one or more eligibility criteria are satisfied; and a means for determining whether to generate and transmit an association request message to an access point (AP) of the WLAN based at least in part on whether the one or more eligibility criteria are satisfied.

According to any of the example embodiments disclosed herein, the eligibility information may include at least one of: i) information that identifies one or more candidate device mobility states permitted to authenticate with the AP or ii) information identifying one or more threshold values.

According to any of the example embodiments disclosed herein, the WLAN may be a Wi- Fi hotspot.

Claims

CLAIMS THAT WHICH IS CLAIMED IS:

1. A method for controlling authentication aggressiveness, comprising:

identifying, by a network association eligibility determination system comprising one or more network node devices comprising one or more computer processors, a request from a user device to associate with a network;

identifying, by the network association eligibility determination system, information included in the request;

identifying, by the network association eligibility determination system, stored user profile information associated with the user device;

identifying, by the network association eligibility determination system, eligibility information and one or more eligibility criteria for associating with the network;

determining, by the network association eligibility determination system, whether the one or more eligibility criteria are satisfied based at in part on the i) eligibility information and 2) at least a portion of the user profile information or at least a portion of the information included in the request; and

determining, by the network association eligibility determination system, whether to permit the user device to associate with the network based at least in part on determining whether the one or more eligibility criteria are satisfied.

2. The method of claim 1, wherein the user profile information comprises device mobility state information, and wherein the eligibility information comprises information indicative of a set of one or more candidate mobility states associated with the network, the method further comprising:

determining, by the network association eligibility determination system, a mobility state associated with the user device based at least in part on the device mobility state information; and

determining, by the network association eligibility determination system, that the mobility state associated with the device is not included in the set of one or more candidate mobility states,

wherein it is determined that at least one eligibility criterion of the one or more eligibility criteria is not satisfied based at least in part on determining that the mobility state associated with the device is not included in the set of one or more candidate mobility states, and wherein it is determined that the user device is not permitted to associate with the network based at least in part on determining that the at least one eligibility criterion is not satisfied.

3. The method of claim 2, wherein determining the mobility state associated with the user device comprises:

determining, by the network association eligibility determination system, a relative speed of the user device with respect to an access point (AP) of the network or a coverage area of the AP;

identifying, by the network association eligibility determination system, stored information indicative of a mapping between one or more ranges of speeds to one or more corresponding mobility states;

determining, by the network association eligibility determination system, that the relative speed of the user device falls within a particular range of speed; and

identifying, by the network association eligibility determination system, a particular mobility state corresponding to the particular range of speed based at least in part on the mapping,

wherein the mobility state associated with the user device is the particular mobility state.

4. The method of claim 2, wherein the mobility state associated with the device is a first mobility state, the method further comprising:

determining, by the network association eligibility determination system, a second mobility state associated with the user device based at least in part on the device mobility state information; and

determining, by the network association eligibility determination system, that the second mobility state associated with the device is included in the set of one or more candidate mobility states,

wherein it is determined that the one or more eligibility criteria are satisfied based at least in part on determining that the second mobility state associated with the device is included in the set of one or more candidate mobility states, and

wherein it is determined that the user device is permitted to associate with the network based at least in part on determining that the one or more eligibility criteria are satisfied.

5. The method of claim 4, further comprising: determining, by the network association eligibility determination system, that the second mobility state is associated with a range of speeds having a lower bound that exceeds a threshold value;

determining, by the network association eligibility determination system, a delay time period responsive to determining that the second mobility state is associated with the range of speeds having a lower bound that exceeds the threshold value; and

directing, by the network association eligibility determination system, transmission of an indication of the delay time period to the user device,

wherein the user device is not permitted to associate with the network until expiration of the delay time period.

6. The method of any of claims 1-5, wherein the user device is first user device, the method further comprising:

receiving, the network association eligibility determination system, user device route information indicative of a travel route associated with a second user device;

determining, by the network association eligibility determination system, one or more network overload or congestion characteristics associated with the network; and

determining, by the network association eligibility determination system, whether to permit the second user device to associate with the network based at least in part on the one or more network overload or congestion characteristics.

7. The method of claim 6, wherein it is determined that the second user device is permitted to associate with the network, the method further comprising:

enabling, by the network association eligibility determination system, fast re- authentication of the second user device by the network; and

pre-authenticating, by the network association eligibility determination system, the second user device with the network.

8. The method of claim 7, wherein fast re-authentication of the second user device comprises utilizing a cached key to authenticate the second user device, and wherein the key is cached at the network based at least in part on the pre-authenticating of the second user device with the network.

9. The method of any of claims 1-5, wherein the request is an association request, wherein the at least a portion of the information included in the request comprises an indication of a signal strength of the request, and wherein the eligibility information comprises a threshold signal strength for associating with the network, the method further comprising:

determining, by the network association eligibility determination system, that the signal strength of the request falls below the threshold signal strength for associating with the network, and

wherein it is determined that at least one eligibility criterion of the one or more eligibility criteria is not satisfied based at least in part on determining that the signal strength of the request falls below the threshold signal strength for associating with the network, and

wherein it is determined that the user device is not permitted to associate with the network based at least in part on determining that the at least one eligibility criterion is not satisfied.

10. The method of claim 9, further comprising:

determining, by the network association eligibility determination system, that the user device is permitted to attempt to associate with the network after expiration of a delay time period.

1 1. The method of any of claims 1-5, wherein the user profile information comprises a counter indicative of a number of unsuccessful attempts by the user device to authenticate with the network, and wherein the eligibility information comprises a threshold number of unsuccessful authentication attempts, the method further comprising:

determining, by the network association eligibility determination system, that the counter exceeds the threshold number of unsuccessful authentication attempts,

wherein it is determined that at least one eligibility criterion of the one or more eligibility criteria is not satisfied based at least in part on determining that the counter exceeds the threshold number of unsuccessful authentication attempts, and

12. A system for controlling authentication aggressiveness, comprising:

at least one memory storing computer-executable instructions; and at least one processor communicatively coupled to the at least one memory, wherein the at least one processor access the at least one memory and executes the computer-executable instructions to:

identify a request from a user device to associate with a network;

identify information included in the request;

identify stored user profile information associated with the user device;

identify eligibility information and one or more eligibility criteria for associating with the network;

determine whether the one or more eligibility criteria are satisfied based at in part on the i) eligibility information and 2) at least a portion of the user profile information or at least a portion of the information included in the request; and

determine whether to permit the user device to associate with the network based at least in part on determining whether the one or more eligibility criteria are satisfied.

13. The system of claim 12, wherein the user profile information comprises device mobility state information, wherein the eligibility information comprises information indicative of a set of one or more candidate mobility states associated with the network, and wherein the at least one processor is further configured to execute the computer-executable instructions to:

determine a mobility state associated with the user device based at least in part on the device mobility state information; and

determine that the mobility state associated with the device is not included in the set of one or more candidate mobility states,

wherein it is determined that at least one eligibility criterion of the one or more eligibility criteria is not satisfied based at least in part on determining that the mobility state associated with the device is not included in the set of one or more candidate mobility states, and

14. The system of claim 13, wherein the mobility state associated with the device is a first mobility state, and wherein the at least one processor is further configured to execute the computer-executable instructions to:

determine a second mobility state associated with the user device based at least in part on the device mobility state information; and determine that the second mobility state associated with the device is included in the set of one or more candidate mobility states,

15. The system of any of claims 12-14, wherein the user device is first user device, and wherein the at least one processor is further configured to execute the computer-executable instructions to:

receive user device route information indicative of a travel route associated with a second user device;

determine one or more network overload or congestion characteristics associated with the network; and

determine whether to permit the second user device to associate with the network based at least in part on the one or more network overload or congestion characteristics.

16. The system of any of claims 12-14, wherein the request is an association request, wherein the at least a portion of the information included in the request comprises an indication of a signal strength of the request, and wherein the at least one processor is further configured to execute the computer-executable instructions to:

determine that the signal strength of the request falls below the threshold signal strength for associating with the network, and

17. The system of claim 16, and wherein the at least one processor is further configured to execute the computer-executable instructions to: determine that the user device is permitted to attempt to associate with the network after expiration of a delay time period.

18. The system of any of claims 12-14, wherein the user profile information comprises a counter indicative of a number of unsuccessful attempts by the user device to authenticate with the network, and wherein the eligibility information comprises a threshold number of unsuccessful authentication attempts, and wherein the at least one processor is further configured to execute the computer-executable instructions to:

determine that the counter exceeds the threshold number of unsuccessful authentication attempts,

19. A system for controlling authentication aggressiveness, comprising:

a means for identifying a request from a user device to associate with a network;

a means for identifying information included in the request;

a means for identifying stored user profile information associated with the user device; a means for identifying eligibility information and one or more eligibility criteria for associating with the network;

a means for determining whether the one or more eligibility criteria are satisfied based at in part on the i) eligibility information and 2) at least a portion of the user profile information or at least a portion of the information included in the request; and

a means for determining whether to permit the user device to associate with the network based at least in part on determining whether the one or more eligibility criteria are satisfied.

20. One or more computer-readable media storing computer-executable instructions that when executed by one or more processors cause operations to be performed comprising:

identifying a request from a user device to associate with a network;

identifying information included in the request;

identifying stored user profile information associated with the user device; identifying eligibility information and one or more eligibility criteria for associating with the network;

determining whether the one or more eligibility criteria are satisfied based at in part on the i) eligibility information and 2) at least a portion of the user profile information or at least a portion of the information included in the request; and

determining whether to permit the user device to associate with the network based at least in part on determining whether the one or more eligibility criteria are satisfied.

21. One or more computer-readable media storing computer-executable instructions that when executed by one or more processors cause operations to be performed comprising:

determining that a user device is within a coverage area of a wireless local area network (WLAN);

identifying device state information associated with the user device;

identifying eligibility information and one or more eligibility criteria for attempting to authenticate with the WLAN;

determining, based at least in part on at least a portion of the device state information and the eligibility information, whether the one or more eligibility criteria are satisfied; and

determining whether to generate and transmit an association request message to an access point (AP) of the WLAN based at least in part on whether the one or more eligibility criteria are satisfied.

22. The one or more computer-readable media of claim 21, wherein the eligibility information comprises at least one of: i) information that identifies one or more candidate device mobility states permitted to authenticate with the AP or ii) information identifying one or more threshold values.

23. A method for controlling authentication aggressiveness, comprising:

determining, by a user device comprising one or more computer processors, that the user device is within a coverage area of a wireless local area network (WLAN);

identifying, by the user devie, device state information associated with the user device; identifying, by the user device, eligibility information and one or more eligibility criteria for attempting to authenticate with the WLAN;

determining, by the user device and based at least in part on at least a portion of the device state information and the eligibility information, whether the one or more eligibility criteria are satisfied; and determining, by the user device, whether to generate and transmit an association request message to an access point (AP) of the WLAN based at least in part on whether the one or more eligibility criteria are satisfied.

24. A user device, comprising:

at least one memory storing computer-executable instructions; and

at least one processor configured to access the at least one memory and execute the computer-executable instructions to:

determine that the user device is within a coverage area of a wireless local area network (WLAN);

identify device state information associated with the user device;

identify eligibility information and one or more eligibility criteria for attempting to authenticate with the WLAN;

determine, based at least in part on at least a portion of the device state information and the eligibility information, whether the one or more eligibility criteria are satisfied; and determine whether to generate and transmit an association request message to an access point (AP) of the WLAN based at least in part on whether the one or more eligibility criteria are satisfied.

25. A system for controlling authentication aggressiveness, comprising:

a means for determining that a user device is within a coverage area of a wireless local area network (WLAN);

a means for identifying device state information associated with the user device;

a means for identifying eligibility information and one or more eligibility criteria for attempting to authenticate with the WLAN;

a means for determining, based at least in part on at least a portion of the device state information and the eligibility information, whether the one or more eligibility criteria are satisfied; and

a means for determining whether to generate and transmit an association request message to an access point (AP) of the WLAN based at least in part on whether the one or more eligibility criteria are satisfied.