Over the last 18 months, Advantech Wireless has explored the synergistic use of the DVB-S2 and DVB-RCS to enhance both data networking and, coming full circle, IPTV solutions. Particularly satisfying was to see the U.S. Department of Defense announce, in February of 2006, that their policy for the transmission of IP of both commercial and military satellites was to use the DVB-S2, DVB-RCS and MIL-STD-188-165 standards.
The Company has been successfully deploying such systems from early 2006 for commercial and defense applications. In addition, Advantech Wireless recently collaborated with Telesat Canada and the Canadian Space Agency (CSA) to demonstrate the first use of DVB-S2 in a DVB-RCS system with a satellite operating at Ka-band. (The major advantage of Ka-band from the stand point of the end user is lower service pricing, made possible as a result of the spot beams and frequency reuse in Ka-band satellite design).
DVB-S was introduced in 1993 to standardize the distribution via satellite of digital television services to consumers. This standard proved quite successful in driving down the cost of satellite modems and, within a few years, it was used for digital television distribution as well as for data distribution as the ‘low-cost’ demodulator chipsets allowed the development of new satellite data distribution markets.
The success of DVB-S encouraged DVB to study an extension, DVB-RCS, which added a standardized satellite-based return channel for multi-user data distribution. In addition to data distribution, DVB-S was also being used for television news contribution via satellite (DSNG) applications and for distributing television and radio channels to terrestrial transmitters.
DVB-S was only specified with QPSK (Quadrature Phase Shift Keying). QPSK is a form of Phase Shift Keying in which two bits are modulated simultaneously, selecting one of four possible carrier phase shifts (0, 90, 180, or 270 degrees). QPSK allows the signal to carry twice as much information as ordinary PSK using the same bandwidth. modulation, which allows a maximum of 2 bits/Sec/Hz efficiency in a satellite link. This is a limitation for professional applications, which can use larger satellite dishes and smaller symbol rates than the consumer transmissions and, hence, can support more advanced modulation schemes. Therefore DVB created yet another standard in 1999 (DVB-DSNG) which standardized 8PSK (Phase Shift Keying) and 16QAM (Quadrature Amplitude odulation — more efficient than QPSK but requiring more link margin) to be used for professional applications.
In parallel with this drive for efficient satellite transmission the DVB-S2 committee also designed a ‘professional’ mode for the standard, which included radical advanced modulation schemes such as 16APSK and 32APSK. These modulation schemes are not suitable today for consumer applications but have an application in high data-rate large dish point-to-point links. This professional mode has been designed to replace the DVB-DSNG standard. The ultimate target was to have one satellite standard addressing as many consumer and professional applications as exist in the market.
Wait, there is more. Until the advent of DVB-S2, two-way VSAT systems had limited support for fade adaptation in the return link only, notably power control in the user terminal and diversity switching in the hub. A DVB-S forward link (i.e., hub outbound) has no direct adaptation possibilities (except the possible use of Uplink Power Control — an established technology).
The use of DVB-S2 Adaptive Coding and Modulation (ACM) offers rain fade countermeasures on the forward link and permits an optimum match of transmitter waveform to the channel conditions. In particular, the DVB-RCS standard has inherent support, as well as some “hooks”, for supporting such adaptation techniques. This article, then, discusses how DVB-S2 and DVB-RCS are married together. Figure 1 shows a typical DVB-RCS network diagram.
DVB-S2 + ITS Benefits
— The Physical Layer and its Performance
Front and centre in the justification for DVB-S2 is the very high physical-layer performance. This is achieved through the use of very powerful coding, combined with provisions for high-order modulation schemes that are optimized for use on nonlinear satellite channels. While there is nothing fundamentally new in either of these elements, the advancements in low cost digital processing power and the development of powerful decoding and synchronisation algorithms have made the use of these techniques feasible, even in low-cost applications such as direct-to-home (DTH) broadcast.
The power of DVB-S2 is illustrated in Figure 2. This figure shows the power/bandwidth trade-off of the modulation and coding combinations incorporated in the standard. The figure also shows theoretical performance bounds. When the modulation constellations and finite block sizes are taken into account, DVB-S2 is within a few tenths of a dB of the theoretically achievable. For all but the highest spectral efficiencies, it is actually quite close to the Shannon bound which, as far as is known today, represents the ultimate performance limit. The figure also shows DVB-S, for comparison. This comparison shows that DVB-S2 outperforms DVB-S by about 3 dB for the same spectral efficiency or by about 35 percent in spectral efficiency for the same link budget.
The DVB-S2 physical layer makes use of a powerful coding technique known as LDPC (Low Density Parity Check) coding, in combination with a small conventional block code (BCH). The main coding technique, also known as Gallagher codes, was first described in the 1960’s. The complexity of decoding was however prohibitive until recently. Techniques inspired by those used for the more recent “Turbo” codes have been shown to work very well. For this reason, LDPC codes are sometimes described as a “cousin” of Turbo codes. The BCH code is included in DVB-S2 to mitigate the “flaring” of the error performance that is inherent in all high performance codes, including LDPC.
DVB-S2 offers a range of modulation schemes, starting with conventional QPSK and 8PSK. For higher spectral efficiency in applications that allow it, the standard also includes 16APSK and 32APSK schemes. These schemes use constellations that consist of a number of concentric rings of constellation points, rather than the square grids of points used in conventional high-order schemes such as 16QAM. This makes the schemes better suited to the nonlinear transmission channels encountered in satellite systems, and offers the possibility of powerful, yet simple pre-compensation techniques. Overall, the range of possibilities offered by DVB-S2 cover a “dynamic range” of required signal-to-noise ratio of 18 dB.
These improvements form the prime justification for the development of DVB-S2, because of what they offer for broadcast services. There are, however, further features in DVB-S2 which have some very important properties for interactive services such as DVB-RCS.
— Application Classes + Modes of Operation
The basic mode of operation of DVB-S2 is often referred to as “CCM”, or Constant Coding and Modulation. The term refers to the fact that the modulation and coding does not change over time. This is the mode that will be used for broadcasting, where the same signal is sent to many receivers. As is the case for any transmission of this kind, properties such as code rate and symbol rate must be tailored to the worst-case situation addressed by the service offering. CCM mode can of course be used for interactive services and other non-broadcast applications, in exactly the same manner as DVB-S is used for this today. However, the standard allows the modulation and coding to change over time. This offers important advantages for non-broadcast applications, as explained in the following.
Transmissions that carry “unicast” data; i.e., where each bit is destined for one receiver only, can take advantage of ACM to tailor the level of protection to the properties of that receiver. This can include “static” considerations of receiver sensitivity and location in the beam, but can also — and more importantly — be adapted dynamically to match the channel conditions existing for any receiver at any time. Doing this allows a very significant reduction of the propagation margins, compared to those that must be included in CCM systems. Depending on the propagation statistics, the use of ACM in this manner can provide improvements in spectral efficiency of 100 percent or more. The gain is obviously higher, the more severe the propagation conditions are. It will, therefore, typically be higher at higher frequencies, and in locations that experience intense rain.
At any one time, the total population of users in an ACM system will present a range of different needs for protection (i.e., for particular modulation / coding combinations). The mix needed, and the amount of capacity needed for each combination, may vary in time. DVB-S2 caters for this in simple fashion. The header of each frame carries the information needed to demodulate it; there is, therefore, no need for any higher-level structures or for any pre-determined distribution of capacity among different protection modes. Frames can simply be made up as needed.
ACM (or its sibling VCM) can also be applied to professional services such as news gathering. In such point-to-point applications, the protection mode is typically varied slowly, and for the entire carrier, in response to variations in the channel conditions at either end of the link. For such applications, this variation may be combined for example with adjustment of the data rate generated by video encoders.
— Frame and Packet Structures
The original DVB-S was developed specifically to transport an MPEG multiplex of several TV programs, known as a “transport stream”. Other applications had to adapt to this format. One example of this is the so-called Multi-Protocol Encapsulation (MPE), which is used for example in DVB-RCS systems to transport Internet Protocol (IP) datagrams over a DVB-S carrier. Likewise, the DVB-RCS signaling in the forward link is formatted to mimic that used for control of MPEG-based applications.
DVB-S2 offers the flexibility to use other organisations of the data, including the possibility of varying the packet size. Potentially, these so-called “generic streams” allow much more straightforward encapsulation for example of IP traffic. This can also potentially reduce the overhead.
The standardisation of generic streams encapsulation is in progress. The first revision of the DVB-RCS standard with support for DVB-S2 is still based entirely on MPEG transport streams.
One way of describing the benefits of adaptive coding and modulation is that this technique allows the elimination of rain margins for most users, most of the time. This gain can be put to use in a number of different ways, chosen according to constraints and objectives.
In current systems, two large contributors to the total cost of service provision are the forward link bandwidth and the RF power amplifier in the user terminal. At the same time, most current systems are unbalanced in the sense that there is much more traffic in the forward link than in the return link. The cost of the return link bandwidth is therefore of lesser concern (This is starting to change as a result of developments in the types of applications used, but it is a valid assumption for most current systems).
The expectation is to use the “adaptivity gain” in the forward link, mainly to increase the spectral efficiency, and that in the return link largely to reduce the necessary size (and hence the cost) of the RF power amplifier. With the usage pattern changes alluded to above, it is probable that some of the return link adaptivity gain will in future be directed towards spectral efficiency improvements as well.
— State Of The Industry
When work commenced in 2004 to incorporate DVB-S2 in DVB-RCS, the industry was just starting to make DVB-S2 equipment available. Since then, most DVB modulator manufacturers have produced DVB-S2 product offerings. Most support the CCM profile and some manufacturers are starting to announce ACM profile offerings. However, there are large development risks associated with the demodulator aspects of DVB-S2.
It is clear DVB-S2 is being driven by the commercial needs form the marketplace. As with DVB-S, the major user of the demodulators for DVB-S2 is the commercial direct-to-home set-top box. Since the broadcast profile in the DVB-S2 specification only requires support for the CCM profile, this is the area where most of the ASIC chip development has occurred. Therefore, the chipsets existing today are supporting the CCM profile only. Typically these ASICs are only guaranteed to work at symbol rates of 10 MBaud and higher. Some RCS manufacturers have decided to implement a low cost CCM solution to provide a solution to the marketplace to take advantage of the increased forward link efficiency. Today, SatNet has a solution implemented using CCM and working at symbol rates down to 4 MBaud. The consumer set top box (STB) ASICs available today support only the larger Normal Frame as is required by CCM broadcasting. The Short (16k bit) Frame is useful in ACM as it reduces the granularity and hence the potential bandwidth waste and latency in an adaptive system.
There are also several developments underway for ACM receivers, which will include support for the low symbol rates required by many of SatNet’ customers. These developments will enable migration to the ACM profile when commercial ACM system solutions are available. These solutions are targeted to interactive services. Advantech Wireless is working on its own implementation solutions for near-term incorporation into its DVB-S2-capable Series 5000 terminal, whereas its Series 4000 is already available with DVB-S2 CCM capability.
The Company first publicly demonstrated ACM modem operation for satellite systems in September 2006, and has been shipping the technology as part of its point-to-point terrestrial microwave links since March 2006.
Featuring DVB-S2
The top-level architecture of a DVB-RCS system with DVB-S2 is shown in Figure 3. Forward link traffic (IP datagrams) arrives from external networks. It is encapsulated and routed to parts of the forward link carrier with appropriate levels of protection for each destination terminal. Information about the mapping between terminal and protection level is provided by the Hub Return Link Sub-System (RLSS). Also provided by the RLSS is the time-varying signaling information for the terminals; in particular, the return link capacity assignments and control messages. The resulting carrier is transmitted through the satellite to the terminal, which demodulates all the frames it can — the demodulator is not tied to any particular modulation/coding combination. Traffic and signaling are extracted in essentially the same manner as for a DVB-S forward link. The main new element is that the terminal reports back the received signal quality, in combination with an estimate of the least-protected mode it can sustain.
Return link transmissions also use adaptation to the channel conditions. For forward link adaptation, the RLSS uses the received signal quality information to select an appropriate mode for each terminal, and signals this to the forward link equipment. This signaling closes the loop for the adaptive operation of the forward link. Return link adaptation decisions are also made within the RLSS; they are communicated to the terminals as part of the signaling already generated there.
In a comprehensive system, the mode switch “decisions” made in the RLSS and based solely on the link conditions will be routed to the Network Management System (NMS) before being implemented. Here, they will be treated as “recommendations”. Final decisions will be made in the NMS, and will include higher-layer considerations such as load balancing and conditions of service level agreements. This resource management function is extremely important for the overall performance of the system and for the provision of quality-of-service guarantees to individual users. It is also a highly complex function, in particular because it manages a transmission resource that has a time-varying total capacity: The information carrying ability of a DVB-S2 ACM carrier depends on how it is made up of frames with different protection level and therefore different spectral efficiency. The remainder of this paper is focussed on the physical and MAC layer aspects directly related to DVB-S2; we do not have the room here to treat the resource management and quality-of-service issues in any detail.
Major System Components
— Overall Gateway and Network Management
The main gateway components are the edge router, the forward link subsystem, the return link subsystem and the network management system. The edge router is a conventional IP router; it serves as the bi-directional traffic interface to the outside world. In some system configurations, it also performs the re-assembly of IP datagrams from ATM cells in the return link. The network management system is not shown in Figure 3, but network management functions are being developed for SatNet’s ACM product.
The remaining elements of the gateway are described as follows...
— Forward Link Subsystem
The Forward Link Subsystem (FLSS) serves to process the IP traffic to all terminals, to generate some parts of the signaling, and to transmit it all towards the satellite. An important new function of the FLSS in a DVB-S2 system with ACM is the switching/routing of traffic and/or signaling to appropriate protection modes.
The Company has concluded that switching at MPEG level is the most attractive option. The ACM switching is a result of events at the physical layer; restricting the implication to the lowest layer possible reduces impacts elsewhere in the system1. For the arrangement of the MPEG switching, a multi-stream architecture has been chosen for the forward link; that is, the DVB-S2 carrier is made up of a number of multiplexed transport streams.
1 For completeness, we mention here that it is in principle possible to implement adaptive coding and modulation without varying the properties of individual carriers over time. This requires a multi-carrier arrangement. Such arrangements have been considered previously, but have now been superseded by the features offered by DVB-S2. Some of the multi-carrier techniques may find application in other areas; e.g., implementations of DVB-RCS adapted for mobility.
The Return Link Subsystem is not modified fundamentally by the introduction of adaptive operation / rain fade countermeasures in the forward link. Advantech Wireless has selected to implement the basic detection and decision algorithms for forward link adaptation in the RLSS.
— User Terminal
The user terminal requires a DVB-S2 demodulator and decoder. Other functions include modification of the system 1 For completeness, we mention here that it is in principle possible to implement adaptive coding and modulation without varying the properties of individual carriers over time. This requires a multi-carrier arrangement. Such arrangements have been considered previously, but have now been superseded by the features offered by DVB-S2. Some of the multi-carrier techniques may find application in other areas; e.g., implementations of DVB-RCS adapted for mobility. timing synchronisation method, to adapt to the mechanism adopted for DVB-S2 ACM, and handling of multiple transport streams on one carrier. In addition, accurate measurement of the received signal Carrier to Noise Ratio and the reporting of the measure are vital to the operation of the ACM system.
Design Of Key System Components
— Forward Link Subsystem
The forward link subsystem consists of two main components: The IP-DVB encapsulator, which transforms a stream of IP datagrams into one or more MPEG transport streams, and the modulator, which generates the actual transmitted carrier. These elements are described next...
� General Functionality of the IP-DVB Encapsulator — The operation of the IP-DVB encapsulator differs somewhat, depending on whether or not the system employs adaptive coding and modulation. These two cases are described separately in the following.
� Systems Employing DVB-S and DVB-S2 with CCM — In current systems, the forward link gateway (IP encapsulator, IPE) implements the functions shown as a conceptual block diagram in Figure 4 on the next page. Incoming IP traffic packets are encapsulated over MPEG packets using the MPE protocol. This is the primary function of the gateway. In addition, the encapsulator generates the DVB Service Information (SI) signaling “tables” describing the characteristics of the network and the physical organisation of the transport streams. Encapsulators optimized for DVB-RCS networks have expanded this table generation feature to produce a number of tables that are specific to this application. These tables are relatively static; they describe top-level characteristics of the system and the return link air interface. One of the few differences between DVB-S and DVB-S2/ CCM is in the format of these tables; there are slight differences between DVB-S and DVB-S2 forward links in this respect. A further function of encapsulators for DVB-RCS is the inclusion of an MPEG multiplexer port. This port allows the inclusion in the transmitted stream of the more “dynamic” signaling. This signaling contains all real-time information needed for operation of the terminals, notably return link capacity assignments and correction messages for timing, power and transmit frequency. The arrangement shown in Figure 4 on the next page is also applicable to systems employing DVB-S2 in CCM mode. Aside from the above-mentioned differences in the SI tables (and the much better physical layer performance), there is no fundamental difference between the operation of DVB-S and DVB-S2/ CCM.
� Systems Employing DVB-S2 with ACM — In ACM mode, the encapsulator performs a number of functions in addition to what it does in CCM mode. Figure 5 shows a conceptual block diagram of the IP encapsulator for ACM operation. The Company emphasizes that this is a conceptual diagram; there are many possible ways of implementing functionality equivalent to that described here.
� Basic Function — In the selected architecture, the traffic is distributed among a number of transport streams, as opposed to the single transport stream used in CCM. The transport streams are quasi-statically configured; each corresponds to a particular protection level in the transmitted signal.
� IP Encapsulator — The IP Encapsulator device packages IP datagram packets on top of the MPEG packets that constitute the transport stream, using a protocol known as MPE (Multi-Protocol Encapsulation). In non-ACM/VCM implementations, this is a conceptually straightforward process: The IP packets are segmented as necessary (because they are in general larger than MPEG packets), equipped with header information and error detection (CRC) necessary for the re-construction in the receiver and mapped to a particular PID (Program Identifier) within the transport stream. A PID can be seen as a destination address or as a logical sub-division of a transport stream. The packets are then sent out of the encapsulator as a transport stream. Practical IP encapsulators used in DVB-RCS systems include a multiplexing function near their output, in which the encapsulated traffic is multiplexed with DVB-RCS specific signaling. This signaling can include capacity assignments and control messages to terminals and is generated in the Return Link Subsystem. It is delivered to the encapsulator as a transport stream. It makes sense to maintain this basic organisation for VCM/ACM operation, in order to enable the continued use of encapsulators designed for systems in which all transmitted information is handled in the same manner (i.e., those using DVB-S or DVB-S2 in “CCM Mode). There are however some small, but significant differences in the way this device is configured. All IP encapsulators offer the possibility of selecting the PID used for each IP flow. This selection is usually made on the basis of the IP destination address and/or the destination MAC address of the terminal. The IP encapsulator has a user-defined table that specifies this mapping. In SatNet’s architecture, the selection of the protection level (known as “MODCOD” in DVB-S2 parlance) to be used for each IP packet is done indirectly at this stage, by defining rules that map each supported MODCOD to a particular PID2. In other words, rather than an explicit mapping of terminals (IP addresses) to MODCOD’s, IP addresses are mapped to specific PID’s within the transport stream. The rationale for this method is that it allows the use of a conventional IP encapsulator, which is not aware of MODCOD’s. All traffic to all terminals is still contained within one transport stream at the output from the IP encapsulator. As will be explained, these PID’s are used down-stream in the Mode Adaptation Unit (MAU) to get the data to the correct modulation and coding scheme. VCM is implemented by a static table in the encapsulator, which always maps data destined for a particular terminal to a particular PID. ACM is in principle implemented in the same fashion, except that the table is updated in real time when the MODCOD required for a particular terminal changes. DVB-RCS signaling is handled in the same manner as traffic. The source of the signaling information (the RLSS) is aware of the MODCOD/PID mapping and generates the signaling MPEG packets with the appropriate PID values for the MODCOD on which they will eventually be transmitted. A properly implemented IP encapsulator does not alter the order of the incoming IP packets. Some delay and delay variation is introduced, due to the necessary processing in the device and because the signaling is usually given priority over traffic in order to meet system timing constraints.
� Mode Adaptation Unit — The primary function of the Mode Adaptation Unit (MAU) is to re-organize the incoming packets into DVB-S2 frames and to deliver these to the modulator. The main functional elements of the MAU are shown in Figure 5. The MPEG packets contained in the transport stream delivered by the IP encapsulator are routed to a number of different buffers, based on the PID value. There is one buffer per supported MODCOD. A device known as the “merger/slicer” controls a switch which guides packets off the buffers and into a device which formats them into DVB-S2 frames; at this point known as Baseband Frames (BBFRAMEs). The BBFRAME formatting consists largely of adding a header. Complete BBFRAMEs are delivered to the modulator.
� Data Rates — Each of the generated transport streams can carry a data rate that is likely to be far in excess of what the eventual DVB-S2 carrier can support. Note that, due to the time-varying demand on the different protection levels, combined with the fact that there is no pre-determined make-up of the DVB-S2 carrier, the total capacity of the carrier will vary over time. This may have an impact on the services and, in a fully managed system, requires traffic shaping. Traffic shaping is a complex matter, which involve the Edge Router (and possibly other IP network components) intimately. The policy of the merger/slicer is a key point in the architectural considerations surrounding the mode adaptation; in particular because it can have a significant impact on the Quality of Service, in the form of packet re-ordering and excessive delay. Typically, the algorithm used to select the MODCOD to serve for any particular frame is a form of a weighted round-robin scheme, which ensures that all MODCOD’s get served reasonably often, but gives priority to those with the highest traffic load. A fully optimized merger slicer needs to be aware of the Quality-of-Service attributes of individual packets. It is no trivial matter to make this information available to the merger/slicer algorithm. However, simpler (QoS-agnostic) algorithms can be used with only a modest impact on either quality of service or bandwidth utilization.
Other Considerations
• Multicasting: The IPE can support multicasting. It is expected that, at least initially, all multicasting traffic will be carried in the most protected mode available.
• Quality of Service: Quality-of-Service provisioning in networks with a variable physical layer is a complex process, which has not yet been addressed in the context of interoperability between manufacturers. In any case, QoS aspects are outside the scope of this paper. We just notice here that one possible way of propagating QoS to the MAC/physical layers of DVB-S2 with multi-stream ACM is to arrange for the grouping of packets with different service requirements / priorities within each protection mode (similar to the classes of the service of the DiffServ model at IP level). Such an arrangement will tend to increase the number of streams that must be supported.
— Modulator
A modulator for DVB-S2 does more than the actual encoding and modulation. It must also create the framing structure and insert the corresponding physical-layer signaling in the stream. When operating with adaptive coding and modulation (ACM), the modulator must also perform certain timing functions that actually modify the transmitted data. Top-level block diagrams for the two versions of the modulator defined in this document are shown in Figure 7 and Figure 6. The two versions are described in the sequel. The CCM functionality is a strict sub-set of the ACM functionality.
The descriptions are based on transmission of MPEG-2 Transport Streams. It is however noted that the operation may eventually be extended to cater for other types of input packets in so-called “generic streams”.
� VCM/ACM Modulator — The VCM/ACM modulator performs many of the same operations as the CCM version, plus some additional ones. The most fundamental difference is that the processing is not a simple, uni-directional sequence of operations. A typical block diagram of the VCM/ACM modulator is shown in Figure 6. VCM and ACM are practically equivalent in terms of modulator functionality. For brevity, we therefore refer to this device in the sequel simply as an ACM modulator. As described above, the generation and sequencing of baseband frames (BBFRAMES) is a non-trivial process in an ACM system. It involves considerations of data content properties above the physical layer, ideally all the way up to Quality-of-Service aspects. In most cases, the nature of this processing will therefore be at least somewhat dependent on the application. The initial version of the DVB-S2 standard nevertheless includes the mode adaptation function (generation of BBFRAME’s) inside the modulator. Many implementers have realized that this advanced and specific mode adaptation functionality is not in its natural home as an integral part of the modulator, which is generally seen as a generic, physical-layer device. An alternative architecture has therefore been adopted, in which the mode adaptation function is handled separately, so that the input to the modulator is a sequence of BBFRAME’s, each tagged with the MODCOD to be applied to it. The modulator’s job is then reduced to transmitting the sequence of BBFRAME’s in the order they arrive. The processing proper in the ACM modulator therefore starts with the stream adaptation; i.e., the creation of FECFRAME’s. The rest of the processing follows essentially the same sequence as in a CCM modulator, If the rate of arrival of BBFRAME’s is lower than that supported by the carrier, the modulator generates “dummy” frames. If the frame rate is too high over an extended period of time, the modulator has no choice but to drop frames. This is approximately equivalent to the null packet insertion and packet dropping performed in the CCM modulator. Because of the asynchronous nature of the up-stream processing, in particular the buffering and selection operations of the mode adaptation function, the method adopted for distribution of timing information (Network Clock Reference packets) in ACM systems is different from that used for DVB-S and DVB-S2 CCM. In ACM, the timing is related to the transmission time of the physical layer DVB-S2 frame header. It is therefore in practice necessary to insert (“stamp”) the timing reference values inside the modulator. This stamping is done before the stream adaptation, but based on time values only obtained downstream. This is illustrated by the feed-back connection shown in Figure 6. The remaining functions of the ACM modulator are equivalent to their CCM counterparts.
Depending on equipment design, it is of course possible to locate the mode adaptation function within the same physical enclosure as the modulator; for example as an optional circuit board.
Return Link Subsystem
As mentioned above, the detection functions for forward link adaptivity (Rain Fade Countermeasures, RFCM) are implemented in the RLSS. This will complement the already existing support for RFCM on the return link. The goal is to provide a full integration of both Forward Link and Return Link Adaptive Coding and Modulation (ACM) in the RLSS. This integration consists of the addition of forward link measurements to the RFCM detection algorithm, and the addition of RFCM modes to the Control of the terminal. Finally, this includes the interface to the IP Encapsulator and the adjustments required to the signaling to cover forward link protection modes. In the forward link, decisions about appropriate protection are based mainly on the Es/N0 and/or required protection level reported by the terminal. A mode switch decision generates a routing command to the encapsulator. The forward Link Es/N0 is reported by the terminal.
User Terminal
The Satellite Interactive Terminal (SIT) is used as part of a DVB-RCS network to exchange traffic data and signaling information with a centralized Hub. There are two transmission paths; the Forward Channel from a central Hub to the user terminal, and a Return Channel from the user terminal to the central Hub. The terminal is composed of two main elements, an Indoor Unit (IDU), and an Outdoor Unit (ODU). The Series 5000 IDU from Advantech Wireless is shown in Figure 8; the Series 5000 IDU features CCM/, VCM and ACM functionality. Refer to Figure 8 for the Series 4000 IDU which has CCM only functionality. The Host PC is also not considered to be part of the terminal; it is assumed to be part of the user’s equipment.
The main features required in the terminal for support of DVB-S2 are the following:
DVB-S2 receiver with an L-band input interface and a baseband digital output interface consisting of demultiplexed streams and a control interface
Handling of re-assembly of IP packets from multiple logical streams
Operation with the adopted DVB-S2/DVB-RCS timing distribution method
Signaling of forward link Es/N0 and supported modulation/coding combination in the SYNC burst
Extension of SNMP operation to cover ACM-related configuration parameters
Acknowledgements
Thanks go to the Canadian Space Agency and Telesat for their participation and support on Canadian R&D programs developing and demonstrating a DVB-RCS system featuring DVB-S2 capabilities.
Reference
[1] ETSI EN 301 790, v1.4.1, “Digital Video Broadcasting (DVB): Interaction Channel for Satellite distribution Systems”
[2] ETSI TR 101 790, V1.2.1, “Digital Video Broadcasting (DVB); Guidelines for the use of EN 301 790”
[3] ETSI EN 302 307, v1.1.2, “Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications”
By Mark Lambert