DVB-RCS has always had a very efficient return link arrangement, including the use of turbo coding and a MAC layer that facilitates very efficient capacity scheduling (MF-TDMA). With the addition of DVB-S2, systems operating according to the DVB-RCS standard are achieving state-of-the art technology throughout. Indeed, the DVB-RCS standard encompasses the DVB-S2 standard for forward link transmissions; this has been the case since the last publication of DVB-RCS in 2005.

DVB-S2 is a cornerstone of the evolution of forward link performance in SatNet's DVB-RCS systems. SatNet offers both hubs and terminals that support DVB-S2; this is in fact the standard product offering, and SatNet has been the first VSAT supplier to offer this, with its DVB-S2 product launch done in June 2006. DVB-RCS encompasses all three operating modes of DVB-S2: Constant Coding and Modulation (CCM), Variable Coding and Modulation (VCM) and Adaptive Coding and Modulation (ACM). For more information on how DVB-RCS and DVB-S2 are used together, please refer to: Synergistic Benefits of DVB-S2 and DVB-RCS

SatNet's peer-to-peer mesh connectivity cuts in half both the transmission delay and the bandwidth occupied by such traffic, bringing advantages for both communications quality and cost; the greatest benefits are achieved for delay-sensitive real-time applications such as voice. The SatNet DVB-RCS implementation of a transparent mesh system provides an overlay to the standard star network architecture. This mesh overlay architecture achieves a combined star/mesh network, initially allowing the hub to support independent Star and Mesh terminal populations and ultimately supporting terminals able to operate in both Star and Mesh mode concurrently. The hub station performs the network management and control functions for the mesh overlay network. For more information, please refer to:Mesh Terminal Product Datasheet

TCP Acceleration

The embedded TCP acceleration provided in SatNet's terminal products provides a high performance solution for DVB-RCS satellite networks. The support for high TCP throughput even in pure VBDC operation is a key feature of the SatNet system solution. Future releases of the terminal products will target the recently released SatLabs Interoperable PEP (I-PEP) standard, thus furthering the benefits of DVB-RCS open standard interoperability in a multi-vendor environment. Software upgrades to the Interoperable PEP will be facilitated for both terminals and the PEP server at the satellite gateway, the latter simultaneously and transparently supporting mixed populations of both old and new terminal products to provide investment protection for existing customers.

HTTP Acceleration

SatNet's terminal products also include embedded HTTP pre-fetching capabilities. This, in combination with the TCP PEP capabilities, provides substantially enhanced web browsing performance. The SatNet solution focuses on reducing page load times while supporting pure VBDC operation, providing improvements to both the user and operator experiences. An HTTP enhancement standard for DVB-RCS is also under definition in the SatLabs community and SatNet's interoperable approach is compatible with the current baseline.

Data Compression

SatNet's PEP solution also performs payload compression for TCP traffic. The solution focuses on delivering a balance of efficiency and performance by employing a solution with highly competitive compression ratios but negligible impact on traffic latency. The focus on TCP traffic targets compression effort at potentially compressible traffic, as opposed to VoIP or other traffic from real-time applications that is commonly compressed at source. This advanced scheme is adaptive per flow to maximize compression while virtually eliminating unnecessary processing for non-compressible flows. The compression scheme comprises not only web traffic but also FTP and all other TCP applications while faithfully delivering all original information without loss or degradation.

back to the top

Traffic transmission collisions cannot occur in the SatNet DVB-RCS system. Rather, bandwidth is assigned dynamically via an extremely flexible and agile scheduling (or reservation) system. There are a number of capacity request mechanisms possible in DVB-RCS to reserve the capacity. The request mechanisms implemented by SatNet include:

• Rate Based Dynamic Capacity (RBDC)
• Volume Based Dynamic Capacity (VBDC)

The bandwidth assigned to a terminal is scheduled in the SatNet Hub. Terminal requests for bandwidth are received via two paths, the in-band request (IBR) and the out-of-band request (OBR). The in-band request is contained in a very small satellite access control field appended to the traffic bursts. The out-of-band requests are in a similar field attached to the synchronization bursts. The SatNet Hub periodically analyses the IBR and OBR requests and assigns traffic capacity to the requesting terminals

The SatNet Hub processes each of the different types of requests from a terminal separately. There are separate assignment mechanisms for RBDC and VBDC. In addition there are two other assignment mechanisms, Constant Rate Assignment (CRA) and Free Capacity Assignment (FCA). Each assignment type has unique properties and is used for different types of traffic:

• CRA Real-time jitter intolerant such as VoIP
• RBDC Near real-time jitter tolerant such as streaming video
• VBDC Non real-time applications such as FTP or HTTP
• RBDC FCA Non real-time applications and opportunistic request mechanism

The terminal does not request CRA capacity. Each terminal has a CRA value ranging from zero up to the total capacity of the return link channel or the individual terminal transmit rate limit.

The terminal requests RBDC capacity in small units. The RBDC assignment must be requested periodically. The periodicity of the RBDC request is determined by a time-out value which can be configured. RBDC can handle near real-time applications, but there is an inherent delay as the first RBDC request is processed. Once the terminal processes the first assignment, the RBDC traffic is very similar to CRA traffic if RBDC is not overbooked.

VBDC requests are made by considering bytes of data quantized to the slot size used in the return link. The terminal requests the equivalent number of slots.

Dynamic bandwidth assignment and quality of service are both managed by the service provider via the c. A very powerful example of this is SatNet's Virtual Telephony™ feature and the NetManager's Connection Control Protocol, which assigns CRA capacity at call setup time in order to guarantee adequate capacity for VoIP phone calls.

back to the top

SatNet implements IP QoS on the forward and return links. In the forward direction, SatNet is proposing to service providers a well-developed solution to enhance IP QoS by providing traffic shaping in mixed-media networks; this becomes most effective when the number of terminals grows beyond 100 or when specific traffic types demand it. In the return direction, SatNet has multiple priority queues in the terminal to enable QoS levels together with sophisticate traffic filtering options. SatNet's QoS system capabilities include:

• Manage and control bandwidth usage and number of sessions/connections of critical applications such as VoIP and Video (return and forward links)
• Set priorities of traffic types such as VoIP (return and forward links)
• Guarantee bandwidth for critical applications (return and forward links)
• Enforce traffic-exclusion decisions (return link)

These capabilities complement SatNet's high level QoS capabilities:

• Manage and control bandwidth distribution between multiple service providers on one hub/gateway
• Manage and control bandwidth distribution per customer for each service provider
• Manage and control user group traffic per customer
• Manage and control individual terminal traffic within user groups

Dynamic bandwidth assignment and quality of service are both managed by the service provider via the NetManager™.

back to the top

IPSec specifies a comprehensive approach to providing robust security for authentication of data (to detect modifications) and encryption of data (to prevent reading); it relies on many underlying technologies. The use of TCP performance enhancement techniques in the context of IPSec VPNs has led to the notion of "accelerated IPSec VPN". SatNet offers two solutions, a first solution for accelerated IPSec VPN at Corporate Center (also end-to-end accelerated IPSec VPN) and a second for accelerated IPSec VPN at the Hub. The accelerated VPN solution relies on the use of IPSec-capable products, with IPSec used in tunnel mode, with the tunnels built between the PEP end points, which are located at the boundaries of the virtual private network.

Accelerated IPSec VPN at the Corporate Center

For illustration purposes, one can imagine a private corporate network with one main office and two remote offices. Under this solution, communications between remote offices (involving two satellite hops) are possible. Encrypted paths, or IPSec tunnels, are implemented between the main office and the two remote offices with one end-point of each IPSec tunnel located in the VPN Server at the main office; thus security is guaranteed between the two remote offices. A SatNet PEP server is installed at each corporate center and into the terminal. The QoS capability is implemented at the hub in the traffic path and DiffServ is used to allow application differentiation.

Accelerated IPSec VPN at the Hub

The SatNet PEP and the QoS capabilities are implemented at the hub in the traffic path. The VPN Server is installed at the hub in the traffic path. All the IP traffic is encrypted in the forward and return directions. IPSec tunnels can be established from the terminal side or the hub side. Multiple tunnels can be set up per terminal to support application differentiation based on the destination IP addresses. Communications between two terminals are encrypted using two bi-directional IPSec tunnels, i.e. one bi-directional IPSec tunnel per terminal.

With an application layer SSL (Secure Socket Layer) that provides VPN technology, organizations can securely share critical information and applications with employees, customers, and business partners via the internet.

Accelerated SSL (Secure Socket Layer) at Corporate Center

The PEP compatible SSL VPN server is installed at the Corporate Center and the client is installed at the Host.The SatNet PEP and the QoS capabilities are implemented at the Hub in the traffic path. This solution allows encrypted applications to run from the host to the SSL VPN Server. This solution provides end users security over the local Terminal LAN, the satellite link and over the Internet. The traffic is encrypted in both directions, unless the host is accessing normal web servers over the Internet. This solution provides TCP acceleration over the satellite link.

back to the top

The SatNet DVB-RCS system supports scenarios for two-way multicast:

• Scenario in which the multicast content source is behind a terminal.
• Scenario in which the multicast content source is at the hub.

Multicast at the Hub

Multicast from behind the hub is supported by the Satnet hub and terminals. The desired multicast routes are configured in the hub and IGMP "joins" are performed between the hub's router and IP encapsulator (IPE). When multicast traffic is received by the Satnet hub, it is forwarded by the router to the IPE which encapsulates and transmits the multicast traffic on the Forward Link. The hub also transmits a multicast mapping table that indicates to the terminals on which PIDs multicast traffic can be received. The terminal will forward the multicast stream on its LAN interface, provided that it has received an IGMP "join" for that multicast stream from a local host.

Multicast from behind a Terminal

Performing a multicast from behind a terminal can pose a challenge: when the multicast reaches the router at the hub, it will fail the Reverse Path Forwarding (RPF) check, unless... the IP router used in the Hub is configurable to bypass RPF check or a method exists to force it somehow. To solve this problem, SatNet recommends either the use of a multicast tunnel, or mTunnel, or to re-write the IP source address in the packets seen going out of the return link sub-system into the router.

back to the top