## 4 TSN Integration with Edge Computing for Enhanced Reliability
### Single Application Instance Handling End Device Capability
#### 4.2.2 Details of the Emulation of Single TSN-FRER and Application Instance  
This section discusses the details of how the complexity of the application deployment is hidden from the industrial end device, and a single application instance is emulated.  
One part of the emulation is to guarantee that only one frame is sent to the device in a communication cycle; it means that selection of one application (as well as TSN talker/listener and FRER) instance is needed, which is used as a serving instance (note: due to fast failover, all application instances generate the control message, but only one of them will be sent to the device).  
The selection of the serving application instance can be managed in the application cluster if the application software is aware of the multiple instances. The instances should have the capability to discover themselves and communicate with each other in order to perform the selection and handle the case if the serving instance cannot work anymore.  
Figure 11: Architectural view of the single emulated application handling scenario.  
Another alternative is to handle the selection by using the emulation support functionality of the TSN IWF entities. In this case, the application instances can be agnostic to the selection coordination. In this case, the corresponding TSN talker will send the frames to the device, while the messages from the other application instance(s) are blocked by the other TSN IWF entities. If the serving application instance cannot work anymore, then the other TSN IWF entities will be informed (e.g., the cloud management can handle it, or the TSN IWFs can automatically recognize each other). Then, the selection coordination functionality of the TSN IWF instances is applied, and the message coming from the newly selected application instance is sent towards the device.  
In addition to the application coordination, the emulation of a single TSN FRER entity is also needed, which requires extensions to the existing IEEE 802.1 CB TSN FRER operation. The issue is that the replication function of the FRER uses a sequence number parameter (GenSeqNum) to identify the duplicated frames. The existing IEEE 802.1 CB specification does not allow for the free modification of the \"GenSeqNum\" parameter. However, if a change of TSN FRER instance is needed in the cloud (virtualized) domain, then the \"GenSeqNum\" parameters of the new and the old FRER instances will not be coordinated, which leads to an unnecessary frame loss.  
In order to resolve the above issue, the following improvements are discussed in the IEEE TSN working group:  
* Allow modification of the \"GenSeqNum\" parameter to any valid value in the \"BEGIN\" event, which is the global event that resets all of the FRER functions;
* A new event called \"SEQUENCE_CHANGE\" is proposed, which could be triggered via external entities or management intervention. In these cases, the \"GenSeqNum\" is set to a specific provided value.  
By using the above modifications, the seamless change between TSN FRER instances deployed in the virtualized domain can also be enabled.