1 / 15

Simulation scenario proposal

Simulation scenario proposal. Date: 2013-17-09. Authors:. Context. Simulation scenarios definition is a key step to clearly scope the work in HEW. We need to ensure that they address the real issues (scenario / interference / traffic model) while being simple enough

jhuss
Download Presentation

Simulation scenario proposal

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. Simulation scenario proposal Date: 2013-17-09 Authors: Laurent Cariou (Orange)

  2. Context • Simulation scenarios definition is a key step to clearly scope the work in HEW. • We need to ensure that they address the real issues (scenario / interference / traffic model) • while being simple enough • and being “open enough” to not preclude parts of the potential solution space • We take the assumptions that HEW will have to ensure improvements in « all main scenarios » • we can therefore spread the difference interference issues over the different scenarios • In this presentation, we review the main simulation scenarios and • allocate specific interference condition problems to specific scenario(s) • define some options in the scenarios to capture all elements that can impact the performance of specific solutions Laurent Cariou (Orange)

  3. Define simulation scenarios to capture all issues and to enable solutions evaluation 1 Need to make sure that all interference conditions are captured and spread over the different scenarios • Need to enable PHY/MAC simulation parameters to be tuned, not to restrict the solution space (e.g. TxPower, channel selection…) 3 Need to include different options in the simulation scenarios so that, for the evaluation of specific schemes, all traffic or devices, that can have an impact on the performance, are taken into account • these options should be assigned to specific family of solutions as part of the evaluation methodology/selection procedure Laurent Cariou (Orange)

  4. 1 Mapping of interference types on the main simulation scenarios • We review the types of interference defined in the usage model document, and evaluate if they are captured in the current simulation scenarios • We base our analysis on document 1000r0, and mapped previous propositions, especially 722-23r0 • The parameters that currently define the interference scenario are mostly the topology (AP/STA placements, channel conditions…) and whether the network is managed or not • By managed, it is meant that multiple APs are sharing the same management entity • But more importantly for simulation scenario definition: a managed network is planned, meaning that the AP locations follow a relatively regular grid and that specific frequency reuse schemes can be applied. Laurent Cariou (Orange)

  5. 1 Mapping of interference types on the main simulation scenarios • 1 Residential: • fully unmanaged (unplanned) networks, potentially overlaid by some P2P links • topology: High density of BSS, low to medium STA density, indoor • 2a Enterprise: • Managed (planned) ESS overlaid by many unmanaged P2P links • topology: high density of BSSs, high density of STAs, indoor • 2b Dense indoor hotspot: • Managed ESS (currently no overlaid interference proposed) • topology: High density of BSSs, high density of STAs, indoor • 3a Outdoor large deployment: • managed ESS (currently no overlaid interference proposed) • topology: relatively low density of BSSs, high density of STAs, outdoor Laurent Cariou (Orange)

  6. 1 Mapping of interference types on the main simulation scenarios Laurent Cariou (Orange)

  7. 1 Mapping of interference types on the main simulation scenarios: Focus on dense hotspot 2b • As the dense hotspot scenario is managed, we consider a frequency reuse deployment • ICD is low (10-20m) • Interference between BSSs belonging to the same planned ESS is important and well captured BSS STAs are concentrated close to the AP: good SNR at cell-edge CCA range BSS BSS BSS BSS BSS simulation of all channels with frequency reuse 3 BSS BSS Cluster Simplified simulation: One channel only, assuming frequency reuse 3 Laurent Cariou (Orange)

  8. 1 Mapping of interference types on the main simulation scenarios: Focus on dense hotspot 2b • We should add interfering networks to the dense hotspot scenario • overlay of BSS short-range links (for tethering devices) • randomly distributed on the whole simulation zone • some of these BSS can be idle and only transmit management frames • Note that there are similarities with Enterprise 2a BSS BSS BSS BSS BSS BSS BSS Laurent Cariou (Orange)

  9. 1 Mapping of interference types on the main simulation scenarios: Focus on large outdoor 3a • As the outdoor large hotspot scenario is managed, we consider a frequency reuse deployment as well • ICD is large: 100-150m • With this frequency reuse, interference between BSSs from the managed network is very low BSS STAs are distributed on the whole AP coverage: low SNR at cell-edge CCA range BSS BSS BSS BSS BSS All channels with frequency reuse 3 BSS BSS Cluster One channel with frequency reuse 3 Laurent Cariou (Orange)

  10. 1 Mapping of interference types on the main simulation scenarios: Focus on large outdoor 3a • Potential interfering network on outdoor hotspot • overlay of other operators will be very common in such scenarios and is the most different interference from other scenarios • in the case of an overlay of 3 operators planned deployments, each of which with freq reuse 3, the scenario becomes a simple theoretical frequency reuse 1 deployment with 100-150m ICD between neighboring OBSSs • with an overlap between neighboring cell around cell-edge (low SNR) • with neighboring cells not sharing the same management entity • with constraint on associations: STAs connect only to one operator APs BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS 1 operator 2 operators 3 operators frequency reuse 1 deployment BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS BSS Laurent Cariou (Orange)

  11. 2 Allowparameterstuning to evaluatetechnical propositions • We all agree that on each scenarios, we should define a default value for all parameters • to define a baseline to compare with • Once we agree on the template (1001rx) for simulation scenario, we’ll make a proposal based on previous slides for this • Now some of those parameters are key to the scenario definition and shouldn’t be tuned • AP/STA positioning, channel models… • channel and potentially bandwidth allocation for planned deployments (dense hotspot and outdoor large deployment) • Depending on the proposed technical solutions, some parameters need to be tunable, as their adaptation is part of the solution space • Tx Power, CCA level, CSMA parameters, bandwidth, channels… Laurent Cariou (Orange)

  12. 3 Define options in the simulation scenarios: proportion of HEW and legacy devices • For all the technical propositions, especially for OBSS, we need to model all elements that could jeopardize the performance of the scheme (to ensure it will keep its efficiency in real deployments) • If the presence of « legacy devices » is susceptible to have such degrading impact : • It will be important to define a proportion (TBD%) of devices in the scenario that won’t implement the proposed scheme and would keep the baseline default parameters • STAs connected to the planned network • APs and STAs part of the interfering network • whether this is mandatory or not should be determined by the group on a per solution basis as part of the evaluation methodology/selection procedure • This « optional/mandatory » mix of devices should be defined in the simulation scenario Laurent Cariou (Orange)

  13. 3 Define options in the simulation scenarios: proportion of HEW and legacy devicesExample with Transmit power control and CCA control • For example, power control solutions are showing promising theoretical gains in dense deployments • However, it is well understood that the use of different power or CCA levels by devices leads to throughput starvation of certain nodes due to the introduction of asymmetric links • some power control solutions can therefore become inefficient • if applied only in the AP but not on STA side • in the presence of overlapping BSSs (P2P links) which don’t apply TPC, or apply it differently • if only part of the traffic is applying TPC (APs could apply TPC for data transmission but not for management frames) • If we want to make sure that such a proposed solution is efficient in real deployments, we would need to capture these degrading elements in the simulation scenarios : • proportion of devices (connected STAs and AP/STAs from the interfering networks) that don’t implement TPC and use « default » TxPower • idle AP/STAs that don’t apply TPC to their management frames transmission Laurent Cariou (Orange)

  14. Conclusion • We propose a design for dense hotspot 2b and outdoor large BSS 3a scenario • we’ll use template 1001rx (if/when agreed by the group) to make a proposition for default parameters for these scenarios, based on the current presentation • Enabling parameter tuning by HEW devices in these scenarios should of course be enabled with some restrictions depending on the scenarios • Options should be defined in the scenarios in order to capture all traffic or types of devices that can have an impact on specific solutions • Example for the mix of HEW and legacy devices for TPC solutions • In the evaluation methodology/selection procedure, each family of proposed solutions should be linked to specific simulation scenario(s) and their option(s) • to ensure a good quality of the evaluation • to be able to compare competing solutions Laurent Cariou (Orange)

  15. References 11-13/1000, “HEW simulation scenarios”, Simone Merlin (Qualcomm) 11-13/1001, “HEW simulation scenarios document template”, Simone Merlin (Qualcomm) 11-13/0722, “HEW Evaluation Methodology”, Minyoung Park (Intel) 11-13/0723, “HEW SG evaluation methodology overview” Minyoung Park (Intel) 11-13/1051, “HEW evaluation methodology” Ron Porat (Broadcom) Laurent Cariou (Orange)

More Related