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.