A wireless local area network (WLAN) is a wireless computer network that links two or more devices using a wireless distribution method within a limited area such as a home, school, or an office building. A WLAN can include a number of access points (e.g., wireless routers) that can transmit and receive radio frequencies to and from wireless enabled client devices, such as laptops, desktops, smartphones, and so forth.
The following detailed description references the drawings, wherein:
To facilitate configuration and maintenance of the various access points, a number of access points may be grouped into a cluster, where all access points in the same cluster may communicate with each other and automatically adjust their configuration (e.g., their server set identifier (SSID) configuration) to match the configuration of the other access points. One of the cluster's access points may serve as a master access point and be responsible for performing various networking functions on behalf of other (“slave”) access points in the cluster. In some implementations, when a configuration (e.g., SSID configuration) of the master access point changes, the slave access points may detect the change and automatically update their configurations to match the configuration of the master access point. This may allow the user to update the configuration of the entire cluster of access points by updating the configuration of the master access point, In some implementations, the user may seamlessly add a new access point to the cluster of access points. For example, the user may power up a new access point, which may automatically communicate with the cluster's access points, identify the master access point, and join the cluster.
Each access point may be programmed with code (e.g., software and/or firmware) which, when executed by one or more processors of the access point, may perform various functions of the access point, discussed in more detail below. The code may be of a particular version (e.g., 1.0, 1.2, etc.), and may be updated to a newer version, where the newer version may fix bugs, support new hardware, support new features, and so forth. In some implementations, in order for the cluster function properly, it may be desirable that all access points are programmed with the same code version. Thus, when a new access point programmed with a first code version point joins a cluster of access points programmed with a second code version, it may be desirable that either the new access point be reprogrammed with the second code version or that the existing access points of the cluster be reprogrammed with the first code version.
Sometimes, however, a particular access point may not be reprogrammed with a particular code version, for example, if that code version does not support the hardware of the particular access point. For example, newer models of access points may include new hardware which may not be supported by older code versions, such as code versions below a certain minimum version.
Examples disclosed herein discuss, among other things, an access point programmed with a first code version. The access point may include a communication interface, which may communicate with a second access point programmed with a second code version, and obtain the second code version from the second access point. The access point may further include a code upgrade module, which may determine, based at least on the first code version and the second version, whether the access point is to be upgraded to the second code version. The code upgrade module may also determine, based on a determination that the access point is to be upgraded, whether upgrade of the access point is enabled, and based on a determination that the access point is to be upgraded and that the upgrade of the access point is enabled, reprogram the access point with the second code version, and reboot the access point. The communication interface may also send to the second access point a command to change configuration of the second access point.
Access point may also include a memory (not shown for brevity) that may include any combination of volatile and non-volatile memories of any types. For example, the memory may include any combination of random-access memories (RAMS), flash memories, hard drives, memristor-based memories, and the like. In some implementation, the memory may store code (e.g., firmware, software, etc.) that may include a set of instructions, which, when executed by a processor of access point 100 (not shown in
The example of
In some implementations, when new access point 100D is powered up and is connected to cluster 200 (e.g., wirelessly or via a wired connection such as LAN), it may communicate with some or all access points 100 within cluster 200, and may determine based on the communications (e.g., based on a communication from communication interface 110A of access point 100A) that access point 100A is the master access point of the cluster.
Similarly, master access point 100A may detect communications from new access point 100D and determine that new access point 100D is currently not a part of cluster 200. In some implementations, master access point 100A may then communicate with new access point 100D (e.g., via communication interface 110A and communication interface 110D) to determine whether and how new access point 100D can be added to the cluster. As part of these communications, master access point 100A may request and obtain from new access point 100D its current code version, i.e., the version of code with which new access point 100D is currently programmed.
Master access point 100A may then determine, e.g., using code upgrade module 120A, whether the code versions of at least one of access points 100A, 100B, 100C, or 100D need to be updated, i.e., upgraded to a newer version or downgraded to an older version. As discussed above, in some implementations, for the cluster to function properly, all access points within a cluster may need to have the same code version. Accordingly, in such implementations, new access point 100D may be added to the cluster if its code version can match the code versions of all access points within the cluster.
Specifically, code upgrade module 120A of master access point 100A may determine whether the code version of master access point 100A needs to be upgraded. To make this determination, in some implementations module 120A may determine whether the code version of new access point 100D is greater than the code version of master access point 100A (and therefore is also greater than the code versions of other access points in the cluster having the same code version as the master access point). In some implementations, based on a determination that the code version of new access point 100D is greater (i.e., newer) than the code version of master access point 100A, module 120A may determine that the upgrade of master access point 100A is needed. In other implementations, module 120A may determine that the upgrade is needed based also on a determination that new access point 100D cannot be downgraded to the code version of master access point 100A, e.g., if new access point 100D is a newer model having new hardware that is not supported by the older code version of master access point 100A. Module 120 may make this additional determination, for example, by inquiring new access point 100D about the minimal code version supported by it.
If module 120A determines that the code version of master access point 100A is to be upgraded, module 120A may then determine whether the upgrade is possible or “enabled.” In some implementations, determining whether the upgrade is enabled may include determining whether code (e.g., software and/or firmware) corresponding to the code version of new access point 100D is available, e.g., whether the code can be downloaded to master access point 100A from another device, such as server 220. Thus, in some implementations, code upgrade module 120A may instruct (e.g., communication interface 110A) that the code be downloaded, after which module 120A may determine that the upgrade is enabled based on a determination that the code was successfully downloaded to master access point 100A and stored in its memory.
Alternatively or in addition, determining whether the upgrade is enabled may include determining whether a user-configurable setting indicates that the upgrade of the access point is allowed. That is, the user may configure a setting that indicates whether the master access point (e.g., 100A) is to upgrade its code version when a new access point (e.g., 100D) having a higher code version is joining the cluster. In such a case, code upgrade module 120A may determine that the upgrade is enabled only if the setting allows it.
Alternatively or in addition, determining whether the upgrade is enabled may include determining whether at least one access point in the cluster (e.g., 100A, 100B, or 100C) cannot be upgraded to the code version of new access point 100D, for example, because it does not support upgrades at all, or because it does not support the newer code version (e.g., if the newer code version is not backward compatible and does not support some older access point models).
If code upgrade module 120A determines that master access point 100A is to be upgraded and that the upgrade is enabled, code upgrade module 120A may reprogram master access point 100A with new code corresponding to the code version of new access point 100D. The reprogramming may include, for example, downloading the code from code database 230 stored on server 220, and replacing (e.g., rewriting) the existing code stored in the memory of master access point 100A with the downloaded code. After replacing the code, to complete the reprogramming, code upgrade module 120A may cause master access point 100A to reboot. After rebooting, master access point 100A may automatically run the new version of code, i.e., the same code that runs on new access point 100D. In some implementations, reprogramming and rebooting master access point 100A may not change the configuration (e.g., the SSID configuration) of master access point 100A.
In some examples, during or after the reprogramming of master access point 100A, any access point in cluster 200 (e.g., 100B and/or 100C) may determine, based on communications with master access point 100A, that the code version of master access point 100A is changing or has already changed to a version different from the code version of the access point. In such a case, the access point may obtain the new code version (e.g., from master access point 100A or from server 220), reprogram itself with the new code version (e.g., by storing the new code in its respective memory), and reboot,
In some implementations, after at least one access points 100 in cluster 200 is rebooted, access points 100 may collectively or individually perform the master election process, during which a new access point may be elected as the master access point. Electing a new master access point within the cluster may not change the master configuration associated because, for example, all access points within the cluster automatically copy the configuration of the currently elected master access point (e.g., 100A). However, if new access point 100D is elected as the new master access point (e.g., during the election process performed after master access point 100A is rebooted), its configuration may be different from the previous master configuration.
To avoid this undesirable scenario, in some implementations, before rebooting the access point (e.g., before, after, or during reprogramming the access point), communication interface 110A may send to new access point 100D a command to change the configuration of new access point 100D and thereby prevent modification of the master configuration. In some implementations, the command may include a command (or a number of commands) causing new access point 100D to copy the configuration of master access point 100A. Thus, even if new access point 100D is elected as the new master access point, the master configuration will be preserved. In other implementations, the command sent to new access point 100D may include a command (or a number of commands) causing new access point 100D to reset to default factory settings. In those implementations, the master election process may be configured not to elect an access point having default factory settings as the master access point. Thus, new access point 100D, after being reset to factory settings may not be elected as the new master access point and thereby change the master configuration.
As discussed above, communication interface 110A and code upgrade module 120 may each be implemented as any combination of hardware and programming. For example, the programming may include processor-executable instructions stored on a tangible, non-transitory computer-readable medium, and the hardware may include a processing resource for executing those instructions. The processing resource, for example, may include one or multiple processors (e.g., central processing units (CPUs), semiconductor-based microprocessors, graphics processing units (GPUs), field-programmable gate arrays (FPGAs) configured to retrieve and execute instructions, or other electronic circuitry), which may be integrated in a single device or distributed across devices. The computer-readable medium can be said to store program instructions that when executed by the processor resource implement the functionality of the respective component. The computer-readable medium may be integrated in the same device as the processor resource or it may be separate but accessible to that device and the processor resource. In one example, the program instructions can be part of an installation package that when installed can be executed by the processor resource to implement the corresponding component. In this case, the computer-readable medium may be a portable medium such as a CD, DVD, or flash drive or a memory maintained by a server from which the installation package can be downloaded and installed. In another example, the program instructions may be part of an application or applications already installed, and the computer-readable medium may include integrated memory such as a hard drive, solid state drive, or the like. In another example, the engines may be implemented by hardware logic in the form of electronic circuitry, such as application specific integrated circuits.
At block 310, the method may detect (e.g., by a master access point of a cluster of access points) a new access point (AP) programmed with a second code version, where the master access point is programmed with a first code version that is older than the second code version. At block 320, the method may determine whether the master access point can be reprogrammed with the second code version, i.e., where upgrade of the master access point is enabled, as discussed above. At block 330, the method may, based on a determination that the master access point can be reprogrammed with the second code version, reprogram the master access point with the second code version. At block 340, the method may send to the new access point a command to change configuration of the new access point, where the communication may include, for example, a command to reset the new access point's configuration to default factory settings, or a command to set the new access point's configuration in accordance with (e.g., to match) the master access point's configuration. At block 350, the method may reboot the master access point, causing the master access point to run the second code version after the reboot.
Processor 410 may be one or more central processing units (CPUs), microprocessors, and/or other hardware devices suitable for retrieval and execution of instructions stored in non-transitory machine-readable storage medium 420. In the particular example shown in
Non-transitory machine-readable storage medium 420 may be any electronic, magnetic, optical, or other physical storage device that stores executable instructions. Thus, medium 420 may be, for example, Random Access Memory (RAM), an Electrically-Erasable Programmable Read-Only Memory (EEPROM), a storage drive, an optical disc, and the like. Medium 420 may be disposed within computing device 400, as shown in
Referring to
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/US2015/064108 | 12/4/2015 | WO | 00 |