Computer Communications

This data set is for running simulation for NDN and mostly on my CCndnS caching policy. some data for random and popularity based caching policies are provided as well. The name of the folders indicates the cache size of each Content Store (CS). Depends on topology of the network (Abilene, Chained and Chained with branches), there are different set of sources of files and content requesters. The measured values from client side is saved in a file with name ClinentX or Client_Rx. The data related to each router is presented in a file with the name of the router. For Abilene network, you can find the topology and the name of the routers in my paper. Be noted that in my paper routers' name starts from 1 (R1) but data files router name starts from 0. So R1 in the paper is R0 in the data set. There is one more file in each folder which provides the general information about the simulation like the cache size of each router, total Interests generated in the simulation or total network hit probability which is the probability of finding data from the network regardless of which router cached data. The name of some of the folders is like "alpha0.8". That means the parameter alpha for zipf distribution is set to 0.8 in this set of simulations. Folders with name "SLA" belongs to Service Level Agreement application that I explained in my paper. Many parameters can be found with value 0. These are parameters that I deactivated in this set of simulations but in general they can be measured. I used them for other studies.

data from three entire days: (1) before Black Friday (Nov/21/2014); during Black Friday (Nov/28/2014); and (3) after Black Friday (Dec/05/2014). There are different sections of network traffic: (1) normal; (2) DDoS; (3) Flash Crowd; and (4) Flash Crowd + DDoS which is a very rare scenario. Since the IP of hosts are confidential, they are masked by letters (one letter represents just one number). The data in this repository is related to site P (78 samples with around 500,00 records each). The dataset is available in the CSV format (text). The fields are limited by apostrophe, separated by semicolon and compressed with 7z. Mirror at: https://uspbr-my.sharepoint.com/:f:/g/personal/and1970_usp_br/EvRKMh0d3slPpDkdZgBuR-oBULsPbgnHvnsqC9P5UzBFOQ?e=TAgPyc . A complete version of this dataset with all the e-commerce sites can be found at: https://uspbr-my.sharepoint.com/:f:/g/personal/and1970_usp_br/EvYstyiZiWdEhOfiI21IOWwB1lCHXsrNUKPpBx7-z1rnWQ?e=efkCVa Please in case of use, cite our original researches: 1) Grouping Detection and Forecasting Security Controls Using Unrestricted Cooperative Bargains; 2) A Proposal to Distinguish DDoS Traffic in Flash Crowd Environments.

The four datasets include the evaluation of various opportunistic routing protocols in four datasets (Reality, Dartmouth, Lyon, INFOCOM2005) using the Adyton simulator (https://github.com/npapanik/Adyton). More specifically, the datasets include the performance data (performance metrics), the processed data used to build the decision matrix and the scoring results for the examined routing protocols using different combinations of decision-making and weighting methods. The four datasets correspond to the four experiments presented in the manuscript entitled "A framework for the evaluation of routing protocols in opportunistic networks". The file ranking-tables.xlsx contains an example highlighting the pitfalls in using traditional performance metrics when ranking protocols using MCDM methods. The example ranks the performance of six well-known opportunistic protocols in the Dartmouth dataset using the SAW decision-making method and the MW weighting method. There are two rankings, one produced using traditional performance metrics and the other using the proposed normalized metrics. The example corresponds to tables 2,3,4 and 5 of the manuscript "A framework for the evaluation of routing protocols in opportunistic networks".

Spectrum scarcity is a critical problem that may reduce the effectiveness of wireless technologies and services. To address this problem, different spectrum management techniques have been proposed such as overlay cognitive radio (CR) where the unlicensed users can share the same spectrum with the licensed users. The main challenges in overlay CR networks are the identification and detection of the Primary User (PU) signals in a multi-source narrow-band interference (NBI) scenario. Therefore, in this paper, we investigate the performance of an orthogonal frequency division multiplexing (OFDM) overlay CR network with Secondary Users (SUs) and subcarriers selection schemes. Three approaches for SUs and subcarriers Selection named Direct, Distributed and Incremental selection techniques are proposed in this paper to increase the expected signal to interference and noise ratio based on full or partial knowledge of the channel state information (CSI). We also show that Distributed selection techniques provide all the SUs equal chances to be selected without affecting the selection diversity gain. General as well as simplified outage probability expressions are derived and extensive simulations are conducted to evaluate the performance of the proposed techniques and support the theoretical derivations. To accommodate more SUs, a new approach for asynchronous NBI estimation and mitigation in CR networks is investigated. Without any prior knowledge of the NBI characteristics and based on sparse signal recovery theory, the proposed approach allows the PU to exploit the sparsity of the SUs interference to recover it and approach the interference-free limit over practical ranges of NBI power levels.

1. Introduction This dataset contains space and time-indexed data collected in a Vehicle-To-Infrastructure (V2I) communication scenario, where a moving vehicle downloaded data from a stationary Access Point (AP) using IEEE 802.11ad Wi-Fi. The dataset is comprised of both throughput data and detailed frame information captured with tcpdump. It can be used to study 802.11ad's behavior in vehicular environments, in particular in what pertains to antenna sector selection. This dataset is associated with the following article, which we recommend consulting for more information: Geolocation-based Sector Selection for Vehicle-to-Infrastructure 802.11ad Communication, Mateus Mattos, António Rodrigues, Rui Meireles, Ana Aguiar, in the Elsevier Journal of Computer Communications, Volume 193, ISSN 0140-3664, 2022, doi:10.1016/j.comcom.2022.07.005. 2. Experimental setup The AP was placed at the corner of a residential-area intersection while a mobile client vehicle drove around it, downloading data from the AP. Commercial Off-The-Shelf (COTS) TP-Link Talon AD7200 were used for both the stationary AP and mobile client. A third AD7200 configured in promiscuous mode was placed next to the mobile client, in order to capture the control frames being exchanged. 2.1 Experimental nodes MAC address Role Position Orientation 70:4f:57:72:b2:52 AP Static, latitude: 41.111879, longitude: -8.631146, mounted of top of a parked vehicle Perpendicular to road 50:c7:bf:97:8a:ac Client Mobile, mounted on roof of client vehicle Towards front of vehicle 50:c7:bf:3c:53:1c Monitor Mobile, mounted on roof of client vehicle Towards front of vehicle 3. Trace description The data is divided into traces. Each trace represents an uninterrupted period of data collection. The experiments were ran twice, once in 2020, and again in 2021. Environmental conditions, such as weather and topography, were consistent between the two experiment sets. 3.1 2020 traces Trace # Start timestamp End timestamp Mobility pattern 235 1593946456 1593946593 Vehicle moving eastwards from AP and back, straight line, low speed 237 1593946793 1593946908 Vehicle moving westwards from AP and back, straight line, low speed 238 1593946938 1593947076 Vehicle moving eastwards from AP and back, straight line, low speed 240 1593947181 1593947332 Vehicle moving westwards from AP and back, straight line, low speed 241 1593947360 1593947499 Vehicle moving eastwards from AP and back, straight line, low speed 242 1593947566 1593947700 Vehicle moving westwards from AP and back, straight line, low speed 243 1593947759 1593947915 Vehicle moving southwards from AP and back, straight line, low speed 244 1593947971 1593948111 Vehicle moving southwards from AP and back, straight line, low speed 245 1593948210 1593948348 Vehicle moving southwards from AP and back, straight line, low speed 246 1593948433 1593948569 Vehicle moving northwards from AP and back, straight line, low speed 247 1593948631 1593948795 Vehicle moving northwards from AP and back, straight line, low speed 248 1593948904 1593949053 Vehicle moving northwards from AP and back, straight line, low speed 249 1593949307 1593950016 Vehicle driving circuit around the intersection, medium speed (see file driving-circuit.gif) 250 1593950073 1593950643 Vehicle driving circuit around the intersection, medium speed (see file driving-circuit.gif) 251 1593950682 1593951240 Vehicle driving circuit around the intersection, medium speed (see file driving-circuit.gif) 3.2 2021 traces Trace # Start timestamp End timestamp Mobility pattern 201 1632244398 1632244548 Vehicle moving eastwards from AP and back, straight line, low speed (see file driving-patterns-by-trace-2021.pdf) 202 1632244563 1632244663 Vehicle moving westwards from AP and back, straight line, low speed (see file driving-patterns-by-trace-2021.pdf) 203 1632244674 1632244799 Vehicle moving southwards from AP and back, then westwards and back, straight line, low speed (see file driving-patterns-by-trace-2021.pdf) 204 1632244812 1632244915 Vehicle moving northwards from AP and back, then westwards and back, straight line, low speed (see file driving-patterns-by-trace-2021.pdf) 206 1632245138 1632245346 Vehicle moving eastwards from AP and back, then westwards and back, straight line, low speed (see file driving-patterns-by-trace-2021.pdf) 207 1632245355 1632245463 Vehicle moving southwards from AP and back, then westwards and back, straight line, low speed (see file driving-patterns-by-trace-2021.pdf) 208 1632245472 1632245581 Vehicle moving northwards from AP and back, then westwards and back, straight line, low speed (see file driving-patterns-by-trace-2021.pdf) 209 1632245592 1632245790 Vehicle moving southwards from AP and back, northwards from AP and back, then westwards and back, straight line, low speed (see file driving-patterns-by-trace-2021.pdf) 210 1632245798 1632245987 Vehicle moving eastwards from AP and back, straight line, low speed (see file driving-patterns-by-trace-2021.pdf) 302 1632335672 1632336273 Vehicle driving circuit around the intersection (see file driving-circuit.gif), medium speed 303 1632336286 1632336870 Vehicle driving circuit around the intersection (see file driving-circuit.gif), medium speed 401 1634983869 1634984363 Vehicle driving circuit around the intersection (see file driving-circuit.gif), medium speed 402 1634984410 1634984881 Vehicle driving circuit around the intersection (see file driving-circuit.gif), medium speed 403 1634984908 1634985562 Vehicle driving circuit around the intersection (see file driving-circuit.gif), medium speed 404 1634985666 1634986835 Vehicle driving circuit around the intersection (see file driving-circuit.gif), medium speed 405 1634986980 1634988303 Vehicle driving circuit around the intersection (see file driving-circuit.gif), medium speed 406 1634988352 1634989470 Vehicle driving circuit around the intersection (see file driving-circuit.gif), medium speed 407 1634989490 1634990434 Vehicle driving circuit around the intersection (see file driving-circuit.gif), medium speed 4. Data description 4.1 File structure The data from the 2020 and 2021 sets of experiments can be found in subfolders 2020 and 2021, respectively. Each subfolder constains the following: gps.csv: client vehicle mobility trace; thrghpt.csv: application throughput data; wifi.csv: summarized 802.11ad frame data; pcap/: contains raw .pcap files used to generate wifi.csv, separated by trace number; configs/: includes JSON file with fields and filters used by tshark for the generation of wifi.csv. 4.2 GPS data: gps.csv GPS data was captured by a high-accuracy GPS device: Trimble Pro Series 6H [link], and consists of a combination of fields provided by multiple NMEA GP* sentence codes, namely: GPRMC, GPGGA, GPGLL, and GNGSA [link]. Column description gps.csv is a table with the following columns: Column Description timestamp UNIX system timestamp at which GPS sentence was recorded, in seconds lat Latitude, in decimal degrees lon Longitude, in decimal degrees alt Altitude, in meters speed Ground speed, in knots HDOP Horizontal dilution of precision PDOP Position dilution of precision VDOP Vertical dilution of precision heading Direction of movement as provided by GPS device, in clockwise degrees from north identifier NMEA sentence code, e.g., GPRMC gpstime Timestamp as provided by GPS device, in seconds Note: Because each GPS sentence only contains a subset of the listed columns, any missing values are set to -1.0. 4.3 Application layer throughput : thrghpt.csv Data was sent from a custom sender application running on the AP, at the maximum possible rate. A custom receiver application on the client vehicle consumes the data. A time-indexed log of the amount of data sent and received was recorded. Column description thrghpt.csv is a table with the following columns: column description timestamp UNIX system timestamp the throughput record pertains to pckt_cntr Number of packets received within the current record byte_cntr Number of bytes received within the current record elapsed_time Time elapsed since previous throughput record thrghpt Throughput for the current record, in in Megabit per second (Mbps) inter_arrival_avg Average inter-packet arrival time during the recording period, in seconds diff_local_avg Average delta between the timestamp recorded in the packet's payload (set by the sender) and the local timestamp in the receiver, in microseconds trace_nr Trace number the throughput data is associated with 4.4 802.11ad frame data: wifi.csv The wifi.csv file contains 802.11ad frame data, captured with tcpdump, on a Talon AD7200 router configured in promiscuous mode and colocated with the mobile client device. Data collection and processing The following tcpdump command was used to collect raw data frames: tcpdump -B 100000 -s96 -i -y IEEE802_11_RADIO -w & In order to create wifi.csv, the raw data frames were processed using tshark in order to filter out unnecessary information. More specifically, we ran the following command: tshark -r -2 -T fields -Y "" -E header=y -E separator=, -E quote=d -E occurrence=f The raw input .pcap files for each trace are provided in the pcap/ folder. The parameters and represent the filtering conditions and what fields we want to extract from each frame, respectively. The actual values used are provided in the configs/tshark.json file. Frames were filtered based on a single field: the WLAN frame type and subtype, or wlan.fc.type_subtype. Only the following types of frames were kept: Frame type/subtype value Description 0x0000 Association request 0x0001 Association response 0x0002 Re-association request 0x0003 Re-association response 0x000a Disassociation 0x000b Authentication 0x000c De-authentication 0x0019 Block ACKs 0x001d Clear-to-send 0x0028 QoS data 0x0030 DMG beacon 0x0164 Grant 0x0167 Grant ACK 0x0168 SLS 0x0169 SLS feedback 0x016a SLS feedback ACK Column description wifi.csv is a table with the following columns: Column Description frame.time_epoch UNIX timestamp of frame capture, in seconds (with microsecond resolution) frame.number Ordinal number attributed to captured frame frame.len Frame length, in bytes ip.src Source IP address ip.dst Destination IP address ip.flags IP flags ip.frag_offset IP fragmentation offset ip.hdr_len IP header length ip.id IP identification field ip.proto IP protocol field ip.reassembled_in Frame number in which IP packet is reassembled radiotap.channel.flags.2ghz 1 if channel frequency is in 2.4 GHz range, 0 otherwise radiotap.channel.flags.5ghz 1 if channel frequency is in 5 GHz range, 0 otherwise radiotap.channel.freq Channel frequency (60480 Hz in this case) radiotap.length IEEE 802.11 radiotap capture header length radiotap.mcs.index Modulation Coding Scheme index udp.srcport UDP source port udp.dstport UDP destination port wlan.ba.bm Block ACK bitmap wlan.bf Full beamforming field of WLAN frame wlan.bf.isInit Whether or not frame is SLS initiator wlan.bf.isResp Whether or not frame is SLS responder wlan.bf.num_dmg_ants Number of DMG antennas wlan.bf.num_sectors Number of SLS sectors wlan.bf.train Whether or not frame is part of SLS training wlan.fc.retry Whether WLAN frame is re-transmitted wlan.fc.type_subtype WLAN frame type and subtype wlan.fixed.ssc.sequence WLAN starting sequence number wlan.fixed.timestamp WLAN timestamp wlan.frag WLAN fragment number wlan.ta WLAN transmitter MAC address wlan.ra WLAN receiver MAC address wlan.seq WLAN frame sequence number wlan.ssw Full Sector-level Sweep (SLS) field of WLAN frame wlan.ssw.cdown SLS countdown (CDOWN) number wlan.ssw.direction SLS direction (0: frame sent by SLS initiator, 1: by SLS responder) wlan.ssw.sector_id ID of sector used for SLS frame wlan.sswf Full SLS feedback field of WLAN frame wlan.sswf.sector_select SLS Feedback Sector Select wlan.sswf.snr_report SLS Feedback SNR Report wlan_radio.11n.mcs_index WLAN MCS index wlan_radio.channel WLAN channel wlan_radio.data_rate WLAN data rate wlan_radio.duration WLAN frame duration wlan_radio.frequency WLAN channel frequency wlan_radio.noise_dbm WLAN noise level, in dBm wlan_radio.phy WLAN PHY type wlan_radio.preamble WLAN preamble wlan_radio.signal_dbm WLAN signal strength, in dBm wlan_radio.timestamp WLAN TSF timestamp data.text Data enclosed in WLAN data frame trace_nr Number of the trace the frame is associated with

1. Introduction This dataset contains space and time-indexed data collected in a Vehicle-To-Infrastructure (V2I) communication scenario, where a moving vehicle downloaded data from a stationary Access Point (AP) using IEEE 802.11ad Wi-Fi. The dataset is comprised of both throughput data and detailed frame information captured with tcpdump. It can be used to study 802.11ad's behavior in vehicular environments, in particular in what pertains to antenna sector selection. This dataset is associated with the following article, which we recommend consulting for more information: Geolocation-based Sector Selection for Vehicle-to-Infrastructure 802.11ad Communication, Mateus Mattos, António Rodrigues, Rui Meireles, Ana Aguiar, in the Elsevier Journal of Computer Communications, Volume 193, ISSN 0140-3664, 2022, doi:10.1016/j.comcom.2022.07.005. 2. Experimental setup The AP was placed at the corner of a residential-area intersection while a mobile client vehicle drove around it, downloading data from the AP. Commercial Off-The-Shelf (COTS) TP-Link Talon AD7200 were used for both the stationary AP and mobile client. A third AD7200 configured in promiscuous mode was placed next to the mobile client, in order to capture the control frames being exchanged. 2.1 Experimental nodes MAC address Role Position Orientation 70:4f:57:72:b2:52 AP Static, latitude: 41.111879, longitude: -8.631146, mounted of top of a parked vehicle Perpendicular to road 50:c7:bf:97:8a:ac Client Mobile, mounted on roof of client vehicle Towards front of vehicle 50:c7:bf:3c:53:1c Monitor Mobile, mounted on roof of client vehicle Towards front of vehicle 3. Trace description The data is divided into traces. Each trace represents an uninterrupted period of data collection. The experiments were ran twice, once in 2020, and again in 2021. Environmental conditions, such as weather and topography, were consistent between the two experiment sets. 3.1 2020 traces Trace # Start timestamp End timestamp Mobility pattern 235 1593946456 1593946593 Vehicle moving eastwards from AP and back, straight line, low speed 237 1593946793 1593946908 Vehicle moving westwards from AP and back, straight line, low speed 238 1593946938 1593947076 Vehicle moving eastwards from AP and back, straight line, low speed 240 1593947181 1593947332 Vehicle moving westwards from AP and back, straight line, low speed 241 1593947360 1593947499 Vehicle moving eastwards from AP and back, straight line, low speed 242 1593947566 1593947700 Vehicle moving westwards from AP and back, straight line, low speed 243 1593947759 1593947915 Vehicle moving southwards from AP and back, straight line, low speed 244 1593947971 1593948111 Vehicle moving southwards from AP and back, straight line, low speed 245 1593948210 1593948348 Vehicle moving southwards from AP and back, straight line, low speed 246 1593948433 1593948569 Vehicle moving northwards from AP and back, straight line, low speed 247 1593948631 1593948795 Vehicle moving northwards from AP and back, straight line, low speed 248 1593948904 1593949053 Vehicle moving northwards from AP and back, straight line, low speed 249 1593949307 1593950016 Vehicle driving circuit around the intersection, medium speed (see file driving-circuit.gif) 250 1593950073 1593950643 Vehicle driving circuit around the intersection, medium speed (see file driving-circuit.gif) 251 1593950682 1593951240 Vehicle driving circuit around the intersection, medium speed (see file driving-circuit.gif) 3.2 2021 traces Trace # Start timestamp End timestamp Mobility pattern 201 1632244398 1632244548 Vehicle moving eastwards from AP and back, straight line, low speed (see file driving-patterns-by-trace-2021.pdf) 202 1632244563 1632244663 Vehicle moving westwards from AP and back, straight line, low speed (see file driving-patterns-by-trace-2021.pdf) 203 1632244674 1632244799 Vehicle moving southwards from AP and back, then westwards and back, straight line, low speed (see file driving-patterns-by-trace-2021.pdf) 204 1632244812 1632244915 Vehicle moving northwards from AP and back, then westwards and back, straight line, low speed (see file driving-patterns-by-trace-2021.pdf) 206 1632245138 1632245346 Vehicle moving eastwards from AP and back, then westwards and back, straight line, low speed (see file driving-patterns-by-trace-2021.pdf) 207 1632245355 1632245463 Vehicle moving southwards from AP and back, then westwards and back, straight line, low speed (see file driving-patterns-by-trace-2021.pdf) 208 1632245472 1632245581 Vehicle moving northwards from AP and back, then westwards and back, straight line, low speed (see file driving-patterns-by-trace-2021.pdf) 209 1632245592 1632245790 Vehicle moving southwards from AP and back, northwards from AP and back, then westwards and back, straight line, low speed (see file driving-patterns-by-trace-2021.pdf) 210 1632245798 1632245987 Vehicle moving eastwards from AP and back, straight line, low speed (see file driving-patterns-by-trace-2021.pdf) 302 1632335672 1632336273 Vehicle driving circuit around the intersection (see file driving-circuit.gif), medium speed 303 1632336286 1632336870 Vehicle driving circuit around the intersection (see file driving-circuit.gif), medium speed 401 1634983869 1634984363 Vehicle driving circuit around the intersection (see file driving-circuit.gif), medium speed 402 1634984410 1634984881 Vehicle driving circuit around the intersection (see file driving-circuit.gif), medium speed 403 1634984908 1634985562 Vehicle driving circuit around the intersection (see file driving-circuit.gif), medium speed 404 1634985666 1634986835 Vehicle driving circuit around the intersection (see file driving-circuit.gif), medium speed 405 1634986980 1634988303 Vehicle driving circuit around the intersection (see file driving-circuit.gif), medium speed 406 1634988352 1634989470 Vehicle driving circuit around the intersection (see file driving-circuit.gif), medium speed 407 1634989490 1634990434 Vehicle driving circuit around the intersection (see file driving-circuit.gif), medium speed 4. Data description 4.1 File structure The data from the 2020 and 2021 sets of experiments can be found in subfolders 2020 and 2021, respectively. Each subfolder constains the following: gps.csv: client vehicle mobility trace (individual NMEA sentences); gps-merged.csv: client vehicle mobility trace (summarized); thrghpt.csv: application throughput data; wifi.csv: summarized 802.11ad frame data; pcap/: contains raw .pcap files used to generate wifi.csv, separated by trace number; configs/: includes JSON file with fields and filters used by tshark for the generation of wifi.csv. 4.2 GPS data: gps.csv and gps-merged.csv GPS data was captured by a high-accuracy GPS device: Trimble Pro Series 6H [link], and consists of a combination of fields provided by multiple NMEA GP* sentence codes, namely: GPRMC, GPGGA, GPGLL, and GNGSA [link]. Column description gps.csv is a table with the following columns: Column Description timestamp UNIX system timestamp at which GPS sentence was recorded, in seconds lat Latitude, in decimal degrees lon Longitude, in decimal degrees alt Altitude, in meters speed Ground speed, in knots HDOP Horizontal dilution of precision PDOP Position dilution of precision VDOP Vertical dilution of precision heading Direction of movement as provided by GPS device, in clockwise degrees from north identifier NMEA sentence code, e.g., GPRMC gpstime Timestamp as provided by GPS device, in seconds Note: Because each GPS sentence only contains a subset of the listed columns, any missing values are set to -1.0. gps-merged.csv is a table containing all mobility information aggregated by GPS timestamp, for ease of use. It contains the following columns: Column Description gpstime Timestamp as provided by GPS device, in seconds timestamp Average UNIX system timestamp at which the GPS sentences from which this row was created were recorded, in seconds lat Latitude, in decimal degrees lon Longitude, in decimal degrees alt Altitude, in meters speed Ground speed, in knots HDOP Horizontal dilution of precision PDOP Position dilution of precision VDOP Vertical dilution of precision heading Direction of movement as provided by GPS device, in clockwise degrees from north 4.3 Application layer throughput : thrghpt.csv Data was sent from a custom sender application running on the AP, at the maximum possible rate. A custom receiver application on the client vehicle consumes the data. A time-indexed log of the amount of data sent and received was recorded. Column description thrghpt.csv is a table with the following columns: column description timestamp UNIX system timestamp the throughput record pertains to pckt_cntr Number of packets received within the current record byte_cntr Number of bytes received within the current record elapsed_time Time elapsed since previous throughput record thrghpt Throughput for the current record, in in Megabit per second (Mbps) inter_arrival_avg Average inter-packet arrival time during the recording period, in seconds diff_local_avg Average delta between the timestamp recorded in the packet's payload (set by the sender) and the local timestamp in the receiver, in microseconds trace_nr Trace number the throughput data is associated with 4.4 802.11ad frame data: wifi.csv The wifi.csv file contains 802.11ad frame data, captured with tcpdump, on a Talon AD7200 router configured in promiscuous mode and colocated with the mobile client device. Data collection and processing The following tcpdump command was used to collect raw data frames: tcpdump -B 100000 -s96 -i -y IEEE802_11_RADIO -w & In order to create wifi.csv, the raw data frames were processed using tshark in order to filter out unnecessary information. More specifically, we ran the following command: tshark -r -2 -T fields -Y "" -E header=y -E separator=, -E quote=d -E occurrence=f The raw input .pcap files for each trace are provided in the pcap/ folder. The parameters and represent the filtering conditions and what fields we want to extract from each frame, respectively. The actual values used are provided in the configs/tshark.json file. Frames were filtered based on a single field: the WLAN frame type and subtype, or wlan.fc.type_subtype. Only the following types of frames were kept: Frame type/subtype value Description 0x0000 Association request 0x0001 Association response 0x0002 Re-association request 0x0003 Re-association response 0x000a Disassociation 0x000b Authentication 0x000c De-authentication 0x0019 Block ACKs 0x001d Clear-to-send 0x0028 QoS data 0x0030 DMG beacon 0x0164 Grant 0x0167 Grant ACK 0x0168 SLS 0x0169 SLS feedback 0x016a SLS feedback ACK Column description wifi.csv is a table with the following columns: Column Description frame.time_epoch UNIX timestamp of frame capture, in seconds (with microsecond resolution) frame.number Ordinal number attributed to captured frame frame.len Frame length, in bytes ip.src Source IP address ip.dst Destination IP address ip.flags IP flags ip.frag_offset IP fragmentation offset ip.hdr_len IP header length ip.id IP identification field ip.proto IP protocol field ip.reassembled_in Frame number in which IP packet is reassembled radiotap.channel.flags.2ghz 1 if channel frequency is in 2.4 GHz range, 0 otherwise radiotap.channel.flags.5ghz 1 if channel frequency is in 5 GHz range, 0 otherwise radiotap.channel.freq Channel frequency (60480 Hz in this case) radiotap.length IEEE 802.11 radiotap capture header length radiotap.mcs.index Modulation Coding Scheme index udp.srcport UDP source port udp.dstport UDP destination port wlan.ba.bm Block ACK bitmap wlan.bf Full beamforming field of WLAN frame wlan.bf.isInit Whether or not frame is SLS initiator wlan.bf.isResp Whether or not frame is SLS responder wlan.bf.num_dmg_ants Number of DMG antennas wlan.bf.num_sectors Number of SLS sectors wlan.bf.train Whether or not frame is part of SLS training wlan.fc.retry Whether WLAN frame is re-transmitted wlan.fc.type_subtype WLAN frame type and subtype wlan.fixed.ssc.sequence WLAN starting sequence number wlan.fixed.timestamp WLAN timestamp wlan.frag WLAN fragment number wlan.ta WLAN transmitter MAC address wlan.ra WLAN receiver MAC address wlan.seq WLAN frame sequence number wlan.ssw Full Sector-level Sweep (SLS) field of WLAN frame wlan.ssw.cdown SLS countdown (CDOWN) number wlan.ssw.direction SLS direction (0: frame sent by SLS initiator, 1: by SLS responder) wlan.ssw.sector_id ID of sector used for SLS frame wlan.sswf Full SLS feedback field of WLAN frame wlan.sswf.sector_select SLS Feedback Sector Select wlan.sswf.snr_report SLS Feedback SNR Report wlan_radio.11n.mcs_index WLAN MCS index wlan_radio.channel WLAN channel wlan_radio.data_rate WLAN data rate wlan_radio.duration WLAN frame duration wlan_radio.frequency WLAN channel frequency wlan_radio.noise_dbm WLAN noise level, in dBm wlan_radio.phy WLAN PHY type wlan_radio.preamble WLAN preamble wlan_radio.signal_dbm WLAN signal strength, in dBm wlan_radio.timestamp WLAN TSF timestamp data.text Data enclosed in WLAN data frame trace_nr Number of the trace the frame is associated with

This open-source software performs a microscopic analysis mainly on the user types. At first, it divides users into six categories; rumor tweeter, anti-rumor tweeter, rumor retweeter, anti-rumor retweeter, rumor-related tweeter, rumor-related retweeter. The last two categories refer to the tweeters and retweeters of what does not support rumor but is related to it, such as those that question about the rumor. Then calculates the user dynamics such as the ratio of following to follower, number of days of membership, number of published tweets per day, and compound score for the description sentence in the users' profiles, both for individual and user categories. Furthermore, the software calculates the number of users who belong to any combination of the sextuple categories. Finally, it performs a macroscopic analysis over datasets in which the number of tweets/retweets in each hour would be plotted.

Real-time applications, such as video conferences, have strong Quality of Service requirements for ensuring a decent Quality of Experience. Nowadays, most of these conferences are performed over wireless devices. Thus, an appropriate management of both heterogeneous mobile devices and network dynamics is necessary. Software Defined Networking enables the use of multicasting and stream layering inside the network nodes, two techniques able to enhance the quality of live video streams. In this paper, we propose two algorithms for building and maintaining multicast sessions in a software-defined network. The first algorithm sets up the initial multicast trees for a given call. It optimally places the stream layer adaptation function inside the core network in order to minimize the bandwidth consumption. This algorithm has two versions: the first one, based on shortest path trees is minimizing the latency, while the second one, based on spanning trees is minimizing the bandwidth consumption. The second algorithm adapts the multicast trees according to the network changes occurring during a call. It does not recompute the trees, but only relocates the stream layer adaptation functions. It requires very low computation at the controller, thus making our proposal fast and highly reactive. Extensive simulation results confirm the efficiency of our solution in terms of processing time and bandwidth savings compared to existing solutions such as multiple unicast connections, Multipoint Control Unit solutions and application layer multicast.

Cleaned the code and add documentation