Environment

In the following we will describe the environment, in which the above described WiMAX system will function. We will use a simplified access network topology and MS distribution that will model the congestion of a BS in relations to its neighbors.

The channel will be modeled with fixed MCSs and the traffic will be a mixture of

2The results should apply quite well also for ASN profile A, since the only difference will be in the way the SCRs are delivered to the BSs.

User Datagram Protocol (UDP) based VoIP traffic with guaranteed throughputs and TCP based elastic FTP and HTTP traffic with BE service.

5.1.2.1 Topology and channel

We will use a simplified system model by modeling our access network as a cluster of three Base Stations with omni-directional antennas. The BSs will reside side by side with the overloaded BS (BS 2) in the middle.

BS 1 10 % of MSs BS 2 BS 3

connected to BS 2

10 % of MSs connected to BS 2

UL: 16-QAM½ DL: 16-QAM¾

UL: 16-QAM½ DL: 16-QAM¾ UL: 16-QAM½

DL: 16-QAM¾

UL: QPSK½ DL: QPSK¾

UL: QPSK½ DL: QPSK¾ Twice as many MSs as in

BS1&3

Figure 5.1: Simulation setup.

The MSs will be distributed to the system so that twice as many MSs will be dropped to the middle BS than to the less congested neighboring BSs (BS 1 and BS 3). The total number of MSs dropped to the system will be 400 meaning that 200 MSs will be dropped to BS 2 and 100 respectively to BS 1 and BS 3 (see Table A.7 for the spe- cific MS distribution). Detailed interference, shadow and fast fading models won’t be used since they are not an important issue in terms of load balancing for static nodes with rather static channel conditions. We will instead model the channel by choosing appropriate fixed MCSs.

As can be seen from Figure 5.1 the MSs residing in the overlapping areas far away from the BS will use a more robust MCS than MSs residing closer to the BSs thus modeling the effect of path loss in the channel. Furthermore a more robust MCS will be used in the UL than in the DL as is commonly done in radio communication systems.

To simplify our simulations and congest the middle BS more we will distribute the MSs so that only MSs connecting to the middle BS will be dropped to the over- lapping area and all the MSs connecting to the lightly loaded BSs will be dropped closer to the BS. The MSs dropped to the overlapping areas (10 % + 10 % of the

total number of MSs connecting to BS 2)³ will be handed over to the less congested BSs if necessary.

Although this setup doesn’t necessarily reflect a very realistic MS distribution, it should still be sufficient for the preliminary evaluation of the basic algorithm.

Detailed values of the MCS and the default MS distribution can be found from Appendix A in Tables A.5, A.6 and A.7.

5.1.2.2 Traffic and QoS

Traffic used in the system will be a mixture of four traffic types VoIP, VoIP with Voice Activity Detection (VAD), FTP and HTTP which will be served by the sched- uler with UGS, ertPS and BE services. In our simulator we will use existing NS2 traffic generators for the first three traffic types and a separately implemented traffic generator for HTTP based traffic.

The traffic type with the highest priority will be UGS based VoIP, whose gener- ator will send fixed size data packets on a fixed periodic interval. To simulate a bidirectional connection a traffic generator will be configured for both the UL and the DL.

The next highest priority traffic type will be ertPS based VoIP with Voice Activity Detection (VAD). The generator for VoIP with VAD will generate traffic during an activity period in a similar way as regular VoIP, but during a silence period nothing will be transmitted.

The lower priority BE traffic types will be FTP and HTTP traffic. FTP traffic will be simulated with the NS2 inbuilt FTP traffic generator, that sends data con- stantly according to the TCP congestion window. The implemented HTTP traffic generator will send packets according to the model specified in [3GPP2] where the process of downloading a web page consists of main and embedded object retrievals and the corresponding reading and parsing times. A more detailed description of this can be found from [Cas07]. For FTP and HTTP data transfer is asymmetrical since only acknowledgments will be sent in the UL.

Each MS will carry only one UL&DL service flow pair and the traffic distribu- tion among the MSs will be equal (25 % of the MSs use VoIP, 25 % VoIP with VAD, 25 % FTP and 25 % HTTP). As mentioned earlier load balancing will only be conducted for non-BE connections meaning that with this traffic mix load bal- ancing will only be conducted for VoIP and VoIP with VAD. More information on the traffic parameters can be found from Appendix A in Tables A.3 and A.4.

3As discussed in part 2.1.1.2 in Mobile WiMAX a frequency reuse factor 3 will be used in the edges of the cell limiting the size of the overlapping area and thus the number of MSs in the overlapping area. However some overlap will also occur between the BS sectors and hence this assumption should be reasonable.

In [Job04] an interesting study was presented on how and why hot-spots happen.

Three typical cases were identified: delay based, capacity based and preferential mo- bility based hot-spots. In the delay based case the time that moving MSs spend in the cell⁴ increases (e.g. traffic jam). In the capacity based case, the capacity of the BS is temporarily reduced (e.g. node updates)⁵. In the preferential mobility based case people are moving towards an event (e.g. a concert) and hence the number of users in the BS increases⁶.

In our simulations we will congest the middle BS based on preferential mobility and delay. Preferential mobility will be simulated by dropping more MSs to the middle cell. The delay case will be simulated by not terminating the initiated ser- vice flows during the simulation which will also simplify implementation. Flow arrivals will be modeled with a Poisson arrival process with an average service flow inter-arrival-time of 1.2 seconds (0.83 flows per second arrival rate)⁷. We can use Little’s formula (4.3) to show that this is a valid arrival rate to congest a BS. In [Die04] a 180 second call holding time was used to model a typical length of a call but since data sessions usually last longer, a flow with this profile could last on average let’s say 300 seconds. If this holding time is used in conjunction with the chosen flow arrival rate, Little’s formula will result in 0.83·300 = 250 connections on average in the BS which would clearly overload a BS in the system.