esa-sceva/satcom-chunk-collection huggingface dataset:
## 3 Understanding Data Analysis for IoT
### Overview of Data Analysis Techniques Relevant to IoT  
The unprecedented volume, velocity, and variety of data generated by IoT devices necessitate the application of diverse data analysis techniques to extract meaningful information. Here are some key techniques relevant to IoT (Figure 4):  
* Descriptive Analysis: This technique is used to understand and summarize the data in a meaningful way, providing insights into past occurrences. It includes simple data aggregations, such as mean, median, mode, and more complex ones, such as correlation and standard deviation [62].
* Diagnostic Analysis: This form of analysis aims to identify the cause of a particular outcome. It often involves more in-depth data exploration techniques, including data mining and correlations.
* Predictive Analysis: By utilizing statistical techniques and machine learning models, predictive analysis can forecast future events based on historical data. Techniques such as regression, time series analysis, and various machine learning algorithms fall under this category [63].
* Prescriptive Analysis: This advanced form of analysis recommends actions to take for optimal outcomes. It utilizes a combination of techniques, including simulation, optimization, and decision-tree algorithms, to provide actionable insights [64].
* Real-time Analysis: This type of analysis is crucial in IoT setups where immediate processing of data is required. It enables the system to respond instantaneously to changing circumstances, which is critical in applications such as collision avoidance in maritime navigation [65].
* Machine Learning and AI: Machine learning and AI algorithms play a significant role in analyzing IoT data. From supervised learning techniques for predictive analysis to unsupervised learning for pattern discovery and anomaly detection, these techniques provide valuable insights and predictions [66].
* Big Data Analytics: Given the volume of data generated by IoT devices, big data analytics techniques are often employed. These techniques can handle large data sets, ensuring efficient storage, processing, and analysis of data [67].  
Each of these techniques plays a unique role in the data analysis process and can be employed individually or in combination depending on the specific needs and objectives of the IoT application in question.
###### Abstract  
This paper presents a study on the suitability and accuracy of detecting structural cracks in brick masonry by exploiting the breakage of ordinary silica optical fibers bonded to its surface with an epoxy adhesive. The deformations and cracking of the masonry specimen, and the behavior of pilot optical signals transmitted through the fibers upon loading of the test specimen were observed. For the first time, reliable detection of structural cracks with a given minimum value was achieved, despite the random nature of the ultimate strength of the optical fibers. This was achieved using arrays of several optical fibers placed on the structural element. The detection of such cracks allows the degree of structural danger of buildings affected by earthquake or other destructive phenomena to be determined. The implementation of this technique is simple and cost effective. For this reason, it may have a broad application in permanent damage-detection systems in buildings in seismic zones. It may also find application in automatic systems for the detection of structural damage to the load-bearing elements of land vehicles, aircraft, and ships.  
structural health monitoring; seismic assessment; detection of structural cracks; masonry buildings; optical fiber; distributed optical fiber sensors Article
# Cognitive Routing in Software-Defined Underwater Acoustic Networks
## 2 Related Work
Consequently, combining cognitive principles with routing schemes to design an algorithm for cognitive acoustic software-defined underwater networks has not yet been considered. This is the first work implementing a cognitive routing protocol in an SDUN that simultaneously considers spectrum sensing and routing for underwater communications. A comparison of all schemes described in this section is given in Table 1.
## 2 The System Model of LDPC
### Simplified Design of the Hamming Distance Coefficient  
Let \(\mathbf{z}^{(k)}=(z_{0}^{(k)},z_{1}^{(k)},\cdots,z_{n-1}^{(k)})\) be the hard-decision information at the \(k\)-th iteration. At the same time, define the syndrome vector \(\mathbf{s}^{(k)}\) at the \(k\)-th iteration by:  
\[\mathbf{s}^{(k)}=\mathbf{z}^{(k)}H^{T}=(s_{0}^{(k)},s_{1}^{(k)},\ldots,s_{m-1}^{(k)}) \tag{3}\]  
Figure 1: The factor graph model of LDPC.  
Here, \(s_{i}^{(k)}\) represents the adjoint information of the \(i\)-th check node, which can be expressed as Equation (4). \(\mathbf{z}^{(k)}\) is a valid codeword if \(\mathbf{s}^{(k)}=\mathbf{0}\).  
\[s_{i}^{(k)}=\sum_{j\in N_{i}}h_{i,j}z_{j}^{(k)} \tag{4}\]  
Let \(\sigma_{i,j}^{(k)}\) be the extrinsic information (EXI) from check node \(C_{i}\) to variable node \(V_{j}\), which can be defined by:  
\[\sigma_{i,j}^{(k)}=h_{i,j}^{-1}\sum_{j^{\prime}\in N_{i}\setminus j}h_{i,j}z_{ j^{\prime}}^{(k)} \tag{5}\]  
In Equation (5), \(0\leq i\leq m-1\) and \(j\in N_{i}\). The check nodes only need to pass the EXI to its adjacent variable nodes in each iteration.  
For the \(j\)-th variable node, \(\overline{d}(z_{j}^{(k)},\sigma_{i,j}^{(k)})\) is the Hamming distance between \(z_{j}^{(k)}\) and \(\sigma_{i,j}^{(k)}\). \(\mathbf{\theta}\) is \(r+1\) dimension vector with \(\mathbf{\theta}=(\theta_{0},\theta_{1},\cdots,\theta_{r})\), and \(\theta_{\overline{d}(z_{j}^{(k)},\sigma_{i,j}^{(k)})}\) is the Hamming distance coefficient, which is usually obtained by computer search with the goal of performance optimization [17]. However, it is difficult to find the optimal \(\mathbf{\theta}\) when the finite-field order is large.  
Inspired by the method of calculating its initial reliability in reference [18], the Hamming distance coefficient \(\theta_{\overline{d}(z_{j}^{(k)},\sigma_{i,j}^{(k)})}\) can be simply designed as follows:  
\[\theta_{\overline{d}(z_{j}^{(k)},\sigma_{i,j}^{(k)})}=r-\overline{d}(z_{j}^{( k)},\sigma_{i,j}^{(k)}) \tag{6}\]  
In Equation (6), \(r=log_{2}q\) and \(\mathbf{\theta}\in[0,r]\). Obviously, the smaller \(\overline{d}(z_{j}^{(k)},\sigma_{i,j}^{(k)})\) means that \(\sigma_{i,j}^{(k)}\) is closer to \(z_{j}^{(k)}\), indicating a higher reliability of \(\sigma_{i,j}^{(k)}\), and the corresponding value \(\theta_{\overline{d}(z_{j}^{(k)},\sigma_{i,j}^{(k)})}\) should be obtained as a larger value. Moreover, the subtraction operation avoids the computer simulation and further reduces the complexity and storage load.
# Performance Analysis of Internet of Things Interactions via Simulation-Based Queueing Models
## 4 Experiment Results  
For our experiments, we considered our simulator (MobileJINQS) that was presented in [17] and is an extension of the Java implementation of the JINQS simulator [45]. In this paper, we extended our simulator to include the ON/OFF models of Section 3. In our experiments, we assumed that each ON/OFF model represented a mobile sender that uses various QoS settings for the transmission of messages. Such a mobile sender generates 7,500,000 messages so as to accurately determine the mean response times and success rates per message. Then, we let the mobile peer connect and disconnect in the time scale of seconds.
## 2 Materials and Methods
### Sample Preparation  
The expansive soil samples were first air-dried, crushed, and sieved through a 2 mm mesh to prepare the soil for the stabilization experiments. To mitigate the potential impact of insufficient natural calcium ion concentration in the expansive soil, cementation solutions with different concentrations were prepared. Specifically, five cementation solution concentrations were investigated: 0 M, 0.5 M, 0.75 M, 1.0 M, 1.25 M, and 1.5 M. The molar ratio of urea to calcium chloride (CaCl\({}_{2}\)) was maintained at 1:1 in all the cementation solutions, as recommended in previous studies.  
The MICP treatment was conducted using a mixing method. The bacterial suspension and the cementation solution were added to the expansive soil in a 1:1 ratio by mass  
\begin{table}
\begin{tabular}{c c c c c c} \hline
**Physical** & **Maximum Dry** & **Optimal** & & & \\
**Properties** & **Density (g/cm\({}^{3}\))** & **Moisture** & **Plastic Limit (\%)** & **Liquid Limit (\%)** & **Plasticity Index** \\ \hline Value & 1.68 & 21.90 & 32.83 & 57.50 & 24.67 \\ Method & ASTM D698 [27] & ASTM D698 [27] & ASTM D4318 & ASTM D4318 & ASTM D4318 \\  & & & [28] & [28] & [28] \\ \hline \end{tabular}
\end{table}
Table 1: Physical properties of the expansive soil.  
\begin{table}
\begin{tabular}{c c c c} \hline
**Free Swell Rate (\%)** & **Unconfined Swell** & **Confined Swell Rate (\%)** & **Method** \\ \hline
56 & 16.38 & 7.19 & ASTM D4546(B) [29] \\ \hline \end{tabular}
\end{table}
Table 2: Swelling potential of the expansive soil.  
\begin{table}
\begin{tabular}{c c c c c} \hline
**Beef Extract** & **Peptone** & **Urea** & **NaCl** & **Rotational Speed** & **Incubation Time** \\ \hline
3 g/L & 10 g/L & 60.06 g/L & 5 g/L & 180 rpm & 7 days \\ \hline \end{tabular}
\end{table}
Table 3: Cultivation conditions for _Sporosarcina pasteurii_.  
and thoroughly mixed until the soil moisture content reached the target value. Based on previous studies that determined the optimal moisture content for maximizing compaction density and performance of expansive soils, all soil improvement tests in this work were consistently conducted at a fixed target moisture content of 21.9% to ensure experimental repeatability and result comparability.  
The MICP-treated soil samples with different cementation solution concentrations (0 M, 0.5 M, 0.75 M, 1.0 M, 1.25 M, and 1.5 M) were labeled as S-0, S-1, S-2, S-3, S-4, and S-5, respectively. After the mixing, the MICP-treated soil samples were placed in a temperature- and humidity-controlled curing chamber (temperature of 25 \({}^{\circ}\)C and relative humidity of 95%) and cured for 7 days to allow for the completion of the MICP process.  
The cured soil samples were then subjected to various physical, swelling, and mechanical property tests, as described in the following sections.
# 5G-MEC Testbeds for V2X Applications
## 3 Existing Testbeds and Implementations
### 5G-Mec V2X Testbeds
#### 3.3.1 5G-VINNI Moving Experimentation Facility Site  
The 5G-VINNI project developed a moving experimentation facility to support public safety communications and emergency response and disaster relief applications. The moving experimentation facility [46] accommodates the SATis5 testbed and uses a Rapid Response Vehicle (RRV). The SATis5 testbed [47] includes an edge node and a central core network node for the satellite backhaul connection. At the same time, the UE connects to the edge node and central core network nodes via the satellite backhaul network. The backhaul is the transport layer used to exchange messages between the edge node and the central core network site. The Fraunhofer FOKUS Open5 GCore toolkit was deployed for the implementation of the 3 GPP 5G core network. The Open5 GCore toolkit provides the 3 GPP Release 15 core network functionality and 5G New Radio integration. The testbed considers the NSA architecture where the traffic is split between the 4G and 5G at eNodeB. The testbed uses the 4G eNB for the RAN instead of the 5G gNB for the base stations because the 5G gNB was not commercially available at that time. The Open5G core integrates with the iDirect satellite hub platform to operate the satellite network. The iDirect hub offers integration with the overall 5G architecture and SDN functionalities with the help of the Satellite Convergence (SatConv) layer and includes an MNO for managing the modemsand satellite hub network. The iDirect Velocity Intelligent Gateway system introduces the 3 GPP core network (SatCore) into the satellite hub platform.  
The core network within the central node differs from that of SatCore and supports the satellite backhaul network. The satellite network operations are virtualized by moving their execution environment from a dedicated server to a VM with the help of the OpenStack Pike VIM. Satellite VNFs incorporate the SatRAN software element, the satellite 3 GPP Core Network function (SatCore), the satellite Network Management System (NMS), and the auxiliary VNFs implemented on the same system that utilizes the OpenStack VIM. The iDirect Velocity Intelligent Gateway system is connected to OSM with regard to MANO. The SATis5 testbed [48] presents the SATCOM integration with the 3 GPP 5G architecture for an over-the-air demonstration.
## 3 Simulation Configuration
### The Simulation Software
\begin{table}
\begin{tabular}{c c c c} \hline \hline  & **GNSS** & & **LEO** \\ \hline
**Satellite part** & BDS & GPS & LEO \\ \hline \multirow{2}{*}{Angular range} & GEO / IGSO : 10\({}^{\circ}\) & \multirow{2}{*}{14.3\({}^{\circ}\)} & \multirow{2}{*}{65\({}^{\circ}\)} \\  & MEO : 15\({}^{\circ}\) & & \\ \multirow{2}{*}{PCO} & YES & YES & NO \\ \multirow{2}{*}{PCV} & NO & YES & NO \\ \multirow{2}{*}{Clock} & YES & YES & YES \\ \hline
**Receiver part** & & & \\ \hline Cut off elev. & 1\({}^{\circ}\) & & 1\({}^{\circ}\) \\ \multirow{2}{*}{PCO} & YES & YES \\ \multirow{2}{*}{PCV} & YES & YES \\ \multirow{2}{*}{Clock} & YES & YES \\ Solid/Pole/Ocean tidal & YES & YES \\ \hline \multicolumn{2}{c}{**Propagation path**} \\ \hline \multirow{2}{*}{Troposphere} & YES & YES \\ \multirow{2}{*}{Ionosphere} & NO & NO \\ \multirow{2}{*}{Phase window} & YES & YES \\ General relativity & YES & YES \\ \hline \multicolumn{2}{c}{**STD of noise**} \\ \hline \multirow{2}{*}{Code} & \multirow{2}{*}{1.0 m} & \multirow{2}{*}{1.0 m} \\ \cline{2-2} \cline{4-4}  & & & \\ \end{tabular}
\end{table} 
Table 1: Simulation configurations of the LeGNSS observation data. It should be pointed out that the angular range in Table 1 is an essential issue in data simulation since it is one of the most important factors for the number of observations recorded by ground stations. Due to the different orbit altitude of different types of satellites, each type of orbits has its own angular range. Usually, the angular range \(\theta\) is calculated by \(\theta=\sin^{-1}(r/(r+l))\), with \(r\) and \(l\) denoting the radius of the Earth and the altitude of the satellites, respectively. We set the angular range to \(65^{\circ}\) for LEO satellites [24], \(10^{\circ}\) for BDS GEO and IGSO satellites, \(15^{\circ}\) for BDS MEO satellites [17], and \(14.3^{\circ}\) for GPS satellites [28], respectively.
## 2 Background and Related Work
### Active Queue Management
#### 2.1.5 Low Latency, Low Loss, and Scalable Throughput (L4S)  
The dual-queue coupled AQM [18; 19] is a novel AQM scheme that utilizes two virtual queues, L4S and Classic, to control network traffic and utilizes the PIE controller as its base [20]. The objective of this AQM is to achieve low latency, low loss, and scalable throughput (L4S) under a wide range of dynamic network conditions. The congestion control becomes the primary mechanism that keeps utilization high but low delay in an L4S service, but it also requires shallow unsmoothed explicit congestion notification (ECN) [17]. ECN [17] is a signal or, to be precise, an ECN field in the IP header with two bits to provide a congestion indication for any incoming congestion. ECN does not require any smoothing delay, as additional delay is required to ensure round trip time data on each flow.
# Novel Resource Allocation Techniques for Downlink Non-Orthogonal Multiple Access Systems
## 4 Proposed Resource Allocation Techniques
### Power Allocation Solution Using KKT Conditions (PKKT)  
To obtain the optimal power allocation solution, the optimization problem is formulated to maximize the system sum rate in Equation (13). The considered constraints are power and minimum data rate, as shown in (14) and (15).  
\[\underset{P}{max}\,B_{sch}\sum_{w=1}^{M}\,log_{2}\bigg{(}1+\frac{P_{w,s}H_{w,s }}{1+\sum_{l=1}^{w-1}P_{l,s}H_{w,s}}\bigg{)} \tag{13}\]  
Figure 2: An example of user pairing process based Hungarian (HNG) algorithm for six users.  
_The closed-form optimal power allocation can be obtained from Equation (22) as represented in Equation (27)._  
\[P_{w,s}^{*}=\frac{1}{\psi_{w}}\Big{(}2^{\frac{R_{w}}{R_{\mathrm{old}}}}-1\Big{)}, \ \forall w\in M \tag{27}\]  
From Equation (21), setting \(w=1\), we obtain Equation (28). See Appendix A for a detailed proof.  
\[P_{1,s}^{*}=P_{max}-\sum_{w=2}^{M}P_{w,s}^{*} \tag{28}\]  
As stated in Lemma 1, the optimal power allocation for sum rate maximization of the multiplexed users under the target data rate and minimum power constraints can be obtained by assigning high power to weak channel gain users first, and then assigning the remaining power to strong channel gain users. This consideration will make sure that the achievable data rate of the weak users is at least equal to the minimum target data rate. Furthermore, the strong channel gain users seem to contribute more sum rate in a given subchannel.
## 3 Considerations for a Real WSN Deployment
### Node Distance Metrics  
Using only physical distance between nodes as metric is inadequate in their actual deployment; we believe that it can only be used for the purposes of model simulations to compare protocols. Our practical implementations of WSN showed that the best node distance metric is the Link Quality Indicator (LQI) that the RF chip provides when a data packet is received. If the selected RF chip does not offer this option, we recommend the use of another chip as money saved with an inferior chip may result in headaches in the future.  
The LQI calculation depends on factors such as the modulation technique, the RF clock drift, the signal-to-noise ratio, the programmed bandwidth, _etc_. When more indicators can be obtained from the RF chip, better criteria can be applied. In short, the cluster construction must be based on LQI information. Geographical considerations will be used only in the deployment of cluster heads, but this deployment could be corrected using LQI aggregated data received in the sink.
## 3 Analysis of the Grid Convergence  
For the analysis of the grid convergence, the calculations of flow dynamics up to the establishment of the steady flow mode for three difference grids were conducted (Table 1, \(t=1.5\)). Here for the grid convergence test, the computational domain was cut off in \(x\)- and in \(r\)- directions and the flow near the body was considered.  
Figure 3 demonstrates the flow fields in isochores (Figure 3a), the dynamics of the parameters at the apex of the body (Figure 3b) obtained using these three difference grids, and the profiles of pressure and density in the BSW for \(r=0.504\) (Figure 3c). The number of points in Grid 1 and Grid 3 differs by about 9 times, and in Grid 1 and Grid 2 by 4 times, but, nevertheless, the isochores of the flow near the body and the shape of the BSW practically coincide (see Figure 3a). The dynamics of pressure and density at the body's top point differ only at the initial stage (where the solution is not smooth) and are practically the same at the steady flow mode (Figure 3b). Besides, the profiles of pressure and density in the BSW show the tendency to become more vertical with decreasing the space steps  
Figure 2: A pointed part of the AD model in a computational domain (increased): (**a**) each node in \(x\) and \(r\) is shown; (**b**) every second node in \(x\) and every fourth node in \(r\) is shown.  
(Figure 3c). Note that the difference scheme is not monotonic and gives two numerical oscillations before and after the SW front [18]. All these test variants show the presence of grid convergence in the used numerical methods.
## 3 System Model
### Offloading Decision: Trade-Off between Energy Consumption and Delay  
In mobile edge computing (MEC) scenarios, each terminal device has limitations in terms of storage capacity, computing performance, and battery lifetime. Each terminal can offload its data  
Figure 2: Reference system model.  
(or task) to its associated nearby edge server and also does not need to operated by itself. The MEC can (i) save the energy of each device, (ii) prevent data loss due to insufficient storage capacity, and (iii) reduce delay due to the lack of computing performance. To make good use of the advantages, it is necessary to decide what to offload and when to offload. The execution delay and energy consumption of each terminal device can be distinguished into two parts, i.e., local computing and edge computing as explained in (1) and (2). In edge computing architectures, the values include the transmission to edge server, processing on the edge server, and downloading from the edge server.  
\[Delay_{offload} = Uploadingdelay+Eprocessingdelay+Downloadingdelay,\] \[Delay_{local} = TDprocessingdelay \tag{1}\]  
where \(Delay_{offload}\) and \(Delay_{local}\) are the delays when the offloading happens or not, respectively.  
\[Energy_{offload} = Uploadingenergy+Eprocessingenergy+Downloadingenergy,\] \[Energy_{local} = TDprocessingenergy \tag{2}\]  
where \(Energy_{offload}\) and \(Energy_{local}\) are the energy consumption when the offloading happens or not (based on offloading decision-making by DQN), respectively.  
As discussed in the literature, offloading decisions are made depending on the following three criteria, i.e., (i) minimization of execution delay, (ii) minimization of energy consumption while satisfying tolerance delay, and (iii) trade-off between energy consumption and execution delay depending on the environment of the applications of offloading in each terminal device [24].  
When the goal is the minimization of total execution delay regardless of energy consumption, each device will conduct the internal offloading policy and it decides whether offloading should happen or not, i.e., local computing or offloading computing [25]. If the goal is the minimization of the energy consumption of each device, it uses the smallest energy resources even if the delay increases. This paper considers both execution delay and energy consumption of each terminal. Furthermore, for real-time communications, more weights are allocated to the minimization of total delays than energy consumption. In this postulated environment, each terminal determines whether it has to offload or not, according to DQN-based offloading decision-making algorithm which is based on reinforcement learning instead of general offloading determination [26; 27].
## 4 Experiments and Results
### Experimental Results  
The results from the autoencoder training, pre-training, and fine-tuning experiments were analyzed. The initial results indicated a rapid loss function convergence, validating the effectiveness of decoder training. Further findings from the pre-training and fine-tuning processes revealed that Deformer exhibited superior performance in music data processing, outperforming the baseline models in multiple key performance metrics.