Fog topologies can exist in many forms, and the architect needs to consider several aspects when designing an end-to-end fog system. In particular, constraints such as cost, processing load, manufacturer interface, and east-west trafficking all come into play when designing the topology. A fog network can be as simple as a fog-enabled edge router connecting sensors to a cloud service. It can also grow in complexity to a multi-tier fog hierarchy with different degrees of processing ability and roles at each tier simultaneously distributing processing loads when and where necessary (east-west and north-south).  Determining factors of the models are based on:

• Data volume reduction: For example, is the system collecting unstructured video data from thousands of sensors or cameras, aggregating the data, and looking for particular events in real time? if so then the dataset reduction will be significant as thousands of cameras will be producing hundreds of GBs of data daily, and fog nodes will need to distill large amounts of data into simple yes, no, danger, safe event tokens. 
• The number of edge devices: If the IoT system is simply one sensor, then the dataset is small and may not justify a fog edge node at all. However, if the number of sensors grows or, in the worst case, the number of sensors is unpredictable and dynamic, then the fog topology may need to scale up or down dynamically. A use case would be a stadium venue using Bluetooth beaconing. As the audience grows for certain venues, the system must be able to scale non-linearly. At other times, the stadium may only seat a fraction of space and only need marginal processing and connectivity resources.
• Fog node capabilities: Depending on the topology structure and cost, some nodes may be better suited for connectivity to WPAN systems, while other nodes in the hierarchy may have additional processing capabilities for machine learning, pattern recognition, or image processing. An example would be edge fog nodes that manage a secure Zigbee mesh network and have special hardware for failover situations or WPAN security. Above that fog level would exist a fog processing node that would have extra RAM and GPGPU hardware to support the processing of raw data streaming from the WPAN gateways.
• System reliability: An architect may need to consider forms of failure in an IoT model. If one edge fog node were to fail, another could take its place to perform some action or service. This case is important in life-critical or real-time environments. In the same manner, extra fog nodes may be provisioned on demand; redundant nodes may be needed in fault-tolerant situations. In the case that there are no additional redundant nodes, some processing may be shared with neighbor nodes at the cost of system resources and latency, but the system will keep functioning. The final use case is where neighbor nodes act as watchdogs for each other. In the event a fog node fails or communication to the node fails, the watchdog will signal a failure event to the cloud and may perform some life-critical actions locally. A good example is in the event that a fog node fails to monitor traffic on a highway; a neighbor node may see the point failure, alert the cloud of the event, and signal on a billboard on the highway to reduce speed.

The simplest fog solution is an edge processing unit (gateway, thin clients, router) placed in proximity to a sensor array. Here, a fog node may be used as a gateway to a WPAN network or mesh and communicate to a host:

The next basic fog topology includes the cloud as the parent over a fog network. The fog node, in this case, will aggregate data, secure the edge, and perform the processing necessary to communicate with the cloud. What separates this model from edge computing is that the service and software layers of the fog node share a relationship with the cloud framework:

The next model extends topology two with the ability to communicate securely and privately to multiple cloud vendors from multiple fog nodes. In this model, multiple parent clouds may be deployed. For example, in smart cities, multiple geographical areas may exist and be covered by different municipalities. Each municipality may prefer one cloud provider over the other, but all municipalities are governed to use one approved and budgeted camera and sensor manufacturer. In that case, the camera and sensor manufacturer would have their single cloud instance coexist with multiple municipalities. The fog nodes must be able to steer data to multiple cloud providers:

Fog nodes also do not need a strict one-to-one relationship bridging sensors to clouds. Fog nodes can be stacked, tiered, or even kept in stasis until needed. Tiering layers of fog nodes above each other may sound counterintuitive if we are trying to reduce latency, but as mentioned previously, nodes can be specialized. For example, nodes closer to the sensors may provide hard real-time services or have cost constraints requiring them to have the minimal amount of storage and compute. A tier above them may provide the compute resources needed for aggregate storage, machine learning, or image recognition through the use of additional mass storage devices or GPGPU processors. The following example illustrates a use case in a city lighting example. 

Here, a number of cameras sense moving pedestrians and traffic; the fog nodes closest to the cameras perform aggregation and feature extraction and pass those features upstream to the next tier. The parent fog node retrieves the features and performs the necessary image recognition through a deep learning algorithm. If an event of interest is seen (such as a pedestrian walking at night along a path), the event will be reported to the cloud. The cloud component will register the event and signal to a set of street lights in the pedestrian's vicinity to increase illumination. This pattern will continue as long as the fog nodes see the pedestrian moving. The end goal is the overall energy saved by not illuminating every street lamp to full intensity at all times: