5_Annex 6 4 - SkyEdge II Technical Description v5

Annex 7.2 - SkyEdge II Technical Description 17/04/2011

Gilat Network Systems 17/04/2011

This document contains information proprietary to Gilat Satellite Networks Ltd. and may not be reproduced in whole or in part without the express written consent of Gilat Satellite Networks Ltd. The disclosure by Gilat Satellite Networks Ltd. of information contained herein does not constitute any license or authorization to use or disclose the information, ideas or concepts presented. The contents of this document are subject to change without prior notice

[]

II Technical Description v5, April 2011

Table of Contents Introduction ...........................................................

1.

....................................................................

1.1 The SkyEdge II System .........................................................

.................... 5

.................................................................. 5

1.2 Benefits for the SkyEdge II Operator ..........................................................

.......................................... 5

2.

SkyEdge II System Overview ..............................................................................

...........................................

3.

SkyEdge II Hub ...................................................................

.....................................................................

3.1 Hub Overview ............................................................................................................

SkyEdge II VSATs ........................................................................... 4.1 SkyEdge II IP ..............................................................

................ 11

................................................... 14

3.4 Hub Configurations ......................................................................................

4.

........................................

15

...............................................................

......................................................................

4.2 SkyEdge II Extend ................................................................................................................. 4.3 SkyEdge II Access ..................................................................

..... 11

........................... 11

3.2 Hub components .................................................................................................................. 3.3 Optional Hub components ...............................................................

8

17 ..... 17

................ 17

............................................................... 17

4.4 SkyEdge II Pro ....................................................................................

...................................................

4.5 Expansion Cards ........................................................................................................

18

........................... 18

4.6 Local configuration and management ............................................................................................... 19 4.7 Outdoor Equipment .............................................................

NetEdge ..................................................................

5.

................................................................ 20

......................................................................

................ 21

5.1 Using NetEdge for Multi-Star Private Networks ........................................................................... 5.2 NetEdge Technology ............................................................................................................

Network Management System (NMS) ...............................................................

6.

6.1 SkyMon

. ............................................................................

6.2 VSAT Auto Pointing System (VAPS) .............................................................

DVB-S2 ACM Outbound ...........................................................................

7.

........................................

7.3 CCM and ACM ...........................................................

........................................

................................................... 30

7.5 SkyEdge II ACM implementation ................................................................ 7.6 SkyEdge II DVB-S2 Enhancements ..............................................................

..... 31 ..... 32

.........................................

33

........................................ 33

................................................................ 37

8.1 DVB-RCS background .............................................................................................. 8.2 SkyEdge II DVB-RCS Access Scheme .........................................................................

.............................

37

........................... 38

8.3 SkyEdge II Physical Layer implementation ......................................................................................... 42

i

30

................ 30

......................................................................

DVB-RCS based Inbound .............................................................

25 28

....................................................

7.4 SkyEdge II DVB-S2 Specifications ...................................................................................................

8.

24

.........................................

7.1 DVB-S2 Background ............................................................................................................. 7.2 DVB-S2 Spectral efficiency ...............................................................

..... 21

................ 23

Proprietary and Confidential

[]


SkyEdge II T echnology .................................................................

9.

............................................................... 49

9.1 TCP Acceleration .............................................................................................................................

..... 49

9.2 HTTP acceleration ................................................................................................................

................ 51

9.3 IP protocol Support ..............................................................................................................

................ 54

9.4 QoS capabilities ........................................................

......................................................................

9.5 IP Telephony in SkyEdge II ......................................................................................

9.6 Mesh Connectivity (SkyEdge II Access and Pro) ............................................................................ 9.7 Network Bonding ..................................................................

60

..... 61

............................................................... 64

10. Specialized VSAT Applications ................................................................

................................................... 66

10.1 SkyAbis Cellular backhaul ........................................................................... 10.2 Multiple applications in a shared network

..... 57

.............................

.........................................

...........................................................

11. Acronyms ..................................................................................................

....................................................

11.1 SkyEdge II Acronyms ............................................................................................... 11.2 General Acronyms ............................................................................

66

............................. 67

.............................

....................................................

68 68 68

Table of Figures Figure 1: SkyEdge II Mesh and Star Topology

...............................................................

............................... 9

Figure 2 - NetEdge Topology ......................................................................................................................... 9 .................. 11 Figure 3: Traffic flow through the hub components ............................................................... Figure 4: SkyEdge II Hub - Rack Layout ............................................................................ ........................... 12 Figure 5: IPM rear panel ......................................................................................................................... ..... 13 Figure 6: SkyEdge II Access and Pro – Expansion Slots ............................................................ .................. 18 Figure 7: Outdoor Unit Components ................................................................ ......................................... 20 Figure 8 General topology of a multi-star corporate network ............................................................ ..... 21 Figure 9 - Multi-star high-level topology with Mesh VSATs (MV) and NetEdge GWs ............................. 22 Figure 10: NMS Main Screen ....................................................................................................... ................ 24 Figure 11: SkyMon Dashboard ................................................................ .................................................... 26 Figure 12: Fault Management View ................................................................... ......................................... 27 Figure 13: Sample report - Outbound Symbol Rate per ModCod ............................................................ 2 8 Figure 14: SkyManage VAPS interface ............................................................................. ........................... 29 Figure 15: DVB-S2 Modulation schemes ............................................................ ........................................ 30 Figure 16: Spectral efficiency of DVB-S2 .................................................................................................... 31 Figure 17: CCM example ...................................................................................... ........................................ 31 Figure 18: ACM Example .............................................................. ................................................................ 32 Figure 19: SkyEdge II ACM implementation ............................................................................... ................ 33 Figure 20: SkyEdge II efficient packing of MPEG frames ......................................................... .................. 35 Figure 21: SkyEdge II Real time scheduling ................................................................................................ 35 Figure 22: SkyEdge II greater efficiency scheduling .................................................................. ................ 36 Figure 23: Time Frequency Plan with different bursts .............................................................................. 38 Figure 24: Frames and Superframes ......................................................................................... .................. 39 Figure 25: TRF Burst .......................................................................................................... ........................... 39

ii


[]


Figure 26: ATM cell makeup ............................................................................... ......................................... 40 Figure 27: CSC Burst .................................................................................. ................................................... 42 Figure 28: Logon and initial sync ............................................................. ................................................... 42 Figure 29: SkyEdge II Inbound ModCods .................................................................................... ................ 43 Figure 30: Example – Time Frequency Plan .................................................................... ........................... 44 Figure 31: ICM-1D change to lower symbol rate ....................................................................................... 45 Figure 32: ICM-2D change to lower ModCod .................................................................. ........................... 46 Figure 33: ICM-3D – AUPC ........................................................................................................... ................ 46 Figure 34: ICM-4D – Dynamic Channels ............................................................. ........................................ 47 Figure 35: Frequency hopping options ....................................................................................... ................ 48 Figure 36: TCP traffic without acceleration .................................................................... ........................... 50 Figure 37: TCP traffic with acceleration ............................................................. ........................................ 51 Figure 38: HTTP traffic without pre-fetching ............................................................................................. 51 Figure 39: HTTP traffic with pre-fetching ................................................................................... ................ 52 ................ 53 Figure 40: Use of a persistent TCP link ....................................................................................... Figure 41: VRRP .............................................................................................................. .............................. 56 Figure 42: SkyEdge II Multi-VLAN, VRF support .................................................................................... ..... 57 Figure 43: Managed Private Networks .................................................................................................. ..... 59 Figure 44: VoIP Topology ......................................................................... .................................................... 60 Figure 45: Cellular backhaul ................................................................................................................... ..... 66 .................................................... 67 Figure 46: Shared hub ..............................................................................

iii


[]


1.Introduction 1.1 The SkyEdge II System SkyEdge II is a high performance, high efficiency two-way satellite communication solution used for a variety of applications and services. It combines reliable support for IP communication as well as telephony and multimedia applications utilizing advanced technologies for efficient usage of the satellite’s space-segment resources. SkyEdge II is the optimized solution for every satellite networking need, easily built, maintained and then expanded as the networks requirements change. Offering more than mere connectivity, optional value added services are enabled by add-ons and equipment from Gilat which is integrated with the SkyEdge II system. SkyEdge II is based on the concept of a single hub which can efficiently work with different types of VSATs to support different needs and applications.

A SkyEdge II System consists of the following components: SkyEdge II Hub (Section 3) the center of the network, providing management and control of communications between VSATs, corporate networks, the internet and the Public Switch Telephony Network (PSTN). SkyEdge II family of VSATs (Section 4) provide users a fast, stable and transparent communication link for all their applications. SkyEdge II VSATs provide data connectivity as well as embedded telephony and multimedia support. SkyEdge II Network Management System (NMS) providing central management of the VSATs and the Hub via a graphical user-friendly interface.

1.2 Benefits for the SkyEdge II Operator The SkyEdge II System is a comprehensive solution for satellite networking needs. Network operators such as service providers and enterprises with dedicated networks, are able to create and manage efficient and cost effective solutions that quickly address end customer needs. Key benefits of SkyEdge II are: High performance for data and multimedia applications, with excellent user experience: o

o

o

High bit rates in both forward and return link, with up to 135Mbps per outbound carrier and 6Mbps per inbound carrier Comprehensive application acceleration solutions embedded in the VSATs hardware Advanced built in QoS mechanisms, allowing high flexibility in meeting user requirements per the required SLAs and the applications used

Lowest Total Cost of Ownership (TCO) with efficient bandwidth handling: o

5

High order modulations with Turbo coding on both the inbound and outbound:


[]


o

Outbound – 32APSK, 16APSK, 8PSK, QPSK

o

Inbound – QPSK, 8PSK

o

Dynamic optimization of bandwidth efficiency through the use of Adaptive Coding and Modulation (ACM) for both the inbound and outbound

o

Acceleration, optimization and compression for TCP and HTTP traffic.

o

VoIP traffic optimization

o

Shared inbound bandwidth for mesh and star traffic

High scalability with low entry level capital requirements: o

Single, all-in-one system for broadband data, VoIP and Video over IP

o

Low basic bandwidth requirement, with a modular expansion path for the hub

o

Tailored VSATs within the SkyEdge II product line support different markets and applications, optimizing the solution for each customer

High system reliability o

High MTBF for hub and VSAT equipment

o

Powerful redundancy schemes for all hub components

o

Robust access schemes with adaptive technology in both the inbound and outbound

Enhanced capabilities supported through multi-platform VSATs: o

VPN client with acceleration

o

TCP acceleration

o

Payload and header Compression

o

Multi VRF and VLAN

o

HTTP acceleration

o

Embedded Voice (SkyEdge II Access and Pro)

o

Mesh add on card (SkyEdge II Access and Pro)

o

Traffic encryption

Based on standard technologies

6


[]


o

DVB-S2 outbound

o

DVB-RCS inbound

High capacity for large networks o

o

Support up to 30,000 VSATs from one hub Outbound carrier up to 135Mbps and up to 300Mbps for a multiple outbound hub architecture

Broad coverage of all market segments, services and solutions: o

o

o

Market Segments —Enterprise/Corporate, Carriers, Governments, Service Providers, Private sectors and Small Office Home Office (SOHO) Services — Broadband IP, Public telephony, VoIP, Video over IP, multimedia, video surveillance, cellular backhauling, Credit card transactions and more Solutions — Rural (USO), SOHO/SME, GSM Backhaul, Rapid deployment, Military, SCADA, Financial, Oil & Gas, disaster recovery & backup

MultiStar supported by existing hub o

7

Cost efficient addition of a uStar to an existing network 

Cost effective Gateway, managed by the hub



Efficient link budget of VSAT's connected to the uStar

o

Single hop to hub and Gateway

o

Protocol Acceleration with Gateway traffic


[]


2.SkyEdge II System Overview Using experience gained from twenty one years of satellite communications development and deployment, Gilat has combined best of breed features into a high-performance platform. The SkyEdge II family can handle any combination of data and telephony on the same hub platform. Operators using the system have the maximum flexibility to tailor the right mix of services for local needs, helping maximize revenue streams per the investment. The SkyEdge II System’s communication capabilities include: Interactive broadband IP Data, IP and multimedia unicast and multicast Rich VoIP capabilities A set of completing and supporting solutions

The SkyEdge Network The main element in the SkyEdge II network is the Hub. The hub uses one or more Outbound channels (over the air link transmissions from the hub to the VSATs) to communicate to all the remote sites. The Hub uses Radio Frequency Transmission (RFT) equipment that is connected to the hub antenna (usually 3.7 meter and above) which transmits and receives signal to and from a geostationary satellite. ThisSkyEdge satelliteIIreflects thework signals towards the land a geographical that covers the serviced VSATs. Hubs can with more than one in satellite to enablearea multicontinent coverage working with several outbound channels. The SkyEdge II Hub statistically and dynamically multiplexes management and user traffic into the outbound in unicast and multicast streams. VSATs receive the outbound and intercept the information which is transmitted to them or the hosts and other equipment (such as telephones) connected to them. Advanced coding, error correction techniques and security features are used to enable a reliable and secure transmission. The SkyEdge II Hub includes TCP and HTTP acceleration technologies to increase the user experience and further reduce the required bandwidth per user. VSATs, residing in the remote locations, log-on and authenticate in the NMS database after power-on and then receive their configuration from the Hub database. Transmission can then start while the hub utilizes multiple inbound channels to receive signals from different VSATS. A DVB-RCS based access scheme is used for transmission. With this technology all VSATs have the capability to request capacity and then transmit in their allocated time and frequency. SkyEdge II uses Multi-Frequenc y Time Division Multiplexing Access (MF-TDMA) in the inbound. This technology means that each VSAT can transmit in each time slot in a different frequency. It yields the optimal usage of satellite resources, meaning the network operator can use a smaller bandwidth to serve more VSATs leading to a better return on investment.

8


[]


Mesh Me

SkyEdge II Pro

sh

Star

SkyEdge II Access

SkyEdge II Hub

SkyEdge II IP SkyEdge II Access

PSTN

High Speed Internet

Figure 1: SkyEdge II Mesh and Star Topology

VSATs usually use smaller antennas (e.g. typically 1.2 meter or smaller antenna for Ku-band) than the hub to transmit signals to the satellite. The transmission is done with an Outdoor Unit (ODU) that includes an RF amplifier for transmission (BUC) and an RF receiver for reception (LNB). The Network Management System (NMS) is connected to the hub and manages both the hub components and the remote VSATs. It features XML and SNMP interfaces for integration to OSS and BSS systems. NetEdge Multitar topology allows building a single, highly efficient and modular satellite access network with multiple private mesh networks within it. Each private network is typically used by a business or a government entity, and is built around a central node. The central node may be the regional HQ for a corporate network, or a regional cellular BTS Controller (BSC) for a cellular network with multiple BTS sites.

Figure 2 - NetEdge Topology

9


[]

10



[]


3.SkyEdge II Hub 3.1 Hub Overview The hub concentrates the satellite traffic, controls and monitors the network working modes, and serves as the main access point to terrestrial networks. The hub forms the center of the star and multi-star topologies. The hub interfaces with the customer’s host computers and the Internet, supports multiple satellite channels of inbound and multiple outbound channels for communication with the VSATs. The SkyEdge II hub has a modular architecture, enabling the addition of equipment as the network grows. It can also be configured with multiple levels of redundancy as required. NTP synchronization is optionally supported from a customer supplied NTP server. The following diagram shows components used in the inbound and outbound paths.

Inbound Segment

IPM Outbound Segment

Figure 3: Traffic flow through the hub components

3.2 Hub components Figure 4 below shows a sample a rack layout with the main hub components.

11


[]


MCR –Multi-Channel Receiver Network Switch RF Switch IPM – IP Encapsul ator and Modulato r KVM – Keyboard, Video & Mouse switch DPS – Data Protocol Server HSP – Hub Satellite Processor Based on UHP– Unified Hub Processor

NMS servers

Figure 4: SkyEdge II Hub - Rack Layout

3.2.1 Radio Frequency Transceiver (RFT) The satellite dish and Outdoor Unit (ODU) feed into the RFT (sometimes housed in a separate rack). The SkyEdge II hub supports C-band and Ku-band, with future support for Ka-band and X-band. The supported RF interfaces are presented in the following table. Category Physical Frequency Range

Tx\Rx Tx Rx Tx

Parameter N- type, 50 ohm N- type, 50 ohm Standard – L Band (950-1700MHz) Optional – IF interface (Via Up\Down converters)

Rx Typical Power levels

Tx Rx

-20 to +5dBm Noise floor range: -130 to -105dBm/Hz Signal range: -94 to -9dBm

Table 1: HUB RF Interface

3.2.2 SkyEdge II IPM The IP encapsulator and modulator (IPM) encapsulates IP packets received from the DPS into MPEG2 transport stream with several PID tags (Program ID), according to the destination IP address of incoming packets. The IPM also schedules traffic according to priorities and link conditions (ACM mode). The timeslot allocation tables for inbound traffic are provided b y the HSP for inclusion into the outbound stream. The IPM supports data rates of 135 Mbps (single carrier) up to 300 Mbps (multiple carriers). Baseband frames (BBFRAMES) then undergo BCH and LDPC encoding to generate FECFRAMES, which are frames which share the same transmitted Modulation and Coding (MODCOD). FECFRAMES are then bit-mapped to QPSK, 8PSK, 16APSK or 32APSK constellations, to generate Physical Layer frames

12


[]


(PLFRAMES). Pilot symbols may be optionally added for improving receiver synchronization when working with high order modulations. The IPM includes the system clock source and has the following specifications: Modulati on: QPSK, 8PSK, 16APSK, 32APSK(upto: 30Msps) L-band output: 950 – 1750 MHz, tunable in 1 KHz 10 MHz frequency reference Symbol rate: 0.3 - 45 Msps Configurab le roll-off factor: 20%, 25%, 30%,

35%

The rear panel of the IPM including connectivity is shown below.

Figure 5: IPM rear panel

The IPM may be deployed in a 1+1 redundant configuration.

3.2.3 Multi-Channel Receiver (MCR) The MCR supports the SkyEdge II DVB-RCS inbound access scheme. single or multi-channel modes:

Each 1u unit can function in

Multi-channel mode – each MCR supports up to a total of 1536ksps, which can be utilized by up to 12 channels of 128ksps. Up to 4 carrier types can be supported. Carrier types are described below (Section 8.3.1.3) . Single channel mode – the MCR supports a single channel of up to 2560ksps, with 1 Carrier Type. MCR specifications: Modulati on: QPSK and 8PSK FEC schemes QPSK – 1/2, 2/3, 3/4, 4/5, 6/7 FEC schemes 8PSK – 2/3, 3/4, 4/5, 6/7 L-band input: 950 – 1700 MHz Clock is extracted from the outbound Up to 32 MCRs in a network segment

13


[]


Up to 12 MCRs in a single chain (single HSP) The MCRs may be configured in an N+1 redundancy scheme (monitored and controlled by the HSP).

3.2.4 Hub Satellite Processor (HSP) Demodulated traffic fro m the MCRs in the form of TRF bursts with ATM cells is reconstructed (de encapsulated and reordered if required) by the HSP and then passed on to the DPS. The HSP is also responsible for space segment resource allocation based on requests from the VSATs and on information about the signal strength per VSAT (received from the MCRs). The allocation informatio n is provided to the IPM for inclusion in the MPEG stream. The HSP also provides the DPS with the modulation and coding tables. The HSP is based on the Unified Hub Processor (UHP) and may be provided in a redundant configuratio n with the DPS and a spare UHP.

3.2.5 Data Protocol Server (DPS) The DPS acts as a border router between the satellite and terrestrial networks for both inbound and outbound traffic by providing acceleration and spoofing for TCP traffic as well as separating traffic according to protocol/type: VoIP, Data, Multicast, and Abis. In addition it tracks the bitrate allocation per VSAT based on the Modcod information provided by the HSP. The DPS is based on the Unified Hub Processor (UHP) and may be provided in a redundant configuration with the HSP and a spare UHP.

3.2.6 Network Management Server (NMS) The NMS is fully described in a separation section. The NMS is based on a Server System and may be provided in a redundant configuration.

3.2.7 Unified Hub Processor (UHP) The UHP is a single board, diskless, general purpose server. The same hardware may be used for the HSP and DPS each running different software. An additional UHP may be provided to provide redundancy for any or all of the UHPs in the hub.

3.3 Optional Hub components The optional Internet Page Accelerator (IPA) and Allot QoS solution are described below. Additional components may be added to support specific features.

14


[]


3.4 Hub Configurations 3.4.1 Scalability The SkyEdge II Hub has been designed to be modular, allowing the expansion from a small, network to a large scale network with minimum addition of HW components. For example, a single outbound carrier supports up to 135Mbps. MCRs, as well as DPS and HSP servers can be added seamlessly to the system to increase system capacity as required.

3.4.2 Redundancy The SkyEdge II Hub supports the following redundancy schemes per component as described in the component descriptions above and in the following table: Component

Redundancy scheme Single Outbound 1+1

Redundancy scheme Multiple Outbound IPM 1+1 per OB channel HSP 1+1* 1+1* per OB channel MCR N+1 N+1 per OB channel DPS 1+1* 1+1* per OB channel NMS 1+1 1+1 per OB channel * Shared UHP per OB provides redundancy for these components. For increased reliability, redundancy can be added for the critical baseband elements, so that no single point of failure exists. For maximum reliability, geographic redundancy can be created through identical hubs in different locations, providing minimal downtime during natural disasters, power outages or other emergencies.

3.4.3 Multiple Satellites/Outbounds The SkyEdge II Multi-Satellite Hub supports communications through up to four different satellites or transponders, for high capacity needs, or for wider geographical coverage or to cater for transponder capacity limitations. An operator can start with a hub that supports only one outbound and later add support for additional satellites by adding the required elements in the hub. The redundancy table above indicates the additional components required for a redundant multi-channel system.

3.4.4 Geographical Redundancy Geographical Redundancy is provided by a dedicated feature. It enables transfer of hub and VSAT configuration between two NMSs situated in different geographical locations. Using this feature the

15


[]


operator can switch over between sites when needed, for example, during a natural disaster such as an earth quake at the main site. In addition, this feature may be useful for importing and exporting NMS configuration for debugging and or fast installation. The application records the configuration, settings and logs of the operational hub at preset intervals and stores this data in a compressed file at the redundant hub or at a safe remote location that can be accessed by the redundant hub. If operational hub failure occurs, this stored data enables the redundant hub to adopt the settings and logs of the operational hub and to take over in the fastest possible manner, minimizing downtime and data loss. Geographical redundancy can be used in two different ways: In Export Mode at an operational hub – this enables sending the data from the operational hub to the redundant hub In Import Mode at a redundant hub – this enables the redundant hub to request the data from the active hub The synchronization process can be carried out using any IP link b etween the two sites. The activation of the standby hub is currently a manual process initiated by the hub manager. This is due to the complexity of the changeover including the necessity to shut down the RF equipment at the active site and activate it at the redundant site. Future version will support automatic switchover using a monitoring VSAT. A further enhancement of this feature will involve the use of a smaller backup hub. The switchover will include an automatically generated configuration with a reduced amount of traffic suitable for the smaller backup hub.

16


[]


4.SkyEdge II VSATs The versatile SkyEdge II VSAT family is tailored for various networking and application needs. All SkyEdge II VSATs can work with the same hub, making deployment of the network both cost effective and simple.

4.1 SkyEdge II IP The SkyEdge II IP is a compact design, two-way VSAT enabling interactive Broadband IP and multicasting applic ations. With DVB standards and extensive IP capabilities, the platform is ideal for businesses of any size requiring extremely fast downstream and upstream throughput for multimedia applications, large file delivery and extremely rapid access to the Web. SkyEdge II IP delivers advanced IP services supporting a wide range of applications including Internet, VoIP, digital signage, video conferencing, data access and VPNs. It is the perfect answer for IP services and customers of all types, including large enterprises, small & medium businesses, SOHO and residential users. SkyEdge II IP provides speed, quality, and superior support for all web and bandwidth intensive applications while enabling prioritization and fairness.

4.2 SkyEdge II Extend The SkyEdge II Extend is a compact design, two-way, two-port VSAT enabling interactive Broadband IP and multicasting applications. With DVB standards and extensive IP capabilities, the platform is ideal for businesses of any size requiring extremely fast downstream and upstream throughput for multimedia applications, large file delivery and extremely rapid access to the Web.

4.3 SkyEdge II Access The SkyEdge II Access is a truly multi-service VSAT that includes IP router functionalities and embedded IP and HTTP acceleration software, VPN, VoIP and plug-in card architecture. QoS support for all traffic, enabling prioritization and fairness based on DiffServ for data and bandwidth reservation for voice, guarantees appropriate service levels for all applications. The SkyEdge II Access presents a versatile VSAT that can empower virtually any market. Optional pre-integrated extension cards with 2xRJ-11 FXS ports support voice communication while the mesh card provides built low

17


[]


latency VSAT to VSAT capabilities. In addition the SkyEdge II Access may be ordered in rack-mount or desktop variants including external or internal AC or DC power supplies.

4.4 SkyEdge II Pro SkyEdge II Pro is a high-end rack mountable VSAT, with mesh VoIP aimed at high performance networks for governmental projects, the Oil & Gas industry, telecom operators and enterprises requiring mesh. By integrating full mesh functionality, the SkyEdge II Pro achieves s eamless, single hop voice and data call capability. Users receive optimal performance with minimal delay, increased quality and subsequently, improved and efficient space segment utilization. The field-upgradeable extension cards include the mesh card as well as 2xRJ-11 FXS ports to support voice communication.

4.5 Expansio n Cards The SkyEdge II Pro and SkyEdge II Access include expansion slots bus for optional additional features. The slot configuration of these VSATs is shown in the following figure. The SkyEdge II Pro is field upgradeable with expansion cards as shown. The SkyEdge II Access requires factory fitting of expansion cards. SkyEdge II Access (3xFXS or 1xFXS + Mesh) 2

Mesh card

3

1

SkyEdge II Pro Field-upgradeable (4xFXS or 2xFXS + Mesh)

4 x LAN ports + serial port

3 FXS cards 3 4

2 FXS cards

2

1

2 FXS cards or 1 doublewidth Mesh card

4 x LAN ports + serial port

Figure 6: SkyEdge II Access and Pro – Expansion Slots

4.5.1

2 FXS extension card

Each FXS extension card supports two FXS analog telephone lines. This can be used for phones or standard fax machines for star or mesh services. The card is using standard SIP and RTP to carry voice traffic so it can be used with standard VoIP gateways and soft switches for regular VoIP calls.

4.5.2

Mesh Receiver Card

The mesh card supports single-hop, full-mesh connection with other mesh VSATs. The mesh connectivity card is fully described in 9.6 below. Typically, a mesh VSAT will need a larger antenna than a regular VSAT, due to the link budget considerations (requiring that VSAT to receive I/B transmissions from other VSATs).

18


[]


4.6 Local configuration and management SkyEdge II VSATs require local configuration of a minimal set of parameters (such as the outbound channel parameters) which enable the VSAT to log-on to the network and start transmitting. After the VSAT logs-on, enhanced over the air (OTA) programming is used by the NMS to further configure the VSATS. VSATs are programmed via the satellite link to support software updates and configuration changes. SkyEdge II VSATs are equipped with non-volatile Flash memory to store this information. The use of non-volatile memory enables the VSATs to recover automatically from power outages, without the need for OTA reprogramming. This significantly improves the network availability and space segment utilization in applications where frequent power loss is anticipated. The SkyEdge II Pro is equipped with an LCD screen and a six button keypad navigator. This allows for “instrument -free” configuration and can be used as an aid in VSAT maintenance. Another mechanism to support local configuration is a VSAT embedded web GUI - SkyManage . The GUI also presents the VSAT state (e.g., searching for Outbound ID, searching for Outbound Frequency). While the VSAT is in operational mode it can provide information through the different menu items including software versions, IP and MAC addresses, available expansion cards etc. Additional information is the VSAT status e.g. CPU utilization, E b/N 0, number of inbound and outbound transmitted and received packets, etc.

In addition the SkyEdge VSATs provide an SNMP interface for collecting telemetry locally by SNMP servers.

19


[]


4.7 Outdoor Equipment 4.7.1 VSAT Antennas The VSAT antenna comprises a reflector; an offset feed horn, and mounting hardware. The standard reflector is a parabolic dish made of a glass fiber composite, or of aluminum. The antenna size for a particular location depends on the inbound channel bit-rate, weather conditions, model, and the satellite footprint for that region. The range of antenna sizes is generally: Ku-band: 0.55 to 1.20m C-band or Ex-C-band: 1.8 to 3.7m . Ka Band: 0.55 to 1.2m

4.7.2 Outdoor Unit (ODU) The ODU is mounted at the focal point of the antenna. It transmits and receives modulated RF signals to/from the hub via the satellite. The ODU contains a High-Power up-Converter (HPC also known as BUC = Block Up Convertor), a Low-Noise Block down-converter (LNB) and an Orthomode Transducer (OMT). The HPC and LNB are connected to separate ports on the OMT. This configuration allows reception of a signal on one polarization and transmission on the other (orthogonal) polarization. The ODU is sealed to withstand harsh environmental conditions. It is capable of functioning reliably in ambient temperatures ranging from -40° to +60°C (-40° to +140°F), at up to 100% relative humidity. Figure 7 shows the components of the ODU.

HPC

Figure 7: Outdoor U nit Components

20


[]


5.NetEdge NetEdge brings a true technological advance into the world of private networking over satellite. Up until recently, for a corporate to have its own private network meant high capital investment and many times a serious compromise on application performance and user experience. With SCPC as the typical means of connectivity, providing reasonable inter-branch data connectivity meant limited or no internet access and significantly higher space segment costs. High quality voice or video conferencing between branches were simply not a practical option. Similarly, with cellular backhauling over satellite, in many cases the space-segment costs and HW costs make the business case challenging for the network operator. With SkyEdge II NetEdge, a service provider can now provide its business and government customers with full connectivity, high performance packages at reasonable costs.

5.1 Using NetEdge for Multi-Star Private Networks NetEdge allows building a single, highly efficient and modular satellite access network with multiple private mesh networks within it. Each private network is typically used by a business or a government entity, and is built around a central node. The central node may be the regional HQ for a corporate network, or a regional cellular BTS Controller (BSC) for a cellular network with multiple BTS sites. Each private network is in the form of a small star-topology network, or “micro-star” (µStar) network. The general topology is depicted in Figure 8 below.

Figure 8 General topology of a multi-star corporate network

The building blocks of a NetEdge multi-star network are mesh VSATs and mesh Gateways (GW): Remote sites are equipped with the high performance mesh VSATs, either the SkyEdge II Access or the SkyEdge II Pro, both expandable with a mesh expansion card. The central node of each private network is based on a high capacity NetEdge GW.

With mesh capability, any site can connect directly in single hop to any other site in the network. This capability is relevant for any type of connectivity: Connecting any 2 mesh sites inside the private network

21


[]


Connecting any point in the network to the internet or to other points outside the satellite network and beyond the hub.

Figure 9 - Multi-star high-level topology with Mesh VSATs (MV) and NetEdge GWs

22


[]


5.2 NetEdge Technology NetEdge technology is based on the Star Inbound spec, using full ICM adaptivity, simultaneous QSPK/8PSK, 1.2 channel spacing and a large dynamic range from 128ksps to 2.56Msps in 1dB steps. The spec is detailed in Table 2 below, and includes several enhancements for the high capacity NetEdge GW sites. Standard SE-II DVB-RCS

GW mesh transmission

Symbol rate [ksps] ModCods Channel Spacing Standard

VSAT Star/Mesh transmission

Symbol rate [ksps]

128, 160, 192, 256, 320, 384, 512, 640, 768, 1024, 1280, 1536, 2048 1 ,2560 QPSK: 1/2, 2/3, 3/4, 4/5, 6/7 8PSK: 2/3, 3/4, 4/5, 6/7 1.2 or 1.35 SE-II DVB-RCS based

ModCods

128, 160, 192, 256, 320, 384, 512, 640, 768, 1024, 1280, 1536, 2048 and 2560 ksps. QPSK: 1/2, 2/3, 3/4, 4/5, 6/7

Channel Spacing

8PSK: 2/3, 3/4, 4/5, 6/7 1.2 or 1.35

Table 2 – SkyEdge II NetEdge Star/Mesh Inbound Spec

1

Will support up to 4 Msps in a planned future software release

23


[]


6.Network Management System (NMS) The SkyEdge II Network Management System (NMS) gives operators multi-tasking, central monitoring and control of the entire communications network. The operator can view, modify and download individual configuration items for the hub and remote terminals.

Figure 10: NMS Main Screen

The hub- based NMS server is accessed via a user interface that runs on the network’s remote clients. The SkyEdge II NMS encompasses every component of the system. By integrating voice, data and multimedia into a common satellite communications system, the NMS management functionality supports both the scope and capabilities of world class satellite networks. The key management features of the NMS are listed below. SkyEdge II contains an advance fault management system that makes it easy to monitor the network and its messages via the NMS. Alarms and events graphically display any change in status of a network element in color-coded icons and text. Browser event display filtering makes events easier to view and manage, and may be used in cases where the event rate is high or the administrator wants to filter out irrelevant or unimportant events. Service Offering Flexibility through Hub Sharing (Partitioning) enables a hub operator to grant client network administrators access to only their portions of the shared network. Group management and operation is supported through separate Software and Work Group definitions for VSATs.

24


[]


A clear and intuitive Graphical User Interface (GUI) uses both object-oriented and hierarchical techniques to help network managers quickly set up and manage the SkyEdge II environment. The NMS provides telemetry configuration parameters and status for network elements, enabling rapid identification of network component status changes and configuration errors. Traffic, satellite and port statistical information can be polled by the NMS and presented to the operator. The NMS uses standards compliant XML and SNMP to create generic definitions of components, parameters, commands and statistics. It also assists in speedily deploying new system components. End-to-end QoS parameters are managed by the NMS on per user and per application bases. Multiple SLAs can coexist within the same system. Central software upgrading provides for modifying the unit(s) specified by group settings. It also supports a short system down time with complete restore capabilities to back down to the previous version.

6.1 SkyMon

.

SkyMon is a web-based monitoring tool for the SkyEdge II s ystem. It performs real-time system monitoring of events, alarms and statistics as well as historic/trend analysis of the system over a one year period. SkyMon collects statistics from Hub Elements and VSATs and also synchronizes periodically with the NMS in order to receive the network topology and events available on the NMS. SkyMon contains pre-defined collections of SNMP-based statistics received from Hub elements and VSATs. These statistic collections have been defined based on Gilat’s vast experience in satellite network monitoring. The statistics include all information required for monitoring and debugging a satellite communication network. The information is collected from the devices with a 5-minute resolution (VSAT statistics are collected with a 3-hour resolution for satellite BW e fficiency ). Users can generate real time and historical reports based the collected information using a user-friendly Web-based GUI. The GUI is accessible from Microsoft IE7 or Mozilla Firefox version 2.0 or above.

6.1.1 Dashboard One of the main SkyMon advantages is its innovative Dashboard: The Dashboard is a user defined screen with as many tabs as users require. In each tab users can add any information that is available to the system: Real-time graphs Historic reports

25


[]


Events table Alarms table Network elements table Summary display of events Each information type is available as a web part that can be placed anywhere in the GUI. Each user can create a unique information display which is saved for per user.

Figure 11: SkyMon Dashboard

6.1.2 Monitor The Monitor page displays the following information: Network element status Fault management status including network elements events & alarms. Available Statistics collections

26


[]


Figure 12: Fault Management View

6.1.3 Reports Reports are built using the Report Builder wizard, a simple guide that enables the user to create report on any statistic or telemetry collected, for a period of up to a year. The reports can be displayed graphically or a s text. SkyMon’s pre -defined reports are divided into 4 categories with several reports under each category: Events: AAA Receive, Event Occurrence, Event Occurrence per Resource Type, Link Connect, Link Disconnect VSAT Auto-Pointing: Installation Report VSAT Counters: OB Es/N0, IB Es/N0, CSC Retries, IB & OB Bytes, IB & OB Bit-Rate, Max TCP Connecti on, VSAT Availability Collection: Outbound Available bit rate, Bit Rate per PID, Bit Rate Utilization, SPS Utilization, Backbone Packets , Distribution Size, Burst Distribution Size, Connections, DPS/HSP CPU Utilization, HSP Memory Usage, IB Active Slot Distribution, IB bps, IB bps IP distribution, IB C/N Distribution, IB Load per slot type, IB Load per Transmission type, IB Load per MPN, ModCod bps, Number of VSATs per ModCod, OB bps, OB IP Distribution Kbps, VSAT IB Es/N0 per MODCOD, VSATs Online (Access & Data), VSAT OB Es/N0 Distribut ion

27


[]


Figure 13: Sample report - Outbound Symbol Rate per ModCod

6.2 VSAT Auto Pointing System (VAPS) In most VSAT networks, commissioning a new remote site is a time-consuming operation requiring space segment usage and highly trained personnel with special equipment. A misaligned antenna can result in a loss of communication, making the operator liable to fines from both the space segment supplier and customers, in addition to the loss of income. Gilat’s SkyEdge II VSAT Automated Pointing System (VAPS) addresses antenna pointing issues to significa ntly improve the s tability and efficiency of the network while reducing costs and speeding up the deployment process. VAPS is a product that enables a service provider and a VSAT Network operator to perform rapid VSAT installation and commissioning. VAPS also enables large-scale VSAT Installation deployment with limited hub personnel.

VAPS supports self-pointing installations which allows more deployments with significantly reduced human error, using less skilled installers with no additional instrumentation.

6.2.1 Benefits of VAPS The use of this system improves the efficiency of the VSAT terminal commissioning process, resulting in cost savings in establishing VSAT networks. Further benefits include: Provides a tool for maximizing the signal strength and minimizing the cross-polarity interference Reduces antenna alignment time allowing more installations per day Cost savings in contractor delay time Cost savings in cell phone charges

28


[]


Automatic confirmation of proper VSAT installations 24x7 system availability for installers

6.2.2 Solution Architecture and operation The VSAT Automated Pointing System consists of both hardware and software to automate the VSAT antenna alignment process. The Auto Pointing process consists of the following phases: Initial Antenna Alignment – Initial pointing of the antenna based on Outbound Es/N0 readings as measured by the VSAT Fine Antenna Alignment – the installer adjusts the antenna polarization based on Co pole/Cross pole readings from the hub. The VSAT transmits CW throughout the process. Normal logging into the system – VSAT moves to operational mode. The installer/user can choose to have only Initial Alignment (outbound based alignment) or to proceed to Fine Alignment (polarization alignment based on CW transmission). The VAPS client is accessed via SkyManage. The installer interacts with the VSAT client throughout the process of antenna alignment in order to get the necessary information (Outbound Es/N0 readings & Co/Cross Pole readings from the Hub) and to report back to the hub about the alignment status. The SkyManage VAPS interface is shown below.

Figure 14: SkyManage VAPS interface

6.2.3 System architecture components The VAPS operation is based on a client embedded on the VSAT that interacts with a dedicated server in the HUB. The dedicated server in the hub (SACIN) works with integrated spectrum analyzers that are used in the fine alignment phases. Each spectrum analyzer (up to 8) supports up to 8 concurrent installations. The VSAT application resides within the VS AT’s internal web server and is accessible from standard browsers – using a PC or a handheld portable device.

29


[]


7.DVB-S2 ACM Outbound The SkyEdge II DVB-S2 outbound channel carries unicast and multicast data, voice traffic, synchronization information for the return (inbound) channel and network control traffic. All the VSATs in the network are tuned to receive the outbound channel. The VSATs recognize and extract the traffic which is intended for them based on a dedicated field which is added to each packet.

7.1 DVB-S2 Background The SkyEdge II outbound is based on the DVB-S2 EN 302 307 s tandard. DVB -S2 is the second generation DVB system for broadband satellite services. Its main applications are broadcast TV, interactive applications, and professional systems such as DSNG (digital satellite news gathering), Internet trunking and cable head end feeds. DVB -S2 offer better spectral efficiency than DVBS and the standard includes methods for encapsulation of new protocols such as MPEG4/H.264. The spectral efficiency is improved by higher modulation schemes, stronger FECs, tighter roll-off factors and the use of ACM.

7.2 DVB-S2 Spectral efficiency DVB-S2 has more modulation options than DVB-S and can support 2, 3, 4 or 5 bits per symbol (QPSK, 8PSK, 16APSK, and 32APSK). Figure 15 illustrates the improved modulations possible with DVB-DVBS2. Q 10

Q 00

000

I QPSK

11

I 8PSK

01

2 bits per symbol

3 bits per symbol 111

Q 16APSK

32APSK

Q

5 bits per symbol

4 bits per symbol 0000

00000

I

I

1111 11111

Figure 15: DVB-S2 Modulation schemes

DVB-S2 ensures better Forward Error Correction by linking Bose-Chaudhuri-Hoquenghem (BCH) with Low Density Parity Check Codes (LDPC). BCH ensures against error floors at very low Block Error Rates. LDPC is a variant of the Turbo-Code family that deals with all other possible error rates.

30


[]


Together, they provide performance very close to the Shannon limit. spectral efficiency of DVB-S2, for various require d C/N values.

Figure 16 summarizes the

Figure 16: Spectral efficiency of DVB-S2

Additionall y, DVB-S2 enables tighter carrier spacing. With roll off factors of 0.35 and 0.20, DVB-S2 improves space segment efficiency by as much as 12.5%.

(as in DVB -S), 0.25

7.3 CCM and ACM 7.3.1 Constant Coding and Modulation (CCM) With CCM the FEC coding and modulation are set for the carrier and remain unchanged. The Coding and modulation chosen as part of the network design take into account availability requirements, rain fade margins and all other link budget factors. In the example below all frame s are transmitted with the same ModCod to meet a specific availability for the worst case VSAT.

Design to ensure availability of worst case VSAT

All frames have same ModCod

Figure 17: CCM example

7.3.2 Adapt ive C oding and M odula tion (ACM) ACM enables adaptation of the coding and modulation on a frame-by frame basis based on the current propagation conditions. As shown in the example below the VSATs provide feedback to the hub about the received signal strength. This feedback should ideally be piggybacked on a standard

31


[]


return channel such as DVB-RCS. In a rain fade condition the ModCod used in the frames sent to a particular VSAT or VSAT group will dynamically be made more robust to prevent outage. In clear-sky conditions the ModCod can allow greater throughput. Feedback to Hub about received signal strength

Frame ModCod changed for specific VSAT or group

Switch to lower ModCod in rain fade conditions

Figure 18: ACM Example

7.4 SkyEdge II DVB-S2 Specificatio ns The following are the main highlights of the DVB-S2 based outbound channel in SkyEdge II: Support of QPSK, 8PSK as well as the high order 16APSK and 32APSK modulations Supports the DVB-S2 standard LDPC and BCH coding with the following rates: o

QPSK 

o

3/5, 2/3, 3/4, 5/6, 8/9, 9/10

16APSK 

o

9/10

8PSK 

o

1/4, 1/3, 2/5, 1/2, 3/5, 2/3, 3/4, 4/5, 5/6, 8/9,

2/3, 3/4, 4/5, 5/6, 8/9, 9/10

32APSK 

3/4, 4/5, 5/6, 8/9, 9/10

High scalability, with outbound rates from 350ksps to 45Msps, with a low minimum bandwidth requirement for a single outbound channel. The low minimum rate is particularly suitable for networks that start on a small scale. Capable of using a 36 MHz or 54MHz transponder in saturated mode, enabling a very high bit/sec per Hz ratio. Employing 16APSK, up to 135Mbps can be transmitted over a single outbound carrier. With 8PSK, an aggregate rate of about 110 Mb/sec can be transmitted in such a transponder.

32


[]


Channel spacing as low as 1.2, meaning that for every symbol transmitted over the air, only 1.2 Hz are required. Support of CCM and ACM

7.5 SkyEdge II ACM implemen tation When working in ACM mode, the outbound stream consists of DVB-S2 frames of different ModCods. Each frame may contain data destined for either a single VSAT, or for multiple VSATs sharing the same ModCod. The high level adaptivity mechanism is the following: Outbound reception quality reports (C/N values) are received from the VSATs in the network. These are sent within the SYNC bursts that are part of the DVB -RCS based inbound. This piggybacking of information onto the SYNC bursts saves inbound bandwidth. The HSP continuously processes this information and then advertises the best ModCod required for the transmission to each VSAT. The inbound scheduling tables are provided from the HSP to the IPM, to be transmitted with a pre-defined multicast ModCod. This ModCod is typically selected to be the most robust in the system For each outbound packet, the DPS uses the ModCod information to indicate the recommended ModCod to the IPM. Network management data is provided from the NMS to the IPM. By default, the data from the NMS will be transmitted with the most robust ModCod used in the network. ACM implies a variable actual bitrate depending on the spectral efficiency of the ModCod used. The DPS provides the external QoS server with the actual throughput bitrate so that the QoS server can make correct decisions about packet s cheduling. The specially developed protocol is used between the DPS and the Allot QoS server.

Figure 19: SkyEdge II ACM implementation

7.6 SkyEdge II DVB-S2 Enhancements The SkyEdge II DVB-S2 ACM implementation features several efficiency enhancements:

33


[]


Support for short and normal MPEG transport frames Efficient packing and Concatenation Advanced scheduling Integration with QoS server – as described in Section 7.5 above and as shown in Figure 19. Minimize inbound traffic using piggybacked feedback mechanisms

– see Section 7.5 above.

A wide range of telemetries for analyzing actual network behavior – SkyEdge II provides all the information needed by operators to know “what is going on” with the adaptive outbound channels.

7.6.1 MPEG Transport Short and Normal Frames MPEG transport frames can be either 2000 bytes (Short) or 8000 bytes (normal) long. The use of normal size frames implies less overhead relative to the data transmitted however the larger size may give rise to: Serialization delay: Each component that processes the frame must complete processing before passing the frame onwards eg: the receiver in the VSAT. This processing time is directly related to the size of the frame. Larger frames therefore introduce a proportional delay. Inefficient packing: There may not always be sufficient data to fill the larger frames resulting in under-use. This under usage (lowered fill factor) affects the spectral efficiency (bits/Hz) of the outbound carrier. For example 4 MHz of s atellite bandwidth carrying frames that are on 2 average 50% full implies a 50% spectral efficiency and 2MHz of wasted bandwidth . With ACM frames the current frame ModCod might not be appropriate for the receiving VSAT i.e.: the ModCod is not robust enough. This packet will be forced to “wait” until a suitable frame is generated. Jitter: The serialization delay and the frame wait described above result in jitter SkyEdge II therefore uses short frames which minimize these effects.

7.6.2 Efficient packing of MPEG frames Dedicating a frame to each destination VSAT results in inefficient usage when small packets do not fill the frame – this is true even when short frames are used. SkyEdge II therefore allows for transmission of multiple unicast packets within an MPEG frame as shown in Figure 20 line 2. It is unlikely that this group of packets will exactly fill the frame and this may result in an unutilized “tail”. The SkyEdge II implementation therefore allows for concatenation where the packet is split 2

This does not take into account spectral efficiency of the ModCod used.

34


[]


across 2 adjacent frames (Figure 20 line 3). This may even take place when the next frame is using a more robust ModCod. The combination of these mechanisms results in almost 100% utilization of the frame capacity.

1

Frame Unicast #134 765

Inefficient use of frame for single VSAT traffic

2

Frame Unicast Unicast Unicast Unicast #134 #265 #490 #134 765

Multiple unicast packets more efficiently fill frame

3

Frame Unicast Unicast Unicast Unicast Unica Frame #134 #265 #134 #490 #134 765 766

Unicast Unicast #851 #134

Concatenated packet across frames– almost 100% fill

Figure 20: SkyEdge II efficient packing of MPEG frames

7.6.3 Adva nced sched uling The adaptive nature of the frames in DVB-S2 may result in scheduling conflicts. Consider the case presented in Figure 21. The VoIP packet is destined for a VSAT that can receive an 8PSK, 7/8 modcod. The VoIP packet could therefore be sent in the next frame but should ideally be sent immediately to reduce jitter. The Internet packet is destined for a VSAT that requires a more robust (QPSK, 3/4) ModCod. In such a case the SkyEdge II scheduling mechanism favors real time applications such as VoIP. The VoIP packet would be sent immediately and the internet packet would suffer a minor delay waiting for a frame with a suitable ModCod.

VoIP Receiving VSAT can Unicast tolerate 8PSK 7/8 #768

Internet Receiving VSAT Unicast limited to QPSK 3/4 #134

? V o IP Frame 765

V o IP

Unicast Unicast Unicast #134 #490 #134

QPSK, 3/4

Frame 766

8PSK, 7/8

Figure 21: SkyEdge II Real time scheduling

Consider the case presented in Figure 22. The HTTP packet is destined for a VSAT that can receive an 8PSK, 2/3 ModCod. This ModCod provides better spectral efficiency than QPSK 3/4 but the 8PSK frame would carry only this packet and would therefore have an inefficient fill-fac tor. As described in Section 7.6.1 above the fill factor can seriously impact the spectral efficiency of the outbound carrier. In this case the SkyEdge II scheduling mechanism will therefore transmit the packet at the lower ModCod and cancel the unneeded frame thus increasing the efficiency of the outbound ACM implementation.

35


[]


Send this packet in the lower ModCod frame to increase the fill factor OR in an unfilled frame with a more efficient ModCod?

HTTP Unicast #433

This packet is destined for a VSAT that can receive 8PSK 2/3

? VoIP Frame 967

Unicast Unicast Unicast #627 #490 #390

QPSK, 3/4

Frame 968

8PSK, 2/3

Figure 22: SkyEdge II greater efficiency scheduling

36


[]


8.DVB-RCS based Inbound The SkyEdge II system modulation and coding scheme is designed to optimize the use of satellite transponders by minimizing the required bandwidth and power resources. DVB-RCS was chosen since it is a multi-vendor standard with a theoretically superior access scheme. SkyEdge II includes ICM with 4 dimensions of inbound adaptivity providing higher throughput in clear sky conditions and better availability in rain fade situations.

8.1 DVB-RCS background The DVB-RCS standard (EN 301 790) was created by the DVB-RCS AHG of the DVB forum. The DVBRCS standard concentrates on and details the PHY and MAC levels of the satellite segment – the air interface: initial logon, access scheme, capacity request and a llocation, bursts formats, timing, synchronization, etc. It provides a full suite of solutions for the physical layer of the satellite communications. The SatLabs Group was founded by several organizations and vendors in the VSAT industry “committed to bringing the deployment of the DVB -RCS standard to large-scale adoption ” . Each SatLab's version defines mandatory and optional features. Although the entire system has to support DVB-RCS the certification given is for the VSAT only after testing in the Cetecom labs, Germany. SatLabs test plan 1.0 defined basic conformance testing to verify that VSATs conformed to the DVB-RCS specifications. Test plan 1.3 adds DVB S2 as the forward channel as well as QOS and other features supported by SkyEdge II. Gilat’s SkyEdge was certified compliant in October 2005. SkyEdge II is the first system to be certified according to test plan version 1.3. The details of the SkyEdge II certification are shown in the table below. ETSI EN 301790 Standard version

V1.4.1

ETSI TR 101 790 (Guidelines document) Optional Features:



V1.3.1 Forward Channel DVB-S 2 Route ID Fast hopping  Dynamic MF-TDMA   Enhanced classifier NCR payload  120MHz hopping   16APSK SSR V1 1.3 OTP V6 

SatLab Version (profile) SatLab System Recommendation (SSR test plan version) SatLabs Terminal certification Test Plan

Table 3: SkyEdge II SatLabs 1.3 certification

The DVB-RCS standard does not define many issues that are required in a commercial network, above the physical layer, without which practical service cannot be provided. Examples include protocol enhancements such as TCP acceleration, HTTP acceleration, VoIP header optimization, endto-end QoS, central management etc. SatLabs 2.0 defines many of these to b e included in future conformance testing.

37


[]


8.2 SkyEdge II DVB-RCS Access Scheme The SkyEdge II inbound was designed with the aim of future interoperability with any DVB-RCS compliant modems. SkyEdge II is based on the standard: the DVB -RCS frame format, the air protocol, burst types and reservation types, the mandatory ATM transport stream etc. On top of these building blocks, the SkyEdge II inbound includes several important enhancements primarily the ICM mechanisms, which take advantage of recent developments in adaptive technologies. In addition, specific algorithms are implemented addressing some of the shortcoming of the DVB-RCS standard, for example by a VoIP optimization algorit hm. Details on the enhancements are provided below.

8.2.1 DVB-RCS Burst Plan DVB-RCS uses an MF-TDMA reservation based access scheme. VSATs are assigned timeslots (within the time-frequency plan described above) in which they can transmit bursts. An example of such a burst plan is shown in Figure 23.

Freq TRF

CSC

TRF

SYN

CSC

TRF

SYN

TRF

CSC

TRF

SYN

CSC

TRF

SYN

TRF

CSC

SYN

TRF

CSC

SYN

Time Figure 23: Time Frequency Plan with different bursts

The timeslot size is determined by the bu rst type. The burst in a timeslot can be either: TRF – Traffic – Actual data with associated header CSC – Common Signaling Channel – used by the VSAT for its initial logon to the network SYNC – used for synchronization acquisition and maintenance, as well as capacity requests. The VSATs also use the SYNC burst to send information about the received signal strength to the hub. The burst allocation plan is broadcast every 40ms within the DVB -S2 outbound carrier. The position of the allocated timeslots is described relative to the Frame and Superframe. Frames – Each Channel is a Frame Superframe – A group of Timeslots and Frames that repeats itself every 360ms. The start of the superframe is synchronized for all the VSATs in the network.

38


[]


Freq TRF CSC

TRF

SYN

CSC

TRFFrTRF ameTRF

Superframe SYN

CSC

SYN

CSC

TRF SYN

TRF

CSC

SYN

TRF

Frame Superframe

CSC

SYN

Time

Figure 24: Frames and Superframes

Each VSAT effectively translates the timeslot into an offset from the superframe start which is synchronized throughout the network.

8.2.2 TRF bursts DVB-RCS allows for two TRF formats: ATM (mandatory) and MPEG (optional) . The Gilat implementation uses ATM only where the number of ATM cells per TRF can be 1 or 2 or 4. The default number of cells is 2 but TRF bursts on carriers of 1536 ks/s or higher automatically use 4 ATM cells. The ATM format is used only for transport – ATM protocol services are not used. The TRF burst does not include any CRC. The structure of a TRF burst is show in Figure 25. Guard

SAC (Satellite Access Control) = 4 Bytes Preamble– Used Used for piggy-backed capacity requests for burst detection ATM cell = 53 bytes and acquisition incl. 5 byte header

Guard

FEC applied and FEC bits added after scrambling

Figure 25: TRF Burst

The insertion of IP datagrams into the ATM cells is shown in Figure 26. In this example 2 separate packets, one from a VoIP session and one from an HTTP session, are broken into 48 byte fragments following the addition of Gilat’s backbone protocol information. The backbone protocol is used for TCP acceleration described in Section 9.1. ATM Adaptation Layer 5 (AAL5) is used to transfer IP data over an ATM virtual circuit and includes mechanisms for segmentation and reassembly. includes:

AAL5 adds an 8 byte trailer to the last cell which

Length (16 bits) – of the entire datagram CRC (32 bits) UU and CPI (8 bits each) – are currently not used by the standard

39


[]


The remainder of the cell is made up of the last data bits and padding bits. Data from different sources is not mixed within the ATM cell but, as shown, a timeslot can include ATM cells from different sources. The priority and order of the cells is decided by VSAT based on the QoS parameters. In all cases the ATM header indicates the relationship of a packet to a session using an 8 bit Virtual Path Identifier (VPI). The other components of the 5 byte ATM cell header are: GFC = Generic Flow Control (4 bits) – 4-zero bits VCI = Virtual channel identifier (16 bits) – includes the VSAT ID allocated by the hub at logon PT = Payload Type (3 bits) – network or user traffic – e.g. NM traffic CLP = Cell Loss Priority (1-bit) HEC = Header Error Correction

VoIP

Web

IP

500 Bytes

600 Bytes

Backbone

518 Bytes

618 Bytes

AAL5

48

48

48

Da t a

ATM

5

48

P a d d i ng

48

48

48

48

48

T r ai l er

5

48

TRF Timeslot

Figure 26: ATM cell makeup

8.2.3 SYNC Burst The SYNC burst is used for synchronization acquisition and maintenance, capacity requests, and to transfer information about the received C/N as part of the AUPC (See section 8.3.2.3) . Each VSAT is assigned a SYNC timeslot which is received every 1s. The SYNC bursts are composed of: Preamble for burst detection Satellite Access Control (SAC) – different to the TRF SAC After randomization an optional CRC is added

40


[]

8.2.3.1


SYNC – Capacity request types

The three categories of request types supported are supported are:

RBGC (Rate Based Guaranteed Capacity) – applicable mainly for admission control types of applicatio ns such as VoIP, where a fixed rate of traffic must first be guaranteed. The hub first notifies the VSAT that capacity will be available (an accept or reject response) so that the VSAT can “report” back to the requesting application. VoIP calls will, for e xample, be rejected if n o capacity exists for the call to be initiated. Once the capacity is approved the guaranteed rate will be provided until the requesting VSAT indicates that it is no longer required.

RBDC (Rate Based Dynamic Capacity) – a bandwidth on demand type of scheme, where the VSAT dynamically increases or reduces its bandwidth requirement request based on the rate of traffic flowing through it. Almost all traffic will be rate b ased with the exception of some VSAT management traffic. The rate reservation has a granularity of 2kbps. VBDC (Volume Based Dynamic Capacity) - capacity requests are generated by the VSAT based on the volum e of traffic it needs to transmit. This category resembles Gilat’s proprietary GA access scheme. In the SkyEdge II implementation this is used mainly for management traffic. FCD – Free Capacity Distribution (based on the Free Capacity Allocation of the standard) – A hub initiated distribution of the remaining free capacity in the n etwork. This can provide a VSAT with a instant transmission mechanism but will only be available when there is free capacity. The distribution algorithm takes into account the current capcity usage and VSAT priority. Any single SkyEdge II VSAT may use a combination of capacity allocations based on the types of traffic it needs to transmit. On top of the different categories, the SkyEdge II extensive inbound QoS mechanism allows enforcing different types of policies to prioritize specific individual VSATs, group of VSATs (MPNs) or specific applications running in the system. This mechanism is further detailed below. 8.2.3.2

SYNC – Synchronizations

The synchronization of VSATs in a DVB-RCS network is based on a very accurate clock of 27 MHz (used in digital video), generated in the Hub. Count values of the clock are broadcast to the terminals and the reconstructed clock is used for deriving an accurate transmit frequency and for burst timing – this allows for minimized guard intervals. Accurate reconstruction of the clock 2 requires geographical location information accurate to 6km (as defined in SkyEdge II –EN 301 790 does not specify a radius). The logon and initial sync are shown in Figure 28.

8.2.4 Common Signaling Channel (CSC) Burst The 16 byte CSC Burst is used for the i nitial VSAT network logon (“link connect”) . The CSC burst includes a preamble for burst detection and CRC

41


[]


VSAT Capab.

VSAT ID

Rand. VSAT Capab.

Rand. VSAT ID

Figure 27: CSC Burst

8.2.4.1

Logon using the CSC Burst

In order to logon the terminal needs the start-up transport stream frequency and symbol rate as well as the Inbound-ID. After acquiring the relevant outbound, the VSAT extracts all the Table informatio n required for the inbound. Network logon is performed in contention mode over CSC slots using the VSAT ID that was configure d during installation . The VSAT MPN, VSAT priority, and VSAT capability information (to signal the options supported) are passed between the VSAT and hub. The logged on VSAT is then assigned a fixed SYNC slot. The logon process and initial sync is shown in Figure 28. Hub

CSC

VSAT

CSC

CSC

CSC reply (c orrections,

SYNC assignm ent

)

SYNC

Corrections

CR SYNC w/

Correction Allocation

Figure 28: Logon and initial sync

8.3 SkyEdge II Physical Layer implementation The physical layer (PHY) implementation of SkyEdge II includes several enhancements to the DVB-RCS standard, making the system more efficient, more flexible and the network operation more reliable. Table 4 below compares some of the basic PHY characteristics of SkyEdge II with the DVB-RCS standard definitions. In the following sections, some of SkyEdge II’s major PHY enhancements are covered. Among those are: -The state of the art 4-dimensional ICM mechanism

42


[]


-The highly efficient 8PSK modulation -The unique Dual Synthesizer Frequency Hopping (DSFH) mechanism (SkyEdge II Access and Pro) Standard EN 301 790

Gilat SkyEdge II

Outbound

DVB-S. DVB-S2 is Optional

DVB-S2

Modulation

QPSK

QPSK or 8PSK

FEC - Turbo

QPSK 1/2, 1/3, 2/3, 2/5, 3/4, 4/5, 6/7

QPSK 1/2, 2/3, 3/4, 4/5, 6/7 8PSK 2/3, 3/4, 4/5, 6/7

Symbol Rates

None defined

Scrambling

Required

128,160, 192, 256, 320, 384, 512, 640, 832, 1024, 1280, 1536, 2048, 2560 Implemented

Table 4: Inbound Physical Scheme Comparison

The SkyEdge II inbound carriers can start as low 140kbps and increase to 4Mbps (SkyEdge II IP) or 6Mbps (SkyEdge II Access and Pro).

8.3.1 SkyEdge II Physical Layer - Inbound flexibility 8.3.1.1

Modulation and FEC schemes

The following ModCods are supported by the SkyEdge II VSATs: QPSK: 1/2, 2/3, 3/4, 4/5, 6/7 8PSK: 2/3, 3/4, 4/5, 6/7 The spectral efficiency of the ModCod combinations is shown in the following figure. Dynamic range: 10.8 dB 2.1 1.9

8PSK 6/7

1.7 z 1.5 /H s ti 1.3 B

8PSK QPSK 2/3 6/7

1.1 0.9 0.7 0.5

QPSK 1/2 3.7

5.5

6.8

7.6

8.6

11.6

12.8

13.9

14.5

Es/No (dB)

Figure 29: SkyEdge II Inbound ModCods

8.3.1.2

Multiple Symbol rates

SkyEdge II supports a range of symbol rates as shown in the table below. The table also shows the dynamic range across all of the possible rates.

43


[]


Symbol Rate (ksps)

128

Delta from Adjacent Symbol Rate (dB)

160

192

256

320

384

512

640

832

1024

1280

1536

2048

2560

1

0.8

1.2

1

0.8

1.2

1

1.1

0.9

1

0.8

1.2

1

Dynamic Range: 13dB

Table 5: SkyEdge II Inbound Symbol Rates

Each Multi Channel Receiver card in the hub (see Section rates. 8.3.1.3

3.2.3 above) can receive 4 different symbol

Carrier Types (CT)

The combination of ModCod, symbol rate and number of channels is referred to as a Carrier Type (CT). In SkyEdge II the CTs are defined a s part of the initial system configuration based on the traffic assumptions and network design. The following table shows an example of a CT definition. Carrier Type 1 2 3 4

Symbol Rate 128 192 256

Number of channels 1 1 2

ModCod Q 1/2 Q 3/4 Q 3/4

512 1 Table 6: CT definition table

This table would result in a Time Frequency Plan as displayed in

8 3/4

Figure 30.

Freq

4 ModCods CT4: 1 x 512Ksps, 8PSK, 3/4

CT3: 2 x 256Ksps, QPSK, 3/4

CT2: 1 x 192ksps, QPSK, 3/4 CT1: 1 x 128ksps, QPSK, 1/2

Time Figure 30: Example

–

Time Frequency Plan

In the above example each CT includes only 1 ModCod for a total of 4.

44


[]


The time-frequency plan is transmitted as part of the outbound DVB -S2 frame every 10 seconds. The division of the Time Frequency Plan into timeslots is described in the Section 8.2.1.

8.3.2 SkyEdge II Physical Layer –ICM – Inbound Adaptivity SkyEdge II includes ICM – multiple dimensions of inbound adaptivity ensuring the highest throughput at the most appropriate ModCod and symbol rate. ICM is based on the closed loop mechanism that continually sends the VSAT C/N reports to the hub for analysis. Based on this constant feedback the hub allocates timeslots and can make changes to the CT definitions. The ICM dimensions available include (not all of them with the same configuration): ICM-1D – Adaptive channel rate selection – Each VSAT uses the appropriate symbol rate ICM-2D – Adaptive ModCod selection – Each VSAT uses the best possible ModCod from the plan ICM-3D – Adaptive Uplink Power Control – The BUC output power is increased or decreased based on a closed loop feedback system ICM-4D – Adaptive channel plan – the Symbol Rate is dynamically modified in real time based on network conditions 8.3.2.1

ICM-1D – Adaptive channel rate selection

As shown in Figure 31 the timeslots used by a VSAT can be allocated in different channels with different symbol rates. ICM-1D exploits the gain differential between higher and lower symbol rates as shown in Section 8.3.1 above. The change can be faster to slower or vice versa.

Freq Q¾ Q¾

Q¾

Q¾

Q¾ ¾

Q¾ Q

Q¾

Q¾

Q¾

Q¾

Q ¾ ¾ QQ ¾

Move to lower symbol rate gains 3dB

256ks/s 128ks/s

Time

Figure 31: ICM-1D change to lower symbol rate

8.3.2.2

ICM-2D – Adaptive ModCod selection

As shown in Figure 32 the timeslots used by a VSAT can be allocated in the same or different channels with different ModCods. ICM-1D exploits the gain differential between higher and lower ModCods as shown in Section 8.3.1 above. The change can be faster to more robust or vice versa.

45


[]


Freq

8

8

8

8

8

8

8

8

8

8

8

¾

¾

6

¾

¾

6

¾

¾

6

¾

¾

/7

/7

/7

Q¾

Q¾

Q¾

Q¾

Q¾

Q¾

Q¾

Q¾

Q¾

Q¾

Q¾

Q¾

Q¾

Q¾

Q¾

Q¾

Q¾ Q½

Q¾ Q¾ Q¾ Q½ ½ Q

Q¾ Q¾ Q¾ Q ½ ½ QQ ½

Q¾

Gain per change

1.1dB

4.3dB

256ks/s

256ks/s

256ks/s

Time

1.3dB

Figure 32: ICM-2D change to lower ModCod

8.3.2.3

ICM-3D – Adaptive Uplink Power Control

The AUPC mechanism aims to keep the receive level at the hub at a nominal value while ensuring that the BUC transmit power remains in the linear zone. Use of excessive power might incur space segment costs. The use of adaptive power control compensates for long term changes in the actual power transmitted caused by: Static attenuation (such as cable); Satellite location offset and aging; Temperature, frequency effect on BUC gain. AUPC is also used to compensate for rain fade. The AUPC includes a mechanism to find the nominal startup transmit power (when the VSAT is first turned on or reset) and an ongoing mechanism to find saturation point and determine how far away this point is from the current Tx power. The VSAT and hub use this information to determine how much gain can be added from the AUPC mechanism and whether other mechanisms such as ICM-1D and 2D need to be used. The mechanism is shown in Figure 33. The receive level at the hub of SYNC bursts received every second from every VSAT is inserted into the out bound traffic to the VSAT. The VSAT can then use this information to determine whether long term or short term effects are affecting the received power. Based on these the VSAT will make the decision to increase or reduce output attenuation. This mechanism is also used by the startup and saturation search algorithms. SYNC bursts (every second) Decision to increase/ decrease

Received ES/N0 (in OB to VSAT)

Figure 33: ICM-3D – AUPC

8.3.2.4

ICM-4D – Dynamic Channels

ICM-4D adapts the Symbol Rate according to the actual network usage. Carriers may be combined to provide higher throughputs or divided into several slower carriers for robustness. As shown in a

46


[]


single 512ksps channel is split into 2 x 256 ksps. The overall network throughput is m aintained while the per VSAT transmission is made more robust (by 3dB as shown in Table 5) .

512 Ksps

512 Ksps

512 Ksps

256 Ksps

256 Ksps

256 Ksps

256 Ksps

256 Ksps

256 Ksps

Network throughput is maintained Per VSAT– more robust channel

Figure 34: ICM-4D – Dynamic Channels

8.3.2.5

ICM – Progressive Adaptivity

SkyEdge II implements an advanced algorithm to determine the correct dimension of ICM to use in a given situation. In rain fade situations the order generally followed is: ICM-3D - Increase BUC power to the maximum possible Choose the most suitable ModCod and symbol rate combination based on a combined lookup table of available dynamic gain. The available dynamic gain will be based on the parameters of the available CTs. Changes occur with the allocation of timeslots. The timeslot allocation is published every 40ms and so round trip changes would take in the order of hundreds of ms.

8.3.3 Dual Synthesizer Frequency Hopping Available in SkyEdge II Access and Pro. Multi -frequency access schemes require that VSATs be able to switch between frequencies. The time taken for the oscillator of the VSAT to change frequency necessitates some sort of delay when a switch is required by the access scheme. The approaches to accommodating this delay are presented in Figure 35. Slow Hopping (1) provides time for the frequency change by simply skipping an entire timeslot. This approach results in higher blockage and lower utilization (around 15% less). The gaps in transmission can also cause jitter. Fast Hopping (2) uses consecutive timeslots but relies on a guard band between all time slots. This too can result in around 15% of the bandwidth being unused.

47


[]


Freq #1

1. Slow Hopping

Freq #2

Freq #1

2. Fast Hopping

Freq #2 Synthesizer settling time

Freq #1

#1 synth

Freq #2 Freq #3

sy nth #1

3. SkyEdge II DSFH

synth #2

Figure 35: Frequency hopping options

Using a dual synthesizer architecture, a VSAT may switch to different frequency channels in consecutive timeslots with guard times as low as 10usec. This high performance fast hopping allows 10-15% higher inbound efficiencies. All SkyEdge II VSATS include DSFH and provide this benefit.

48


[]


9.SkyEdge II Technology As a successor of the successful first generation of the SkyEdge, the SkyEdge II system from Gilat relies on an assortment of advanced technologies which maximize the return on investment for the operator and enhance the user experience. With SkyEdge II transmission adaptivity and application acceleratio n over satellite are further improved, and higher bit-rates are provided. On top of this infrastructure, DVB-S2 is supported in the outbound with the option of Adaptive Modulation and Coding (ACM), providing higher efficiency and higher system availability. The inbound efficiency is improved with the enhanced DVB-RCS with higher order modulation and 4 dimensions of inbound adaptivity (ICM-4D). Several additional technologies are used to further enhance throughput and better utilize the available space segment.

9.1 TCP Acceleration TCP performance over satellite without special treatment is impacted due to the latency introduced by the distance between the Earth and the satellite. Typically this distance translates to a latency of between 240 to 280 msec, depending on where the sending and receiving sites are in the satellite footprint. This makes the round trip time due to propagation delay at least 480 milliseconds. During a connection TCP employs four congestion control mechanisms to avoid generating an inappropriate amount of network traffic for a certain network condition. These algorithms are: Slow start Congestion avoidance Fast retransmit Fast recovery These algorithms are used to adjust the amount of unacknowledged data that can be injected into the network and to retransmit segments dropped by the network. The effective performance then changes between different operating systems as the TCP stack is implemented differently.

49


[]


SYNC

SYNC (Source IP-Add, Port, Dest1, PA-Add, Port, Socket)

ACK (Socket) ACK ACK TCP1 TCP2 ACK1 ACK2 ACK3

TCP3 TCP4 FIN

ACK4 ACK

Figure 36: TCP traffic without acceleration

SkyEdge II includes a special mechanism to overcome the limitations described above and boost TCP performance while maintaining the reliability of the transmission. This mechanism is referred to as This “TCP spoofing”, “Performance Enhancement Protocol” (PeP) or the “Backbone” protocol. protocol is used between the DPS and the VSATs to carry the traffic. The protocol provides reliability and congestion control both in a Star topology and in direct mesh transactions (2008) . The mechanism employed is transparent to the end user and application – there is no need to change any configurat ion or install any client on the TCP end d evice. The mechanism works as follows: Selective retransmits and larger windows are used to improve the performance of the TCP sessions TCP data segments received by the VSAT are locally acknowledged by the VSAT (acting as the remote side of the PEP) on one side and the DPS on the other side (as recommended in RFC 3135). This speeds up TCP slow start and allows the sending TCP host to quickly open up its congestion window. NAKs - Local Negative Acknowledgments are employed to trigger local (and faster) error recovery when significant error rates occur (spike noises). Retransmission – The VSAT and DPS locally retransmit data segments lost on the satellite link, thus aiming at faster recovery from lost data. In order to achieve this, the VSAT and DPS use acknowledgments arriving from the end system that receives the TCP data segments, along with appropriate timeouts, to determine when to locally retransmit lost data. Inbound and outbound TCP-IP headers are compressed.

50


[]


SYNC

SYNC

ACK (Socket) ACK ACK TCP1 ACK2 ACK3 ACK4 ACK5

TCP2

ACK2

TCP3

ACK3

TCP4 ACK4 FIN

ACK5 ACK 5 (B.B.) + FIN ACK

ACK

Figure 37: TCP traffic with acceleration

9.2 HTTP acceleration In a satellite environment, HTTP performance suffers from latency even when the TCP layer is accelerated. Dealing specifically with the HTTP traffic further improves the bandwidth usage and browsing speed. Gilat’s Internet Page Acceleration (IPA) server farm improves the Internet browsing experience while minimizing traffic on the Inbound as well as the outbound channels of the satellite network. This

means that the operator can sell service to more end users over the same bandwidth or alternatively provide better service with higher rates. Tests conducted with the IPA server farm in Gilat ’s labs (on a list of tens of web sites) showed improvements both in the outbound and the inbound. The number of inbound packets was reduced by 35% on average. The number of outbound packets dropped an average of 30%. The total accumulated time to load all the pages was 40% below a comparable network without the IPA. Although performance varies from site to site, these figures represent the capabilities in general. Browser

Server GET HTML O b

ject

ct H TML O bje GET Embedd ed Ob ject #1

O Em bedded

bjec t #1

GET Embedd ed Ob ject #2

Em bedded O bjec t #2 GET Embedd ed Ob ject #3

O Em bedded

bjec t #3

GET Embedd ed Ob ject #4

O Em bedded

bjec t #4

Figure 38: HTTP traffic without pre-fetching

51


[]


The IPA solution is based on a Hub Page Accelerator (HPA) collocated with the hub and a Remote Page Accelerator (RPA) residing in the VSATs. The mechanisms employed are as follows:

9.2.1 Pre-fetching Fetching an HTML page requires a number of TCP connections, one for each embedded object (images, applets, frames, etc.). Sometimes one object has to be completely loaded before embedded objects are fetched, for example an HTML frame set has to be completely loaded before the enclosed frames are fetch which in turn have to be completely loaded before the embedded images are fetched. With the IPA the entire page is provided as a single element to the user browser. As a result, the complete web page is available faster. The IPA pre-fetches the entire w eb page from the Internet at the first GET request, and then automatically pushes it to the remote site without the need to send additional GET requests for each object. This saves space segment (bandwidth) by eliminating the GET requests on the inbound, and reduces the satellite delay . Consequently, the user does not wait for each component object to be downloaded and displayed. B ro w s e r

RPA

H P A Server GET HT ML Ob

ject

H TML O bjec

t

Ob ject #1

Ob ject #2

Ob ject #3

Ob ject #4

c t 4-1 Embedded Obje Ob ject #1

Ob ject #2 Ob ject #3

Ob ject #4

Figure 39: HTTP traffic with pre-fetching

9.2.2 Persistent TCP connections Instead of opening a new TCP connection for every HTTP transaction, the RPA opens a single, persistent connection to the HPA server after the first object request is received. The browser at the customer’s host and the RPA at the VSAT will establish a standard HTTP dialog, with a new TCP connection for every transaction, however these connections are established locally and do not suffer from long delays. The RPA will aggregate all the HTTP information into the single TCP link with the HPA and the VSAT will then handle it as another TCP connection, using spoofing and encapsulating it in Gilat’s “Backbone” protocol. This implementation saves the latency and protocol overhead involved in the multiple TCP connections required to request a complete web page. This reduction in latency is mostly associated with avoiding the TCP 3-way handshake required for opening and closing connections.

52


[]


Figure 40: Use of a persistent TCP link

9.2.3 Header compression Inbound reduction of bandwidth is performed by the RPA by compressing the HTTP header of inbound packets. This reduces the amount of traffic flowing in the inbound and increases the efficiency of the space segment usage.

9.2.4 Text Compression The solution supports compression of the outbound text traffic using GZIP. Text compression saves bandwidth since the text portion of a web page (the HTML) accounts for a significant percentage. The HPA compresses text received from the web servers. GZIP can be uncompressed in browsers based on HTTP 1.1.

9.2.5 Addit ional func tiona lity

The solution supports transparent and non-transparent modes. mode, source IP address of requests to the web server bears the sourceInIPtransparent address of the RPAthe client. In non-transparent mode, request to the web servers have the source IP addresses of the cache servers. Transparent mode is essential when user authentication/monitoring are required. The solution is scalable and expandable. Additional servers can be added with little effort. HPA and Cache connections are load-balanced. This means that a failure with one server does not eliminate service from other servers. HPA and Cache servers are in an internal and protected subnet. This feature allows better protection for the IPA service without additional equipment. DNS caching is supported in the remote sites. This feature reduces repeated transactions to DNS servers from different PCs connected to the same VSAT and adds to the link efficiency.

53


[]


9.3 IP protocol Support The SkyEdge II system is efficiently designed to provide broadband and enterprise IP services and supports the following protocols:

9.3.1 IP

SkyEdge II supports the Internet Protocol (IP). All standard applications that run over IP are supported such as TCP, UDP, FTP, email, web browsing, messaging and VoIP. The system includes embedded performance enhancing capabilities to boost performance and use r satisfaction. Static as well as dynamic routing is supported in SkyEdge II. In addition the common ICMP and special messages are supported such as PING and ARP.

9.3.2 RIP RIP (Routing Information Protocol) is a relatively simple routing protocol primary intended for use in reasonably homogeneous networks of moderate size. It is used by routers to maintain and update their routing tables. A router running RIP will periodically transmit its routing tables to all neighboring routers (using UDP as transport). This is usually done once every 30 seconds. Additionally updates are sent whenever its routing tables change. RIPv2 was designed to overcome some of the limitations of RIPv1, mainly the lack of support for subnet masks. It also changed the routing tables’ distribution from simple broadcast to multicast. SkyEdge II supports RIPv1 and RIPv2 – both at the VSAT and at the DPS. The network administrator can enable selectively RIPv1 and RIPv2 by completely enabling or disabling them or allowing to only “listen” for RIP messages or to only send them. The SkyEdge II also supports RIPv2 authentication. A VSAT can advertise itself as a default gateway for the hosts connected to it. Its routing table will include an entry for network 0.0.0.0 with itself as the next router. To better utilize the space segment SkyEdge II takes advantage of the intrinsic broadcast character of the satellite channel and changes in the DPS routing table at the hub that require a RIP update are transmitted to all the VSATs simultaneously in a single message. In addition RIP scheduled updates are sent over the satellite only if the “route change flag” is set, otherwise they are “spoofed” by the VSAT and the DPS.

9.3.3 BGP BGP is one of the most important protocols on the internet as it is used to establish routing between most ISPs. Very large private IP networks may use BGP internally eg: for joining of a number of large Open Shortest Path First (OSPF) networks where OSPF by itself would not scale to size. Another reason to use BGP is multihoming a network for better redundancy, either to multiple access points of a single ISP (RFC 1998) or to multiple ISPs. With the use of BGP, the end-site announces a single address space to its upstream links. When one of the links fails, the protocol notices this on both sides and traffic is not sent over the failing link any more.

54


[]


9.3.4 DHCP The SkyEdge II VSAT act s as a DHCP server or a DHCP relay agent. As a DHCP server the SkyEdge II VSAT will provide configuration information to up to 32 hosts that request it (the number of hosts to be supported can be limited from the NMS). Any legal DHCP request will be honored as long as there are available IP addresses, there is no filtering based on MAC address. The addresses pool can be based on an arbitrary IP address or on the VSAT’s own address. Primary and secondary DNS servers can be configured for the VSAT. In addition address for a primary and secondary WINS Serves can be configured (WINS stands for Windows Internet Name Service. It is a service analogous to DNS for the Windows environment that maps NetBIOS computer names to IP addresses).

As a DHCP relay agent the SkyEdge II will forward DHCP request messages to the customer’s network attached to the DPS. It should be noted that, when functioning as a DHCP relay agent, the VSAT will forward DHCP requests from every host. All the management of the pool of IP address has to be configured at the customer provided DHCP server. The range of assigned IP addresses must be from the same subnet as the VSAT IP address.

9.3.5 IGMP IGMP is a protocol used for managing IP multicast groups. It is necessary for a multicast router to be aware of the groups to which local hosts belong since if at least one host in a sub-network belongs to a multicast group the multicast router should forward to that sub-network packets addressed to that multicast group. Hosts use IGMP to join or leave such groups. SkyEdge II supports IGMPv2. Every SkyEdge II VSAT acts as a multicast router, periodically sending IGMPv2 queries to the hosts attached to it. The DPS acts like a host responding to IGMP queries from routers in the customer’s IP network or the Internet. The DPS maintains a list of which IP multicast groups are being supported. To keep this list up to date the DPS periodically broadcasts a message (internally between the DPS and VSATs) with information of all the currently supported groups, this message is similar in purpose, to a regular IGMP membership query. If a VSAT has received an IGMP membership report (external IGMP) from a host reporting membership to a group that was not included in the DPS message, the VSAT will send an internal IGMP request message (after a random time). Since the rest of the VSATs do not “listen” to inbound messages the DPS broadcast a new internal IGMP message with updated information so that other VSATs that might request membership in this group will not send a superfluous internal IGMP request.

9.3.6 NAT Operators have the option to operate SkyEdge II VSAT with the Network Address Translation (NAT) protocol. It then uses “private” addresses to communicate with the user’s hosts and “public” address to communicate with the DPS and the customers IP network or Internet. SkyEdge II further supports PAT (Port Address Translation) where multiple private IP addresses are translated to one public IP address using the TCP/UDP ports as the multiplexing aid.

55


[]


9.3.7 Acce ss l ist Access list - SkyEdge II has as an IP Classifier that can implement different actions based on the IP traffic sources and destinations. It allows the network operator to selectively allow or deny network access to hosts and applications. It enables to block all the traffic from a VSAT except for certain source or destination IP address (or address range) and Ports (White Listing) or allow traffic from all host and applications except for specified address and/or ports (Black Listing). The same IP classifier is a dominate element in the QoS capabilities of the system.

9.3.8 VRRP Any SkyEdge II VSAT can function as a virtual router within a VRRP group. With V irtual Router Redundancy Protocol (VRRP) two or more routers on a network act as a single virtual default gateway for an entire network. Computers on the network refer to the virtual address for gateway services. The router that is actively providing gateway services is the Master router, while the other routers serve as backups according to a priority table. As the Master periodically advertises its services, the other routers watch the network to ensure that the gateway is working. If the router is no longer advertising its availability, the next highest router in the priority table begins to advertise as the default gateway, transparently preserving services for the full network through the virtual address which remains valid for all clients. The result is improved business continuity ensuring higher network performance without business users or applications having to do anything, or even know, about network problems that could stop an individual gateway.

Figure 41: VRRP

56


[]


9.3.9 VLAN The implementation of VLANs in SkyEdge II enables the definition of multiple VLANs per VSAT. Each VSAT LAN port can either be in Tag mode or Trunk mode. This eliminates the need for an external VLAN switch. This all embedded solution is less expensive than other VSAT solutions, as it requires fewer components in the solution and is simpler to manage. Some of the benefits of this implementation are: Complete solution – both tag mode and trunk mode are supported enabling the use of both external switches or port-based tagging Flexibility in service - IP Transparency – different customers on different VLANS can have overlapping IP addresses Scalability – up to 8 VLANs per SkyEdge II Pro/Access and 2 per IP/Extend Security – The VLAN/VR implementation provides end-to-end traffic separation between different users sharing the same VSAT Backbone integration – The feature enables operators to seamlessly connect to MPLS backbones and map LSP to VLANs and Diffserv DSCP codes, thereby extending services over the satellite link QoS – different VLANS can be mapped to separate queues which are controlled with maximum rate and relative priority DHCP relay/proxy per VLAN – each VLAN/VR has its own set of DHCP parameters so two customers using the same VSAT can be served by two different DHCP servers.

SkyEdge II

192.168.0.0/24 VLAN A

192.168.8.0/24 VLAN A

Virtual Router 192.170.0.0/24 VLAN C

Virtual Router 192.168.8.0/24 VLAN B

Hub

VLAN Switch

Figure 42: SkyEdge II Multi-VLAN, VRF support

9.4 QoS capabilities The capability to manage and control the traffic flowing in the network is crucial for an efficient use of space segment resources. Furthermore networks today are required to support different

57


[]


applications running concurrently, where each application has a different nature and different users are under different service level agreements. The Diffserv architecture uses the term “Service Level 3 Agreement” (SLA ) to describe the “service contract … that specifies the forwarding service a customer should receive”. The SLA may include traffic conditioning rules which constitute a set of profiles such as metering, marking, discarding and shaping to be applied. SkyEdge II is following the Diffserv architecture and was designed from day one to server as a multipurpose hub for multiple applications and multiple user groups. It provides mechanisms to enforce traffic rules on a single VSAT level as well as on a group level. The QoS mechanisms can be classified according to the traffic direction of inbound and outbound.

9.4.1 Inbound Traffic management capabilities have been implemented both in the VSATs and in the HSP. This mechanisms control traffic per application, per VSAT or per group of VSATs (MPN). 9.4.1.1

Application traffic control (inside a VSAT) according to DiffServ

When application traffic control is configured in SkyEdge II, the IP classifier analyzes the inbound traffic per VSAT and classifies it to three flow priority levels: Low, Medium, and High. The IP Classifier uses the information in the IP Addresses and TCP/UDP ports and performs rate control or weighted priorities per flow (implementing Per Hop Behavior –(PHB) as defined by DiffServ RFCs 2474, 2475 , 4 2597 (3260) and 2598 (3246)). The IP Classifier can also recognize packets according to their DSCP code for packets that are already marked, and assign them automatically to the appropriate queue and handling. SkyEdge II can recognize and handle applications according to one of thirteen types of PHBs – each one is recognized by a different code point (in DSCP). The different classifiers are categorized under the following 4 categories: Expedited Forwarding (EF), Class Selector (CS), Assured Forwarding (AF) and Default Forwarding (DF). Each SkyEdge II VSAT uses thirteen queues to support the capabilities described above. 9.4.1.2

VSAT priority, CIR and MIR

In addition to the above, another level of prioritization is provided on SkyEdge II, using four VSATbased priority levels called metals. In this mode each VSAT belongs to one of the four service levels: Bronze, Silver, Gold, or Platinum. The distribution of metal priority defines how resources are distributed among different VSATs when the network is congested (using ratios). Furthermore, it is possible to define for each VSAT a Committed Information Rate (CIR) and Maximum Information Rate (MIR). This can prohibit network abusing and improve resource sharing.

3 4

The term SLA was updated in some RFCs to SLS – Service Level Specification Differentiated Services Code Points

58


[]

9.4.1.3


Managing traffic per VSAT group - MPN

The MPN mechanism is a QoS mechanism, controlling CIR and MIR on a VSAT group level. Logical groups may be created in the system to allow optimal resource sharing among users of the same entity (e.g. the aggregate guaranteed capacity among all remote branches of the same enterprise can be optimized), or bandwidth borrowing between different MPN groups can be done, for statistical sharing on a network level (e.g. a certain MPN group can enjoy higher rates while another MPN is not fully exploiting its service MIR). 9.4.1.4

Managed Private Networks

MPNs give service providers a mechanism to share the network infrastructure between different customers while maintaining guaranteed committed an information rate (CIR) and a maximum information rate (MIR) for each MPN. Each MPN acts like a pool of VSATs that is sharing a certain inbound bandwidth that the network is committed to supply. Thus congestion in the network will not influence the performance in a vacant MPN, and a congested MPN will not influence the performance in the rest of the bandwidth segment.

Networks bandwidth resources

Resources assigned to customer A Resources assigned to customer B

Oversubscription in MIR values

Figure 43: Managed Private Networks

9.4.2 Outbound QoS The Outbound QoS system is used for optimizing and controlling the usage of the outbound bandwidth. The integrated system, provided by Allot, Includes real-time monitoring and controlling of traffic rates, protocol distribution, top users, active users, top servers, etc. All inbound and outbound IP traffic is routed through the server which resides in the hub and guarantees perfect classificat ion for true end-to-end QoS. The Allot QoS server is integrated with the ACM Outbound as described in Section 7.5 above. Allot's Deep Packet Inspection (DPI) technology is used to provide granular insights into the applications and protocols traversing the network in real-time. An optional accounting application can be added for billing customers according to their network usage. This solution create reports that provide a full history of IP-based account activity, this capabilities to analyze specific application-level traffic flows, as well as long-range traffic usage patterns.

59


[]


9.5 IP Telephony in SkyEdge II Voice over IP (VoIP) is universally replacing legacy telephony services. The VoIP capabilities of SkyEdge II enable a satellite service provider to provide a full telephony service to customers. SkyEdge II provides full support for IP Telephony by using an external ATA (Analogue Terminal Adapter) or by using the internal ATA supported on the SkyEdge II Access and SkyEdge II Pro. The SkyEdge II Access has 2 slots that can accommodate add-on ATA cards. These ATA cards have 2 phone ports thereby providing up to 4 embedded telephony p orts per VSAT. The embedded ATA card is managed and monitored by Gilat’s NMS. IP Phones may be directly connected to the embedded LAN ports on the VSAT. The Figure below provides a schematic description of the elements included in a SkyEdge II VoIP solution, along with their interconnection and dependencies:

SkyEdge II HUB Softswitch IP

E1

SkyEdge II IP ATA

PSTN PSTN SkyEdge II Access

Phone

IP-phone

Figure 44: VoIP Topology

The main characteristics of the SkyEdge II VoIP solution are the following: Voice quality – In order to achieve high quality voice call a dedicated virtual circuit per call is created. The hub manages this circuit in such a way that it eliminates jitter and thus maintains the quality of the session. Codecs supported - The system supports G.729 (8Kbps) and G.723.1 (5.3Kbps and 6.3Kbps) codecs. Protocols supported (for compatibility with external ATAs or IP phones): SIP – SIP voice call are identified as they start. The SkyEdge II implementation includes call admission control (CAC) ((RBGC described in Section 8.2.3.1 above) , and requests BW allocation from the system when a SIP INVITE is detected. If there are enough system resources then they are guaranteed for the whole duration of the call and a virtual circuit between the remote and the hub is created. At the end of the session the resources are

60


[]


returned to the system. If there are not enough system resources to start the call, then the call is dropped. H.323, MEGACO and MGCP supported through RTP detection – the allocation of the resources and creation of the virtual connection is done when the RTP packets start to flow. The system identifies the RTP frames and based on the information inside it does the bandwidth allocation. Fax over IP – T.38 protocol for fax over IP is supported in SIP. Fax over IP over H .323 is supported using manual configura tion of the FXS port. Strict Priority - Since VoIP runs simultaneously with other applications, the VoIP traffic will get absolute priority over any other traffic running over the VSAT. Efficient space segment utilization – In order to best utilize the space segment the system uses several techniques: Inbound - compresses the RTP frame header by 95% from 40 Bytes to 2 Bytes. Outbound – 40% Compression of packet header (from 67 to 40 Bytes) Topologies supported – Star and Mesh, - calls may be established between a SkyEdge II VSAT terminal and the hub, or single hop between mesh-enabled VSATs - improving voice quality and significantly cutting down on delay and bandwidth usage. Concurren t calls – Each VSAT support up to 30 voice calls in parallel. Local calls – Calls made between 2 phones connected to the same VSAT are connected locally and do not use satellite capacity. Up to 256 concurrent local calls are supported. Management – The embedded ATA cards are fully managed from the NMS. Both configuration and monitoring are supported. Any VoIP equipment that supports SIP protocol may be used, however, the implementation of different vendors may include variations. Gilat should be consulted prior to network implementation.

9.6 Mesh Connectivity (SkyEdge II Access and Pro) In star topologies, communication between any two VSATs traverses the satellite twice in each direction – from the VSAT to the hub and from the hub to the second VSAT . This topology wastes space segment, raises operational expenses, and incurs a very noticeable delay for applications such as VoIP and video conferencing. The SkyEdge II Access and Pro can be equipped with a plug-in card to support mesh connectivity among multiple VSATs. A direct connection may be set up between two VSATs equipped with mesh reception capability, where communication traverses the satellite only once in each direction. TCP

61


[]


traffic is accelerated over the mesh connection in a similar manner to VSAT-hub traffic, thus reducing space segment utilization and providing better response times.

9.6.1 The Mesh Receiver 9.6.1.1

Mesh Receiver Physical Characteristics

The SkyEdge II mesh receiver is a double-width add-on for the SkyEdge II Access or Pro, which fits into expansion slots 1 and 2. When a mesh receiver is installed, the RF receive cable connecting the indoor unit and the LNB is connected to the mesh receiver's input and a short cable then extends the signal from the mesh receiver to the VSAT’s main RF input. 9.6.1.2

Mesh Receiver Specifications Receiver type

Single channel, frequency hopping

Frequency Range

950 – 1750 MHz

Modulations and Coding

QPSK: 1/2, 2/3, 3/4, 5/6, 6/7 8PSK: 2/3, 3/4, 5/6, 6/7

Symbol Rates

128 – 2560Ksps

Maximum carrier data rate

6.1Mbps

Maximum payload rate

4.5Mbps, upgradeable to 5Mbps

Maximum mesh connections per

> 1000

VSAT Access Scheme

30 simultaneous sessions DVB-RCS based

Frequency Hopping

Fast

Table 7: Mesh Receiver Specifications

9.6.2 Mesh Operation Mechanism Whenever traffic is to be exchanged between two VSATs capable of mesh connectivity, two logical connections are established, one for each direction. Upon connection establishment: o

TCP spoofing is enabled between the remotes with the purpose of improving user experience as well as reducing the amount of traffic to be actually transmitted on the network.

As with star traffic, predefined QoS policies apply for the transmission between the remotes. The following QoS policies may be applied: o

62

VSAT traffic shaping, based on standard Diffserv with 13 queues. Applications are classified into one of the 13 queues with weighted queuing.

o

VSAT CIR and MIR. These levels take into account both Star and Mesh traffic.

o

VSAT priorities, enabling prioritization of individual VSATs into 1 of 4 priority levels.


[]


o

o

Network flow priority mechanism: When there is congestion bandwidth is allocated to VSATs with prioritized applications before VSATs with lower priority applications. VSAT group QoS – VSATs may be grouped into an MPN (Managed Private Network) with CIR and MIR set for the group.

For voice sessions, admission control is applied to guarantee secured bandwidth for the session duration. A voice or a video session with a minimum bandwidth requirement will only be established if bandwidth is available. Voice and Video traffic is inherently prioritized over all other applications in the network. Jitter is controlled to no more than 20ms.

9.6.3 Bandwidth allocation in Mesh Connections are allocated bandwidth according to traffic requirements in the applicable direction and according to the applicable QoS policies. As with star traffic, mesh VSATs request rate-based or volume-based bandwidth according to the application being used. Real time traffic, such as voice or video is assigned rate-based traffic to ensure low latency and jitter. Non real-time traffic typically uses a volume based allocation, allowing higher utilization of the inbound medium. In SkyEdge II networks star and mesh traffic share the same bandwidth. In enterprise mesh networks however, it is possible to save MCR modules and therefore CapEx at the hub by using the Bandwidth Separation feature with separated dedicated mesh channels. This is suitable for cases where certain sites will only use mesh traffic and will therefore not require channels allocated by the hub MCR.

9.6.4 Acce ss me chan ism The same time-frequency burst plan is shared by star and mesh VSATs, to allow maximum borrowing of bandwidth, optimizing bandwidth utilization according to the dynamic changes in the network. Mesh VSATs receive the allocation map and may simultaneously run mesh traffic and star traffic in consecutive time slots within the same inbound carrier or on different carriers without constraints.

9.6.5 Connection Management Each connection is marked with a network-u nique identifier. Each VSAT is notified of both connections during session setup, as it needs to transmit in the allocated timeslots of one connection and receive the bursts transmitted in the timeslots of the other connection. The VSAT then notifies its mesh receiver of the establishment of the connection. From this po int onwards and until the connection is terminated (e.g. due to closing of the TCP connections that triggered its establishment), the receiver tracks the allocated timeslots and provides the VSAT with any bursts received.

9.6.6 Mesh/Star failover (Future) The link budget for mesh connectivity is typically limited by the VSAT hardware and sometimes also due to pointing accuracy issues. Mesh connectivity with peer mesh VSATs may therefore not always

63


[]


be possible, and connectivity between peers will have to be done via the hub as in a star topology. An example scenario is when the network is using multiple carrier rates where all lower rate carriers are congested. SkyEdge II’s flexible design allows mesh VSATs to operate in a star topology in such cases. The mesh/star failover mechanism operates as follows: The inbound allocation map is shared by star and mesh traffic, as mentioned above. VSATs are allocated send and receive timeslots, either from the hub or from peer VSATs. The hub assigns inbound allocations for transmission and reception every 40ms according to the instantaneous link conditions, overall network demand, and QoS policies. The hub will attempt to assign mesh allocations for the peer VSATs upon mesh session initiations. If no allocation is available, the session will flow through the hub as in a star topology. In a case where a mesh session already exists, and link conditions deteriorate, the hub may reassign the bandwidth and so that traffic flows in a star topology.

9.7 Network Bonding Operators that use Gilat equipment are concerned about the possibility of VSATs being taken out from their network and used in other networks. The network bonding feature enables operators to prevent such a possibility by bonding VSATs to their networks. Network bonding is based on the exchange of Network and Private Keys between the NMS and the VSAT. The Network Key is common for all VSATs in the network. The NMS generates a Network key by hashing (encoding) a password provided by the NMS operator. The operator may change the password (hence the network key) at any given time or may choose to disable the feature at any time. The Private Key (unique for each VSAT) is determined during VSAT manufacturing, and remains the same over the entire life of a VSAT. VSATs store authentication keys in their non-volatile memory; the NMS stores the keys in its database.

Initial Bonding – By default, a VSAT leaves the factory floor not bonded to any network. Bonding occurs once the VSAT sends an AAA request (either during boot or through the periodic mechanism). If Network Bonding is enabled, the NMS saves the private key in its database and sends an AAA reply containing the current network key and the saved private key. The VSAT saves the received network key in its non-volatile memory. The VSAT then transmits these keys as part of each subsequent AAA request. If Network Bonding is disabled, the NMS still verifies the keys provided by the VSAT and authenticate the VSAT as per the verification result. Bonding Verification – When the VSAT sends an AAA request, the NMS compares the provided keys with the current network key and the stored private key. If at least one of the provided keys matches the corresponding value known to the NMS, the VSAT is fully authenticated and continues normal operation (as determined by all other parameters). If none of the keys provided by the VSAT matches its corresponding value stored in the NMS database, and the VSAT is already bonded, the NMS sends an AAA reply containing a Bonding Failure indication and user data prohibition command. The VSAT remains online but user data cannot be

64


[]


transmitted. The VSAT continues sending periodic AAA messages at preset intervals. In the NMS, the VSAT indicates the Bonding Failure state.

Unbinding a Bonded VSAT – Upon receiving an Unbind command, the VSAT erases the network key information from its flash memory and continues its normal operation. In addition, as a result of receiving an Unbind command, the VSAT will not bond again until it is reset. When Network Bonding is disabled (i.e. its status is changed from enabled to disabled), all VSATs automatically unbind through normal operation of the AAA mechanism. In response to a VSAT AAA request, the NMS replies with a blank network key, causing the VSAT to unbind. However, unlike in the case of the explicit command, the VSAT does not need to be reset in order to bond again once the feature is reactivated.

65


[]


10.Specialized VSAT Applications Gilat is a complete solutions supplier and offers a wide range of complementary services and applications. The following paragraphs list some example scenarios

10.1 SkyAbis Cellular backhaul In this case, the remote VSATs are connected to Base Transceiver Station (BTS), which is the network node serving the end users by cellular wireless protocols. The SkyEdge II VSATs work with the Gilat SkyAbis™ adaptor to optimize and compress traffic flow towards the BSC. The solution uses the dynamic bandwidth allocation of SkyEdge II for best efficiency and minimal operational costs. Cellular operators can use this solution to extend their service coverage to rural areas in a cost effective manner. The SkyEdge II s ystem can simultaneously transport Abis as well as other traffic.

Sky-Abis adapter BSC

MSC

SkyEdge II

E1

SkyEdge II

E1 IP

IP

E1

E1

Sky-Abis Adapter SkyEdge II Hub

BTS 1

BTS n

Figure 45: Cellular backhaul

SkyEdge II also supports the current usage of BTSs with integrated IP adapters. For IP-Abis SkyEdge II further optimizes the traffic by using compression techniques that can reduce the traffic by up to 20%. Compression techniques include: IP Abis header compression UDP header compression for voice or UDP Abis signaling TCP spoofing for signaling and other TCP Abis traffic Creating an internal tunnel excluding Gilat's propriety backbone protocol Packet aggregation

66


[]


10.2 Multiple applications in a shared network The hub is in this case is owned by one entity (typically a satellite operator) but offering services to two or more organizations. In this case one customer is a university which uses the VSATs to create a virtual class over a wide geographical coverage. This service brings Interactive distant learning and combines video broadcast from the HQ with video conferencing capabilities. It is combined with additional messaging service, white board and completing features. The same hub operator provides secured connectivity to employees of another organization to their data center HQ. This service is secured by means of IPSec tunnels and use dedicated resources as supported by the MPN QoS capabilities.

Internet, Intranet

IDL teacher

Figure 46: Shared hub

67


[]


11.Acronyms 11.1 SkyEdge II Acronyms Abbreviation BB DPS

Explanation Back-Bone (proprietary protocol) Data Protocol Server

GW HPA HSP IPA VSAT

Gateway Hub Page Accelerator Hub Satellite Processor Internet Page Accelerator Very Small Aperture Terminal

11.2 General Acronyms

68

Abbreviation ACM CCM MODCOD VoIP SIP H.323 cRTP

Explanation Adaptive Coding and Modulation Constant Modulation and Coding Modulation and Coding combination Voice over IP Session Initiation Protocol A messaging VoIP protocol Compressed RTP

RTP BW QoS QPSK GMSK MF-TDMA

Real Time protocol Bandwidth Quality Of Service Quadrature Phase Shift Keying Gaussian Phase Shift Keying Multi Frequency – Time Division Multiple Access


5_Annex 6 4 - SkyEdge II Technical Description v5

Recommend Documents