Sie sind auf Seite 1von 6

2011 International Joint Conference of IEEE TrustCom-11/IEEE ICESS-11/FCST-11

Simulation Tools Enabling Research in Convergence of Fixed and Mobile Networks


Andreas Bontozoglou
School of Computer Science and Electrical Engineering, University of Essex, UK email: abodoz@essex.ac.uk

Kun Yang
School of Computer Science and Electrical Engineering, University of Essex, UK email: kunyang@essex.ac.uk

Ken Guild
School of Computer Science and Electrical Engineering, University of Essex, UK email: kguild@essex.ac.uk

AbstractThe massive increase of mobile handsets in conjunction with the new and more demanding services deployed over wireless networks lead to huge bandwidth requirements for both the wireless and the backhaul networks. Ethernet Passive Optical Network deployment has already been started to replace E-1/T1 lines. In addition wireless broadband access is taking place mostly with the use of WiMax. Integration and convergence of the above technologies had been proven to have many benets. Due to the nature and the complexity though of the scenarios in this area, a large scale simulator, supporting multiple services and QoS is needed in order to validate new network and resource management algorithms. In this paper a simulator developed using OMNet++ framework is presented. The designed modules and their functionality are listed. A discussion on how these could be used to form different convergence architectures and the major outcome/results of such a simulation are explained. Index TermsFMC, OMNet++, Convergence, simulator, EPON, WiMax, 802.16, 802.3ah, 802.1q

I. I NTRODUCTION In the last decade mobile wireless services have evolved rapidly trending toward high bandwidth connectivity. This phenomenon is accompanied and largely driven by the massive increase in the number of smart phones. As a result, more demanding new services such as e-health and video services are deployed over wireless networks leading to more bandwidth and QoS (Quality of Service) requirements for both mobile wireless networks and their (xed) backhaul networks. The work presented in this paper is associated with an ehealth research project called PAL[1]. However, the outcomes are applicable to any other scenarios where xed-mobileconvergence (FMC) is involved. The standard backhaul technology used until recently was E-1/T-1 ISDN lines, which are capable of transmitting 2 Mpbs. Although these lines can guarantee QoS, they have limited scalability and leasing them costs a lot. Furthermore, with the increased bandwidth demand on the wireless access network, E-1/T-1 lines proved to be non-sufcient. Thus mobile network operators tend to use more exible and economic solutions for backhauling their base stations. One of the most promising and uprising technologies is Ethernet Passive Optical Network (EPON - 802.3ah [2]) which is already being deployed from many operators. EPON uses the standard 802.3 (Ethernet) packet format, which makes it simple and compatible with

most of the networking equipment. In addition, it supports QoS and dynamic bandwidth allocation between the attached ONUs using TDMA. For the wireless access networks, the one of technologies that has drawn the attention of network operators and the scientic community the last years is WiMax (IEEE 802.16 [3]). This is because it supports a variety of service types over long distances (even non Line of Sight (LoS)) and can reaches a theoretical throughput of 70 Mbps. WiMax is also a scheduled medium access technology using OFDM (Orthogonal Frequency Division Multiplexing) and allocating symbols to Subscriber Stations (SS) which makes it capable of doing dynamic bandwidth allocation and supporting QoS. The idea for converging the above two technologies has been around for some years now. The authors of [4] proposed four different architectures in order to integrate EPON and WiMax networks. As mentioned in that article, the benets of such an integration are presented below. First, the combination of the EPONs 1Gbps capacity with the non-LoS mobility offered from the WiMax. Also integration of these technologies is easy since they are both under 802 standards and there is huge support from the industries since Ethernet related/based equipment is dominant in the markets. Furthermore deploying an EPON network to support various other access networks is a cost effective solution while EPON architectures is generic enough to support any other PON type on top of it. In addition, in the long term EPON is easily upgradeable once it is deployed since new interfaces can be used to boost it up to 10Gbps NG-PONs (Next Generation) and LR-PONs (Long Reach) ([5]). Finally the DBA capabilities and the packet scheduling used from both technologies can help network performance, QoS operational expenses. The physical topology of a converged network, consisting of EPON and WiMax networks, is presented in the Figure 1 below. The optical part of the network consists of the Optical Line Terminal (OLT) assigning bandwidth to the Optical Network Units (ONU) while the access networks are WiMax Base Station (BS) serving multiple Subscriber Stations (SS). Extending the previous articles proposed architectures, the authors of [6] also listed the up to-date integration techniques and presented a DBA scheme using Layer 2 VPNs to converge both technologies. The integration types of EPON and WiMax

978-0-7695-4600-1/11 $26.00 2011 IEEE DOI 10.1109/TrustCom.2011.254

1789

could be summarized as: 1) Independent: In this architecture EPON and WiMax are interconnected but they work independently. 2) Hybrid: In this case the ONU and the WiMax BS are build in the same box providing an optical interface and an air interface. This is also known as ONU-BS. 3) Unied Connection-Oriented: Here the proposed scheme requires the ONU to encapsulate Ethernet frames into WiMax PDUs before transmitting on the ber. This make possible a common request-allocation mechanism. 4) MoF - Microwave over Fiber: As the name suggests this architecture transmits the wireless signals directly over the ber and thus the OLT is working as a WiMax BS. 5) Virtual: In this case a bridge is installed between the ONU and the BS to coordinate them. This architecture doesnt require any modication of the PON or WiMax devices/protocols [7].

following section II related work is going to be presented, focusing mostly on the simulation tools used. In Section III the basic simulator modules, their design and parameters will be presented separated in three major categories (Backhaul, Access networks and Trafc). Section IV is a small discussion about how these modules could be used to form the convergedintegrated architectures listed above. The next section (V) will show some outcomes of both OMNet++ framework and the simulator developed and how these can be analyzed and presented. Finally the sections for Conclusions and Acknowledgments follow. II. R ELATED W ORK Lots of work has been done in the area of FMC (Fixed Mobile Convergence) in past. The majority of this was focused on optimization, management and integration of different technologies. In addition most of the work presented up todate was analytical, without the involvement of any simulation for evaluation. In this section, focusing on previous work and especially on the simulation part, some example articles are going to be presented. First the most common and widely used simulation platform is OPNET, based on which the authors of [10] presented a signaling and admission control scheme for Hybrid Optical Wireless (HOW) networks. In this article a scheduler was proposed that was taking under consideration the wireless networks status. The simulation performed using OPNET modeler on EPON and WiMax networks, the results of it show that the proposed IOW-AC scheme is more efcient than the default/normal AC in means of dropping probability and acceptance of new connections. In the article [11] a Multi-User Session Control (MUSC) solution is presented. The authors explain the existed standards for performing QoS reservations and the problems that these face when it comes to mobility and Multi-ISP (Internet Service Providers ) environment. Although the authors were focusing more on section continuation while handing over different ISPs, they used a 802.11e access points and WiMax in oder to support QoS on the access network. The backhaul networks consist of a number of interconnected routers, representing the ISP infrastructure. Finally in [6], the authors proposed a converged architecture based on end-to-end VPN tunnels. The Unied ConnectionOriented integration of EPON and WiMax was chosen in order for the OLT to support ow differentiation as WiMax, thus 802.16 PDUs were transmitted on the ber/optical part of the network. A simulation was performed to validate the proposed per-ow QoS DBA and Call Admission Control scheme using OMNet++. Although the parameters used, seem to t the Numbat projects defaults, an extension had to be implemented for rtPS and nrtPS services. In addition the EPON proposed, does not comply with the 802.3ah standard, since it uses WiMax PDUs. Finally no source code was released out of this work. As seen from above, although NS2 has a vast variety of wireless access network modules [12], the only simulator to

Fig. 1.

Simulated network Overview

As mentioned above, convergence has many advantages and is the way networks will be in the future. Integrating these technologies can be a very complicated job to do due to the number of protocols involved. In addition, FMC is usually referring to wireless access networks which means that a simulation is not avoidable due to the large number of mobile nodes needed to validate the deployment. Simulation seems the only way to test scenarios with large number of mobile nodes. In a converged environment like the one described many things could be tested and developed, including: packet schedulers, DBA algorithms, end-to-end QoS, handovers (horizontal and vertical depending on the number of access technologies used) and Call Admission Control systems. Thus this work is focused mainly on the above mentioned technologies and how they could be simulated in an integrated scenario. A simulator has been developed based on the OMNet++ framework ([8]) and INET/MANET modules of it and is going to be presented below. Please refer to the link at [9] for detailed information and the source code. The rest of the paper is organized as follows. In the

1790

support an EPON network (by the time this work started) was OPNET modeler which is a proprietary one. The same lack of PONs appears also in the still under development NS3[13] simulator. The need on a exible, extensible and open source simulation environment is obvious. The modules developed to enable such an environment are going to be presented in the next section. III. S IMULATION M ODULES The developed modules and their capabilities are going to be briey discussed in this section, without many technical or codding details. The following subsections are organized from aggregation network to access network (ref. Figure 1), starting by presenting the basic trafc differentiation and service conguration which is global for each simulation. A. Services and Trafc differentiation 1) Service Conguration: All the modules developed for this simulator are able to get conguration from the services module. This enables multi-service scenarios to be deployed, which is something that OMNet++ didnt support by default. The service conguration module is fairly simple and holds the required information for the services enabled in the scenario. These information include the following: Names: A strings representing each services name. Vlans: A VLAN (Virtual Local Area Network) IDs, one for each service. Priority: This is the priority of each service in the scenario (name[0] - vlan[0] - priority[0]) MSR: Maximum sustained rate, as a QoS metric used from WiMax BSs MRR: Minimum reserved rate, as a QoS metric used from WiMax BSs This module is accessible from any other module or submodule that needs this information. These include the relay units and the queuing modules. The most important feature is that trafc mapping conguration is handled here. Thus the module includes the VLAN ID used for each service. Vlans (802.1q [14]) are going to be used to differentiate trafc from the congured service and to be mapped to queues of different technologies/protocols. The end-to-end frames used and how data are encapsulated are presented in Figure 2.

The encapsulation module developed in the interface receives higher layer packets and creates Ethernet II frames. Also this layer is referred as Logical Link Control thus is the appropriate place to congure the VLANs supported from the interface. On initialization, this module generates random MAC addresses for all the VLAN IDs congured and registers a fake/virtual interface in the hosts interface table. The interface has always the same format: interfaceName.vlanId (ie. eth0.3). Furthermore this module holds in the memory a map with the allocations VLAN - MAC. 3) VLAN Network Congurator: A NetworkCongurator module that is able to handle VLANs on the initialization of a simulation. As the congurators provided from the INET framework, its job is to assign IP addresses to all the available interfaces of all the hosts. The difference is that this one will take under consideration the VLANs. There are not many parameters available currently to keep it simple. What it actually does is to take the 10.x.y.0/24 subnet for each VLAN. 10.0.0.0/24 is always going to be the real (hardware) device. The x.y is replaced by the VLAN id. The VLAN id is decided from the interface name because as mentioned in the encapsulation module (above) it is going to be registered in the ethX.Y format. Drawback: This means that each VLAN is allowed 254 machines (counting both hosts and network devices). In case that the machines are more than this limit an error message will break the simulation. In many cases this number is more than enough, although it is going to be easy to modify the Congurator and limit the VLAN number to 254 giving x the VLAN ID and add y to the host bits (mask: 16), increasing the maximum number of hosts per VLAN to 216 . 4) Trafc generation: The simulator is mainly focusing on OSI layer 2 (link layer) but in order to generate realistic trafc from the generators that already exist in OMNet++, higher layers are needed. On the mobile nodes side, the trafc must be differentiated and in order to be mapped to different queues through the whole network. This is achieved by the default behavior of layer 3 (IP in most of the cases) routing. Since all the interfaces in this simulator support 802.1Q they are going to create virtual interfaces on each host, giving the ability to generate trafc to different gateways (one for each subnet). Automatically this procedure is going to map the generated packet into a different VLAN. All the devices participating in the network have 802.1Q knowledge and thus they are going to map the trafc to different queues and services. This way of differentiating trafc seems to be most detailed and is the closest to a real-life deployment. B. Backhaul Network 1) OLT: The major network to be used for the aggregation is the EPON. This includes a series of modules and functionality. First an OLT (Optical Line Terminal) implementation has been done. The OLT operates at layer 2 as a bridge between the optical and the electrical network. Each LLID (Logical Link ID) dened in the OLT (on run-time) has a different queue and priority and nally it is mapped to a different VLAN on

Fig. 2.

End-to-end Trafc Differentiation

2) VLANS 802.1Q: In addition, VLANs were not implemented in the OMNet++ simulator so a simple implementation of the 802.1q has been done. The basic module created is the VLAN enabled Ethernet interface and its conguration for the run-time. The implementation is limited only to the very basic parts needed for trafc generation and differentiation.

1791

Fig. 3.

The OLT interface

the electrical network, which is the default behavior of the relay module. This module is registered as an interface, so it can easily be replaced and extended it in order to map trafc on different basis. The major options would be to map: (1) IP header DSCP values (layer 3) to LLIDs and (2) ports to LLIDs, assuming that the relay unit has multiple Ethernet ports. The most important modules designed are in the EPON/OLT optical interface. This includes three sub-layers, each one providing different functionality (Figure 3). Taking the layers bottom-up:

2) ONUs: ONUs were also implemented in the simulator in the same trend as the OLT module. They operate as a layer 2 switches by mapping LLIDs to VLANs and they also have the same layers in their optical interface. The difference is that the MAC control layer is much more complicated while the queue management module is much simpler. The way the EPON is currently designed, in the simulator, involves no polling. The OLT assigns start and length registers to the ONUs using MPCP GATE messages and the second ones are responsible for managing the time (and register shifts) using the global simulation clock. Thus the assumption that there is a mechanism for synchronization has been done. This assumption complicates the code of the ONUs a lot but avoids the propagation problems mentioned at [5] that are more noticeable in LR-PONs. Furthermore, for both ONUs and OLT a new queue creation module was designed in order to give the ability of logging packet drops, sent bytes, sent frames and rates for the dynamically created queues. That was a feature missing from OMNet++ due to non-copyable output vectors. To conclude, the above EPON module is the most developed and tested one in the simulator. It is designed to follow the standard, in most of the cases, and is totally extensible on the MAC and queue/scheduling layers. A public release of it (and the 802.1q VLANs) can be found at [15]. C. Access Networks 1) WiMax: INET/MANET framework of OMNet++ includes some code for 802.16 (underTest) but this found to be unusable, since the SS (Subscriber Station) cannot register with the BS. In addition the project seems abandoned and not updated. Another implementation that was found is Numbat [16]. As the project description says, it is mostly focused on DHCPv6 and was incompatible with the INET/MANET stack. Thus many missing parts have been developed for Numbat. The rst and most important is that the SS interface card created and integrated with INET/MANET protocol stack. Thus now is possible to add the interface on any pre-congured host (or even router) and use the INET framework capabilities. In the original implementation the SSs were able to request only one CID(Connection Identier). Multiple CID support added and the module is going to register to the hosts interface table one virtual interface for each non-control CID acquired. Furthermore rtPS service implemented so it currently supports BE, rtPS and UGS ows. Since multiple CIDs are now possible, a sophisticated scheduler has been developed for the WiMax BS. This is responsible for allocating symbols to each CID but at the same time it respects service priorities and MSR - MRR values. Once again MAC is a module interface for easy extensibility and scheduler changing. In addition, the old Numbat was working with IPv6 in the Convergence Sublayer (CS) of WiMax. IPv6 was taken out since integration with INET stack has been done, thus another mechanism needed to be developed. This is now done with VLANs and with a small modication on the registration process packet format.

epon mac: The MAC layer is responsible only for the actual transmission. This includes the Inter-Frame Gap (IFG). Modules above are responsible for calculating the required transmission time of each frame. oltMacCtl: The MAC control layer and is responsible for controlling when the interface is transmitting and when not. olt Q mgmt: The queue management module and is probably the most complicated one. At rst this module acts as a single queue so that the MAC control module can request frames. On second hand, it is responsible for ONU registration and queue creation. As a result, a different queue is dynamically created for each MACLLID pair. In addition, since this layer keeps all the information about the queues and the trafc load, it is the one to perform bandwidth allocation on the up-link. Thus most of the MPCP protocol functions are taking place in the queue module. MPCP protocol was also partially implemented in OMNet++ mostly for registration and GATE updates. Once again this is also an interface. A basic module is provided with all the tools and logging capabilities to do DBA but the default algorithm used is a round robin which will do fair allocation to each ONU ignoring services. Different behavior can be achieved by extending this module and overriding one function, which makes it very exible on comparison of different allocation algorithms.

1792

On the SS side analytical statistics can be collected from the dynamically created queues/ows. This is based on the same module used on the EPON project. SS mobility was also changed in order to be handle with the OMNet++ build in models instead of the custom implementation in Numbat. Finally a basic call admission control scheme for UGS service was implemented and the NACK messages for the registration process. From the above full functioning WiMax BS and SS are now available and compatible with OMNet/INET. To conclude this section, the above features were added and extensively tested but another problem arise when WiFi is added in the same scenario, which is going to be explained in the next section. 2) Wireless Channel Extension: OMNet++ by default supports only one wireless channel per simulation scenario. This becomes a limitation and results on WiFi mobile nodes to receive WiMax messages and the opposite when they co-exist. Also the radio receivers calculate the ranges based on the same frequency and channel characteristics. This problem was solved by making WiMax to register on a different ChannelControl module. The last module though is very closely cooperating with the build-in mobility modules that update the base station and nodes positions. Thus lots of the mobility code had to be changed and adapted to support heterogeneous wireless environment. IV. C ONVERGENCE In this section, the interconnection and integration capabilities of the modules developed are discussed. The subsections here include the architectures mentioned in section I, without MoF. MoF is more based on signal processing rather than messages/packets thus a different type of simulator is needed, not an event-based like OMNet++. A. Independent In the independent architecture the EPON and the WiMax networks are simply connected. This can be done without any modications on modules described above, since all of them support the common Ethernet interface and operate as layer 2 bridges. B. Hybrid In hybrid architecture, the ONU and the BS are build into the same box - module for the simulator. The copper Ethernet interfaces are no longer needed, so a new module can be created where the BS MAC layer will be directly connected to the ONUs relay module. Furthermore, some new messages need to be developed in order to enable information exchange between the two technologies. Alternatively the relay engine can be extended to control both optical and wireless submodules. C. Unied Connection-Oriented In this architecture the WiMax PDUs are also used on the optical network. This can be achieved by extending the Convergence Sublayer (CS) layer of the base station module.

Thus instead of de-capsulating the data from the PDU and re-encapsulating on Ethernet II frame, it is going to directly encapsulate the PDU (with the data) into the frame. This way the intermediate interfaces and modules will not need any modications. The hard part of this integration technique is going to be on the OLT side, where is should now operate as a WiMax BS also. Another layer can be created above the queuing management module to handle the PDUs, SS registration and symbol allocation. The required functionality though is located in the MAC layer of the BS, which has to be removed in this case. Thus moving it into the OLT and modifying it to take under consideration the ONUs, would make it work. D. Virtual This architecture requires a bridge module to be designed, which is going to be connected on both the BS and the ONU. A different interface can be used in each module as the control interface to the bridge. Some modication is going to be needed in these modules and a new protocol should be used for the signaling. From the changes needed for each architecture mentioned above, it is obvious that the developed simulator can be easily modied to support any of them. This is mainly due to the modular nature of OMNet++ which makes it highly extensible with reusable modules. V. S IMULATION R ESULTS In this section simple diagrams and statistics, that can be acquired from the simulator, are going to be presented. Since OMNet++ is used as the simulation framework, the result logging is very developed and tested. In addition the way it works, allows all the modules that take part in the simulation to log statistics, thus the results listed here are just examples focusing on the context of this work rather the simulators full capabilities. At rst, data rate allocation on FMC networks is most of the times the point of focus. Since the network is converged and consisting of sub-networks it is important that results can be acquired for each stage: per MN, per access network (technology specic probably), for the aggregation network and nally end-to-end. Results can be taken this way per service and the granularity can be changed. The same result can be acquired for each SS or BS. Furthermore these statistic come from the dynamically created queues mentioned in Section III which can also log the dropped bytes, thus a drop rate can be acquired the same way. Additionally, since both EPON and WiMax perform DBA with respect to service priorities, delay is a useful statistic that can conrm the correct operation of the schedulers and bandwidth allocation algorithms. The same options about granularity and nodes plotted can be applied on the delay measurements. The difference is that delay is end-to-end, including both aggregation and access networks. As an example, the Figure 4 show the average end-to-end delay for 18 SSs in an

1793

8 BSs scenario. Each SS runs up to three services (Voice,Video and Data).

convergence architectures. The sum-modules developed, their functionality and their extensibility was explained in this work. Furthermore a small discussion on how these modules can be used to form different integration scenarios was done. Finally some example outcomes from running a simulation scenario were presented in order to explain in which detail results can be collected and analyzed. For future work, a polling based MAC layer may be implemented for compatibility reasons with a variety of DBA algorithms working with this scheme. In addition some well known algorithms may be implemented for comparison purposes, like in example IPACT. VII. ACKNOWLEDGMENTS This work is partially funded by the EPSRC/TSB Project PAL and the University of Essex.

Fig. 4.

Avg. end-to-end Delay for 18 SSs in an 8 BSs scenario

R EFERENCES
[1] (2011) The PAL project. [Online]. Available: http://palproject.org.uk/ [2] (2010) IEEE p802.3ah ethernet in the rst mile task force. [Online]. Available: http://www.ieee802.org/3/ah/index.html [3] (2009) IEEE standard: Part 16: Air interface for broadband wireless access systems. [Online]. Available: http://standards.ieee.org/getieee802/download/802.16-2009.pdf [4] G. Shen and R. Tucker, Invited paper xed mobile convergence (fmc) architectures for broadband access: Integration of epon and wimax, Communications Magazine,IEEE, vol. 45, pp. 4450, August 2007. [5] H. Song, B.-W. Kim, and B. Mukherjee, Long-reach optical access networks: A survey of research challenges, demonstrations, and bandwidth assignment mechanisms, Communications Surveys Tutorials,IEEE, vol. 12, no. 1, pp. 112 123, rst 2010. [6] A. Dhaini, P. Ho, and X. Jiang, Wimax-vpon: A framework of layer-2 vpns for next-generation access networks, Optical Communications and Networking,IEEE/OSA Journal of, vol. PP, no. 99, pp. 400414, 2010. [7] K. Yang, S. Ou, K. Guild, and H.-H. Chen, Convergence of ethernet pon andIEEE 802.16 broadband access networks and its qos-aware dynamic bandwidth allocation scheme, Selected Areas in Communications,IEEE Journal on, vol. 27, no. 2, pp. 101 116, feb. 2009. [8] A. Varga. (2011) An extensible, modular, component-based C++ simulation library and framework, primarily for building network simulators. [Online]. Available: http://www.omnetpp.org/ [9] . (2011) An open-source communication networks simulation package for the OMNeT++ simulation environment. [Online]. Available: http://inet.omnetpp.org/ [10] Y. Yan, H. Yu, H. Wessing, and L. Dittmann, Enhanced signaling scheme with admission control in the hybrid optical wireless (how) networks, in Proceedings of the 28thIEEE international conference on Computer Communications Workshops, ser. INFOCOM09. Piscataway, NJ, USA: IEEE Press, 2009, pp. 109114. [Online]. Available: http://portal.acm.org/citation.cfm?id=1719850.1719869 [11] E. Cerqueira, L. Veloso, A. Neto, M. Curado, E. Monteiro, and P. Mendes, Qos support for multi-user sessions in ip-based next generation networks, Mob. Netw. Appl., vol. 13, no. 3-4, pp. 366384, 2008. [12] (2011, March) ns2 contributed code (updated 30 March 2011). [Online]. Available: http://nsnam.isi.edu/nsnam/index.php/Contributed Code [13] (2011, May) ns3 model library, release ns-3.11. [Online]. Available: http://www.nsnam.org/docs/release/3.11/models/ns-3-model-library.pdf [14] (2006, May) IEEE standard: Virtual bridged local area networks. [Online]. Available: http://standards.ieee.org/getieee802/download/802.1Q2005.pdf [15] B. Andreas. (2010) Epon module for OMNet++ simulator. [Online]. Available: http://sourceforge.net/projects/omneteponmodule/ [16] T. Mrugalski. (2010, 11) Mobile wimax, ipv6 autoconguration (with focus on dhcpv6) and some of the mobility related mechanisms in the Omnet++ environment. [Online]. Available: http://klub.com.pl/numbat/ [17] (2011) A high-level interpreted language, primarily intended for numerical computations. [Online]. Available: www.gnu.org/software/octave/

Finally more complicated analysis can be done using octave([17]). A library has been created to handle data aggregation/averaging and rate conversions. OMNet++ supports multiple runs using different conguration in order to compare results. Results aggregated per run can be used for plotting. As example the Figure 5 presents the average delay per second for the video service on a network with 8 BSs and 18 SSs while increasing the load (six runs). Load (L) is dened here as: generated traf f ic L= available bandwidth Furthermore, for each run described above, three different bandwidth allocation techniques used on the OLT resulting in a total of 18 runs.

Fig. 5.

Delay vs. Load using different bandwidth allocation techniques

VI. C ONCLUSION AND F UTURE W ORK In this paper a small introduction on EPON and WiMax technologies has been done and different architectures for integrating them have summarized. The main focus though is the simulator designed based on the OMNet++ and INET/MANET frameworks which support both technologies and most of the

1794

Das könnte Ihnen auch gefallen