esa-sceva/satcom-chunk-collection huggingface dataset:
## 2 Clouds Properties from Infrared and Microwave Satellite Observations
### Infrared Observations Only
\begin{table}
\begin{tabular}{c c c c c c} \hline \hline  & & \multicolumn{3}{c}{**Satellite**} & \\ \cline{3-5}
**Authors** & **Year** & \multicolumn{1}{c}{**Sensor**} & \multicolumn{1}{c}{**Channel Frequency**} & \multirow{2}{*}{**Main features**} & \multicolumn{1}{c}{**Uncertainty or Accuracy**} \\  & & & **[GHz]** & & **of the Method (When** \\  & & & & **[GHz]** & & **Declared/Applicable)** \\ \hline [PERSON] et al. [66] & 2004 & IR sounder & - & COT, effective & \multirow{2}{*}{5\% \textless{RMSE}_{\text{COT,\%}}<20\%} \\ [PERSON] et al. [60] & 2004 & AIRS & - & COT & - \\  & & & Synergistic use & & \\ [PERSON] et al. [67] & 2005 & AIRS, MODIS & - & of MODIS and & \\  & & & AIRS cloud & - \\  & & & products & \\  & & & Cloud & \\ [PERSON] et al. [68] & 2007 & Ultra-spectral & - & microphysical & - \\  & & IR sounder & & parameters & \\ [PERSON] et al. [69] & 2009 & IASI & - & Cloud properties & - \\  & & & Cloud detection, & \\ [PERSON] et al. [70] & 2012 & IASI & - & fractional & - \\  & & & & coverage, height & - \\  & & & & and phase & \\ [PERSON] et al. [71] & 2013 & - & - & assimilation & - \\  & & & & system & \\ [PERSON] et al. [73] & 2014 & IASI & - & assimilation & - \\  & & & & system & \\ [PERSON] et al. [76] & 2017 & IASI & - & Thin clouds & ACC\({}_{\text{CPH,\%}}>97\%\) \\ Feofilov and Stubenrauch [77] & 2017 & AIRS & 15 & Cloud properties & - \\  & & AMSR-E, & & & \\ [PERSON] and [PERSON] [78] & 2018 & CloudSat, & - & Mixed-phase & BIAS\({}_{\text{LWP,mixed clouds}}\cong\) 5.7 g/m\({}^{2}\) \\  & & & CALIPSO, & & clouds & 5.7 g/m\({}^{2}\) \\  & & MODIS & & & Cloud-top and \\ [PERSON] et al. [79] & 2017 & MODIS & - & optical & - \\  & & & & properties & \\  & & & & Cloud & \\ [PERSON] et al. [44] & 2020 & - & - & microphysical & - \\  & & & & parameters & \\  & & & & Single-layer & \\ [PERSON] et al. [80] & 2008 & MODIS & - & cloud-top & - \\  & & & & pressure & \\ Cox and Munk [89] & 1954 & - & - & Sunglint in cloud & - \\  & & & & retrieval & - \\ [PERSON] et al. [88] & 1997 & - & - & Sunglint in cloud & - \\ [PERSON] and [PERSON] [90] & 1986 & - & - & retrieval & - \\ [PERSON] and Bailey [91] & 2001 & - & - & Sunglint in cloud & - \\  & & & & retrieval & - \\ [PERSON] and & & & & Sunglint in cloud & - \\ [PERSON] [92] & 2018 & - & - & Sunglint in cloud & - \\ [PERSON] et al. [81] & 2020 & - & - & Optically thick & - \\  & & & & clouds & \\ \hline \hline \end{tabular}
\end{table} 
Table 2: _Cont._
# A New Kinematic Model of Portable Articulated Coordinate Measuring Machine
## 2 Model
### Generalized Geometric Error Theory  
To describe the kinematic model of PACMM, the transformation matrix of the coordinate frame \(f_{i}^{ideal}\) with respect to \(f_{i-1}^{real}\) is indicated by using D-H's 4 \(\times\) 4 matrix \({}_{i}\). Figure 1 shows the transformation relationship between the coordinate frame \(f_{i-1}^{real}\) and \(f_{i}^{real}\). However, the actual geometric parameters of the coordinate frame \(f_{i}^{ideal}\) with respect to \(f_{i}^{real}\) for PACMM exists the slightly deviations from the nominal values because of the existence of machining errors, assembly errors, link deformation and so on. The transformation relationship between the coordinate frame \(f_{i}^{ideal}\) and \(f_{i}^{real}\) is shown in Figure 2. Therefore, the coordinate frame \(f_{i-1}^{real}\) transformed to \(f_{i}^{real}\) would need two steps: Firstly, the homogeneous transformation matrix \(A_{i}\) would be obtained by the coordinate frame \(f_{i}^{ideal}\) with respect to \(f_{i-1}^{real}\) ; Secondly, the homogeneous transformation matrix \(E_{i}\) would be obtained by the coordinate frame \(f_{i}^{real}\) with respect to \(f_{i}^{ideal}\). Equation (2) follows:  
\[E_{i}=Rot\left(x_{i},\varepsilon_{i4}\right)Rot\left(y_{i},\varepsilon_{i5} \right)Rot\left(z_{i},\varepsilon_{i6}\right)Trans\left(\varepsilon_{i1}, \varepsilon_{i2},\varepsilon_{i3}\right) \tag{2}\]  
where the three parameters \(\varepsilon_{i1},\varepsilon_{i2},\varepsilon_{i3}\) indicate the translation values from the origin \(O_{i}^{\xi}\) to \(O_{i}^{\Re}\) in the frame \(f_{i}^{ideal}\) along the \(X\), \(Y\) and \(Z\) axes, respectively. The other three parameters \(\varepsilon_{i4},\varepsilon_{i5},\varepsilon_{i6}\) represent the Euler angles of the coordinate frame \(f_{i}^{real}\) with respect to \(f_{i}^{ideal}\) in the Figure 2.  
Figure 1: Frame translation and rotation due to the errors for the \(i^{th}\) link.  
In the Equation (2), the six parameters \(\varepsilon_{i1},\varepsilon_{i2},\varepsilon_{i3},\varepsilon_{i4},\varepsilon_ {i5},\varepsilon_{i6}\) are generally called the generalized geometric error parameters. To simplify the calculation process, the matrix \(E_{i}\) is approximately represented by the [PERSON]'s formula expansion of the Equation (2). The first order values of expansion formula only remain because the coordinate frame \(f_{i}^{real}\) slightly deviates from \(f_{i}^{ideal}\). Therefore, the matrix \(E_{i}\) is rewritten as the Equation (3):  
\[E_{i}=\left[\begin{array}{cccc}1&-\varepsilon_{i6}&\varepsilon_{i4}& \varepsilon_{i1}\\ \varepsilon_{i6}&1&-\varepsilon_{i5}&\varepsilon_{i2}\\ -\varepsilon_{i4}&\varepsilon_{i5}&1&\varepsilon_{i3}\\ 0&0&0&1\end{array}\right] \tag{3}\]  
The matrix \(B_{i}\) called the generalized geometric error matrix and indicates the transformation matrix of the coordinate frame \(f_{i}^{real}\) with respect to \(f_{i-1}^{real}\).  
\[B_{i}=A_{i}E_{i} \tag{4}\]
## 4 The Used Simulation Environment and Our Model Extensions  
### Static MCO Implementation in Artery  
Artery, an extended ITS-G5 model collection for INET/OMNeT++, already has the basic extensions needed to implement MCO [36]. Until this MCO model was deployed in Artery, modelers only checked if the Router class was assigned to the Middleware. If so, the packet was simply sent out on its only interface. A few years ago, modifications were added to allow users to statically select the channels they want to use before the simulation begins. For each scenario, we need to provide an application XML description file (_services.xml_) containing the type of systems to test and the ports they listen on. With the static MCO feature, a channel field was added where you can define the identifier of the channel that will be used in the simulation. This is how the Middleware component will know which channel to put the listener assigned to that application on. In addition, another XML file is needed (_mcoPolicy.xml_) where you can tell the Artery's Middleware which channels you want to use in the simulation and which are the default CCH and the secondary SCH channels. This Middleware is the component that plays a central role in transmitting and receiving ITS-G5 messages in Artery. This is where we initialize the objects in the Facility layer and the applications used during the simulation. When a message is about to be sent out, the _requestTransmission_ function defined here will be executed. In this case, the request function of the Router class assigned to the Middleware will be called inside the function. It will first compose the PDU of the packet, based on the type of the message to be sent and the transport protocol information given in the parameter, provide it with security headers, and then send it out to the lower layers.
## 8 Application and Discussion of the Results
### Application on SSI
#### 8.1.2 Application Layer  
Although smart contracts can be applied in SSI, they are, at least currently, most likely not used in SSI infrastructures. The literature focuses on Solidity, the programming language of Ethereum. Based on the statistics provided in Section 5, we notice a decline in publications on that topic. Hence, most threats outlined in Section 6.3 could be applied to SSI but are less relevant. One exception is the threat of transaction irregularities, which could work on SSI. Following, the threats on the application layer have to be regarded.
## 5 Applications of THz-FSO Communication
### 6G and Beyond  
THz-FSO systems are primary candidates for augmenting 6G networks, as they represent a shift in the paradigm of telecommunication due to providing ultra-low latency, a high-capacity, and low energy consumption. Modern-day applications for which THz-FSO systems are essential in terms of data and latency include holographic telepresence, autonomous vehicle coordination, and industrial automation [43, 45, 57, 99].  
THz-FSO systems, in the context of 6G networks, provide the ULLC owing to the high spectral efficiency of the optical link. This makes them suitable for use in applications such as real-time augmented and virtual reality applications as well as in smart city applications. In addition, the THz-FSO system, which supports multi-6G device connectivity with lesser interference, complements the vision of 6G [57; 58].  
One technological innovation in this area is the utilization of terahertz polymer vortex photonic crystal fibers that guarantee the stable transmission of orbital angular modes. Introducing these fibers enhances the capability and reliability of 6G backhaul networks and will create grounds for new ways of incorporating THz-FSO links [100]. Furthermore, the utilization of multifunctional integrated chips for the THz-FSO link also minimizes the power consumption of the system and, therefore, minimizes the operational costs, leading to faster growth of these systems in future networks [8; 42].  
As the need for a higher data rate and more connectivity increases, THz-FSO communication will continue to spearhead technological advancement in telecommunication.
# An Efficient Library for Reliability Block Diagram Evaluation
## 3 RBD Computation Library-librbd
### librbd Usage
#### 3.3.3 Example of librbd Usage  
Let us consider the system shown in Figure 1. Since components C1 and C2 are identical in parallel configuration, the reliability curve of this first block can be computed by invoking rbdParallelIdentical. Finally, the reliability of the whole system can be computed through a series block with components C3 and C4 and the reliability of the previously evaluated parallel block by invoking rbdSeriesGeneric.  
Listing 1 shows the C source code used to implement and analyze the described system. The reliability curves of all components are evaluated over \(T=10\) time instants. The source code, through the consecutive invocation of two different librbd APIs, evaluates the reliability of the whole system. Finally, the evaluated reliability is printed to the standard output.  
The C source code related to the described example and shown in Listing 1 has been compiled and executed. Its output is shown in Listing 2.
## 2 Materials and Methods
### Clinical Data  
Ten clinical patients with advanced oropharyngeal cancer who underwent radiotherapy at our institution were randomly selected from the departmental database. All the plans used volumetric modulated arc therapy (VMAT, RapidArc) to treat three targets at dose levels of 69.96, 59.40 and 54.45 Gy in 33 fractions, with a simultaneous integrated boost generated with an Eclipse Treatment Planning System (TPS) v.13.6 (Varian Medical Systems, Palo Alto, CA, USA). Bilateral neck irradiation was delivered to all the patients, with involved high-dose PTV on the right side for six patients, the left side for two patients, and centrally for the remaining two patients. For each treatment fraction, a CBCT scan was acquired, using the clinical HN protocol, before delivering treatment to assess the patient setup and anatomical variation. All the CBCT images were automatically saved in an ARIA database (Varian Medical Systems, Palo Alto, CA, USA). The published studies have shown that the anatomic changes in HN cancer patients are more pronounced in the first half of treatment [25] and, based on our clinical institute experience, that re-planning requests are often performed in the second half of treatment. Hence, for each patient, the CBCT scans performed around the middle (fraction #16) and latter parts of the treatment course (fraction #26) were extracted from the imaging database for further analysis.
## 5 Experimental Result
### Accuracy vs. First-Order Hyper-Parameters  
As introduced in Section 2, to study the impact of the eLSNNs hyper-parameters and flavours on the accuracy, we conducted an exhaustive search. We evaluated the accuracy as the Matthews Correlation Coefficient (MCC) on the test set, which includes all the samples related to vehicle passages on the bride section during a randomly chosen day before and after the scheduled maintenance intervention.  
In Figure 9, we report on the y-axis the network accuracy measured as MCC. We limited the plot to those hyper-parameters configurations leading to eLSNNs with an MCC \(\geq 0.6\). This corresponds to an accuracy of 0.77. Moreover, in the same figure, we draw the line at the MCC = 0.75. We consider all the eLSNNs configurations achieving an MCC higher than 0.75 as acceptable or \"good\" configurations. This threshold corresponds to accuracy above 0.88.  
On the x-axis, we report three sets of plots. Each set corresponds to different inference ticks (\(t_{inf}=5,10,20\)). Inside each set, the left plot refers to the current-driven eLSNN, and the right plot refers to the event-driven eLSNN. Inside each of these plots, we report the eLSNN configurations achieving a MCC \(>0.6\). The percentage of these configurations on the total evaluated (1728 for each eLSNN flavour) is reported in the text on each plot's bottom. The MCC accuracy of each configuration is reported with red bins for an input number of 50 and with blue bins for an input number of 150 bins. In the SHM application, the input number (\(I\)) corresponds to the magnitude of the spectral components of the FFT. It thus is equal to the double of the accelerations samples, which needs to be read by the sensor to compute an eLSNN inference.  
The combination of these parameters (\(t_{inf}\)&\(I\)) constitutes the first-order hyper-parameter that, as we will see in the next section, impact the inference execution time of the eLSNNs and then their energy consumption. From the figure, we can notice that for the current-driven eLSNNs, the largest number of acceptable configurations is achieved for an input number (\(I\)) of 50. Which also corresponds to the lower complexity of the eLSNN computations (see Section 4). Differently, for the event-driven eLSNNs, acceptable configurations can be achieved only with an input number (\(I\)) of 150. As we will see in Section 5.4, this has a severe drawback on the pre-processing cost for this eLSNN flavour. It is also worth to note that for the current-driven eLSNNs the accuracy improves with larger inference ticks, having any acceptable configurations with \(I=50\) and \(t_{inf}=5\) but several with \(I=50\) and \(t_{inf}=10,20\). However, this is not the case for the event-driven eLSNNs for which their MCC does not improve significantly with progressive \(t_{inf}\) increases. It is now interesting to evaluate these parameters' impact in terms of eLSNN inference execution cycles.
## 1 Introduction
The goal of this work is to summarize all recent developments regarding the design of an architectural framework for 6G networks. In this context, the most important challenges towards the 6G vision are described, as well as the basic concepts of the most important functionalities among different layers. In the same perspective, several recent works are presented as well, while a discussion takes place that summarizes all key outcomes of this work. The rest of this work is organized as follows: In Section 1.1 of the introductory part, related survey papers are discussed, along with their key contributions. The contributions of our work are mainly highlighted in Section 1.2. In Section 2, the most important key 6G-enabling technologies are presented. These include decentralized and distributed ML for resource optimization and threat mitigation, cell-free implementations, advanced physical-layer protocols, interconnection of a vast number of heterogeneous devices with open access protocols, and blockchain technology and digital twins (DTs). In Section 3, various recent architectural approaches are highlighted and discussed with respect to the aforementioned key pillars. An overall discussion takes place in Section 4, while concluding remarks are highlighted in Section 5. For illustration purposes, the paper structure is also depicted in Figure 1.
## 2 Problem Background
### Need for Routing Fairness in OppNets
#### 2.1.3 Fair Routing as an Augmentation for Energy Awareness  
Energy level is an essential indicator of a node's ability to partake in routing. With regards to routing, energy awareness ensures that nodes have sufficient energy before entrusting them with routing tasks. However, it is important to note that routing is not the only source of energy consumption on nodes. Nowadays, portable handheld devices are used for numerous energy consuming purposes including communication, entertainment and task-oriented activities. The implication is that energy awareness cannot actually ensure fair routing in OppNets. This is because nodes with higher energy levels are more likely to be selected as forwarders, despite: (i) being already overused by the network (for instance, A, a popular device that is frequently recharged, is prone to becoming even more burdened); or (ii) their inability to contribute (e.g., B, a device with higher battery level but less chances of delivering the message). This may either be worrying to users or degrade throughput. Fair routing not only distributes resource utilization among networking nodes (thereby assuring the user that A would not be overused by the network whenever it is recharged), but is also tasked with ensuring that even less popular nodes (such as B) are able to contribute towards improving throughput. Therefore, fair routing augments energy awareness in OppNets.
## 7 Results and Recommendations  
This section summarizes the results of the evaluation and comparison of both guides. Furthermore, areas for possible improvements are given. Table 10 shows the results and recommendations for the NIST guide derived from the evaluation of topicality, completeness and depth. Table 11 does the same for the BSI guide. The NIST guide should improve in topicality. Published RFCs on IPv6 since 2010 should be considered for coverage. There are also newer versions of some RFCs, which should be updated and changes should be checked and included into the guide as well. Some of the covered transition methods are outdated and should be considered for removal from the guide. NIST is recommended to take new developments, IETF standards, and security breaches relevant for IPv6 deployments into account in order to keep the guide up to date. Since the guide already features a very high completeness, it is only recommended to keep an eye on new developments, so that this score would stay high in future versions of the guide. From the viewpoint of content depth, the guide could improve by incorporating practical examples for concrete infrastructures and distinguishing between different security requirements. This is one important feature of the BSI guide that could increase the quality of the NIST guide as well. There are some areas where depth could still be positively increased by extending explanations or providing better examples. These areas are DHCPv6, ND, IPsec, DNS security issues, Routing Protocols, and  
Figure 13: Average depth of transition methods. \begin{table}
\begin{tabular}{|l|l l l|} \hline
**Category** & **Weight** & **BSI** & **NIST** \\ \hline
**Specification and Address format** & 0.22 & 0.10 & 0.19 \\
**IPsec and ICMPv6** & 0.14 & 0.03 & 0.12 \\
**DHCPv6 and Autoconfiguration** & 0.21 & 0.06 & 0.18 \\
**Routing and DNS** & 0.24 & 0.06 & 0.17 \\
**Transition Methods** & 0.20 & 0.07 & 0.15 \\
**Total** & 1.00 & 0.32 & 0.81 \\ \hline \end{tabular}
\end{table} 
Table 9: Comparison of weighted completeness. Dual Stack. Depth of the coverage of ICMPv6 specification could be decreased since the discussion is rather extensive. As Table 11 shows, topicality of the BSI guide is good because the new version was published more recently. It is only recommended to check for new relevant security breaches and IETF standards on regular basis to keep the guide up to date. Completeness, however, is very low throughout the guide, as the guide focuses on only the most relevant RFCs, technologies, and methods. Nevertheless coverage of IPsec, DHCPv6, DNS security issues, Multihoming, Dual Stack, and Tunneling should be increased. Cryptographic Methods and DNSSEC, which are not covered so far, should at least be mentioned in order to let readers know about their existence.
## 5 Discussion
### Score Analysis of the Models  
\"Score\" analysis was used to evaluate model development and testing for FV prediction effectiveness [38]. Each predictive metric was assigned a numerical value, with the top performing model receiving a score of 4 (because there are four models under consideration). On the other hand, the lowest scoring model received a score of 1. Cumulative scores were used to assess predictive prowess. Scores were derived for both training and testing subsets, and were combined to generate a total score value for each of the four models (Table 6). The score analysis results are illustrated in a radar diagram (Figure 11). The total score values rank the models RBFNN-GO (best) > MELM-GO > RBFNN > MELM (worst), despite the RBFNN model achieving a higher score than the MELM-GO model regarding the testing subset. These results suggest that the OFI model ranking is more meaningful than the total score model ranking in terms of relative model generalizability. The scoring method is assigning too great of a weight to the results of the training subset.  
\begin{table}
\begin{tabular}{l l l l l l l l l} \hline \hline
**Models** & **Subset** & **ARE** & **RMSE** & **RRMSE** & **R2** & **PI** & **a20-Index** & **Score** & \begin{tabular}{l} **Total** \\ **Score** \\ \end{tabular} \\ \hline MELM & \begin{tabular}{l} Train \\ Test \\ \end{tabular} & 1 & 1 & 1 & 1 & 1 & 2 & 7 & 16 \\ \hline RBFNN & \begin{tabular}{l} Train \\ Test \\ \end{tabular} & 1 & 2 & 2 & 2 & 2 & 1 & 10 & 29 \\ \hline MELM-GO & \
\begin{tabular}{l} Train \\ Test \\ \end{tabular} & 1 & 3 & 3 & 3 & 3 & 3 & 16 & 31 \\ \hline RBFNN-GO &
\begin{tabular}{l} Train \\ Test \\ \end{tabular} & 1 & 4 & 4 & 4 & 4 & 4 & 21 & 43 \\ \hline \hline \end{tabular}
\end{table}
Table 6: Score analysis results of developed models in relation to individual performance metrics and cumulative scores for training and testing subsets combined to provide an overall total score value for each standalone ML and HML FV prediction model.  
\begin{table}
\begin{tabular}{l l l l l} \hline \hline
**Models** & **MELM** & **MELM-GO** & **RBFNN** & **RBFNN-GO** \\ \hline OFI & 0.0965 & 0.0383 & 0.0455 & 0.0327 \\ \hline \hline \end{tabular}
\end{table}
Table 5: Calculated OFI values for developed models applied to the FV datasets.