esa-sceva/satcom-chunk-collection huggingface dataset:
## 2 System Model
### Channel and Modulation  
Modern communication systems estimate the channel by periodically sending pilot signals, and use those estimates to adjust the modulation and coding schemes so as to maintain a certain frame error rate (FER). However, the unpredictable nature of channels and the blind period between channel sounding cycles make it impossible to achieve optimal adaptation for all codewords.  
In this paper, channels are modeled as interference-free additive white Gaussian noise (AWGN). We assume that multiple codewords or packets (For simplicity, we assume that each packet consists of a single codeword and we refer to packets or codewords indistinctly. In a scenario where each packet consists of multiple codewords, we can either acknowledge codewords independently or treat each packet as a single unit which can either succeed or fail to decode. ) are bundled together into a single block, experiencing the same (often unknown) SNR at the receiver. All the IR bits requested in the same round also experience the same SNR, but this SNR is independent from that for the bundle and for previous rounds of IR (if any). This assumption is made in light of the fact that there is typically a delay between the transmissions of the original bundle and the IR, during which channel conditions could have changed.  
In order to increase throughput, the transmitter uses high-order modulations with multiple bits per symbol for all but the noisiest channel conditions. Encoding these modulation symbols directly would increase the error correction capabilities [38], but would complicate significantly the encoding and decoding. Treating the bits in a modulation symbol as independent and using binary error correcting codes is significantly simpler computationally, especially in the case of LDPC codes, but the performance is slightly worse than with non-binary error correction codes. Still, it is the most common approach in practice. Therefore, this paper assumes the use of binary encoders and decoders which operate as if the bits came from independent BPSK modulations with constant SNR throughout each codeword, even if higher order modulations are actually being used [39].
## 7 Evaluation
### Evaluation Methodology  
To get more representative experimentation results, it was decided to perform the evaluation on the micro level, i.e., to run transformations and calculate the performance of each model separately. To simplify the evaluation, we applied decomposition of such transformations into so-called atomic transformations, which are formally represented by the tuple \((I_{SMCT}^{1}\), \(I_{SMCT}^{2}\), \(rel(I_{SMCT}^{1}\), \(I_{SMCT}^{2}))\), where \(I_{SMCT}^{1}\) and \(I_{SMCT}^{2}\) are single instances of _SMCT_ and _rel_ is a relation or containment type relating \(I_{SMCT}^{1}\) and \(I_{SMCT}^{2}\). For the inputs used in the experiment, these tuples were instances of (_Actor_, _Use Case_, _Association(Actor_, _Use Case_)) and (_Lane_, _Task_, _Containment(Lane_, _Task_)) for the UML use case models and BPMN process models, respectively.  
Three measures were selected for the evaluation of experimental results:  
* Accuracy, which is defined as the proportion of correctly executed transformations to the total number of performed transformations: \[accuracy=\frac{\#_{correct}}{\#_{trans}}\] (1)
* Mean deviation between the number of extracted outputs and benchmark output results, which is used to measure the extraction error per model: \[MeanDiff=\frac{1}{\#_{trans}}\sum_{i}^{\#_{trans}}\frac{\left|\frac{\#_{actual}^ {i}-\#_{extracted}^{i}}{\#_{actual}^{i}}\right|}{\#_{actual}^{i}}\] (2)
* Jaccard distance between extracted outputs and actual outputs, which is used to evaluate the proportion of elements generated successfully compared to the set of elements that was generated actually; again, the mean is considered to aggregate the performance per model: \[\textit{Jaccard}=\frac{1}{\#_{trans}}\sum_{i}^{\#_{trans}}\frac{\left|O_{ actual}^{i}\cap\ O_{extracted}^{i}\right|}{\left|O_{actual}^{i}\cup\ O_{extracted}^{i}\right|}\] (3)  
Here, \(\#_{trans}\) is the total number of atomic transformations performed; \(\#_{correct}\) is the number of transformations that were processed correctly; \(O_{actual}^{i}\) is the benchmark set of elements that had to be generated in the \(i\)th transformation; \(O_{extracted}^{i}\) is the set of elements that were actually generated in the \(i\)th transformation; and \(\#_{actual}^{i}\) and \(\#_{extracted}^{i}\) depict the number of elements in \(O_{actual}^{i}\) and \(O_{extracted}^{i}\) respectively. Note that in this context, a transformation is considered to be correctly executed if all the output elements and their types match the defined benchmark output results for both elements and their types. Therefore, accuracy is considered as the stricter measure, while the mean Jaccard distance value is more appropriate for evaluating partially correct results.
# A Dynamic Service Reconfiguration Method for Satellite-Terrestrial Integrated Networks
## 3 Problem Descriptions
### Workflow of Service Migration and Reconfiguration  
The service migration and reconfiguration process of the STIN can be divided into two main steps, the migration awareness stage and the execution stage. The flowchart is shown in Figure 2.  
(1) Migration awareness stage  
Due to the periodic movement of satellite nodes in the STIN and the mobility of users, both satellite edge nodes and ground edge nodes may experience service migration and reconfiguration. First, the global states awareness ability of SDN/NFV is used to obtain external and internal environmental states of the current STIN system as well as  
Figure 1: Service migration and reconfiguration process in satellite–terrestrial integration networks.  
the previous services that are already deployed, subsequently it decides whether the service migration is triggered. If the trigger event occurs, the next stage of the algorithm is execution. If not, there is sustained monitoring as before.  
(2) Migration and reconfiguration execution stage  
The second stage mainly uses the service migration reconfiguration algorithm proposed to calculate the new migration location for the services to be migrated, and optimizes the migration path to meet the reconfiguration requirements with minimizing cost as the optimal objective.  
The service migration strategy is decided by the migration and reconfiguration algorithm, which is running on the control nodes in the STIN, usually on a GMCC or GEO controller. Additionally, it determines whether the migration needs to be started in the current network state. If so, the optimal migration strategy is determined, including the target location of the migration node, the optimal migration path, and the resource reconfiguration scheme. Once the corresponding satellite nodes have received the determined migration strategy, it will execute the migrate action that is moving the VNF to the target location through the optimal migration path. Those migration processes may lead to extra delays, including the transmission delay of migrating the VNF and the propagation delay of the migration path. Furthermore, the extra delay would affect the end-to-end delay of the network users, for which it is important to design an effective service migration optimal algorithm that can minimize the negative impact of migration.  
Additionally, in the process of migration, the data synchronization function of the GEO satellite is used to save data to ensure the continuity of service and data consistency.  
Figure 2: Flowchart of service migration and reconfiguration.
# NESO-Based Path Following Control for
## 3 Control Strategy Design
### Safety Control Strategy for the Underactuated Hovercraft
#### 3.2.1 Yaw Safe Control Law for the Underactuated Hovercraft  
A novel NESO-based backstepping sliding mode controller with turning SLC is achieved by adopting an auxiliary variable during the virtual law of the backstepping control to achieve yaw control for an underactuated hovercraft. **Step 1:** Define the heading and yaw tracking errors as \(\psi_{e}=\psi-\psi_{d}\), \(r_{e}=r-\alpha_{r}\), then it follows from (9) that the dynamic of the heading and yaw tracking errors can be expressed as  
\[\dot{\psi}_{e}=r-\dot{\psi}_{d} \tag{27}\]  
\[\dot{r}_{e}=\dot{r}-\dot{\alpha}_{r} \tag{28}\]  
To stabilize the heading-tracking error of (27) and take the nonlinear time-varying turning SLC into account, a virtual control \(\alpha_{r}\) with an auxiliary variable is designed as  
\[\alpha_{r}=\Delta\alpha_{r}+\alpha_{rc} \tag{29}\]  
\[\alpha_{rc}=-k_{\psi}\psi_{e}+\dot{\psi}_{d}+k_{\zeta}\zeta \tag{30}\]  
where \(k_{\psi}\) and \(k_{\zeta}\) are control parameters to be designed, and the \(\zeta\) is an auxiliary variable updated by  
\[\dot{\zeta}= \begin{cases}-k_{a}\zeta-\frac{|\Delta\alpha_{r}\psi_{d}|+\frac{1 }{2}\Delta_{\alpha_{r}}^{2}}{\zeta^{2}}\zeta+\Delta\alpha_{r},&|\zeta|\geq\ell \\ 0,&|\zeta|<\ell\end{cases}  \tag{31}\]where \(\ell\) is a small positive parameter, \(k_{a}>0\) is a designed parameter, and the virtual control law \(\alpha_{r}\) is limited by the turning safety limit  
\[\alpha_{r}= \begin{cases}r_{\max}(t)&\alpha_{rc}\geq r_{\max}(t)\\ \alpha_{rc}&r_{\min}(t)\leq\alpha_{rc}<r_{\max}(t)\\ r_{\min}(t)&\alpha_{rc}<r_{\min}(t)\end{cases}  \tag{32}\]  
where \(r_{\max}(t)\) and \(r_{\min}(t)\) represent the maximum and minimum of the turning safety limit (control area) parameter shown in Figure 2a, respectively. **Remark 5**. : _As a typical high-performance marine surface vehicle, underactuated hovercrafts generally sail at high speed, and its safety limit is an important performance index to ensure its safe navigation. Therefore, the constraint of the safety limit needs to be considered in the control law design process of underactuated hovercrafts. Considering the SLC, the virtual control law is limited by introducing an auxiliary dynamic variable.
# Multi-Agent Simulation Approach for Modular Integrated Construction Supply Chain
## 4 Results and Discussion
### Results
#### 4.2.2 Results of Scenario 2  
In this scenario, suppliers provide prefabricated components to MiC factories, which then supply integrated construction modules to the construction site. Figure 8 presents the GIS map from AnyLogic's simulation showing the locations of each supplier, MiC factory, and construction site.  
The results for Scenario 2 are presented in Table 5.  
In Scenario 2, we analyze the costs associated with the delivery of prefabricated components to the MiC factory and the subsequent delivery of integrated construction modules from the factory to the construction site. Table 5 shows how the total cost varies with the number of vehicles used by each supplier.  
The total variable cost includes the variable costs for both \(T_{1}\) and \(T_{2}\). For example, with one vehicle per supplier, the variable cost for \(T_{1}\) is EUR 1,870,500, and for \(T_{2}\), it is EUR 43,320. This cost remains stable for \(T_{1}\) and \(T_{2}\) across all configurations, indicating consistent routing efficiency.  
The fixed cost comprises the fixed costs for both \(T_{1}\) and \(T_{2}\). As the number of vehicles \(T_{1}\) increases, the total fixed cost for \(T_{1}\) rises from EUR 220,500 to EUR 322,500, and the reverse with respect to fixed costs for \(T_{2}\), which varies between EUR 58,800 and EUR 17,200,  
Figure 8: Scenario 2: locations of each supplier, MiC factory, and construction site.  
\begin{table}
\begin{tabular}{c c c c c c c} \hline \hline \multirow{2}{*}{**Number of Vehicles per Supplier**} & **Total Variable Cost for \(T_{1}\)** & **Total Variable Cost for \(T_{2}\)** & **Total Fixed Cost for \(T_{1}\)** & **Total Fixed Cost for \(T_{2}\)** & **Penalty (EUR)** & **Total Cost (EUR)** \\  & **(EUR)** & **(EUR)** & **(EUR)** & **(EUR)** & **(EUR)** & **(EUR)** \\ \hline
1 & 1,870,500 & 43,320 & 220,500 & 58,800 & 87,000 & 2,280,120 \\
2 & 1,870,500 & 43,320 & 220,500 & 29,400 & 13,500 & 2,177,220 \\
3 & 1,870,500 & 43,320 & 220,500 & 19,600 & 0 & 2,153,920 \\
4 & 1,870,500 & 43,320 & 258,000 & 17,200 & 0 & 2,189,020 \\
5 & 1,870,500 & 43,320 & 322,500 & 17,200 & 0 & 2,253,520 \\ \hline \hline \end{tabular}
\end{table}
Table 5: Results for Scenario 2.  
because in all configurations, we use one \(T_{2}\) vehicle, and so the fixed costs depend only on days of use of this vehicle.  
Related to penalties, with 1 vehicle per supplier, the delay costs EUR 87,000, reflecting significant delays. As the number of vehicles increases, the penalty decreases, eventually reaching zero when three or more vehicles by each supplier are used.  
The optimal number of vehicles appears to be three, as this configuration has the lowest total cost of EUR 2,153,920.
## 3. Group Technology and Data Collection
### Clustering Algorithms and Data Collection  
The group of those similar and homogeneous cases is referred to as a cluster [45]. Hierarchical clustering methods are performed by a series of successive mergers. The main goal of cluster analysis is to form a classification system to group relatively similar cases within themselves.  
Three different methods of hierarchal linkage clustering are shown in Figure 1: single-linkage (minimum distance or nearest neighbor), complete-linkage (maximum distance or farthest neighbor), and average linkage (average distance). These are all based on the similarity level but the main difference between them is the selection of the data points that are examined to take as a final criterion on which the similarity or distance depends [46; 47].  
The joining of clusters of the three linkage mechanisms is shown in Figure 2. No rule exists that can brief around the most proper clustering algorithm for a particular problem. A lot of testing and statistical logic is necessary to choose an effective clustering algorithm. [PERSON] et al. [48] proposes an algorithm named k-SCC to estimate the optimal k in categorical data clustering.  
The dendrogram is the graphical display of clustering. Usually, it is built backward, starting from the final cluster with all the objects and from similarity 0 [49].  
Single Linkage (Minimum Distance)  
Groups of clusters are created from single entities by merging or combining nearest neighbors, the nearest neighbor connects the smallest distance or largest similarity.  
In the beginning, the smallest distance in D = {d\({}_{\text{ik}}\)} should be found, and then merged with the corresponding objects, say U and V to obtain the cluster (UV).  
The distances between (UV) and any other cluster W are computed by Equation (1):  
\[d_{(UV)W}=min\ \{d_{\text{1}W},\ d_{\text{V}W}\} \tag{1}\]  
here \(d_{\text{1}W},\ d_{\text{V}W}\) are the closest distances between the neighboring clusters groups of U and W and group cluster V and W, respectively.  
Simple linkage tries to be very nearsighted. The object that will be added to the cluster should be close to any one of the other objects in the cluster, even if it is relatively far from all the others. So, the single linkage has a goal to make long, stringy clusters and nonconvex cluster shapes.
# Non-Invasive and Accurate Blood Glucose Detection Based on an Equivalent Bioimpedance Spectrum
## 8 A Non-Invasive Blood Glucose Detection Experiment
### Multi-Person Blood Glucose Test
It is observed that the majority of non-invasive blood sugar estimates are excessively high, while a few are lower than the biochemical blood sugar values. The mean absolute error is approximately 0.5. In conclusion, the blood glucose detection model developed in this study effectively captures the changing trends of an individual's blood sugar levels and can accurately identify high blood sugar samples in multi-person experiments. According to the above results, the proposed blood glucose detection model can feasibly identify high blood glucose samples in multi-person tests. Statistical analyses of big data indicate that factors such as gender, height, weight, age, waist circumference, and meal timing exhibit significant correlations with blood sugar levels. These variables can be utilized as features or independent variables in predictive models to enhance the accuracy of the predicted values.
# A Lightweight Blockchain-Based IoT Identity Management Approach
## 5 Results
### Comparison with Related Works  
Alongside the seven key aspects that are granted by adopting a blockchain-based identity management system, we compare our solution with related works based on the benchmarks for blockchain-based identity management systems [21]. Table 2 presents the comparison.  
For instance, [PERSON] et al. [14] used Ethereum to evaluate their work that displayed fast transaction time. However, they noticed and considered the limitations of using Ethereum, such as high cost and transaction long latency, which is around 6 min. in the Ethereum production network. [PERSON] et al. [16] used the IOTA protocol in order to conduct their experiment where the transaction time took a few seconds for the block size of 500 characters. Moreover, IOTA analyzed as a centralized solution as the coordinator node (consensus node) is operated by the IOTA foundation, leading to a single point of failure. [PERSON] et al. [15] used a simulator to evaluate their achievement. However, the reading and writing time take 6 to 9 s, which is not a good result for an IoT IdM solution supporting billions of devices. Similarly, [PERSON] et al. [8] also used a simulator to evaluate their work. They adopted 16 to 36 bytes transactions without including the payload the certificate data.  
In our work, we used a permissioned blockchain to leverage a decentralized, secure, and fast solution. The average writing time of 1 MB transaction can take around 205 milliseconds, while the average reading time is 69 milliseconds. Although, we may still need to geographically distribute the blockchain nodes to different locations to obtain the estimates latency for a production network.
# CoKnowEMe: An Edge Evaluation Scheme for QoS of IoMT Microservices in 6G Scenario
## 1 Introduction
### Telecommunication Evolution and Status of 5G Deployment
\begin{table}
\begin{tabular}{p{113.8 pt} p{113.8 pt} p{113.8 pt} p{113.8 pt}} \hline \hline
**Region** & **Operator (Number of Covered Cities)** & **Launch** &
\begin{tabular}{} **Penetration Rate** \\ **Forecast** \\ \end{tabular} \\ \hline Australia & Optus (14), Telstra (46), Vodafone (8) [5] & 05/22/2019 [5] & - \\ \hline Austria & A1 Telekom (129), Drei (Three) Austria (4), Magenta Telekom (T-Mobile Austria) (28) [5] & 03/26/2019 [5] & - \\ \hline Belgium & Proximus (79) [5] & 04/02/2020 [5] & - \\ \hline Canada & Bell (5), Rogers (4), Telus (5) [5] & 01/15/2020 [5] & - \\ \hline Czech Republic & O2 (2) [5] & 06/19/2020 [5] & - \\ \hline Finland & DNA (21), Elisa (30), Telia (8) [5] & 07/01/2019 [5] & - \\ \hline European Union & - & - & 29\% (2025) [6] \\ \hline Germany & Telecom Deutschland (20), Vodafone (96) [5] & 07/16/2019 [5] & 98\% (2022) [2] \\ \hline Gulf Cooperation Council & - & - & 73\% (2026) [7] \\ \hline Hungary & Maygar Telekom (2), Vodafone (2) [5] & 10/17/2019 [5] & - \\ \hline India & - & - & 26\% (2026) [7] \\ \hline Ireland & Err (19), Vodafone (5) [5] & 08/13/2019 [5] & - \\ \hline Italy & TIM (8), Vodafone (5) [5] & 06/06/2019 [5] & - \\ \hline Japan & KDDI (15), NTT Docomo (35), Softbank (12) [5] & 03/25/2020 [5] & - \\ \hline Korea & KT (85), LGU+ (85), SKT (85) [5] & 04/03/2019 [5] & 90\% (2026) [2] \\ \hline Latin America & - & - & 34\% (2026) [7] \\ \hline Latvia & Tele2 (2) [5] & 01/22/2020 [5] & - \\ \hline Middle East and North Africa & - & - & 18\% (2026) [7] \\ \hline Netherlands & Vodafone Zigogo (50\% of the Netherlands) [5] & 04/28/2020 [5] & - \\ \hline New Zeland & Vodafone (4) [5] & 12/10/2019 [5] & - \\ \hline Norway & Telenor (4), Telia (2) [5] & 03/13/2020 [5] & - \\ \hline North America & - & - & 84\% (2026) [7] \\ \hline North-East Asia & - & - & 65\% (2026) [7] \\ \hline Poland & Plus (7), T-Mobile (11) [5] & 05/12/2020 [5] & - \\ \hline South East Asia and Oceania & - & - & 33\% (2026) [7] \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Status of 5G deployment and forecast.
## 2 Materials and Methods
### Model Construction  
#### 2.3.1 Structuration of Time-Series Data  
In order to build a cubic data structure (objects \(\times\) time \(\times\) spectral bands), all spectral bands were re-interpolated on a date grid, regularly spaced over the period of interest, i.e., the period that the extreme climatic event may have impacted crops. The objective was to ensure that the cubic \(\underline{\mathbf{\chi}}\), had the same number of steps (\(N\) days of measurements) to prevent temporal data gaps due to clouds and inconsistent numbers of available satellite images. The interpolation at a date \(t\) was performed band-by-band, by a convolution of the chronology measured with a Gaussian filter [31] centred on \(t\) and with full width at half maximum (\(P\)).  
Temporally sparse satellite observations, especially for areas that can be affected by cloudy conditions, may not be sufficient for monitoring rapid changes such as some phenological crop stages [32]. Moreover, [PERSON] et al. [33] have demonstrated that there is an impact of varying atmospheric conditions and sun-sensor-surface viewing geometries on satellite-derived time-series. A preliminary sensitivity analysis with a noise reduction approach and given time steps provided information on the sensitivity of the variation of the \(P\) and \(N\) parameters to interpolation. The parameters \(P\) and \(N\) involved in the interpolation setting, were optimised by cross validation of 2 blocks repeated 5 times of a N-PLS between cube \(\underline{\mathbf{\chi}}\) and vector \(\mathbf{y}\) using the calibration dataset (see Section 2.3.2). For this analysis, values of \(P\) and \(N\) ranged from 10 to 50 and 5 to 30, respectively.
## 5 Integrated System Testing
### Test Scenario 1  
#### 5.1.1 Test Settings  
We adjusted the sensor settings on the control page to suit our test scenario, as shown in Figure 15. This page has four sections: current node information, selecting timings, customized timings, and response, each of which are explained in further detail below:  
1. Current node information This section is divided into three columns. The column on the far left shows the code number of the warehouse being monitored by the system. The middle column shows the code number of monitoring devices in this warehouse. The far-right column displays the command the user wishes to input (at this point there is only one command available: 1. Transmit data). Users can adjust the settings in each column based on node requirements.
2. Selecting or customizing timings This interface allows users to set data collection times for nodes. Users can either select from the time options provided (48 options at intervals of 30 min as per system design), or input their own specific timings.
3. Response function Users can immediately begin data collection by clicking the respond now button.  
For our test scenario, we selected Sensor 1 in Warehouse 130 and applied Command 1. Transmit data. We selected all the available options in the timings section so that the system would transmit  
Figure 15: Control interface for managing sensor timings.  
remote monitoring data every 30 min for a full 24-h cycle. We then clicked Confirm to save our settings. In relation to hardware, we linked the Ethernet to the smart gateway and server. We repeated the same settings for Sensor 2.