Abstract

This paper presents an add-on Class of Service (CoS) layer for wireless mesh networks. The proposed protocol is applicable for contention-based MACs and is therefore compatible with most of the Wireless Local Area Network (WLAN) and Wireless Sensor Network (WSN) protocols. The protocol has a locally centralized control for managing data flows, which either reserve a fixed bandwidth or are weighted by fair scheduling. The protocol reduces transmission collisions, thus improving the overall throughput. IEEE 802.11 adhoc WLAN has been taken as a platform for simulations and prototyping for evaluating the protocol performance. Network Simulator Version 2 (NS2) simulations show that the CoS protocol efficiently differentiates bandwidth, supports bandwidth reservations, and reaches less than 10 ms transfer delay on IEEE 802.11b WLAN. Testing with a full prototype implementation verified the performance of the protocol.

1. Introduction

A wireless mesh network consist even thousands of devices communicating with multihop routing. Examples of wireless mesh technologies are Wireless LANs (WLANs) and Wireless Sensor Networks (WSNs). Compared to WSNs, WLAN has typically higher capacity and comprises more powerful devices such as laptops and cell phones. A WSN consists of small, low cost, and autonomic devices combining environmental sensing, data processing, and wireless communication. Unlike the traditional computer networks, a WSN is application-oriented and deployed for a specific task e.g. monitoring a physical phenomenon, object tracking, or control purposes. The WSN application space ranges from home and industrial automation to military uses. WSN nodes are typically deployed without planning in large quantities, necessitating self-configurability and distributed operation.

In general, the wireless networking offers easy deployment and mobility but has limited capacity due to constraints in radio frequency bands. Still, bandwidth is needed e.g. for file transfer and video conferencing in WLANs or the retrieval of surveillance images in multimedia WSNs [1]. As several devices share the common wireless medium, a network may congest causing rapidly increasing and varying transfer delays. The network congestion is prone to occur, when multiple users or devices are utilizing the wireless medium such as in open access WLANs or dense WSNs. Thus, Quality of Service (QoS) guarantees are required to ensure sufficient bandwidth and delays for each application.

Varying QoS requirements necessitates traffic differentiation to ensure that the important traffic is preferred when a network congests. Lower priority traffic should receive least bandwidth while higher priority traffic should get low channel access delays. Also, to prevent service degradation, a certain bandwidth should be guaranteed for constant bit rate applications such as voice and video.

The wireless medium can be shared with contention-based or contention-free approaches. The contention based approach, such as Carrier Sense Multiple Access (CSMA), has low overhead and divides bandwidth on-demand basis. However, as the offered load increases, additional methods are required to coordinate transmissions to avoid capacity loss due to collisions. Contention-free channel access eliminates collisions by assigning dedicated (reserved) communication times for a device but requires coordination between devices thus introducing additional overhead. As adjusting reservations to varying traffic requirements is complex, the majority of the popular WLANs and WSNs use CSMA based approaches or reservations are optional extensions for CSMA.

This paper presents the design, implementation, and performance evaluation of a Class of Service (CoS) support layer for wireless mesh networks referred to as Class of Service Protocol (CoSPro). CoS is an approach for delivering QoS by dividing traffic into several classes and providing differentiated service for each class. The key principle is to elect a controller device to manage traffic and grant other devices within its vicinity permissions to access medium.

Bandwidth reservation and traffic differentiation algorithms are individually well researched in the literature. However, in the existing protocols and research proposals, the coexistence of these methods requires a specific Medium Access Control (MAC) protocol. This paper presents a novel per flow QoS model that provides both bandwidth guarantees with reservations and priority based traffic differentiation. CoSPro assumes only contention-based channel access and is compatible with wide range of existing networks such as IEEE 802.11 WLAN and IEEE 802.15.4 Low Rate Wireless Personal Area Network (LR-WPAN).

The overhead of the protocol is reduced by avoiding signaling on lightly loaded network when contentionbased channel access is sufficient to guarantee acceptable performance. Thus, CoSPro achieves substantially lower delays than traditional polling protocols. Unlike traditional resource reservation protocols, unused reservations are not wasted in CoSPro as the bandwidth control algorithm assigns unused capacity to the priority based traffic flows. The feasibility of the protocol is verified with simulations and an implementation on IEEE 802.11 WLAN. IEEE 802.11 is used as an example of throughput oriented ad-hoc network technology. The results are generalizable to other contention-based MAC protocols and multimedia WSNs utilizing bandwidth critical applications.

The paper is organized as follows. Section 2 presents the related research proposals. Section 3 describes the design of CoSPro. Section 4 provides the protocol performance evaluation and simulation results. Section 5 presents the implemented prototype and gives the measurement results and Section 6 concludes the paper.

2. Related Work

This section discusses the relation and applicability of CoSPro to the popular wireless WLAN and WSN standards and the related wireless QoS proposals. As CoSPro is a MAC layer enhancement, only the standards that define channel access are considered. In the related QoS proposals, proprietary QoS proposals that define completely new MAC or routing layers are not listed due to incompatibility with the existing standards.

2.1. Wireless MAC Standards

IEEE 802.11 is the most widely utilized WLAN standard that provides the nominal data rates of 11 Mbit/s, 54 Mbit/s, and 150 Mbit/s with 802.11b, 802.11a/802.11g, and 802.11n extensions. The 802.11n standard can achieve even 600 Mbit/s data rate by multiplexing spatially up to four data streams. The standard defines two topologies, infrastructure and ad-hoc. In the ad-hoc topology, stations communicate directly with each other under the Distributed Coordination Function (DCF). In the infrastructure mode, stations communicate through an Access Point (AP) under DCF or with an optional Point Coordination Function (PCF) that provides contention-free communication via reservations. A common MAC protocol based on Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) is utilized on top of the heterogeneous radio layer. The probability of collisions is reduced by carrier sensing and waiting a predetermined Inter-Frame Space (IFS) and a randomized backoff period before the transmission of a frame. Also, an optional Request to Send/Clear to Send (RTS/CTS) procedure can be used to avoid collisions due to hidden node problem [2]. However, the RTS/CTS handshake before each transmission causes additional sending delays and introduces a relatively large overhead when the size of a data payload is small.

IEEE 802.11e extension defines QoS support for 802.11 MAC by introducing two new communication modes: Enhanced Distributed Channel Access (EDCA) and Hybrid Coordination Function (HCF). EDCA is an extension to DCF, while HCF is used in the infrastructure mode. Traffic differentiation is realized by defining up to 8 traffic categories (TC) per station. A traffic category is associated with certain CW and IFS settings, in which lower values increase the likelihood for channel access and thus better throughput and lower delays. Similarly to the PCF, HCF allows stations to request resources and thus gain a reserved throughput.

The performance of IEEE 802.11e has been extensively studied. Although studies have shown that 802.11e provides relatively good service differentiation [3,4], the standard has also shortcomings. While the QoS provided by EDCA have been found notably better than besteffort, it does not have real QoS guarantees [5,6]. Also, the adjustment of CW and IFS sizes is problematic [7]. With CW, high-priority traffic susceptible to degradation when heavy low-priority exists. IFS size adjustment has been found to provide more efficient service differentiation, but it tends to starve lower priority traffic.

IEEE 802.11s is draft amendment for mesh networking. It specifies a mesh routing protocol and a new coordination function that allows reservations without a centrally coordination device. The reservation method is based on scheduled channel usage. A source device negotiates either a periodic or one-time dedicated channel access time with the destination device. During the negotiation, the destination exposes the reservation schedules of its neighbors, which allows finding a non-conflicting communication time [8]. The priority in which reservations are granted is based on the IEEE 802.11e and shares its benefits and problems.

Unlike WLANs, WSNs do not have a dominating standard as resource constrained hardware necessitates a trade-off between energy, complexity, and performance thus denying a fit-for-all protocol. IEEE 802.15.4 LRWPAN, WirelessHART, and ISA 100.11a are the three most prominent standards defining WSN MAC. In addition to these standards, the use of proprietary, deployment specific techniques is popular.

IEEE 802.15.4 uses CSMA/CA approach that is similar to the 802.11. A high-band physical layer operating in the 2.4 GHz band uses 250 kbit/s nominal data rate, while the nominal data-rates in 868 MHz and 915 MHz bands are 20 kbit/s or 40 kbit/s, respectively. IEEE 802.15.4 network supports three types of network devices: a Personal Area Network (PAN) coordinator, coordinators, and devices. The PAN coordinator initiates the network and operates often as a gateway to other networks. Coordinators collaborate with each other for data routing and network self-organization. Devices do not have data routing capability and can communicate only with coordinators. An optional low duty cycle operation allows nodes to save energy as the transceiver is active only part of the time. To reduce complexity, RTS/CTS procedure is not supported and backoff period is not increased upon collisions, which increases the probability of collisions and therefore decreases performance. IEEE 802.15.4 allows contention-free slots but does not otherwise support QoS.

WirelessHART and ISA 100.11a define a whole protocol stack including application profiles, routing and transport, and MAC. WirelessHART builds on top of the IEEE 802.15.4 physical layer but defines own MAC protocol. WirelessHART guarantees certain capacity and latency by globally scheduling transmission times for flow on each device. While the approach is acceptable for industrial applications in which reliability is the main concern and network is static and predictable, the approach is too inflexible for generic networks as it requires global knowledge of the traffic patterns. ISA 100.11a reuses IEEE 802.15.4 MAC and physical layers, but adds channel hopping and blacklisting. The network and transport layers in ISA 100.11a are IPv6 based and support various transport services, such as best-effort and real-time.

In WSNs, the scope of the CoSPro differs from Wireless HART and ISA 100.11a that are targeted at industrial, low-traffic networks. CoSPro is targeted at higher rate multimedia WSNs where network congestion is a problem.

CoSPro is compatible with IEEE 802.11 and 802.15.4 standards and solves several of their shortcomings. Differentiated traffic flows can utilize unused reservations, unlike in 802.11/802.15.4 standards where the unused reservations waste capacity. In addition, the CoSPro traffic control limits competition on air interface, and thus prevents performance drop caused by collisions typically seen in these protocols [9–11].

2.2. Wireless QoS Proposals

Several protocols and methods have been introduced for providing QoS over the Internet Protocol (IP). Popular choices are Resource Reservation Protocol (RSVP) and Differentiated Services (DiffServ) defined by the Internet Engineering Task Force (IETF). RSVP uses resource reservation, while DiffServ offers CoS by utilizing the IP header Type of Service (TOS) field and defining a basic set of rules for differentiating packet forwarding in the routers. DiffServ and RSVP can be used in conjunction of other protocols. For example, the IETF defined Multi-Protocol Label Switching (MPLS) has a support for DiffServ. MPLS makes network management easier for QoS by creating a specific path for a sequence of packets. Also, Subnet Bandwidth Manager (SBM) is a RSVP based admission control protocol targeted for IEEE 802-style LANs. The IP-based methods are complementary to the CoSPro, as they ensure end-to-end QoS and can utilize CoSPro to manage per-hop service.

Several modifications for providing CoS for WLAN have been proposed in research papers. Most of these concentrate on improving the WLAN MAC protocol. The proposed modifications often utilize the changing of the size of the contention window or backoff interval of the CSMA-algorithm [12,13]. Another method is to change the length of the IFS. Since a shorter IFS gives a higher priority access, some proposals present an enhanced service support by changing the type or size of IFS [14,15]. While the concepts of these methods can be used with both DCF and PCF, few modifications concentrate solely on PCF [16,17]. As the IEEE 802.15.4 channel access is conceptually similar to the 802.11 WLAN, similar backoff and IFS based QoS have been proposed [10,18,19]. Other related methods for achieving CoS on wireless networks include reservation based protocols [20], enhanced support and adaptation of a particular higher layer protocol (mainly UDP and TCP) [21,22], and admission control [23].

The protocol presented in [23] estimates available bandwidth and prevents congestion with admission control for real-time flows and rate control for non-real time flows. In the protocol, the bandwidth usage estimation is a critical issue and the protocol needs to be integrated with MAC to get the extensive channel usage information.

A number of research articles address the performance problems encountered in the IEEE 802.11 and 802.15.4 channel access. Performance can be enhanced by adapting to the channel in order to compensate channel errors [24,25], by tuning the CSMA algorithm to improve throughput [26], or by avoiding hidden node collisions in multihop networks [27]. However, these MAC layer proposals do not usually provide differentiated QoS.

A problem with the MAC layer research proposals for QoS is the guaranteeing of a certain bandwidth for a single flow. The bandwidth reservation can be provided by a network layer solution, but all traffic belonging to the bandwidth reserved with such method must still contend with other traffic on the link layer. The limited capacity and varying radio environment in wireless networks demand constraining offered load [28,29].

Unlike most of the related proposals, CoSPro provides both bandwidth control according to the application requirements and solves the performance degradation seen in IEEE 802.11 and 802.15.4 with a high number of devices. CoSPro can be implemented without modifying the underlying MAC layer. Also, the bandwidth control supports both bandwidth reservation and traffic classification.

3. CoSPro Design

The lack of QoS is generally not a problem if network is lightly loaded, as all devices get desired bandwidth and buffering delays remain small. The design of CoSPro relies on this fact by controlling bandwidth usage to prevent network congestion and thus performance problems. Minimizing control overhead is another key factor in the design; control messaging is relaxed when the network is not congested.

CoSPro uses locally centralized approach to control traffic in one-hop radius. The design extends to mesh networks, where separate parts of the network are controlled independently. In mesh networks, nodes make forwarding decisions independently resulting into a selfconfiguring and self-healing multi-hop topology. With CoSPro, each mesh node belongs to a certain local traffic control area managed by a controller device. The controlled devices are referred to as end devices. Data transfer can take place between the controller and end devices or directly between end devices. In mesh networks, a controller manages traffic in a virtual cluster of devices as shown in Figure 1. The clustering algorithm should minimize the number of clusters by selecting one controller within communication range. Suboptimal clustering (several or no controllers for an end device) lowers performance but does not prevent device operation, as CoSPro is built on top of a contention-based channel access that will work regardless of the existence of a CoSPro controller. Defining the clustering algorithm is outside the scope of this paper, but examples of suitable algorithms are presented in [30] and [31]. CoSPro can be applied directly to clustered networks, such as in IEEE

802.15.4 operating in cluster-tree mode. In these networks, cluster heads forward traffic from their child nodes. This way, a child node saves energy as its transceiver can be turned off most of the time.

CoSPro controls traffic per hop basis and can thus be realized either on the mesh routing or MAC layer as shown in Figure 2. The implementation on MAC layer decreases overhead as messages and status information can be piggybacked to existing Protocol Data Units (PDUs), but may not be feasible e.g. when MAC protocol is hardware implemented. An application can utilize CoSPro directly through an Application Programming Interface (API), in which case application packets are fitted into a CoSPro PDU, or indirectly by differentiating traffic based on its contents (e.g. TOS field). In the latter case, traffic is controlled by predefined rule sets and CoSPro is transparent to applications, allowing e.g. the use of IP protocols with the IPv6 over Low power WPANs (6LoWPAN) technique. With 6LoWPAN, CoSPro is implemented on mesh routing layer (mesh under) instead of IP layer (route over). The protocol analysis and implementation in this paper assume the routing layer and the API approaches.

The functional model of the CoSPro end device is presented in Figure 3. The CoSPro classifier prepares application data for sending and puts data to transmission queue according to its traffic class. The local scheduler retrieves packets from queue according to the flow settings. The phases in sending of a PDU are managed by the CoSPro control, which communicates with the controller device. The CoSPro control also allows an application to set flow priorities and ask for bandwidth reservations. The received data is passed transparently to the application.

The model of the controller device is presented in Figure 4. The network scheduler is used for handling differentiated traffic and the reservation table holds reserved flow information. CoSPro uses the medium adaptation to provide information about the usage of the medium and its capabilities, such as data rate. The usage of the medium affects the decision to enter or leave the congestion mode, whereas reservations utilize knowledge of the available data rates. A configuration for limiting allocations and the value of the congestion threshold is determined by the policy control.

3.1. Traffic Management

The goal of the CoSPro traffic management is a versatile traffic differentiation while assuming only simplest of contention based channel access protocols. Both prioritized channel access and bandwidth guarantees are supported, and applications using different types of traffic can coexist seamlessly in a network.

CoSPro manages traffic in data flows. Each end device can originate or terminate one or more flows. A flow uses one of the two modes provided by CoSPro, which are the reserved bandwidth mode and differentiated bandwidth mode. The modes define how the available bandwidth is divided between active devices. Both reserved and differentiated mode flows coexist in the network. The reserved bandwidth mode allocates a fixed bandwidth for a flow and is thus suitable for satisfying flows with strict bandwidth requirements. CoSPro uses the remaining capacity for the differentiated bandwidth mode traffic, which provides controllable bandwidth division according to traffic classes. A controller manages flows only in one-hop radius. For multi-hop reservations, CoSPro can be used with conjunction of end-to-end bandwidth reservations protocols such as RSVP.

The CoSPro controller keeps record of average bandwidth usage in the network by receiving periodic channel usage updates from active devices. A device that has not transmitted traffic does not need to send updates. An end device can send freely with the differentiated mode as long as the used bandwidth remains under a network specific congestion threshold. When the threshold is exceeded, CoSPro considers the network to be congested and the devices must request a permission to send differentiated mode flows. The use of congestion threshold significantly reduces signaling overhead on lightly loaded network, since there is no need to exchange request and grant signals.

The QoS states used in a CoSPro end device is depicted in Figure 5. An end device changes its congestion state upon receiving an indication from the controller. All flows in a device share the congestion state. A flow is initially in the differentiated bandwidth mode, but enters the reserved bandwidth mode when the end device containing the flow requests and receives a reservation

update from the controller device. The flow is set back to differentiated mode, if the reservation is dropped.

3.2. Traffic Classes

Traffic class is a mean to define and provide support for different traffic types. For ease of configurability, a traffic class must be defined in an understandable manner. For example, the level of service in 802.11e defined traffic classes (background, best-effort, video, and voice) related to each other is not obvious. Adjusting the traffic classes for the exact level of service requires experimenting with different values. The definition of CoSPro traffic class allows predictable and easily configurable level of service: bandwidth is divided fairly based on defined weights (priorities).

A CoSPro traffic class is consists of priority and aging time parameters. Each flow is assigned with a traffic class that can be negotiated between controller and an end device. For example, in the prototype implementation, an end device defines the used traffic class by sending the parameters during an initial handshake procedure with the controller. The aging time defines the maximum transfer time for a PDU. After the aging time has elapsed, a queued packet is discarded as obsolete. The interpretation of the priority parameter differs slightly between the reserved and differentiated bandwidth modes. In the reserved traffic mode, priority indicates whether the controller device should accept or reject a new allocation request. In the differentiated mode, the priority parameter defines how the bandwidth is di-

vided among traffic flows. Also, low priority reservations can be dropped if differentiated traffic contains a lot of high priority flows.

3.3. Reserved Bandwidth Algorithm

In the reserved bandwidth mode, controller grants a portion of total capacity for a flow. The reserved bandwidth mode relies on the fact that contention based MAC protocols support strict QoS requirements, when offered traffic load is controlled and not near the maximum capacity [32]. Therefore, by ensuring that used bandwidth does not exceed the maximum capacity, collisions are rare and each flow gets statistical throughput and delay guarantees.

A device reserves bandwidth by sending a request containing minimum required and preferred bandwidth to the controller. Controller assigns each reserved flow at least the minimum requested bandwidth. If the requested bandwidth exceeds available capacity, lowest priority flows are dropped. Surplus bandwidth is assigned first to the higher priority flows. Controller may redefine or cancel the reservation to enable admission for a higher priority flow. The local scheduler of an end device limits traffic to the negotiated bandwidth by delaying the retrieval of next packet for a flow, thus limiting the number of reserved flows accessing air interface simultaneously.

3.4. Differentiated Bandwidth Algorithm

In the differentiated bandwidth mode, an end device requests the controller for permission to send data. This is a common approach in polling mechanisms that has the main drawback of increased overhead and latency [33]. CoSPro introduces several methods to improve the polling efficiency. First, polling is used only when the network is congested. Second, a node may send several packets when it gets the permission, which reduces the per packet overhead. Third, instead of assigning each device a transmission opportunity periodically [34], CoSPro grants transmission periods dynamically based on the knowledge of flow activity and queued frames. Therefore, CoSPro is able to control latency and bandwidth.

The differentiated bandwidth mode uses a weighted fairness algorithm, in which the flows are given bandwidth in proportion to their weight. In CoSPro, a priority parameter p_i is used as the weight of a flow f_i. A flow f_i gets an average bandwidth of b_i as

, (1)

where N is the amount of active flows and B_diff is the bandwidth available to differentiated mode flows. The adjustment of priority is intuitive, for example a class with priority of four receives twice as much bandwidth as class with priority of two. The value for B_diff is calculated as

, (2)

where B_total is the total available bandwidth and r_i is the actual bandwidth utilized by reserved mode flow f_i.

A device signals the status of its local queue within a transmission request containing information about each active flow. The controller queues the requests, uses the network scheduler to determine the next request, and sends an allowed transmit indication to an appropriate device. The indication contains the allowed traffic class, the length of the transmission period, and a limit to the sending bandwidth. The bandwidth limit is determined by (2). Thus, the limit ensures that enough capacity is available for reserved flows, but also utilizes bandwidth that is unused by reserved flows. Consequently, a differentiated mode flow can send data without bandwidth limitations when reservations do not exist.

A device stops sending, when the transmission period length is reached. Next, the device sends end transmission indication to the controller, which contains the same information than traffic request. The message denotes that the device has completed sending during this period and eliminates the need to update the flow status with a new traffic request message. The controller may interrupt an active device with deny transmit indication, if the controller has a request that must be scheduled immediately. If the controller does not receive end indication, it schedules next request after the transmission period has ended.

3.5. Differentiated Mode Scheduling Algorithm

This section presents one possible algorithm for providing bandwidth differentiation as shown in (1). The algorithm realizes bandwidth allocation by scheduling transmission opportunities based on the flow priority values, requests sent by the devices, and the amount of successfully transmitted traffic. The use of transmitted traffic ensures that bandwidth differentiation is fair between flows using different packet sizes and devices having differrent packet error rates. For example, a device experiencing high packet error rate can still get more bandwidth than lower priority flows from devices having a better link. The use of an algorithm that considers aging time as a scheduling deadline could improve real-time scheduling for traffic with same priorities [35,36]. However, it would not provide differences in bandwidths, which is the approach taken in CoSPro.

The scheduler in the CoSPro controller device has a list of active flows F. A flow f is marked active after a traffic request concerning it is received. Each request contains the number of PDUs waiting for sending at the end device, denoted as c, and the average size of waiting PDUs, denoted as a. The scheduler selects one of the active flows and gives it a permission to send PDUs for the duration of d. A flow is marked inactive after it is scheduled.

For the scheduling decision, the scheduler keeps a record of received traffic from each flow, denoted as t_i. The scheduled flow is selected by weighting the amount of received traffic by the priority of the flow. The weighted traffic value w_i is derived as

w_i = t_i / p_i.                 (3)

The flow f_i that has the smallest weighted traffic value w_i is selected. If there are several flows having the same weight, the one with the highest priority is selected. The purpose of the selection is to keep the traffic weights equal. As the weights are equal, the transferred traffic and therefore the obtained bandwidth are proportional to the priority values as (1) requires. For ensuring that the w_i calculation is not distorted by different device activities, the scheduler reduces the recorded received traffic counters (t_i) periodically. Otherwise, the devices that have not sent for a long time would get more bandwidth than defined.

After the flow has been selected, the scheduler determines the time the device is allowed to send PDUs belonging to the flow. This is done by calculating the length of the transmission period d. First, the amount of PDUs is determined, denoted as n. Then, n is converted to a particular transmission period length d.

If F contains only one flow, the n is set directly to the value c_i contained in the request. Otherwise, the n is calculated as

, (4)

where w_k corresponds to flow f_k, which is the flow with the second smallest weighted traffic value in F. By comparing the two smallest weighted traffic values, the scheduler can allocate the length of the transmission period for the selected flow before the other flows (from which the traffic requests has been received at the moment) need to be scheduled for transmission. In (4), the actual number of bytes to be sent is derived by multiplying the subtracted weighted traffic values with priority pi. The amount of bytes is converted to the number of PDUs by dividing it with the average PDU size a_i. Taking the minimum prevents any larger n value than the device has requested.

Finally, the length of the transmission period is calculated from the PDU count with the average PDU size and the known network bandwidth b as

d= na_i / b. (5)

The scheduler has two configurable parameters for controlling the average sending durations: D_min and D_max. The d is assigned within these limits. The limits affect to the overall CoSPro trade-off between transfer delay and throughput. The purpose of the D_min parameter is to improve throughput by ensuring that several PDUs can be sent during a transmission period. The D_max is used to control the delay that a flow experiences while waiting for a transmission period to be reserved.

4. Performance Analysis

The performance is analyzed when CoSPro is implemented on top of the IEEE 802.11 MAC operating under DCF. The DCF mode was chosen because the proposed centralized control architecture of CoSPro would be interfered by PCF.

4.1. Throughput Analysis

The throughput of CoSPro using differentiated mode is compared to the standard 802.11 with and without the RTS/CTS procedure. CoSPro reserved mode does not include additional messaging and has throughput similar to the standard WLAN. The values are calculated by assuming IEEE 802.11b having 11 Mb/s basic data rate with direct sequence spread spectrum. The overhead caused by IFS sizes, backoff times, and acknowledgements for WLAN MAC PDUs have been accounted in the calculations. The calculated bandwidth presents the best-case throughput for a single device, since the effect of collisions, bit-errors, and retransmissions is ignored. CoSPro overhead includes also transmission requests, allow transmit, and the end of transmission indications.

The calculated throughputs are shown in Figure 6. The frame overhead and acknowledgements cause considerable throughput penalty with frames having a small payload. The throughput penalty of CoSPro differentiated flows depends on the length of the transmission period. Differentiated mode flows shows better results than the standard WLAN with RTS/CTS, when the transmission period length exceeds 10 ms. Compared to the standard WLAN with 1500 B payload, CoSPro has 4.5% lower throughput with 50 ms transmission period when RTS/CTS is not used and 17% higher throughput when RTS/CTS is used. In addition, CoSPro has a good throughput with a small frame payload, because it allows more frames to be sent within a single transmission period. As the transmission period length is increased, the throughput of CoSPro approaches the standard WLAN values. Because the length of the transmission period is controlled with D_min and D_max scheduler parameters, the overhead penalty can be adjusted to an acceptable range. In general, longer transmission periods reduce the overhead.

4.2. Delay Analysis

The delivery delay for a PDU contains the time required to transfer it between MAC layer entities and the time it waits for scheduling. The delay can be evaluated by calculating the time an arbitrary flow k must wait for scheduling. Let t_k denote the amount of data belonging to the kth flow. Before sending the kth flow again, the device must wait until equal amount of data has been transferred via other flows. The amount of data is determined by the priority values and can be obtained from (1) and (3) as

, (6)

where t_i is the traffic that must be transferred via any other ith flow before the device can sent to the kth flow again. The value of t_i can be converted to time d_i as

, (7)

where d_k denotes the time taken to send traffic t_k. It is easily seen that a long transmission period for the kth flow increases the transmission periods of the other flows as well. Since a flow must wait for other flows to finish, the use of long transmission periods increases delays. Also, it should be noted that (7) does not include the time caused by the MAC layer overhead or the CoSPro signaling. For equal sized PDUs, the delay will be divided in the fraction of the flow priorities similarly to the bandwidth.

4.3. Simulated Performance

CoSPro performance was verified with the Network Simulator (NS) version 2 [37] and compared to IEEE 802.11 EDCA [38]. CoSPro was implemented in NS as a new protocol layer, which was located on top of the simulated 802.11 MAC layer. The simulation settings used 11 Mb/s physical link rate and did not include the generation of packet losses, RTS/CTS signaling, or fragmentation.

The simulation measured traffic differentiation and the effect of competition in air interface, by increasing the number of active devices. Each device utilized three flows with real-time, background, and best-effort priorities. Real-time flow was presented typical voice traffic, while

flows.

background and best-effort flows presented typical data traffic. The offered throughput and simulation settings with CoSPro and IEEE 802.11 EDCA are presented in Table 1. The 802.11 EDCA access categories determine IFS and backoff values and are the same as defined in IEEE 802.11e standard. Video access category was used for real-time traffic, because voice access category performed poorly in EDCA when the number of devices was increased.

Figure 7 presents the average throughput of traffic flows. After 6 active devices, network capacity is exceeded and the throughputs of low priority flows decrease. CoSPro provides better throughput for real-time traffic when the number of active devices increases. The performance drop with 802.11 EDCA is caused by the increased number of collisions, whereas CoSPro limits the number of sending devices thus reducing the competition. In 802.11 EDCA, higher priority traffic causes starvation to the lower priority traffic. CoSPro does not have this problem. Instead, the aggregate throughputs of best-effort and background traffic in CoSPro converge with 24 active devices because of used minimum scheduler time D_min, which prevents low priority traffic from starving. As the competition over air interface increases, 802.11 EDCA real-time traffic drops, while CoSPro is able to provide real-time traffic flow sufficient throughput without notable performance drop.

End-to-end packet delays with CoSPro and 802.11 EDCA with 6 active devices are shown in Figure 8. 802.11 EDCA real-time traffic has the smallest delays due to its small IFS and backoff values. As the CoSPro uses the legacy 802.11 IFS and backoff values that are

slightly higher than EDCA real-time values, the CoSPro real-time traffic has slightly higher delays. However, the delays are still low enough for the flows to be used for multimedia traffic.

5. Prototype Implementation

The prototype implementation places CoSPro between the application and WLAN link protocol layers, as presented in Figure 9. The prototype consists of the controller and end device software modules that implement CoSPro functionality. In the implemented prototype, CoSPro also operates on top of the User Datagram Protocol/Internet Protocol (UDP/IP) layers. The prototype was built on that layer in order to enable testing with different existing network cards and drivers. Although UDP/IP increases overhead, the layers are otherwise transparent and do not affect the operation of the prototype, since the layers do not employ flow control or acknowledgements.

The prototype architecture is the same for both the end device and the controller device except for the control part. An application data packet is fitted inside CoSPro PDU in the PDU construction function. A CoSPro PDU contains the identification of the used traffic class and the information needed to separate CoSPro control and application data in the PDU classification part of the protocol. The PDU is queued until the local scheduler selects it and sends it by using the lower protocol layers. The local scheduler is controlled by the send control part of CoSPro. The send control communicates in the congestion mode with the network scheduler, which is located at the controller device. The protocol control provides retransmissions for the CoSPro control messages.

The CoSPro modules were implemented as Microsoft Windows 32-bit executables. The executable programs utilized Windows Sockets 2 application programming interface (WinSock2) for networking. The prototype used common PC hardware with Avaya Wireless PC Card, Nokia C110/C111 and Nokia D211 WLAN cards meeting the IEEE 802.11b standard.

6. Prototype Measurements

The measurements were carried out using the implemented prototype. The end devices were located around a central device, which was also the CoSPro controller device. The distances between the devices were less than ten meters, as the purpose was to provide similar link conditions to all devices and to minimize the near-far effect. The central device was used to receive all data sent by the other devices. The results obtained with CoSPro were compared to the standard WLAN. In the standard WLAN tests, devices sent data also to the central device, but the CoSPro software modules were not used.

The measurements utilized the 11 Mbit/s nominal bandwidth of IEEE 802.11b. Each measurement used the packet size of 1400 B, which was selected to minimize the header overhead and to avoid IP datagram fragmentation. In the used WLAN cards, the RTS/CTS procedure and fragmentation were disabled, and the number of transmission retry limit was set to four. Also, the default values were used for other MAC parameters.

6.1. Performance of Priority Scheduling

The priority scheduling test evaluated the performance of the CoSPro scheduling algorithm. The test used four devices utilizing priority values of 2, 4, 6, and 8. Each device started sending at 700 kbit/s and increased the offered throughput to 2.7 Mbit/s during the test.

Figure 10 presents the measured throughput with CoSPro. The CoSPro congestion threshold is exceeded when a device sends more than 1.0 Mbit/s, which totals to more than 4 Mbit/s network load. As a result of the protocol, the devices with higher priorities get better throughput with the expense of lower priorities. The device having the lowest priority traffic carries the penalty