SIMULATION RESULTS | Capacity Planning and Design

The average-based design models lead us to much smaller estimates of required capacity. Therefore, they run the risk of not being able to guarantee acceptable performance for many real-time applications such as voice or video where jitter must also be taken into account. We currently do not have design models that can take jitter into account so we need to evaluate whether the jitter remains acceptable in a system designed with an average delay method.

In this section, we present simulation results to study the delays encountered by the individual voice and video sources under various provisioning scenarios and compare them with the required delays for voice and video, respectively. We used ns-2 to conduct simulations. In this section, we only consider AF subclasses where multiple sources send packets to each subclass, and packets of each subclass are served in the order of their arrival while sharing bandwidth between the subclasses using PDD scheduling. The simulation model for AF class is shown in Figure 1. We simulate a voice source using a two state on–off model where it generates packets with a deterministic inter-arrival time of 15 ms in the on-state. On-periods are exponential with rate 2.5 and off-periods are also exponential with a rate 1.67. Each packet is of size 120 bytes. The video source is modeled using deterministic batch arrivals with batch inter-arrival time of 33 ms. The number of packets in a batch are geometrically distributed with an average of five packets. In each burst, the last packet has size distributed as uniform (0,1000) bytes. All other packets have 1000 bytes.

 
Figure 1: Simulation model for AF class.

Here also c_LB/r, c_OO/r, and c_P/r refer to overprovisioning required when, dimensioning for average delays using LB based model, using on–off-based model and Poisson-based model, respectively. Observe that the capacity computed using these models along with PDD-based scheduling for single, five, and ten voice and video sources. Now we use that capacity for the simulation and compare in Figures 2 through 7 the delays for single, five, and ten voice and video sources. We have plotted the observed mean delay and error bars corresponding to twice the sample standard deviation for voice and video sources. We also present a horizontal line showing the required average delay for each source.

 
Figure 2: Delay for single voice source.

 
Figure 3: Delay for single video source.

 
Figure 4: Delay for five voice source.

 
Figure 5: Delay for five video source.

 
Figure 5: Delay for ten voice source.

 
Figure 6: Delay for ten video source.

Note that for the Poisson-based capacity model with single sources, the actual mean delay is many times the target delay, both for voice and video. Moreover, some voice packets can have a delay as high as 400 ms and will be useless at the receiver. For video also, packets can have delays as much as 1 s. Such a capacity planning is not very useful and could lead to unsatisfied customers. When we multiplex five or ten voice and video sources, the average delays get closer to the target delays and for ten sources, they are even acceptable for both voice and video. However, there is still a large variance in the observed delays and voice packets could still have as high as 40 ms and video as high as 100 ms. Note that such high delays could be tolerable if they affect only a small number of packets.

Next, we consider on–off and LB-based design models. Observe that both the approaches provide acceptable delays, average as well as average along with two times standard deviation. The values are smaller than the required delays and hence a significant fraction of packets belonging to voice and video sources will encounter less than required delays. These models remain consistent for single, five, or ten sources and provide acceptable, performance to individual sources. Note that the LB-based model provides delays which are less than the target for both voice and video, although it requires lesser capacity than the on–off-based models. Observe that not only the delays are acceptable but also the variance is quite small.

Based on these results, it can be argued that LB-based model could be used to determine required capacity for a source requesting an average delay QoS. When allocating capacity for a small number of sources, it can achieve the multiplexing gain and provides minimal capacity to meet the required delays.

IP TRANSPORT ARCHITECTURE

Next, we present the architectural details for the IP transport link between the BS and the GW. Presence of multiple service classes with different QoS requirements running on a native IP link with constrained capacity necessitates prioritization and scheduling among the arriving packets. Internet Engineering Task Force (IETF) has standardized the differentiated services architecture (DiffServ) for large-scale deployment of IP networks with QoS support. They have provided three types of service to packets: expedited forwarding (EF), assured forwarding (AF), and best effort. The applications requiring absolute delay bound are mapped to EF class. For providing the average delay bound, we use the AF class. We propose to use the proportional delay differentiation (PDD) model of Dovrolis et al. for providing different delays to the subclasses within the AF class. The PDD-based approach is unique in its simplicity and tractability. Recently, many real-time applications have been successfully mapped to delay and loss differentiation parameters of the PDD subclasses.

Next, we discuss the architectural details of a forwarding interface of the BS. For this purpose and toward discussions in later sections, consider multiple sources which want to send their traffic from BS (A) to GW (B) connected by a direct link ℓ.

Consider now the BS (A) and GW (B) routers. Assume that the concerned forwarding interface on BS A to GW B has been configured for n EF subclasses and m AF subclasses. At the interface, each source is mapped to EF or AF class based on whether the class requires absolute or average delay. The mapping to subclass (such as i) within the class (EF or AF) is based on the source application running at the source (voice, video, etc.). The IP link (A-B) has to support a set of sources . In Figure 1, we present the architecture of the forwarding interface of BS A, supporting DiffServ. Let the capacity of the direct link connecting BS (A) to GW (B) be c. We assume that the bandwidth is distributed among the n EF subclasses, AF class and BE class using a weighted fair queuing scheduler (WFQ) where the vector h determines the weights used in scheduling. This ensures that each EF subclass on the link gets no less bandwidth than , where

(17.1a)

 
Figure 1: Forwarding interface of BS A.

Here,  is the minimum bandwidth required for subclass i to provide the target delay  to the sources belonging to the class. Similarly, h^AF captures the weight for the AF class which translates into minimal bandwidth of

(17.1b)

c^AF is the total bandwidth available to the AF class such that can be shared between the m subclasses. The bandwidth c^BE available to the BE class can be computed as

(17.1c)

Multiple sources belonging to the same subclass (EF or AF) at the BS A are placed in the queue for the subclass on a first-come-first-serve basis. Let the set of sources belonging to the ith EF subclass be , then every source  has a absolute delay requirement . Similarly, for the ith AF subclass, sources  have an average delay requirement such that . Source s belonging to AF or EF class has an average arrival rate of r_s. When generated by an on–off source model, it has a peak rate of R_s and the on period of average length I_s. Such a source can be effectively shaped by an LB filter of parameter (σ_s, ρ_s), where ρ_s is the average arrival rate and σ_sis the maximum allowed burst length of the LB filter. To ensure low losses, it is advisable to have ρ_s > 1.1r_s and high value of σ_s.

Observe that sometimes the bandwidth allocated to the AF class needs to be shared between the m subclasses such that each subclass meets its target delay requirement. This is done by using PDD scheduling between the subclasses where the value of parameter  determines the extent of differentiation. Furthermore, each AF subclass can have an end-to-end delay requirement for the concerned hop. Providing hop-by-hop delay allows greater flexibility and options of better mapping the sources to subclasses. 

WIMAX NETWORK ARCHITECTURE

In Figure 1, we present the overall network architecture of a WiMAX network. The network can be logically partitioned into three components, user terminals, ASN, and CSN. User terminals capture the data origination points, could be using the fixed, mobile, or portable WiMAX technology. All the three variations can be supported using a common air interface. ASN spans the BS and the ASN-GW. BS receives the transmitted signal, processes it, and converts into an IP packet and sends to the GW on the outgoing IP transport link. GW receives and upon processing determines the destination on the network side and sends the packet. BS and GW are connected to each other using an IP transport. Typical implementations would have BS located in the field/coverage area and the GW will be centrally located in the switch centers. Therefore, the IP link between BS and GW forms the transport backhaul network. CSN contains many different commercial off-the shelf (COTS) components, which provide connectivity services to the WiMAX subscribers. Addressing, authentication, and availability (AAA) servers, mobile IP home agent (MIP HA), IP multimedia services (IMS), content services, etc. provide support for seamless services to subscribers. AAA servers ensure that a user is uniquely identified and authenticated as legitimate customer. MIP HA ensures that roaming across IP networks is handled and accurate routing of data packets is ensured. Call processing related services are provided by IMS entity. Billing and operational support systems help in managing the overall network.

 
Figure 1: Logical network architecture of a WiMAX network.

In Figure 2, we present typical implementation of a WiMAX network in a market. For example, say a carrier plans to lay down WiMAX network in Washington D.C. market. Typically, we would have more than 100 BSs connecting to a GW location, based on the anticipated traffic, each GW location might require a cluster of servers providing the functions of the GW. Each IP transport link would be leased from the local carrier and provisioned. Based upon the cost points and required capacity, the carrier can choose to directly lease a TDM segment, Ethernet link, fiber connectivity, etc. Components of the CSN located at each switch center might also be implemented using clusters and would have enough capacity to support the entire market. Switch centers could be connected to each other using a high speed IP network running on an OC-192 (or higher) SONET ring leased from local exchange carrier. Actual network would also include connectivity to the other markets, trunking with public switched telephone network (PSTN) via the end office (EO), tandem connections with other wireless carriers, etc.

 
Figure 2: Physical network architecture of a WiMAX network.

For most WiMAX networks, it is unlikely that the carriers would provision the IP transport based on the capacity of the WiMAX air interface. According to WiMAX forum, air interface built on 10 MHz channel with 2 × 2 MIMO can support peak downlink rate of 63 Mbps and peak uplink rate of 28 Mbps per sector. Assuming three sectors per BS, this would translate into close to 200 Mbps of backhaul transport for each BS. When we share the symbols 3:1 between DL and UL, it could provide data rates of 46 Mbps DL and 8 Mbps UL per sector. Even then it would require about 150 Mbps of capacity between BS and GW. Such a requirement would lead to an unmanageable backhaul cost, which might become a road block in the large-scale adoption of the WiMAX technology.

Our contention is that the service providers will only provision based on the anticipated demand. For example, they might provision just enough capacity for N voice calls, Mvideo calls, and few more Mbps for best effort. This would ensure that the initial cost of building the network is manageable, and as the users grow, more backhaul can be added to ensure acceptable QoS for the subscribers.

OPEN ISSUES AND FUTURE WORK | Automatic and Optimized Cell-Mesh Planning in WiMAX

Automatic cell planning for data networks is still an open research subject. Its unique characteristics justify the efforts to extend current voice models to obtain new models. We have found few models oriented to the design of multiuser wireless data networks based on WiMAX like technologies. A complete solution that considers traffic models, link channel quality, sectorized antennas, channel allocation, and variable transmission profile, as far as we know, has not been found.

Right now we are considering a medium complex traffic model. There are several things to do to complete this model. Even though granted services require a fixed data rate, there might be some multiplexing gain based on statistical usage of this flows by end users. In voice model, there is an extension based on silence suppression which reduces capacity requirements for the system. In other types of flows, there are more realistic traffic models based on variable bit rate sources, which are harder to include. There is a need to include models that are nearer the operation scheduler in the design process. Finally, in BE traffic, there is a serious problem with the uplink scheduling. This model is more suitable for downlink transmissions, where the base station assigns transmission opportunities to contending flows. In the uplink, the backoff process defined in IEEE 802.16 standard requires a low usage of the available capacity for it to be effective. It is known that many users contending for the channel simultaneously would cause a low equivalent data rate per user. This model is not included in this work. We need to keep an equilibrium between precision and complexity. As this is a design process, there would be a prohibitive computational cost if the traffic model is far more complicated.

Another issue to be extended, is that users could dynamically change the base station which they connect to. Temporarily, during congestion periods of a base station, a node could connect through another base station which is not optimal in terms of propagation but that has available capacity. Our model only considers static assignment of users to base stations.

Another extension of our model is based on uplink channels estimation. We do not consider this in our model because of its complexity. Usually, uplink data rate requirements are lower than downlink ones, which gives a margin for uplink link budget. We consider symmetric channels for propagation between a user and a base station. Under this consideration, uplink channel quality should be similar to downlink quality. The issue we find difficult to include is the interference. The estimation of uplink received power can be easily done. When we consider interference signals at the base station, we have to consider transmission power of other base stations and other users. The interference from other base stations can be easily considered, but we have no method to estimate the interference caused by other users because we do not know a priori the base station they are connected to, their transmission channel, nor their antennas orientation. We are working on better ways to improve this part of the model.

We are working right now on simplifications of this model to account mathematically tractable solutions. We are considering an optimization problem based on activation and deactivation of candidate base stations, but also to include power control and data traffic models. Variable transmission profile based on adaptive modulation and coding is a really complex part, because of discontinuity. We are looking forward to find the simplifications needed to write it as a mathematical model and compare it with this solution.