Real-time ns3 emulation

Introduction
Cellular telephony is now an indispensable hallmark of modern life. The ability to communicate and connect to people, information and content is now always close at hand, and broadband mobile services will soon turn ubiquitous Internet connectivity into a commonplace affair. With the proliferation of mobile devices reaching staggering new numbers with each passing year, few technologies can be said to be as successful. The Cisco Global Mobile Data Trafﬁc Forecast Update for 2010-2015 estimates that mobile device adoption will have reached one device per capita globally by 2015 [1]. The role of the archetypal cell phone is now diminished in the presence of smartphones, tablets and other mobile broadband-capable devices that offer a more rich end-user experience than ever before. In 2010, smartphone usage doubled while three million tablets and 94 million laptops were connected wirelessly, resulting in a near tripling of global mobile data volume for the third consecutive year. The predictions for the coming years are even more astounding, with a projected 26-fold increase in mobile data trafﬁc between 2010 and 2015. While data-enabled mobile devices are becoming a part of everyday life, the technology behind modern cellular networks that makes it all possible is far from commonplace. Cellular systems represent the conﬂuence of some of the most advanced accomplishments in contemporary engineering. The technology has been in a perpetual state of accelerated evolution in attempt to keep up with growing demand and the mounting requirements of cellular networks.

Even as 3G systems such as 3GPP UMTS/WCDMA and now “3.5G” systems like HSPA+ are still in the process of being rolled out, we are beginning to see new standards emerge onto the mobile scene that promise to satisfy the ever-increasing thirst for data services. 3GPP Long Term Evolution (LTE) has come about amid a slew of competing next-generation cellular standards and has set the bar high in terms of low-latency and high-data rate performance. LTE, along with its counterpart set of standards known as System Architecture Evolution (SAE), is beginning to be widely embraced by operators that recognize its potential to meet the challenges of future networks. It is the product of major leaps forward in the science of wireless communications, the labor of thousands of engineers, and intense research efforts on the part of the industry and academic community.

Research institutions seem to have likewise grasped the potential of LTE, as count-less related studies are released every year that contribute to improving the standard and the fundamental technology. As such, it is still very much a work in progress, with signiﬁcant enhancements over the original standard being incorporated into each subsequent release of the LTE speciﬁcations. Researches are continually ﬁnding novel ways to increase throughput and spectral efﬁciency over the wireless channel, mitigate the effects of interference, optimize protocols, streamline network architecture, extend battery life for terminals, enhance data security and privacy and reﬁne every aspect of cellular communications. Such developments have enabled applications for mobile platforms that provide a level of functionality and access to content and multimedia over the Internet that was previously the exclusive domain of personal computers with wireline broadband connections.

In order to prototype new protocols and algorithms and improve upon existing ones, researchers establish wireless testbed systems on which perform experiments. These test environments are designed to reproduce the conditions of actual cellular deploy-ments in a lab setting and consist of a combination of software and hardware compo-nents such as channel emulators (for recreating the effects of an impaired channel on a wireless signal) and equipment for emulating base stations and mobile terminals. The majority of these testbed implementations are largely hardware-based and, while some vendors offer application-speciﬁc test equipment, many research testbeds make use of custom (often DSP and FPGA-based) hardware that can be programmed and tailored to suit speciﬁc experiments. Even so, the expense of such hardware and the difﬁculty of programming and conﬁguring custom electronics places practical limitations on the nature and scale of the simulated environments that can be employed for testing mobile systems.

Experiments involving real-time hardware emulation of components combined with actual software and hardware are referred to as Hardware-in-the-Loop or HIL simula-tions. The emulation hardware reproduces the “black-box” input and output character-istics of the respective system, while the components being tested feed inputs to the black box and respond to output ideally as they would in a real-world setting.

We propose an entirely software-based alternative to costly and inﬂexible HIL plat-forms used in the design and validation of next-generation cellular technologies. We in-vestigate a software-in-the-loop system by which actual applications and protocols can be integrated with a self-contained software simulation of a virtual LTE/SAE network. By making use of the open-source ns-3 network simulation framework, we implement several protocol models as part of our extended effort to develop a consummate model of a LTE/SAE network. By designing our software to take advantage of parallel com-puting architectures, we attempt to achieve real-time performance for simulating not only the LTE radio interface but higher-layer protocols in the access and core network as well, thereby offering all of the realism and accuracy of hardware emulators with the cost and conﬁgurability of a computer simulation. We ﬁnally demonstrate a proof-of-concept experiment involving end-to-end communication between mock hosts and User Equipment with real application data transmitted over a simulated network. Through our efforts, we hope to make strides toward creating a powerful tool that can be put into the hands of researchers enabling them to do rapid prototyping of the technology that will make the vision of the future mobile Internet a reality.

    This docume  nt is organized as follows. In Section 1, we outline the purposes and motivations behind our investigation and development efforts. In Sections 2 and 3, we lay down the high-level goals for the project followed by an assessment of speciﬁc system-level requirements. We then provide some background relevant to our software implementation. Section 4 presents some fundamentals of discrete event simulation. We then go over the basics of LTE/SAE protocols and architecture in Section 6 to aid in understanding the model implementation presented in Section 9. We test our core simu-lator and network model performance and demonstrate some proof-of-concept simula-tions in Section 10. Lastly, in Section IV, we conclude this thesis with some remarks on our results and progress in achieving our project goals and discuss the future direction of our work.

Motivations
<p style="margin: 0in 0in 10pt; text-align: justify; text-justify: inter-ideograph;"> There were many driving factors in seeking a novel software simulation platform. Chief among these are our desire to scale our simulations to a degree well beyond conventional research testbeds while still producing accurate, real-time behavior. Additionally, we require an enhanced level of ﬂexibility and control in order to manipulate every minute detail of our simulations. We now expand on each of these motivating factors.

==== <span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 11pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">Related Work -Limitations of Hardware Testbeds   ====

<p style="margin: 0in 0in 10pt; text-align: justify; text-justify: inter-ideograph;">  As a part of a larger research effort to investigate enhancements to LTE, this project came about after looking into alternative testbed solutions and realizing the shortcom-ings of available off-the-shelf products and custom development boards. The existing solutions that presented themselves generally fall into two categories, the ﬁrst of which being a system consisting of multiple proprietary hardware emulator boxes.1While a range of these products exist for emulating various network elements in the radio access and core network, they are typically only good for serving the role of one such device. Simulating any sort of practical and interesting cellular deployment scenario like the examples given in the next section would require an array of several of these devices.2The cost associated with each product makes this approach prohibitively expensive.3Furthermore, the most ﬂexible and extensible of these products still do not permit tun-ing and conﬁguration of every subsystem and protocol layer for simulated LTE devices such as user equipment. The other direction more often followed by academic research groups is the use of development boards, which provide embedded FGPAs that may be programmed with the LTE stack along with DSP modules for reproducing the low-level PHY and channel characteristics.4For most existing research testbeds of this variety, we again see the necessity of investing in several of these devices that must be indi-vidually programmed to simulate the role of a single network entity. For the types of experiments involving simulating large-scale networks we envisage, the complexity of conﬁguring and interconnecting a large number of these boards becomes intractable.

<h4 style="margin: 0in 0in 10pt; text-align: justify; text-justify: inter-ideograph;">  <span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 11pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">Testing and Prototyping of 4G Cellular Systems

<p style="margin: 0in 0in 10pt;">  <span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 11pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;"> Although production implementations of the LTE/SAE standard are, at present, offered for commercial use and networks are beginning to be deployed by operators globally, research and development activities are by no means stagnant. Long Term Evolution, by

<p style="margin: 0in 0in 10pt; text-align: justify; text-justify: inter-ideograph;">  <span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 11pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">1 Products such as LTE eNodeB and UE emulators are available through vendors like Aiglent [9].

<p style="margin: 0in 0in 10pt; text-align: justify; text-justify: inter-ideograph;">  <span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 11pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">2 Section 6.8.3 of [55] describes a testbed system employing four base station emulators for simulating a single multi-RAT cell.

<p style="margin: 0in 0in 10pt; text-align: justify; text-justify: inter-ideograph;">  <span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 11pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">3 Some of the least expensive products we found, such as the NI test suite in [2], are still in the ﬁve to ten-thousand USD range.

<p style="margin: 0in 0in 10pt; text-align: justify; text-justify: inter-ideograph;">  <span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 11pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">4 Some examples of FPGA-based LTE testbeds are given in [11, 12].

<p style="margin: 0in 0in 10pt; text-align: justify; text-justify: inter-ideograph;">  <span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 11pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">I t's very name, implies upgradability and extensibility in the long-term. The ambitious 3GPP Release 10 system, known as LTE-Advanced, is already planned as the next milestone along the LTE upgrade path that will bring us a true 4G-compliant standard. Such ambitious requirements, as outlined in Section 6, arguably will be crucial for operators and service providers to remain competitive in providing the fast, ubiquitous, on-demand connectivity and access to content services that future subscribers will come to expect. The challenges of future networks are many and must be addressed with innovative solutions from all angles. Here we have just a small selection of examples that are the focus of our research group alone.


 * <span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 11pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;"><span style="line-height: 115%; font-size: 12pt; mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;">Diverse, heterogeneous, self-organized networks <span style="line-height: 115%; font-size: 12pt; mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;">: The future mobile landscape is anything but uniform and homogeneous when it comes to interconnected tech-nologies and administrative domains. Already we are seeing diverse multi-operator environments that support a variety of radio access and core network technologies that must be seamlessly integrated to provide subscribers with constant, uninter-rupted service while roaming. It is well understood that central to the ability to handle the data trafﬁc volumes that we are seeing in modern cell networks is the notion of ofﬂoading of trafﬁc from macrocell to picocell and femntocell base stations and WLAN access points as well. The resulting environment is a dense, ad-hoc assortment of access technologies. Furthermore, the complexity of integrating 4G and legacy 3GPP and non-3GPP technologies within a single operator’s network combined with the necessity of internetworking with other domains will require novel methods for Inter-Cell Interference Coordination, Dy-namic Spectrum Access, cognitive radio and self-organizing, ad-hoc networking capabilities [3, 4, 5].


 * <span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 11pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;"><span style="line-height: 115%; font-size: 12pt; mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;">Mobility <span style="line-height: 115%; font-size: 12pt; mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;">: Mobility has been a chief concern of 3GPP technical speciﬁcations groups and, while the current standard incorporates procedures for seamless han-dover between various RATs, investigations are still ongoing in areas such as ver-tical handover between LTE and WLAN accesses and application-layer mobility [6, 7].


 * <span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 11pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;"><span style="line-height: 115%; font-size: 12pt; mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;">Transport and application-layer protocol optimization <span style="line-height: 115%; font-size: 12pt; mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;">: Many protocols running “over-the-top” of mobile networks, such as TCP and HTTP, were never designed for the trafﬁc patterns and conditions applicable to mobile settings. This lack <span style="line-height: 115%; font-size: 12pt; mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;">of cross-layer optimization potentially impairs performance, and so is an area worthy of investigation on its own.


 * <span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 11pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;"><span style="line-height: 115%; font-size: 12pt; mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;">Mobile cloud applications <span style="line-height: 115%; font-size: 12pt; mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;">: Cloud-based applications and services are ushering in a new era of computing in the way of functionality and robust end-user expe-rience. Software, storage and computation capacity are moving away from the end-user device and into the network, where they can be provisioned on-demand from anywhere with an Internet connection. The possibilities for business mod-els of mobile cloud and utility computing are already catching the attention of the industry since value-added services are a key source of revenue for operators and service providers. From an engineering perspective, however, the low latency and high data rate requirements of many cloud services make their integration into cellular environments difﬁcult.

====<span style="color: rgb(42, 42, 42); font-family: 'Segoe UI', Tahoma, Verdana, Arial, sans-serif; font-style: normal; line-height: 17px; "><span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 11pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">Opportunities for Collaboration and Cooperation ====

<p style="margin: 0in 0in 10pt;">It has always been our intention for our work to be a free, open source contribution to mobile research community at large. As our software implementation is itself based on the open source ns-3 framework, we hope to see our modiﬁcations and additions incorporated into the ns-3 project and made available to anyone interested in perform-ing large-scale network simulations. Any source code for the protocols or algorithms implemented on top of our simulation platform are also obtainable, along with doc-umentation, via the Web for individuals and research groups to experiment with and modify, hopefully inviting peer review and encouraging other research efforts to be combined with our own.5This level of collaboration would certainly not be possible if we had adopted a platform based on proprietary hardware and software.

===<span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 14pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">Goals ===

<p style="margin: 0in 0in 10pt;">One of the greatest challenges in research and development of wireless communications systems is that the standards and technology are in a constant state of ﬂux. Hardware-based testbeds may not offer the opportunity to extend the underlying components to reﬂect the changing technology. Software, on the other hand, can be modiﬁed with minimal cost or effort. While a software-based approach clearly wins out in this regard, for the purpose of testing actual applications and protocols in real time, these advantages cannot come at the cost of inaccurate emulated behavior or results. From these considerations, we arrive at the following fundamental goals for the project.

====<span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 11pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">Accurate Cellular Wireless Emulation in Software ====

<p style="margin: 0in 0in 10pt;">To provide a true emulation of something, the emulated system must appear to have the exact black-box input and output characteristics of the actual system. This of course means that processes of the emulation must mirror, in real time, the behavior of the real-world physical system. As we examine in Section 4.5, speciﬁc measures must be taken to enable real-time performance for software running on a non-real time operating system. In terms of our protocol representation, the effects of the wireless channel shall be simulated based on industry-standard models for statistical radio propagation, interference and error rate calculation. Upper layer protocols in the LTE stack and in the core network can then run ”as-is.” In other words, while our simulated version of said protocols may only provide some essential subset of features found in commercial applications of the same, they shall be correct in the sense of conforming to applicable speciﬁcations and RFCs and effectively be no different than the “real thing” in the way of bit-level accuracy of headers and encapsulated user-plane data as well as control-plane messages. Finally, through the use of virtual interfaces, known as TUN/TAP devices for Linux systems, we create a means of transporting real application data into and out from the simulation as if an application were running on a networked device. After accounting for each of these considerations, we believe our software can be made to realistically mimic the behavior of real-world cellular networks.

====<span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 11pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">Flexibility of Simulation Scenarios ====

<p style="margin: 0in 0in 10pt;">We have already emphasized our goals for simulation ﬂexibility, conﬁgurability and scalability. For the users of our platform who wish to design speciﬁc simulated topolo-gies and scenarios, the tools for building such scenarios come in the form of a modular Application Programming Interface (API). With this common API, users can instantiate network objects such as nodes, devices and links and deﬁne object parameters in a sim-ple program or script, which can then be executed from the user’s shell. Our API makes full use of the ns-3 object model for aggregating instances of protocols and devices to network nodes in a very user-friendly fashion. The ability to collect statistics and observe network objects is also an essential feature provided by the ns-3 trace system.

====<span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 11pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">Support for High-Performance Computing Systems ====

<p style="margin: 0in 0in 10pt;">When simulating large-scale networks with many objects in real-time, computational performance is key. For a system to be considered real time, it must be guaranteed to meet certain timing deadlines. So, in the case of discrete event simulation, as we shall introduce in Section 4, events occurring in the simulation time domain must be syn-chronized with the real time domain to a certain acceptable degree of deviation, beyond which simulation results can no longer be considered accurate. When adding to the algorithmic complexity or size (in the sense of number of objects) of a simulation, at a certain point the processing resources needed in order to maintain real-time perfor-mance will exceed what a single host machine can provide. To address this problem, our software must be designed to exploit parallel programming paradigms to make use of multi-core processors and clustered computing. High-Performance Computing (HPC) clusters can be built cheaply from off-the-shelf components and can be augmented with computational capacity simply by adding additional processors or compute nodes to the cluster.6It is our intention to develop algorithms that efﬁciently take advantage of clustered architectures so that simulations can be scaled with the underlying hardware platform. ===<span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 14pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">Needs Assessment ===

<p style="margin: 0in 0in 10pt;"><span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 14pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">From these general goals, we outline the following speciﬁc requirements for the system we are undertaking to implement in this and future iterations.


 * <span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 14pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">Accurate physical-layer emulation: The PHY layer protocols and channel model shall be accurate to the extent allowed by the ﬂoating point representation and operations of the underlying OS. Industry-standard models for representing inter-ference, fading, shadowing, and propagation loss shall be employed. Data rate, delay and block or bit error rate experienced by air-link signals shall correctly reﬂect varying channel conditions along with the speciﬁc modulation and coding scheme, channel bandwidth and resource allocation scheme.
 * <span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 14pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">Bit-level accuracy of user-plane protocols: Essential functionality of LTE and Evolved Packet Core user-plane protocols and procedures shall conform to 3GPP and IETF speciﬁcations. For the sake of efﬁciency, some control-plane functionality may be more loosely deﬁned, however the overall sequence of control messages or events should obey the standards.


 * <span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 14pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">Real-time synchronization of event sequence: Simulation events shall occur with within a speciﬁc range of wall-clock time. This range depends on the nature of the event and affected systems and is predetermined based on perceived effects on simulation accuracy. Events that fail to meet real-time deadlines shall be logged along with any causally-related events for analysis.


 * <span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 14pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">Parallel and distributed discrete event simulation: Algorithms for parallel and distributed DES shall be used that automatically (or with minimum interaction on the part of the user) take into account the nature of the simulation scenario along with the underlying computing platform and operating system capabilities to most efﬁciently distribute computation across available processing resources.


 * <span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 14pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">Application data tunneling through virtual network interfaces: A TUN/TAP de-vice, which is a virtual link-layer interface, shall be provided by the operating system through which data generated from the IP layer and above (including aux-iliary protocols such as ARP) can be tunneled between the OS and simulator program. Multiple instances of Virtual Machines (VMs) with TAP devices can be mapped to wireless User Equipment or wired hosts represented in the simu-lated network and real application data generated by these VMs can be thereby be transmitted and received across the network.


 * <span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 14pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">Modular object model and API: As discussed, network objects shall be con-structed in a modular and extensible way, allowing simulation parameters to be deﬁned in a script or at simulation runtime. We achieve this using the ns-3 ob-ject model and conﬁguration system. Classes deﬁning new applications protocols should be able to be easily integrated on top of existing protocol and network element objects.


 * <span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 14pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">Conﬁgurable trace and logging system: Logging of interesting statistics along with Operations, Administration, and Maintenance (OA&M) data can be enabled for collecting information on any given simulation object. This shall be done in an efﬁcient way that minimizes I/O operations (i.e. disk reads/writes) while balancing memory usage.

<h3 style="margin: 0in 0in 10pt;">DIscrete Event Network Simulation <p style="margin: 0in 0in 10pt;">Simulation is an invaluable tool for researchers across many disciplines, from the “hard” sciences and engineering to economics and social sciences. It allows us to analyze the behavior of interesting real-world and hypothetical processes under various conditions by reproducing that behavior in a virtual space [13]. A simulation, in the most general sense, is any system that imitates the behavior of another system according to a ﬁnite set of rules that govern the progression of the state of the system being modeled (or more speciﬁcally, the states of some composite elements of system) over time [14]. From this abstract deﬁnition, we can derive the essential ingredients of a simulation: the mathe-matical model of the physical system that we wish to represent, the states of the model, and the time over which the states are changing. The model dictates, either determinis-tically or stochastically, the transition of simulation states based on previous states and given inputs and initial conditions. As many complex physical processes are composed of a large set of variables that give way to an inﬁnite set of possible states, any prac-tical model must identify and isolate speciﬁc variables and data that are meaningful to providing an accurate imitation of the system, where the accuracy is proportional to the complexity of the model. While computers are the essential instrument for conduct-ing simulations, they have certain inherent limitations that pose analytical challenges in addition to the underlying difﬁculty in expressing complex physical systems. In the following sections and throughout this document, we expand on these issues in the di-rection of understanding discrete-event network simulation on a parallel and distributed microprocessor computers while making a point of identifying limitations and analyz-ing their effects on providing accurate and useful simulation results.

<p style="margin: 0in 0in 10pt; text-align: justify; text-justify: inter-ideograph;">Discrete-Event Simulation (DES) is a simulation technique that lends to modeling telecommunications networks. DES involves formulating state transitions as a sequence of events, which occur at discrete points in time. DES has its roots in discrete event system theory, which is a rigorously-deﬁned mathematical framework that we shall not directly pay any mind to because, when applied to representing communications networks, the concept can be simpliﬁed greatly [15]. If one grasps the very basics of packet-switched networking, it is straightforward to see how DES can be applied to simulate such systems. The model is made up of individual network elements, such as nodes, devices (i.e. interfaces), and links (channels), each element having its own set of states. For instance, the states of a node such as a IP router might consist of a packet queue for each port on the router. Network element are deﬁned by some state transition logic that determines its behavior based on its current states and input. Coming back to the router example, this logic may take the form of a routing table for making forwarding decisions. As mentioned, state transitions are driven by events, which are “scheduled” by being inserted into their chronological position in the future event set or queue. Events can be scheduled in order to represent the transmission or reception of a packet by our router. We can break down each of these aspects into three encompassing data structures: the set of state variables, a single event list, and a global simulation clock [14]. Parallel DES, which we shall later introduce, puts some interesting twists on these aspects. For now, we elaborate on these common components of DES.

====<span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 11pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">Time ==== As stated in [14], there are several notions of time to consider when simulating physical systems.


 * Physical time: This is the actual time of the physical system being modeled. For most real-world systems, the physical time domain is continuous.


 * Wall-clock time: The real time that elapses during simulation execution, which is independent from the physical time.
 * Simulation time: The representation of physical time in the simulation. Unlike the former cases, which are the same as the conventional notion of time, sim time is an entirely abstract notion. The simulation clock increments not with some regular period but, instead, hops from one event timestamp to the next as it progresses chronologically through the sequence of events. These timestamps are mapped into the continuous, physical time domain with the accuracy of whatever numeric data type, such as a double-precision ﬂoating point number, is used. In other words, events can be scheduled to occur at any instant of sim time that can be represented by the respective data type.

====<span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 11pt; mso-bidi-theme-font: minor-latin; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">Event Scheduling Algorithms ====

<p style="margin: 0in 0in 10pt;">Events, as we mentioned, are any conceivable occurrence that causes the progression of simulation states. Events can be anything from atomic operations, such as assignments to state variables, to complex subroutines that rely on dynamic input from multiple simulation objects. Global events (e.g. a command to terminate the simulation after a speciﬁc sim time) are those that have an effect on the simulation as a whole. More often, events are scheduled that affect the states of one or more local objects. In DES simulation of telecommunications networks, these local events may be scheduled to update the state of a particular network component. For instance, a packet transmission event may occur on a host node, triggering the node to then schedule a reception event on the destination node occurring after some transmission delay. When the simulation advances to the reception event, the event is executed and may result in a reply event to acknowledge packet reception. Similarly a host node may schedule an event for itself to retransmit a packet in the case that the host does not receive an acknowledgement after a certain time. As we can see, it is this modeling of a complex, causally-related chain of events (a relationship that may be unintuitive or difﬁcult to discern otherwise) that makes DES useful and interesting. The future event set or list is a data structure that implements, at minimum, the following operations. insert(E,t)Inserts a given event E with timestamp t.

extractExtracts the event with the lowest timestamp. When we consider how events may not be scheduled in the same order they are pro-cessed, that is, the sim time associated with an event yet to be inserted into the event set may come before (i.e. be lower than) the current lowest timestamp. This is illustrated in Figure 4.1.

<span style="line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 11pt; mso-bidi-font-family: "Times New Roman"; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-fareast-theme-font: minor-fareast; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">The underlying data structure is thus similar to a priority queue with the key dif-ference that insertions can occur at any position. Such a data structure should thus be optimized for fast insertions of this nature. Implementations using doubly-linked lists, set-associative containers such as the C++ STL std::mapclass and others can be found. 78A calendar queue is a data structure, ﬁrst introduced in [31], designed specif-ically for the future event set problem, and claims O(1)performance for both insertand extract(or enqueue and dequeue) operations. Other implementations are given in [32] and [33].

<span style="color: rgb(42, 42, 42); font-family: 'Segoe UI', Tahoma, Verdana, Arial, sans-serif; font-style: normal; line-height: 17px; ">testbed
<p style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; line-height: 15.75pt; background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: white; background-position: initial initial; background-repeat: initial initial;"> <span style="font-size: 10pt; font-family: Verdana, sans-serif; border-top-style: none; border-right-style: none; border-bottom-style: none; border-left-style: none; border-top-color: windowtext; border-right-color: windowtext; border-bottom-color: windowtext; border-left-color: windowtext; border-top-width: 1pt; border-right-width: 1pt; border-bottom-width: 1pt; border-left-width: 1pt; padding-top: 0in; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; ">OVERVIEW

<p style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; line-height: 15.75pt; background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: white; background-position: initial initial; background-repeat: initial initial;"><span style="font-size: 10pt; font-family: Verdana, sans-serif; border-top-style: none; border-right-style: none; border-bottom-style: none; border-left-style: none; border-top-color: windowtext; border-right-color: windowtext; border-bottom-color: windowtext; border-left-color: windowtext; border-top-width: 1pt; border-right-width: 1pt; border-bottom-width: 1pt; border-left-width: 1pt; padding-top: 0in; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; ">We propose the development of a small cellular wireless test system based on a National Instruments development platform. <span style="font-size: 10pt; font-family: Verdana, sans-serif; border-top-style: none; border-right-style: none; border-bottom-style: none; border-left-style: none; border-top-color: windowtext; border-right-color: windowtext; border-bottom-color: windowtext; border-left-color: windowtext; border-top-width: 1pt; border-right-width: 1pt; border-bottom-width: 1pt; border-left-width: 1pt; padding-top: 0in; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; "> <span style="font-size: 10pt; font-family: Verdana, sans-serif; border-top-style: none; border-right-style: none; border-bottom-style: none; border-left-style: none; border-top-color: windowtext; border-right-color: windowtext; border-bottom-color: windowtext; border-left-color: windowtext; border-top-width: 1pt; border-right-width: 1pt; border-bottom-width: 1pt; border-left-width: 1pt; padding-top: 0in; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; ">The initial use of the test system will be for the design and validation of algorithms in two key aspects of emerging cellular networks:

<span style="line-height: normal; font-size: 10pt; font-family: Verdana, sans-serif; border-top-style: none; border-right-style: none; border-bottom-style: none; border-left-style: none; border-top-color: windowtext; border-right-color: windowtext; border-bottom-color: windowtext; border-left-color: windowtext; border-top-width: 1pt; border-right-width: 1pt; border-bottom-width: 1pt; border-left-width: 1pt; padding-top: 0in; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; ">(i)<span style="font-size: 10pt; border-top-style: none; border-right-style: none; border-bottom-style: none; border-left-style: none; border-top-color: windowtext; border-right-color: windowtext; border-bottom-color: windowtext; border-left-color: windowtext; border-top-width: 1pt; border-right-width: 1pt; border-bottom-width: 1pt; border-left-width: 1pt; padding-top: 0in; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; "> <span style="font-size: 10pt; font-family: Verdana, sans-serif; border-top-style: none; border-right-style: none; border-bottom-style: none; border-left-style: none; border-top-color: windowtext; border-right-color: windowtext; border-bottom-color: windowtext; border-left-color: windowtext; border-top-width: 1pt; border-right-width: 1pt; border-bottom-width: 1pt; border-left-width: 1pt; padding-top: 0in; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; ">Fast intercellular interference coordination for strong and varied interference inherent in high density deployments, and

<p style="line-height: normal;"><span style="text-indent: -0.5in; font-size: 10pt; line-height: 115%; font-family: Verdana, sans-serif; border-top-style: none; border-right-style: none; border-bottom-style: none; border-left-style: none; border-top-color: windowtext; border-right-color: windowtext; border-bottom-color: windowtext; border-left-color: windowtext; border-top-width: 1pt; border-right-width: 1pt; border-bottom-width: 1pt; border-left-width: 1pt; padding-top: 0in; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; ">(ii)<span style="font-size: 10pt; line-height: 115%; border-top-style: none; border-right-style: none; border-bottom-style: none; border-left-style: none; border-top-color: windowtext; border-right-color: windowtext; border-bottom-color: windowtext; border-left-color: windowtext; border-top-width: 1pt; border-right-width: 1pt; border-bottom-width: 1pt; border-left-width: 1pt; padding-top: 0in; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; "> <span style="font-size: 10pt; line-height: 115%; font-family: Verdana, sans-serif; border-top-style: none; border-right-style: none; border-bottom-style: none; border-left-style: none; border-top-color: windowtext; border-right-color: windowtext; border-bottom-color: windowtext; border-left-color: windowtext; border-top-width: 1pt; border-right-width: 1pt; border-bottom-width: 1pt; border-left-width: 1pt; padding-top: 0in; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; ">Algorithms for cell selection and multi-flow in distributed and heterogeneous backhauls.

{C <span style="font-family: Verdana, sans-serif; font-size: 10pt; ">The detailed simulations can be performed on the testbed supplied by National Instruments. This setup has two PXI chassis with modules for RF, baseband and real-time network layer processing. National Instruments is also providing LabView-Based modules to emulate a 3GPP LTE physical layer so that we can test our algorithms on Industry standard cellular systems. {C <span style="font-size: 10pt; font-family: Verdana, sans-serif; border-top-style: none; border-right-style: none; border-bottom-style: none; border-left-style: none; border-top-color: windowtext; border-right-color: windowtext; border-bottom-color: windowtext; border-left-color: windowtext; border-top-width: 1pt; border-right-width: 1pt; border-bottom-width: 1pt; border-left-width: 1pt; padding-top: 0in; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; ">The LabView modules are based partially on <span style="font-size: 10pt; font-family: Verdana, sans-serif; border-top-style: none; border-right-style: none; border-bottom-style: none; border-left-style: none; border-top-color: windowtext; border-right-color: windowtext; border-bottom-color: windowtext; border-left-color: windowtext; border-top-width: 1pt; border-right-width: 1pt; border-bottom-width: 1pt; border-left-width: 1pt; padding-top: 0in; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; "> <span style="font-size: 10pt; font-family: Verdana, sans-serif; border-top-style: none; border-right-style: none; border-bottom-style: none; border-left-style: none; border-top-color: windowtext; border-right-color: windowtext; border-bottom-color: windowtext; border-left-color: windowtext; border-top-width: 1pt; border-right-width: 1pt; border-bottom-width: 1pt; border-left-width: 1pt; padding-top: 0in; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; ">FPGA IP cores licensed to NYU-Poly. The system has sufficient capabilities to simulate two base stations and two mobiles, each with 10MHz and 2x2 antennas. The initial test system will target a simplified version of the LTE standard, with

<span style="color: rgb(42, 42, 42); font-family: 'Segoe UI', Tahoma, Verdana, Arial, sans-serif; font-style: normal; line-height: 17px; ">List of people involved
1. Prof. Sundeep Rangan <p style="margin: 0in 0in 10pt;"><span style="color: rgb(42, 42, 42); font-family: 'Segoe UI', Tahoma, Verdana, Arial, sans-serif; font-style: normal; line-height: 17px; ">2. Russell Ford, Ph.D., Computer Science, Beginning 2010; B.S., Electrical Engineering , Florida State University, USA.

<p style="margin: 0in 0in 10pt;"><span style="color: rgb(42, 42, 42); font-family: 'Segoe UI', Tahoma, Verdana, Arial, sans-serif; font-style: normal; line-height: 17px; ">3. <span style="color: rgb(42, 42, 42); font-family: 'Segoe UI', Tahoma, Verdana, Arial, sans-serif; font-style: normal; line-height: 17px; ">Mustafa Akdeniz, Ph.D., Electrical Engineering, Beginning 2010; B.S., Electrical Engineering, <span style="color: black; line-height: 115%; font-family: "Calibri","sans-serif"; font-size: 11pt; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: "Times New Roman"; mso-hansi-theme-font: minor-latin; mso-bidi-theme-font: minor-latin; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA; mso-bidi-font-size: 10.0pt;">Boğaziçi University, Istanbul, Turkey

<p style="margin: 0in 0in 10pt;"><span style="color: rgb(42, 42, 42); font-family: 'Segoe UI', Tahoma, Verdana, Arial, sans-serif; font-style: normal; line-height: 17px; ">4. Trisharan Singh Kapoor, M.S. in Electrical Engineering, Beginning2010; B.Tech in ELectronics and Communication Engineering, G.G.S.I.P.U., India.

<span style="color: rgb(42, 42, 42); font-family: 'Segoe UI', Tahoma, Verdana, Arial, sans-serif; font-style: normal; line-height: 17px; ">5. Parisa Amirieliasi

<span style="color: rgb(42, 42, 42); font-family: 'Segoe UI', Tahoma, Verdana, Arial, sans-serif; font-style: normal; line-height: 17px; ">6. Changkyu Kim