Techniques for optimizing wireless deployments using location-based association affinity

The present embodiments relate to connecting a network device to a wireless access point in a network environment based on an association affinity between the network device and the wireless access device. A wireless access point in a network environment can receive a request for a first network device to connect to any wireless access point in the network environment that includes a signal strength metric. The wireless access point can determine whether the first network device corresponds with a prioritized wireless access point using weighted averages based on a historical derived proximity of the wireless access points in the network environment and a historical connectivity to wireless access points in the network environment. A connection prioritization action can be performed to connect the first network device with the prioritized wireless access point in the network environment based on the determination of whether the first network device corresponds with the prioritized wireless access point.

BACKGROUND

Many network environments can include multiple wireless access points that can facilitate wireless data communication with network devices in the network environment. For example, a network device (e.g., a computer, a mobile device, a wireless printer, a network camera, a sensor) can connect to an access point in the network environment to initialize data communication with external devices via an external network (e.g., the internet). In network environments that include multiple wireless access points, the wireless network device may connect to any wireless access point in the network, such as the first wireless access point identified by the wireless network device, for example.

However, in such instances, the wireless network device may not connect to an access point with the greatest network processing efficiency for the wireless network device. For example, a network device may connect to a first access point with a greater distance (and a lower data communication capability) from the network device than a second access point that may include a greater data communication capability for the network device. This can lead to lower data throughput in data communication and lower user experience.

SUMMARY

The present embodiments relate to connecting a network device to a wireless access point in a network environment based on an association affinity between the network device and the wireless access device. A first example embodiment provides a method performed by a first wireless access point in a network environment. The method can include receiving a request for a first network device to connect to any wireless access point in the network environment. The method can also include obtaining a signal strength metric from the first network device.

The method can also include determining whether the first network device corresponds with a prioritized wireless access point. Determining whether the first network device corresponds with the prioritized wireless access point can include processing the historical derived proximity of the wireless access points in the network environment to assign a first set of weighting values to each wireless access point based on a historical proximity of each wireless access device to the first wireless device. Determining whether the first network device corresponds with the prioritized wireless access point can also include processing the historical connectivity to wireless access points in the network environment to assign a second set of weighting values to each wireless access point based on a number of previous connection instances of each wireless access device to the first network device. Determining whether the first network device corresponds with a prioritized wireless access point can also include selecting a second wireless access point as the prioritized wireless access point based on the first set of weighting values and the second set of weighting values assigned to the wireless access points. The method can also include performing a connection prioritization action to connect the first network device with the prioritized wireless access point in the network environment based on the determination of whether the first network device corresponds with the prioritized wireless access point.

A second example embodiment relates to a system. The system can include a processor and a non-transitory computer-readable medium. The non-transitory computer-readable medium can include instructions that, when executed by the processor, cause the processor to receive a request for a first network device to connect to any wireless access point in the network environment. The instructions can further cause the processor to obtain a signal strength metric for the first network device and each wireless access point in the network environment.

The instructions can further cause the processor to determine whether the first network device is associated with any wireless access point in the network environment based at least in part on a historical connectivity to wireless access points in the network environment and the obtained signal strength metrics. The instructions can further cause the processor to perform a connection action to connect the first network device with the prioritized wireless access point in the network environment based on the determination of whether the first network device is associated with any wireless access point in the network environment.

A third example embodiment relates to a non-transitory computer-readable medium. The non-transitory computer-readable medium can include stored thereon a sequence of instructions which, when executed by a processor causes the processor to execute a process. The process can include receiving a request for a first network device to any wireless access point in the network environment. The process can also include obtaining a signal strength metric from the first network device.

The process can also include determining whether the first network device is associated with any wireless access point in the network environment as a prioritized wireless access point. The prioritized wireless access point can be based at least in part on a historical connectivity to wireless access points in the network environment and a historical derived proximity of the wireless access points in the network environment to the first network device derived from obtained signal strength metrics. The process can also include performing a connection prioritization action to connect the first network device with the prioritized wireless access point in the network environment based on the determination of whether the first network device is associated with any wireless access point in the network environment as the prioritized wireless access point.

DETAILED DESCRIPTION

The present embodiments relate to connecting wireless network devices to access points in a network environment based on an affinity between a wireless network device and an access point. An affinity can comprise a previous connections between the wireless network device and the access point based on any of historical connection instances of the wireless network device to the access point and a proximity (e.g., determined based on a signal strength metric) between the wireless network device and the access point. For instance, a wireless network device comprising a wireless printer can be located nearest to a first access point. In this example, the wireless printer can have an affinity to the first access point based on the proximity to the first access point and/or any previous connection instances to the first access point.

Responsive to receiving a request for connection by a wireless network device, a wireless access point can obtain a signal strength metric (e.g., received signal strength indicator (RSSI)) between the wireless network device and each access point. The signal strength metric can provide insights into a proximity to each access point and/or a data processing capability for each access point.

The wireless access point can determine whether the network device is associated with (or has an affinity with) any wireless access point in the network environment. A wireless access point with such an association to the network device (e.g., based on a proximity to the network device and/or the previous connection instances) can be referred to as a prioritized wireless access point. The network device can be associated with a prioritized wireless access point based on a historical connectivity to wireless access points in the network environment (e.g., previous connections with access points) and a historical derived proximity of the wireless access points in the network environment to the network device (e.g., derived proximities of the wireless network device based on RSSI values). For example, a wireless device can be associated with first wireless access point when the wireless device is stationary (e.g., a wireless printer) and within a close proximity to the first wireless access point. Access points can access a table storing access points associated with a network device, historical connectivity to wireless access points in the network environment, and historical derived proximities of the wireless access points in the network environment.

A connection prioritization action can be performed by wireless access points in the network to connect the first network device with any prioritized wireless access point in the network. For example, the connection prioritization action can include all wireless access points other than the prioritized wireless access point delaying connection to a network device for a threshold time duration (e.g., 300 milliseconds, 1 second, 5 seconds). In this example, the network device can first connect to the prioritized wireless point during a time duration prior to the network device being able to connect to the other access points. As another example, the connection prioritization action can include the network device connecting to any wireless access points other than the prioritized wireless access point and subsequently disconnecting from the network device when the prioritized access point is available for connection to the network device.

In some embodiments, the network device can include a user device (e.g., a mobile phone, tablet) that can be mobile in nature (e.g., the device may be frequently moved about the network environment). In these embodiments, the network device may not be associated with any access point. Accordingly, the connection action can include identifying a proximity of the network device to all access points in the network environment and connecting to an access point with a nearest proximity to the network device.

The present embodiments can utilize identified wireless client location patterns from Received Signal Strength Indicator (RSSI) values to optimize a multiple Access Point (AP) wireless deployment by building affinity values for specific network devices into the APs based on network device characteristics. In a multi-AP wireless deployment where the APs are capable of coordinating actions or a status of each AP (e.g., either directly between APs or via a controller, server, or the like), a moving average of RSSI values may be calculated for each network device to associate with each given AP. Over time, based either on a simple moving average or a machine learning (ML) model, the frequency of associations for each network device to any other AP weighted according to a set of weights for each AP. This weight can be used to infer whether each unique network device, represented by its media access control (MAC) address is either a mobile device (e.g., a mobile phone), or a static wireless device (e.g., a desktop computer), as well as its propensity for remaining in a given location. The assigned weights can be used to derive a receptivity of any given AP to each network device, where the receptivity can include the availability of the AP to accept an association request against it from the given network device.

For example, an office environment can include 4 APs equally distributed across multiple floors in a building. Network devices can include guest mobile phones, employee mobile phones, laptop computers, desktop computers, printers, etc. As devices connect to APs, network devices can be observed as connecting to APs over time. Some network devices (e.g., mobile phones) can connect to a number of APs over time based on movement of the devices throughout the environment. Other devices (e.g., a printer, desktop computer) can be observed as remaining in a fixed location and can be associated with an access point nearest to such devices.

Historical connection data and historical proximity data can be used to build a receptivity weight for each AP and network device pair, such that a preferred (e.g., nearest) AP can always accept an association request immediately from a corresponding network device, where other APs can perform an action (e.g., delay connection) to the network device to encourage the network devices to associate to prioritized APs that included an optimized RSSI value, which can optimize WiFi performance.

In many instances, systems can use signal strength information to derive a location of a network device to an AP. However, in such instances, APs may be unable to prevent network devices from associating with a sub-optimal AP (e.g., an AP a great distance from the network device), as a stronger AP may not be immediately identified.

The present embodiments can allow for cooperative ranked-choice association affinity between a group of APs within a multi-AP deployment such that network devices can be explicitly directed into associating (or re-associating) with a prioritized AP. Further, the present embodiments can allow for adaptive and dynamic optimization of wireless network devices in a distributed wireless deployment.

A. Network Environment Overview

FIG.1illustrates an example network environment100including multiple access points (e.g.,102a-d) and multiple network devices (e.g.,104a-c,106a-b). As noted above, a plurality of access points102a-dcan be disposed within the network environment (e.g., a building, an office environment).

The access points102a-dcan provide wireless access to external networks (e.g., the internet) across the network environment100. For example, device104acan establish a connection to access point102a. The access points102a-dcan be disposed across the network environment100to provide optimized performance (e.g., data throughput) across the network environment100.

The network environment100can include a plurality of network devices104a-c,106a-b. For instance, network devices can include both network devices104a-cthat are static in nature (e.g., a server, a desktop computer, a copier) and network devices106a-bthat are mobile in nature (e.g., a mobile phone, a tablet, a laptop computer). As described in greater detail below, devices that are static in nature (e.g.,104a-c) may establish a prioritized access point, while devices that are mobile in nature (e.g.,106a-b) may not include an established prioritized access point.

As shown inFIG.1, network devices104a-c,106a-bcan connect to access points102a-dbased on associations between the network devices and access points. For instance, network device104acan correspond with prioritized access point102a. In this example, access point102acan first establish a connection with network device104awhile other access points102b-ddelay attempting to connect to network device104aaccording to a connection prioritization action. As another example, network device104ccan correspond with prioritized access point102c. In this example, access point102ccan first establish a connection with network device104cwhile other access points102a-b,102ddelay attempting to connect to network device104caccording to a connection prioritization action.

As another example, network device106amay not correspond with any prioritized access point. In this example, an access point (e.g.,102a) can obtain RSSI values of network device106afor each access point102a-d. The access point can derive a proximity of each network device106ato each access point102a-dand select an access point with a nearest proximity to the network device106a(e.g.,102a) as the prioritized access point. In this example, the connection prioritization action can include the access point102afirst attempting to connect to network device106a.

FIG.2is a block diagram of an example access point (AP)200. AP200can include features similar to those described with respect to access points102a-dinFIG.1. The AP can include a network interface202facilitating wireless data communication with other APs or network devices. The AP200can also include a processor204and a computer-readable medium206containing instructions to cause the processor to perform processing tasks as described herein.

The AP200can include a proximity derivation module208. The proximity derivation module208can obtain signal strength metrics (e.g., an RSSI value) for one or more network device(s). The signal strength metrics can be used to derive an approximate proximity of a network device to each AP. For instance, a RSSI value (e.g., −30 db) for a first network device can be converted into a corresponding proximity (e.g., in meters) to the access point. In some instances, a series of RSSI values can be obtained for each AP. In these instances, a proximity of the network device to each AP can be derived and utilized in selecting an AP as a prioritized AP as described herein.

The AP200can also include a wireless device connection module210. The wireless device connection module210can obtain a request to initiate a connection by a network device and initiate a connection to the network device. The wireless device connection module210can also obtain identifying information and a signal strength metric for the network device that can be used to determine whether the network device corresponds to a prioritized AP (e.g., as performed in associated AP derivation module214). The wireless device connection module210can perform a connection prioritization action (e.g., provide instructions to APs other than the prioritized AP to delay connection to the network device) to connect the network device to the prioritized AP.

The AP200can include a weighted average generation module212. The weighted average generation module212can obtain historical connection and historical proximity data for a network device and assign weights to each AP based on this data. The historical connection and historical proximity data can be obtained/accessed using a table (e.g.,216).

Historical connection data can specify previous connection instances of a network device to an AP. For example, historical connection data can specify ten previous connection instances where a network device (e.g.,104b) connects to a first AP (e.g.,102c) eight times and a second AP (e.g.,102b) two times. The historical connection data can be used to assign a first set of weighted averages to the APs. The first set of weighted averages to each of the APs can be used to assign a network device to a prioritized AP. For example, a first AP (e.g.,102c) can be assigned a first weighting factor and a second AP (e.g.,102b) can be assigned a second weighting factor. The weighting factors can be provided as integers, values, percentages, etc.

Historical proximity data can specify previous proximity data of a network device with each AP in the network environment. The historical proximity data can indicate a location of the network device relative to the APs in the network environment over time. For example, signal strength metrics (RSSI values) of the network device can be processed to determine that the network device is within a closest proximity to a first AP in the network environment at a given time, which can be included as part of the historical proximity data.

The historical proximity data can be processed to derive a second set of weights for the APs in the network environment. For example, the second set of weights can be assigned to each AP based on an average derived proximity of the network device to each AP over time. For example, a first AP that comprises a closest proximity to the network device of all APs for a majority of a time duration can include a greater weight than a second AP that comprises a more distant proximity to the network device of all APs for a majority of a time duration.

The AP200can also include an associated AP derivation module214. The associated AP derivation module214can determine whether a network device is associated with any access point as a prioritized AP. As noted above, a prioritized AP can include an AP with an affinity to a network device (e.g., based on previous connections to the AP and/or a historical proximity of the network device to the AP). For example, an access point disposed near (e.g., within ten feet) a network device (e.g., a desktop computer) can comprise a prioritized AP due to the proximity of the network device to the AP and historical connections of the network device to the AP.

As described herein, determining a prioritized AP for a network device can be based at least in part on a historical connection of the network device to APs in the network, historical proximity data of the network device to APs in the network, current signal strength metrics for the network device, and derived weighting factors for the APs in the network. For example, a first set of weighting factors can be assigned to the APs in the network based on historical connections to the network device and a second set of weighting factors can be assigned to the APs in the network based on historical proximity data for the network device.

Determining a prioritized AP for a network device can include ranking APs by each of the first set of weighting factors and the second set of weighting factors. For instance, a first ranked AP can include an AP with a greatest number of previous connection instances to the network device (as specified by the first set of weighting factors) and a closest proximity to the network device (as specified by the second set of weighting factors). As another example, the prioritized AP can include an AP with weighting factors above a threshold level.

Responsive to determining an AP as the prioritized AP, a connection prioritization action can be performed by the APs in the network. For instance, an action can be identified from multiple potential action based on the AP type, network settings, a network device type, etc. For instance, performing the connection prioritizing action can include providing instructions to all APs other than the prioritized AP to delay connection to the network device for a time duration to prioritize connection to the prioritized AP.

In some instances, a network device may not correspond with a prioritized AP. For example, a device new to the network may not have any previous connections to the network and may not correspond with any AP as a prioritized AP. As another example, a mobile device may be mobile in nature and can connect to multiple APs within the network environment and may not correspond with any AP as a prioritized AP. In such instances, an AP can obtain a signal strength metric of the network device for all APs and select an AP with a strongest signal strength metric (e.g., a closest proximity) as the prioritized AP.

The AP200can also include a table216. The table216can provide a listing of, for each network device, signal strength metrics, historical proximity data, historical connection data, weighting factors, prioritized APs, etc. The AP200can maintain the table216or obtain data included in the table216from another AP or a controller node external to the network environment. The table216is discussed in greater detail inFIG.3.

FIG.3illustrates an example table216. As noted above, the table216can provide data relating to an association between a network device and APs in the network environment. For instance, a table216can include data relating to multiple network devices302a-c. For each network device302a-c, the table216can include signal strength metric data304a-c, connection history data306a-c, weighted average data308a-c, AP associations310a-c, etc. Each time a network device is connected to an AP in the network, data (e.g., signal strength values, an AP in which the network device connected) can be updated at the table.

The table can maintain a listing of signal strength values304a-cfor each AP at a given time instance. The signal strength values can be used to derive a proximity of each network device to each AP in the network. In some instances, some APs may be located beyond a threshold distance from the network device, and the APs may not identify the network device. The signal strength values can be stored over time (e.g., as historical proximity data) to provide a second weighted average for each AP. As an illustrative example, a first network device can have associated RSSI values for APs in the network, where a first AP has a first average RSSI value (−38 db) over a time duration and a second AP has a second average RSSI value (−100 db) over the time duration. In this example, the first AP may have a closer average proximity based on converting the RSSI values into a proximity to the network device. Weighting factors for each AP can be derived and stored in the table216(e.g., at308a-c).

The table216can also maintain a listing of historical connections (e.g.,306a-c) for each network device302a-c. For example, a listing of historical connections can provide that a first AP previously connected to the network device eight times, while a second AP previously connected to the network device one time. A second set of weighted averages can be derived from the historic connections to the network device.

The table data can be utilized to determine whether a network device is associated with an AP. In some embodiments, the table216can specify whether an AP is associated with the network device (e.g., in310a-c). As an illustrative example, network device302bcan include a desktop computer located in the network environment near access point 2 (AP2). In table216, the historical proximity data304bcan indicate a closest proximity of the network device302bto AP2. Further, as shown in the table216, the historical connection data306bcan specify that the network device302bhas previously connected to AP2 in multiple instances. Accordingly, weighted averages (e.g., in308b) can include a greatest weight for AP2 based on the historical connections (e.g., in306b) and historical proximity data (e.g., in304b) to identify AP2 as the prioritized AP (e.g., in310b).

In this example, the table216can provide data relating to another network device302c(e.g., a mobile phone). In table216, the historical proximity data304cmay not comprise any AP with a closest proximity over time due to the movement of the mobile phone in the network environment. Further, as shown in the table216, the historical connection data306ccan specify that the network device302bhas previously connected to each AP (e.g., AP1, AP2, AP3) in multiple instances. Accordingly, weighted averages (e.g., in308b) may be assigned to all APs such that no AP comprises threshold levels to associate the network device302cwith any AP, and no AP is associated with the network device302c(e.g., in310c).

B. Example Method for Connecting a Network Device to an AP Based on a Derived Affinity

FIG.4is a block diagram400of an example method for connecting a network device to an AP based on an affinity between the network device and AP. An AP (e.g.,200) as described herein can perform any steps of the method as described herein. In some instances, an external controller node can direct an AP (or a plurality of APs) to perform any steps of the method as described herein.

At402, a connection request from a network device can be received. For instance, responsive to a network device (e.g., a computer, mobile device) entering the network, the network device can submit a request to connect to the network to any discovered APs in the network. The request can include information identifying the network device (e.g., serial number, MAC address, device type, an account associated with the network device).

At404, a signal strength metric for the network device can be obtained. This can include the network device (or the AP) obtaining a message and deriving a signal strength metric (e.g., RSSI) from the message. For instance, the network device can interact with each discoverable AP in the network and each AP can derive a respective signal strength metric for each AP. A first AP (a controlling AP) or a controller node can obtain the obtained signal strength metric(s).

At decision406, it can be determined whether the network device is associated with a prioritized access point. For instance, this can include determining whether the network device has a previously identified prioritized AP (e.g., provided in table216). As another example, determining whether the network device is associated with a prioritized access point can include deriving weighted averages and identifying an AP as a prioritized AP. Determining whether the network device is associated with a prioritized access point is described in greater detail with respect toFIG.5below.

At408, if the network device corresponds with a prioritized AP, instructions can be provided to each AP in the network to perform a connection action. For instance, all APs other than the prioritized AP can obtain instructions to delay connection to the network device for a time duration, allowing the network device to first connect to the prioritized AP. As another example, all APs other than the prioritized AP can obtain instructions to allow the network device to connect any AP but subsequently disconnect from the AP responsive to determining the prioritized AP is available to connect to the network device. The connection action can prioritize an associated with an affinity to the network device prioritized a connection to the network device.

At410, responsive to determining that the network device has no prioritized AP, a proximity of the network device to each AP can be determined based on obtained signal strength metrics for each respective AP. For example, signal strength metrics (e.g., RSSI values) can be converted into an estimated proximity to each AP (e.g., using a conversion algorithm, a conversion table). The network device may not be associated with any AP if the network device is new to the network or is a mobile device that connects to multiple APs across the network due to the mobile nature of the device, for example.

At412, a first AP with a nearest proximity can be selected as the prioritized AP for the network device. For example, RSSI values of APs in a network can specify that a first AP is nearest to a mobile device in the network. In such instances, selecting an AP that is nearest to the network device can optimize data transmission between the network device and the selected AP.

FIG.5illustrates a block diagram500of an example method for determining whether a network device corresponds to a prioritized AP (e.g.,502). The method as described inFIG.5can be performed by a first wireless access point in the network environment or a controlling node disposed external to the network environment (e.g., disposed in a cloud infrastructure system), for example.

At504, a signal strength metric for the network device with each AP in the network environment can be obtained. As noted above, signal strength metrics can be indicative of a proximity of each AP to the network device, which can also specify data communication capabilities of each AP for the network device. An AP can obtain signal strength metrics from each respective AP or from the network device. In some embodiments, the AP can only process signal strength data for APs with a signal strength metric above a threshold (e.g., removing any APs outside a threshold distance from the network device). In some embodiments, depending on the network device type, only APs capable of transmitting data over a specific frequency (e.g., 2.4 GHz, 5 GHz) may be processed as described herein, omitting any AP unable to transmit data over the specific frequency.

At506, a listing of historical connection data for the network device can be retrieved. The historical connection data can specify a number of previous connection instances of the network device to APs in the network. The historical connection data can be retrieved from a table (e.g.,216) either stored at the AP or maintained at another AP (e.g., or an external controller node). For instance, a first AP can identify a network device from identifying information received from the network device and send a request to a controlling node to obtain the historical connection data from the controlling node maintaining the table.

At508, a first weighted average for each AP can be derived based on the listing of historical connection data. The first weighted average can include assigning weights or weighting values to each AP in the network environment. For example, historical connection data can specify that for ten previous connection instances, a first AP connected to the network device eight times and a second AP connected to the network device two times. The weight assigned to the first AP can include a highest weight given the number of connection instances to the network device, indicating an affinity for the network device to connect to the first AP. Similarly, a second AP can be assigned a second weight that is less than the weight for the first AP. Assigned weights can include values, integers, percentages, multiplication factors, etc., associated with each AP. The assigned weights in the first set of weighting factors can be updated and added to the table.

At510, a listing of historical proximity data for the network device can be retrieved. The historical proximity data can include signal strength metrics (e.g., RSSI values) for the APs over a time duration. The historical proximity data can be indicative of an average proximity of each AP to the network device over time, and whether the network device is mobile or stationary in nature. The historical proximity data may be retrieved from the table (e.g., stored at the AP or retrieved from an external device).

At512, a second weighted average for each AP can be derived based on the listing of historical proximity data. The weights can be assigned to each AP based on a derived proximity of each AP to the network device. For example, an average proximity of a first AP to the network device for a time duration (e.g., one week) can include ten feet, and an average proximity of a second AP to the network device for the time duration can include fifty feet. In this example, a first assigned weight for the first AP can be greater than an assigned weight for the second AP based on the average proximity of each AP to the network device. The assigned weights based on the historical proximity data can be indicative of a closer average proximity of each AP to the network device, which can be indicative of an affinity of any AP to the network device.

At514, a first AP can be identified as the prioritized AP based on the first weighted averages and second weighted averages. For instance, for each AP, the assigned weights from the first weighted averages and second weighted averages can be combined to rank/arrange the APs by the assigned weights. For instance, a first AP with a highest combined assigned weight (e.g., indicative of a number of connection instances to the network device and an average proximity to the network device) can be selected as the prioritized AP. In some instances, an AP can be selected as a prioritized AP only if both assigned weights exceed a threshold level.

At516, an instruction to perform the connection prioritization action can be provided to each AP in the network. As described above, the connection prioritization action can include instruction to all APs other than the prioritized AP to delay connection to the network device or disconnect from the network device.

As noted above, infrastructure as a service (IaaS) is one particular type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet). For example, the external controller or the sharing of data (e.g., tables) between wireless access points as described herein can be operated using one or more IaaS models. In an IaaS model, a cloud computing provider can host the infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., a hypervisor layer), or the like). In some cases, an IaaS provider may also supply a variety of services to accompany those infrastructure components (e.g., billing, monitoring, logging, load balancing and clustering, etc.). Thus, as these services may be policy-driven, IaaS users may be able to implement policies to drive load balancing to maintain application availability and performance.

The VCN606can include a local peering gateway (LPG)610that can be communicatively coupled to a secure shell (SSH) VCN612via an LPG610contained in the SSH VCN612. The SSH VCN612can include an SSH subnet614, and the SSH VCN612can be communicatively coupled to a control plane VCN616via the LPG610contained in the control plane VCN616. Also, the SSH VCN612can be communicatively coupled to a data plane VCN618via an LPG610. The control plane VCN616and the data plane VCN618can be contained in a service tenancy619that can be owned and/or operated by the IaaS provider.

The control plane VCN616can include a control plane demilitarized zone (DMZ) tier620that acts as a perimeter network (e.g., portions of a corporate network between the corporate intranet and external networks). The DMZ-based servers may have restricted responsibilities and help keep breaches contained. Additionally, the DMZ tier620can include one or more load balancer (LB) subnet(s)622, a control plane app tier624that can include app subnet(s)626, a control plane data tier628that can include database (DB) subnet(s)630(e.g., frontend DB subnet(s) and/or backend DB subnet(s)). The LB subnet(s)622contained in the control plane DMZ tier620can be communicatively coupled to the app subnet(s)626contained in the control plane app tier624and an Internet gateway634that can be contained in the control plane VCN616, and the app subnet(s)626can be communicatively coupled to the DB subnet(s)630contained in the control plane data tier628and a service gateway636and a network address translation (NAT) gateway638. The control plane VCN616can include the service gateway636and the NAT gateway638.

The control plane VCN616can include a data plane mirror app tier640that can include app subnet(s)626. The app subnet(s)626contained in the data plane mirror app tier640can include a virtual network interface controller (VNIC)642that can execute a compute instance644. The compute instance644can communicatively couple the app subnet(s)626of the data plane mirror app tier640to app subnet(s)626that can be contained in a data plane app tier646.

The data plane VCN618can include the data plane app tier646, a data plane DMZ tier648, and a data plane data tier650. The data plane DMZ tier648can include LB subnet(s)622that can be communicatively coupled to the app subnet(s)626of the data plane app tier646and the Internet gateway634of the data plane VCN618. The app subnet(s)626can be communicatively coupled to the service gateway636of the data plane VCN618and the NAT gateway638of the data plane VCN618. The data plane data tier650can also include the DB subnet(s)630that can be communicatively coupled to the app subnet(s)626of the data plane app tier646.

The Internet gateway634of the control plane VCN616and of the data plane VCN618can be communicatively coupled to a metadata management service652that can be communicatively coupled to public Internet654. Public Internet654can be communicatively coupled to the NAT gateway638of the control plane VCN616and of the data plane VCN618. The service gateway636of the control plane VCN616and of the data plane VCN618can be communicatively couple to cloud services656.

In some examples, the service gateway636of the control plane VCN616or of the data plane VCN618can make application programming interface (API) calls to cloud services656without going through public Internet654. The API calls to cloud services656from the service gateway636can be one-way: the service gateway636can make API calls to cloud services656, and cloud services656can send requested data to the service gateway636. But, cloud services656may not initiate API calls to the service gateway636.

In some examples, the secure host tenancy604can be directly connected to the service tenancy619, which may be otherwise isolated. The secure host subnet608can communicate with the SSH subnet614through an LPG610that may enable two-way communication over an otherwise isolated system. Connecting the secure host subnet608to the SSH subnet614may give the secure host subnet608access to other entities within the service tenancy619.

The control plane VCN616may allow users of the service tenancy619to set up or otherwise provision desired resources. Desired resources provisioned in the control plane VCN616may be deployed or otherwise used in the data plane VCN618. In some examples, the control plane VCN616can be isolated from the data plane VCN618, and the data plane mirror app tier640of the control plane VCN616can communicate with the data plane app tier646of the data plane VCN618via VNICs642that can be contained in the data plane mirror app tier640and the data plane app tier646.

In some examples, users of the system, or customers, can make requests, for example create, read, update, or delete (CRUD) operations, through public Internet654that can communicate the requests to the metadata management service652. The metadata management service652can communicate the request to the control plane VCN616through the Internet gateway634. The request can be received by the LB subnet(s)622contained in the control plane DMZ tier620. The LB subnet(s)622may determine that the request is valid, and in response to this determination, the LB subnet(s)622can transmit the request to app subnet(s)626contained in the control plane app tier624. If the request is validated and requires a call to public Internet654, the call to public Internet654may be transmitted to the NAT gateway638that can make the call to public Internet654. Memory that may be desired to be stored by the request can be stored in the DB subnet(s)630.

In some examples, the data plane mirror app tier640can facilitate direct communication between the control plane VCN616and the data plane VCN618. For example, changes, updates, or other suitable modifications to configuration may be desired to be applied to the resources contained in the data plane VCN618. Via a VNIC642, the control plane VCN616can directly communicate with, and can thereby execute the changes, updates, or other suitable modifications to configuration to, resources contained in the data plane VCN618.

In some embodiments, the control plane VCN616and the data plane VCN618can be contained in the service tenancy619. In this case, the user, or the customer, of the system may not own or operate either the control plane VCN616or the data plane VCN618. Instead, the IaaS provider may own or operate the control plane VCN616and the data plane VCN618, both of which may be contained in the service tenancy619. This embodiment can enable isolation of networks that may prevent users or customers from interacting with other users', or other customers', resources. Also, this embodiment may allow users or customers of the system to store databases privately without needing to rely on public Internet654, which may not have a desired level of threat prevention, for storage.

In other embodiments, the LB subnet(s)622contained in the control plane VCN616can be configured to receive a signal from the service gateway636. In this embodiment, the control plane VCN616and the data plane VCN618may be configured to be called by a customer of the IaaS provider without calling public Internet654. Customers of the IaaS provider may desire this embodiment since database(s) that the customers use may be controlled by the IaaS provider and may be stored on the service tenancy619, which may be isolated from public Internet654.

FIG.7is a block diagram700illustrating another example pattern of an IaaS architecture, according to at least one embodiment. Service operators702(e.g. service operators602ofFIG.6) can be communicatively coupled to a secure host tenancy704(e.g. the secure host tenancy604ofFIG.6) that can include a virtual cloud network (VCN)706(e.g. the VCN606ofFIG.6) and a secure host subnet708(e.g. the secure host subnet608ofFIG.6). The VCN706can include a local peering gateway (LPG)710(e.g. the LPG610ofFIG.6) that can be communicatively coupled to a secure shell (SSH) VCN712(e.g. the SSH VCN612ofFIG.6) via an LPG610contained in the SSH VCN712. The SSH VCN712can include an SSH subnet714(e.g. the SSH subnet614ofFIG.6), and the SSH VCN712can be communicatively coupled to a control plane VCN716(e.g. the control plane VCN616ofFIG.6) via an LPG710contained in the control plane VCN716. The control plane VCN716can be contained in a service tenancy719(e.g. the service tenancy619ofFIG.6), and the data plane VCN718(e.g. the data plane VCN618ofFIG.6) can be contained in a customer tenancy721that may be owned or operated by users, or customers, of the system.

The control plane VCN716can include a control plane DMZ tier720(e.g. the control plane DMZ tier620ofFIG.6) that can include LB subnet(s)722(e.g. LB subnet(s)622ofFIG.6), a control plane app tier724(e.g. the control plane app tier624ofFIG.6) that can include app subnet(s)726(e.g. app subnet(s)626ofFIG.6), a control plane data tier728(e.g. the control plane data tier628ofFIG.6) that can include database (DB) subnet(s)730(e.g. similar to DB subnet(s)630ofFIG.6). The LB subnet(s)722contained in the control plane DMZ tier720can be communicatively coupled to the app subnet(s)726contained in the control plane app tier724and an Internet gateway734(e.g. the Internet gateway634ofFIG.6) that can be contained in the control plane VCN716, and the app subnet(s)726can be communicatively coupled to the DB subnet(s)730contained in the control plane data tier728and a service gateway736(e.g. the service gateway ofFIG.6) and a network address translation (NAT) gateway738(e.g. the NAT gateway638ofFIG.6). The control plane VCN716can include the service gateway736and the NAT gateway738.

The control plane VCN716can include a data plane mirror app tier740(e.g. the data plane mirror app tier640ofFIG.6) that can include app subnet(s)726. The app subnet(s)726contained in the data plane mirror app tier740can include a virtual network interface controller (VNIC)742(e.g. the VNIC of642) that can execute a compute instance744(e.g. similar to the compute instance644ofFIG.6). The compute instance744can facilitate communication between the app subnet(s)726of the data plane mirror app tier740and the app subnet(s)726that can be contained in a data plane app tier746(e.g. the data plane app tier646ofFIG.6) via the VNIC742contained in the data plane mirror app tier740and the VNIC742contained in the data plane app tier746.

The Internet gateway734contained in the control plane VCN716can be communicatively coupled to a metadata management service752(e.g. the metadata management service652ofFIG.6) that can be communicatively coupled to public Internet754(e.g. public Internet654ofFIG.6). Public Internet754can be communicatively coupled to the NAT gateway738contained in the control plane VCN716. The service gateway736contained in the control plane VCN716can be communicatively couple to cloud services756(e.g. cloud services656ofFIG.6).

In some examples, the data plane VCN718can be contained in the customer tenancy721. In this case, the IaaS provider may provide the control plane VCN716for each customer, and the IaaS provider may, for each customer, set up a unique compute instance744that is contained in the service tenancy719. Each compute instance744may allow communication between the control plane VCN716, contained in the service tenancy719, and the data plane VCN718that is contained in the customer tenancy721. The compute instance744may allow resources, that are provisioned in the control plane VCN716that is contained in the service tenancy719, to be deployed or otherwise used in the data plane VCN718that is contained in the customer tenancy721.

In other examples, the customer of the IaaS provider may have databases that live in the customer tenancy721. In this example, the control plane VCN716can include the data plane mirror app tier740that can include app subnet(s)726. The data plane mirror app tier740can reside in the data plane VCN718, but the data plane mirror app tier740may not live in the data plane VCN718. That is, the data plane mirror app tier740may have access to the customer tenancy721, but the data plane mirror app tier740may not exist in the data plane VCN718or be owned or operated by the customer of the IaaS provider. The data plane mirror app tier740may be configured to make calls to the data plane VCN718but may not be configured to make calls to any entity contained in the control plane VCN716. The customer may desire to deploy or otherwise use resources in the data plane VCN718that are provisioned in the control plane VCN716, and the data plane mirror app tier740can facilitate the desired deployment, or other usage of resources, of the customer.

In some embodiments, the customer of the IaaS provider can apply filters to the data plane VCN718. In this embodiment, the customer can determine what the data plane VCN718can access, and the customer may restrict access to public Internet754from the data plane VCN718. The IaaS provider may not be able to apply filters or otherwise control access of the data plane VCN718to any outside networks or databases. Applying filters and controls by the customer onto the data plane VCN718, contained in the customer tenancy721, can help isolate the data plane VCN718from other customers and from public Internet754.

In some embodiments, cloud services756can be called by the service gateway736to access services that may not exist on public Internet754, on the control plane VCN716, or on the data plane VCN718. The connection between cloud services756and the control plane VCN716or the data plane VCN718may not be live or continuous. Cloud services756may exist on a different network owned or operated by the IaaS provider. Cloud services756may be configured to receive calls from the service gateway736and may be configured to not receive calls from public Internet754. Some cloud services756may be isolated from other cloud services756, and the control plane VCN716may be isolated from cloud services756that may not be in the same region as the control plane VCN716. For example, the control plane VCN716may be located in “Region 1,” and cloud service “Deployment 6,” may be located in Region 1 and in “Region 2.” If a call to Deployment 6 is made by the service gateway736contained in the control plane VCN716located in Region 1, the call may be transmitted to Deployment 6 in Region 1. In this example, the control plane VCN716, or Deployment 6 in Region 1, may not be communicatively coupled to, or otherwise in communication with, Deployment 6 in Region 2.

FIG.8is a block diagram800illustrating another example pattern of an IaaS architecture, according to at least one embodiment. Service operators802(e.g. service operators602ofFIG.6) can be communicatively coupled to a secure host tenancy804(e.g. the secure host tenancy604ofFIG.6) that can include a virtual cloud network (VCN)806(e.g. the VCN606ofFIG.6) and a secure host subnet808(e.g. the secure host subnet608ofFIG.6). The VCN806can include an LPG810(e.g. the LPG610ofFIG.6) that can be communicatively coupled to an SSH VCN812(e.g. the SSH VCN612ofFIG.6) via an LPG810contained in the SSH VCN812. The SSH VCN812can include an SSH subnet814(e.g. the SSH subnet614ofFIG.6), and the SSH VCN812can be communicatively coupled to a control plane VCN816(e.g. the control plane VCN616ofFIG.6) via an LPG810contained in the control plane VCN816and to a data plane VCN818(e.g. the data plane618ofFIG.6) via an LPG810contained in the data plane VCN818. The control plane VCN816and the data plane VCN818can be contained in a service tenancy819(e.g. the service tenancy619ofFIG.6).

The control plane VCN816can include a control plane DMZ tier820(e.g. the control plane DMZ tier620ofFIG.6) that can include load balancer (LB) subnet(s)822(e.g. LB subnet(s)622ofFIG.6), a control plane app tier824(e.g. the control plane app tier624ofFIG.6) that can include app subnet(s)826(e.g. similar to app subnet(s)626ofFIG.6), a control plane data tier828(e.g. the control plane data tier628ofFIG.6) that can include DB subnet(s)830. The LB subnet(s)822contained in the control plane DMZ tier820can be communicatively coupled to the app subnet(s)826contained in the control plane app tier824and to an Internet gateway834(e.g. the Internet gateway634ofFIG.6) that can be contained in the control plane VCN816, and the app subnet(s)826can be communicatively coupled to the DB subnet(s)830contained in the control plane data tier828and to a service gateway836(e.g. the service gateway ofFIG.6) and a network address translation (NAT) gateway838(e.g. the NAT gateway638ofFIG.6). The control plane VCN816can include the service gateway836and the NAT gateway838.

The data plane VCN818can include a data plane app tier846(e.g. the data plane app tier646ofFIG.6), a data plane DMZ tier848(e.g. the data plane DMZ tier648ofFIG.6), and a data plane data tier850(e.g. the data plane data tier650ofFIG.6). The data plane DMZ tier848can include LB subnet(s)822that can be communicatively coupled to trusted app subnet(s)860and untrusted app subnet(s)862of the data plane app tier846and the Internet gateway834contained in the data plane VCN818. The trusted app subnet(s)860can be communicatively coupled to the service gateway836contained in the data plane VCN818, the NAT gateway838contained in the data plane VCN818, and DB subnet(s)830contained in the data plane data tier850. The untrusted app subnet(s)862can be communicatively coupled to the service gateway836contained in the data plane VCN818and DB subnet(s)830contained in the data plane data tier850. The data plane data tier850can include DB subnet(s)830that can be communicatively coupled to the service gateway836contained in the data plane VCN818.

The untrusted app subnet(s)862can include one or more primary VNICs864(1)-(N) that can be communicatively coupled to tenant virtual machines (VMs)866(1)-(N). Each tenant VM866(1)-(N) can be communicatively coupled to a respective app subnet867(1)-(N) that can be contained in respective container egress VCNs868(1)-(N) that can be contained in respective customer tenancies870(1)-(N). Respective secondary VNICs872(1)-(N) can facilitate communication between the untrusted app subnet(s)862contained in the data plane VCN818and the app subnet contained in the container egress VCNs868(1)-(N). Each container egress VCNs868(1)-(N) can include a NAT gateway838that can be communicatively coupled to public Internet854(e.g. public Internet654ofFIG.6).

The Internet gateway834contained in the control plane VCN816and contained in the data plane VCN818can be communicatively coupled to a metadata management service852(e.g. the metadata management system652ofFIG.6) that can be communicatively coupled to public Internet854. Public Internet854can be communicatively coupled to the NAT gateway838contained in the control plane VCN816and contained in the data plane VCN818. The service gateway836contained in the control plane VCN816and contained in the data plane VCN818can be communicatively couple to cloud services856.

In some examples, the customer of the IaaS provider may grant temporary network access to the IaaS provider and request a function to be attached to the data plane tier app846. Code to run the function may be executed in the VMs866(1)-(N), and the code may not be configured to run anywhere else on the data plane VCN818. Each VM866(1)-(N) may be connected to one customer tenancy870. Respective containers871(1)-(N) contained in the VMs866(1)-(N) may be configured to run the code. In this case, there can be a dual isolation (e.g., the containers871(1)-(N) running code, where the containers871(1)-(N) may be contained in at least the VM866(1)-(N) that are contained in the untrusted app subnet(s)862), which may help prevent incorrect or otherwise undesirable code from damaging the network of the IaaS provider or from damaging a network of a different customer. The containers871(1)-(N) may be communicatively coupled to the customer tenancy870and may be configured to transmit or receive data from the customer tenancy870. The containers871(1)-(N) may not be configured to transmit or receive data from any other entity in the data plane VCN818. Upon completion of running the code, the IaaS provider may kill or otherwise dispose of the containers871(1)-(N).

In some embodiments, the trusted app subnet(s)860may run code that may be owned or operated by the IaaS provider. In this embodiment, the trusted app subnet(s)860may be communicatively coupled to the DB subnet(s)830and be configured to execute CRUD operations in the DB subnet(s)830. The untrusted app subnet(s)862may be communicatively coupled to the DB subnet(s)830, but in this embodiment, the untrusted app subnet(s) may be configured to execute read operations in the DB subnet(s)830. The containers871(1)-(N) that can be contained in the VM866(1)-(N) of each customer and that may run code from the customer may not be communicatively coupled with the DB subnet(s)830.

In other embodiments, the control plane VCN816and the data plane VCN818may not be directly communicatively coupled. In this embodiment, there may be no direct communication between the control plane VCN816and the data plane VCN818. However, communication can occur indirectly through at least one method. An LPG810may be established by the IaaS provider that can facilitate communication between the control plane VCN816and the data plane VCN818. In another example, the control plane VCN816or the data plane VCN818can make a call to cloud services856via the service gateway836. For example, a call to cloud services856from the control plane VCN816can include a request for a service that can communicate with the data plane VCN818.

FIG.9is a block diagram900illustrating another example pattern of an IaaS architecture, according to at least one embodiment. Service operators902(e.g. service operators602ofFIG.6) can be communicatively coupled to a secure host tenancy904(e.g. the secure host tenancy604ofFIG.6) that can include a virtual cloud network (VCN)906(e.g. the VCN606ofFIG.6) and a secure host subnet908(e.g. the secure host subnet608ofFIG.6). The VCN906can include an LPG910(e.g. the LPG610ofFIG.6) that can be communicatively coupled to an SSH VCN912(e.g. the SSH VCN612ofFIG.6) via an LPG910contained in the SSH VCN912. The SSH VCN912can include an SSH subnet914(e.g. the SSH subnet614ofFIG.6), and the SSH VCN912can be communicatively coupled to a control plane VCN916(e.g. the control plane VCN616ofFIG.6) via an LPG910contained in the control plane VCN916and to a data plane VCN918(e.g. the data plane618ofFIG.6) via an LPG910contained in the data plane VCN918. The control plane VCN916and the data plane VCN918can be contained in a service tenancy919(e.g. the service tenancy619ofFIG.6).

The control plane VCN916can include a control plane DMZ tier920(e.g. the control plane DMZ tier620ofFIG.6) that can include LB subnet(s)922(e.g. LB subnet(s)622ofFIG.6), a control plane app tier924(e.g. the control plane app tier624ofFIG.6) that can include app subnet(s)926(e.g. app subnet(s)626ofFIG.6), a control plane data tier928(e.g. the control plane data tier628ofFIG.6) that can include DB subnet(s)930(e.g. DB subnet(s)830ofFIG.8). The LB subnet(s)922contained in the control plane DMZ tier920can be communicatively coupled to the app subnet(s)926contained in the control plane app tier924and to an Internet gateway934(e.g. the Internet gateway634ofFIG.6) that can be contained in the control plane VCN916, and the app subnet(s)926can be communicatively coupled to the DB subnet(s)930contained in the control plane data tier928and to a service gateway936(e.g. the service gateway ofFIG.6) and a network address translation (NAT) gateway938(e.g. the NAT gateway638ofFIG.6). The control plane VCN916can include the service gateway936and the NAT gateway938.

The data plane VCN918can include a data plane app tier946(e.g. the data plane app tier646ofFIG.6), a data plane DMZ tier948(e.g. the data plane DMZ tier648ofFIG.6), and a data plane data tier950(e.g. the data plane data tier650ofFIG.6). The data plane DMZ tier948can include LB subnet(s)922that can be communicatively coupled to trusted app subnet(s)960(e.g. trusted app subnet(s)860ofFIG.8) and untrusted app subnet(s)962(e.g. untrusted app subnet(s)862ofFIG.8) of the data plane app tier946and the Internet gateway934contained in the data plane VCN918. The trusted app subnet(s)960can be communicatively coupled to the service gateway936contained in the data plane VCN918, the NAT gateway938contained in the data plane VCN918, and DB subnet(s)930contained in the data plane data tier950. The untrusted app subnet(s)962can be communicatively coupled to the service gateway936contained in the data plane VCN918and DB subnet(s)930contained in the data plane data tier950. The data plane data tier950can include DB subnet(s)930that can be communicatively coupled to the service gateway936contained in the data plane VCN918.

The untrusted app subnet(s)962can include primary VNICs964(1)-(N) that can be communicatively coupled to tenant virtual machines (VMs)966(1)-(N) residing within the untrusted app subnet(s)962. Each tenant VM966(1)-(N) can run code in a respective container967(1)-(N), and be communicatively coupled to an app subnet926that can be contained in a data plane app tier946that can be contained in a container egress VCN968. Respective secondary VNICs972(1)-(N) can facilitate communication between the untrusted app subnet(s)962contained in the data plane VCN918and the app subnet contained in the container egress VCN968. The container egress VCN can include a NAT gateway938that can be communicatively coupled to public Internet954(e.g. public Internet654ofFIG.6).

The Internet gateway934contained in the control plane VCN916and contained in the data plane VCN918can be communicatively coupled to a metadata management service952(e.g. the metadata management system652ofFIG.6) that can be communicatively coupled to public Internet954. Public Internet954can be communicatively coupled to the NAT gateway938contained in the control plane VCN916and contained in the data plane VCN918. The service gateway936contained in the control plane VCN916and contained in the data plane VCN918can be communicatively couple to cloud services956.

In some examples, the pattern illustrated by the architecture of block diagram900ofFIG.9may be considered an exception to the pattern illustrated by the architecture of block diagram800ofFIG.8and may be desirable for a customer of the IaaS provider if the IaaS provider cannot directly communicate with the customer (e.g., a disconnected region). The respective containers967(1)-(N) that are contained in the VMs966(1)-(N) for each customer can be accessed in real-time by the customer. The containers967(1)-(N) may be configured to make calls to respective secondary VNICs972(1)-(N) contained in app subnet(s)926of the data plane app tier946that can be contained in the container egress VCN968. The secondary VNICs972(1)-(N) can transmit the calls to the NAT gateway938that may transmit the calls to public Internet954. In this example, the containers967(1)-(N) that can be accessed in real-time by the customer can be isolated from the control plane VCN916and can be isolated from other entities contained in the data plane VCN918. The containers967(1)-(N) may also be isolated from resources from other customers.

In other examples, the customer can use the containers967(1)-(N) to call cloud services956. In this example, the customer may run code in the containers967(1)-(N) that requests a service from cloud services956. The containers967(1)-(N) can transmit this request to the secondary VNICs972(1)-(N) that can transmit the request to the NAT gateway that can transmit the request to public Internet954. Public Internet954can transmit the request to LB subnet(s)922contained in the control plane VCN916via the Internet gateway934. In response to determining the request is valid, the LB subnet(s) can transmit the request to app subnet(s)926that can transmit the request to cloud services956via the service gateway936.

FIG.10illustrates an example computer system1000, in which various embodiments may be implemented. The system1000may be used to implement any of the computer systems described above. As shown in the figure, computer system1000includes a processing unit1004that communicates with a number of peripheral subsystems via a bus subsystem1002. These peripheral subsystems may include a processing acceleration unit1006, an I/O subsystem1008, a storage subsystem1018and a communications subsystem1024. Storage subsystem1018includes tangible computer-readable storage media1022and a system memory1010.

Processing unit1004, which can be implemented as one or more integrated circuits (e.g., a conventional microprocessor or microcontroller), controls the operation of computer system1000. One or more processors may be included in processing unit1004. These processors may include single core or multicore processors. In certain embodiments, processing unit1004may be implemented as one or more independent processing units1032and/or1034with single or multicore processors included in each processing unit. In other embodiments, processing unit1004may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

In various embodiments, processing unit1004can execute a variety of programs in response to program code and can maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed can be resident in processor(s)1004and/or in storage subsystem1018. Through suitable programming, processor(s)1004can provide various functionalities described above. Computer system1000may additionally include a processing acceleration unit1006, which can include a digital signal processor (DSP), a special-purpose processor, and/or the like.

Computer system1000may comprise a storage subsystem1018that comprises software elements, shown as being currently located within a system memory1010. System memory1010may store program instructions that are loadable and executable on processing unit1004, as well as data generated during the execution of these programs.

Storage subsystem1018may also provide a tangible computer-readable storage medium for storing the basic programming and data constructs that provide the functionality of some embodiments. Software (programs, code modules, instructions) that when executed by a processor provide the functionality described above may be stored in storage subsystem1018. These software modules or instructions may be executed by processing unit1004. Storage subsystem1018may also provide a repository for storing data used in accordance with the present disclosure.

Storage subsystem1000may also include a computer-readable storage media reader1020that can further be connected to computer-readable storage media1022. Together and, optionally, in combination with system memory1010, computer-readable storage media1022may comprehensively represent remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing, storing, transmitting, and retrieving computer-readable information.

Communications subsystem1024provides an interface to other computer systems and networks. Communications subsystem1024serves as an interface for receiving data from and transmitting data to other systems from computer system1000. For example, communications subsystem1024may enable computer system1000to connect to one or more devices via the Internet. In some embodiments communications subsystem1024can include radio frequency (RF) transceiver components for accessing wireless voice and/or data networks (e.g., using cellular telephone technology, advanced data network technology, such as 3G, 4G or EDGE (enhanced data rates for global evolution), WiFi (IEEE 802.11 family standards, or other mobile communication technologies, or any combination thereof), global positioning system (GPS) receiver components, and/or other components. In some embodiments communications subsystem1024can provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface.

In some embodiments, communications subsystem1024may also receive input communication in the form of structured and/or unstructured data feeds1026, event streams1028, event updates1030, and the like on behalf of one or more users who may use computer system1000.

Additionally, communications subsystem1024may also be configured to receive data in the form of continuous data streams, which may include event streams1028of real-time events and/or event updates1030, that may be continuous or unbounded in nature with no explicit end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measuring tools (e.g. network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, and the like.

Communications subsystem1024may also be configured to output the structured and/or unstructured data feeds1026, event streams1028, event updates1030, and the like to one or more databases that may be in communication with one or more streaming data source computers coupled to computer system1000.