## 4 TSN Network-Wide Scheduling--Approaches Overview, Challenges, and Future Directions
### Challenges for Network-Wide Scheduling
Similar problems exist in a pure TSN setup where multiple domains are involved. One example presented in [59] is the in-vehicle network where electronics and mechanical systems are distributed in domains (e.g., autonomous driving domain, power train domain, chassis domain, body domain, telematics, and infotainment). Cross-domain functionalities need the collaboration of different domain controllers. This setting brings about more challenges related to hybrid multidomain scheduling. An important challenge to solve is a potential clock mismatch. Mechanisms such as TAS require network-wide synchronization. Technologies that support time synchronization such as 5G ease the problem slightly. Ref. [114] discusses the integration of TSN and 5G. Since 5G supports multiple time domains, it could join the TSN time domain by synchronizing one of its working clocks to the TSN master clock according to the gPTP procedure. However, this is not available in other scenarios such as having two TSN domains, each having its own controller and master clock. A possibility to cope with this challenge is to have a synchronization controller that resides at the border of all the domains and belongs to all of them. The synchronization controller could solve the problem by playing a GM role. Nonetheless, the synchronization controller would be a single point of failure. Another option is to introduce time awareness to the control plane such that the CNCs exchange synchronization information and consider the time difference while calculating the cross-domain schedule. - A second challenge is related to bandwidth mismatch. In this case, the interdomain interface could be a congestion point. Ref. [94] suggests using network slicing and queue length management to mitigate this mismatch. - A third challenge is related to the configuration generation for multidomain operation. The configuration could be generated centrally once the network-wide scheduling problem is solved by only one orchestrator and distributed to all network elements. Here, the other orchestrators should share their domain information. The challenge here is that different technologies have different features and a single orchestrator controlling all is not a viable solution. For example, the central network controller (CNC) from TSN does not support 5 Gs control features such as network slicing, etc. The 3 GPP suggested a solution in release 16/17 which exposes the 5 Gs as a virtual switch to the CNC [114]. - The same logic could be applied in the general case of multidomain configuration. Suppose we have two domains, each controlled by a separate controller. In that case, we can introduce a higher-level CNC that sees each domain as a virtual switch. The domain controller must then expose the domain's resources as a virtual switch with certain capabilities. Afterward, the higher-level CNC calculates the global configuration and distributes it to controllers of the domains. Finally, each domain controller calculates and deploys the actual configurations such that it meets the configuration calculated by the higher CNC. - The previous mode of functioning combines centralized and distributed computation of configuration. However, such a hybrid mode has other challenges related to scheduling time and the control of traffic overhead. A third approach is the distributed mode, where every controller calculates the configuration of its domain locally without consulting the other controllers. This approach still needs an entity to verify the end-to-end requirement. That could be the talker and/or the listener, with the help of all the domain controllers in between. In this case, a distributed cross-domain scheduling protocol is required. As for the cross-domain scheduling algorithms, only a few works exist. For example, ref. [94] suggested a platform for cross-domain coscheduling based on CQF and CSQF (Cycle-Specified Queueing and Forwarding).