1 / 24

An IEEE 802.11p Empirical Performance Model for Cooperative Systems Applications

An IEEE 802.11p Empirical Performance Model for Cooperative Systems Applications S. Demmel, G. Larue, D. Gruyer, A. Rakotonirainy ITSC 2013 – MoD2.5 – Presenter: S. Demmel / sebastien.demmel@qut.edu.au 17:12-17:30, Monday 7 October 2013, The Hague, NL. Outline. Introduction

keren
Télécharger la présentation

An IEEE 802.11p Empirical Performance Model for Cooperative Systems Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. An IEEE 802.11p Empirical Performance Model for Cooperative Systems Applications • S. Demmel, G. Larue, D. Gruyer, A. Rakotonirainy ITSC 2013 – MoD2.5 – Presenter: S. Demmel / sebastien.demmel@qut.edu.au 17:12-17:30, Monday 7 October 2013, The Hague, NL

  2. Outline • Introduction • Research goal & rationale • Model’s goals • Experimental summary • General principles • Frame loss model • Latency model • Finer points • Parameterisation & profile generation • Performance improvements • Limitations • Conclusion

  3. Introduction • Research goal: provide a realistic, yet simple, network performance model for application-centric simulation environments (micro- or macroscopic). • Why? • Facilitate study of Cooperative-ITS applications • Reduce complexity/computational load when network topology is not overly complex • Solve lacking performance of some existing physical layer models

  4. Introduction • Model will: • Focus on a few critical performance metrics • Use empirical data to closely model actual on-road performance • Approximate the lower OSI layers and serve upper-layer applications specifically • Intended use in detailed microscopic simulations, for small group of vehicles • VEINS microscopic traffic simulation with complex network topology • SiVICsensors & applications simulation focused on smaller group of vehicles

  5. Experimental summary • 1st setup: empirical performance evaluation of IEEE 802.11p devices • Devices sourced from CVIS project + open-source drivers • 2 devices (mobile & static) • 3 main metrics (range, frame loss, latency) • Satory test tracks (road-like environment) from 09/2011 to 02/2012, 450+ km driven • Results presented at IEEE IV Symposium 2012 • Measured performance was lower than standard, the effects of several environmental factors were studied, good latencies

  6. Experimental summary • 2nd setup: same hardware as first setup, with: • 3 devices (2 static, one mobile) • 1 day measurements (12/2012) • Metrics related to specific points of interest for the model • Findings detailed later in this presentation

  7. General principles • OSI approximation: no complex topology, point-to-point connections • Focus on closely matching experimental data and being able to generate new “plausible” data • 2 modelled performance metrics: • Frame loss • Latency

  8. Frame loss model • Frame loss model is based on profiles • a profile is a frame loss probability curve generated for each single uninterrupted connection between 2 nodes • Temporally consistent • Parameterised on empirical data • Includes multi-path reflections from the ground, objects and vegetation, weather, and hardware in-homogeneities

  9. Frame loss model • Frame loss probability (t), a function of: • Distance • Relative speed • A, B, ..., F are parameters estimated on empirical data • The parameters values depend on speed • 4 classes (0-40, 40-60, 60-100, 100-160 km/h) • Each classes has its own set of cumulative distribution functions for each parameters • Correlations between some parameters are present

  10. Frame loss model

  11. Latency model • Experimental evidences showed that latency does not depend on relative speed or distance • Latency is a function of the packet size • Accounts only for direct connectivity • Accounts for delays caused by increased network activity (up to 6 devices active together) • Model is most appropriate for Basic Safety Messages (BSM) like packets

  12. Latency model • Latency can be computed with continuous or digital distributions, depending on the simulation’s architecture • Example: 1000 drawings per packet size class, 5 ms increments

  13. Parameterisation • FL profile has 6 parameters • Procedure: • Each parameters is first estimated with a Levenberg-Marquardt algorithm for non-linear least squares • Then we extract a continuous PDF via a smoothed non-parametric probability density estimate • PDF are transformed to Cumulative distributions • Inverse transform sampling can be used to drawn a value (per parameter) for each generation of a new profile

  14. Parameterisation • Parameters E and D show correlation • with: where α,β are estimated from experimental data • α,βare used to subdivide the [100-160] km/h class for improved fidelity to experimental data • Influence of air humidity(hence weather) was considered, but not enoughvariation in the dataset toconclude

  15. Profiles generation • 100 profiles in the [60-100] km/h class

  16. Profiles generation 0-40 km/h 40-60 km/h 60-100 km/h 100-160 km/h

  17. Performance improvements • Question: when is it appropriate to generate new profiles? • The “neighbours problem” • Two nearby nodes connected to a same 3rd node can have widely diverging performance • Within which distance can we generate only a single profile for several nodes? • What is the “shelf life” of a profile? • Will 2 nodes connecting to a same 3rd node a few minutes apart from the same direction be able to re-use the same profile?

  18. Performance improvements • The “neighbours problems” • Profile 1 • (F-E)/D = 225 mmax range 349 m • Profile 2 • (F-E)/D = 706 mmax range 789 m

  19. Performance improvements • If two nodes are, at max, 25 metres apart, can they use the same profile? • We use data from the 2nd setup • Metrics: (F-E)/D and (1-E)/D, the boundaries of the increasing FL slope / average (F-E)/D = 303 metres • 2nd dataset confirms earlier findings for motion direction symmetry and expectations about antennas effects • Yes • Accounting for the 25 metres intra-nodes distance, we find at worst a 10% (37 metres) error between each nodes for each lap

  20. Performance improvements • Profile’s “shelf life” • Can we re-use a same profile for 2 consecutives vehicles? • Would be especially useful with a significant traffic density • No, we probably should not • 9 laps over about 20 minutes, a third showed large lap-to-lap changes

  21. Performance improvements • Summary, through an example: • A roadside unit connecting to a flow of incoming vehicles arriving with random interdistances • Isolated vehicles have their own profile • Compact group of vehicles less than a minute apart can use the same profile • Profile 2 • Profile 3 • RSU • Profile 2 • Profile 4

  22. Limitations • Limited set of environmental conditions • Accurate for open freeway, or rural and suburban environments • Cannot be used for urban scenarios • Weather is present in the data, but cannot be used as a parameter (no weather-bases classes) • Limited number of nodes • No routing, groups management • Needs refinements for “grouped” FL profiles generation • Focused on packets up to 1 kB(no specific mechanism for larger multi-packets payloads)

  23. Conclusion • We created a resource-inexpensive empirically-based model for key IVC metrics • Provides realistic networking for application-centric simulation, e.g. for the evaluation of C-ITS applications such as CCW or road trains • The model still needs to be extended to include a wider range of environmental conditions (urban, different weathers,...), different hardware types and improve the management of profiles with larger number of nodes

  24. Conclusion Thank you for attending this presentation! Dr. Sébastien Demmel Research associate, Centre for Accident Research and RoadSafety – Queensland. sebastien.demmel@qut.edu.au / +61 7 3138 7783 130 Victoria Park Road, QLD 4059 Kelvin Grove Australia.

More Related