## 3 The Proposed Fog-Based MQTT Architecture with an Authentication Scheme
### Multi-Tier MQTT Broker Based on Fog Computing (Mu-TiMB)  
An IIoT system based on the traditional MQTT paradigm may lead to a complex, undependable, and non-scalable framework [25] since the current infrastructure is not designed to cope with the rapid growth of data generated in IoT, and this will increase the consumption of resources and reduce the quality of services for the clients. Moreover, industrial applications in the cloud do not meet the requirements of low latency, network traffic reduction, and reliability [26], which are fundamental properties for the industrial field where the process must be continuously monitored. Therefore, we need to solve such issues by adopting fog computing in smart industries [27]. The idea of Mu-TiMB is based on dividing the clients into groups to interact with the nearest fog broker, called the local broker. As shown in Figure 2, the architecture comprises three layers: the IoT devices layer, where MQTT clients can PUBLISH and SUBSCRIBE messages to/from the local broker; the fog layer, which is composed of two broker tiers, called local brokers and aggregation brokers; and the third layer is the cloud broker, which performs traditional MQTT broker functions with the aggregation brokers. The notation used in Figure 2 is described in Table 2.  
The messages sent by clients to subscribe to or publish topics are conducted via the local broker. In other words, there is no direct connection between clients and aggregation brokers or between clients and the cloud broker; the topic will be published and subscribed to by the clients only through the local broker which, in turn, either handles and provides the requested topic or obtains the topic from the corresponding upper-layer brokers. As a result, delivering the topic from the publisher to the subscriber will create three communication scenarios: (1) the clients connect to the same local broker; (2) the clients connect to different local brokers, but the same aggregation broker; and (3) the clients connect to different local brokers and different aggregation brokers but share the same cloud broker. Since the clients are clustered and connected directly to different local brokers, the requested topic cannot be found in the local broker but can be found in the \begin{table}
\begin{tabular}{c c} \hline \hline
**Symbols** & **Meaning** \\ \hline \(\mathrm{P_{i}}\) & Publisher \\ \(\mathrm{S_{i}}\) & Subscriber \\ \(\mathrm{LB_{i}}\) & Local Broker \\ \(\mathrm{AB_{i}}\) & Aggregation Broker \\ \(\mathrm{CB_{i}}\) & Cloud Broker \\ \(\mathrm{T_{i}}\) & Topic \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Notation used in Mu-TiMB architecture. Figure 2: Multi-tier MQTT broker based on fog computing (Mu-TiMB). aggregation broker or the cloud broker. The details of the three scenarios are described in Section 3.1.2. The first scenario is where the publisher and subscriber are connected to the same local broker. In this scenario, the local broker performs the traditional functions of the MQTT broker, which receives the PUBLISH message on a topic from the publisher and delivers the requested topic to the subscriber. In addition to this function, the local broker acts as an MQTT client to publish the topic to the corresponding upper aggregation broker, which in turn, sends it to the cloud broker. This step allows for saving a copy of the published message, including the topic and its data, in all the corresponding upper-layer brokers in case the topic is subscribed to by clients from other brokers. This process is performed each time the published data are received by the local broker. The second scenario is that the publisher and the subscriber are connected to two different local brokers but have the same aggregation broker.