A REVIEW ON CAPACITY PLANNING AND NETWORK SIZING FOR VSAT IN SATELLITE COMMUNICATIONDR.
VENKATA RAGHAVENDRA MIRIAMPALLYProfessor, Department of Electronics & Communication Engineering,St Mary’s Integrated Campus, Hyderabad, Telangana.Email: [email protected] ABSTRACTThe greatest challenge to developers of VSATs is to build versatile and reliable data communication systems that could compete with existing terrestrial technology. Consumer broadband Internet access is a reality for more than 40 million homes in developed countries, but pushing this out in a global context has proven to be a challenge. Implementers of VSAT networks have their own challenges to face, that of properly sizing the network and maintaining its performance as requirements change. The purpose of this paper is to provide some guiding principles how to approach the problem of capacity planning and network sizing.Key words: Satellite Communication, VSAT1 INTRODUCTIONCollecting Requirements for the VSAT Network We are taking the systems approach to this problem, which consists of determining the requirements, sizing the network, and determining overall performance against the requirements.
The typical requirements for a data communication network fall into the following categories. • The applications that the network is to support, in specific terms such as software, user devices, message content, and standards to be employed. • The number of connections / users and locations that are to be serviced, which defines the geographic properties and the connections of the requirements.
The output of this part of the exercise is the topology of the network. • The traffic or information volume that is offered to the network by each user or by an expected volume of users considering the particular amount of information as well as the timing of its occurrence (also referred to as its temporal nature). • Throughput is the amount of useful data that is transferred per unit of time, measured in bits per second, packets per second, or the like. This provides an estimate of the aggregate bandwidth required from the VSATs, hub, and satellite.
• Time delay (also called latency) is the amount of time required to transfer a specific amount of data. Applications should be subdivided as to their fundamental needs in this area—real-time applications versus non-real-time applications. Latency is collection of line transfer time, access protocol time, propagation time, and node processing time. Interestingly, satellite system users focus on propagation time, which is only one of the factors. If this is a circuit-switched type of network, then the call setup time must also be considered. All of these times are the sum of a number of contributors, some of which are constant and some of which are variable or random in nature. • Response time is measured from when a user initiates a request to when the response is displayed on the user’s terminal device.
This applies mostly to data communication networks where users employ PCs or other types of display terminals, phones, and video systems. • Other service demands that are unique to the user community, such as mobility and transportability, growth, and ability to support new and evolving applications. • Service management aspects, such as reliability, availability, mean time to repair (MTTR), and help-desk and accounting support.Each requirement has a definite impact on the, cost, complexity and capacity of the network, VSAT or otherwise. Requirements (first, second and third) are the basic inputs for the design of the network, defining the structure, distribution, and timing of the information to be carried and/or distributed among users. Believe it or not, this is the hardest thing to determine because in most situations it is simply not known with any precision. Another real but less good reason is the internal structure of the organization where functional groups tend to not want to share this kind of information.
Breaking down these barriers can be extremely time taking, tedious and this is a reason why the network fails to satisfy users who were unable to have their particular needs presented in the final design of the network. The remaining requirements (fourth, fifth and sixth) are performance measures that can be obtained from a live network. User fulfillment is often driven by them, this is the reason why it is important that they should be understood before a major commitment is made to a particular technology. In the nonappearance of a working network, tests with a pilot system can gain insight knowledge. It turns out that the user experience and level of approval is based on what they already know from using other networks and services. If their expectation is low, then any improvement will be made favorably. Throughput measures the actual quantity of data flowing between users over a given network.
In the process of carrying data, the network introduces overhead information that is needed to control and manage network operation and is not part of throughput. Another non throughput contributor is data that must be retransmitted due to congestion or errors on particular links. For these reasons, the throughput rate offered by a vendor’s VSAT product may in fact be overstated by a considerable margin, as much as 100%. Since it is difficult to sort out overhead, the best way to know the actual throughput is to perform a live test. The logical way to design a data network is to begin with the requirements for data transfer among the various users and points of operation. If you are starting with an existing star network, there would already be a working host computer and many remote users.
Typically, this would use terrestrial leased lines that connect from the remote sites back to the host. The data requirements can be determined at the host where all of the data can be observed for each remote and each leased line connection. Statistics on the information packets, their delays, and the overall response times are collected using monitoring software that is loaded into the host. In a peer-to-peer or client/server environment, the network is far less structured and there is no single point of concentration where data characteristics can be gathered. Remote hosts and servers allow some of this information to be collected, as can monitor devices on LAN segments and routers used to interconnect LANs. This information may be available at a network management station that employs SNMP. If necessary, technicians can make manual measurements using a protocol analyzer such as the Sniffer by Network General or the LAN analyzer by Novell. Information such as quantity of packets and their lengths, throughput, retransmissions, number of virtual circuits, and transfer delays are definitely of value in sizing the VSAT network.
It is likely, however, that this information will only address part of the requirement because there will be new applications and computer systems. Service demands and management (requirements 7 and 8) may represent the difference between success and failure in a real implementation. Engineers who focus on technical details can satisfy themselves that the network will, in theory, meet the need.
Once deployed, the network will be subjected to a variety of stresses in the environment: • The users themselves, who cause the demand to rise and fall in unpredictable patterns; their actions can cause hiccups and failures due to bugs in software or situations that the developer did not expect; • The physical environment, in terms of location, weather, and distance to be covered;• Availability of support for remote locations too far for repair people to visit; • Lack of extra components and test facilities that allow the operator to identify and correct problems quickly and with minimum disruption; this is the result of the extended distances and remoteness that itself is justification for using VSATs in the first place. Developers of VSAT networks must assess and track all of these factors if they wish to succeed beyond seeing the system enter service. Experience is the best teacher when it comes to VSAT network operation and extension. Our advice is to begin the design effort with a research project where requirements are collected, categorized, and refined. Values of acceptable time delay and response time must be established ahead of time so that the network components can be sized properly. Figure 9.
1 shows the major elements of the link between user terminal and server computer over a VSAT star network. This is at a high level and should not be regarded as a specific design (we provide such an example later in this chapter). We can see that there are several contributors and each add to the delay as experienced by the user of the PC client workstation. Figure1. Major contributors to delay and response time in a VSAT star network.At the start of an exchange between client and server, the user enters data and hits the return key. This causes a block or frame of data to be applied to the local access line between the PC and the VSAT indoor unit.
The speed of this line determines the time delay for transfer of the entire packet (we can ignore propagation time since the distance is usually less than 1 km). Hence, the data is repackaged within the indoor unit and formatted for the satellite return link. VSATs may initiate an exchange of data using a fast access technique like ALOHA or CDMA; subsequent transfers of either large blocks or files or a real-time information transfer could be accomplished with continuous transmission (SCPC) or TDMA. The amount of additional delay will depend on the access technique, channel loading, and need for retransmission (a consequence of using either ALOHA or CDMA).
The uplink and downlink introduce nearly constant propagation delay, amounting to approximately 260 ms total (for a single hop). The delay of the satellite repeater is typically less than 1 ms and therefore can be ignored. An exception would be an advanced processing type of repeater that requires a certain amount of time to route the packets. This is specified by the satellite manufacturer and would be expected to be a constant number much less than the propagation delay. The next significant contributor to delay is the processing within the hub baseband equipment, resulting in a restored block of data at the local access line.
Most hub installations multiplex several streams of such data together, a process that can add a small but measurable delay. Finally, there is the transfer and propagation time associated with any backhaul circuit between the hub and the server. Additional delay is introduced by the server (including its operating system, file management system, and application processing). Processing time within the host is not supposed to be counted as part of the response time of the network, but it is often added since it will, of course, be experienced by the user at the PC client. A well-engineered VSAT network will fail if the server cannot process the required number of user actions. For that reason, it is essential that the performance of the server by itself be budgeted and verified before connecting to the satellite network. This establishes the baseline with which to certify the overall service on an end-to-end basis. The same can be said of additional network connections that data must be negotiated before reaching either the end user or the server.
An example of a typical time budget for this end-to-end connection is provided in Table 1. We have made the assumption that the user wishes to transfer a block of 10 KB, which is 80,000 bits. Assumed line transmission speeds and processing delays are indicated in the table. In this example, we looked at one direction only; also, there are other contributors, such as an end-device queuing delay, that add to the total. There would be a separate estimate for the forward direction compiled in the same manner. This estimate shows that the access-line delay contribution occurs only once and is determined by the speed of the link (256 Kbps at the original access point, producing a delay equal to 80,000/256,000 = 312.
5 ms). The uplink/downlinkTable 1 An Example of a Delay and Response Time Budget for a PC-to-Server Application over a VSAT Network, Assuming Transfer of a Block Containing 10 KB (Including Overhead)Item Element Line Speed (Kbps) Intrinsic Delay to Transfer Block (ms) Propagation Delay (ms) Actual Contribution (ms)1 PC client workstation – 0 – 02 Access line 256 312.5 – 312.53 VSAT indoor unit, inbound direction – 10.0 – 104 Multiple access protocol (TDMA) – 25.0 – 255 Uplink propagation – – 135.
0 135.06 Satellite (bent pipe) – – 0.0001 0.00017 Downlink propagation – – 130.0 1308 Hub baseband equipment – 50 – 509 Backhaul data circuit (hub to server) 2,048 39.1 3.0 42.110 Server processing – 100.
0 – 100.0 Figure 2: Delay and Response Time Budget for a PC-to-Server Application over a VSAT2. VSAT ACCESS PROTOCOLS Capacity estimation in a VSAT network is a complex problem driven by the fact that many of the key variables are not well known ahead of time. Also, even if you have a good estimate of the required number of users, their locations, and the data throughput needs, there is still the problem of considering how these users will interact with each other and with the system at any given time.
We typically work with an average of some sort and allow for a peak during the busy hour or seasonal peak of activity (like just before Christmas in the retailing industry or summer in air travel and hotels). But this does not consider the statistical peaking that occurs from an instantaneous heavy load after some unexpected event or if some particular users activate an application that produces a surge in the network. As illustrated in Figure 3, the network loading has statistical peaks and an overall average during any particular period (1 week is shown). A network sized for the average load will work during off- peak periods. However, the noise-like peaks could overload any of a number of potential choke points—some within the control of the VSAT network designer and some outside of it—resulting in greatly increased latency and even dropped data communication sessions. As in any computer system, this can only be dealt with by allowing some headroom in terms of bandwidth or processing capacity.
Figure 3: Illustration of data traffic load on the VSAT network, assuming random activity of users and applications.What we have are some basic methods of estimating the load, and from that, the capacity. This should be taken as a starting point for sizing and not used as if it was an accurate prediction. There are different access protocols for the purpose.
TDMA Access Protocol: The inbound channel is shared by multiple VSATs that transmit their data in bursts. TDMA is one of two basic multiple access methods used for this purpose.ALOHA Access Protocol: Another approach for separating the inbound channel transmissions in time is the ALOHA protocol.
The scheme is simpler in that the transmissions are uncoordinated; however, the complexity occurs because there are occasional overlaps that result in lost communication. This is overcome by retransmissions from the affected VSATs.CDMA Access Protocol: CDMA is a relative newcomer to the VSAT scene.
The strong play made by QualComm with its CDMA cellular standard and evolving 3G technology has greatly enhanced the position CDMA holds on a global basis. However, the benefits of CDMA for GEO satellite applications are considerably less and hence it has not played a major role to date.FDMA as an Access Protocol: FDMA, and more specifically Single channel per carrier (SCPC), have long been used in preassigned and demand-assigned networks of multiple Earth stations in point-to-point and mesh topologies. ATM Protocol over Satellite: Many of the original applicants for Ka-band satellite licenses proposed to use ATM as the access protocol of choice. The reasons for doing this might be summarized as follows: • ATM was originally developed for broadband networks—its short, constant length cell structure promotes fast action from routing and switching equipment. • ATM is adapted to many telecommunications applications—toll quality voice, video, high-speed data. • ATM is inherently a mesh network structure—onboard routing between beams is easily accommodated.
• ATM hardware has been available and proven for more than 10 years—development timelines could be reduced with the possibility of using off-the-shelf designs. Comparison of Access Protocol Performance: TDMA and ALOHA are very established as VSAT access protocols for the inbound channel. Recently, CDMA has been developed as another inbound channel access method, and ATM has been selected for some of the Ka-band systems. These techniques differ in their operation and most certainly in their performance. The consequence of this is that users should select the protocol based on the requirements of the application.
ALOHA and CDMA have the benefit of offering the transfer of a data packet with the minimum possible delay. This requires that the channel be lightly loaded. TDMA is best applied to an application that requires near continuous data transmission. Lastly, FDMA is a simple approach that guarantees that bandwidth is available and where additional time is introduced for frequency assignment purposes. It is the function of the VSAT indoor equipment to take a continuous data stream, such as for a telephone channel or file transfer, and break it up into a sequence of bursts.
A time-division or SCPC channel can be provided on a preassigned basis to be maintained until the network is reprogrammed. Alternatively, the connection can be established on demand, through a process called bandwidth reservation. This would employ the ALOHA or CDMA protocol to request the bandwidth, which is subsequently provided via the TDMA or FDMA protocol. At the conclusion of the call, a release request is transmitted and the bandwidth is made available to others.3. SIZING OF VSAT NETWORKSThe typical VSAT can be configured to satisfy a range of data transfer requirements and thereby achieve an acceptable response time or whatever the appropriate quality of service measure may be.
Whether a satisfactory result can be obtained depends on this match; not every application will fit the particular architecture and throughput capabilities of the typical VSAT network. Cases where there is a good fit usually adhere to the following: • The network is clearly a star topology, where there is a central host computer that supports a large quantity of remote locations. This depends on having a centralized data processing structure, where remotes depend on the host for information access and network management.
Alternatively, the hub is connected to the Internet through a suitable ISP. • The data rates on the forward and return links are sized adequately for peak demand. • The throughput requirements are consistent with the basic data transfer capabilities of the VSATs and the hub. This must be verified through the process of sizing.
The focus of this paper is on the proper sizing of star VSAT networks. Before this activity can begin, all of the requirements for the network must be listed and quantified. These are broken down as to form of information and application that processes it, locations and the associated number of users, and the measures of quality of service to be addressed. Table2. Provides a format for this type of analysis, based on a typical organization’s needs. From this, the requirements for the hub, remote VSAT, and transponder can be surmised.3.
1 HUB SIZING The sizing of the hub equipment is particularly important to VSAT network design because it relates to the most costly single element. Quantities of line interface cards, modulators and demodulators, and baseband processing equipment must be determined and placed on order with the supplier. However, this is a complex problem that warrants careful consideration and significant involvement by the supplier since they understand the unique architecture and capabilities of their products. The hub is often modular in nature, being composed of a variety of racks of equipment that are configured for the particular network requirement. It is relatively simple to add, remove, or rearrange equipment within the hub, thus allowing the capacity to be managed and new capabilities introduced from time to time. In the case of star networks using MPEG 2 and DVB-S, several outbound carrier components are standard items that are supplied to the broadcasting industry. These include the MPEG multiplexer, IP encapsulator, and DVB-S modulator. Specialized components would be added by the VSAT manufacturers for inbound-to-outbound synchronization and restoration of proper MPEG PCR timing.
Table 2. Example of a Summary of VSAT Network RequirementsUser Application Network Requirements Number of Locations Bandwidth Requirements Quality of ServiceInternet access (one user; small group; remote site) High-speed access to Internet backbone; TCP/IP 250 Better than dial-up Page download within 30 secondsRemote access to corporate intranet (LAN extension) High-speed access to private network infrastructure; Web based applications; TCP/IP 250 Better than dial-up Page download within 30 secondsRemote access to corporate business applications Medium- to high-speed access to private network 250 32 Kbps per user Response time less than 5 secondsContent distribution Multicast uplink for wide area distribution to PCs and content caching servers; UDP/IP and Multicast Transport Protocol 15 256 Kbps 100% accuracy of delivery within 1 hourVideo teleconferencing High-speed access to private network infrastructure or public ISDN; H.320 or H.323 standards 25 256 Kbps 1.5-second one-way delayTelephone Low- to medium-speed access to private network infrastructure or PSTN; POTS or VoIP standards 250 8 Kbps 0.5-second one-way delayLeased line Medium- to high-speed connection; Frame Relay 15 256 Kbps 300-ms one-way delayThe RF terminal is typically of standard design as applied in teleports and either located in an external shelter or outdoor cabinet.
Once the antenna, LNBs, and RF power equipment are installed, it is unlikely that many changes will be required to accommodate the hub baseband equipment. The critical step, discussed later, is the sizing of the HPA, which could be one of three types: SSPA, TWTA, or klystron power amplifier (KPA). Adding equipment or increasing RF power may require a major modification of this part of the hub, and even a complete replacement could be a consequence. It is usually best to allow the VSAT hub supplier to participate in the sizing of the network. This can be done using the power of competition to obtain the best estimate, both in the terms of the quantity of equipment and the ultimate price.
A low estimate could result in under-capacity; additional equipment could be brought after the network is put into service to resolve cases where response times are excessive. Backup, spare items, and any specialized test equipment and software should be purchased at the same time and tested to verify proper operation. The critical elements of the hub related to sizing are shown in the simplified block diagram given in Figure 4. In its role as the central point of the star network, the hub coordinates all transmissions over the satellite and provides the connection to the host computer. These elements must be sized to support the maximum capacity of the hub, which also determines the capacity of the network. In this example, the applications are serviced by a central host or server computer that may provide access to the external world as well (e.
g., the Internet). Figure 4: The elements in the hub that determine network size and performance.From a network standpoint, the server establishes all of the sessions with remote user devices and assures reliable transmission. The backhaul circuit is either a short direct connection in the case of a locally connected hub or a dedicated circuit using private or public transmission facilities. Communication between the port and the server follows the protocol used by the host in its normal operation. Most corporate applications operate through the TCP/IP suite of protocols, and the physical and link layers are likely to be provided with Ethernet (IEEE 802.3).
While it is customary to use a synchronous physical layer such as a T1 or E1 for the backhaul, there are instances where an asynchronous metropolitan area Ethernet service can be employedVSAT REMOTE SIZING The remote site where a VSAT would provide service is typically a branch office, retail store, government service center, or even a home. Historically, the type of data communication to such locations was using either a dial-up telephone connection or an analog leased line, a problem that the VSATs were originally designed to address. With the advent of the Internet, broadband DSL and cable modems, and real-time applications like VoIP and videoconferencing, expectations for data speeds have increased to more than 128 Kbps. For a single user, this speed can provide a reasonable approximation of a broadband service.
More users on the same line will demand greater access speed—the precise amount will depend on the activity these users engage in. The ability of the VSAT to meet the requirements of a remote location is constrained by the maximum throughput of the inbound channel data rate, which typically is not greater than about 2 Mbps, and more likely is between 300 and 600 Kbps. Out route speeds, however, can reach tens of megabits per second with the maximum currently supported by the DVB-S standard being in the neighborhood of 100 Mbps. TRANSPONDER CAPACITY SIZING A given VSAT network may only require a fraction of a satellite transponder, where a transponder supports several outbound channel carriers and their associated inbound channel carriers within its usable bandwidth. This packing efficiency permits a given network to go into operation at a relatively modest cost because transponder capacity can usually be purchased based on the percentage of the transponder that is needed.
As in the case of a multicarrier Earth station HPA, sharing the transponder power must allow for multicarrier output backoff in the range of 3 to 5 dB to control intermodulation distortion.CONCLUSION1. In this paper we have discussed about capacity planning for a VSAT technology in satellite communication, then we introduced different protocols and multiple access techniques used for communication. 2. Further we compared these protocols and finally explain the concept of VSAT network sizing.REFERENCES 1. Elbert, B., (guest ed.
), “Satellites Address the Digital Divide,” Online Journal of Space Communication, Issue 5, July 2003, http://satjournal.tcom.ohiou.edu/issue5/main.html. 2.
Stallings, W., Business Data Communications, 4th ed., Upper Saddle River, NJ: Prentice Hall, 2001, p. 214.
3. Rosener, D., et al., “A Robust, High Performance Network Provided by Astrolink,” AIAA International Communications Satellite Systems Conference, Montreal, Canada, 2002.
4. Choi, H.-K., et al., “Interactive Web Service Via Satellite to the Home,” IEEE Communications Magazine, March 2001, p. 182.
5. Lee, J. S., and L. E. Miller, CDMA Systems Engineering Handbook, Norwood, MA: Artech House, 1998, p. 368.6.
Elbert, B. R., Networking Strategies for Information Technology, Norwood, MA: Artech House, 1992.7. Barda, A., Z.
Ner, and S. Laufer, “Closing the Digital Divide Through Resource Allocation Techniques,” Online Journal of Space Communication, Issue 5, July 2003, http://satjournal.tcom.ohiou.edu/home.html.
