project title: enhanced network security for seamless...

Deliverable D7.3 Dissemination Level: RE 317888-NEMESYS

October 2015 1

SEVENTH FRAMEWORK PROGRAMME

Trustworthy ICT

Project Title:

Enhanced Network Security for Seamless Service Provisioning in the Smart Mobile Ecosystem

Grant Agreement No: 317888, Specific Targeted Research Project (STREP)

DELIVERABLE

D7.3: Event-driven Simulation Experiments

Deliverable No. D7.3

Workpackage No.

WP7 Workpackage Title

Scenarios Development, Validation and Evaluation

Task No. T7.3 Task Title Simulation Experiments

Lead Beneficiary ICL

Dissemination Level RE

Nature of Deliverable P

Delivery Date 10 November 2015

Status Final

File Name NEMESYS_Deliverable_D7.3.pdf

Project Start Date 01 November 2012

Project Duration 36 Months


October 2015 2

Authors List

Author’s Name Partner E-mail Address

Leading Author / Editor

Omer H. Abdelrahman ICL [email protected]

Co-Authors

Mihajlo Pavloski ICL [email protected]

Gokce Gorbil ICL [email protected]

Erol Gelenbe ICL [email protected]

Francois, Frederic R ICL [email protected]

Elif T. Ceran ICL [email protected]

Yasin Murat Kadioglu ICL [email protected]

Lan Wang ICL [email protected]

Anastasios Drosou CERTH [email protected]

Ilias Kalamaras CERTH [email protected]

Stavros Papadopoulos CERTH [email protected]

George Lyberopoulos COSMOTE [email protected]

Eleni Theodoropoulou COSMOTE [email protected]

Konstantinos Filis COSMOTE [email protected]

Ioanna Mesogiti COSMOTE [email protected]

Reviewers List

Reviewer’s Name Partner E-mail Address

Max Suraev TUB [email protected]

Lombardo Dario TIIT [email protected]

mailto:[email protected]


















October 2015 3

Abstract

This deliverable describes SECSIM, a software tool for modelling and simulation and for evaluating cybersecurity of mobile networks. The report describes the simulation models that have been developed for UMTS and LTE networks; normal user behaviour including web browsing, SMS, instant messaging, as well as mobility within macro and small cells; machine to machine communications; and attacks scenarios such as signalling overload, SMS spam and fraud, and compromised femtocells. We then present a graphical user interface for SECSIM that has been built as part of the NEMESYS control centre, allowing an operator to remotely run, configure and retrieve the results of simulations. Finally, we present experiments illustrating the different attacks scenarios supported by SECSIM, and how the produced datasets can be used to evaluate some of the solutions developed by NEMESYS.


October 2015 4

Table of Contents

Authors List .................................................................................................................... 2

Reviewers List ................................................................................................................ 2

Abstract .......................................................................................................................... 3

List of Figures ................................................................................................................. 5

List of Tables .................................................................................................................. 5

Abbreviations ................................................................................................................. 6

1 Introduction ........................................................................................................... 8

1.1 Contributions of the Deliverable ..................................................................... 9

1.2 Organisation of the Deliverable .................................................................... 10

2 Related Work ....................................................................................................... 11

2.1 Commercial network simulators ................................................................... 11

2.2 Open source network simulators .................................................................. 13

3 Description of SECSIM Simulator ......................................................................... 16

3.1 UMTS Network Simulation Model ................................................................ 16

3.1.1 Protocol Stack ........................................................................................ 17

3.1.2 Network Nodes ...................................................................................... 18

3.2 LTE Network Simulation Model ..................................................................... 21

3.3 Mobility ......................................................................................................... 23

3.4 Normal User Traffic Models .......................................................................... 23

3.4.1 Web Browsing Model of the User .......................................................... 23

3.4.2 Instant Messaging .................................................................................. 25

3.4.3 Short Message Service ........................................................................... 26

3.4.4 M2M Communications .......................................................................... 26

3.5 Attack Models ............................................................................................... 27

3.5.1 RRC Signalling Storms ............................................................................ 27

3.5.2 SMS Spam............................................................................................... 27

3.5.3 Compromised Femtocells ...................................................................... 28

3.5.4 Botnet-like behaviour ............................................................................ 28

4 SECSIM View in the NEMESYS Control Centre ..................................................... 30

4.1 RRC attack parameters .................................................................................. 31

4.2 Spam SMS attack parameters ....................................................................... 32

4.3 Chat parameters ............................................................................................ 33

4.4 Simulation results .......................................................................................... 34

5 Simulation Experiments ....................................................................................... 35

5.1 RRC storms .................................................................................................... 35

5.1.1 Simulation scenario and setup ............................................................... 35

5.1.2 Results .................................................................................................... 36

5.2 SMS spam campaigns .................................................................................... 37


October 2015 5


5.2.2 Results .................................................................................................... 38

5.3 Compromised femtocells .............................................................................. 40


5.3.2 Results .................................................................................................... 41

6 Conclusions .......................................................................................................... 43

Annex I: Overview of the Result File Formats .............................................................. 46

Scalar files ................................................................................................................ 46

Vector files ............................................................................................................... 47

Annex II: Analysis Tools ................................................................................................ 48

Annex III: Overview of the Simulation Data ................................................................. 49

RRC Storms ............................................................................................................... 49

Compromised Femtocells ........................................................................................ 50

List of Figures

Figure 1: Modelled network elements. ....................................................................... 17

Figure 2: The control plane of the UMTS protocol stack. Highlighted areas are modelled in detail. ....................................................................................................... 18

Figure 3: The data plane of the UMTS protocol stack. Highlighted areas are modelled in detail. ....................................................................................................................... 18

Figure 4: The simulation model of a radio bearer, consisting of a (single server, single FIFO queue) pair in each direction. The uplink and downlink servers are located at the UE and the Node-B, respectively. .......................................................................... 20

Figure 5: (a) Overview of the RNC model, and (b) details of its RRC sub-module. ..... 19

Figure 6: Web traffic model representing interactive user browsing. ........................ 24

List of Tables

Table 1: Parameters of the web traffic model used in the simulation experiments ... 24

Table 2: Vector results for the RRC experiments ......................................................... 50

Table 3: Vector results for the compromised femtocells experiments ....................... 50


October 2015 6

Abbreviations

APP Application

BSC Base Station Controller

CMU Carnegie Mellon University

CHD Correspondent Histogram Descriptor

CS Circuit Switched

C&C Command and Control

DARPA Defence Advanced Research Projects Agency

EE-CNL End-to-End Communications Network Lab

GGSN Gateway GPRS Support Node

GPRS General Packet Radio Service

GTNetS Georgia Tech Network Simulator

GUI Graphical User Interface

HNB Home Node B

IDE Integrated Development Environment

IP Internet Protocol

IuCS Iu interface CS domain

IuH Iu interface HNB

IuPS Iu interface PS domain

LBL Lawrence Berkeley National Laboratory

LTE Long Term Evolution

MAC Medium Access Control

MNO Mobile Network Operator

MSC Mobile Switching Centre

NED Network Description

NeSSi Network Security Simulator

NEST Networked Embedded Systems

NET Network

NSF National Science Foundation

NSP Network service providers

OPNET Optimized Network Engineering Tool

PARC Palo Alto Research Center Incorporated

PARSEC Parallel Simulation Environment for Complex System

PDU Protocol Data Unit

PHY Physical Layer

Prowler Probabilistic Wireless Network Simulator

PS Packet Switched

QA Quality Assurance


October 2015 7

RB Radio Bearer

RNC Radio Network Controller

SGSN Serving GPRS Support Node

SNR Signal to Noise Ratio

SSDM Signalling Storm Detector and Mitigator

TCP Transmission Control Protocol

THD Time Histogram Descriptor

UCB University of California, Berkeley

UMTS Universal Mobile Telecommunications System

USC/ISI University of Southern California Information Sciences Institute

VINT Virtual Inter-Network Testbed

VoLTE Voice over LTE


October 2015 8

1 Introduction

Simulation has lately become very popular among telecommunication network researchers, operators, vendors and developers worldwide. This popularity stems from the fact that different sophisticated and powerful simulation packages are currently available, and also because simulation offers flexibility in model construction and validation. In the mobile network research area, it is quite difficult to deploy a complete test bed containing a large number of network elements (base stations, BSCs, MSCs) and users in order to validate and verify a new service, a certain network protocol or a specific network algorithm. In these circumstances, network simulators save a lot of money and time in accomplishing this task. Mobile network simulators are also particularly useful in allowing the mobile network designers, developers and vendors to test new protocols or to change the existing protocols in a controlled and reproducible manner. Simulations are particularly useful when the loss in accuracy is offset by the gains in scalability, since testbed-based experiments involving a large number of users can be difficult to implement.

Mobile network technologies keep developing very fast and there many different actors that participate in the process having different technologies or products running on different software. That is why the network simulations most of the times require open platforms which should be scalable enough to include a wide variety of topologies and the support of different technologies in the simulations of the whole network.

Network simulators are used by people from different domains such as researchers, industrial developers, and service providers to test the design, as well as verify and analyse the performance of different network protocols and services. They can also be used to evaluate the effect resulting from different parameters on the protocols and services under study. Generally, a network simulator will comprise of a wide variety of networking technologies and protocols and should offer users the ability to build complex networks from basic building blocks like clusters of nodes and links.

When developing new algorithms and adapting old ones it is much easier to evaluate them in a simulated environment than in a real network/system. In early stages of development, there may not even be a real system to test the algorithms in. Access to live commercially deployed systems may also be restricted for business related reasons, since these systems are used to generate business profits and they cannot afford downtimes or performance degradation caused by imperfect new services, algorithms and protocols.

Network simulators are used extensively in the mobile industry (operators, vendors, standardisation bodies, research centres, etc.) mainly for analysis, design and testing applications. By simulating different network types, technologies, elements, interfaces, features, and applications the end-to-end performance of different technology designs can be compared. Therefore, technology designs can be tested and demonstrated before production or installation, increasing R&D productivity and speed of deployment.

Mobile Network Operators (MNOs), in particular, make extensive use of network simulators for dimensioning purposes. Careful radio planning and coverage


October 2015 9

prediction can save a lot of money for an MNO, because the optimum number of base stations that are required to cover a particular area can be calculated with the use of suitable simulation tools. These tools can also be used for network coverage and capacity optimization purposes, thus providing the MNO with the required resources to offer enhanced quality of service with the minimum cost.

Network simulators can also be applied in the design and analysis of security services. Network service providers (NSPs), who strive to offer improved security features to their customers as a value-adding feature, have to devise a security framework in which detection devices are placed within the network. However, before doing so, NSPs should take into consideration that it is not desirable to make frequent alterations or test with different security deployments in the network infrastructure of a live system, because the risk of a failure, for example a loss of service, is too high. For this reason, network operators can benefit from a network simulation tool, which will provide them with the ability to test various features, including security architectures, in order to ensure that possible attacks will be efficiently detected before the actual deployment. The advantage of network simulators over conventional testbeds includes the low cost as well as the ease at which tests can be performed. In addition, possible hazard scenarios, which are called “what-if scenarios”, could be tested, something that, in general, may not be possible in real-world conditions. Network simulators provide NSPs the ability to experiment with different network security setups and algorithms in order to evaluate the efficiency of the intrusion detection as well as the operational costs. In this fashion, a security framework can be tested in a simulation environment in advance of the physical deployment of the actual detection units in the network ‎[19].

However, there are certain disadvantages in using simulations for large-scale mobile network security research. First, the use of simulators cannot guarantee 100% accurate predictions, which can only be achieved if the simulators capture exactly the characteristics of a real-life system. In practice, however, real-life network characteristics, parameters and complexities cannot be fully and accurately realised by any network simulator. Furthermore, the maintenance of simulation models is a major challenge, since having an outdated network representation is not useful, and larger networks tend to change more rapidly causing a large management overhead. These issues limit the advantages of network simulators, and they are typically resolved by using a combination of simulation and real world experiments.

1.1 Contributions of the Deliverable

The deliverable describes SECSIM, a modelling and simulation platform developed to support large-scale security analysis of threats against mobile networks. SECSIM has been designed with the ability to distribute different parts of the network over multiple physical or virtual machines to allow simulation of very large mobile networks. Built on top of the network simulation platform OMNeT++ ‎[1], SECSIM has a modular architecture enabling the addition of mobile traffic models derived from real network traces or based on new apps, devices and malware; it also combines packet-level and call-level representation of communications, thus improving scalability by modelling high traffic volume events like VoIP calls and multimedia


October 2015 10

streaming at the call level. This flexible architecture enables rapid testing of the network-based solutions developed in NEMESYS, and offers a valuable resource for evaluating different network configurations and settings.

1.2 Organisation of the Deliverable

The rest of the deliverable is organised as follows. In section ‎2, we present a brief review of existing simulation platforms for wireless networks, focusing on their capabilities, weaknesses as well suitability for evaluating the security of mobile networks. Section ‎3 presents a detailed description of SECSIM and its simulation models for UMTS and LTE networks, mobility, normal user behaviour as well as attacks. The graphical user interface (GUI) of SECSIM in the NEMESYS control centre is described in section ‎4. Section ‎5 presents simulation experiments illustrating the different attack scenarios that can be generated with SECSIM, and how the resulting datasets can be used for evaluating some of the solutions developed within NEMESYS. Finally, the report is concluded in section ‎6.


October 2015 11

2 Related Work

Existing mobile network simulators include commercial simulators, open source simulators and proprietary simulators developed within the context of special projects. The commercial simulators are developed to produce accurate and reliable simulations and can be very detailed and accurate in their predictions. The downside of this is that they are generally quite costly and difficult to be enhanced with new characteristics and features. Open source simulators are free and easy to improve. Their major benefit is the fact that they have a lot of expert users who provide their own improvements which make these simulators able to handle a large variety of simulation tasks. Proprietary simulators are usually not available for free use and can be directed towards very specific research purposes.

An indicative, non-exhaustive, list of existing mobile network simulation platforms is presented below. A technical and market-based comparison between SECSIM and the most popular mobile network simulators is presented in Deliverable 8.3 ‎[23].

2.1 Commercial network simulators

Valid8 Network Emulator

The Valid8 ‎[3] is a 3G/4G network emulation and load testing environment, which enables testing of difference network interfaces and nodes, with the possibility of including real base stations and mobile devices to evaluate the wireless interface. The tool supports the emulation of up to 1,000 mobile devices, and is used mainly for demonstration, testing and training related to existing protocols. However, it is not flexible to allow prototyping of new solutions, a feature which is critical for a mobile simulator aimed at large-scale security analysis.

Riverbed Modeler

Riverbed Modeler ‎[4] (previously known as OPNET) is the market leading network simulation software, which provides high-fidelity modelling and detailed analysis of a broad range of wired and wireless networks, including models for UMTS and LTE. However, OPNET has been traditionally used and developed to evaluate the wireless aspects of mobile communications, and consequently it offers very accurate models of the lower layers (PHY, MAC and RLC), but inaccurate models of the higher layer signalling protocols. For example, it does not support paging and includes a simplified version of the RRC state machine (no idle mode), rendering it ineffective for evaluating signalling storms that originate from such control plane aspects. Finally, the simulator has poor scalability (100s mobile devices), and its results files are in a proprietary binary format, making it difficult to use in the context of the NEMESYS project to generate simulation data to be analysed by other modules (e.g. visual analytics and anomaly detection modules). Indeed, ICL evaluated this simulator at the beginning of the project, and decided to build new simulation models based on the OMNeT++ simulation platform, due to the aforementioned weaknesses of Riverbed Modeler.


October 2015 12

QualNet

The QualNet communications simulation platform (QualNet) ‎[5] is a planning, testing and training tool that "mimics" the behaviour of a real communications network. QualNet is used for modelling large networks with heavy traffic. It consists of QualNet scenario designer, QualNet animator, QualNet protocol designer, QualNet analyzer, and QualNet packet tracer. QualNet is the commercial version of the open source simulator GloMoSim. The main strength of QualNet is that it is able to support thousands of nodes and a variety of machines and operating systems. However, QualNet does not have any predefined model constructs ‎[24].

NetSim

NetSim ‎[6] is a network simulation software for protocol modelling and simulation. It comes in three versions:

Pro version addresses the needs of defence and industry.

The standard version is used for education customers for carrying out network R&D.

The academic version is used for education customers for lab experimentation and teaching.

NetSim comes with an in-built development environment, which serves as the interface between the user’s code and NetSim's protocol libraries and simulation kernel. Protocol libraries are available as open C code for user modification. NetSim can be run on a variety of operating systems.

EXFO’s Network Simulation and Load Testing

EXFO offers test solutions ‎[15], covering the mobile network from RAN to IMS. EXFO’s solutions allow mobile operators and equipment manufacturers to verify their wireless networks before deployment by offering the ability to simulate a capacity of tens of millions of subscribers and thousands of network elements. In addition, hundreds of thousands of control-plane messages per second as well as hundreds of gigabits per second of user-plane traffic at line rate can be generated.

EE-CNL

End-to-End Communications Network Lab (EE-CNL) ‎[16] provides a “Live Network” in any customized package to suit test requirements. The EE-CNL comprises a set of PC-based simulators, popularly known as MAPS™. According to the manufacturer, all functionalities conform to industry standards providing reliable integrated solutions to vendors and service providers for simulation, monitoring and troubleshooting 2G, 3G and 4G mobile networks.

PRISMA’s simulators

PRISMA ‎[17] has developed a range of network simulating solutions for vendors and service providers who need integrated solutions for simulating, monitoring and troubleshooting their 2G, 3G and 4G mobile networks. PRISMA’s portfolio currently offers:

2G, 2.5G – Abis Simulator, A/Gb Simulator, MSC and SGSN/GGSN Simulator

3G – Iu Simulator; Iub Simulator


October 2015 13

4G – S1/X2 Simulator

According to the manufacturer, a full set of interface types is supported, including E1/T1, STM-1 SDH (channelized) as well as E1 over IP. Monitoring can be performed concurrently with simulation (both on the simulated interfaces and on those connected between real node elements), thus avoiding the need of separate instrumentation and allowing a significant cost reduction.

2.2 Open source network simulators

Ns-2, Ns-3

Ns-2 ‎[7] and its successor Ns-3 are two of the most widely used network simulators in use today. They are object-oriented discrete-event network simulators originally developed at Lawrence Berkeley Laboratory at the University of California, Berkeley, as part of the Virtual InterNetwork Testbed (VINT) project. Ns provides substantial support for simulation of TCP, routing, and multicast protocols over wired and wireless (local and satellite) networks. Ns has always included substantial contributions from other researchers, including wireless code from the UCB Daedalus and CMU Monarch projects and Sun Microsystems. The simulator can evaluate parameters associated with Enhanced UMTS performance (end-to-end delay, jitter, and throughput) to assess the impact of new protocols and architectures ‎[8]. Ns can simulate the layered protocols and application behaviors. Weaknesses include the fact that Ns needs recompilation every time there is a change in the user code; its software architecture is not well structured; the time it takes to perform a simulation can be very slow especially when the simulated network contains many nodes (more than 400) ‎[24]. Another weakness of Ns is the lack of graphical presentations of simulation output data ‎[25].

NeSSi

NeSSi (Network Security Simulator) ‎[18] is a novel network simulation tool which incorporates a variety of features relevant to network security distinguishing it from general-purpose network simulators. It can be used for security research and evaluation purposes since it supports profile-based automated attack generation, traffic analysis and support for the detection algorithm. NeSSi has been successfully used for testing intrusion detection algorithms, conducting network security analysis, and developing overlay security frameworks. However, it must be enhanced with more default attack scenarios and the already realized Bot Net infrastructure must be extended ‎[19].

GloMoSim

GloMoSim ‎[9] is a library-based simulator, developed at the University of California, Los Angeles, for mobile wireless networks. It is written in PARSEC (Parallel Simulation Environment for Complex System), which is an extension of C. GloMoSim is a scalable simulator that can be used to support research involving simulation and modeling of large-scale networks with thousands of nodes. The main strength of GloMoSim is its scalability to support thousands of nodes and executing simulation on multiple machines. Although GloMoSim was designed for both wired and wireless networks, currently it supports wireless networks only ‎[24]. The main disadvantage of GloMosSim is the fact that it is not regularly updated ‎[25].


October 2015 14

OMNeT++

OMNeT++ ‎[1] is an extensible, modular, component-based C++ simulation library and framework, primarily for building network simulators for wired and wireless communication networks. It supports sensor networks, wireless ad-hoc networks, Internet protocols, performance modeling, and photonic networks. OMNeT++ offers an Eclipse-based IDE and a graphical runtime environment. There are extensions for real-time simulation, network emulation, database integration, and SystemC integration. Although OMNeT++ is not a network simulator itself, it is currently gaining widespread popularity as a network simulation platform in the scientific community as well as in industrial settings, and building up a large user community. OMNeT++ provides a component architecture for models. Components (modules) are programmed in C++, then assembled into larger components and models using a high-level language (NED). OMNeT++ has extensive GUI support. However, OMNeT++ is a bit slow due to its long simulation run and high memory consumption. In addition, it is a bit difficult to use ‎[24].

GTNetS

The Georgia Tech Network Simulator (GTNetS) ‎[10] is a network simulation environment that allows researchers in computer networks to study the behavior of moderate to large scale networks, under a variety of conditions. In GTNetS, there is clear and distinct separation of protocol stack layers. Packets in GTNetS consist of a list of protocol data units (PDUs) that are appended and removed from the packet as it moves down and up the protocol stack. Simulation objects representing network nodes have one or more interfaces, each of which can have an associated IP address and an associated link. Applications in GTNetS can have one or more associated protocol objects, and can simulate the flow of data (including actual data contents) between applications. The main strength of GTNetS is that the design of GTNetS closely matches the design of real network hardware and therefore with a little knowledge of networking, the model can be constructed and simulated. However, it is still under ongoing development. ‎[24]

Akaroa

The ongoing research project of the Simulation Research Group, known world-wide as Akaroa, ‎[11], is aimed at developing techniques and methodologies for automated distributed simulation, suitable for quickly and reliably carrying out performance evaluation studies of modern multimedia telecommunication networks, by using the distributed computing power of a network of computers. The group has developed Akaroa2, ‎[12], a novel controller for distributed stochastic simulation, which is currently used by scientists at many universities and research laboratories in all continents. Akaroa represents one of the first applications of the concept of grid processing (distributed processing using multiple workstations). The main strength of AKAROA is its high speed in running simulations. However, AKAROA is a bit difficult to use ‎[24].

Prowler

Prowler (Probabilistic Wireless Network Simulator) ‎[13] running under MATLAB, provides an easy way of application prototyping with nice visualization capabilities especially for Networked Embedded Systems (NEST) - large-scale distributed systems


October 2015 15

with resource limited processing nodes tightly coupled to physical processes via sensors and actuators. Prowler is a probabilistic wireless network simulator capable of simulating wireless distributed systems, from the application to the physical communication layer. Although Prowler provides a generic simulation environment, its current target platform is the Berkeley MICA mote running TinyOS.

Wireless Network Simulator in Matlab

The Wireless Network Simulator in Matlab ‎[14] is a simple but complete mobile wireless network simulator in Matlab which provides free space, two-ray, and lognormal shadowing radio propagation and a random waypoint model for mobility. In the PHY layer SNR-based packet capture, broadcast, dynamic transmission rate and power are supported. Although this simulator is quite simple, its MAC layer supports only IEEE 802.11.


October 2015 16

3 Description of SECSIM Simulator

We have implemented our simulation models in OMNeT++ ‎[1], which is an object-oriented, modular, discrete-event network simulation framework. Because of its generic architecture, it is suitable to use for simulation in various domains, particularly systems that can be mapped into entities that communicate by exchanging messages. There are three main features of OMNeT++ that make it a suitable platform for building SECSIM:

Modularity – the modelling concepts in OMNeT++ are based on building simple modules, which can be reused in building more complex compound modules. All modules communicate between each other by messages. Regarding SECSIM, this concept is suitable for modelling the protocol stacks in a cellular mobile network, as well as modelling different network entities (mobile terminals, base stations, etc.).

Object-oriented approach – OMNeT++ uses this powerful programming concept by means of the C++ language to build its modules. While modules, messages and queues are designed in the Network Description (NED) language from the OMNeT++ class library, their functionality is programmed with C++ code. This feature is closely connected to the modularity, and advantages of object-oriented concepts like inheritance, polymorphism etc., could be fully used.

Parallelism – the feature of parallel distributed simulation is an emerging topic. It allows the model to be partitioned in logical processes which are simulated independently on different hosts or processors. This is an important feature for SECSIM as it needs to simulate real mobile networks with thousands of mobile terminals. The approach of OMNeT++ is that parallelism can be used only with modifications in the configuration, and not in the model.

Another useful feature is the flexibility of result recording and analysis. The simulator provides many techniques for result recording, and tools for data extraction and visualization. It also offers graphical and command line user interfaces, making it suitable for the visualization, remote configuration and execution of simulations. Finally, the simulator is highly portable with distributions available in most common operating systems (Linux, Mac OS/X and Windows).

3.1 UMTS Network Simulation Model

We have developed a discrete event simulation model of the UMTS network, focusing on the signalling layer in the radio access network (RAN), while accurately representing the data plane since it drives signalling events. Our simulation models support distributed simulation, allowing us to leverage multiple hosts and processors in a single simulation.

SECSIM supports the simulation of a single mobile network operator, and does not implement nodes and services required to enable roaming. Communications between the simulated network and other networks are represented by servers


October 2015 17

which simulate the interactions that may take place between a simulated user and another user who is not explicitly simulated.

Each node of the mobile network is represented as a self-contained and independent entity in the simulation, and nodes communicate through message exchanges, which are modelled based on the 3GPP standards for mobile protocols. We have developed models of the UE, Node-B, RNC, SGSN and GGSN, and also models of the Internet cloud and Internet hosts (i.e. servers) as shown in Figure 1. While we do not model the circuit-switched (CS) domain explicitly, the SGSN model contains aspects of the MSC server necessary to establish and tear-down CS calls, i.e. voice calls and SMS; our SGSN model is therefore a hybrid of the SGSN and the MSC server.

Figure 1: Modelled network elements.

3.1.1 Protocol Stack

In the control plane, we model the session management (SM), GPRS mobility management (GMM) and RRC layers in significant detail. In the user plane, we model different applications at the application layer, which includes CS and IP applications and allows us to differentiate between different types of user activity. We also realistically model the transport layer (TCP and UDP) and the IP layer. The parts of the control plane and data plane protocol stack implemented in our simulation models are shown in Figure 2 and Figure 3, respectively.


October 2015 18

Figure 2: The control plane of the UMTS protocol stack. Highlighted areas are modelled in detail.

Figure 3: The data plane of the UMTS protocol stack. Highlighted areas are modelled in detail.

We have a simplified model of the RLC layer, but we do not explicitly model the MAC and PHY layers; effects of changes in radio conditions are modelled as random variations in the data rate of the radio channels. In addition to the control plane protocols discussed above, we model the RANAP, NBAP and GTP protocols.

3.1.2 Network Nodes

The simulation model has a modular design consisting of simple and compound modules which facilitates code reuse and design.

3.1.2.1 Radio Network Controller

The RNC is the switching and controlling network element in the RAN, and performs radio resource management (RRM) functions in order to guarantee the stability of the radio path and the QoS of radio connections by efficient sharing and management of radio resources. The RRC protocol is utilized for all RRM-related control functions such as the setup, configuration, maintenance and release of radio bearers between the UE and the RNC. The RRC protocol also carries all non-access stratum signalling between the UE and the CN. In order to manage the radio resources, the RRC protocol associates a state machine to each UE, which is maintained synchronised at the UE and the RNC via RRC signalling messages. The RNC controls the transitions between the RRC states based on information it receives from the UEs and the Node-Bs on available radio resources, conditions of the currently used radio bearers, and requests for communication activity.


October 2015 19

The main functions of the RNC are implemented using the simulation model depicted in Figure 4(a) which consists of RAN (left) and CN (right) sub-modules, where details of each layer/component are hidden within these sub-modules:

rrc: handles signalling between the RNC and UE.

gtp: carries data packets to and from the core network according to GPRS tunnelling protocol.

netLayerRan and netLayeCn: for node addressing and packet encapsulation.

nicNodeB and nicSgsn: wired network interface cards for the RAN and CN.

Figure 4: (a) Overview of the RNC model, and (b) details of its RRC sub-module.

Figure 4(b) shows the details of the rrc model in the RNC, which includes of a logic element responsible for decision making and control, and for relaying data packets to and from the gtp component. The rrc sub-module also comprises a single signalling server (sigServer) and a single FIFO queue, used to model the processing time for RRC signalling messages. The server handles two classes of signalling messages, where one class consists of signalling messages that effect a state transition (e.g. the RB setup message), and the second class includes all other signalling messages, including mobility updates. The service time assigned to the first class reflects the time taken to allocate and de-allocate radio resources by the RNC, whereas a default and smaller service time is used for the second class (1 ms in our simulations). The values of the service times for the first class were chosen based on the typical processing required to effect a change that the signalling involves, for example setting up a radio bearer, and reflects the complexity of the procedure based on 3GPP standards. It should be noted that while these values are realistic, they are by no means definitive since the exact values are vendor-dependent. The signalling server at the RNC is one of the points of interest in our simulations on signalling storms.

3.1.2.2 Node-B

In our simulation model, node-B has minimum functionality, acting mainly as a relay between the UE and RNC, and is controlled by the RNC using the NBAP signalling


October 2015 20

protocol. The node-B simulation model is presented in Figure 5(a) which consists of simple sub-modules for mobility and network layer functions, in addition to a compound sub-module mobileNic, shown in Figure 5(b), which handles communications over the wireless interface.

Figure 5: (a) Node-B simulation model comprising simple sub-modules and (b) a compound sub-

module for the wireless interface.

As mentioned previously, we model changes in radio conditions as random variations in the data rate of the radio channels. In particular, uplink and downlink radio transmissions over a radio bearer (RB) are modelled by two single server FIFO queue pairs, one for each direction as shown in Figure 6. The service time at the transmission server, i.e. radio bearer, is calculated based on the length of the currently transmitted RLC packet and the current data rate for the RB. Changes in the RB data rate are reflected on the service time of the current packet. Each UE has one signalling RB and one data RB. In addition to the transmission delays for the RBs, propagation and processing delays are also modelled. We also model the usual communication delays (i.e. transmission, propagation and processing delays) over wired links connecting the different network elements, e.g. between the node-B and the RNC.

Figure 6: The simulation model of a radio bearer, consisting of a (single server, single FIFO queue)

pair in each direction. The uplink and downlink servers are located at the UE and the Node-B, respectively.


October 2015 21

3.1.2.3 User Equipment

The UE simulation model consists of a wireless interface element identical to the one at the node-B, an RRC and mobility modules, and terminal applications that interact with remote servers and generate user traffic such as web, instant messaging, VoIP, SMS, etc.

Figure 7: The UE simulation model.

3.2 LTE Network Simulation Model

This section summarises the changes that have been implemented in order to adapt the above simulation models for LTE. Indeed, utilizing the modularity and object oriented structure of OMNeT++ we have reused much of the work performed in developing the UMTS network modules in order to build the LTE simulation model. To this end, a new network has been constructed using the Network Description language, and modules from both UMTS access network and core network have been modified accordingly. Messages between modules have also been reused, apart from the ones which are specific for LTE and have been additionally created.

The network structure of LTE is shown in Figure 8. In the core network, the Packet Data Network (PDN) Gateway (PGW), or simply the Packet Gateway, is similar to the function of GGSN node in UMTS. It represents the network’s point of contact with outside world. We have modelled only minor changes from GGSN to PGW. The sgw_mme node represents both Serving Gateway (SGW) and Mobility Management Entity (MME), which handle the data routing and signaling functions of the SGSN. The sgw_mme node acts also as a mobility anchor point for inter-base station handover.Note that we do not include CS services in our LTE model, e.g. we do not support CS fallback for users that wish to make voice calls, and instead we model voice over LTE (VoLTE) in the same way as other VoIP service.


October 2015 22

Figure 8: The LTE network model.

Significant changes in the LTE model are related to mobility and connection management, and radio resource control. All of these functions have been moved from the RNC to the evolved NodeB (eNodeB), shown in Figure 9.

Figure 9: The Evolved NodeB model.

The eNodeB model in Figure 9 is similar in design to the UMTS NodeB, but the main difference is that it contains additional intelligence needed to perform the functions which are handled by the RNC in UMTS. Mainly, these functions are implemented in mobileNic module. The RRC as a signaling protocol between the UEs and eNodeB, allows the eNodeB to maintain the RRC state machine for every UE. The RRC protocol is modelled in detail, and it is significantly different from the one in UMTS, using a simplified state machine which includes only “Idle” and “Connected” states. These changes are implemented in both the UE and eNodeB modules. Since the RRC logic is now transferred to eNodeB, we have added two queues, sigServer and processor, to represent signalling and processing delays. The former represents the delays incurred by RRC messages due to other signalling traffic which is not explicitly modelled, while the latter represents the processing overhead for the RRC messages.


October 2015 23

Finally, because of its modular design, the LTE model can be enriched with other open-source module libraries that have been developed by the OMNeT++ community, such as ‎[22] which provides detailed models of the PHY and MAC layers.

3.3 Mobility

OMNeT++ provides a mobility framework that supports the introduction of new mobility models. In our simulations, all mobile devices move within the boundaries of the simulation area following a modified random waypoint mobility model, which we developed to enable UEs to preferentially move to areas covered by femtocells.

The standard random waypoint mobility model operates as follows. At the start of the simulation, all UEs are randomly distributed in the area. Each UE then selects a random location in the area and a random speed and proceeds to move to its chosen destination. When it reaches the destination, the UE waits for a random amount of time, and then repeats this process. In the modified version of this model, each area covered by a femtocell has a rectangular “attraction" area. Each attractor a has an attraction probability pa, i.e. when a UE selects a random destination, it has a probability of pa of choosing attractor a. The total probability of a UE selecting any of the femtocells in the area is then Σa pa, where the sum is taken over the set of all femtocells in the scenario. If the UE does not select any of the femtocell areas, then it proceeds with the normal destination selection process. Since the “normal" selection process is unaware of attractor areas, the UE may or may not select a femtocell area in this stage.

If the UE selects a femtocell area as its destination, then the amount of time it waits is chosen from a different probability distribution specific to that femtocell. Note that as a UE is moving across the simulated area to its destination, it may enter and then exit femtocell areas. Every time the UE attaches to a new macrocell or femtocell, the cell id is recorded in the simulation result files. When the UEs are operating according to a diurnal pattern, i.e. when the UEs are assumed to be inactive during the night, the UEs are immobile during their inactive period.

3.4 Normal User Traffic Models

In order to improve the performance of simulations and to be able to realistically evaluate large scale mobile networks, we combine packet-level and call-level representation of user plane communications in our simulation model. Communications that are message-based or bursty in nature are represented at the packet level; these include communications for SMS, email, web browsing, and instant messaging. Other types of communications are represented at the call level: examples include voice and VoIP calls, and multimedia streaming.

3.4.1 Web Browsing Model of the User

We model interactive web browsing behaviour using a self-similar traffic model as shown in Figure 10, where time is not drawn to scale. The parameters of the web traffic model are random variables from probability distributions; Table 1 gives the values we used in our simulations, which are based on web metrics released by


October 2015 24

Google ‎[2]. In addition to this random mode, the web application model also supports a scripted mode in which given user traces are replayed in order to inject browsing events at predetermined times.

Figure 10: Web traffic model representing interactive user browsing.

Name Description Value

pa Activity period Constant, 24 hours

da Activation delay (min.) Uniform(1, 10)

ds Initial session delay (mins) is/2

ns Number of main page requests in session

truncated normal μ=10, σ=5, min = 2

is Inter-session interval (min.) truncated normal, μ = 20, σ =10, min = 2

ir Inter-request interval (sec.) truncated exponential, λ-1 = 60, min = 10, max = 600

lr Request size (B) truncated normal, μ = 600, σ = 100, min = 300

lm Main page size, excluding embedded resources

Histogram [2]

limg Size of image resources (KB) truncated exponential, λ-1 = 50, min = 1.2, max = 400

ltxt Size of text resources Histogram [2]

ne Number of embedded objects in page

Histogram [2]

Rimg Ratio of image resources to all embedded resources in page

uniform(0.1,0.5)

dpc Processing delay, client (ms) truncated normal, μ =50, σ =10, min = 0

dps Processing delay, server (ms) truncated normal, μ =4, σ =1, min = 1

Table 1: Parameters of the web traffic model used in the simulation experiments

The day-night cycle of the user is represented by the activity period, which is the time the UE is actively generating web traffic during a 24-hour period. The idle period between two activity periods is the remaining hours within the 24 hours. The


October 2015 25

user starts its first activity period after an activation delay da, and the period consists of one or more browsing sessions. The first session within an activity period starts after an initial session delay ds, and the inter-session interval is is the time between the last and the first main request in one session and the next.

Within a session, the user generates main page requests and embedded object requests for web pages and the web objects embedded within the main page, respectively. The first main page request is scheduled at the start of the session, which results in a page response from the web server. This response is subject to a processing delay dpc at the client, which represents the time it takes for the web client at the UE to process the received response. A web page contains zero or more embedded objects, and the client generates an embedded object request for each one. We assume that HTTP version 1.1 is used and that each embedded object request is pipelined over a single TCP connection. The length of a request is denoted by lr. The inter-request interval ir is the time between the generation of two consecutive main page requests, and it is independent of the reception of the responses. The session length is controlled by the number of main page requests ns in the session.

The web server generates a response for each request it receives after a processing delay dps. The length of a main page response is lm, and it excludes the sizes of any embedded objects and TCP/IP headers. The number of embedded objects per page is ne, and we model two types of objects: images and text (e.g., CSS documents, scripts). The size of an embedded object is limg and ltxt for image and text objects, respectively. Rimg gives the ratio of image objects to all embedded objects in a page. In the simulations, a client selects a web server uniformly at random for each main page request.

3.4.2 Instant Messaging

Instant messaging (IM) applications are characterised by frequent, small data transmissions and a long tail distribution representing messages with media rich contents such as videos and photos. The IM application model consists of two distinct but related parts: message generator and responder. Each UE generates messages to chosen destinations, and also responds to received messages with a given probability. The message generator works based on sessions and waves. A session represents the duration that the user is actively generating messages, and consists of one or more waves where the messages are actually sent. At each wave, the user generates and sends one or more messages, the number and length of which are configurable with random distributions, to a single destination (mobile user) chosen at random. The time between waves within a session, the session duration and the time between user sessions are given by the interWaveTime, sessionDuration and interSessionTime parameters, respectively. On the other hand, the UE responds to each received message with a given probability, which is configured by the textresponseProbability parameter. Note that the responding to received messages is independent of message generation, and can occur both inside and outside of the user's IM sessions.

The final destination of a message can be another mobile in the same network or a mobile in another network (not explicitly simulated); mobiles in different networks


October 2015 26

are represented by one or more servers in the simulation, which act on behalf of these users. Mobiles in the same network are explicitly simulated. Regardless of its final destination, each message passes through an Internet chat server, which forwards the message to its final destination, i.e. another mobile user. We simulate multiple chat servers representing popular chat applications and services such as WhatsApp, Skype, etc., and currently assume that each message belongs to a chat application that is chosen uniformly at random from the available applications. The simulation model supports more generic message-to-application assignment based on other random distributions.

3.4.3 Short Message Service

The SMS application is similar to the IM application in that it consists of a message generator and a responder, and also operates based on the same concept of sessions and waves. Different from the IM application, we assume a single intermediate server within the mobile network that handles all SMS messages for that network, i.e. the SMSC server. SMS messages are also different than IM messages in their types. Each SMS message is assigned a type at creation time, which can also be inferred from its destination address (i.e. phone number); an SMS message can be classified as in-network mobile, out-network mobile, premium, and other, e.g. non-premium SMS based services, based on its destination. In-network mobiles are naturally represented by the UEs explicitly simulated; we represent the out-network mobiles, premium numbers and other destinations by servers outside the simulated mobile network, with one or more servers representing each class. Therefore, the type of a sent or received SMS can be inferred from its source and destination addresses (numbers). The type of the SMS message the UE generates is chosen at random based on the parameters of the SMS application.

3.4.4 M2M Communications

Machine-to-machine (M2M) applications are increasingly being deployed over cellular networks, and they typically use SMS or mobile data for communication. The simulation of M2M communications allows us to evaluate (i) how some of these critical applications are affected by network attacks, (ii) the negative impact that poorly designed M2M systems can have on mobile networks, and (iii) the accuracy of our anomaly detection algorithms, since some of these M2M applications exhibit attack-like behaviours (e.g. deterministic and synchronised communications and low response ratio) which may be misclassified by our algorithms.

The user traffic models described in the previous section can be configured in order to model different types of M2M systems. For example, we have simulated an M2M application for asset tracking where a cellular-enabled device periodically sends a single SMS to one of its servers, chosen at random. The device does not normally receive messages but may occasionally do so from its server (with a small probability). It also follows a diurnal cycle, which can be markedly different from regular mobile devices, representing for examples assets that are moved at night.


October 2015 27

3.5 Attack Models

3.5.1 RRC Signalling Storms

3.5.1.1 Aggressive Signalling Attackers

We consider two different attack strategies, or equivalently, misbehaviour patterns in our evaluation: FACH and DCH attacks. In FACH attacks, the attacker aims to overload the control plane by causing superfluous promotions to the FACH state, and therefore needs to know when a demotion from FACH occurs in the UE. In DCH attacks, the demotion of interest is from the DCH state.

To perform these attacks, the attacker would need to infer the radio network configuration parameters i.e., the RRC timers and the radio link buffer threshold, and also monitor the user's activity in order to estimate when a transition occurs so as to trigger a new one immediately afterwards. Naturally there will be an error between the actual transition time and the estimated one, which we represent by a random variable. Consequently, the rate of this error is a measure of the aggressiveness of the attacker.

In FACH attacks, the attacker sends a small data packet to a random Internet server in order to cause a promotion to FACH. Higher rate data traffic is generated in DCH attacks in order to cause the buffer threshold to be reached and therefore result in a promotion to DCH. For simulation purposes, our RRC model at the UE informs all registered malicious applications when an RRC state transition occurs. Before launching the next attack, the attacker waits for a period of time (representing the estimation error) after a suitable demotion is detected, e.g., from FACH to PCH in the FACH attack case.

3.5.1.2 Signalling-intensive Applications

This attack is based on a poorly designed application that sends periodic messages whenever the user is inactive, with the transmission period set to be slightly larger than the FACH or DCH timer in order to increase the chances of triggering state transitions. This behaviour represents the case where a mobile application or operating system uses a pull mechanism to fetch updates periodically, and the update period happens to ``synchronise'' with the RRC timer. However, unlike aggressive attackers, the misbehaving application cannot guarantee the generation of signalling traffic for each of its updates, since (i) the application only starts when local user activity stops but it cannot observe downlink traffic that may have restarted the RRC timer at the signalling server; and (ii) the data volume may not be large enough to trigger a promotion. In both cases, the periodic transmissions may become completely out of sync with the RRC state machine, therefore not generating any signalling traffic.

3.5.2 SMS Spam

The SMS spam traffic models are based on the SMS application described in Section ‎3.4.3. We model two types of SMS spam campaigns which are described in the following.


October 2015 28

3.5.2.1 SMS Spam Malware

The SMS spam malware model represents a mobile malware that sends spam SMS messages to the contact list of the infected mobile. The model is based on the generic SMS messaging model described in Section ‎3.4.3., but it does not have a diurnal cycle. The spam malware occasionally sends a configurable number of spam SMS messages, with each message being sent to a contact chosen randomly from the mobile's contact list, and the time between consecutive spam bursts drawn from a random distribution.

3.5.2.2 Dedicated Spammer

The dedicated spammer is assumed to be a server or other device connected to the mobile network and capable of sending SMS messages at a high rate. We assume that the dedicated spammer has obtained a list of the phone numbers of many mobile users, and frequently selects one or more users at random and sends a spam SMS message to each. However, while the dedicated spammer may know the phone numbers of many mobile devices, it does not know to what type of device the phone number corresponds, e.g. smartphone, tablet, notebook, M2M device, etc. The dedicated spammer sends one to two SMS messages to mobile devices in the network chosen at random, where the time between transmissions is assumed to be a random variable. The dedicated spammer follows the diurnal cycle, and does not respond to any received SMS messages.

3.5.3 Compromised Femtocells

We model compromised femtocells that generate revenue for the attacker by sending premium SMS messages on behalf of the UEs attached to them. In particular, a compromised femtocell misbehaves as follows: after a certain time has passed since a new UE has attached to it, the femtocell generates and sends one or more SMS messages to a premium number on behalf of the UE. Depending on the configuration of the femtocell, this behaviour can be repeated periodically as long as the UE is attached to the femtocell, or performed once at/near attach time.

The misbehaviour is triggered every time a UE attaches to the compromised femtocell. Therefore, if a UE goes out of the femto-cell's coverage and then comes back in again at a later time, the attack will be triggered again for the same UE. Also, due to the initial delay between the attach time of the UE to the femtocell and when the attack is triggered, a UE that just passes through a femtocell area without stopping there for long enough will not trigger an attack. Finally, the compromised femtocells adhere to the day/night cycle in order to reduce the probability of being detected and therefore attacks are not triggered for a UE if it is inactive.

3.5.4 Botnet-like behaviour

This behaviour represents command and control (C&C) activities which are common in botnets, and can be exhibited by any of the malicious applications described above. It also represents more broadly any communications that take place between the malware and its remote server to facilitate its illicit activities such as uploading private information, receiving instructions about premium destination numbers, etc. The behaviour is modelled using a simplified version of the IM application, where a communication can be initiated by either the application or the remote server. Such


October 2015 29

communications, however, do not immediately trigger malicious traffic (e.g. premium SMS) in order to reduce the chances of the remote server being detected.


October 2015 30

4 SECSIM View in the NEMESYS Control Centre

The configuration of the SECSIM simulator is accessible to the mobile network operator (MNO) through the integrated Graphical User Interface of the NEMESYS control centre, presented in Deliverable D6.2. The operator can run simulation experiments for a variety of scenarios, by specifying appropriate parameters, and retrieve the simulated data. The simulated data can be viewed in raw format, analysed using the data analytics methods, such as anomaly detection, or visualised using one of the available visual analytics tools.

The main window of the SECSIM simulator GUI within the MNO control centre is depicted in Figure 11. The parameters of the “New Dataset Properties” group allow the operator to generate a new simulated dataset.

Figure 11: The main window of the SECSIM simulator GUI.

The parameters for a new simulation are split into two groups. The “General parameters” group, to the left, contains the parameters that are common in any type of simulation. These parameters are the following:

The number of mobile devices to be considered in the simulation.

The duration spanned by the simulated data.

Whether the user mobility is enable or not.

Whether web browsing is enabled.

Whether an RRC attack is enabled.


October 2015 31

Whether SMS sending is enabled.

Whether a spam SMS attack is enabled.

Whether instant messaging (chat) traffic is enabled.

The “Specific parameters” group, to the right, contains parameters that are specific to the various scenarios enabled using the general parameters. The specific parameters for a scenario appear when the corresponding scenario is enabled. The specific parameters for the various scenarios are described in the following sections.

4.1 RRC attack parameters

The parameters controlling an RRC attack simulation, depicted in Figure 12, are the following:

The RRC state used for the attack, which can be either 'DCH or 'FACH'.

The number of UEs which use the RRC attack application.

The time instance at which the RRC attack starts.

The time instance at which the RRC attack stops.

By enabling the RRC attack simulation, the Signalling Storm Detector and Mitigator (SSDM) can also be enabled. The SSDM detection-related parameters are the following:

Whether the SSDM functionality is used.

Whether type 1 detection is enabled. This type of detection involves counting consecutive transitions to a channel (FACH or DCH).

Whether type 2 detection is enabled. This type of detection involves calculating a cost function based on usage of allocated resources.

The threshold of consecutive transitions. If this threshold is reached, an attack is detected.

The SSDM mitigation-related parameters are the following:

Whether mitigation is enabled in every UE.

The time instance at which mitigation should be switched on.

The time duration to block the communication of an attacking UE.


October 2015 32

Figure 12: Specific parameters of the RRC attack simulation.

4.2 Spam SMS attack parameters

The parameters controlling the spam SMS attack simulation are depicted in Figure 13 and are the following:

The number of UEs infected with the spam SMS-sending malware.

The average time between two waves of generated SMS messages.

The probability of an SMS message being sent to a premium number.


October 2015 33

Figure 13: Specific parameters for the spam SMS attack simulation.

4.3 Chat parameters

Finally, the parameters controlling the simulation of instant messages sent using chat applications are depicted in Figure 14 and are the following:

The average time between two waves of generated chat messages.

Figure 14: Specific parameters of the chat application simulation.


October 2015 34

4.4 Simulation results

The operator can enable any of the above normal or attack applications, or combinations of them, in order to generate the desired scenario. After the appropriate parameters are configured, the operator can send a simulation request to the SECSIM simulator, by pressing the “Run simulation” button. Once the data are generated and downloaded, the operator can view them in raw format, by pressing the “Raw data” button. This produces a presentation of the generated data in a table format, as depicted in Figure 15.

The data can also be visualised using the available visual analytics methods, by pressing the “Visualize” button. The visual analytics tools have been presented in Deliverables D5.2.3 and D5.3.2. Example visualisations produced from data generated by the simulator are presented in the following section.

Figure 15: Table view of the raw data generated by the simulator.


October 2015 35

5 Simulation Experiments

This section presents simulation experiments related to the attack scenarios that we described previously, and which show the capability of SECSIM in producing different datasets for evaluating other NEMESYS components. The UMTS network topology used in all our simulation experiments closely resembles the architecture shown in Figure 16.

Figure 16: The architecture of the simulated UMTS network.

5.1 RRC storms

We have conducted several simulation experiments to investigate the impact of RRC signalling storms and the anomaly detection algorithms that we have developed within NEMESYS. These experiments are reported in detail in ‎[20]‎[21]. This section presents simulation results to illustrate the capability of SECSIM in allowing detailed temporal discrete event representation of large scale multi-cell simulation, including user mobility, base station traffic, as well as the simulation of detailed communication and signalling traffic that is ongoing in the backbone network. The simulation scenario also allows for the evaluation of our signalling storm detector and mitigator (SSDM) ‎[20].

5.1.1 Simulation scenario and setup

The simulated network consists of 500 UEs in an area of 2x2 km2, which is covered by 7 NodeBs connected to a single RNC. The CN consists of the SGSN and the GGSN, which is connected to 14 Internet and messaging hosts acting as application servers. All UEs attach to the mobile network at the start of the simulation, and generate web browsing traffic following the model described in Section Web Browsing Model of the User. We assume that 20% of the mobiles are malicious or compromised, and overload the RNC by causing superfluous connection setup and release requests. The service times in the RNC have been artificially increased in order to simulate overload conditions with a small number of mobiles.


October 2015 36

5.1.2 Results

The results in Figure 17 show that the signalling misbehaviour increases gradually between 2800 and 4000 seconds from the beginning of the simulation, rather than suddenly which would create artefacts such as a huge spike of signalling load due to many devices attacking at the same time. Also, for the purpose of showing the effect of the storm and the proposed countermeasure, we only activate the detection and mitigation mechanism at 7000 seconds.

Figure 17(a) shows the number of signalling messages sent and received by the RNC during a simulation run. The application response time for a normal mobile is presented in Figure 17(b), which is the duration between the instant when the user requests a web page and when all of the web page has been received. The results are plotted over an averaging and sliding window of 50 seconds and for different values of the SSDM’s threshold n which operates as follows. The SSDM maintains a counter for each active mobile device, and if this counter exceeds n, indicating excessive radio resource control requests, the mobile device is temporarily blocked to avoid overloading the signalling plane.

It can be observed that the signalling load increases significantly as a result of the attack, which in turn increases the time it takes for a mobile to acquire a radio channel to send and receive data, leading to higher latency and jitter. However, the proposed detection and mitigation scheme quickly detects and then mitigates the attack, effectively bringing back the average response time for the normal users to the level it had before the storm. In particular, rapidly after the mitigation mechanism is enabled, if the mitigation counter is set to the optimum values of 2 or 3, the signalling load and the application response time drop to their values before the attack began. However if the mitigation counter is set to higher values, its usefulness is not apparent.


October 2015 37

Figure 17: Simulation results: time variation of (a) the total signalling load at the RNC, and (b) the

observed response time for applications for different SSDM thresholds.

5.2 SMS spam campaigns

This scenario includes multiple abnormal activities that appear simultaneously over a period of 14 days, and is intended to illustrate the capability of the NEMESYS visual analytics module in identifying such complex behaviours.


There are 3,158 UEs which belong to three main SMS classes: 2000 light SMS users with an average rate of 10 messages per day, 1000 heavy SMS users with an average rate of 20 messages per day, and 158 M2M devices which interact with two dedicated messaging servers. The scenario covers a period of 14 days, in which all users behaves normally for the first week, while different groups of users become infected with different types of SMS malware during the second week as follows:

50% of the light SMS users are infected with malware which acts by sending few SMS messages without discriminating between the hours of day and night. Therefore, these users do not follow a diurnal cycle during the attack days. The malware also sends messages at a low rate to a destination chosen uniformly at random from the user’s contacts, resulting in a uniform distribution of messages to the recipients during the attack days.

Half of the heavy SMS users and a final 25% group of the light SMS users become infected with a premium SMS dialler, as well as with multiple malware variants, triggering all of the above behaviours in combination with a high SMS traffic load.


October 2015 38

5.2.2 Results

The data obtained from SECSIM for the above simulation scenario can be visualised using the methods described in deliverables D5.2.3 and D5.3.2. Figure 18 shows an example using the multi-objective visualisation approach of D5.2.3. The data visualised in this figure correspond to the 14th day of the simulation, where all the simulated anomalies are activated.

Each point in the visualisation represents a mobile phone user. There are three apparent large clusters. The bottom cluster corresponds to the users behaving normally. The cluster appears to have an elongated shape, in contrast to the expected circular shape of clusters representing a common type of behaviour. This indicates that multiple types of behaviour exist in this cluster. Indeed, as verified by the Time and Correspondent Histogram Descriptors (THD and CHD) of this area, also depicted in Figure 18, the left part of the cluster corresponds to normal users of light usage, sending a small amount of SMS messages to a few contacts, while the right part corresponds to normal users of heavy usage, sending a larger amount of SMS messages to more contacts. The small circular cluster appearing to the left of the large bottom cluster corresponds to users communicating with only a single contact during this day, which renders their histogram descriptors identical to each other.

Figure 18: Multi-objective visualization of the 14

th day of the simulation, where all attacks are

active. The depicted histograms are example Time and Correspondent Histogram Descriptors (THD and CHD) from various areas of the user clusters.

The large circular cluster in the middle of Figure 18 corresponds to the users infected by the malware which does not discriminate between the day and night hours and moreover sends SMS messages to a uniform distribution of the user contacts. These


October 2015 39

characteristics of the malware are apparent in the shape of the histogram descriptors, which denote a large usage rate with a rather uniform shape.

Finally, the large circular cluster to the top of the figure corresponds to the users infected by the malware with the multiple types of attack activities, as well as the premium SMS messages attack. The behaviour of this malware is apparent in the shape of the histogram descriptors of this area, which denote a very heavy SMS usage rate during all day and towards all the user contacts.

Similarly, Figure 19 illustrates the abstract k-partite graph visualization of the 14th day of the simulation, where all attacks are activated. In this visualization, each node of the graph corresponds to one user in the dataset, while edges in the graph (hidden in this figure in order to reduce visual clutter) are used in order to connect the sources with the destinations of the communication events. Yellow colour represents the destinations and blue colour the origins of communications. In order to facilitate the reader the areas of interest (i.e. clusters of similar behaviour) have been manually highlighted with a green circle. In this respect and as shown in Figure 19, the visualization of the simulation data using the abstract k-partite graph allows for the identification of clusters of users with similar behaviours. Interactive analysis using the k-partite graph and the multi-objective visualization (see Figure 18) confirm each other by revealing the identifying the similar behavioural groups/clusters, as it was also verified with a comparison to the raw data generated by the simulator (see scenarios in Section ‎5.2.1).

Figure 19 Abstract k-partite graph visualisation of the 14

th day of the simulation, where all attacks

are activated. Each cluster corresponds to a group of users with similar behaviors (manually highlighted in the red ellipsoids). Yellow color represents the destinations and blue color the origins of communications.


October 2015 40

5.3 Compromised femtocells

In this section we present simulation experiments related to attacks from compromised femtocells, which has been applied to validate the anomaly detection algorithms developed in D4.3 ‎[26].


The simulated network has an area of 5km by 5km, fully covered by 7 macrocells, and with 13 femtocells distributed within the area, each with a randomly assigned range of either 20m or 50m. The femtocells are open access, representing small cells that are deployed to improve indoor coverage in shared spaces such as shopping malls and office buildings. The macrocells have a large range (> 1 km) and none of them are compromised. Mobile devices always connect to a femtocell if they are in range of one; otherwise they connect to a macrocell.

The simulation scenario consists of 10,000 UEs, which attach to the mobile network in the first 40 minutes and then remain attached for the total duration of the simulation which is 7 days. The SMS applications are activated between the first and the second hour in the simulation. The UEs have a diurnal cycle and are active for between 14 to 16 hours per day. Each UE has a normal SMS application running. There are three classes of normal SMS messaging users in the simulations: light, moderate, and heavy, with the messaging parameters given in Table 2 and Table 3. The interWaveTime parameter for all user classes is set to truncnormal(2min, 15s), and the UEs generate either 1 or 2 messages per wave, which is chosen uniformly at random for each wave. Table 2 also provides the average number of SMS messages sent (including generated and response messages) and received per UE during the simulated seven days.

SMS user class

No. of users

Session duration

Inter-session time

Response probability

Average no. of sent SMS (generated+ responses)

Average no. of received SMS

Light 4000

Truncated normal (2min, 15s)

Truncated normal (7h, 2h)

0.3 54 95

Moderate 3000

Truncated normal (5min, 30s)


0.4 105 120

Heavy 3000

Truncated normal (9min, 1min)


0.5 191 159

Table 2: SMS user classes in the femtocell experiments


October 2015 41

SMS address type

Message probability

Unpopular premium SMS scenarios

Popular premium SMS scenarios

In-network mobiles 0.54 0.49

Out-network mobiles 0.44 0.39

Premium numbers 0.01 0.1

Others 0.01 0.02

Table 3: Address-based SMS message generation probabilities in the femtocell experiments

The number and SMS application behaviours of the different types of SMS end-points in the simulations are given in Table 4.

Node SMS address type Total number

Generates messages

Responds to messages

UE In-network mobiles 10000 Yes Yes

Message server

Out-network mobiles 3 Yes Yes

Non-malicious premium 2 No Yes

Malicious premium 1 No No

Others 1 No No

Table 4: SMS messaging end-points

The simulator currently supports two types of femtocell misbehaviours:

Bursty attack: A compromised femtocell generates and sends a burst of 1 to 4 SMS messages to a premium number once at/near attach time of the UE.

Periodic attack: A compromised femtocell generates and sends a single SMS message to a premium number once at/near attach time and then periodically (once every hour) as long as the UE is attached to the femtocell.

5.3.2 Results

This section analyses the results of the compromised femtocells experiments, using the anomaly detection framework developed in deliverable D4.3. The bursty attack scenario is considered, where normal users are assumed to send premium SMS messages with probability 0.01, and there are two compromised femtocells that send a large number of premium SMS messages on behalf of the mobile devices connected to them.

To begin the analysis, the billing information collected from the mobile network is aggregated over periods of 30 minutes. Three types of information are included in the aggregated data, namely: 1) Sent SMS, 2) Sent premium SMS, and 3) Received SMS messages. This information is collected for each femtocell in the mobile


October 2015 42

network, and is subsequently fed into the Bayesian Robust Principal Component Analysis (BRPCA) method, presented in deliverable D4.3.

Figure 1Figure 20 presents the stacked graphs visualisation of the aggregated billing behaviour and the anomaly scores for the two compromised femtocells, which are numbered 10 and 19. A periodic behaviour can be observed in both the anomaly scores and the aggregated billing data, while the anomalous time periods for each femtocell can be easily identified from the large increase in the anomaly scores.

Figure 20: Stacked graphs visualisation for the two compromised femtocells, numbered 10 and 19.

On the contrary, Figure 21 illustrates the stacked graphs visualisation of the aggregated billing behaviour and the anomaly scores for two uncompromised femtocells, utilising the same time period that was used in Figure 20. In this case, the anomaly scores have a smaller value for all the time periods. In addition, there is no apparent periodic behaviour, since both the aggregated billing data and anomaly scores are more uniformly distributed when compared to the results shown in Figure 20.

Figure 21: Stacked graphs visualisation for two uncompromised femtocells, numbered 8 and 9.


October 2015 43

6 Conclusions

In this deliverable, we presented a critical review of existing simulation platforms for wireless networks, showing that the available simulators are not sufficient for analysing the cybersecurity of mobile networks. This is due to the fact that wireless simulations have been traditionally used in order to evaluate aspects of the physical and lower protocol layers, yielding very accurate simulations at the cost of scalability. This led us to building simulation models on top of the modular OMET++ simulation platform which enables different abstraction levels for modelling to achieve a good trade-off between accuracy and performance. In our simulation models, we have focused on specific layers of the control plane that are vulnerable to signalling attacks, while at the same time accurately representing the data plane since it drives signalling events. The resulting simulator, SECSIM, has been used extensively to evaluate the anomaly detection and visualisation techniques developed in the NEMESYS project. Experiments to illustrate the developed simulation models and attack scenarios have been presented in this report, together with examples of how the generated datasets are analysed by some of the NEMESYS components. In future work, we will continue the development of SECSIM models, and investigate the utility of integrating accurate physical layer models such as the open-source library developed in ‎[22].


October 2015 44

References

[1] A. Varga and R. Hornig. “An overview of the OMNeT++ simulation environment”. In Proceedings of the 1st International Conference on Simulation Tools and Techniques for Communications, Networks and Systems Workshops (Simutools’08), pages 60:1– 60:10, Mar. 2008.

[2] S. Ramachandran. (2010, May) Web metrics: Size and number of resources, Google, May 2010.

[3] Valid8 Network Emulator, http://www.valid8.com/

[4] Riverbed Modeler, http://gb.riverbed.com/products/performance-management-control/network-performance-management/network-simulation.html

[5] QualNet, http://web.scalable-networks.com/content/qualnet

[6] NetSim, http://www.tetcos.com/netsim_gen.html

[7] Network simulator ns2, http://www.isi.edu/nsnam/ns/

[8] M. Vranjes, S. Tomislav, and S. Rimac-Drlje. "The use of NS-2 simulator in studying UMTS performances", International Journal of Electrical and Computer Engineering Systems 1.2 (2010): 63-71.

[9] GloMoSim, http://www.scalable-networks.com/pdf/glomosim.pdf

[10] Georgia Tech Network Simulator (GTNetS), http://www.ece.gatech.edu/research/labs/MANIACS/GTNetS/index.html

[11] Akaroa, http://www.cosc.canterbury.ac.nz/research/RG/net_sim/simulation_group.shtml

[12] Akaroa2, https://akaroa.canterbury.ac.nz/akaroa/features.chtml

[13] Prowler, http://www.isis.vanderbilt.edu/projects/nest/prowler/

[14] Wireless Network Simulator in Matlab, http://wireless-matlab.sourceforge.net/

[15] EXFO’s Network Simulation and Load Testing, http://www.exfo.com/products/lab-manufacturing-testing/bu1-wireless-network-performance/network-simulation-load-testing

[16] GL’s End-to-End Communications Network Lab, http://www.gl.com/telecom-test-solutions/communications-networking-2G-3G-4G-lab.html

[17] PRISMA’s simulators, http://www.prisma-eng.com/solutions/network-equipment-manufacturers/dedicated-core-solutions/core-network-simulating-solutions/

[18] Network Security Simulator (NeSSi), http://www.nessi2.de/

[19] R. Bye, S. Schmidt, K. Luther, and S. Albayrak. “Application-level simulation for network security”. In Proc. 1st international conference on Simulation tools and techniques for communications, networks and systems & workshops (Simutools'08). Marseille, France, Article 33, 2008.

[20] NEMESYS deliverable D4.1, “Anomaly detection based on signalling protocols”, October 2014.

http://www.valid8.com/3G_Network_Emulator.html

http://gb.riverbed.com/products/performance-management-control/network-performance-management/network-simulation.html



http://web.scalable-networks.com/content/qualnet

http://www.tetcos.com/netsim_gen.html

http://www.isi.edu/nsnam/ns/

http://www.scalable-networks.com/pdf/glomosim.pdf

http://www.ece.gatech.edu/research/labs/MANIACS/GTNetS/index.html

http://www.cosc.canterbury.ac.nz/research/RG/net_sim/simulation_group.shtml

http://www.cosc.canterbury.ac.nz/research/RG/net_sim/simulation_group.shtml

https://akaroa.canterbury.ac.nz/akaroa/features.chtml

http://www.isis.vanderbilt.edu/projects/nest/prowler/

http://wireless-matlab.sourceforge.net/

http://wireless-matlab.sourceforge.net/

http://www.exfo.com/products/lab-manufacturing-testing/bu1-wireless-network-performance/network-simulation-load-testing

http://www.exfo.com/products/lab-manufacturing-testing/bu1-wireless-network-performance/network-simulation-load-testing

http://www.gl.com/telecom-test-solutions/communications-networking-2G-3G-4G-lab.html

http://www.gl.com/telecom-test-solutions/communications-networking-2G-3G-4G-lab.html

http://www.prisma-eng.com/solutions/network-equipment-manufacturers/dedicated-core-solutions/core-network-simulating-solutions/



http://www.nessi2.de/


October 2015 45

[21] NEMESYS deliverable D4.2, “Anomaly detection based on real-time exploitation of billing systems”, October 2014.

[22] A. Virdis, G. Stea, G. Nardini, "SimuLTE: A Modular System-level Simulator for LTE/LTE-A Networks based on OMNeT++", SimulTech 2014 , Vienna, AT, August 28-30, 2014.

[23] NEMESYS deliverable D8.3, “Market analysis and assessment”, April 2015.

[24] N. Sarkar and S. Halim, “A Review of Simulation of Telecommunication Networks: Simulators, Classification, Comparison, Methodologies, and Recommendations”, Multidisciplinary Journals in Science and Technology, Journal of Selected Areas in Telecommunications (JSAT), March Edition, 2011.

[25] S. Mallapur and S. Patil, “Survey on Simulation Tools for Mobile Ad-Hoc Networks”, IRACST – International Journal of Computer Networks and Wireless Communications (IJCNWC), ISSN: 2250-3501, Vol.2, No.2, April 2012.

[26] NEMESYS deliverable D4.3, “Anomaly detection within femtocell architectures”, October 2014.


October 2015 46

Annex I: Overview of the Result File Formats

Simulation data are available in two formats: scalar results in .sca files, and vector results in .vec files. Indices for the vector files are stored in .vci files used to speed-up processing of the vector files. Both output vector and scalar files are textual, line-oriented files, and therefore they can be viewed and processed with any data processing tool and programming language of choice.

Result files start with a header that contains several attributes of the simulation run: a reasonably globally unique run ID, the network NED type name, the experiment-measurement-replication labels, the values of the iteration variables and the repetition counter, the date and time, the host name, the process id of the simulation, random number seeds, configuration options, and so on.

These data can be useful during result processing, and increase the reproducibility of the results. Detailed information on the format of the result files is available at http://www.omnetpp.org/doc/omnetpp/manual/usman.html#sec548.

Scalar files

Scalar results are “summary" metrics, such as the total number of signalling messages received by the RNC, the mean of the packet sizes of uplink PDUs, etc. Scalar results can be sums, means, time averages, more detailed statistics (mean, count, std dev, min, max, etc.), and histograms; histogram results include the full statistics for the metric. Every scalar generates one line in the file, except for statistics and histogram scalars, which generate several lines.

The header of a scalar le looks like the following:

version 2 run Normal_Pch-0-20140413-19:24:33-5082 attr configname Static_Normal_Pch attr datetime 20140413-19:24:33 attr experiment Static_Normal_Pch attr inifile omnetpp.ini attr iterationvars "" attr iterationvars2 $repetition=0 attr measurement "" attr network GenericNet attr processid 5082 attr repetition 0 attr replication #0 attr resultdir results attr runnumber 0 attr seedset 0

The rest of a scalar le contains the scalar results: ... scalar MNet.ues[0].app session.count 2 scalar MNet.ues[0].app html.requested 20 scalar MNet.ues[0].app html.received 20 scalar MNet.ues[0].app html.errors 0 scalar MNet.ues[0].app sock.opened 40 scalar MNet.ues[0].app sock.broken 0 ...

http://www.omnetpp.org/doc/omnetpp/manual/usman.html#sec548


October 2015 47

Each “normal" scalar result is recorded on a single line. A histogram scalar however occupies several lines: ... statistic MNet.ues[0].apps[0] rtt:histogram field count 621 field mean 1.2970212116002 field stddev 0.74738951780857 field sum 805.45017240374 field sqrsum 1391.0124351194 field min 0.033891096559 field max 3.021663929799 attr interpolationmode none attr source responseTime attr title "response time, histogram" bin -INF 0 bin -0.1577202558245 0 bin -0.037853926774433 4 bin 0.082012402275633 6 bin 0.2018787313257 21 bin 0.32174506037577 38 bin 0.44161138942583 57 bin 0.5614777184759 35 bin 0.68134404752597 25 bin 0.80121037657603 26 ...

Vector files

Vector results are time series data, in the format of (timestamp, value), where timestamp is the simulation time when the event happened, e.g. when a packet was received, and value is the corresponding value for the event, for example the size of the received packet. For multi-column results such as (timestamp, source, destination, size, etc.), multiple vectors (one for each column) are recorded, which can be joined in post-processing if desired. All output vectors from a simulation run are recorded into the same file. An example fragment from a vector file, without the header, looks like this: ... vector 1 net.host[12] responseTime ETV 1 12.895 2355.66 1 14.126 4577.66664666 vector 2 net.router[9] queueLen ETV 2 16.960 2 1 23.086 2355.66666666 2 24.026 8 ... There two types of lines: vector declaration lines that begin with the word vector, and data lines. A vector declaration line introduces a new output vector, and its columns are: vector id, simulation module that created the vector, name of the vector, and multiplicity (usually 1). Actual data recorded in this vector are on data lines which begin with the corresponding vector id. The most important columns on data lines are the simulation time and the recorded value.


October 2015 48

Annex II: Analysis Tools

OMNeT++ provides an analysis tool in its simulation IDE, which can be used to view the data, perform simple data analysis, and produce plots. The analysis tool lets you load several result files at once, and presents their contents somewhat like a database. You can browse the results, select the particular data you are interested in (scalars, vectors, histograms), apply processing steps, and create various charts or plots from them. Data selection, processing and charting steps can be grouped together and stored as “recipes", which get automatically re-applied when new result files are added or existing files are replaced. This automation spares the user lots of repetitive manual work, without resorting to scripting. The analysis tool is described in more detail at http://www.omnetpp.org/doc/omnetpp/UserGuide.pdf. Note that while the analysis tool is great to visually interact with small datasets, it may be very slow when the datasets are large.

The scavetool command-line utility program provides some of the functionality of the analysis tool, while allowing you to use shell scripts to automate parts of the data analysis. It allows filtering of data, and can convert results to various le formats such as csv. The scavetool is described at http://www.omnetpp.org/doc/omnetpp/manual/usman.html#sec417.

Note that since all result files are text-based, any data analysis tool or program can be used for post-processing, e.g. Python, Matlab, R, etc.

http://www.omnetpp.org/doc/omnetpp/UserGuide.pdf

http://www.omnetpp.org/doc/omnetpp/manual/usman.html#sec417


October 2015 49

Annex III: Overview of the Simulation Data

RRC Storms

Table 5 presents the vector metrics in the results of the RRC signalling storms experiments. Note that many more vectors are available from the simulation, but we have only collected the vectors of interest for the visualization of RRC attacks in these simulations. In these vectors, a tuple is inserted every time a relevant event occurs at the module that is recording the vector. For example, for the queue length metric an event is inserted to the vector every time the queue length changes. Note that the * symbol is a wildcard, e.g. ues[*] means “for all UEs in the simulation”. From these vectors, it is possible to calculate other metrics, such as RRC session duration per UE, distributions of the packet sizes for uplink and downlink PDUs per UE, packet rates, etc. There are also many scalars that are collected in the simulation results, and it would not be practical to list them here.

Node Module name Vector name Description

RNC

GenericNet.rnc.rrc.ranap.logic

numSigSentRan Number of signalling messages sent to the RAN (to the UEs and the NodeBs) for each significant RRC event

numSigSentRan Number of signalling messages sent to the CN (to the SGSN) for each significant RRC event

numSigSentRan Packet length (bytes) of each signalling message received from the RAN

recvdCnSigPkts Packet length (bytes) of each signalling message received from the CN

GenericNet.rnc.rrc.ranap.sigServer

queueLength Queue length, in terms of number of messages, of the RRC signalling server

queueingTime Queueing time (seconds) of each processed RRC signalling message

UE

GenericNet.ues [*].appLayer.tcpApps[0]

sessions Start of a browsing session

GenericNet.ues [*].rrc

sentDataPkts Packet length (bytes) of each sent uplink PDU

recvdDataPkts Packet length (bytes) of each received downlink PDU

sentSigPkts Packet length (bytes) of each sent uplink RRC signalling message

recvdSigPkts Packet length (bytes) of each received downlink RRC signalling message

rrcState Current RRC state (1: Idle, 2: PCH, 3: FACH, 4: DCH)


October 2015 50

Node Module name Vector name Description

GenericNet.ues [*].sm.gmm

gmmState Current GMM (mobility) state (1: Detached, 2: Idle, 3: Connected)

sentSigPkts Packet length (bytes) of each sent uplink SM/GMM signalling message

recvdSigPkts Packet length (bytes) of each received downlink SM/GMM signalling message

Table 5: Vector results for the RRC experiments

Compromised Femtocells

The main vectors of interest collected in these simulations relate to the generation and reception of SMS messages by UEs in the mobile network. In addition to these SMS-related data, we also collect vectors of cell ids from UEs as described in Table 6.

Node Module name Vector name

Description

UE

FemtocellNet.ues[*].mobileNic.sender

cellId Each entry contains the cell id that the UE camps on and the timestamp (in seconds) when the UE attached to that cell. An entry is added whenever the UE changes the cell it camps on.

FemtocellNet.ues[*].appLayer.udpApps[0]

sentMsgs Each entry contains the destination address (node id) of the sent SMS message and the timestamp (in seconds) when the message was sent. An entry is added for each SMS message the UE sends. The type of the SMS message can be inferred from the destination address.

FemtocellNet.ues[*].appLayer.udpApps[0]

recvdMsgs Each entry contains the source address (node id) of the received SMS message and the timestamp (in seconds) when it was received. An entry is added for each SMS message the UE receives. The type of the sender (e.g. whether it is coming from a mobile in a different network) can be inferred from the source address.

Table 6: Vector results for the compromised femtocells experiments

project title: enhanced network security for seamless...

Documents