HTTP Message Broker Architecture for Firewall-Friendly Cloud Device Links

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing message brokers are not well-suited for cloud-based controllers due to increased complexity, resource consumption, and scalability challenges when operating through firewalls, making secure communication between cloud-based controllers and network devices difficult.

Innovation Solution

Implementing a fire and forget message broker that uses a single, persistent HTTP connection with a gRPC proxy or WebSocket tunnel to facilitate communication, ensuring guaranteed delivery and reduced resource usage.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a cloud-based controller is used to manage WiFi networks, then scalability and redundancy are improved, but communication complexity increases due to firewalls interposing between the controller and network devices

Engineering Contradiction:

ImprovescalabilityVSAvoidcommunication complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces a message broker as an intermediary component that runs on the network device itself, acting as a local mediator between the cloud-based controller and the network device applications. This local message broker receives messages from the cloud controller through firewall-traversing protocols (MQTT, HTTP, WebSocket) and delivers them to appropriate applications on the same device, eliminating the need for complex firewall configurations and direct peer-to-peer communication channels.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent implements a lightweight message broker that is copied and run directly on each network device (access point, switch, router) rather than requiring a centralized broker or complex point-to-point connections. This local copy of the message broker functionality enables each device to independently handle its own communication needs with the cloud controller, simplifying the overall system architecture and reducing firewall-related complexity.

Inventive Principle:

Principle #26Copying

2Reliability

If existing message brokers are used in cloud-based controllers, then communication functionality is provided, but resource consumption and complexity increase

Engineering Contradiction:

Improvecommunication functionalityVSAvoidresource consumption

Core Design Contradiction:

ReliabilityVSUse of energy by moving object

Solution Approach 1:

The patent implements an extremely lightweight message broker that consumes minimal computational resources (less than 1% CPU and minimal memory) on network devices with constrained resources. This lightweight implementation uses simple data structures (hash maps for message routing) and efficient algorithms to minimize resource consumption while maintaining reliable communication functionality, making it suitable for resource-constrained IoT devices.

Inventive Principle:

Principle #27Cheap short-living objects (Disposable)

Solution Approach 2:

The message broker is designed to be self-contained and run autonomously on each network device without requiring heavy external support infrastructure. It independently handles message reception, routing, and delivery to local applications, freeing up system resources and reducing the computational burden on the overall network infrastructure.

Inventive Principle:

Principle #25Self-service

3Ease of operation

If traditional communication protocols are used between cloud-based controllers and network devices, then communication is established, but firewall complications and scalability challenges arise

Engineering Contradiction:

Improvecommunication establishmentVSAvoidscalability

Core Design Contradiction:

Ease of operationVSAdaptability or versatility

Solution Approach 1:

The patent segments the communication architecture into two independent parts: (1) a simple, firewall-friendly transport layer using standard protocols like MQTT, HTTP, or WebSocket for communication between the cloud controller and the message broker on network devices, and (2) a local message routing layer that handles application-specific message delivery on each device. This segmentation allows the use of simple, widely-supported protocols for cloud-device communication while maintaining scalable message routing capabilities locally.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The message broker implementation uses universal, firewall-traversing protocols (MQTT, HTTP, WebSocket) that can operate through standard firewall configurations without requiring special port openings or complex security arrangements. This universal protocol support enables the system to scale across diverse network environments and firewall configurations, making the solution adaptable to various deployment scenarios.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Data Source

PatentUS12596597B2HTTP-based message broker architectures for communications between a cloud-based controller and network devices of a wireless communications network and related methods

Publication Date: 2026.04.07 RUCKUS IP HOLDINGS LLC

AI summary

An application of a cloud-based controller forwards a message to a message broker of the cloud-based controller. The message is then transmitted to a network device of a wireless communications network over a WebSocket tunnel connection. Thereafter, an acknowledgment is received in response to transmitting the message at a gRPC proxy for the message broker.