BB23.E Safety critical applications via Satcom
From its-wiki.no
(Redirected from SCOTT:BB3.1.E)
BB3.1.E | ||||||
---|---|---|---|---|---|---|
|
![]() |
Title | M2M safety critical and non-critical applications via Satcom |
---|---|
Page Title | |
Technology Line | Security & Safety |
Lead partner | INDRA |
Leader | Xavier Alberti |
Contributors | INDRA |
Related to Use Cases | SCOTT:WP18 |
Description | suggest to move to SCOTT:BB23.I Use of satellite safety communications to guarantee the service level requirements (i.e availability, continuity, integrity and latency, etc). It can support data from sensors (or WSN) and typical railway applications, including voice calls. |
Main output | An enhanced waveform able to meet with the safety and security stringent requriements in terms of availability, continuity, integrity and latency derived from the mission critical applications. The designed waveform will provide the required mechanisms (e.g. error detection, error correction, encryption, etc) at physical and link layer to guaranty the QoS performances that allowing to provide a high security and safety level to the communication service. |
BB category | SW component |
Baseline | Usage of satellite spectrum resources implies a considerable cost in terms of capacity reservation to the satellite operator. The ratio that a radio signal modulation can reach between the volume of the data traffic to transmit (in bits per seconds) and the real amount of spectrum occupied (in Hz) depends on the design and the implementation of what it is called the “waveform” (i.e. including physical and mac/link layer of a communication protocol). We can take advantage from the waveform designed and implemented (e.g. Hub modem prototype) in the frame of the ESA Iris program to serve the ATM (Air Traffic Management) traffic. This waveform is burst-to-burst oriented and provide a high efficiency in the use of the spectral resources. |
Current TRL | TRL-4. It is justified due to, on one hand, the proposed M2M waveform design was consolidated by mean of SW simulation model (i.e.transmitter and receiver are simulated at bit/sample level), using MATLAB and on the other hand, the receiver component was already implemented in a receiver front-end HW prototype (i.e bread-board) and subsequently validated in a real-time satcom network simulator. |
Target TRL | TRL-7. Objective: to reach a validated prototype for receiver (hub side) and transmitter (remote side) in an emulated real-time operational environment (without satellite bandwidth leasing). |
Move to SCOTT:BB23.I
email from Xavier 18Apr2017
After a deeper analysis of the Building Blocks and the modifications which have been produced these last weeks, we have detected that one of our BBs, the BB23.E “M2M safety critical and non-critical applications via Satcom” is redundant and no longer needed.
- The technology to be developed in this Building Block is already covered by BB23.I.
- This BB manage the development of various communication gateways including ours, so doesn’t make sense to add also another BB for it.
- Our BB23.E has no participants but us, and BB23.I has a more interesting partners’ participation with a more coherent integration between gateways.
We have discussed this with the owner of this BB, and we agreed to participate in this BB to develop this technology, so we will merge our BB23.E technical aspects and requirements with them. So we propose to delete the BB23.E “M2M safety critical and non-critical applications via Satcom”.
Indra (Satcom department) has efforts in both WP23 and WP26, so there is no problem with this aspect.