## 4 Proposed Architecture
### Local MQTT Broker  
In the proposed architecture, a locally deployed MQTT broker is utilized as an intermediate security and routing layer within the hospital network. This broker, implemented using the Eclipse Mosquito platform, runs on a dedicated edge server or embedded device such as a Raspberry Pi. Its primary role is to receive data from resource-constrained IoT publishers--such as wearable or diagnostic devices--which encrypt the data payload using lightweight cryptographic algorithms (e.g., Salsa20-Blake2b). The local broker functions in conjunction with a custom-built bridge application that acts as a security gateway. The bridge application subscribes to the local broker and is responsible for decrypting incoming lightweight-encrypted messages and re-encrypting the payload using AES-256 before forwarding them to the cloud-based MQTT broker over a TLS 1.3 channel. Resource efficiency is prioritized at the edge, and stronger cryptographic guarantees are enforced when data leaves the hospital premises.  
A critical component of the proposed multi-layer security framework is the secure and efficient management of cryptographic keys. To meet the dual requirements of resource-constrained IoT edge devices and compliance-driven cloud communication, a hybrid key management model is adopted. At the edge, IoT devices encrypt payloads using lightweight ciphers (Salsa20 for confidentiality and Blake2b for integrity) with pre-provisioned static symmetric keys. This design minimizes computational and memory overhead, aligning with the limited resources of typical embedded medical devices. The symmetric keys for AES-256 encryption are securely created and managed using Amazon Web Services Key Management Service (AWS KMS) [24]. During the initial system deployment phase, each hospital or medical environment will provision its infrastructure, registering all local MQTT brokers and subscribers as legitimate devices within AWS KMS, allowing only authenticated and authorized devices to request symmetric keys for encryption and decryption. In addition to the symmetric encryption applied at the application layer, the proposed framework enforces transport-layer security using TLS 1.3 to protect all communications between internal system components, particularly between the local MQTT broker, cloud MQTT broker and subscriber. To ensure mutual authentication and prevent unauthorized access, the framework utilizes X.509 certificates issued by trusted Certificate Authorities (CAs). These certificates are securely installed and configured at three locations within the architecture: local broker, cloud broker and subscriber.  
To ensure real-time monitoring of system health and broker availability, the proposed framework includes a heartbeat failure detection mechanism at the local MQTT broker level. Each local broker is configured to periodically publish a lightweight \"I am online\" status message to a cloud-facing topic (e.g., hospital/floor1/broker/status). This message is sent at a fixed interval (e.g., every 10 s) and includes metadata such as: broker identifier (e.g., hostname or floor-specific ID), current timestamp, status code (e.g., \"online\", \"degraded\"). The cloud-side subscriber component subscribes to all registered broker status topics (e.g., hospital/+/broker/status) and updates an internal status table reflecting broker health. If a subscriber does not receive a heartbeat from a broker within the configured timeout threshold (e.g., 2\(\times\) heartbeat interval), it flags the broker as unavailable or disconnected and notifies the user interface layer. This information is visualized in the system's cloud dashboard, enabling administrators to monitor all local brokers and identify broker failures in real time.