## 2 R-SpaceFibre Design: Features and Trade-Offs
### R-SpaceFibre Data Link Layer  
This section describes the proposed architecture of R-SpaceFibre Data link layer. A simplified architectural block diagram of the layer is shown in Figure 3. R-SpaceFibre major innovation is the exclusion of the retry mechanism from the protocol stack. The first consequence is that none of the Data Retry Buffer, the Broadcast Retry Buffer or the FCT Retry Buffer has to be included in the R-SpaceFibre Data link layer, with consistent savings of logical resources. This comes at the price of no data-retry if an error occurs with consequent data loss. However, the system is designed to continue the communication process, and a corrupted datum is passed to the higher level of the protocol. In fact, target applications such as SAR imagers can withstand the corruption of a single bit or the loss of a data word. The SpaceFibre CODEC properly works with a maximum Bit Error Rate (BER) of \(10^{-5}\)[11]. However, typical BERs for satellite applications are in the order of \(10^{-10}\), which is much lower than the worst case handled by the SpaceFibre protocol. The application system engineer will decide whether complexity reduction at the price of data retry removal is acceptable for their application, depending on link criticality, orbit (BER), etc.  
R-SpaceFibre is designed mainly for point-to-point communication. For this reason, the broadcast service, responsible for sending short messages to all the nodes of a network, is unnecessary. Thus, _In_ and _Out BCBs_ have been excluded from the architecture. The removal of retry and broadcast services implies that also all QoS mechanisms (i.e., VCs scheduling and bandwidth reservation) become less complex, thus the MAC can be simplified.  
The CRC Check block has been removed from the Rx Block: consequently, the IP core is no more able to signal to the far-end if received data frames or control words are corrupted. The near-end needs to acknowledge also corrupted data frames, so that compatibility with a full implementation of the standard at the far-end is maintained. More details about R-SpaceFibre compatibility with a full SpaceFibre interface are provided in Section 2.3. On the contrary, the CRC on the Tx Block cannot be removed: it has to be maintained in order to be compatible with the SpaceFibre protocol. Indeed, a standard SpaceFibre endpoint always performs CRC check on received data frames and control words; without it, the CODEC would automatically consider all received data as corrupted. Nevertheless, the  
Figure 3: R-SpaceFibre data link layer block diagram.  
CRC block could be excluded from the Tx Block if the R-SpaceFibre just needs to communicate with R-SpaceFibre nodes. The proposed design includes optional data scrambling on both Tx and Rx side.  
The SpaceFibre standard establishes that the number of VCs shall to be between 1 and 32. R-SpaceFibre can handle an arbitrary number of VCs, but, to reduce the impact on resource usage, the number of VCs shall be limited to one or two. In particular, by choosing to use only one VC the QoS is drastically reduced, together with the multiplexing logic between VCs and the lower part of the Data link layer. Both standard and literature [17] suggest that the QoS could be completely eliminated in an implementation of just of one or two VCs, but this implies that babbling node protection is not provided [2].  
Finally, VCs dimension is set to be 256 data words, which is the minimum dimension according to the standard. In conclusion, the most relevant design changes in the R-SpaceFibre development are the removal of:  
* [noitemsep,topsep=0 pt]