Bandwidth Allocation and Management for Multimedia Networks Over Satellite Links

Charles Auger, Peter Andreadis, Claude Blisle, and Steve Bernier Communication Research Center Ottawa, Ontario, Canada E-mail: charles.auger@crc.ca ABSTRACT This paper presents a dynamic bandwidth allocation and management technique based on flow analysis and quality of service provisioning. This technique aims at improving the performance and bandwidth utilization of various multimedia applications over long-delay satellite links. A network configuration using satellite communication resources and providing e-mail, web browsing, file transfer and database services has been modeled using OPNET 7.0. A dynamic bandwidth allocation scheme combined with a weighted-fairqueuing (WFQ) algorithm has been implemented in the network model. Network configuration, and implementation details are discussed. 1. INTRODUCTION The ubiquitous nature of satellite communications makes it an ideal candidate for providing Internet services worldwide. The advantages of combining the high bandwidth, wide area coverage, reconfigurability, and multicast capabilities of satellites with terrestrial networks provide immense new market opportunities. Users can be connected to the satellite link directly from their home or mobile terminal, via a local area network or through an Internet gateway. This architecture creates a wide variety of bandwidth requirements at the different satellite communication ground terminals (GT). Considering the expensiveness of satellite bandwidth, a technique to effectively share it between the different GTs is needed. In this paper, such a technique allowing dynamic bandwidth allocation is presented. It has been developed in the context of a controlled network environment, where our client has knowledge and control over the types of traffic and the network applications. Consequently, traffic can be categorized in flows according to some pre-determined rules, and priorities can be assigned to each flow. The quality of service offered to users is therefore related to the bandwidth allocation scheme and the prioritization mechanisms. Section 2 of the paper presents the network configuration used in this study and introduces the modifications done to the communication protocol in order to improve performance and bandwidth utilization. Section 3 describes the dynamic bandwidth allocation scheme. Section 4 deals with the use of the WFQ queuing mechanism and explains the modifications done to it to support dynamic bandwidth allocation. Some closing remarks and directions for future work are presented in section 5. 2. MODEL DESCRIPTION The project described in this paper is composed of two distinct tasks. The first one consists of evaluating the performance of our clients applications when part of the network travels through a geo-synchronous satellite constellation. This has been accomplished by modeling the networks using OPNET and evaluating the performance through simulations. A summary of the OPNET design is presented in section 2.1. The second task of the project consists of proposing and evaluating ways to improve the performance of the network applications traveling through the satellite links. The potential improvements we considered are presented in section 2.2 and the modifications made to our OPNET models to support those improvements are described in section 2.3. 2.1 Original Network Configuration Two subnets linked via satellite are modeled using the OPNET 7.0 software. The subnets contain two networks, one located in Ottawa, called CRC Ottawa, and the other in Europe, called Samos U (Figure 1). The Samos U network contains Lans and workstations running various applications that request data from the CRC Ottawa network. Each ground terminal is allocated dedicated bandwidth to communicate over the satellite link. The links shown here emulate a satellite connection with various delays. The satellite payload is designed as a simple router at this point. No physical waveform or satellite processing is modeled at this time. The RF characteristics are modeled as link quality expressed in terms of BER. All traffic generated travels over the satellite link. No caching is performed. The application data sent are file transfers (FTP), web (HTTP), e-mail, database and weather information downloads (HTTP based application). Traffic models where developed using the Profile and Application configuration tools of OPNET. Many simulations were performed for three types of TCP stacks, and for different bandwidth apportionments under various BER.

Queuing serves three purposes in our performance enhancement solution: a) Traffic segregation and prioritization: WFQ allows the selection of rules to segregate incoming traffic in different queues based on criterias such as source and destination address/port, transport protocol, and application type. It also allows the assignment of weights to the queues that will influence the order in which packets will be transmitted.

b)

Source of information for bandwidth allocation: as we will see in subsequent sections, the dynamic bandwidth allocation mechanism relies on queue information to select the amount of bandwidth to allocate to a GT. Congestion control: although this subject is not part of the current paper, queuing can serve as a basis for packet discarding when congestion occurs at a GT.

c)
Figure1. Satellite Network in OPNET From the simulation results, two major issues can be raised. First, as expected, the network performance is greatly influenced by the TCP implementation and even with the best implementation available performance results are still marginal over long delay links. Second, to obtain good response time, the apportioned bandwidth should be made equal to four times the average traffic throughput. While this is not a costly issue for terrestrial networks, in a satellite environment, where bandwidth is an expensive resource, a better utilization than 4-to-1 would be desirable. For more details of the network simulations performed and the results, refer to Performance Analysis of Multimedia Networks over Satellite Links, by P. Andreadis[1]. 2.2 Improvement Areas Three possible performance improvements to our network configuration have been considered. First, TCP enhancements have been analyzed in order to improve the performance of TCP based applications over long-delay error prone links. The topic of TCP performance issues and possible improvements over satellite links is presented in [2]. The second potential improvement concerns the allocation of bandwidth. The expense of satellite communication resources renders static bandwidth apportionment cost ineffective [3]. Furthermore, traditional circuit-switched based allocation methods are inadequate to efficiently support highly bursty Internet multimedia traffic over satellite links. Such allocations policies guarantee QoS at the expense of network capacity [4]. We therefore designed a dynamic bandwidth allocation scheme that aims at improving the bandwidth utilization of the satellite links and the performance of the applications using those links. The last improvement area consists of prioritization mechanisms that have been added to our network models by using the WFQ queuing algorithm provided with OPNET.

2.3 Modifications to network configuration Unlike the original network configuration where each GT was allocated a fixed portion of the bandwidth, multiple GTs are now in contention to obtain bandwidth. We therefore need a way to share the total available bandwidth between multiple requesters. The intended satellites multiple access method being a combination of frequency division multiple access (FDMA) and time division multiple access (TDMA), we use the concept of a frame to represent a data burst, corresponding to a bandwidth allocation. A consequence of the first modification is the fact we cannot let IP control the transmission of the packets for it would use all the available bandwidth without respect to a GTs allocation. The transmission rate of a GT has to be controlled to transmit according to its frame allocation. Transmission control could have been done by modifying OPNETs IP or MAC implementation. But, considering the fact we already had to modify the ip_output_iface functionality for the bandwidth request/allocation mechanisms, we chose to implement transmission control in that process model also. The main advantage of this architecture is that it allows us to reuse OPNETs implementations of WFQ (segregation, queuing, prioritization) while the downside is that we must port our modifications to new versions of the ip_rte_v4 (the ip_output_iface child process creation has been modified) or ip_output_iface (which implements the queuing schemes) process models. The last modification to the network model is the addition of a node responsible for bandwidth allocation. This node, called the master controller (MC), allocates portions of the total available bandwidth (frames) to the GTs according to the bandwidth requests received. There is one MC per satellite beam that has satellite communication links to all GTs under that beam. Those links, used for the exchange of access

control information, are separate from the bandwidth available for data transfer. As the previous discussion shows, our solutions to the need for dynamic bandwidth management and prioritization are closely related. The next two sections will clarify the roles of our GT and MC nodes by explaining the modifications that have been done in the models and code in more details. 3. DYNAMIC BANDWIDTH ALLOCATION This section describes how dynamic bandwidth allocation has been implemented in our OPNET models. The bandwidth allocation scheme aims at improving the performance of the applications that use the satellite links and the bandwidth utilization (i.e. throughput) of those links. Our solution drives at this goal by allocating bandwidth as a function of the GTs needs, which are estimated according to the level and type of traffic they are experiencing. Compared to static allocation, this method has a major advantage that improves both bandwidth utilization of the satellite links and the performance of the applications. When sending a bandwidth request to the MC, a GT will provide information about the current size (i.e. number of packets) and weights of its queues. As we will see shortly, this information will determine the amount of bandwidth allocated to the GT. The functionality required to implement dynamic bandwidth allocation is divided in the two satellite communication nodes, as explained below. 3.1 Ground terminal functionality The dynamic bandwidth allocation is supported in a GT by a processor called satellite medium access controller (SatMAC). The SatMAC is responsible of handling the transmission of packets on the satellite link and requesting/receiving bandwidth allocations from the MC. Link layer characteristics, such as modulation and burst time plans, are not taken into account Also, to simplify our model, the reception of data packets from the other GTs is performed directly by IP since the SatMAC doesnt act on those packets. The SatMAC performs the following three functions: a) Transmit a packet: this action is triggered every frame by a self interrupt. The SatMAC transmits the maximum number of packets without exceeding the MCs allocation. The frequency of the self interrupts combined with the number of bits transmitted at an interrupt represents a frame, which is equal to the bandwidth allocation of the transmitting GT. We do not segment the IP packets, thus reducing processing time. In order to utilize all the bandwidth at transmission time, we send the required number of packets to utilize the frame size plus or minus a given constant. We then adjust the next frame size according to the over/underutilization. The packets are obtained by sending a request to WFQ (with the op_pk_send_forced function) asking for the next packet to send. A transmission delay is calculated using the capacity of the satellite link and the size of the 3

packets. The delay is used with the op_pk_send_delayed function. We will see in section 4 how the WFQ process model (i.e. ip_output_iface) has been modified to support this packet pulling functionality.

b) Send bandwidth request: this action is triggered by a self

interrupt scheduled every n frames (super-frame). This self interrupt is distinguished from the other one (i.e. transmit a packet) by an interrupt code. The SatMAC sends a packet (using the op_pk_send_forced function) to the WFQ process requesting queue information. The response received from WFQ is then transmitted on the satellite link to the MC. We will see in the next section what information is placed in that packet by WFQ.

c)

Receive bandwidth allocation: this action is triggered by a stream interrupt representing the arrival of a packet from the MC. The SatMAC retrieves the bandwidth allocation from the packet and updates a state variable with that new value.

3.2 Master controller functionality The MC is the central point of control for bandwidth allocation in a beam. It is responsible for receiving bandwidth requests from the GTs inside the beam and responding to those requests with bandwidth allocations. The MC performs the following functions:

a)

Receive bandwidth request: this action is triggered by a stream interrupt representing a bandwidth request from a GT. The MC stores the queue information contained in the packet (i.e. size and weight of each queue) in local variables. It will be used when calculating the bandwidth allocation. The MC also adds the total number of packets in the queues of the GT to a variable. At bandwidth allocation time, this variable will contain the total number of queued packets for all requesting GTs, allowing the MC to take into account the number of packets waiting for transmission in the beam when allocating bandwidth to a GT.

b) Calculate and send bandwidth allocation: this action is

triggered by a self interrupt scheduled every super-frame. The MC will allocate bandwidth to every requesting GT using the requests previously received. Looping through the list of requests, the MC will calculate a bandwidth allocation for each GT. The percentage of the total available bandwidth allocated to a GT will be equal to the percentage of packets belonging to that GT in the total number of packets (i.e. proportional allocation). At the time of this writing, queue weight is not taken into account by the allocation algorithm. 4. WEIGHTED-FAIR-QUEUING (WFQ)

This section describes how the WFQ queuing scheme is used in our network model and how it has been modified to support dynamic bandwidth allocation. WFQ allows the selection of rules to split incoming traffic in different queues and the assignment of weights to the queues that will influence the order in which packets are transmitted. Our client is using those functionalities in order to select the quality of service that should be offered to different users and/or applications. Also, WFQ is efficient in that it uses whatever bandwidth is available to forward traffic from lower priority queues if no traffic from higher priority is present and it ensures that queues dont starve for bandwidth. As explained in section 2, the satellites FTDMA MAC led us to implement packet transmission control in the ip_output_iface process model in order to allow the SatMAC to request packets when required (i.e. packet pulling). A consequence of this modification is that we needed to make sure the process models original packet pushing functionality remained unchanged, for it could be used by other nodes in the network. We therefore did two types of modifications to the ip_rte_v4 and ip_output_iface process models: section 4.1 presents the functionalities that have been added to the ip_output_iface process model in order to support the additional requirements of our network solution; section 4.2 presents the modifications made to the ip_rte_v4 and ip_output_iface original process models to allow interoperability between original and new functionalities. 4.1 Addition of new functionalities Three states have been added to the ip_output_iface process model (which we renamed to crc_output_iface) as shown in figure 2. A description of those states is presented next.

Figure 2.crc_output_iface process model

a)

init2 state: this blocking state has been added to the process model to establish a communication link between the SatMAC and WFQ. When the init2 state is reached, we are guaranteed that every module in the network have completed the enter executives of their init state. As a result, we can query the registry for the existence of a SatMAC in the node model. If one is found, the WFQ child process will be registered as the direct recipient of the output stream from the SatMAC node to the IP node with the op_intrpt_port_register function. This way, when the SatMAC generates a stream interrupt to the IP node in order to obtain information from IPs WFQ child process (i.e. queue information or a packet), the latter will be the recipient of that interrupt.

b) gt_info state: this non-blocking state has been added to

the process model to allow WFQ to respond to the SatMACs requests for queue information, which is used for bandwidth allocation. The gt_info state obtains the following information for each queue in WFQ: number of packets in the queue, sum of the packets sizes, and weight of the queue. This information is placed in a packet that is sent to the SatMAC with the op_pk_send_quiet function in response to the SatMACs op_pk_send_forced blocking call.

c)

gt_packet state: this non-blocking state has been added to the process model to allow WFQ to respond to the SatMACs requests for packets. The gt_packet state

obtains the next queue to be serviced with the Oms_Qm_Next_Queue_Select function and extracts the packet at the head of that queue. This packet is then sent to the SatMAC with the op_pk_send_quiet function in response to the SatMACs op_pk_send_forced blocking call. 4.2 Modifications to original functionalities This section presents the modifications made to the ip_rte_v4 and crc_output_iface process models to allow inter-operability between original and new functionalities. The only modification made to the IP model is the creation of the WFQ child process in the init_too state. The function responsible for creating the child process (i.e. ip_rte_wfq_information_process) has been modified to create a process called crc_output_iface (instead of ip_output_iface), which is the name of the modified version of WFQ described in this section. The two modifications made to WFQs original functionalities are described below.

queues. This transition is distinguished from the others by its indirect invocation mode (i.e. interprocess communication). SEND_PACKET: this other original ip_output_iface transition is triggered by a self interrupt transferring control to the extract state where a queued packet will be transmitted. It is distinguished from the other transitions for its the only self interrupt. INFO_TO_SATMAC: this new transition is triggered by a stream interrupt representing the arrival of a packet from the SatMAC requesting queue information. This transition has to be distinguished from the other new transition (PACKET_TO_SATMAC), which is also a stream interrupt from the SatMAC. The distinction is done with a request type (queue information or packet) placed in one of the packets fields by the SatMAC prior to sending the packet. PACKET_TO_SATMAC: this other new transition is also triggered by a stream interrupt representing the arrival of a packet from the SatMAC requesting a packet to be transmitted on the satellite link. As explained above a field in the packet distinguishes the two stream interrupts.

a)

enqueue state: the enqueue state has been modified in order to ensure packets bound for the SatMAC (i.e. to be transmitted on the satellite link) would not be transmitted by IP/WFQ as other packets bound for other output interfaces. The satellite transmissions have to be controlled by the SatMAC in order to conform to the FTDMA MAC and the GTs bandwidth allocation. Two particular events of the enqueue state have to be avoided for satellite bound packets; the transmission of the packet when all queues of the interface are empty, and the scheduling of a self interrupt that could also result in the transmission of a packet. A single modification to the enqueue states code allows the avoidance of these events since they are both nested in the same "if" statement. This "if" statement has therefore been modified to prevent the execution of the events when a packet has to be sent to the SatMAC, as shown below. Before modification:
if ((processor_busy [interface_index] == OPC_FALSE))

5. CONCLUSION We have presented a dynamic bandwidth allocation mechanism that aims at improving the performance of multimedia networks over satellite links. The WFQ queuing scheme is used in the network model to prioritize traffic, to provide information for bandwidth allocation, and to implement transmission control at a ground terminal. At the time of this writing, it is too early to present meaningful simulation results. The first stage of this task, which we are currently completing, was to obtain a communication framework for dynamic bandwidth management using WFQ state information. We chose to implement the proportional/centralized bandwidth allocation algorithm because of its simplicity. The work presented here will be extended further. First, WFQ queue weight will be taken into account for bandwidth allocation. This will allow us to run various simulations to evaluate the behavior of our performance enhancement solution. Next, we are planning to develop a distributed bandwidth allocation framework, which would be more reactive to network status changes by saving one RTT for the exchange of bandwidth allocation information. Finally, we will concentrate our efforts to the implementation and simulation of various bandwidth allocation algorithms in our centralized and distributed models.

After modification:
if ((processor_busy [interface_index] == OPC_FALSE) && (outstrm != outstrm_to_satmac))

b) idle state: the idle state has been modified in order to

allow transition to the new states presented in the previous section. There are now four possible transitions from the idle state: RECEIVE_PACKET: this original ip_output_iface transition is triggered by the reception of a packet from IP. Transition to the enqueue state is performed and the incoming packet is inserted in one of the

Acknowledgement This project was co-funded by the Canadian Department of National Defense and the Communications Research Center. References

[2]

Jing Peng, Improving TCP Performance over Long Delay Satellite Links, presented at OPNETWORK 2001, August 2731st Washington D.C. Claude Blisle, Peter Andreadis, Steve Bernier, Franois Lvesque, and Michel Barbeau, Bandwidth Allocation for IP Traffic Over Satellite Links, SSGRR 2000, July 31st - August 6th, 2000 - LAquila, Italy A. Iera, A. Molinaro, G. Aloi, S. Marano, Dynamic Channel Access Protocol in Geo-synchronous Satellite Networks, Proc. Wireless Communications and Networking Conference, pp 813817, September 2000

[3]

[1]

Peter Andreadis et al., Performance Analysis of Multimedia Networks over Satellite Links, presented at OPNETWORK 2001, August 27-31st Washington D.C.

[4]