- Page 1: iDirect enabled technology: Introduction
- Page 2: TCP over satellite and reliability
- Page 3: Rain fade and performance issues
- Page 4: Services
The iDirect solution addresses rain fade in two ways: first of all, the use of TPC forward error correction technology means that significantly less power is required to deliver the same bandwidth as a legacy system using RSV. Secondly, the iDirect solution incorporates automatic power control that automatically boosts transmit power as the signal degrades due to inclement weather. The additional power margin provided by TPC forward error correction can be used to boost the signal without exceeding the power limits imposed by the satellite vendor on their transponder. The hub equipment located at the teleport constantly monitors the signal from each remote site. As bad weather moves into a particular area, the remote VSAT(s) in that area are remotely and automatically commanded to boost their transmission power. As the weather clears, the transmission power is throttled back.
Downloading (outbound) on a broadband satellite system is not overly difficult. The transmission is basically a broadcast that is sent to all remote VSATs. In the case of the iDirect solution, each satellite router has a burned in MAC address and it can only receive data that is specifically sent to it. iDirect uses a proprietary TDM frame format that is approximately 60% more efficient than most DVB systems; otherwise the operation is very similar. The difficulty comes on the uplink or inbound link.
Multiple remote VSATs must contend for bandwidth in order to transmit or uplink their data. Some legacy broadband satellite systems contend for bandwidth, leveraging technology that works much like shared Ethernet. As more users are added to the system there are collisions that result when multiple users request bandwidth at the same time. As the load increases, this can create a snowball effect until all the bandwidth is chewed up just handling the contention. Thus it is very important that the network not be highly over-subscribed or service may be seriously impacted. Once a VSAT has contended for access, the hub will assign bandwidth on the same frequency or channel (TDMA) or on multiple frequencies or channels (MF-TDMA). This bandwidth assignment will be made based on some sort of fair access algorithm and the active bandwidth request from the remote VSATs. Unfortunately the access is inconsistent because collisions may occur when multiple VSATs request a connection and bandwidth at the same time, and must back off and retransmit. This causes slow start up times and adds jitter which affects applications like VoIP and Video/IP.
Most of these systems (which are based on the DVB/RCS specification) allocate bandwidth in 8 or 16 Kbps chunks for pre-configured amounts of time, frequently measured in seconds. As the time period expires, if the remote VSAT isn’t using the bandwidth or if a higher priority request is made, then the bandwidth is released and may be reassigned. Unfortunately this method of allocating bandwidth can be very wasteful and inefficient, and is very difficult to optimize for best performance. Internet or web based traffic is very bursty. Transmission times are generally very short and random in nature. Since bandwidth is generally allocated for a minimum of several seconds, all the idle time in which a VSAT holds assigned bandwidth, but is not actively transmitting is wasted transmission capacity.
The iDirect system minimizes the connect time by assigning a small amount of dedicated bandwidth or CIR (Committed Information Rate) to each satellite router, so a VSAT never has to contend for access. It always has a connection to the hub. An additional pool of shared bandwidth is dynamically allocated to each remote site up to 8 times/second using a fair access algorithm to prevent high usage sites from starving other sites. Bandwidth, or timeslots are never held by VSATs, but are constantly assigned and allocated in real time, taking maximum advantage of available bandwidth and distributing it. The hub dynamically allocates bandwidth to each site based on configured rate limits, QoS, CIR and current queue depths. In some ways, this technology can be thought of as upgrading from a shared Ethernet hub to a smart Ethernet switch, with all of the resultant performance benefits provided by that solution. Frame Size between users in real time. Bandwidth efficiency increases from 10 to 20% for most legacy systems, to over 95% on an iDirect system.
The iDirect solution is excellent for VoIP and Video/IP for several reasons. Because of the dedicated bandwidth, there is no contention required to begin a transmission, managing jitter for these sensitive applications. Additionally, allocated bandwidth for a VSAT is feathered’ or spread out across entire frames, creating a smooth even data flow, rather than the jerky delivery experienced with many other systems.
Many legacy systems use a 250ms frame size. That means sampling at only 4 times/second which yields a sluggish web response and very poor voice quality. The iDirect frame size is variable depending on the application, but is generally set at 125ms which means sampling 8 times/second. This yields a crisp user web response and business class quality VoIP service. Of equal importance is the ability mentioned above, to feather’ or spread out the transmission data smoothly and evenly across the transport frames for a consistent low-jitter service.
Quality of Service (QoS)
Application QoS based on Class Based Queuing, found in leading QoS engines like Lucent’s Access Point router, Sitara, etc. allows the administrator to allocate a percentage of bandwidth to specific applications or protocols and to set the priority level (basically the queue depth) in order to deliver the desired quality. QoS works in both directions, so a VoIP call won’t be stepped on by another VSAT’s large download file. When the prioritized application is idle, the bandwidth is available for general use. A further advantage and unique capability of the iDirect solution is the ability to do fragmentation and interleaving. This eliminates the case where the system has started to transmit a large data packet and a small voice packet comes behind and is delayed (even though it is prioritized in the queue). When large packets are fragmented, then the voice packet only has to wait for one slot.
- Traffic prioritization may be performed on
- Destination IP Address
- Source IP Address
- Source TCP Port Number
- Diffserv and ToS Bits
- Protocol (TCP, FTP, UDP, RTP, ICMP)
The QoS feature can also be used to filter out or discard unwanted data based on the same criteria, basically by assigning zero (0%) bandwidth allocation for the undesirable application or protocol. For example, an organization might want to block gaming, or MP-3 downloads or Kazaa file sharing, or restrict the amount of bandwidth available for these and other applications.