Patent Description:
Most wireless devices (also referred to herein as "user equipments", or "UEs") support multiple access technologies. For example, smartphones typically support cellular, e.g., <NUM>rd Generation Partnership Project (3GPP), <NUM>rd Generation (<NUM>), and <NUM>th Generation (<NUM>), etc. as well as other technologies such as Wi-Fi (IEEE <NUM>), Bluetooth, etc. Other device types, such as Internet of Things (IoT) devices, may support cellular (e.g., NB-IoT) and/or other technologies such as Wi-Fi, Bluetooth, etc. Consequently, the device may be operative to select which wireless access technology (or technologies) to attach to from the multiple wireless technologies and/or wireless network providers available at a specific location and time.

3GPP LTE provides an optional standard for access network discovery and selection function (ANDSF) which is expected to be included in the policy control function (PCF) in the standards for <NUM>. The network features of this standard include a defined control plane functional element called an ANDSF server which is accessible over the Gi interface. The defined reference point in the 3GPP standard is S14. A defined ANDSF client function is used by a device to access the ANDSF server. This client function may be either provided natively as an integrated component of the device's operating system (OS) and/or as a software client which is on the device by a service provider, employer's IT department, or by the user. Enforcement of ANDSF-based policies may take into account external data associated with the device's operating environment, such as, for example: location, network identifiers (e.g., SSID, etc.), connectivity conditions, time of day, applications, etc..

<CIT> describes systems, methods, and apparatuses for identifying, based at least in part on an access network discovery and selection function (ANDSF) quality of service (QoS) policy, a preferred access point (AP) of a wireless local area network (WLAN). In some embodiments, the ANDSF QoS policy may be compared to one or more of an air-interface congestion parameter of the AP, and/or a backhaul congestion parameter of the AP.

<CIT> describes a method, network node, and non-transitory machine-readable storage medium including one or more of the following: identifying, by an ANDSF server, an anticipated location for a user equipment device (UE) in communication with the ANDSF sever via an S14 session established over a first access network; generating, by the ANDSF server, a policy based on the anticipated location for the UE, wherein the policy includes an identification of an access point for use by the UE to access a second access network other than the first access network; and transmitting, by the ANDSF server, the policy including the identification of the access point to the UE via the S14 session over the first access network.

<CIT> is directed to a system and method for self-scaling generic policy tracking. The system can include a policy key on a client for scanning the client for at least one configuration, assessing a policy compliance based on the configuration, and reporting at least one policy state to a policy server. The system can also include a policy server for receiving the at least one policy state from the policy key, and configuring network access to the client based on the at least one policy state. The policy key can report at least one policy state on a periodic communication cycle that can be scaled according to system load for increasing system capacity.

<NPL>, is directed to Zenprise's Android Enterprise Application Store.

The embodiments of the disclosure will be understood and appreciated more fully from the following detailed description, taken in conjunction with the drawings in which:.

The examples of <FIG> and <FIG> do not fall under the scope of the appended claims but are considered as useful for understanding the invention.

An enterprise network includes: at least one wireless access point operative to enable a wireless device to connect to the enterprise network, networked resources to be accessed by the wireless device, and a network selection server implemented on at least one computing device and operative to: authenticate credentials provided by the wireless device when connecting to the enterprise network via the at least one wireless access point, and provide network access selection policies to the wireless device, where the network access selection policies at least determine access by the wireless device to network resources while said wireless device is connected to said enterprise network.

A wireless device includes: processing circuitry, at least one input/output (I/O) module operative to connect the wireless device to at least one mobile service provider network and at least one enterprise network, and a network selection client application operative to be executed by the processing circuitry to employ an enterprise-centric network access selection policy when the wireless device accesses the at least one enterprise network.

Today, most wireless devices support multiple access technologies. For example, smartphones typically support cellular (e.g., 3GPP <NUM> & <NUM>, etc.) as well as other technologies such as Wi-Fi (<NUM>), Bluetooth, etc. Other types of wireless devices, such as Internet-of-Things (IoT) devices, may support cellular (e.g., NB-IoT) plus other technologies such as Wi-Fi, Bluetooth, etc. A wireless device may therefore typically select from among multiple wireless access technologies when attaching to access networks that may be available at a given specific location and time. Ideally, the device would select the best available technology and/or service provider. However, there are many factors that influence a device's network selection, e.g., device applications, network load or conditions, cost considerations, user profile, etc..

In practice today, on a cellular network, the service provider that issues the device identifier (e.g., subscriber identity module - "SIM") is effectively in control of setting the policy with regard to how the device determines which access technology to use, such as, for example, what radio frequency (RF) conditions or signal thresholds may be used, the present location of the device, the network identifiers of the serving and candidate network, the application, etc. Accordingly, even when attaching to a technology not provided by the service provider, e.g., a third party Wi-Fi network, the device's settings, typically set by the service provider, dictate the conditions under which the device may handover from cellular to Wi-Fi (or vice-versa) as well as which Wi-Fi networks to prioritize, and according to what criteria. As a further complication, each device manufacturer may have different implementations for the default conditions for inter-technology handovers.

For example, a business or enterprise may provide wireless service (e.g., Wi-Fi and/or one or more other access technologies) for its employees and guests. But service from one or more cellular technologies may also be present on premises; radio frequency (RF) signals provided by one or more service providers (SPs) may leak into the business location. As a result, devices in this nominally private realm have the option of choosing between wireless services provided by the enterprise wireless network or the service provider network. As a consequence, some users (whose devices connect to the SP network) may not have access to certain applications and/or other services which the private business provides as part of its wireless service. It will be appreciated that in such circumstances, it may be preferable for the enterprise to dictate network selection policy for wireless devices for devices brought into its premises. The enterprise would be able to set enterprise-centric network selection policies, i.e., policies which are appropriate to the local (enterprise) network conditions. Using network selection policies provided by the enterprise would enable devices to connect to the appropriate network for enterprise applications, thereby providing a smoother and more rewarding experience when on enterprise premises.

Furthermore, many enterprises allow employees to bring their own mobile devices (likely from multiple device vendors and using more than one service provider) to work, often for use as their "work device. " It will be appreciated that it would be preferable that all such work devices connect in the same way, to the same network, thereby enabling the enterprise to more securely control and/or grant access to enterprise applications on the selected network(s), providing an added level of uniformity and/or manageability to the enterprise's network security policies for protecting critical information. However, if the service provider or manufacturer default policies control network selection, it may not be possible to implement an enterprise-centric network selection policy.

It will be appreciated that ANDSF may not be designed to provide an enterprise-centric network selection policy. For example, the enterprise's employees and guests may be served by multiple service providers, where some of the SPs may choose to not even deploy ANDSF, and those that do deploy ANDSF may use different, non-uniform implementations. In addition, SP ANDSF policies are typically designed for their entire service area, and thus may not be aware of or crafted in sufficient detail for a specific enterprise or location. The SP-centric orientation of typically ANDSF implementations may therefore effectively prevent an "as is" use of ANDSF for enterprise-centric policies.

However, In accordance with embodiments described herein, ANDSF and/or similar functionality may provide a basis for implementing an enterprise-centric network selection policy. Reference is now made to <FIG> which is a partly pictorial, partly block illustration of an enterprise network access selection system <NUM>, constructed and operative in accordance with embodiments described herein. System <NUM> comprises enterprise network <NUM>, service provider network <NUM> and wireless device <NUM> (hereinafter also referred to as "device <NUM>"). It will be appreciated that system <NUM> may provide connectivity for multiple instances of device <NUM>; in the interests of clarity, only one wireless device <NUM> is shown in <FIG>.

Enterprise network <NUM> comprises enterprise network selection server <NUM> (hereinafter also referred to as "server <NUM>") and wireless access points (APs) <NUM>. Wireless APs <NUM> may be of any suitable wireless technology for accessing enterprise network <NUM> from wireless device <NUM>, such as, but not limited to, the WiFi Certified Passpoint standard for public-access WiFi that enables seamless roaming among WiFi networks and between WiFi and cellular networks. It will be appreciated that enterprise network <NUM> also comprises other devices such as application servers, personal computers, printers, physical access devices, etc. that may be connected either wirelessly via wireless APs <NUM> and/or via wired connections.

Enterprise network selection server <NUM> provides control plane functionality to enterprise network <NUM>. It will be appreciated that server <NUM> may not necessarily be located physically within the premises of the enterprise associated with enterprise network. Server <NUM> may also be implemented remotely and connected to enterprise network via a communications network (e.g., the Internet) as part of a virtual private network (VPN) associated with enterprise network <NUM>. Server <NUM> may also be implemented remotely as a cloud-based service.

Enterprise network selection server <NUM> comprises enterprise access network authentication application <NUM>. Enterprise access network authentication application <NUM> is an application module that provides authentication onto enterprise network <NUM> (e.g., via HotSpot <NUM> or similar means on wireless APs <NUM>). Enterprise network selection server <NUM> also comprises network selection server authentication application <NUM> which is an application module that provides authentication for the network selection functionality provided by server <NUM>. In accordance with embodiments described herein, enterprise access network authentication application <NUM> and/or network selection server authentication application <NUM> may be implemented as integral components of server <NUM>. However, it will be appreciated that enterprise access network authentication application <NUM> and/or network selection server authentication application <NUM> may alternatively be implemented as remote components located elsewhere in enterprise network <NUM> and accessed remotely by server <NUM> as needed. It will similarly be appreciated that enterprise access network authentication application <NUM> and/or network selection server authentication application <NUM> may implemented as cloud-based services.

As will be described in greater detail herein below, in operation, enterprise network selection server <NUM> may access a multiplicity of authentication services, including, for example:.

Server <NUM> may use these authentication services to obtain additional information about wireless device <NUM> and/or its associated user. Such additional information may include, for example, but not limited to:.

Wireless device <NUM> may comprise network selection client <NUM>. Network selection client <NUM> may be a native component of the operating system (OS) on device <NUM>, such as, but not limited to, a native implementation of an ANDSF client by the manufacturer or distributor of device <NUM>. It will be appreciated, however, that it may be necessary to add extensions to native ANDSF client in order for it to provide support for the embodiments described herein. Alternatively, network selection client <NUM> may be a non-native client application provided by Enterprise network selection server <NUM> during a previous connection between device <NUM> and enterprise network <NUM>.

Enterprise network selection server <NUM> may be operative to download network selection client <NUM> to wireless device <NUM> if network selection client <NUM> is not present on wireless device <NUM>. Similarly, server <NUM> may be operative to download a device profile for network selection client <NUM> if one is not already present or if an existing device profile is outdated. The device profile may specify enterprise-specific policies to apply when device <NUM> connects to enterprise network <NUM>. In accordance to some embodiments, the device profile may also be applied when connecting to a larger shared group or entity to which enterprise network <NUM> belongs. For example, enterprise network <NUM> may be associated with a branch of a retail chain; the device profile may be configured for use for other branches of the retail chain. Similarly, enterprise network <NUM> may be associated with a retail chain that shares a loyalty card with other retail chains; the device profile may be configured for use when visiting the other retail chains as well. In such a case, server <NUM> may be, for example, implemented in a cloud network in order to render it accessible from multiple locations.

The policies in the device profile may include references to identifiers and/or data related to enterprise network <NUM>, (e.g., network identifiers, network state, etc.), as well as, or instead of, data directly obtainable from wireless device <NUM> (e.g., time, location, motion, RF signal strength, etc.). Then, while connected to enterprise network <NUM>, wireless device <NUM> would then effectively follow enterprise-centric policies according to a local (i.e., on wireless device <NUM>) device profile.

Reference is now made to <FIG> which is a schematic illustration of an exemplary enterprise network selection server <NUM>, configured and operative in accordance with embodiments described herein to at least facilitate the implementation of enterprise-centric network selection policies in wireless devices <NUM> (<FIG>). Server <NUM> may be instantiated using any suitable computing device(s) that may support the embodiments as described herein. For example, server <NUM> may implemented using hardware, software, and/or firmware on a multi-purpose personal computer, computer tablet, or smartphone. Server <NUM> may also be implemented on a communications router or switch.

Server <NUM> comprises processing circuitry <NUM>, input/output (I/O) module <NUM>, enterprise access network authentication application <NUM>, network selection server authentication application <NUM>, and policy database <NUM>. Enterprise access network authentication application <NUM>, network selection server authentication application <NUM>, and policy database <NUM> may be implemented using any suitable memory for storing software and/or operational data, such as an optical storage medium, a magnetic storage medium, an electronic storage medium, and/or a combination thereof. It will be appreciated that the memory, or parts thereof, may be implemented as a physical component of server <NUM> and/or as a physical component of one or more secondary devices in communication with server <NUM>. It will also be appreciated that in the interests of clarity, while server <NUM> may comprise additional components and/or functionality, such additional components and/or functionality are not depicted in <FIG> and/or described herein. It will also be appreciated that the depiction of applications <NUM> and <NUM> as integral components of server <NUM> may be exemplary, in actual implementation, authentication functionality may be provided by one or more other servers.

Processing circuitry <NUM> may be operative to execute instructions stored in the memory. For example, processor <NUM> may be operative to execute enterprise access network authentication application <NUM> and/or network selection server authentication application <NUM>. It will be appreciated that processing circuitry <NUM> may be implemented as a central processing unit (CPU), and/or one or more other integrated circuits such as application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), full-custom integrated circuits, etc., or a combination of such integrated circuits. It will similarly be appreciated that server <NUM> may comprise more than one instance of processing circuitry <NUM>. For example, one such instance of processing circuitry <NUM> may be a special purpose processor operative to execute enterprise access network authentication application <NUM> and/or network selection server authentication application <NUM> to perform some, or all, of the functionality of server <NUM> as discussed with respect to <FIG>.

I/O module <NUM> may be any suitable software or hardware component such as a universal serial bus (USB) port, disk reader, modem or transceiver that may be operative to use protocols such as are known in the art to communicate either directly, or indirectly, with other elements of system <NUM> of <FIG>, such as, for example, wireless access points <NUM>, service provider network <NUM>, third-party identity provider <NUM>, and/or wireless device <NUM>. For example, a mobility management entity (MME), a gateway, etc. over a communications network such as, for example, I/O module <NUM> may be operative to use some or all of Hotspot <NUM>, Bluetooth, a backbone network, the Internet, etc. to connect to the other elements of system <NUM>. It will be appreciated that in operation I/O module <NUM> may be implemented as a multiplicity of modules, where different modules may be operative to use different communication technologies.

It will also be appreciated that the embodiments described herein may also support configurations where some or all of the communications between I/O module <NUM> and elements of system <NUM> are brokered by a local server in enterprise network <NUM>; at least some of the functionality attributed herein to server <NUM> may be also performed on such a local server. It will similarly be appreciated that since I/O module <NUM> is operative to communicate with the other elements of system <NUM>, the physical location of server <NUM> may not necessarily be within close proximity of any specific element(s) of system <NUM>.

Enterprise access network authentication application <NUM> and/or network selection server authentication application <NUM> may be applications implemented in hardware, firmware, or software that may be executed by processing circuitry <NUM> to at least provide the functionality of server <NUM> as described herein to enable enterprise-centric network selection by wireless devices <NUM>.

Reference is now made to <FIG> which is a schematic illustration of an exemplary wireless device <NUM> from the system of <FIG>, configured and operative in accordance with embodiments described herein to enable usage of enterprise-centric network selection policies when accessing enterprise network <NUM> (<FIG>). Device <NUM> may be instantiated using any suitable computing device(s) that may support the embodiments as described herein. For example, device <NUM> may implemented using hardware, software, and/or firmware on a multi-purpose personal computer, computer tablet, or smartphone. Device <NUM> may also be implemented on a dedicated Internet of Things (IoT) device.

Device <NUM> comprises processing circuitry <NUM>, input/output (I/O) module <NUM>, and network selection client <NUM>. Network selection client <NUM> may comprise device profile <NUM>. Network selection client <NUM> may be implemented using any suitable memory for storing software and/or operational data, such as an optical storage medium, a magnetic storage medium, an electronic storage medium, and/or a combination thereof. It will be appreciated that the memory, or parts thereof, may be implemented as a physical component of device <NUM> and/or as a physical component of one or more secondary devices in communication with device <NUM>. It will be appreciated that in the interests of clarity, while device <NUM> may comprise additional components and/or functionality, such additional components and/or functionality are not depicted in <FIG> and/or described herein.

Processing circuitry <NUM> may be operative to execute instructions stored in the memory. For example, processor <NUM> may be operative to execute network selection client <NUM>. It will be appreciated that processing circuitry <NUM> may be implemented as a central processing unit (CPU), and/or one or more other integrated circuits such as application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), full-custom integrated circuits, etc., or a combination of such integrated circuits. It will similarly be appreciated that device <NUM> may comprise more than one instance of processing circuitry <NUM>. For example, one such instance of processing circuitry <NUM> may be a special purpose processor operative to execute network selection client <NUM> to provide an enterprise-centric policy for accessing enterprise network <NUM> as discussed with respect to <FIG>.

I/O module <NUM> may be any suitable software or hardware component such as a universal serial bus (USB) port, disk reader, modem or transceiver that may be operative to use protocols such as are known in the art to communicate either directly, or indirectly, with at least enterprise network <NUM> and/or service provider network <NUM>. For example, I/O module <NUM> may be operative to use some or all of Hotspot <NUM>, Bluetooth, a backbone network, the Internet, etc. to access elements of enterprise network <NUM> via wireless APs <NUM>, and/or to access service provider network <NUM>. It will be appreciated that in operation I/O module <NUM> may be implemented as a multiplicity of modules, where different modules may be operative to use different communication technologies.

It will also be appreciated that the embodiments described herein may also support configurations where some or all of the communications between I/O module <NUM> and elements of system <NUM> are brokered by a local server in enterprise network <NUM>; at least some of the functionality attributed herein to device <NUM> may be also performed on such a local server.

In accordance with some embodiments described herein, network selection client <NUM> may be implemented as a native OS component (such as, for example, an ANDSF client) on device <NUM> that may be executed by processing circuitry <NUM> to use enterprise-centric network selection policies when accessing enterprise network <NUM>. In accordance with other embodiments described herein, network selection client <NUM> may be a non-native application implemented in hardware, firmware, or software that that may be executed by processing circuitry <NUM> to use enterprise-centric network selection policies when accessing enterprise network <NUM>.

It will be appreciated that when first accessing enterprise network <NUM>, device <NUM> may not have an installed network selection client <NUM>. If network selection client <NUM> is not already present in device <NUM> - either natively (e.g., as part of the OS) or as a non-native application - device <NUM> may not be configured to use enterprise-centric network selection policies to access enterprise network <NUM> until network selection client <NUM> is installed in device <NUM>. An SP, for example, may install an ANDSF client in devices supporting 3GPP functionality to function as network selection client <NUM>. It will be appreciated that using an SP provided ANDSF client may be contingent on prior agreement with the SP's ANDSF client provider to customize the client to support enterprise access policies.

When device <NUM> lacks a native OS version of network selection client <NUM>, there are a number of alternatives for installation of a non-native version. For example, for employees of the enterprise associated with enterprise network <NUM>, a non-native version of network selection client <NUM> may be installed by "traditional means", e.g., software installation by the enterprise's information technology (IT) department, and/or by the user themselves, etc. It will be appreciated that network selection client may be integrated/embedded into other applications, such as, for example, an enterprise VPN client (such as Cisco AnyConnect) or a mobile device management (MDM) product.

For non-employees (e.g., guests and customers of the enterprise), there may be several options for downloading network selection client application <NUM> to device <NUM>. For example, a QR code may be provided (e.g., at the entrance of the enterprise/business/venue, or via text message, email, instant messaging, etc.) that may be used to trigger the installation of an appropriate software client (e.g., appropriate to the device vendor, device model, device OS, OS release, etc.).

Network selection client application <NUM> may also be bundled as part of another application that may provide additional functionality and/or purpose for the enterprise or even a group of enterprises. Such an application may be downloaded from many sources, including the enterprise's website, etc. Such an application may be targeted at customers of the enterprise, for example providing additional services such as store directory, location-based functions (which may leverage the enterprise's wireless network and/or any location-based beacons, functions and/or services).

Reference is now made to <FIG> which is a high-level flow chart of an exemplary authentication process <NUM> to be performed by enterprise network selection server (<FIG>), constructed and operative in accordance with embodiments described herein. Server <NUM> may receive (step <NUM>) an attach request from wireless device <NUM> for enterprise network <NUM> using a current network selection policy for device <NUM>, and in response provide (step <NUM>) an IP address to the requesting device. It will be appreciated that the presentation of steps <NUM> and <NUM> as being performed by server <NUM> may be exemplary; in other embodiments, these steps may be performed by other elements of enterprise network <NUM>, for example wireless APs <NUM>.

Server <NUM> may receive (step <NUM>) an authentication request from device <NUM> for enterprise network <NUM>. Server <NUM> may invoke enterprise access network authentication application <NUM> (<FIG>) to determine whether or not the authentication request was successful. The authentication request may comprise a credential that is significant to the enterprise (e.g., certificate), or a credential from an identity provider that the enterprise trusts, such as, for example, service provider <NUM> (<FIG>) and/or third party identity provider <NUM> (<FIG>). A representative list of examples of such credentials may include: onetime codes (e.g., as provided by an SMS text message), username/password combinations, media access control transparent auto login (MAC-TAL), generic bootstrapping architecture (GBA), secure remote password protocol (SPR), external databases (e.g., home subscribe server (HSS), lightweight directory access protocol (LDAP)), X509 certificates, etc. When authenticating with a device subscriber identity module (SIM) (e.g., from service provider network <NUM>), extensible authentication protocol - authentication and key agreement (EAP-AKA) authentication may also be used.

If the request was not authenticated (step <NUM>), access is refused to device <NUM> and process control may return the start of process <NUM>.

If the request was authenticated (step <NUM>) server <NUM> may invoke network selection server authentication application <NUM> to determine if network selection client application <NUM> is enabled on device <NUM> (step <NUM>). For example, application <NUM> may request a confirmation response from network selection client application <NUM> on device <NUM>. If a response is not received, it may be assumed that there is no client application on the device.

Network selection server authentication application <NUM> may download (step <NUM>) a network selection client for installation to device <NUM> if necessary. It will be appreciated that step <NUM> may include a dialogue with device <NUM> requesting additional information regarding the device's configuration (i.e., in order provide a compatible client application) and/or requests for user confirmation of the download and installation.

Network selection server authentication application <NUM> may also check whether or not the policies on the device are up-to-date. If the device policies are not up-to-date (step <NUM>), Network selection server authentication application <NUM> may push (step <NUM>) an updated policy to device <NUM>. It will be appreciated that application <NUM> may access default, individual, and/or group policies from policy database <NUM> (<FIG>) to perform step <NUM>.

It will be appreciated that a user's policies may be refined based upon measurements of the user's and/or the network's prior behavior. In accordance with some embodiments described herein, server <NUM> may monitor (step <NUM>) network access behavior by device <NUM>. For example, measurement data may be collected via a number of techniques, including: from data gathered in the wireless APs <NUM>; from network elements or functions (e.g., routers, gateways, etc.); from explicit measurement agents (e.g., deep packet inspection); from end point or application servers; and/or from applications or software shims in device <NUM>. It will be appreciated that depending on the implementation of process <NUM>, step <NUM> may include use of all such data gathering means, a subset of such means, or even a statistical subset or sample of such means.

It will be appreciated that using the data gathered in step <NUM>, relevant trends and correlations may be observed, as well as inferences may be made regarding a correct response to certain situations. From these, inferences can be drawn for improving or optimizing the response to future events and situations. Algorithms such as dynamic feedback and/or machine learning algorithms may then be used to adjust (step <NUM>) policies per analysis of the observed behavior. Policies may also be modified proactively, to address known events or anticipated changes in the enterprise's environment, network conditions, etc..

Reference is now made to <FIG> which is a high-level flowchart of an exemplary authentication and network selection process <NUM> to be performed by wireless device <NUM> (<FIG>) as already configured with network selection client application <NUM>.

Device <NUM> may attach (step <NUM>) to enterprise network <NUM> via I/O module <NUM> and receive (step <NUM>) an IP address after attaching. Device <NUM> may then invoke network selection client application <NUM> to authenticate (step <NUM>) to server <NUM> in accordance with the policies provided by device profile <NUM>.

If, per an exchange with server <NUM>, the policy in device profile <NUM> is not up-to-date (step <NUM>), network selection client application <NUM> may pull (step <NUM>) an updated policy from server <NUM>.

While still connected to enterprise network <NUM>, device <NUM> may access (step <NUM>) elements of enterprise network <NUM> according to the current policy in device profile <NUM>.

Reference is now made to <FIG> which is a partly pictorial, partly block illustration of exemplary enterprise network access selection system <NUM>, constructed and operative in accordance with embodiments described herein. System <NUM> may comprise several components that may be generally similar to like-numbered components of system <NUM> (<FIG>). For example, network selection server <NUM>, UE <NUM> and network selection client <NUM> may be generally similar to enterprise network selection server <NUM>, wireless device <NUM> and network selection client <NUM> as depicted in <FIG>. System <NUM> may also comprise network authentication server (NAS) <NUM>, enterprise wireless infrastructure <NUM>, home subscribe server (HSS) <NUM>, ID broker <NUM>, terms and conditions (T&C) server <NUM>, application server / resource provider (AS/RP) <NUM>, and resource (RS) <NUM>. Enterprise wireless infrastructure <NUM> comprises one or more APs generally similar to APs <NUM> (<FIG>) as well as one or more mobile cell antennae from a least one mobile service provider. It will be appreciated that the functionality attributed herein to NAS <NUM>, HSS <NUM>, ID broker <NUM>, T&C server <NUM>, AS/RP <NUM>, and/or RS <NUM> may be implemented on one or more computing devices comprising processing circuitry and memory that may be suitable for providing such functionality. In accordance with embodiments described herein, ID broker <NUM> may be implemented using identity provider openID gateway (IdP GW OP).

Reference is now made to <FIG>, <FIG>, <FIG>, and <FIG> which together illustrate an exemplary process flow <NUM> for system <NUM> in accordance with embodiments described herein. As depicted in <FIG> and <FIG>, process flow <NUM> may comprise the following sub-processes: network authentication <NUM>, T&C <NUM>, network selection client provision <NUM>, network selection policy pull <NUM>, access to enterprise services <NUM>, and network selection policy push <NUM>.

Network authentication <NUM> may begin with Generic Advertisement Service (GAS) Access Network Query Protocol (ANQP) and authentication IEEE <NUM> authentication (step <NUM>), where UE <NUM> authenticates itself for the purposes of connecting to AP <NUM>. Once step <NUM> has completed, UE <NUM> may initiate an authentication procedure (step <NUM>) with the NAS <NUM>, e.g., providing (via AP <NUM>) SIM-based credentials for authentication by a mobile network operator (MNO). NAS <NUM> may then use the credentials to authenticate UE <NUM> with the HSS <NUM> (step <NUM>), such that NAS <NUM> may effectively broker authentication of UE <NUM> by HSS <NUM>. Once UE <NUM> has been authenticated by HSS <NUM>, NAS <NUM> may provide UE <NUM> with a token indicating successful authentication and redirect UE <NUM> to T&C server <NUM> (step <NUM>). NAS <NUM> may also provide a token and a UE identifier (UE-ID) associated with UE <NUM> to T&C server <NUM> (step <NUM>).

T&C <NUM> may begin with UE <NUM> providing an associated UE-ID and the token received from NAS <NUM> to T&C server <NUM> (step <NUM>). T&C Server <NUM> may verify the UE-ID and token against the UE-ID and token received from NAS <NUM> and proceed per the relevant terms and conditions (step <NUM>). For example, different enterprise partners may have different terms and conditions for accessing the enterprise. T&C server <NUM> may then collect additional information from UE <NUM> in order to establish acceptance of the terms and conditions by UE <NUM> (step <NUM>). T&C server <NUM> may then provide a URL to UE <NUM> in order to redirect UE <NUM> to NSS <NUM> (step <NUM>).

Network selection client provision <NUM> may begin with UE <NUM> providing a network selection client provisioning / update request to NSS <NUM> (step <NUM>). NSS <NUM> may then select a network selection client type for UE <NUM> based on factors associated with UE <NUM> (step <NUM>). For example, the network selection client type may be selected based on a type of device and/or a user profile associated with UE <NUM>. NSS may then provision UE <NUM> with the selected network selection client, e.g., network selection client <NUM> from <FIG> (step <NUM>). It will be appreciated that in some cases, UE <NUM> may already have an installed client application that may be updated in step <NUM>. Similarly, in some cases, UE <NUM> may already have an up-to-date client application. In such cases step <NUM> may not be performed.

Once the network selection client has been provisioned/updated on UE <NUM>, network selection policy pull <NUM> may begin with UE <NUM> pulling a network selection policy from NSS <NUM> (step <NUM>). NSS <NUM> may select one or more appropriate network selection policies for UE <NUM> (step <NUM>) based on, for example, the associated network selection client type and/or other information specific to UE <NUM>. NSS <NUM> may then provide the selected network selection policies to UE <NUM> (step <NUM>).

UE <NUM> may then begin access to enterprise services <NUM> by sending a service request (step <NUM>) to AS/RP <NUM>. The service request may include the UE-ID and/or an application identifier to be used by AS/RP <NUM> to redirect UE <NUM> to IDP GW OP <NUM> (step <NUM>), where AS/RP <NUM> may send UE <NUM> an application identifier (ASClient-ID) and a URL for IDP GW OP <NUM>. UE <NUM> may then forward the ASClient-ID to IDP GW OP <NUM> (step <NUM>). IDP GW OP <NUM> may then perform application layer authentication for UE <NUM> (step <NUM>), Using, for example, known authentication methods, such as, for example, GBA-based authentication. IDP GW OP <NUM> may then perform authorization of use for ASClient-ID by UE <NUM> (step <NUM>) in line with enterprise policies for the indicated application vis-à-vis the requesting UE <NUM>.

Once IDP GW OP <NUM> has authorized UE <NUM> to access the requested application, it may provide an authorization code (Auth-Code) to UE <NUM> and redirect it to AS/RP <NUM> (step <NUM>). UE <NUM> may then send the authorization code to AS/RP <NUM> (step <NUM>), which in turn may forward the received authorization code to IDP GW OP <NUM> (step <NUM>). IDP GW OP <NUM> may then forward an ID-token and Access-Code to AS/RP <NUM> (step <NUM>) to "unlock" the requested enterprise service (as per the service request of step <NUM>).

AS/RP <NUM> may then "OK" the requested enterprise service (step <NUM>) by providing the Access-Code to UE <NUM>. UE <NUM> may then access a resource associated with the service request by sending the Access-Code to RS <NUM> (step <NUM>). RS <NUM> may use the received Access-Code to verify access (with the IDP GW OP <NUM>) by UE <NUM> (step <NUM>).

It will be appreciated that from time-to-time NSS <NUM> may update the policies for UE <NUM>, either directly, or as part of a group update for user-based policies and/or device-based policies. NSS <NUM> may push such a policy update to UE <NUM> in network selection policy push <NUM>. Network selection policy push <NUM> may begin with NSS <NUM> performing update policy decisions (step <NUM>) in accordance with user-based and/or device-based criteria. NSS <NUM> may then push one or more policy updates to UE <NUM> (step <NUM>).

It will be appreciated that an enterprise network implementation (e.g., enterprise network <NUM>) is typically much smaller (or more local) than a service provider's service area (e.g., service provider network <NUM>). By way of example, the enterprise network implementation may extend throughout a building, or a campus; whereas a service provider's service area may be a city, a region, or a country. Furthermore, an enterprise may also has access to additional information specific to its private location, building and/or network, which a service provider or a device cannot access. Hence it is much easier for the enterprise to more narrowly optimize the device's policies for performance specific to the local environment, as well as with regard to other aspects including the specifics of the device OS. Such optimizations may even be done on a static or dynamic basis, and may even be highly local in nature, using additional device data such as location data from other sources beyond GPS (e.g., such as beacons for tightly controlled lab-specific access policies), actions that the user is taking on the device, etc..

The following represents an exemplary listing of access selection policies that may be used individually and/or in combination for wireless devices <NUM> in system <NUM>:.

It will be appreciated that while systems <NUM>/<NUM> may facilitate enterprise-centric network selection policies, an installed network selection client application <NUM> may not necessarily be restricted to serving a single enterprise. Depending upon the implementation of network selection client application <NUM> and/or the storage space allocated to policy database <NUM>, application <NUM> may be "shared" by multiple enterprises, each with its own set of policies stored in policy database.

It is appreciated that software components of the embodiments of the disclosure may, if desired, be implemented in ROM (read only memory) form. The software components may, generally, be implemented in hardware, if desired, using conventional techniques. It is further appreciated that the software components may be instantiated, for example: as a computer program product or on a tangible medium. In some cases, it may be possible to instantiate the software components as a signal interpretable by an appropriate computer, although such an instantiation may be excluded in certain embodiments of the disclosure.

It is appreciated that various features of the embodiments of the disclosure which are, for clarity, described in the contexts of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features of the embodiments of the disclosure which are, for brevity, described in the context of a single embodiment may also be provided separately or in any suitable subcombination.

Claim 1:
An enterprise network (<NUM>) comprising:
at least one wireless access point operative to enable a wireless device (<NUM>) to connect to said enterprise network;
networked resources operative to be accessed by said wireless device; and
a network selection server (<NUM>), implemented on at least one computing device, and operative to:
authenticate (<NUM>, <NUM>) credentials provided by said wireless device when connecting to said enterprise network via said at least one wireless access point,
upon the authentication (<NUM>, <NUM>), determine (<NUM>) whether a network selection client application (<NUM>) is present on said wireless device, and
upon determining that said network selection client application is not present on said wireless device, push (<NUM>) an installable version of said network selection client application to said wireless device, the network selection client application comprising a device profile, the device profile specifying network access selection policies to said wireless device,
wherein said network access selection policies at least determine access by said wireless device to said networked resources while said wireless device is connected to said enterprise network,
wherein said network selection server (<NUM>) is further operative to:
determine (<NUM>) whether said network selection client application has an up-to-date network access selection policy for said wireless device to access said networked resources;
upon determining that said network access selection policy is not up-to-date, push (<NUM>) an updated version of said network access selection policy to said wireless device;
monitor (<NUM>) network access behavior by the wireless device; and
adjust (<NUM>) the network access selection policies for the wireless device based on analysis of the monitored network access behavior.