-
StatusOngoing
-
Status date2021-09-29
-
Activity Code6B.070
In a beam-hopping system as illustrated below, a beam-hopping time plan (BHTP) is executed repeatedly to serve different service areas. The dwell times correspond to the current traffic demands by the remote terminals. This cyclic execution runs until a new BHTP is provided, which defines a new time plan and possibly new beam coverages (new cluster) matching changed traffic demands. Therefore, beam-hopping provides the required flexibility and variability to match non-uniform and time-varying traffic demands to the satellite system resources.
A key features of beam hopping systems is to support seamless updates of the BHTP (no interruption and no loss of synchronization between gateway, satellite and user terminals) in order to assure a given quality of service (QoS).
DVB-S2X specifies three new Super-Frame Formats (5, 6, 7) for beam-hopping and two application modes of beam-hopping: pre-scheduled (using Format 5) and traffic-driven (using Format 6, 7). This project focuses on the first mode, which relies on repetitive cycles of the BHTP until a new BHTP is applicable. This allows for extra features compared to Format 6 and 7:
- PLFrame fragmentation among dwells for increased efficiency
- Validation of the start of dwell detection
- Close tracking of carrier frequency or timing drifts due to e.g. Doppler
The project objectives are the following:
- Implementation and validation of a complete DVB-standard compliant signal transmission chain for forward link beam hopping
- Enhancement of a wideband modulator (capable of DVB-S2X Annex E, Super-Framing Format 4) to support now Format 5, NCR distribution and signalling of BHTP updates
- Enhancement of a wideband user terminal device (capable of DVB-S2X Annex E, Super-Framing Format 4) to support now Format 5, NCR synchronization, exploiting the signalling of BHTP updates for seamless data reception
- Integration of all devices in an automated testbed for analysis, testing, demonstration, and evaluation of different system configurations and transmission scenarios
- Variable Super-Frame length
- Correct insertion of the new signalling elements of Format 5
- Implementation of individual queues for all service areas (coverages)
- Accurate and standard compliant NCR implementation
- Standard compliant lower layer signalling for BHTPs
- Seamless BHTP update procedure
- Coping with channel impairments, e.g. Doppler induced drifts
Based on the previous ESA project on beam-hopping (cf. link below), large and proven heritage can be re-used and extended for these developments.
Benefits on modulator side:
- Accurate NCR insertion for different cells
- Scheduling and planning of BHTP updates as well as NCR time tagged execution
- Cell-specific data queueing
Benefits on user terminal side:
- Initial learning of BHTP and seamless BHTP update handling based on information from lower layer signalling and NCR
- Adjacent cell interference awareness
- Design is also suitable for continuous reception mode.
- Implementation and test of DVB standard compliant ground components
- Modulator with beam-hopping-specific flexibility
- User terminal with beam-hopping-specific synchronization and data decoding
- Automated lab testing employing a beam-hopping payload emulator and a satellite channel emulator
- Wideband transmission up to 500 Mbaud over L-band
- End-to-end data transmission in a beam-hopping system
- DVB-S2X compliant implementation of beam-hopping using Super-Frame Format 5
- All roll-offs: 5%, 10%, 15%, 20%, 25%, 35%
- All MODCODs: VLSNR-MODCODs, QPSK … 256 APSK
The hardware testbed (as visualized in the figure) consists of four key components:
- Wideband modulator with IP encapsulator configurable to the actual BHTP
- Satellite payload emulator implementing the beam-hopping characteristic
- Satellite channel emulator for the transmission scenario related impairments (e.g. Doppler and Doppler drift)
- User terminal for data reception, decoding and IP decapsulation
Milestones & Meetings |
Planned Schedule |
|
KO |
Kick-Off |
11/2020 |
SDSR |
System Definition and Specification Review |
02/2021 |
PDR |
Preliminary Design Review |
06/2021 |
CDR |
Critical Design Review |
09/2021 |
TRR |
Test Readiness Review |
06/2022 |
ATR |
Acceptance Test Review |
10/2022 |
FR |
Final Review |
12/2022 |
FP |
Final Presentation |
12/2022 |
CDR successfully closed, Implementation Phase is on-going.