In many circumstances, an application server holding a Federated Learning (FL) task has a transmission delay requirement and limited FL coverage. An FL coverage means an area in which UEs the Application server can organize for federated learning. An Application server has a transmission delay requirement for each FL member (UE). Some of UEs are actually holding valuable dataset but cannot fulfil transmission delay requirement, which leads to a decreasing of FL performance. However, if a UE's direct network connection cannot fulfil the transmission delay requirement (i.e. an QoS on Uu), leveraging the devices with direct connections helps to involve more UEs holding valuable dataset for the FL task with the following case study: A UE-A with bad transmission condition sends a UE's training result to UE-B via direct device connection. In such case, a UE-B aggregates the training result locally and provides to UEs an update of training model for next round. Some research e.g. in [6] [7] have illustrated the increasing performance in subcase-B (we call it "decentralized averaging methods"). In order to include more devices to participate in FL and to reduce the devices' reliance on the PS, the authors in [7] uses decentralized averaging methods to update the local ML model of each device. In particularly, using the decentralized averaging methods, each device only needs to transmit its local ML parameters to its neighboring devices. And the neighboring devices can use the acquired ML parameters to estimate the global ML model. Therefore, using the decentralized averaging methods can reduce the communication overhead of FL parameter transmission.

To show the performance of decentralized averaging method, the [6] implemented a preliminary simulation for a network that consists of one BS that is acted as an application server and six devices, as shown in Figure 7.1-1. In Figure 7.1-1, the green and purple lines respectively represent the local ML parameter transmission of original FL and the FL with decentralized averaging methods. Due to the transmission latency requirement, only 4 devices can participate in original FL. For the FL with the decentralized averaging update method, 6 devices can participate in the FL training process since the devices which are out of coverage can connect to their neighbouring devices (i.e. Device a and Device b) for model updating. From Figure 7.1-1, we can see that the FL with decentralized averaging method outperforms the original FL in terms of identification accuracy. Specifically, the original FL (without using direct device connection) has an upper limit of identification accuracy to about 0.85, while using direct device connection for decentralized averaging method helps to increase the identification accuracy to about 0.88 which is actually a big optimization since the line already goes smoothly after 200 round of FL training. Besides, the FL leveraging direct device connection can also reduce the energy consumption for some devices since it only needs to transmit its ML model parameters to device instead of the BS.

As depicted in Figure-2, there is an Application server for federated learning which needs to communicate with the UEs in a FL coverage for FL task. To achieve an ideal performance (i.e. fast convergence and high model accuracy), there is a transmission latency requirement to each FL member UE's data transmission. Alice and Bob are FL members but their cell phones sometimes have bad signal condition which cannot transmit data to FL service directly. Meanwhile, Bob is willing to support the "decentralized averaging method" (as described in clause 7.1.1) service for its neighbouring cell phones. Alice, Bob are neighbouring to each other within a FL coverage.

1. Alice is a FL member and already acquires the global AI/ML model from the Application server for FL task, later on when Alice moves to a tunnel with bad signal condition, Alice cell phone's with direct device connection with her neighboring cell phone cannot transmit model data to its Application server anymore.
2. In the tunnel, Alice discovers Bob, who is neighboring to Alice, a FL member and willing to activate the "decentralized averaging method" service. Thus, Alice requests Bob to establish a direct device connection so that Alice can transmit the AI/ML model training result to Bob.
3. Bob updates the AI/ML model based on Alice's training result and Bob's local training result. And Bob sends the updated AI/ML model to Alice for further training.

When Bob moves to a good coverage and is able to transmit the AIML training model (e.g. after several rounds of AIML model parameters exchange between Alice and Bob have been done), Bob transmits the training result to Application server to assist the Application server to perform a global model updating.

By leveraging direct device connection, Alice and Bob can keep the model training of a FL task even when they are under a bad network coverage. And the training result between Alice and Bob can be further uploaded to Application server for global model updating. Thanks to leveraging direct device connection, it helps FL to be performed even when no communication availability to FL server. Such use case helps to optimize the FL performance.

In clause 6.40.2 of TS 22.261 v18.6.1