Sustainable urban planning manages cities to protect the environment and uses resources wisely for the needs of urban daily life. The Internet of Things (IoT) optimizes the usage of resources and the consideration of urban utilities, such as congestion and pollution. Furthermore, Blockchain supports transparent data collection and securely storing data. Immutability is a fundamental feature of Blockchain, which keeps the data unchanged; however, researchers have proposed mutable Blockchains for data modifications by putting away security. This paper studies mutable Blockchains for sustainable IoT urban planning. It aims to discuss the productivity of mutable Blockchain in IoT-driven Sustainable Urban Planning. To this end, it discusses the challenges of mutable blockchains, presents the analytical modeling in practical applications, and examines the security of mutable Blockchains in public and centralized private Blockchains. Our main goal is to discuss their potential and limitations in IoT-based urban planning environments. The analysis shows that mutable Blockchains reduce computational costs but increase security risks. Our study explains the need for carefully governed mutability to support privacy and adaptability in IoT-based urban planning.

The Internet of Things (IoT) has recently received a lot of attention from the information and communication technology community. It has turned out to be a crucial development for harnessing the incredible power of wireless media in the real world. The nature of IoT-Fog networks requires the use of defense techniques who are light and mobile-aware. The edge resources in such a distributed environment are open to various safety hazards. DDoS UDP flooding attacks are the most frequent threats to edge resources in IoT-Fog networks. It is crucial for sabotaging fog gateways and can overcome traditional data filtering techniques. This paper introduces M-RL, a lightweight intrusion detection system with mobility awareness that can detect DDoS UDP flooding attacks while taking into account adversarial IoT devices that engage in IP spoofing. To this end, this paper analyzes the malicious behaviors that result in anonymity against Rate Limiting and Received Signal Strength (RSS)-based approaches, combines their advantages, and addresses their vulnerabilities. We test our method in different contexts to achieve that goal, and we find that it may decrease the accuracy of the RL, RSS, and RSS-RL methods to 70%, 48.9%, and 64.3%, respectively. The outcomes demonstrate the proposed approach's resistance to software-based source address forgery, impersonation, and signal modification. It offers more than 99% accuracy and supports node mobility. In this case, the best possible accuracy of the previous methods is 77%.

Summary In the Internet of Things (IoT) scenario, the integration with cloud‐based solutions is of the utmost importance to address the shortcomings resulting from resource‐constrained things that may fall short in terms of processing, storing, and networking capabilities. Fog computing represents a more recent paradigm that leverages the wide‐spread geographical distribution of the computing resources and extends the cloud computing paradigm to the edge of the network, thus mitigating the issues affecting latency‐sensitive applications and enabling a new breed of applications and services. In this context, efficient and effective resource management is critical, also considering the resource limitations of local fog nodes with respect to centralized clouds. In this article, we present FPFTS, fog task scheduler that takes advantage of particle swarm optimization and fuzzy theory, which leverages observations related to application loop delay and network utilization. We evaluate FPFTS using an IoT‐based scenario simulated within iFogSim, by varying number of moving users, fog‐device link bandwidth, and latency. Experimental results report that FPFTS compared with first‐come first‐served (respectively, delay‐priority) allows to decrease delay‐tolerant application loop delay by 85.79% (respectively, 86.36%), delay sensitive application loop delay by 87.11% (respectively, 86.61%), and network utilization by 80.37% (respectively, 82.09%), on average.