Study on using design patterns to implement a simulation system for WiMAX network

Several literatures have been proposed to evaluate the simulation software, which can be summarized into three categories: the first category is for overview and introduction [8, 9]. The second category is the evaluation and comparison for the inner system architecture, such as fidelity, suitability, scalability, and extensibility [10‐14]. The third is the evaluation and comparison for the outer user experiences, such as learning time, user support, interface user-friendly, operate convenience, and performance [15‐17]. In order to obtain the most suitable simulator, we evaluate the existing 22 simulators as mentioned in the above papers according to their license ways, programming languages, operating systems, and lifetime as shown in Table 1. After evaluation, we finally selects the six most often used simulation software as the study items, i.e., J-Sim, NS-2, NS-3, OMNeT++, OPNET, and QualNet. We give brief introductions and comparisons for the abovementioned six simulation software as follows.

In the previous studies, many researchers provide their contribution on how to add or modify the WiMAX module, e.g., some NS-2 WiMAX modules are proposed by Networks and Distributed System Laboratory (NDSL) [19, 20], National Institute of Standards and Technology (NIST) [21, 22], LRC [23], and Light WiMAX (LWX) [24], respectively. In addition, Freitag et al. propose NS-2 WiMAX service flow module [25]; Guo et al. propose NS-2 WiMAX path propagation module [26]; Farooq et al. propose NS-3 WiMAX module [27]; Ismail et al. propose NS-3 WiMAX module [28]; and Furlong et al. propose NS-3 WiMAX OFDMA expansion module [29]. In [30], the authors propose to use a strategy pattern to implement the scheduling module.

In those papers, all authors have referred to their customize simulators and code by using object-oriented language for expansion modules, which follow object-oriented design rules; therefore, those system architectures posses the convenience for modification and the flexibility for expansion. However, those properties are difficult to quantify and have a consistent assessment metric. Moreover, some papers have mentioned that none of simulation software is able to reproduce all of MAC layer control messages and processing procedures, as well as we found that any two simulation software do not implement the same control message types and processing procedure. Hence, it would be different for the performance expression of time-related evaluation metrics in different simulation software, e.g., the influence of packet delay time. In order to investigate how the management message processing procedure affects the time-related evaluation metrics, a system architecture should allow users to arbitrarily define his management message types and processing procedure, and then, we can obtain a more objective system performance evaluation results. Finally, to our knowledge, it often is incompatible for the operation interface of scheduling modules due to incorporation for the different scheduling factors and algorithms, which leads the studies inconvenience to evaluate the performance of various scheduling algorithms. Therefore, it would be helpful for the study of the scheduling algorithm selection, if the system architectures of schedule algorithm and operation interface can be independently developed.

A programming is a series of thinking process to convert an abstract problem description into a realistic code entity. Compare with the program-oriented design manner that based on the functions capability and executions order, the object-oriented design manner has capability to receive, process, and deliver independent data unit as design foundation, i.e., object; hence, the system architecture has more flexible and easier to maintain. The design patterns are exactly in the basis of object-oriented design manner to get rid of bad one and keep good one from the frequent occurrence solutions. The purpose of design patterns is to organize these solutions in a simple and easy way, and they make our programming more flexible, more modularized, more reusable, and easier to understand. Design patterns do not teach us how to code, but they are the discussion schemes to solve the problems under different situations. The pattern in design patterns means a useful solution has been proven that can be used to solve the recurring problems under a special scenario. Based on the Gof literatures [31], there are 23 types of design patterns and are divided into three categories, which are creational, structural, and behavioral introduced as follows.

Creational design patterns mainly abstract the instantiation process, which help us to make a system independent of how its objects are created, composed, and represented. A class creational pattern uses inheritance to vary the class instantiated, whereas an object creational pattern will delegate instantiation to another object. Creational patterns include abstract factory, builder, factory method, prototype, and singleton pattern. Structural patterns are concerned with how classes and objects are composed to form larger structures. Structural class patterns use inheritance to compose interfaces or implementations. Structural patterns include adapter, bridge, composite, decorator, façade, flyweight, and proxy pattern. Behavioral patterns are concerned with algorithms and the assignment of responsibilities between objects. Behavioral patterns describe not only just patterns of objects or classes but also the patterns of communication between them. These patterns characterize complex control flow that is difficult to follow at run-time. They shift your focus away from flow of control to let you concentrate just on the way that objects are interconnected. Behavioral patterns include a chain of responsibility, command, interpreter, iterator, mediator, memento, observe, state, strategy, and template method.

PHY package is a program collection which is responsible for the physical layer functions corresponding to the real world, the main capability is using the frame structure form to provide link capacity, and the modular function includes the various wireless technical frame structures, such as orthogonal frequency division multiple access (OFDMA), and subcarrier permutation mechanism. There are three main modules in this package, i.e., slot factory module, frame builder module, and resource allocation module. In slot factory module, factory pattern is used to produce the simple structure object, such as basic slot structure, slot, and frame, because these objects use only one substructure type. In frame builder module, builder pattern is used to produce more complex objects, such as subframe, because the area types and amount on the inside of the subframe are dependent on the network topology and the device node-type. In resource allocation module, the order of nodes to obtain link resource is in first-come first-served (FCFS) manner. The system architecture will be implemented by the use of singleton if the real object only has one object entity to exist, such as subcarrier permutation mode or basic slot structure. Meanwhile, in order to simplify the needed parameters of frame production, we enumerate the original parameters in advance, such as system bandwidth and fast Fourier transform (FFT) sizes, and then, we calculate the derived parameters by using the original parameters, such as symbol time, useful transmission time, and the amount of symbol time of frame. According to the selected parameters, such as the ratio of bandwidth allocation and permutation mode for DL and UL, user can calculate the duration and sub-channel amount of subframe finally to create the instance of frame object. There exist three conditions to have the best solution of the subframe duration allocation, i.e., to completely use the frame duration, to exactly be the integer multiple of slot time for the subframe duration, and to be identical for both the subframe duration ratio and the bandwidth allocation ratio; therefore, we proposed a two-stage minimum variance bandwidth allocation algorithm (TSMVBA) to deal with the bandwidth allocation problem for DL and UL subframes. The UML diagrams for slot factory and frame factory have been shown in Appendix 1: Figs. 8 and 9, respectively.

MAC package is a program collection which is responsible for the MAC functions corresponding to the real world, whose main capability is to process and execute the management messages. Some specific purposes can be accomplished by the management messages, such as CDMA connection contention mechanism, bandwidth requirement and allocation mechanism, and the packet transmission and reception procedures. We proposed SM³PA to let users arbitrarily define their management messages for their interested manage procedure, and the definitions and process procedures of management messages can be independently developed. SM³PA have three main concepts: firstly, the system architecture of event types, event processing procedure, and event owner can be independently developed; secondly, the concept of command flow (CF) is used, where CF refers to a chain of events getting together to accomplish a specific purpose; thirdly, the event owner certainly has the ability to handle the event.

In the virtual simulation world, time is advanced in a non-continuous way, and the advanced interval precision determines the required reality time. For saving reality time, we focus on the occurrence time of the specific event, called monitor time. We list all the event types that possibly occur at monitor time, which are enumerated in the event package. The processing procedures of all event types define a common execution interface, which consist of many sub-procedures, while the operating interface of these sub-procedures is defined in the event processing procedure package. The different types of devices may have the same type of events, but their processing procedure may be different; therefore, the execution details and steps of the sub-procedures are provided by the device class, i.e., the concept that “the event owner certainly has the ability to handle event.” We establish a chain of event types to accomplish a specific purpose to facilitate the management of the relationship among events and to mitigate the management problem caused by increasing the number of sub-procedures because the system quickly grows up, where the codes are independently in various sub-packages, that is how we implement the command flow way.

When the simulation starts to execute, system core will ask for the execution time of the next nearest event of all device instances, and then, the system time will advance to the next nearest event time and to notify all device instance sequentially to process events. Since the needed processing time of each event is different, the next system time of each device instance will be different. When the event execution finishes, the original event owner will create new event instance and store in the event queue of new event owner. A current event may trigger several new events if multiple events occur simultaneously, where the new events will comply with the event priority order to execute. If all events at this monitor time have been processed, the above procedure will be repeated until no new event creates or reaches the predefined simulation stop time.

MAC package and event package are complementary. An event package is responsible to define event types, while an MAC package uses various event types to create command flow and sequentially to execute the events in command flow. In order to prove practicable, we define three command flows, i.e., connection contention mechanism, bandwidth request and grant mechanism, and data transmit and receive mechanism. The design of command flow is based on hybrid multi-hop relay network (HMRN), and HMRN is described in topology package.

In Fig. 1, the red and green blocks represent DL and UL subframes, respectively, while Arv, Req, Gnt, Trs, Rcv, Rly, Dpt, and Ack denote packet arrival, bandwidth request, bandwidth grant, packet transmit, packet receive, packet relay, packet departure, and packet acknowledge, respectively, where the subscripts represent the device types of event owner. About the event relations in command flow, the relation of one-to-one is the simplest, e.g., a subscriber station (SS) bandwidth request event Req _ss triggers the scheduling event of base station (BS) and transparent relay station (tRS) Sch _BS & _ntRS and further triggers the bandwidth grant event Gnt _BS & _ntRS . The relation of one-to-many is more complex, e.g., the packet receive events Rcv _BS,tRS & _ntRS occurred on the relay station (RS) triggers the packet relay event Rly _tRS & _ntRS , but the packet departure event Dpt _BS will be triggered if it occurs on BS, i.e., the identical type event occurred on the different device types may have different processing procedures. In Fig. 1, a packet needs about two frame time duration from entering system to departing system.

NET package is a program collection which is responsible for the network and upper layer functions corresponding to the real world, whose main capability is to implement the traffic generator (TG) and probability distribution model (PDM). PDM is based on linear congruential generator (LCG), which may have uniform, exponential, normal, lognormal, extreme, and geometric distributions for implementations. After a most suitable distribution model has been selected, the random number generator is used to generate random variant, e.g., traffic or service time, where the UML diagram for random number generator is shown in Appendix 1: Fig. 10.

Event package is a program collection which is responsible for the MAC layer management message corresponding to the real world, whose main capability is to define the event types and the sub-procedure operation interfaces inside the event process procedures, and the code entity of execution detail is provided by the device instance. The system architecture of event package includes interface class, abstract class, and object class program, and the use of patterns has factory, bridge, chain of responsibility, and command pattern, where the UML diagram for event package is shown in Appendix 1: Fig. 11.

This package uses the interface class as super class and defines five basic operate interfaces, namely event identity code (EID), event owner (EO), event type (ET), trigger time (TT), and execution method (EM). EID is used to facilitate tracing the footprints of a specific event instance and convenience to monitor and debug. EO is responsible to provide the code entity of the event processing sub-procedure. ET is used to define event priority and the relationship among events. TT is used to sequentially perform event on time. EM is used to make all event types have a common interface method to perform their processing procedure. Under the different types of network topology, the same type events may trigger the same new events but having different owners, e.g., in transparent relay network, the users send the bandwidth request information to BS. After BS finishes the scheduling procedure, it informs the users to send data to tRS. However, in non-transparent relay network, the ntRS is responsible for the user all the request, scheduling, and grant procedures. In order to let the same type event have the different processing procedures with the different owners, we proposed a system architecture to allow that event type, processing procedure, and event owner can be developed and grow up independently to increase flexibility.

In this package, we use factory pattern to create event instance. The use of bridge pattern is to separate execution sub-procedures defined by the device package role category from execution procedures defined by the event package processing procedure class, so they can evolve independently. The chain of responsibility pattern is to let all device categories have an opportunity to process event instances on behalf of management messages and lower the coupling relationship between the sender and the receiver. Finally, the design concepts of event class come from command pattern, i.e., event instance, to control system operation.

Device package is a program collection which is responsible for network device corresponding to the real world, whose main capability is to facilitate the definition and implementation of the network devices. This package divides simulation system network devices into two categories. The first category is responsible for describing the basic ability of real-world network devices, called basic device, e.g., UE, RS, and BS. The second category is responsible for describing the event process ability of virtual world network device, called role device, i.e., a temporary name of basic device during the process period of a specific event, e.g., packet arrival role and bandwidth request role. In basic device, we define and implement the basic function of real network device, such as PHY layer, MAC layer, packets manage, and events manage functions. In role device, we define the needs of sub-procedure operation interface of the event execution and use the one-to-one mapping manner to corresponding with event types. The identical type events in different type of basic devices possibly have different processing sub-procedure, e.g., packet receive event. After receiving packet, BS lets the packet depart; tRS forwards it to BS; non-transparent relay station (ntRS) adds it to the next bandwidth requirement; therefore, the details of sub-procedure execution, i.e., code entity, are provided by basic device. This design concept is inspired by the different individuals that the same work item should have the same execution procedure, but the execution details can be adapted according to the reality conditions. Moreover, to simplify the operation of event processing, we defined a common execution interface for all of event types. During the simulation, basic device will trigger the various type events along with simulation progress. When it is necessary to execute the event processing procedure, the basic device transforms into the corresponding role device according to the trigger event type and obtains the event processing ability, and the role device will transform back into basic device after event execution finished. The UML diagrams for basic device class and role device class have been shown in Appendix 1: Figs. 12 and 13, respectively.

Topology package is a program collection which is responsible for network topology corresponding to the real world, whose main capability is conveniently to manage and use the network topology. A modular function includes two parts, namely topology establishment and user deployment. In order to establish the network topology in a simulation architecture, we proposed an applicable for multi-hop relay network topology architecture (AMRNTA). In AMRNTA, we use tree structure to establish the network topology, in which all nodes have two types of links, i.e., control link and data link. Control link and data link are responsible for delivering the management messages and data, respectively, and each link has both uplink and downlink directions. Before establishing network topology, each son node needs to define a parent node, and then, the son node first establishes a UL data link to his parent node, meanwhile the parent node adds this son node to his DL data link queue. Next, the son node sets his parent node as a control link target node (CLTN). If the CLTN has the wireless resource allocation ability, the son node establishes a UL control link to this CLTN, meanwhile the CLTN adds the son node to his DL control link queue; otherwise, the son node sets the CLTN parent node as a new CLTN if it does not have the wireless resource allocation ability and repeat the foregoing procedure until the new CTLN has the ability to allocate wireless resource. The establishment of network topology is in a point-to-multipoint (PMP) manner and has broadcast function, because a son node only has a parent node but the parent node may possibly have many son nodes. With this architecture, the procedure of establishing network topology can be simplified.

In order to avoid interference, each serving station needs to have independent resource, and its available resource is to satisfy the maximum user requirement and be proportionally allocated to the serviced users. We propose three slot allocation rules as follows. Firstly, based on the maximum number of hops in the network topology, a subframe is divided into the same number of zones. Secondly, the available slot amount of each zone is proportionally allocated to the serviced users. Thirdly, the number of serviced users should be the maximum amount if several zones reuse the same resource area.

About the user deployment modular functions, we design three user deploy mechanisms, i.e., sequence, random, and proportional modes. The sequence mode refers to the users which will be sequentially assigned to the serving station, which is suitable for system debug. The random mode refers to the user will be assigned to the serving station according to uniform distribution in random manner, which is most approximate to real situation. The proportional mode refers to the users which will be assigned to the serving station according to the ratio of their serviced users, which is suitable to evaluate the system performance under different loads.

Scheduler package is a program collection which is responsible for scheduling mechanism corresponding to the real world, whose main capability is the implementation of scheduler algorithm, and the goal is to make the reuse of system scheduler codes to maximize. In order to let all scheduling algorithms share a common operating interface, to combine multiple parameters into a schedule metric to implement the more complex schedule concept, and to replace the schedule module more easily to evaluate the performance of various scheduling algorithms, we propose four design concepts; the first is the input of schedule module which is scheduling units having the ability to generate the schedule comparison unit; the second is schedule comparison unit having the abilities to compare with identical class and combine many parameters to form a comparison item; the third is the core of schedule module which is scheduling algorithm concentrating on the schedule mechanism; the fourth is the output of schedule module which is an ordered set of scheduling units. In the aspect of pattern use, we use a strategy pattern to encapsulate the schedule module to make them interchangeable, and the system architecture and the exchange of schedule algorithms are independent. The factory pattern simplifies the generate procedure of schedule unit. In this package, we implement uniform, random, and round robin scheduling algorithm to demonstrate the feasibility. The UML diagram for scheduler package is shown in Appendix 1: Fig. 14.

Report package is a program collection which is responsible for the output of system information and performance evaluation metrics, whose main capability is to make the system information output module independent of other packages. The output format of information can be arbitrarily changed under the premise of not affecting the other packages. The design idea of this package comes from the concept of the observation point in queueing theory, and a chain of responsibility patterns is used to design system architecture. The modular functions have two parts, namely system monitor and performance evaluation metrics. The former one includes system scenario and simulation parameters, as well as the important information at the time of system status changed. The latter one includes throughput, packet delay time, packet queue length, packet waiting time, and packet drop ratio. The UML diagram for report package is shown in Appendix 1: Fig. 15.

Figure 3 shows the uplink subframe output data for various device types, in kilobit (kb), where the abscissa and Y-axis represent system time and output data, respectively. The uplink subframe output data of BS SS (bSS), tRS SS (tSS), ntRS SS (ntSS), RS, and BS have been shown by the curves in different colors of red, blue, green, pink, and orange, respectively. In Fig. 3, the uplink subframe output data of BS is 30.96 kb, which is composed of the BS user data 10.8 kb and the forwarded user data by RS 20.16 kb, while the latter part are from tSS and ntSS with the forwarded user data 12.96 and 7.2 kb, respectively. Because that the access zone (AZ) size for 1 hop users is 105 slots (3T _slots × 35CHs), of which 75 slots are allocated to the BS to receive user data, the BS AZ output data is 10.8 kb (75 × 48 × 4 × 3/4 = 10.8 kb). The size of transparent relay zone (tRZ) is 140 slots (4T _slots × 35CHs). BS uses all slots to receive the data forwarded by tRS, so the output data is 20.16 kb. As to non-transparent relay zone (ntRZ), because it merely supplies forwarded data from ntRS to tRS, so the output data is 0 kb. It is worth mentioning that, in order to guarantee an RS can forward data to its destination as soon as possible, we adopted the relay first resource allocation strategy (RFRAS). RFRAS gives RS packets having higher priority when the service object includes RS and SS packets, and then, resources will be assigned according to their priority order. In the meantime, to prevent service objects with lower priority from being starved, each service object can only be assigned with one resource at a time.

Figure 4a shows the average packet delay times for various device types, where the abscissa and Y-axis represent system time and delay time, respectively. The delay times of bSS, tSS, ntSS, RS, and BS have been shown by the curves in different colors of red, blue, green, pink, and orange, respectively, i.e., the delay times of 1 hop, 2 hops, 3 hops, 1&2 hops, 1&2&3 hops with the values of 2.5, 7.5, 127, 49.1, and 32.8 ms, respectively. Meanwhile, Fig. 4b shows the detail delay times from tSS to BS (the blue line in Fig. 4a), including the delay times of the first hop (tSS ➔ tRS) and the second hop (tRS ➔ BS), while Fig. 4c shows the detail delay times from ntSS to BS. In Fig. 4a, the value of red line is 2.5 ms, because BS users can upload data to the BS directly. The packet transmitted during the uplink subframe will certainly be received before the uplink subframe is terminated; therefore, the maximum delay time is one uplink subframe duration. In addition, if the packet arrival rate is faster than the upload rate, the packets will be stored in queue or dropped. Since the packet queuing waiting time does not belong to the delay time, the delay time of 1 hop users will always be a fixed value of 2.5 ms.

Figure 5 shows the average packet queue lengths for all device types. In Fig. 5, we first see the growing up trends of bSS and tSS are similar, and both reach full-load at about 110 ms. In light of Section 4.1, AZ has 105 slots, of which 8 bSS shared 75 slots. Every bSS can be allocated with about 9.375 slots in average; the remaining 30 slots were shared by 3 tSS; and every tSS obtains 10 slots. Since they have identical packet arrival rate and approximately the same packet upload rate, their growing curves are similar. Secondly, we can see that at the initial stage, the number of ntSS queue packets maintained at about 10 packets. When system time is 190 ms, it starts to climb and then reached full loading at 400 ms. At the initial stage, because the tRS queue is under light loading, tRS has the maximum capability to receive serving user packets. However, the queue length of tRS will gradually increase, because the ability of BS receiving packets is lower than the ability of the whole tRSs transmitting packets. When the tRS queue is full, ntRS also gets slow because of the uploading speed, which causes the packet queue length to gradually increase until full.

Figure 6 shows the average packet waiting times for various device types. The waiting times of bSS, tSS, and ntSS have been shown by the curves in different colors of red, blue, and green, respectively, i.e., with the values of 126, 120, and 68 ms, respectively. The waiting times can also be obtained by estimation as follows. In AZ, each bSS has 9.375 slots, i.e., 1.875 packets, usable in average; because bSS queue often keeps at 48 packets, the average waiting time of the last packet is 25.6 frame duration, i.e., 128 ms. Similarly, for the waiting times of tSS, since each tSS has 10 slots, i.e., 2 packets, usable in average, the average waiting time of the 48th packet is 24 frame duration, i.e., 120 ms. For the waiting times of tSS, every ntSS can upload 3.5 packets in average, and the queue length often keeps at 47 packets; therefore, the last packet needs to wait for 13.4 frame duration, i.e., 67 ms. Therefore, the estimated results are close to the simulation results.

Figure 7 shows the average packet drop ratios for all device types. In Fig. 7, in terms of bSS, the packet drop ratio is 58 % by simulation, and it is lower than 62.5 % by calculation with average manner, i.e., when the simulator calculates the drop ratio, the arriving and the dropping packets are accumulative from the beginning to the end of the simulation. However, when we calculate the average drop ratio, we only use average packet arrival rate and uplink subframe capacity. At the initial stage of simulation, there are plenty bandwidth resources, so the drop ratio is small. The smaller drop ratio dilutes the late stage’s larger drop ratio; therefore, the simulation drop ratio is lower than the average drop ratio. Similar situation also happens in tSS and ntSS. In terms of tSS, the simulation and average drop ratios are 55.4 and 60 %, respectively, and the ntSS simulation and average drop ratios are 22.5 and 30 %, respectively.