Content for  TR 22.876  Word version:  19.1.0

In a modern factory, a team on a workstation comprises two human operators, two mobile robots and a fixed robot. Everyone has his own pre-defined task. Robots assist the human operators by accomplishing painful tasks in a fluid and precise manner; they also monitor that the workstation environment remains safe for the human operators. The mobile robots must not interfere with humans and between them. The robot control is not executed on a distant server in the cloud because reliability and confidentiality were not ensured at a sufficient level. Furthermore, as stated in [14], the overall end-to-end latency is not always guaranteed which can cause production loss. Communications between robots can rely on private wireless networks in the factory that enable expected QoS (reliability, throughput, and latency) as well as confidentiality. The new robots are autonomous robots that can react to human voices or learn in real-time what operators do. They can perceive their environment and transmit information to other robots. They can communicate, learn from each other, assist each other and do self-monitoring. The autonomous robot's skills rely on several AI/ML models running on the robot itself which has the inconvenience that the mobile robot's battery drain quicker. To overcome this issue, when the battery level reaches a certain value, a part of the AI/ML model can be transferred to a service hosting environment and / or to another robot by splitting the AI/ML model as defined in [20]. The split model approach of [20] is applicable to a UE-to-UE (or robot-to-robot) architecture. Thus, the AI/ML model M is split and shared between (e.g.) 2 robots, say an assisted robot and an assistant robot. Intermediate data generated by the assisted robot are transferred to the assisting robot which finalizes the inference and transmits the results back to the assisted robot. This intermediate data transfer must be extremely efficient in terms of latency and throughput. When many models are at stake, the split model method is an additional challenge for the 5GS in terms of throughput, latency and synchronization. Because they are more autonomous, mobile and smart, the industry 4.0 robots embed a large variety of sensors that generate huge amount of data to process. Table 5.2.1-1 reflects that variety. Each type of sensing data requires a different AI/ML model. Each of these models produce predictions in a certain delay and with a certain accuracy. Thus, as an offloading strategy, we can imagine that a model is split between 2 robots because it has been established that for a particular AI/ML model, the latency with the sidelink communication was better (smaller) than with the regular 5G communication path, as stated in [12] and [13]. At the same time, other AI/ML models are split between the robot and the service hosting environment because from an energy standpoint this configuration is the best. Table 5.2.1-2 is an example of this offloading strategy where four AI/ML models are split between a robot and the service hosting environment and four other AI/ML models are split between two robots. Sidelink and 5G communication paths are complementary from an AI/ML model split policy standpoint. Table 5.2.1-1 shows some typical and diverse AI/ML models that can be used on robots. For each model, all the split point candidates have been considered and only the split points that generate the minimum and the maximum amount of intermediate data have been noted.

In Table 5.2.1-2 the AI/ML models are distributed between the service hosting environment and the proximity robot. The way the models are distributed is out of scope of this use case and depends on various criteria as said previously. Therefore, the next Table is an example that illustrates the distribution. The intermediate data size is presented with the range [Min - Max], where Min and Max are respectively the sum of the Min values and the sum of the Max values of the selected models as defined in Table 5.2.1-1 (figures in bold).

As previously said latency is a critical requirement. Figure 5.2.1-3 summarizes the latency cost in three scenarios:

1. The inference of model M is done locally. Latency is denoted LLI.
2. The inference process is fully offloaded on a second device (Robot/UE). Latency is denoted LFO.
3. The inference process is partially offloaded on a second device (Robot/UE). Latency is denoted LPO.

The current Use Case promotes the scenario (C) where a model M is split in two sub-models Ma and Mb. If both robots (UEs) have a similar computing power, the assumption is that the latency due to the inference of model M is almost equal to the latency of model Ma plus the latency of model Mb. Hence, once the split model is deployed on the two robots (UEs), the aim is to minimize the E2E latency and to be as close as possible to the non-split case. This is done with a transfer delay of both the intermediate data and the inference results as small as possible. We can note that if the computing power on the assistant robot is more important, then scenario (C) would be the preferred scenario. In scenario (B), the inference process is fully offloaded on the assistant robot (UE). The major inconvenience is the strong and negative impact on latency of the raw data transfer towards the assistant robot.

Two human operators are working. Two mobile AI-driven robots (A_robot and B_robot) and one static AI-driven robot (C_robot) assist them. The three robots (A_robot, B_robot and C_robot) belong to the same service area, embed the same two powerful AI/ML models M1 and M2, sensors (e.g. LIDAR, microphone) and cameras (e.g., 8K videos stream). A_robot and B_robot are powered with a battery and C_robot with fixed ground power. The three robots (A_robot, B_robot and C_robot) are connected, e.g., to the AF, 5GC, or to each other using D2D technologies (Prose, BT, WiFi, etc.). The workstation is equipped with camera and sensors. The service area is 30 m x 30 m and the robot speed is at maximum 10 km/h. The service area is covered by a small cell and a service hosting environment is connected and can support AI/ML processes.

1. B_robot battery level is rather low but it can still work for a while if a part of its machine learning process is offloaded.
2. B_robot broadcasts a request message to get assistance. C_robot and the service hosting environment responds positively.
3. B_robot negotiates with C_robot and the service hosting environment what parts of M1 and M2 respectively for the inference process they are in charge of, knowing that the quality of the prediction must not be under a certain level and that the end-to-end latency must not be above a certain value. M1 model is split between B_robot and the service hosting environment. M2 model is split between B_robot and C_robot.
4. B_robot, C_robot and the service hosting environment agree on split points for both M1 and M2 models and B_robot starts sending the intermediate data to C_robot and the service hosting environment.
5. C_robot infers and transmits using unicast mode with a very short delay the predictions back to B_robot. The service hosting environment infers and transmits using unicast mode the predictions back to B_robot in a very short delay.
6. In the meanwhile, A_robot is carrying a load to the operator A_operator.
7. A_operator bends down to pick up a screw that has fallen on the floor. At the same time B_operator is passing between A_operator and A_robot. A_robot can't see A_operator anymore.
8. B_robot is busy with another task, but it can observe the scene. It reports the scene as intermediate data to C_robot and the service hosting environment.
9. C_robot and the service hosting environment amend the ML model based on the new training data.
10. C_robot and the service hosting environment infer and then transmit in unicast the prediction back to B_robot. The safety application on the service hosting environment collects the inference results.

Intermediate data can be exchanged between two robots (UEs) and / or service hosting environment, and the robot with a low battery level can continue working for a while. All the robots in the group receive the alert message and react:

1. They all stop working; or
2. A_robot changes its trajectory.

A_operator and B_operator can work safely. The huge amount of data that is required for inferring is kept local in the factory.

The Use Case can rely on the Proximity Service (ProSe) services as defined in TS 23.303. Cyber-Physical Control Applications, see TS 22.104, already proposes to rely on a ProSe communication path. The proposed requirements are limited in terms of data transfer as shown in Table 5.2-1, where the message size does not exceed a few hundred of Bytes (250 kB at maximum). Clause 6.40 of TS 22.261 provides requirements for AI/ML model transfer in 5GS. The requirements in this clause does not consider requirements for direct device connection. In TS 22.261 Table 7.6.1-1, the max. end-to-end latency is 10 ms, the maximum data rate is [1] Gbits/s and reliability is 99.99% for Gaming or Interactive Data Exchanging.

These requirements partially cover the current Use Case needs.