October 12, 2015

Applications like water and gas metering, widely spread sensor networks, security cameras of remote sites and similar require communications over a very broad area with varying demands for data rates. For those applications, satellite communications, over a GEO satellite or an LEO satellite network is a very viable solution. Battery powered or solar operation is a much-desired feature for many of those applications.
In this post, we describe an air interface, derived from the standard DVB-S2/S2X/RCS2, which enables half-duplex transmission, sleep periods and terminal alerting. All these features enable low power operation for the terminals.
The main principle behind the air–interface is that it enables a predefined and predictable reception and transmission times of each terminal. Furthermore providing the terminals with satellite constellation information would also facilitate predictable operation within an LEO satellite network.
Low power operation is much desired for the payload as well. This principle of transmission and reception time predictability is also a facilitator for this feature at the payload.

Introduction

Since their introduction, communication satellites provide a platform for communication over long range links with a very wide area coverage. As long as latency is not critical, the link budget is acceptable and equipment and satellite spectrum costs make a good business case, satellites provide an excellent solution for applications like broadcasting, video transmission, telephony, data trunking and more.
For other applications, such as sensor networks or remote infrastructure monitoring, like water, gas and electricity facilities metering, security cameras and other types of sensors, satellites can provide an excellent solution for their communication needs. The very large coverage area of a satellite enables such a system to use a single hub in which data from a continent size region can be collected. The spectral requirements of such systems, being mainly of a very low rate, make it possible to operate with a limited amount of satellite spectral resources, and in very low SNR conditions. On the other hand, in many cases, equipment size and power requirements are an obstacle for
implementation of a satellite communication terminal, which has typically relatively large footprint from both size and power points of view.
In this post, we describe a system concept, derived from standard satellite communication protocols, DVB-S2, DVB-S2X and DVB-RCS2, which is designed to comply with the requirements for very-low-power, low-cost satellite terminal.
The small size requirement directly implies a small antenna and small electronic equipment size.
Smaller antenna affects the link budget, however, the fact that the data rate requirement, and consequently the bandwidth requirement is low, makes it possible to operate in a very low Signal to Noise ratio (SNR) conditions. The VL-SNR mode in is an excellent candidate for this kind of applications, enabling operation in SNR as low as -10dB. A Higher level of symbol spreading, and compression makes it possible to operate in even lower SNR’s if needed [4]. Furthermore, for an LEO or MEO systems, whereby the propagation loss is lower, even a smaller antenna would comply with the link budget requirement.
Smaller equipment size and cost are possible by usage of dedicated ASIC-based equipment. The SX-3000 family of products, which feature full standard modem capabilities, yet fully programmable to allow for necessary non-standard features, may be used as a basis for a low-cost low profile terminal.
However, to further support size and power reduction, some modifications of the protocol would be beneficial. Such modifications would include:

• Half duplex operation, making a complex diplexer redundant
• Mechanisms to enable intervals of non-operation thus enabling full or partial power-off, saving power and cost.

In this post, we will also describe a protocol enabling low power operation in a data delivery systems. We also present a method to overcome the handicap of operation with LEO systems, which may require the receiver to be operational even if no information is transmitted to it, in order to be able to track the satellite and manage the handover to other satellites.

Framing Structure

The straightforward way to achieve half duplex operation would be to perform on-the-fly transmit-receive conflict resolution without limiting terminals by any framing mechanism. To do that, the satellite scheduler must ensure that transmission frames are only multiplexed onto the forward link at such times that they arrive at the terminal when it is not transmitting. This means, in turn, that the satellite forward link multiplexer must maintain a separate forward queue for each (active) terminal and, in
addition, track the propagation delay between the satellite and that same terminal. Once every return link time slot, and for each non-empty output queue, the scheduler would use the delay information to consult the return link capacity allocation matrix (which keeps track of the return slot assigned to terminals) in order to check whether, at the projected time of the forward link packet reception, the terminal is scheduled to transmit or not. The scheduler must then serve fairly the non-blocked queues, or do it taking into account priorities based on request timing, terminal priority or terminal traffic history.
In addition, scheduling must allow terminals certain pre-agreed short transmission windows for random-access return link transmissions. Finally, return link capacity allocation must keep a terminal’s transmission duty cycle below 100% to ensure that forward link traffic can be sent to it without excessive delay.

We propose here another method, which uses a framing mechanism that greatly simplifies scheduling. Forward link transmissions will be grouped into time intervals. Each interval will be partitioned into several sub-intervals, N(si), each consisting of an integer number of DVB-S2/S2X frames. The terminal population will be partitioned as well to N(si) sub-populations (preferably equal size). The division will be done in a way that maximizes randomness across geography (and therefore within any single beam at
any time). This division can be static or dynamic based on traffic history. In each time interval, each terminal is allocated some sub-intervals for reception and some other sub-intervals for transmission. A terminal is allocated return link transmission time during the sub-interval when it is not receiving. Return link capacity allocation will take into account satellite-terminal delay to ensure that capacity assignments (made in the satellite’s return link time frame) are compatible with the terminal’s transmit
time window.

The Figure below describes the proposed transmit-receive method for 4 N(si). As can be seen, the transmission of the satellite is broken to 4 sub-intervals. Each terminal group is allocated a single sub-interval for reception and three for transmission. Within sub-interval 1 all the terminals allocated in sub-population 1 will receive information. Sub-interval 2 will be used for transmission to the terminal in sub-population 2 etc. Transmission of terminals in sub-population 1 will occupy sub-intervals 2-4 and will be sent using a return link channel. At the same time transmit data from terminal sub-population 2 will occupy time slots 1, 3 and 4 and will be sent over different return link channels. Decreasing the duration of the sub-intervals will reduce delay but also reduce the effectiveness of grouping. Increasing (or decreasing) the number of sub-intervals in an interval will increase (decrease) the transmit time interval window (to 1-1/N(si) of an interval) and increase (decrease) the delay somewhat (to 1-1/N(si) of an interval).

Data can be sent over the beam forward link continuously, while on the return channels data can be transmitted over a portion of the time (75% in our example.)
Terminal assignment to a sub-population and a group will be done at the gateway. Transmit-receive scheduling and return link capacity assignment will be signaled in higher layers. Their implementation in the gateway and the terminal will be entirely in software. This will make it possible for the scheduling scheme to continue to evolve after system deployment.
This framing mechanism has an additional advantage as the terminal can set itself to a “sleep mode”, during which it could power down its transmitter or receiver circuitry, since the time of transmission and reception are now predictable. This can be further enhanced by further dividing each subpopulation into groups. Each group is to be served by a fraction of the sub-interval capacity, e.g. signaled by a time-slice number, as defined by Annex M of DVB-S2 standard, representing the group. This will make it possible for a terminal to power down its receiver for the duration of a frame as soon as it has determined that the frame’s group (time-slice) number is not its own.
If the forward link transmissions need not be continuous, as for example in the case of LEO and high altitude platforms, where coverage area is smaller and the data rate is not too high, the frame structure as depicted in the figure below can be used. This is a frame for a multibeam system with several forward channels and several reverse channel beams.
The frame is divided into several intervals:

1. Broadcast region, in which the gateway transmits, in all beams and channels, information for all terminals including Synchronization signals and Beam, channel and time allocation for transmissions to each terminal group in the forward and reverse channels, for or from which information has to be transmitted. Transmission in this channel shall be made with diversity to overcome multi-beam interference that may occur.

2. Unicast regions for transmission aimed for a given group allowing half-duplex. Multicast allocation transmissions to a group of terminals can be made as well, with more detailed allocation information. On the return channels additional control information, including updated location, received signal strengths of the serving and adjacent beams, and requests for further transmission slot allocations, can “piggyback” to the data transmitted.

3. Random Access Region needed for terminals to send requests for allocation in the next time intervals.

The frame structure (as shown below) allows low power operation and low power consumption for terminals and payload. Besides the synchronization and allocation transmissions (which are made very short), terminals and payload can schedule long sleep periods, in which power of some power consuming components is turned off.

Beam and Satellite Switching

The fact that the suggested protocol is based on pre-determined time reference, can be used to produce an efficient tracking, seamless beam and satellite handover procedures for Medium Earth Orbit (MEO) and Low Earth Orbit (LEO) satellites, and even high altitude platforms.

Assuming that:

1. At installation, the terminal is programmed with its geo-location, accurate to within 50m. The terminal will also be coarsely 3-axis aligned (in a North-South orientation and 2-axis tilt).
2. During commissioning, the terminal runs a calibration routine that fine-aligns its orientation and tilt based on satellite reception.
3. A system-wide Time of Day (ToD) time base is established, which is accurate (at the satellite) to within 100 ns of UTC. The gateways align themselves to this time base. The DVB-RCS2 Network Control Reference (NCR) can serve for this purpose.
4. The satellites periodically broadcast, over the forward link of each beam, information that specifies the system’s satellite constellation – orbits and satellite positions – to an accuracy that enables a terminal to predict the location of any satellite up to 12 hours ahead to within 100 m (300 ns one-way propagation time).
5. All gateways and terminals run identical, coverage mapping routines that use the information in (1) and (2), timed by (3), to determine satellite coverage of a terminal.

Given (1) through (4) above, the terminal antenna is able to lock on satellites without relying on signal strength indication. A terminal that has been in standby mode for hours can activate itself for the time needed to receive up-to-date constellation information, including antenna pointing as needed.
All forward links generated by a satellite across all its beams are to synchronized at the symbol, frame, sub-interval and intrval levels. Coverage mapping routine (5), running in the terminal, determine the frame at which the terminal must switch beams.
The terminal is following the information given by the gateway, based on that information and the synchronization it can determine when to switch beams or satellites.
For the forward link, the terminal can decide when to move since it has a portion of a of a frame time (e.g. 3/4) time to move – it is receiving only over a portion of the sub frames (e.g. 1).

The figure below describes the switching mechanism for the reverse link. Initiated by the terminal.

Satellite and beam routing to a terminal are determined by the gateway and signaled to the terminal through side-information attached to every forward link packet. The gateway, running the same coverage mapping routine (e) as the terminal, determines the timing of terminal beam switching and route forward link traffic accordingly. In order to minimize forward link queuing delay during a beam switch, the gateway should be aware of sub-framing when managing forward link queuing.
With the exception of short and infrequent session initiating messages, return link transmissions from a terminal can only be made after a capacity request has been sent to the gateway and a capacity assignment had been received in response. The gateway responds to capacity requests with a tightly controlled response time: the terminal will receive the assignment a constant number of sub-frames after it had made the request and – unless the return channel is heavily overloaded – the assignment will be for a (small) constant number of sub-frames in the future.

The gateway accepts requests for capacity in the new beam that are received over the old beam. When anticipating a beam switchover, the terminal makes – over the old beam – a request for capacity in the new beam at such time that the assignment is received just before switchover Request. There is only at most one such request pending from a terminal. While the request is pending, the terminal continues to receive forward link and transmit (previously assigned) return link traffic over the old beam.
The gateway re-routes traffic to the new beam at such time that it starts arriving at the terminal immediately the following switchover. There is a transition phase (approximately coinciding with the time the cross-beam capacity request is pending) when the gateway receives terminal traffic over the old beam and transmits traffic to the same terminal over the new beam.
At switchover, the terminal re-programs its transmit and receive local oscillator frequency synthesizers during the receive and transmit sub-frames, respectively.

The features described above are applicable for switching among satellites as well. As all the satellites in the system are to be synchronized to a common Time of Day, their forward links should be synchronized at the frame, group, sub-interval and interval levels, and their return links should have synchronized slots.
The coverage mapping routine running in the terminal determines the timing of satellite switchover. A terminal in standby mode uses this information to switch to the new satellite and proceed to demodulate its terminal alert channel. Forward link traffic to an active terminal that is switching satellites is re-routed by the gateway to the new satellite. The gateway will run the same coverage mapping algorithm as the terminal and should time the re-route in advance so that, after propagating through the system, forward link traffic arrives at the terminal aligned in time with the switchover without experiencing any switchover-related queuing delay.

To perform return link switchover, the terminal sends, ahead of the switchover moment, a special capacity request message that is forwarded by the old (switched-from) satellite to the gateway(s) serving the old and the new ones. The capacity request specifies the time of switchover, allowing to allocate capacity in the new satellite accordingly. The terminal should time this request message to allow enough time for an assignment response to arrive back through the old satellite before the switchover. The terminal will then be able to switch its return link transmission from the old to the new satellite with only a small hit in throughput (see immediately below).
The terminal will re-program its transmit and receive LO frequency synthesizers during the receive and transmit sub-frames immediately preceding the switchover, respectively. Additionally, the antenna is to be steered from the old satellite to the new one during the back-end part of the transmit sub-frame immediately preceding switchover. This reduces by a small amount the return link transmit time window within the last frame before the switch. In addition, any difference in terminal-satellite path delay between the old and the new satellite will cause a shift in the frame, changing the duration of the first transmit window following the switch. The coverage-mapping routine should also provide the carrier frequency Doppler shift of the new satellite.
There will be, immediately after switchover, a larger uncertainty in the timing of the received forward channel than during beam dwell. A larger search window will, therefore, be needed for the first subframe or (for a terminal in standby mode) alert channel access. At the same time, assuming the parameters of this window will be much shorter than one forward link baseband frame, creating no ambiguity in the PL header to be demodulated.
First-time return link transmissions will arrive at the new satellite with a larger timing error than follow traffic (500 ns assuming the parameters of or 1% of 50 S) for a relatively short 1000 bit burst at 20 Mbps). To optimize the return link guard interval so it is not driven by the constraints of this tiny fraction of traffic, return link capacity assigned through the procedure described above will leave entire slots as guard time intervals and if needed, the satellite’s return link receiver(s) will be alerted to
perform burst acquisition over a larger search window.

System Design Principles

In order to clarify the main features and constraints set by the air interface, we present here some system design principles, with example values for implementations.
The design of an interactive wireless data delivery systems starts with the traffic demand and available spectrum. The required data rate is computed based on traffic statistics and latency considerations. It is essentially within the realm of traffic engineering.
The data rates and available spectrum are related to the spectral efficiency of the protocol used, which in turn depends on the available signal to noise ratio and the roll-off used. For the forward link, a DVB-S2 or DVB-S2X air interfaces are capable of providing spectral efficiency between 0.076 to 5.9 bits per symbol transmitted (including VLSNR modes), while for the return link, the DVB-RCS2 protocol provides 0.053 to 0.37 bits per symbol transmitted (as the bandwidth is proportional to the symbol rate with a factor of spectral extension due to roll-off, the actual spectral efficiency is somewhat reduced relatively to those numbers). For the sake of simplicity, we assume a constant spectral efficiency over the entire area. In practical systems, variable or adaptive control would enable optimization from that respect. In addition to the above, the maximally allowed latency per message and the duration of the sleep period should be determined.

* This paper was previously published by: Doron Rainish and Avraham Freedman, at the Ka conference, Bologna, Italy, 2015 (http://www.kaconf.org/2015/)
For more information regarding the implementation of low-power air interface please contact SatixFy @ info@www.satixfy.com