Methods and systems for enabling federated learning on 3GPP edge APP architecture

Abstract

Embodiments herein disclose a system (100), and a method includes registering a Federated Haptic Server (FedHS) (110) with a plurality of Edge Configuration Servers (ECS) (160) from different Edge Computing Service Providers (ECSPs). Further, the method includes registering Edge Enabler Servers (EES) (140) with the FedHS (110) after discovery, enabling communication between the FedHS (110) and Edge Application Servers (EAS) (130). Further, the method includes receiving locally trained model updates from a plurality of User Equipment (UE) devices (120) and EAS (130) deployed by different ECSPs. Further, the method includes aggregating the locally trained model parameters at the FedHS (110) to create global model parameters. Further, the method includes transmitting the global model parameters back to the EAS (130) and the plurality of UE devices (120), while maintaining data privacy between different ECSPs.

Description

METHODS AND SYSTEMS FOR ENABLING FEDERATED LEARNING ON 3GPP EDGE APP ARCHITECTURE TECHNICAL FIELD

[0001] Embodiments disclosed herein relate to a federated learning method and its implementation within a 3 GPP EDGE APP architecture.BACKGROUND

[0002] Remote robots have revolutionized various commercial applications, including healthcare, industrial automation, and gaming. These robots enable tasks to be performed remotely, which is particularly beneficial in scenarios where human presence is either risky or impractical. The integration of Augmented Reality (AR) and Virtual Reality (VR) technologies has opened new pathways for digital twins and the tactile internet. The tactile internet is a concept that enables real-time, sensory interactions between users and devices over a network These technologies are crucial for applications like remote medical telesurgery, where precise and real-time control is essential. The tactile internet aims to deliver real-time haptic feedback, making remote interactions feel as immediate and natural as possible. The advent of the 5G network has significantly enhanced communication capabilities, ensuring Ultra -Reliable Low Latency Communications (URLLC). This is critical for applications that require high availability, reliability, and security, such as remote medical telesurgery. The 5G network’s ability to provide low latency and high bandwidth makes it ideal for supporting these advanced applications. However, training models on a cloud for applications like remote telesurgery can pose risks, including the exposure of privacy -sensitive data and inefficient use of bandwidth. These challenges necessitate a more decentralized approach to model training.

[0003] Furthermore, the 5G network is integrated with high-performance computing facilities at the network edge to minimize latency and conserve bandwidth. Edge computing is crucial as it provides computational capabilities to end devices at the nearest edge, thereby reducing latency issues over the backhaul network. Moreover, Al inferencing can support tactile applications to meet their low latency requirements. Consequently, the high-performance computing capabilities of the 5G infrastructure at the edge make it an ideal choice for deploying haptic / tactile applications.

[0004] The above information is presented as background information only to help the reader to understand the present invention. Applicants have made no determination and makeno assertion as to whether any of the above might be applicable as prior art with regard to the present application.OBJECTS

[0005] The principal object of the embodiments herein is to disclose a system and methods to facilitate federated learning support in a multi operator edge environment with a plurality of federated clients.

[0006] Another object of the embodiment herein is a system and methods to provide architectural support on the 3rd Generation Partnership Project (3GPP) edge app architecture to facilitate decentralized learning model by preserving sensitive data.

[0007] Another object of the embodiment herein is a system and methods to enable the aggregation ofknowledge at a central entity capable of integrating edge services under different edge service providers.

[0008] Another object of the embodiment herein is a system and methods to ensure privacy and efficient use of bandwidth by decentralizing the training of models at the edge and transferring model parameters to a central server for aggregationBRIEF DESCRIPTION OF FIGURES

[0009] The embodiments disclosed herein are illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the drawings, in which:

[0010] FIG. 1 depicts a system for facilitating federated learning support in a multioperator edge environment using 3 GPP architecture, according to embodiments as disclosed herein;

[0011] FIG. 2 is an example use case in a telesurgery application, according to embodiments as disclosed herein;

[0012] FIG. 3 depicts a block diagram of the Federated Haptic Server (FedHS) of the system, for facilitating federated learning in a multi-operator edge environment, according to embodiments as disclosed herein;

[0013] FIGS.4a-4c depicts registration functions related to FedHS registration with the Edge Configuration Servers (ECS), according to embodiments as disclosed herein;

[0014] FIGS. 5a-5c depicts registration functions related to Edge Enabler Servers (EES) registration with the FedHS, according to embodiments as disclosed herein;

[0015] FIG. 6 depicts message exchange via interface EDGE Fedl, EDGE Fed2 and EDGE Fed3 with application deployment, according to embodiments as disclosed herein; and

[0016] FIG. 7 is a flowchart depicting a method for enabling federated learning in a multi-operator edge environment, according to embodiments as disclosed herein.DETAILED DESCRIPTION

[0017] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

[0018] For the purposes of interpreting this specification, the definitions (as defined herein) will apply and whenever appropriate the terms used in singular will also include the plural and vice versa. It is to be understood that the terminology used herein is for the purposes of describing particular embodiments only and is not intended to be limiting. The terms “comprising”, “having” and “including” are to be construed as open-ended terms unless otherwise noted .

[0019] The words / phrases "exemplary", “example”, “illustration”, “in an instance”, “and the like”, “and so on”, “etc.”, “etcetera”, “e.g.,” , “i.e.,” are merely used herein to mean "serving as an example, instance, or illustration." Any embodiment or implementation of the present subject matter described herein using the words / phrases "exemplary", “example”, “illustration”, “in an instance”, “and the like”, “and so on”, “etc.”, “etcetera”, “e.g.,” , “i.e.,” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0020] Embodiments herein may be described and illustrated in terms of blocks which carry out a described function or functions. These blocks, which may be referred to herein as managers, units, modules, hardware components or the like, are physically implemented by analog and / or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electroniccomponents, optical components, hardwired circuits and the like, and may optionally be driven by a firmware. The circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like. The circuits constituting a block may be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware to perform some functions of the block and a processor to perform other functions of the block. Each block of the embodiments may be physically separated into two or more interacting and discrete blocks without departing from the scope of the disclosure. Likewise, the blocks of the embodiments may be physically combined into more complex blocks without departing from the scope of the disclosure.

[0021] It should be noted that elements in the drawings are illustrated for the purposes of this description and ease of understanding and may not have necessarily been drawn to scale. For example, the flowcharts / sequence diagrams illustrate the method in terms of the steps required for understanding of aspects of the embodiments as disclosed herein. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the present embodiments so as nottoobscure the drawings with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein. Furthermore, in terms of the system, one or more components / modules which comprise the system may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the present embodiments 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.

[0022] The accompanying drawings are used to help easily understand various technical features and it should be understood that the embodiments presented herein are not limited by the accompanying drawings. As such, the present disclosure should be construed to extend to any modifications, equivalents, and substitutes in addition to those which are particularly set out in the accompanying drawings and the corresponding description. Usage of words such as first, second, third etc., to describe components / elements / steps is for the purposes of this description and should not be construed as sequential ordering / placement / occurrence unless specified otherwise.

[0023] The embodiments herein disclose a system and method for enabling federated learning over edge app architecture. Federated learning allows forthe decentralized training of models at the edge, helping to preserve privacy and reduce bandwidth usage. The system involves training models locally on edge devices and then aggregating the model parameters at a central server, referred to as the Federated Haptic Server (FedHS).

[0024] Embodiments herein disclose a system and a method for enabling distributed training of machine learning models within edge computing environments. The federated learning is a technique where models are trained on multiple devices without sharing raw data. Devices train on local data and send only model updates to a central server, enhancing privacy and reducing bandwidth. The edge app architecture is a framework designed for edge computing that brings data processing closer to users and improves response times and optimizes bandwidth usage. Implementing federated learning in the edge app architecture allows edge devices (e.g., Internet of Things (loT) devices or smartphones) to train models collaboratively while keeping sensitive data local and ensures privacy and reduces network load. The federated learning over the edge app architecture combines decentralized model training with edge computing, enhancing privacy, efficiency, and scalability. At the end of the process, the weights are updated using decentralized models. These models have the advantage that, instead of sending a photo to a server, which would require a lot of space and bandwidth, they send a set of weights that carry thenecessary information. For example, instead of sending actual photos, only the weights representing the photo are transmitted. This method preserves privacy, as no one can decode the image from the weights, which are simply learning parameters. Even if a particular weight is high, it does not reveal the picture. Thus, this method keeps privacy-sensitive data secure, which is a key feature of federated learning.

[0025] FIG. 1 depicts a system 100 for facilitating federated learning support in a multioperator edge environment using 3rd Generation Partnership Project (3GPP) architecture. The 3GPP architecture refers to the architecture for the evolved core network, facilitating communication protocols. The multi-operator edge environment is the architecture that allows multiple Edge Computing Service Providers (ECSPs) to operate in a collaborative framework. The system 100 comprises the FedHS 110, a plurality of User Equipment (UE) devices 120, a plurality of Edge Application Servers (EAS) 130, a plurality of Edge Enabler Servers (EES) 140, a plurality of Edge Data Network (EDN) 150, a plurality of Edge Configuration Servers (ECS) 160, and a 5G Core Network (CN) 170. The EAS 130 are software applications designed to run at the edge of the network, rather than relying solely on centralized cloud services andprocessing data locally to reduce latency and bandwidth use. Examples of the EAS 130 can be, but are not limited to, Internet of things (loT) application server SA6 Video, SA6 Audio realtime analytics, Augmented Reality (AR) and Virtual Reality (VR) servers and so on. The EES 140 provides the necessary infrastructure and services to facilitate edge computing. The EES 140 helps deploy, manage, and optimize edge applications. Examples of the EES 140 can be, but are not limited to, edge management platforms, data integration servers, microservices platforms and so on. The EDN 150 refers to the infrastructure that connects edge devices and servers, facilitating dataflow and communication. Examples of the EDN 150 can be, but are not limited to, Local Area Networks (LAN), Software-Defined Wide Area Network (SD-WAN) and so on. The ECS 160 refers to the settings and parameters that dictate how edge devices and applications operate within the network. The ECS 160 includes security settings, data processing rules, and network connectivity. Examples of the ECS 160 can be, but are not limited to, device management tools, network policy configurations, application deployment settings, and so on. The UE 120 refers to devices that users utilize to connect to a network. The UE devices 120 enable users to access various services, including the internet, communication, and streaming. Examples of the UE 120 can be, but are not limited to, a smartphones, tablets, laptops, desktop computers, wearable devices, loT devices, voice over IP phones and so on. The UE 120 comprises a plurality of Application Client (AC) 122 and an Edge Enabler Client (EEC) 124. The AC 122 refers to software that runs on the UE 120 and interacts with a server to provide specific functionalities or services. The AC 122 typically communicate with a server to retrieve data, send requests, or perform specific tasks, enhancing user experience and functionality. Examples of the AC 1220 can be, but are not limited to, a web browsers, email clients, messaging apps, social media apps, wearable devices, gaming clients, file transfer clients, streaming apps, cloud storage clients, and so on. The EEC 124 are devices or software that interact with edge servers to facilitate data processing and communications. The EEC 124 often reside on the end-user side. Examples of the EEC 124 can be, but are not limited to, smartphones network interface controller (NIC) network adapters, loT gateways, edge routers, smart home hubs and so on.

[0026] FIG. 1 shows system 100, comprising two EAS 130a, and 130b, two EES 140a and 140b, two EDN 150a and 150b, two ECS 160a and 160b and two AC 122a and 122b. In contrast, FIG. 2 depicts system 110, comprising three EES 140a, 140b, and 140c, three EDN 150a, 150b, and 150c, and three ECS 160a, 160b, and 160c.

[0027] The FedHS 110 is the primary entity that supports federated learning across multiple ECSPs. The FedHS 110 aggregates and updates learning models while preserving data privacy. The system 100 includes three main interfaces EDGE Fed 1, EDGE Fed 1, and EDGE Fed3, which facilitates communication between different components. The EDGE Fedl manages interactions between FedHS 110 and EES 140. The EDGE Fed2 handles communication between FedHS 110 and ECS 160. The EDGE Fed3 facilitates interactions between FedHS 110 and the 5G core network 170. Each interface supports specific protocols for registration, discovery, and data transfer. The FedHS 110 registers with ECS 170 via EDGE Fed2, making it discoverable by EES 140. The EES 140 then registers with FedHS 110 through EDGE Fedl, enabling communication and service provisioning. The EAS 130 and theUE 120 send local model updates to FedHS 110, which aggregates these updates and distributes the global model back to the clients.

[0028] The 5G Core 170 provides the core functionalities of the 5G network, managing dataflows and communications between devices and services. The 5GCore 170 supports ultrareliable low-latency communication, essential for haptic feedback applications. Mobile Network Operator (MNO) provides the wireless network infrastructure necessary for communication between devices and ensures connectivity and quality of service across the network.

[0029] Haptic refers to the technology and techniques used to create a sense of touch or tactile feedback in a digital environment. It involves interactions that simulate the sensation of touch, allowing users to receive feedback through physical sensations. Haptic feedback is an application of this technology, where devices provide tactile responses, such as vibrations or motions, to mimic the feeling of touch. For example, smartphones often use haptic feedback to simulate the sensation of pressing a button on the screen. A haptic server introduces an additional dimension to interactions, much like how video and audio are transmitted over long distances. Haptic technology aims to replicate the sensation of touch remotely. For instance, while a user in country A might watch a video with audio originating from country B, haptic feedback could enable them to perceive tactile sensations. Ideally, this technology could be extended to robotic systems, such that when a robot interacts with an object in say country B, the corresponding tactile feedback would be transmitted and experienced by the user in country A.

[0030] The FedHS 110 is a central entity that coordinates federated learning by collecting model updates from various clients, aggregating them, and maintaining data privacy.The FedHS 110 supports interoperability among different ECSPs and ensures secure communications. The ECS 160 manages configurations for edge services and facilitates connections between the EEC 124 and EAS 130. The ECS 160 capable of handling multiple Service Level Agreements (SLAs) and dynamic provisioning. Thus, the ECSs 160 functions like servers that are connected to different Internet Service Providers (ISPs). For example, ECS1 160ais deployed under Edge Service Provider (ESP)-l, ECS2160b deployed underESP-2, and ECS3 160c deployed underESP-2. Each would have contracts with these edge service providers. ECSs 160 can connect with the edge servers of these entities by exchanging messages through an interface like EDGE FED 2. If a model is deployed under, for instance, ESP-1, and another model is hosted under ESP -2, both models can send their weights to a central server (FEDHS). This server can then accumulate the weights, update them, and send the improved weights back. This process results in a more refined model that utilizes more information without compromising privacy. The EDN 150 connects all edge devices, managing data transfer between EAS 130 and clients. The EDN 150 is optimized for low -latency data transmission, crucial for real-time haptic feedback. TheUE 120 represents devices (e.g., haptic gloves, robotic hands) that interact with the network to provide or receive haptic feedback. The UE 120 is equipped to process inputs and outputs from haptic applications. For example, the UE device (120) is a robotic actuator equipped with haptic gloves, providing real-time data for local training in the context of haptic -based medical telesurgery. The AC 122 acts as the client on the UE 120, facilitating interaction with the haptic system. The AC 122 is designed to operate in real-time, responding to inputs from the haptic devices. The EEC 124 enables UE 120 to access edge services, supporting connections to EAS 130 and FedHS 110. The EEC 124 acts as a gateway between the user and edge applications. The EAS 130 runs haptic-based applications and provide local training data to the FedHS 110. The EAS (130) performs split control of haptic devices in telesurgery applications and provides real-time feedback, including detection and correction of control faults such as instrument slippage, to ensure ultra-low latency and reliable control during the operation.

[0031] The FedHS 110 sends a registration request to the ECS 160 via EDGE Fed2, including the SLA. The ECS 160 registers FedHS 110, allowing it to be discoverable by the EES 140 connected to the ECS 160. Once registered, the EES 140 sends a registration request to FedHS 110 via EDGE Fedl. This request includes security credentials to ensure that only authorized entities can access FedHS 110. Upon successful registration, the EAS 130 initiates a Quality of Service (QoS) session withFedHS 110 to ensure reliable and efficient data transferduring the learning process. Each UE 120 locally trains its model based on the data it collects and ensures that sensitive data remains on the client device, preserving privacy. The EAS 120 sends its local model weights to the FedHS 110, either directly or through split control mechanisms. The split control mechanism in haptic applications and teleoperation systems divides the control functions between local devices and remote servers to optimize performance, reduce latency, and enhance user experience. Local devices include UE 120 (like haptic gloves or robotic arms) that directly interact with the user and processes immediate inputs and provide real-time feedback. In contrast, the remote server is often a powerful computing unit, like the FedHS 110, that handles complex computations, model training, and data aggregation. The split control mechanism employs communication protocols to facilitate the exchange of databetween the local device and the remote server. For example, in a medical telesurgery application, a surgeon uses the haptic glove (local device) to manipulate instruments. The split controller detects hand movements and provides immediate tactile feedback through the glove. Meanwhile, data on instrument positions and movements is sent to FedHS 110 (remote server) formodel training. The FedHS 110 aggregates model parameters from multiple surgeries and sends improved models back to the haptic glove, enhancing future interactions while ensuring dataprivacy. The FedHS 110 aggregates the received weights from multiple federated clients. This aggregation is done without transferring raw data, thus preserving privacy. The aggregated model parameters are sent back to the federated clients, enabling them to update their local models with global knowledge while keeping the underlying data private. The FedHS (110) aggregates model parameters using a federated learning algorithm and transmit the aggregated model back to the EAS (130) and UE devices (120) for local model updates.

[0032] Although FIG. 1 shows various components of the system 100, but it is to be understood that other embodiments are not limited thereto. In other embodiments, the system 100 may include less or more components. Further, the labels or names of the components are used only for illustrative purposes and do not limit the scope of the invention. One or more components can be combined to perform the same or substantially similar function in the system 100.

[0033] FIG. 2 is an example use case in a telesurgery application. FIG. 2 illustrates a high-level architecture for a teleoperation use case involving multiple remote robots operating under different ECSPs and emphasizes the interaction between the FedHS 110 and various components necessary for facilitating federated learning while maintaining data privacy.

[0034] The system 100 relates to deploying a haptic application within an edge computing environment, specifically for medical telesurgery. The haptic-based application is deployed on the EAS 130, enabling a haptic glove service that controls a remotely located haptic actuator. However, traditional cloud -based haptic gloves face challenges in preventing control faults like instrument slippage due to high latency. To address this, the system 100 introduces implementing low -latency control at the closest edge using the EAS 130 (split control EAS) withan algorithm detecting and preventing instrument slippage faults. The actuator's generated data can be locally trained at the UE 120 and edge to detect / prevent slippage.

[0035] This architecture requires broad application support (software and hardware) and deployment of Artificial Intelligence (Al) / Machine Learning (ML) models trained on large datasets, which can be financially burdensome for a single ECSP. Moreover, trust and legal concerns arise from potential data leakage during training / inferencing of haptic applications belonging to different ISPs.

[0036] Here, being provided through learning means that, by applying a learning method to a plurality of learning data. The learning method may be performed in the central and remote server itself in which the learning according to an embodiment is performed, and / or may be implemented through a separate server / system. Examples of the learning method include, but are not limited to, supervised learning, unsupervised learning, semi -supervised learning, or reinforcement learning.

[0037] The system 100 introduces the FedHS 110 to facilitate federated learning support in a multi-operator edge environment with multiple federated clients. The FedHS 110, an edge or cloud server, periodically gathers trained parameters from federated clients UE(s) 120 and split control EAS(s)) and facilitates federated weight updates while maintaining data privacy.

[0038] Radio Access Network (RAN) connects individual network devices through wireless connections, enabling devices like the UE 120 to communicate with the core network. The AC 122 runs on theUE 120, such as a robotic hand, starts the connection process with the haptic gloves hosted on the Cloud Application Server (CAS). The CAS is a remote server that hosts the primary haptic application components and handles data processing in the cloud. The UE 120 requests to connect with the haptic gloves and the EAS 130 to enable real-time detection and correction of potential errors, like slippage. The UE 120 sends a serviceprovisioning request through the EEC 124 to the ECS 160, looking for compatible servers that can provide the necessary capabilities. The ECS 160 returns a list of available EAS 130 and the CAS that meet the application's requirements, potentially utilizing FedHS 110 for performance metrics. After identifying suitable servers, the QoS session is established between the EAS 130, CAS, and UE 120 to ensure performance criteria are met. The UE 120 can now consume data from the CAS and EAS 130, including feedback from the robotic hand's movements. The EAS 130 sendsits local model weights totheFedHS 110 for aggregation. The UE 120 may also train its model locally and send updates directly totheFedHS 110. The FedHS 110 receives weight updates from federated clients, ensuring that data privacy is maintained throughout the process. The FedHS 110 aggregates the received weights and sends back the updated global model parameters to the clients, preserving the privacy of the original data.

[0039] Therefore, the system 100, as depicted in FIG. 2, enables the robust federated learning environment that maintains data privacy while facilitating collaborative model training across different edge service providers. The integration of advanced communication protocols and edge computing significantly enhances the capabilities and reliability of haptic applications in sensitive domains like telesurgery.

[0040] FIG. 3 depicts a block diagram of the FedHS 110 of the system 100, for facilitating federated learning in the multi -operator edge environment, specifically for applications like haptic-based medical telesurgery. The FedHS 110 comprises a FedHS discovery and selection unit 302, a FedHS receiving unit 304, a FedHS sender unit 306, a FedHS service utility unit 308, a FedHS registration functions management unit 310, a FedHS encryption unit 310, a FedHS decryption unit 314, and a FedHS aggregation unit 316. The FedHS discovery and selection unit 302 can identify and register ECS 160 and EES 140 across differentECSPs. The FedHS receiving unit 304 receives incoming messages from ECS 160, EES 140, and 5G core 170. The FedHS receiving unit 304 handles the discovery and registration of services, as well as any deregistration requests or core function messages and ensures that FedHS 110 is aware of all active clients and services. The FedHS sender unit 306 can send messages from FedHS 110 to ECS 160, EES 140, and 5G core 170 for similar functions. The FedHS sender unit 306 facilitates the flow of information, ensuring that the necessary updates and messages regarding discovery, registration, and core functions reach their destinations efficiently. The FedHS service utility unit 308 can maintain a list of services offered within the scope of a particular ECS 160 and EES 140. By keeping an updated inventory of available services, the FedHS service utility unit 308 aids in efficient resourceallocation and service discovery, allowing clients to find appropriate services based on their needs. The FedHS registration functions management unit 310 can manage registration, deregistration, and updates of services for EES 140 and ECS 160. The FedHS registration functions management unit 310 ensures that all relevant information about active services and their status is accurately maintained, thus facilitating smooth operations within the federated learning environment. The FedHS encryption unit 310 can encrypt updates from incoming federated clients and assigns encryption -based user IDs to ensure data privacy during federated learning aggregation across different ECSPs. By assigning an encryption -based user ID, the FedHS encryption unit 310 ensures that sensitive data transmitted between clients and the FedHS 110 is protected from unauthorized access, thereby maintaining data privacy. Throughout the process, the FedHS encryption unit 310 ensure that all communication between clients and theFedHS HOare secure. The FedHS decryptionunit 314 can decrypt the encrypted weights and updates associated with specific client models. The FedHS decryption unit 314 allows the FedHS 110 to accurately process and utilize the information provided by federated clients while ensuring that the original data remains secure until it is needed. The FedHS aggregation unit 316 aggregates weights of the model belonging to specific parameters. By combining these weights, theFedHS aggregation unit 316 helps in creating a global model that reflects the collective learning from all federated clients, enhancing the performance of the AI / ML algorithms employed in the application. The FedHS aggregation unit 316 is connected to a memory 320 and an Input / Output (I / O)unit 330. The FedHS aggregation unit 316 manages the sending and receiving of information between FedHS 110, ECS 160, EES 140, and the 5G core 170. This communication is facilitated through the FedHS receiving unit 304 and the FedHS sender unit 306.

[0041] Therefore, the FedHS 110 in FIG. 3 is designed to support efficient federated learning across the multi-operator edge environment. The FedHS 110 emphasizes the importance of secure communication, effective service management, and collaborative learning while ensuring privacy and reliability for applications, particularly in sensitive domains like medical telesurgery. By coordinating the various components effectively, the FedHS 110 plays a critical role in mitigating issues related to data privacy and fault sensitivity, which are paramount in medical applications where precision and safety are crucial.

[0042] FIGS. 4a-4c depicts registration functions essential forthe entity FedHS 110 to communicate with the ECS 160. These functions include registration, de-registration, and update functionalities. As shown in FIG. 4(a), the FedHS 110 initiates the registration bysending a request to theECS 160 via EDGE Fed2. For this process, theFedHS 110 must have the ECS 160 address and both parties need valid credentials to enable secure communication. Upon successful registration, theECS 160 responds with a registration ID and updates the EDN 150 information to include details about the FedHS 110. FIG. 4(b) depicts the de-registration process. Here, FedHS 110 sends a de-registration request to the ECS 160. The ECS 160 then verifies the security credentials of FedHS 110. Upon successful verification, it removes all information associated with FedHS 110 from its records. The update registration functionality is depicted in FIG. 4(c). In this scenario, the FedHS 110 sends an update registration request to theECS 160. Upon receiving this request, theECS 160 verifies the credentials again and, once verified, updates its records with the new information provided in the request. These registration functions ensure secure and effective communication between FedHS 110 and the ECS 160, enabling efficient management of registration information.

[0043] FIGS. 5a-5c depicts registration functions necessary for the EES 140 to communicate with the FedHS 110. These functions encompass registration, de-registration, and update functionalities. As shown in FIG. 5(a), the EES 140 initiates registration by sending a request to the FedHS 110 via EDGE Fed 1. For successful registration, it is essential that the FedHS 110 has the EES 140 address and both entities possess valid credentials for secure communication. Once the registration is successful, theFedHS 110 responds with a registration ID, which may include the expiration time of the registration. FIG. 5(b) details the deregistration process. The EES 140 sends a de-registration request to the FedHS 110. Upon receipt, the FedHS 110 verifies the EES's 140 security credentials. If the verification is successful, theFedHS 110 removes all information associated with the deregistering EES 140 from its records. The update registration functionality is depicted in FIG. 5(c). In this case, the EES 140 sends an update registration request to the FedHS 110. After receiving this request, theFedHS 110 verifies the security credentials. Upon successful verification, theFedHS 110 updates its records with the new information provided in the request, which may also include the expiration time. These registration functions facilitate secure and efficient communication between the EES 140 and FedHS 110, ensuring effective management of registration information.

[0044] FIG. 6 depicts message exchange via interfaces EDGE Fed 1, EDGEFed2, and EDGE Fed 3, along with the application deployment. The procedures involved include the FedHS 110 registration functions with the ECS, EES registration functions with the FedHS 110, and the FedHS's utilization of 3GPP core networks. Additionally, the FIG. 6 encompassesdata traffic and weight aggregation from federated clients, specifically UE 120 and EAS 130, with the FedHS 110. Upon instantiation, the FedHS 110 registers with the ECS 160 via EDGE Fed2. This process requires FedHS 110 to have the ECS 160 address and both entities must possess the necessary credentials for secure communication. The FedHS 110 can retrieve the ECS 160 communication information through the 5GC procedure via EDGE Fed3. After successful registration, the ECS 160 exposes the communication information of FedHS 110. The EES 140 registers with the ECS 160, and following successful registration, the FedHS 110 communication information is made available to the EES 140 via EDGE Fed 1. The EES 140 registers with FedHS 110, provided both entities have the necessary credentials. Upon successful communication, the EES can expose the FedHS 110 information to the EAS 130 registered with that specific EES 140. The remote telesurgery AC, operating on a robotic haptic hand as UE 120, connects to the ECS 160 via the EEC 124. It sends a service provisioning request to discover suitable EDNs 140. The ECS 160 identifies a set of available EES 140 candidates from among the various EDNs 150 and extracts the FedHS 110 address to execute the service provisioning request. Upon successful registration, the ECS 160 returns a list of suitable EDNs 150 to the EEC 124. The EEC 124 registers with a selected suitable EES 140. Following successful registration, the EAS 130 can request a QoS session with both the UE 120 and the FedHS 110. Upon establishing a successful QoS session with the UE 120 and FedHS 110, the EAS 130 updatesits model and redirects the UE 120 model to the FedHS 110. After successfully receiving updates from the FedHS 110, the EAS 130 updates its parameters, along with the global parameters for the UE 120. This workflow ensures a coordinated and efficient process for communication and service provisioning among the various components involved.

[0045] FIG. 7 is a flowchart depicting the method for enabling federated learning in a multi-operator edge environment. The operations (702-710) are handled by the system 100. At step 702, themethod includes registering the FedHS 110 witha plurality of ECS 160 belonging to different ECSPs. The FedHS (110) registers with the ECS (160) using an interface referred to as EDGE Fed2, enabling the exchange of messages related to security credentials, registration, and service agreements. At step 704, the method includes registering EES 140 with the FedHS 110 after discovery, to facilitate communication between the FedHS 110 and EAS 130. The EES (140) sends a registration request to theFedHS (110) via an interface EDGE Fedl. At step 706, the method further includes receiving locally trained model updates from a plurality of UE devices 120 and EAS 130 deployed by different ECSPs. The EAS (130)facilitates split control of haptic applications, including real-time feedback from haptic actuatorsand error correction, such as instrument slippage, processed at the edge to meet ultralow latency requirements. At step 708, the method further includes aggregating the locally trained model parameters at the FedHS 110 to create global model parameters. The FedHS (110) aggregates model parameters using a federated learning algorithm, ensuring decentralized model training while preserving the data privacy of the UE devices (120) and EAS (130) across different EC SPs. At step 710, the method further includes transmitting the global model parameters back to the EAS 130 and the plurality of UE devices 120, while maintaining data privacy between different ECSPs.

[0046] The various actions in method 700 may be performed in the order presented, in a different order, or simultaneously. Further, in some embodiments, some actions listed in FIG.7 may be omitted.

[0047] The federated learning system (100) enables data to remain on local devices, reducing the need to transfer sensitive information to a central server. By processing data at the edge, it minimizes delays associated with data transmission, which is especially beneficial for real-time applications. The system (100) can support numerous edge devices, making it scalable for widespread deployment, crucial for applications involving many loT devices. Federated learning utilizes diverse data from multiple sources, enhancing the robustness and accuracy of machine learning models. Since only model updates are shared instead of raw data, communication overhead is significantly reduced, leading to more efficient use of network resources. Additionally, processing data locally can be more energy-efficient compared to transmitting large volumes to central servers.

[0048] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device. The modules shown in Fig. 1 and 3 include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.

[0049] The embodiment disclosed herein methods for enabling federated learning in a multi-operator edge environment. Therefore, it is understood that the scope of the protection is extended to such a program and in addition to a computer readable means having a message therein, such computer readable storage means contain program code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The method is implemented in at least oneembodiment through or together with a software program written in e.g., Very high speed integrated circuit Hardware Description Language (VHDL) another programming language, or implemented by one or more VHDL or several software modules being executed on at least one hardware device. The hardware device can be any kind of portable device that can be programmed. The device may also include means which could be e.g. hardware means like e.g. an ASIC, or a combination of hardware and software means, e.g. an ASIC and anFPGA, or at least one microprocessor and at least one memory with software modules located therein. The method embodiments described herein could be implemented partly in hardware and partly in software. Alternatively, the invention may be implemented on different hardware devices, e.g. using a plurality of CPUs.

[0050] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and / or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of at least one embodiment, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the scope of the embodiments as described herein.

Claims

CLAIMSWe claim:

1. A method for enabling federated learning in a multi-operator edge environment, comprising :registering, by a system (100), a Federated Haptic Server (FedHS) (100) with a plurality of Edge Configuration Servers (ECS) (160) belonging to different Edge Computing Service Providers (ECSPs);registering, by the system (100), Edge Enabler Servers (EES) (140) with the FedHS (110) after discovery, to facilitate communication between the FedHS (110) and an Edge Application Servers (EAS) (130);receiving, by the system (100), locally trained model updates from a plurality of User Equipment (UE) devices (120) and the EAS (130) deployed by different ECSPs; aggregating, by the system (100), locally trained model parameters at the FedHS (100) to create global model parameters; andtransmitting, by the system (100), the global model parameters to the EAS (130) and the plurality of UE devices (120), while maintaining data privacy between different ECSPs.

2. The method as claimed in claim 1, wherein the EES (140) sends a registration request to the FedHS (110) via an interface EDGE Fedl.

3. The method as claimed in claim 1, wherein the FedHS (110) registers with the ECS (160) using an interface referred to as EDGE Fed2, enabling the exchange of messages related to security credentials, registration, and service agreements.

4. The method as claimed in claim 1, wherein the EAS (130) facilitates split control of haptic applications, including real-time feedback from haptic actuators and error correction processed at the edge to meet ultra-low latency requirements.

5. The method as claimed in claim 1, wherein the FedHS (110) aggregates model parameters using a federated learning technique, ensuring decentralized model training while preserving the data privacy of the UE devices (120) and EAS (130) across different ECSPs.

6. A system (100) for enabling a decentralized learning model in a multi -operator edge environment comprising:a Federated Haptic Server (FedHS) (110) configured to enable federated learning across different Edge Computing Service Providers (ECSPs);a plurality of Edge Application Servers (EAS) (130) deployed at the edge by different ECSPs, each EAS (130) configured to run haptic-based applications and provide local training data to the FedHS (110); anda plurality of User Equipment (UE) devices (120), each UE (120) comprising an Edge Enabler Client (EEC) (124) and haptic applications, configured to locally train models using data generated by haptic actuators;wherein the FedHS (110) aggregates locally trained model parameters received from the plurality of EAS (130) and UE devices (120) across multiple ECSPs via a set of communication interfaces to produce a global model while preserving data privacy.

7. The system (100) as claimed in claim 6, wherein the FedHS (110) communicates with a 5G core network (170) through an interface referred to as EDGEFed3, facilitating user plane path management, and with the Edge Configuration Server (ECS) (160) of each ECSP through an interface referred to as EDGE Fed2 for registration and discovery purposes.

8. The system (100) as claimed in claim 6, wherein the EAS (130) is configured to: perform split control of haptic devices in telesurgery applications; andprovide real-time feedback, including detection and correction of control faults such as instrument slippage, to ensure ultra-low latency and reliable control during the operation.

9. The system (100) as claimed in claim 6, wherein the UE device (120) is a robotic actuator equipped with haptic gloves, providing real-time data for local training in the context of haptic-based medical telesurgery.

10. The system (100) as claimed in claim 6, wherein theFedHS (110) is configured toaggregate model parameters using a federated learning algorithm and transmit the aggregated model back to the EAS (130) and UE devices (120) for local model updates.

11. The system (100) as claimed in claim 6, wherein the FedHS (110) comprising:a FedHS discovery and selection unit (302) configured to identify and register ECS (160) and EES (140) across different ECSPs;a FedHS receiving unit (304) configured to receive messages from ECS (160), EES (140), and 5G core (170) for discovery, registration, deregistration, and core functions;a FedHS sender unit (306) configured to send messages from FedHS (110) to ECS (160), EES (140), and 5G core (170) for similar functions;a FedHS service utility unit (308) configured to maintain a list of services offered within the scope of a particular ECS (160) and EES (140);a FedHS registration functions management unit (310) configured to manage registration, deregistration, and updates of services for EES (140) and ECS (160);a FedHS encryption unit (312) configured to encrypt updates from incoming federated clients and assigns encryption-based user IDs to ensure data privacy during federated learning aggregation across different ECSPs;a FedHS decryption unit (314) configured to decrypt weights and updates associated with specific client models; anda FedHS aggregation unit (316) configured to aggregate weights of the model belonging to specific parameters.

Images