Description:FIELD OF THE INVENTION:
This disclosure pertains to Artificial Intelligence and Fog computing in general, focusing on systems and methods that facilitate the dynamic deployment of fog applications and services within Internet of Things (IoT) environments.

BACKGROUND OF THE INVENTION
The era of IoT applications initially relied on cloud computing, where sensor data was collected and processed in the cloud. However, this architecture has limitations, including network delays between sensing and actuation, reliability issues due to unstable connectivity, and high network overhead due to the exponential increase in data generation. To address these problems, fog computing was introduced, where computational resources are allocated closer to the IoT devices. This reduces latency, improves connectivity, and enhances real-time capabilities. However, the adoption of fog computing has been slowed by challenges such as resource constraints, heterogeneity, and lack of standardization.

The deployment of services on fog devices is a key challenge in fog computing. In the context of Cloud computing, automation tools such as Infrastructure as Code (IaC) have been developed to manage, configure, and provision servers and data centers. Unlike conventional computing systems, fog devices are heterogeneous and have a completely different hardware architecture that may run on different software and be optimized to perform specific tasks. The heterogeneity of fog hardware requires handling platform independence, interoperability, standardization and portability with resource constraints.

The fundamental necessity in a fog federation is to ensure seamless collaboration and interoperability among all the fog devices within the network. Consequently, the dynamic deployment of services on fog devices presents a challenge in managing platform independence, interoperability, and portability while considering resource limitations. This challenge bears resemblance to the issues of vendor lock-in and portability encountered when dealing with composite cloud applications across various cloud service providers. To address this requirement, a system has been developed to enable on-the-fly deployment of services on fog nodes as needed. The current invention showcases the design and modeling of the application's system, along with the dynamic deployment and undeployment of fog services. The FogDEFT Framework extends the OASIS TOSCA (Topology and Orchestration Specification for Cloud Applications) standards, allowing for portable fog services while abstracting the heterogeneity of fog hardware. It also offers user-friendly development paradigms and the capability to deploy services on-the-fly.

One of the challenges in Fog computing is the on-demand deployment of services on fog nodes. As a result, extensive research has been conducted on the deployment of applications and services in fog computing. Various documents studied for this purpose are disclosed below:

N Ferry et al. carried out a case study of GeneSIS in smart buildings. They showed that GeneSIS could support security by design from the development (via deployment) to the operation of IoT systems and keep up security and adapt to evolving conditions and threats while maintaining their trustworthiness.
HA Hassan and RP Qasha propose a new approach to generate a deployable model for the distributed IoT systems based on a simplified, user-friendly declarative description of the smart devices’ communication, configuration, installation, and computation with the IoT system parts with Ansible based YAML description. The work minimizes the efforts for the deployment of the distributed IoT applications on various infrastructures, including the cloud.
The document O Tomarchio et al. proposed a TOSCA-based framework, ‘TORCH,’ for deploying and orchestrating classical and containerized cloud applications on multiple cloud providers. The main benefit of the framework is the possibility to add support to any cloud platform at a very low implementation cost, and it allows deployment management through a simple web tool.
R Dautov et al. discloses a hierarchical architecture for provisioning software updates from the cloud to terminal devices via edge gateways in a targeted manner through a last-mile deployment agent, placed on edge gateways via the centralized cloud in the form of containerized microservices, that receive firmware updates from the cloud and install them on connected IoT devices at the edge.
H Song et al. describe joint research on an industrial use case with a Smart Healthcare application provider on a model-based approach for automatically assigning multiple software deployments to hundreds of Edge gateways (fleet) and uses a set of hard and soft constraints to achieve correct, even distribution of software variants.
B Donassolo et al. proposed another orchestration framework called ‘FITOR,’ an automated deployment and microservice migration solution for IoT applications. The framework uses Optimized Fog Service Provisioning (O-FSP) based on a greedy approach that outperforms other relevant strategies in terms of i) acceptance rate, ii) provisioning cost, and iii) CPU usage.
N Ferry et al. developed a framework for continuous deployment for decentralized processing across heterogeneous IoT, edge, and cloud infrastructures called Generation and Deployment of Smart IoT Systems (GeneSIS). GeneSIS provides (i) a domain-specific modeling language to model the orchestration and deployment of Smart IoT Systems and (ii) an execution engine to support automatic deployment across IoT, edge, and cloud infrastructure resources.
S Venticinque and Amato proposed a new fog service placement methodology. The methodology’s effectiveness is demonstrated in the energy domain with smart grid.
G Davoli et al. developed a modular orchestration system called ‘FORCH.’ The orchestrator is aware of different service models (SaaS/PaaS/IaaS) and dynamically deploys services and manages resources on the fog nodes.
H Sami and A Mourad proposed a new framework for deploying fog service on-demand on the fly based on Kubeadm and Docker with the presence of volunteering devices. Moreover, the framework optimizes the container placement problem with an Evolutionary Memetic Algorithm (MA) that uses heuristics to make decisions.
H Sami et al. discloses an efficient resource and context-aware approach for deploying containerized microservices on-demand called Vehicular-OBUs-As-On-Demand Fogs. The scheme embeds adaptable networking architecture combining cellular technologies and the vehicular ad-hoc wireless network (802.11p) and a Kubeadm-based approach for clustering with docker container-based microservices deployment. The solution provides an on-demand fog and service placement solution on vehicles based on an Evolutionary Memetic Algorithm.
S Hoque et al. have carried out a technical evaluation of docker container and container orchestration tools, their capability, limitations, and how containerization can impact application performance. The result shows that significant adjustments are required to meet the fog environment needs, and they have proposed a framework based on the docker swarm to address issues with the help of ‘OpenloTFog’ toolkits.
F. Li et al. puts the first effort to use TOSCA, the new cloud standard, for IoT applications and demonstrated the feasibility of modeling IoT components gateways and drivers for building Air Handling Unit (AHU) with the first edition of TOSCA. ACF da Silva et al. automatically deployed an IoT application with Open TOSCA based on Mosquitto Message Broker running on the cloud, and the publishers and subscribers were running in two different raspberry pis. Later, in, they automatically deployed an IoT application out of the box where a python script on raspberry pi pushes the data to the message broker on a cloud, and another virtual machine is hosting a web-based dashboard to present the sensor data. They validated this deployment with three case studies of emerging middleware (i) Eclipse Mosquitto, (ii) FIWARE Orion Context Broker, and (iii) OpenMTC.
Tsagkaropoulos et al. presented TOSCA extensions for modeling applications relying on any combination of technologies and discussed semantic enhancements, optimization aspects, and methodology that should be followed for edge and fog deployment support. Furthermore, added a comparison with other cloud application deployment approaches.
HE Solayman and RP Qasha, used TOSCA for deploying IoT applications for Intensive Care Unit (ICU) based on Docker Containers. The demonstration shows automation of IoT application provisioning in heterogeneous environments consisting of hardware components and cloud instance message broker for network communication between components containerized with docker containers.

However, none of the aforementioned documents specifically focus on the dynamic on-the-fly deployment and undeployment of fog services. Hence, it is imperative to devise an on-demand deployment mechanism for services on fog nodes. The current invention showcases the implementation of dynamic fog service deployment, highlighting the system design and modeling of the application, along with the subsequent deployment and undeployment of fog services.

SUMMARY OF THE INVENTION
Accordingly, the present invention provides a dynamic fog service deployment framework, herein referred to as FogDEFT, comprising a plurality of microprocessor with internet connectivity to provide a platform independence component utilizing containerization techniques to enable the deployment of services on diverse Fog devices and operating systems, ensuring platform independence and supporting multi-architecture docker images for deployment; a plurality of Docker Services with an interoperability component leveraging docker swarm to create clusters of fog devices, establishing an overlay network as a load balancer and routing mesh, facilitating seamless coordination and cooperation within the fog federation; and publisher and subscriber to receive a broadcast of each update from the docker with a standardization component extending the Topology and Orchestration Specification for Cloud Applications (TOSCA) modeling language specifically for fog devices, allowing the modeling and deployment of fog services with compatibility and standardization across fog devices.

In an embodiment, the present invention provides that the plurality of microprocessors are Fog nodes with a storage capacity.
In another embodiment, the present invention provides that the docker service is running in the swarm mode.
In another embodiment, the present invention provides that the platform independence component utilizes containerization or OS-level virtualization to provide an efficient and lightweight approach for fog devices, enabling the execution of fog services without interfering with the host system or other containers.
In another embodiment, the present invention provides that the interoperability component utilizes Docker Swarm to create clusters of FOG devices, establishing an overlay network that functions as a load balancer and routing mesh, distributing incoming traffic across multiple containers for optimal workload distribution and utilization within the fog environment.
In another embodiment, the present invention provides that the standardization component extends the TOSCA modeling language to address the portability of fog applications across different fog federations, providing a standardized description for composite fog applications and enabling easy transportation of fog service descriptions across different platforms.
In another embodiment, the present invention provides a method for dynamic fog service deployment using the FogDEFT framework, comprising dynamically provisioning fog application services on-the-fly to devices using the extended TOSCA modeling language; facilitating on-demand deployment of fog services on resource-constrained fog devices through containerization and interoperability mechanisms; and enabling on-demand undeployment of fog services on resource-constrained fog devices for efficient resource utilization.
In another embodiment, the present invention provides that the operations further comprise: transmitting a request to adjust the information based on data detected by a sensor of the device or data received by the device; receiving an authorization to adjust the parameters based on the request; and adjusting the parameters in response to receiving the authorization.
In another embodiment, the present invention provides a computer-readable medium containing instructions that, when executed by a processor, cause the processor to perform the method as claimed in claim 7 for dynamic fog service deployment using the FogDEFT framework.

The novelty in this invention is the ability to dynamically deploy and undeploy any services on heterogeneous fog devices based on the situation, without requiring human intervention. By leveraging containerization, service images can be created to run on various fog computing devices, ensuring compatibility and platform independence. The utilization of orchestration tools (such as Docker Swarm) facilitates seamless communication and cooperation between fog devices, enabling them to collaborate and perform tasks collectively. The extended TOSCA modeling language specifically tailored for fog devices eliminates the need for manual deployment and undeployment processes. Fog services can be provisioned and deprovisioned dynamically based on real-time conditions and requirements. This automation empowers fog computing devices to autonomously adapt and adjust their deployed services without human intervention. This combination of features allows fog computing devices to efficiently and automatically deploy or undeploy services as needed, making them adaptable to changing situations and optimizing resource utilization. In terms of independence from human intervention, it is important to generate service templates on-the-fly as well which can be achieved by leveraging Large Language Models (LLMs). By fine-tuning LLMs, it becomes possible to create tailor-made service templates. The ability to dynamically adjust fog services without human intervention represents a significant novelty, enhancing the flexibility, efficiency, and responsiveness of fog computing environments.

The FogDEFT framework addresses challenges related to deploying services across different layers of devices, such as edge devices, fog devices, fog nodes, and cloud servers. These challenges include heterogeneity, portability, interoperability, and lack of standardization. The framework tackles these challenges through the following approaches:

1. Platform Independence with Containerization: FogDEFT leverages containerization techniques, allowing for the deployment of services on diverse fog devices and operating systems. This ensures platform independence, enabling the use of multi-architecture Docker images for deployment.
2. Interoperability with Docker Swarm: FogDEFT utilizes Docker Swarm to create clusters of fog devices. This creates an overlay network that serves as a load balancer and routing mesh, enabling interoperability between devices within the fog network.
3. Standardization by Extending TOSCA for Fog Devices: To address standardization concerns, the FogDEFT framework extends the widely-adopted TOSCA modeling language. This extension enables the modeling and deployment of fog services, ensuring compatibility and standardization across fog devices.

By leveraging containerization, interoperability through Docker Swarm, and extending TOSCA, the FogDEFT framework provides a comprehensive solution for dynamic fog service deployment, overcoming the challenges posed by heterogeneity, portability, interoperability, and lack of standardization.

OBJECTIVE OF THE INVENTION:
1. The objective of the present invention is to enable the dynamic provisioning of fog application/services on-the-fly to devices using TOSCA.
2. The present invention aims to facilitate on-demand deployment of fog services on resource-constrained fog devices.
3. The invention focuses on enabling on-demand undeployment of fog services on resource-constrained fog devices.
4. Additionally, the invention aims to generate service templates on-the-fly as well for anomalies for which a service template doesn’t exist.

BRIEF DESCRIPTION OF DRAWINGS:
These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read concerning the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:

Fig. 1: Dynamic Deployment of services on fog devices using the FogDEFT framework;
Fig. 2: One of the examples of dynamically deployment of a service on a device using FogDEFT framework;
Fig. 3: Interoperability with Docker swarm;
Fig. 4: Hardware design for Example 1;
Fig. 5: Service design blueprint for Example 1;
Fig. 6: One of the valid orders for deployment/undeployment for Example 1;

Further, skilled artisans will appreciate that elements in the drawings are illustrated for simplicity and may not have necessarily been drawn to scale. Furthermore, the drawings may show only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

DETAILED DESCRIPTION OF THE INVENTION
To promote an understanding of the principles of the invention, reference will now be made to the embodiment illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended, such alterations and further modifications in the illustrated system, and such further applications of the principles of the invention as illustrated therein being contemplated as would normally occur to one skilled in the art to which the invention relates.
It will be understood by those skilled in the art that the foregoing general description and the following detailed description are exemplary and explanatory of the invention and are not intended to be restrictive thereof.

Reference throughout this specification to “an aspect”, “another aspect” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrase “in an embodiment”, “in another embodiment”, and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

The terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such process or method. Similarly, one or more devices or sub-systems or elements or structures or components proceeded by "comprises...a'' does not, without more constraints, preclude the existence of other devices or other sub-systems or other elements or other structures or other components or additional devices or additional sub-systems or additional elements or additional structures or additional components.

Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The system, methods, and examples provided herein are illustrative only and not intended to be limiting.

Embodiments of the present invention will be described below in detail concerning the accompanying drawings.

The current innovation introduces a fog federation framework known as FogDEFT, which facilitates the dynamic deployment of fog services as needed. This framework tackles the challenge of heterogeneity among fog devices and offers a standardized platform for deploying custom or user-developed applications in real-time. The deployment process utilizes the xOpera orchestrator and the ansible automation tool, leveraging the Secure Shell (SSH) infrastructure to push ansible modules. Consequently, this framework ensures security, operates without the need for agents, and seamlessly works with various fog devices out-of-the-box. The framework achieves Platform Independence, Interoperability and Standardization as follow:
1. Platform independence: Fog devices primarily consist of network equipment and gateway devices such as routers, network switches, and sometimes conventional computational devices. These devices exhibit diverse hardware architectures and operating systems. To address this heterogeneity, the FogDEFT framework incorporates a platform-independent abstraction layer through virtualization. However, traditional hardware virtualization is not practical for resource-constrained fog devices due to its costliness and resource-intensive nature. Therefore, the utilization of containerization or OS-level virtualization as a viable solution. Containers leverage the OS kernel of the host machine, running in isolation without interfering with the host system or other containers. Consequently, containerization becomes a feasible option for fog devices, as it provides an efficient and lightweight approach compared to hardware virtualization. To support this approach, it is crucial to have multi-architecture builds of Docker images available on the Docker registry. This ensures that fog devices can pull the specific Docker image designed for their processor architecture on-demand during fog service orchestration. By enabling this flexibility, the fog federation framework accommodates the diverse hardware architectures present in fog environments.
2. Interoperability: Fog services deployed within Docker containers can seamlessly operate in swarm mode, leveraging Docker Swarm to create clusters of fog devices. This results in the establishment of an Overlay Network, exemplified by the Ingress Network (10.0.0.1/24) shown in Fig. 1. The Ingress Network incorporates a load balancer and routing mesh, efficiently distributing incoming traffic across multiple containers when multiple replicas of a service are running, such as 10.0.0.6:80 and 10.0.0.7:80. This load balancing ensures optimal workload distribution and utilization within the fog environment. The routing mesh plays a crucial role by redirecting traffic from any Docker host in the swarm to a specific host where the service container is located. This means that any fog service running with a single replica, such as 10.0.0.6:80 or 10.0.0.7:80, becomes accessible through all IP addresses of fog devices in the swarm, using the same port number. Consequently, both standalone and swarm mode fog services can communicate with other services in swarm mode, without requiring knowledge of the container's placement within the fog federation. This abstraction layer handles interoperability and enables seamless coordination and cooperation within the fog federation through Docker Swarm.
3. Standardization: In order to achieve the portability of a fog application across different fog federations, standardization is necessary. This is a similar challenge faced by the cloud community when migrating a composite cloud application from one cloud service provider to another. OASIS has addressed this issue through the Topology and Orchestration Specification for Cloud Applications (TOSCA), which establishes a standardized description for composite cloud applications. The TOSCA description represents the conceptual structure of an application using two fundamental building blocks: nodes and relationships. Nodes represent infrastructure and software components such as servers, virtual machines, and runtime environments, while relationships define the connections and dependencies between these nodes (e.g., hosted on, depends on, connected to). Each node is defined by its attributes, properties, capabilities, and requirements. The requirements of a node correspond to the capabilities of another node. If a node requires a certain capability, there must be another node with that capability to fulfill the requirement. Both nodes and relationships have associated types where attributes, properties, capabilities, and requirements are declared. TOSCA provides a set of normative node and relationship types as a foundation. Additionally, custom nodes and relationship types can be created by extending these normative types to construct a TOSCA Service Template for a composite application. The TOSCA Service Template encompasses a topology template, which defines the conceptual topology of the composite application using a collection of node and relationship templates. A TOSCA Service Template is expressed as a YAML file, providing a standardized application description that can be easily transported across different platforms. Notably, TOSCA is platform agnostic and offers language extension mechanisms, allowing for flexibility and adaptation to various environments and requirements. The node types mentioned are open source and can be found in online repositories. However, due to the extension of TOSCA for describing fog applications, substantial modifications are required for the existing node types. In the FogDEFT Framework, newly created node and relationship types are provided in Table II and III respectively, which can be used to create TOSCA Service Templates specifically for fog applications.

Explanation of Diagrams:
Fig. 1 illustrates the concept of Dynamic Deployment of services on fog devices using the FogDEFT framework. In (A), a Platform, which can be any hardware with processing power, is shown executing an ongoing task (Service A). It is important to note that the platform can also be idle and not executing any service. In (B), the platform is interrupted due to an anomaly. (C) demonstrates that the platform does not have a service to address the anomaly, so it consults an immediate Hub for a suitable service. The Hub contains all the required services and initiates the deployment of a fog application/service to address the anomaly. Upon receiving the fog service, the platform puts Service A on hold and starts executing the fog service for the anomaly. (D) illustrates the actual deployment process of a service on the platform. The TOSCA Service Template defines the service's topology, and a TOSCA Compliant Orchestrator executes this topology, resulting in a container file that can be executed on the platform. (E) depicts the scenario where the executed service is no longer needed, and the platform undeploys the service. Finally, (F) shows that once all is done, the platform resumes executing Service A.

Fig. 2 The FogDEFT framework is illustrated with an example of dynamic service deployment on a device. The scenario involves a drone performing Task A on a field (A). Suddenly, an accident occurs on the adjacent road (B), referred to as Event X in the figure. This event is considered an anomaly for the drone since it lacks a service to handle Event X. The drone detects the anomaly and consults a nearby hub, transmitting information about Event X (C). The hub, which houses all required services, evaluates the priority of Event X and decides to deploy a new service called Task B on the drone (D). Consequently, the drone suspends Task A and initiates the execution of Task B (E). Once Task B is completed and no longer required, the Hub undeploys Task B and the drone resumes Task A (F).

Fig. 3 describes a load balancer and routing mesh that efficiently directs traffic from various Docker hosts, such as Docker Host 2 and 4, within a swarm to a specific Docker host where the service container is located. As a result, any fog service operating with a single replica (either at 10.0.0.6:80 or 10.0.0.7:80) becomes accessible through all IP addresses of fog devices in the swarm, utilizing the same port number. This seamless connectivity is made possible by the routing mesh. Consequently, any fog service running in either swarm mode or standalone mode can effectively communicate with other services running in swarm mode.

Fig. 4 describes the hardware design for Example 1. The setup consists of two Arduino Nano 33 BLE Sensor boards (2.2 and 2.3) positioned outside the convention center. These boards are connected to a Raspberry Pi 4 (2.8) through serial ports. The Arduino boards (2.2 and 2.3) are equipped with various built-in sensors, including temperature, humidity, light, barometric pressure, proximity, and a microphone, allowing them to gather data about the outdoor environment.

Additionally, an Arduino Uno board is connected to four actuators in the form of servo motors (2.5, 2.6, 2.9, and 2.10) through Pulse Width Modulation (PWM) pins. This Arduino Uno is also connected to a Raspberry Pi 4 (2.4) via a serial port.

All the Raspberry Pis, including the Raspberry Pi 4 (2.8) and the Raspberry Pi 4 (2.4), along with the workstation located inside the control room (2.11), are interconnected through a network and possess internet connectivity.

Fig. 5 illustrates the topology design for deploying fog services for Example 1, specifically for IoT-driven climate control systems. In this diagram, the nodes are represented by boxes, and the directed edges represent the relationships between nodes.

At the bottom, there are two fog nodes (3.6 and 3.7). The middle node represents Docker Services 3.3, consisting of a message broker and a web server for displaying sensor data and system state. These services are running in swarm mode, and their inter-service dependencies are specified in the docker-compose file. This Docker Service node is hosted and dependent on two nodes: Swarm Leader 3.4 and Swarm Worker 3.5. The relationship between these two nodes signifies that they are hosted on the same fog node.

The remaining two nodes are Publisher 3.2 and Subscriber 3.1 services. The Publisher node 3.2 is responsible for pushing sensor data to the message broker. It operates as a standalone container hosted on the fog node connected to the external Arduino. Similarly, the Subscriber node receives broadcast updates from the message broker and adjusts actuators accordingly. This node also operates as a standalone container hosted on the fog node connected to the Arduino controlling the actuators.

This service blueprint highlights the need for at least four different microservices: a message broker, a web viewer, a sensor data publisher, and a Subscriber with a climate controller. Notably, the design allows for dynamic changes by modifying a single URI within the Subscriber node. This flexibility enables adapting to varying climate conditions, possibly triggered by specific events. Thus, this fog federation framework provides a versatile platform for deploying services on-demand and in real-time.

Fig. 6 illustrates deploying and undeploying, with the help of an example. Consider a simple e-commerce application that consists of four services: a web server, a payment gateway, a database, and a recommendation engine. The web server is responsible for handling user requests and displaying products, the payment gateway handles payment processing, the database stores product and customer data, and the recommendation engine suggests products to users based on their browsing history. To deploy this application, we need to determine the order in which the services should be started. Here’s a possible topological sort:
Database → Payment gateway → Recommendation engine → Web server
In this topological sort, the database is the first service to be started because it does not depend on any other service. The payment gateway is started next because it depends on the database, and the recommendation engine is started after that because it depends on both the database and the payment gateway. Finally, the web server is started because it depends on all three services. This topological sort ensures that all dependencies are satisfied before the service is started, which helps prevent errors and ensures that the application runs smoothly. Similarly, if we want to undeploy the e-commerce application then we have to stop the four services in some topological sort as well. Such as:
Web server → Recommendation engine → Payment gateway → Database
Now, coming back to our application of climate control, we need the order to deploy and undeploy the fog service. One of the possible orders is shown in figure 6.
.
The following examples define the invention by way of illustration which does not limit the scope of the invention.

Example 1:
The current invention showcases the dynamic deployment of fog services through a case study involving the climate control system of a convention center. Convention centers located within cities often host a wide range of events, including conferences, exhibitions, and cultural gatherings. In certain situations, such venues may also serve as storage areas during off-times or transform into isolation wards during pandemics, as evident in the past two years.

Given the diverse nature of these events and the varying seasons they take place in, different climate conditions are required inside the convention center. For instance, a cultural event may necessitate specific lighting requirements and intensity that differ from those of an international conference. Furthermore, these requirements may also vary between daytime and nighttime. Weather conditions and the prevailing season significantly influence climate control needs. A summer event calls for lower temperatures, a winter event requires higher temperatures, and during the monsoon season, lower humidity and temperature are desired. Additionally, the number of guests present also impacts temperature and humidity control.

Considering these factors, automating the climate control systems in convention centers becomes an ideal scenario for the dynamic deployment of fog services. The development of this system presents several key challenges. These challenges include:

1. Designing a versatile system, primarily consisting of a hardware platform, capable of accommodating various sensors and actuators. This system should have the capability to host fog services.
2. Developing a collection of fog services utilizing the FogDEFT framework. These services should be capable of dynamically deploying on the fly, depending on the specific event being organized. The services will operate primarily on on-premises infrastructure, minimizing reliance on the internet and cloud resources.
3. Implementing a centralized system that can effectively control the deployment and undeployment of these services. This central system will oversee the management and coordination of the fog services as per the requirements of the event.

Once the generic hardware platform is designed (specifications are mentioned in Table IV), the software takes charge of creating the fog federation platform using on-premises gateway devices, specifically Raspberry Pis. Table IV categorizes the devices into two groups. Firstly, Arduinos fall under the microcontrollers category. These programmable chips execute the same program upon power connection. In this case, two types of Arduinos, Nano 33 BLE Sense and Uno, are used. The former is responsible for sensing the external environment and collecting sensor data, which is then transmitted via the connected Raspberry Pi 4's serial port. The latter is utilized for actuation, controlling the climate inside the convention center by interacting with connected actuators.

Secondly, Raspberry Pis and the system within the control room are categorized as microprocessors. Unlike Arduinos, Raspberry Pis function as typical computers with operating systems capable of loading and executing programs, processes, and services. These devices are treated as fog nodes, and the FogDEFT Framework simplifies the development and deployment of fog services on them.

The prototype design (Fig. 4) consists of two fog nodes (Raspberry Pi 4 devices). Fog services responsible for maintaining the climate are deployed on these fog nodes. The topology design of the fog services deployed within convention centers for IoT-driven climate control systems is depicted in Fig. 5. Nodes are represented by boxes, and directed edges represent relationships between nodes. The bottom two gray nodes represent the fog nodes, while the green node in the middle represents Docker Services running in swarm mode (message broker and web server for displaying sensor data and state). These Docker Services depend on the two blue nodes, Swarm Leader and Swarm Worker, respectively, which are also hosted on fog nodes. The remaining nodes represent Publisher and Subscriber services. The Publisher node sends sensor data to the message broker, hosted in a standalone container on the fog node connected to the external Arduino. Similarly, the Subscriber node receives updates from the message broker and adjusts the actuators, also hosted in a standalone container on the fog node connected to the actuators. The service blueprint in Fig. 5 highlights the need for four different microservices: message broker, web viewer, sensor data publisher, and Subscriber with climate controller. Notably, a single URI change within the purple node named Subscriber can dynamically adapt to completely different climate conditions, depending on the specific event. The FogDEFT Framework offers the necessary node and relationship types to create a TOSCA Service Template (shown in Listing 1) based on the blueprint in Fig. 5.

Listing 1
ABBREVIATIONS:
1. FogDEFT: Fog computing out of the box: Dynamic dEployment of Fog service containers with TOSCA
2. TOSCA: Topology and Orchestration Specification for Cloud Applications
3. OASIS: Organization for the Advancement of Structured Information Standards
4. OS: Operating System
, C , Claims:We claim:
1. A dynamic fog service deployment framework, herein referred to as FogDEFT, comprising:
a plurality of microprocessor with internet connectivity to provide a platform independence component utilizing containerization techniques to enable the deployment of services on diverse Fog devices and operating systems, ensuring platform independence and supporting multi-architecture docker images for deployment;
a plurality of Docker Services with an interoperability component leveraging docker swarm to create clusters of fog devices, establishing an overlay network as a load balancer and routing mesh, facilitating seamless coordination and cooperation within the fog federation; and
publisher and subscriber to receive a broadcast of each update from the docker with a standardization component extending the Topology and Orchestration Specification for Cloud Applications (TOSCA) modeling language specifically for fog devices, allowing the modeling and deployment of fog services with compatibility and standardization across fog devices.

2. The dynamic fog service deployment framework as claimed in claim 1, wherein the plurality of microprocessor are Fog nodes with a storage capacity.
3. The dynamic fog service deployment framework as claimed in claim 1, wherein the docker service is running in the swarm mode.
4. The dynamic fog service deployment framework as claimed in claim 1, wherein the platform independence component utilizes containerization or OS-level virtualization to provide an efficient and lightweight approach for fog devices, enabling the execution of fog services without interfering with the host system or other containers.
5. The dynamic fog service deployment framework as claimed in claim 1, wherein the interoperability component utilizes Docker Swarm to create clusters of FOG devices, establishing an overlay network that functions as a load balancer and routing mesh, distributing incoming traffic across multiple containers for optimal workload distribution and utilization within the fog environment.
6. The dynamic fog service deployment framework as claimed in claim 1, wherein the standardization component extends the TOSCA modeling language to address the portability of fog applications across different fog federations, providing a standardized description for composite fog applications and enabling easy transportation of fog service descriptions across different platforms.
7. A method for dynamic fog service deployment using the FogDEFT framework as claimed in claim 1, comprising:
a) dynamically provisioning fog application services on-the-fly to devices using the extended TOSCA modeling language;
b) facilitating on-demand deployment of fog services on resource-constrained fog devices through containerization and interoperability mechanisms; and
c) enabling on-demand undeployment of fog services on resource-constrained fog devices for efficient resource utilization.
8. The method as claimed in claim 7, wherein the operations further comprise:
i. transmitting a request to adjust the information based on data detected by a sensor of the device or data received by the device;
ii. receiving an authorization to adjust the parameters based on the request; and
iii. adjusting the parameters in response to receiving the authorization.
9. A computer-readable medium containing instructions that, when executed by a processor, cause the processor to perform the method as claimed in claim 7 for dynamic fog service deployment using the FogDEFT framework.
10. The novelty in this invention is the ability to dynamically deploy and undeploy any services on heterogeneous fog devices based on the situation, without requiring human intervention. By leveraging containerization, service images can be created to run on various fog computing devices, ensuring compatibility and platform independence. The utilization of orchestration tools (such as Docker Swarm) facilitates seamless communication and cooperation between fog devices, enabling them to collaborate and perform tasks collectively. The extended TOSCA modeling language specifically tailored for fog devices eliminates the need for manual deployment and undeployment processes. Fog services can be provisioned and deprovisioned dynamically based on real-time conditions and requirements. This automation empowers fog computing devices to autonomously adapt and adjust their deployed services without human intervention. This combination of features allows fog computing devices to efficiently and automatically deploy or undeploy services as needed, making them adaptable to changing situations and optimizing resource utilization. The ability to dynamically adjust fog services without human intervention represents a significant novelty, enhancing the flexibility, efficiency, and responsiveness of fog computing environments.