Patent ID: 12200039

Like reference numerals refer to corresponding parts throughout the drawings. Moreover, multiple instances of the same part may be designated by a common prefix separated from an instance number by a dash.

DETAILED DESCRIPTION OF THE EMBODIMENTS

A plurality of different software applications typically are present on a network device (e.g., an access point, a switch, etc.) of a WiFi network, and each of these applications may need to communicate with a controller of the WiFi network. In a WiFi network having an on-premise controller, the network devices typically communicate with the controller over secure wired connections that are behind the customer firewall, making communication relatively simple. However, when a cloud-based controller is used, communications typically must be transmitted over public networks and through firewalls, which can be much more complex and challenging.

One way to provide secure communications between a cloud-based controller and a network device of a WiFi network is to establish a secure tunnel such as, for example, a secure shell (“SSH”) tunnel, between the cloud-based controller and the network device for each application service running on the cloud-based controller that communicates with the network device. Commands, notifications and other messages generated by the applications services running on the cloud-based controller are transmitted to corresponding applications running on the network device over the appropriate respective SSH tunnels. Unfortunately, this approach may use significant network resources (e.g., ports), requires complex port forwarding rules, and firewalls interposed between the cloud-based controller and the network device may further complicate the implementation. As a result, scaling such a system may be difficult. Thus, establishing separate secure tunnels between each application service and the corresponding applications running on the network device may be less than an ideal solution.

So-called “message brokers” are known in the art which can consolidate communications between one or more applications that are running on a first device and one or more applications that are running on a second device, so that the communications can be exchanged between the first and second devices over a single network connection rather than a plurality of separate connections. A message broker is a software application that performs communications between, for example, a device and a server, by translating the messages from the messaging protocol of the sending device to the messaging protocol of the receiving device. A message broker may include multiple queues, buffers or partitions (referred to herein collectively as “queues”), and the messages may be assigned to the queues based at least in part on the destination address of each message. A message broker may receive messages from multiple sources such as various applications on the sending device (which are often referred to as “producers”) and may forward the received messages to multiple destinations such as various applications on the receiving device (which are often referred to as “consumers”). There is at least a one-to-one relationship between a given queue and a given consumer on the receive device. The applications running on the sending device forward each message to the appropriate queues of the message broker, and the message broker then forwards the messages in the queues to the respective applications running on the receiving device. In addition to allowing communication between multiple producers and/or consumers over a single connection, message brokers can provide guaranteed message delivery. In particular, if a message fails to reach a consumer (e.g., because the consumer is offline), the message broker will continue to resend the message until the consumer acknowledges receipt thereof. Examples of commercially available message brokers are Kafka (from the Apache Software Foundation) and MQTT (from mqtt.org).

Unfortunately, most commercially available message brokers are not well-suited for use with cloud-based controllers. For example, many commercially available message brokers employ protocols that open multiple ports at the same time which increases complexity and consumes additional network resources. Message brokers may also lose functionality when operating through firewalls, may require that significant processing and/or memory resources be available on the network devices, and/or may not be readily scalable. For these reasons, existing message broker solutions cannot be readily used for cloud-based controller applications without significant negative effects.

A cloud-based controller for a WiFi network will typically have at least two front end devices for communicating with applications on the controlled network devices. The first device is a hypertext transfer protocol (“HTTP”) ingress controller. The HTTP ingress controller forwards communications to the network devices over respective persistent, HTTP-based network connections, and may act as a reverse proxy (i.e., a virtual address) that network devices may forward information to (e.g., commands, data, etc.). The ingress controller can also act as a load balancer that balances the incoming communications/requests from the network devices by distributing the requests across multiple components (e.g., servers) of the cloud-based controller, which improves scalability. Typically, the network devices will have default ports for HTTP and HTTPS communications. As such, it typically is not necessary to configure a customer firewall when an HTTP based message broker is used. This may be a significant advantage favoring use of HTTP-based message brokers. Unfortunately, however, most commercially available message brokers are not HTTP-based, and the ones that are (e.g., Kafka) may be overly complex or lose functionality when operating through customer firewalls.

The second front end device of a cloud-based controller is a layer 3 Internet Protocol (“IP”) based load balancer which performs similar functions to the ingress controller with respect to layer 3 IP traffic. However, it may be difficult to use commercially available message brokers with a layer 3 IP based load balancer because end users of the WiFi network are often unwilling to open specific port numbers on their firewall.

Pursuant to embodiments of the present invention, techniques are provided for exchanging messages between a cloud-based controller and the network devices of a wireless communications network (e.g., a WiFi network). These techniques may ensure guaranteed delivery of messages, avoid issues with firewalls that are interposed between the cloud-based controller and the network devices, utilize relatively few network resources, require only limited processing and memory resources on the network devices, and may be highly scalable.

In a first embodiment, the cloud-based controller includes a message broker that may be configured to receive messages from a plurality of different sources (e.g., application services running on the cloud-based controller) and forward those messages to a network device over a single, bidirectional, persistent HTTP connection. The message broker may be a “fire and forget” message broker that does not include any mechanism for determining whether the messages forwarded from the message broker are received at their intended destinations. The cloud-based controller may further include a gRPC proxy (or other RPC proxy) for the message broker. The gRPC proxy may receive messages from the message broker before they are transmitted from the cloud-based controller and may receive acknowledgments from the network device. Thus, the gRPC proxy may ensure that messages from the message broker are reliably delivered. The gRPC proxy may forward messages received from the message broker to an ingress controller of the cloud-based controller that forwards the messages to a network device over a single, persistent HTTP-based connection.

The messages from the cloud-based controller are received by a gRPC agent running on the network device. The gRPC agent (or other RPC agent) acts as an acknowledgment generator, and thus returns an acknowledgment over the HTTP-based connection for each message received, and these acknowledgments are passed to the gRPC proxy on the cloud-based controller (which acts as an acknowledgment receiver) so that confirmation is provided as to the delivery status of each message. The gRPC agent running on the network device forwards the received messages to an embedded message broker running on the network device. The embedded message broker stores each received message in an appropriate queue (e.g., a queue associated with the application to which the message is addressed) and forwards the messages to the appropriate application running on the network device. Messages may similarly be sent from the applications running on the network device to the cloud-based controller in the exact same fashion, with the embedded message broker collecting the messages from the applications and the gRPC agent on the network device forwarding the messages over the persistent HTTP-based tunnel and also acting as an acknowledgment receiver. On the cloud-based controller, the received messages are passed to the gRPC proxy, which acts as an acknowledgment generator (to confirm to the network device that the messages were received) and which forwards the received messages to the message broker on the cloud-based controller for distribution to the application services. The applications running on the cloud-based controller and/or on the network device may optionally provide acknowledgments directly to the applications on the other device with which they communicate via a call-back URL procedure, as will be explained in greater detail herein.

In a second embodiment, the cloud-based controller may again include a fire and forget message broker that may be configured to receive messages from a plurality of different sources (e.g., application services running on the cloud-based controller) and forward those messages to a network device over a single, bidirectional, persistent HTTP connection. In this embodiment, however, the HTTP-based connection may be implemented as a WebSocket tunnel. The message broker may forward messages received from the cloud services to a WebSocket server, and the WebSocket server forwards the messages to an ingress controller of the cloud-based controller for transmission to a WebSocket client provided on the network device.

The WebSocket client receives the messages and forwards them to a message broker client library on the network device. The message broker client library passes the messages to a message handler which forwards the messages to the appropriate applications on the network device. The message broker client library may also generate acknowledgments in response to each message that are transmitted to the cloud-based controller over the WebSocket tunnel, where they are passed back to the cloud services. Messages may likewise be sent from the applications running on the network device to the cloud-based controller in the same fashion, with the message broker client library collecting the messages from the applications and passing them to the WebSocket client for transmission to the cloud-based controller over the WebSocket tunnel. The second embodiment may be appropriate for network devices that may not have sufficient resources to support a gRPC agent.

The techniques for exchanging messages between a cloud-based controller and the network devices of a WiFi network that are disclosed herein use a message broker to simplify having multiple cloud-based services communicate with the network devices while also providing benefits in terms of scalability and load balancing. The embodiments disclosed herein may use persistent bidirectional HTTP connections between the cloud-based controller and each network device, which allows the ingress controller of the cloud-based controller to perform load balancing. Moreover, since a single, persistent, bidirectional HTTP connection is used between the cloud-based controller and each network device, the communication technique may use less network resources than other approaches, and/or may require less resources on each network device. The use of the HTTP connection also makes it easier to operate through firewalls, and may avoid the loss in flexibility that some message brokers experience when operating, for example, through customer firewalls.

Embodiments of the present invention are described in further detail below with reference to the figures.

FIG.1is a block diagram illustrating a simplified WiFi network100in which the communications techniques according to embodiments of the present invention may be used. As shown inFIG.1, the WiFi network100may include one or more access points110, one or more client devices120(such as cellular telephones, computers, tablets, printers and a wide range of other WiFi-capable electronic devices), and one or more cloud-based controllers140. Each access point110may include one or more radios112that operate, for example, in the 2.4 GHz frequency band, the 5 GHz frequency band, and/or the 6 GHz frequency band. The client devices120may also include one or more client radios122that operate in the 2.4 GHz, 5 GHz and/or 6 GHz frequency bands. Only a single radio112,122is shown in each access point110and client device120for simplicity, but it will be appreciated that many access points110and client devices120are capable of operating in multiple different frequency bands.

The access points110and the client devices120may communicate with each other via wireless communication that is compatible with an IEEE 802.11 standard. For example, a client device (e.g., client device120-1) may associate with a particular access point (e.g., access point110-1). The client device120-1may communicate with other client devices120and/or with external networks150via the access point110-1. In order for a client device120to associate with an access point110, the access point110and the client device120can transmit advertising frames on wireless channels, detect one another by scanning the wireless channels, exchange data/management frames (such as association requests and responses) to establish a connection and configure security options (e.g., Internet Protocol Security). Once the association is completed, the client device120can wirelessly communicate over the WiFi network100by transmitting and receiving frames or packets via the wireless connection to the access point110. The wireless signals114that are transmitted from the access points110to the client devices120and the wireless signals124that are transmitted from the client devices120to the access points110are illustrated inFIG.1via jagged lines.

WiFi network100may further include a switch network130that includes one or more network switches and/or routers132. As an example, a network switch132-1may include a number of communication interfaces or ports (not shown) that are connected to various of the network devices. During operation, a first of the communication interfaces may receive a packet or other data container from a first electronic device (e.g., a client device120, an access point110, another network switch132, etc.). The packet may then be processed and forwarded to a second port associated with a second electronic device. The network switch and/or router132may be a layer-2 or layer-3 network switch or router. The switch network130, and the network switches132thereof, may be coupled to access points110of the wireless network102via wired links134.

The access points110and the switches/routers132may be connected to an external network150. The network150may comprise, for example, the Internet, an intra-net and/or one or more dedicated communication links. The network150may be separated from the switch network130and the access points110by a firewall160, which may monitor network traffic that is incoming to and outgoing from the switch network130and decide whether to permit or prohibit various traffic based on one or more security rules. The access points110may provide the client devices120access to the network150. It will be appreciated that some access points110may only be connected to the network150through other access points110(e.g., in a mesh network implementation).

The WiFi network100further includes one or more cloud-based controllers140that are deployed at one or more locations that may be relatively remote from the access points110and/or the switch network130. The cloud-based controllers140may communicate with the network switches132and the access points110via, for example, the network150. The cloud-based controllers140may perform configuration operations and/or management operations that control functionality of the network devices of the WiFi network100such as the access points110and the switches and routers132. For example, the cloud-based controllers140may define flow definitions comprising packet processing rules and corresponding actions and promulgate these rules to the network switches132of the switch network130. As another example, the cloud-based controller140may manage the access points110, for example by providing various configuration information, controlling settings, routing information, collecting statistics, providing authorization/authentication information and the like. The cloud-based controller140may communicate with the access point110and/or network switches132via one or more logical links142, which in some embodiments may at least partially overlap the wired links134.

As described in further detail below with reference toFIG.7, the access points110, client devices120and/or the cloud-based controllers140may include subsystems, such as a networking subsystem, a memory subsystem and a processor subsystem.

FIG.2is a block diagram illustrating an architecture for exchanging messages between a cloud-based controller200and a network device250according to certain embodiments of the present invention.

As shown inFIG.2, a cloud-based controller200includes a plurality of application services210, a message broker220, a gRPC proxy230and an ingress controller240. The services210may comprise a plurality of applications running on the cloud-based controller200that communicate with the network device250. The network device250is a device that is part of a wireless communications network (e.g., WiFi network100ofFIG.1). The network device250may comprise, for example, an access point, a switch, a data plane, a router or the like. The network device250includes a gRPC agent260, an embedded message broker270, and a plurality of applications280that run on the network device250that communicate with the cloud-based controller200. While only a single network device250is shown inFIG.2for simplicity, it will be appreciated that the cloud-based controller200may be in communication with a large number of different network devices250.

As shown inFIG.2, the services210running on the cloud-based controller200may need to send notifications, commands or the like to the network device250. Messages comprising such notifications and/or commands are passed from the various services210to the message broker220. Herein, references to “messages” refer to the information that is exchanged between the application services210of the cloud-based controller200and the applications280of the network device250. These messages may comprise at least part of a “payload” of one or more larger transmissions that are used to pass the messages between the application services210of the cloud-based controller200and the applications280of the network device250through one or more intermediate elements. As is further shown inFIG.2, the message broker220may include a plurality of queues222. The messages forwarded by the services210may, for example, be directed to particular queues222based on the intended recipient(s) of the message(s). The message broker220may, for example, comprise software that translates a message from a messaging protocol of the sender (e.g., one of the services210) to the messaging protocol of the intended recipient (e.g., one of the applications280on the network device250). The message broker220takes the messages received from the plurality of different services210and outputs these messages to the gRPC proxy230. The gRPC proxy230may comprise a software application that allows an application or device to communicate with an application running on an external device as if the external application were a local object.

In addition, the gRPC proxy230may operate as an acknowledgment receiver to ensure that messages sent from the cloud-based controller200are received by the network device250. The message broker220may thus guarantee reliable delivery.

The gRPC proxy230may forward each message received from the message broker220to the ingress controller240. The ingress controller240establishes a single, bidirectional, persistent HTTP-based connection245with the network device250. The network device250may have default ports for HTTP and HTTPS traffic and hence by using an HTTP connection245between the cloud-based controller200and the network device250the need to configure a firewall that may be positioned between the cloud-based controller200and the network device250(e.g., a firewall of the organization deploying the WiFi network that the network device250is part of) may be eliminated. The need for opening additional ports for the connection may also be eliminated. Thus, by providing a gRPC-over-HTTP connection between the cloud-based controller200and the network device250, the number of network resources consumed and the complexity of the connection can be reduced. This acts to improve scalability.

Still referring toFIG.2, messages forwarded by the ingress controller240over the HTTP connection245are received at the gRPC agent260of the network device250. The gRPC agent260is a counterpart to the gRPC proxy230that allows the network device250to appear as a local object to the cloud-based controller200. The gRPC agent260also generates acknowledgments in response to each received message, and the acknowledgments are forwarded back to the ingress controller240of the cloud-based controller200over the HTTP connection245. The ingress controller240forwards the acknowledgments to the gRPC proxy230. If an acknowledgment is not received for a particular message within a specified time period, the gRPC proxy230may resend the message to guarantee that the messages received from the message broker220are all properly delivered to the network device250. The gRPC agent260on the network device250forwards each received message to the embedded message broker270, and each message is mapped to an appropriate queue272based on the particular application280the message is addressed to. The embedded message broker270then passes each received message from the queues272to the appropriate applications280.

The applications280may also generate messages that are passed to the cloud-based controller200, such as data, status messages, event notifications and the like. These messages are passed from the applications280to the embedded message broker270, where they are routed to appropriate queues272within the message broker270based on the intended recipients (e.g., the different services210on the cloud-based controller200) of the messages. The embedded message broker270forwards these messages to the gRPC agent260. The gRPC agent260transmits the messages over the single, persistent, bidirectional HTTP connection245to the ingress controller240of the cloud-based controller200. The ingress controller240may perform load balancing with respect to messages received from network device250(and from other devices communicating with the services210), and thus may facilitate scalability for the cloud-based controller200. The ingress controller240passes the received messages to the gRPC proxy230, which forwards the messages to the message broker220where they are routed to appropriate queues222. The gRPC proxy230also generates an acknowledgment for each received message that is passed to the ingress controller240for transmission to the gRPC agent260of the network device250over the HTTP connection245. The message broker220then passes the messages from the network device250to the appropriate services210. The messages may be routed to the appropriate services210based on uniform resource locators (“URLs”) for the different services210that are included in the messages.

As is further shown inFIG.2, a so-called “callback URL” may be used as an alternative (or additional) technique for each service210to confirm that messages it sends to the network device250have in fact been received by the network device250. The callback URL is an object that is embedded in a message sent by one of the services210that includes the URL for the particular service210. When the application280to which the message is addressed reads the message, an application programming interface may generate, for example, both an acknowledgment and a result of execution of the command or other request that are routed to the ingress controller240via a separate path (e.g., through a path/ap/callback/traceroute/{app serial number}). The acknowledgment includes the URL for the service210that sent the original message, and the ingress controller240routes the acknowledgment to the service210. The callback URL may be used, for example, with respect to messages having lower importance. For example, an access point might acknowledge a command from the cloud-based controller200instructing the access point to illuminate an LED thereof via a call-back URL acknowledgment. For more important commands (e.g., commands relating to troubleshooting), the acknowledgments may be sent through the above-described primary path for acknowledgments.

FIG.3Ais a flow chart diagram illustrating a method for a cloud-based controller to communicate with a network device of a wireless communications network. As shown inFIG.3A, operations may begin with an application service of the cloud-based controller forwarding a message to a message broker of the cloud-based controller (operation200). The message may thereafter be transmitted from the cloud-based controller to the network device over a persistent HTTP connection (operation215). Thereafter, a gRPC proxy of the cloud-based controller may receive an acknowledgment that the message was received at the network device (operation230).

FIG.3Bis a flow chart diagram illustrating further details of one possible implementation of the method ofFIG.3A. As shown inFIG.3B, operations may again begin with an application service of the cloud-based controller forwarding a message to a message broker for the cloud-based controller (operation200). The message may be stored in a queue within the message broker. The message broker may appropriately reformat the message and then forward the reformatted message to a gRPC proxy of the cloud-based controller (operation205). The gRPC proxy may, in turn, forward the reformatted message to an ingress controller of the cloud-based controller (operation210). Then, as discussed above with respect toFIG.3A, the ingress controller may transmit the message to the network device over a persistent HTTP connection between the cloud-based controller and the network device (operation215).

The gRPC agent of the network device may receive the message (operation220). In response, the gRPC agent may generate an acknowledgment message that is forwarded over the persistent HTTP connection to the ingress controller of the cloud-based controller (operation225). The ingress controller passes the acknowledgment to the gRPC proxy (operation230). The gRPC proxy may then discard the original message (since it now knows that the message was received). As is further shown inFIG.3B, in response to receiving the message, the gRPC agent (in addition to generating the acknowledgment) may pass the message to the embedded message broker, where the message is routed to an appropriate queue (operation235). The embedded message broker may then forward the message to the appropriate application (operation240).

FIG.4Ais a flow chart diagram illustrating a method for a network device of a wireless communications network to communicate with a cloud-based controller according to further embodiments of the present invention. As shown inFIG.4A, a message generated by an application service of the cloud-based controller is received at the network device (operation300). The message is passed to an application that is installed on the network device based on an address contained in the message (operation310). The application then extracts a callback URL from the message (operation315). The application may then transmit an acknowledgment addressed to a service running on the cloud-based controller in response to receiving the message (operation330). The acknowledgment may be transmitted to the ingress controller of the cloud-based controller, and the ingress controller may forward the acknowledgment directly to the application service that sent the original message based on a URL contained within the acknowledgment. This acknowledgment is not received at the message broker.

FIG.4Bis a flow chart diagram illustrating more details of an example implementation of the method ofFIG.4A. As shown inFIG.4B, a message generated by an application service of the cloud-based controller is received at the network device (operation300). The message may be received at a gRPC agent of the network device and may be generated and forwarded to the gRPC agent in the manner discussed above with reference to operations200,205,210,215and220ofFIG.3B. The message may then be pushed from the gRPC agent to an embedded message broker of the network device (operation305). The message is passed to an application that is installed on the network device based on an address contained in the message (operation310).

The application extracts a callback URL from the message (operation315). The application may then transmit an acknowledgment addressed to a service running on the cloud-based controller to the ingress controller of the cloud-based controller (operation320). The acknowledgment may be transmitted, for example, over a path/ap/callback/traceroute/{app serial number}. The ingress controller may then forward the acknowledgment directly to the application service that sent the original message based on a URL contained within the acknowledgment (operation325).

Some network devices may only have limited memory and/or processing capabilities. These devices may not have sufficient resources to run gRPC and/or an embedded message broker. For example, some inexpensive access points may have limited memory. With these devices, there may not be sufficient resources to communicate with a cloud-based controller using the techniques discussed above with reference toFIGS.2-4B.

FIG.5is a block diagram illustrating an architecture for exchanging messages between a cloud-based controller400and a network device450according to further embodiments of the present invention. The architecture shown inFIG.5may require less resources within the network device450as compared to the architecture shown inFIG.2.

As shown inFIG.5, the cloud-based controller400includes a plurality of services410, a message broker420, a WebSocket server430and an ingress controller440. The services410may comprise a plurality of applications running on the cloud-based controller400that communicate with the network device450. The network device450is a device that is part of the wireless communications (e.g., WiFi) network such as access point, a switch, a data plane, a router or the like. The network device450includes a WebSocket client460and a plurality of applications470that run on the network device450that communicate with the cloud-based controller400.

As shown inFIG.5, the application services410running on the cloud-based controller400may need to send notifications, commands and/or other information to the network device450. Messages containing such notifications and/or commands are passed from the various services410to the message broker420, where the messages are stored in queues422based on the intended recipients of the messages. The message broker420may, for example, be identical to the message broker220discussed above with reference toFIG.2. The message broker420passes the received messages to the WebSocket server430. The WebSocket server430may comprise a server that acts as a middleman to securely route communications through firewalls using secure socket layer (“SSL”) certificates. WebSocket is also HTTP-based and hence this approach again allows communications between the application services410of the cloud-based controller400and applications470running on a network device450to be routed over a single, persistent, bidirectional HTTP-based connection. The WebSocket server430forwards the messages to the ingress controller440for transmission over the WebSocket tunnel445that is formed between the cloud-based controller400and the network device450.

The WebSocket client460on network device450is at the other end of the WebSocket tunnel445and receives the messages from the cloud-based controller400. The applications470included on the client device450include a message broker client library472. The messages are passed from the WebSocket client460to the message broker client library472. The message broker client library472may be a counterpart to message broker420. The payload in the transmission over the WebSocket tunnel is or includes the original message generated by the application service410running on the cloud-based controller400. The WebSocket client460can extract the payload (including the message) and forward it to the message broker client library472as shown by the heading “packet forwarding” inFIG.5. Upon receipt of a message, the message broker client library472generates an acknowledgment which is passed to the WebSocket client460and transmitted back to the message broker through the WebSocket tunnel445, ingress controller440and WebSocket server430. The message broker410may then forward the acknowledgment to the service410that generated the original message. If an acknowledgment is not received for a particular message within a specified time period, the service410that generated the original message may resend the message to guarantee that the message is properly delivered to the network device250. Since the message broker client library472provides acknowledgments, the message broker420may be implemented as a simple “fire and forget” message broker. The message broker client library472may then pass the message to a message handler474. It will be understood that both the message broker client library472and the message handler474are part of an application470. The message handler474is a component of the application470that executes the message (e.g., responds to the message). For example, if the message is a “trace route” command, the message handler can execute that command and return the result to an application service410running on the cloud-based controller400via, for example, a callback URL.

The applications470running of the network device450may also generate messages that are passed to the cloud-based controller400, such as data, status messages, event notifications and the like. These messages are passed from the applications470to the message handler474, where they are routed to the message broker client library472. The message broker client library472forwards these messages to the WebSocket client460. The WebSocket client460transmits the messages over the WebSocket tunnel445to the ingress controller440of the cloud-based controller400. The ingress controller440may perform load balancing with respect to messages received from network device450(and from other devices communicating with the services410), and thus may facilitate scalability for the cloud-based controller400. The ingress controller440passes the received messages to the WebSocket server430, which forwards the messages to the message broker420where they are routed to appropriate queues422. The message broker420then passes the messages from the network device450to the appropriate services410. For return messages there may be no acknowledgments.

As is further shown inFIG.5, an optional “callback URL” may be used as an alternative (or additional) technique for each service410to confirm that messages it sends to the network device450have in fact been received by the network device450. The callback URL may be implemented in the same manner as discussed above with reference toFIG.2, and hence further description thereof will be omitted here.

FIG.6Ais a flow chart diagram illustrating a method for a cloud-based controller to communicate with a network device of a wireless communications network according to embodiments of the present invention. As shown inFIG.6A, operations may begin with an application service of the cloud-based controller forwarding a message to a message broker for the cloud-based controller (operation500). The message may thereafter be transmitted from the cloud-based controller to the network device over a WebSocket tunnel (operation515). Thereafter, an acknowledgment may be received at the application service of the cloud-based controller acknowledging that the message was received at the network device (operation540).

FIG.6Bis a flow chart diagram illustrating further details of one possible implementation of the method ofFIG.6A. As shown inFIG.6B, operations may again begin with an application service of the cloud-based controller forwarding a message to a message broker for the cloud-based controller (operation500). The message may be stored in a queue within the message broker. The message broker may appropriately reformat the message and then forward the reformatted message to a WebSocket server of the cloud-based controller (operation505). The WebSocket server may, in turn, forward the reformatted message to an ingress controller of the cloud-based controller (operation510). The ingress controller may transmit the message to the network device over a WebSocket tunnel between the cloud-based controller and the network device (operation515).

A WebSocket client of the network device may receive the message (operation520). The WebSocket client may pass the message to a message broker client library, which is an application running on the network device (operation525). The message broker client library may generate an acknowledgment message that is forwarded over the WebSocket tunnel to the ingress controller of the cloud-based controller (operation530). The ingress controller passes the acknowledgment to the application service of the cloud-based controller that sent the message via the WebSocket tunnel and the message broker of the cloud-based controller (operation535). The message broker client library may also route the message to the appropriate application of the network device (operation540).

FIG.7is a block diagram illustrating an electronic device600in accordance with some embodiments. The electronic device may comprise, for example, a client device, an access point or a controller. The electronic device600includes a processing subsystem610, a memory subsystem612, and a networking subsystem614. Processing subsystem610includes one or more circuit elements that are configured to perform computational operations. Memory subsystem612includes one or more circuit elements for storing data and/or instructions. In some embodiments, the instructions may include an operating system and one or more program modules which may be executed by processing subsystem610.

Networking subsystem614includes one or more circuit elements that are configured to couple to and communicate on a wired and/or wireless network (i.e., to perform network operations), including: control logic616, an interface circuit618and one or more radiating elements620. Thus, electronic device600may or may not include the one or more radiating elements620. Networking subsystem614includes at least a networking system based on the standards described in IEEE 802.11 (e.g., a Wi-Fi networking system).

Networking subsystem614includes processors, controllers, radios/radiating elements, sockets/plugs, and/or other devices used for coupling to, communicating on, and handling data and events for each supported networking system. Note that mechanisms used for coupling to, communicating on, and handling data and events on the network for each network system are sometimes collectively referred to as a “network interface” for the network system. Electronic device600may use the mechanisms in networking subsystem614for performing simple wireless communication, e.g., transmitting frames and/or scanning for frames transmitted by other electronic devices.

Processing subsystem610, memory subsystem612, and networking subsystem614are coupled together using bus628. Bus628may include an electrical, optical, and/or electro-optical connection that the subsystems can use to communicate commands and data among one another.

The operations performed in the communication techniques according to embodiments of the present invention may be implemented in hardware or software, and in a wide variety of configurations and architectures. For example, at least some of the operations in the communication techniques may be implemented using program instructions622, operating system624(such as a driver for interface circuit618) or in firmware in interface circuit618. Alternatively or additionally, at least some of the operations in the communication techniques may be implemented in a physical layer, such as hardware in interface circuit618.

Embodiments of the present invention have been described above with reference to the accompanying drawings, in which embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout.

It will be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element, without departing from the scope of the present invention. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.

It will be understood that when an element is referred to as being “connected” or “coupled” to another element, it can be directly connected or coupled to the other element or intervening elements may be present. In contrast, when an element is referred to as being “directly connected” or “directly coupled” to another element, there are no intervening elements present. Other words used to describe the relationship between elements should be interpreted in a like fashion (i.e., “between” versus “directly between”, “adjacent” versus “directly adjacent”, etc.).

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” “comprising,” “includes” and/or “including” when used herein, specify the presence of stated features, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, operations, elements, components, and/or groups thereof.

Aspects and elements of all of the embodiments disclosed above can be combined in any way and/or combination with aspects or elements of other embodiments to provide a plurality of additional embodiments.