FW: Simulation methodology issues / group
Dear Colleagues,
As both Colin and Jeff are OK to forward this email thread, I'll
copy this onwards and add a comment.
There will be, I believe, a need to create an additional special
committee to look at how the 802.11 TGn requirements, criteria,
channel models
and simulation scenarios should be reflected in a simulation
implementation.
The idea is not to for the group to own a simulation model itself, but
to promulgate
best known methods and increase confidence that the results that are
finally presented are capable of valid comparison.
I've been approached by a number of people on exactly this topic, and
I think they should form the nucleus of a new committee. I'm aware of
a couple
of people who want to make presentations at the November meeting on the
subject, and I think it would be a highly appropriate topic to consider
at the meeting.
Comments?
Best Regards,
Adrian P Stephens
Intel Corporation
Tel: +44 771 276 3448 (Mobile)
Tel: +44 1223 763457 (Office)
-----Original Message-----
From: Jeff Gilbert [mailto:gilbertj@atheros.com]
Sent: 21 October 2003 04:52
To: Lanzl, Colin
Cc: verceg@zyraywireless.com; Stephens, Adrian P; Sadri, Ali S;
Sadowsky, John
Subject: Re: Simulation methodology issues / group
Hi Colin,
Thanks much for your detailed reply.
Yes, I also expressed concern at Singapore - and actually if I
recall correctly TGn did not vote against it, it is just that the only
vote that was taken relating
to the FRCC did not include it and none of us asked for a straw poll
that did.
Anyhow, this is the past - I think that people were mostly focused on
getting things closed out - which in principle is good - and for the
present and future I think we can rectify things and am glad that you
and others feel similarly. I also
sent the thoughts to Adrian and a couple of his coleagues and he agreed
and had some
good thoughts as well. (I'll let him send any/all on as I would rather
not w/o his permission though I do not anticipate he would mind sharing
any of his thoughts on it.) He did suggest my raising it at the FRCC
con call tomorrow.
I would also be willing to put a few slides together on the topic to
present at
Albuquerque if that will help get the ball rolling - though it could be
tightly tied to
the FRCC so I'll bring it up tomorrow as well. I'm cc'ing them to this
email as well in case they'd like to comment with a more limited
distribution. As for adding it to the channel models call - thanks -
perhaps a brief mention may be
useful to get people thinking - particularly with respect to the phy rf
impairments. We can touch base tomorrow or wed by email after the FRCC
con call.
I agree that TGn should not own the simulation or do the simulation
work or mandate particular tools, but should just make sure to clarify
the relevant
areas so that proposals can be fairly and accurately compared. The
channel
and usage models are great steps along this - there are just a few holes
left at
the phy level and phy/mac boundary. As I mentioned, I think that the
level of
complexity should match the level of accuracy desired - if lower
accuracy is
desired then perhaps we can simplify the way results are compared /
evaluated - this
is a valid position - but if we are to use the full channel and usage
models we should
make sure that the extra work results in a more accurate comparison.
Detailed comments interspursed. I'm fine with your starting a
thread on the
reflector.
Regards,
Jeff
Jeffrey M. Gilbert, Ph.D.
Director of Advanced Technology
Atheros Communications
gilbertj@atheros.com
----- Original Message -----
From: "Lanzl, Colin" <clanzl@aware.com>
To: "'Jeff Gilbert'" <gilbertj@atheros.com>
Cc: <verceg@zyraywireless.com>
Sent: Monday, October 20, 2003 7:03 AM
Subject: RE: Simulation methodology issues / group
> Hi, Jeff:
>
> Adrian, Matthew Shoemake and I tried to address this very issue in
> Singapore with precisely the recommendation you suggest. TGn voted
> down that attempt. In my opinion, there was massive confusion between
> simulation methodology and simulation. Most people feel as you do,
> that we need to somehow specify how proposals use the tools we're
> providing in the usage models and channel models. However, there is
> very high resistance to TGn owning a simulation or doing any
> simulation work.
>
> I made it very clear to TGn that the channel model committee does not
> own simulation methodologies and that the results of the vote mean
> that TGn owns the problem. I'd be surprised if Adrian were willing to
> take on that responsibility in the Functional Requirements and
> Comparison Criteria special committee: he's got plenty to do without
> that. Also, the work of simulation methodology spans both the MAC and
> PHY activities and needs to draw on both pools of experts to do a good
> job.
>
> I think it would be very productive if you could turn this list into a
> short series of slides for presentation to TGn. I think it would
spark proper,
> intelligent debate. I'll support the re-introduction of this idea
> wholeheartedly, primarily based on the problems TG3a are having in
> 802.15 right now.
>
> That said, I have a couple of comments on your list.
>
> Tx power, Rx noise: I think we should work with power densities to
make it
> easy to handle different regulatory domains. We've tried hard to be
> agnostic to band definitions and this helps remove the bandwidth
> variable from proposals. We still need to set some sort of Tx power -
> if we choose the least common denominator for required simulations,
> this frees proposers to provide "standard" simulations for comparison,
> yet allows them to optimize for particular band choices they favor.
> This gets around the
> +15dBm in the low 5GHz band versus the +30dBm in some ISM bands issue.
> +A
> similar argument applies in favor of noise power density in receive
> chains.
Yes, Adrian raised the issue of using noise psd as well. I agree to
make it less dependent on b/w. It is an easy application for rx but for
Tx it becomes a little more complicated. There are two limiting factors
- the amount of power
you can put into one antenna (power, not psd) due to PA limitations and
the
system limitations due to spectral regulations. This could be some
combination of psd and total power and it is not clear what the
interpretation of the various regulations will be to multi-antenna
power. But what is most important is that all proposals are consistent.
I do like you thought of one "standard" choice and then letting people
also compare to other alternatives if they want to.
> Interference: I think it is time we get 802.19 into the job of
> helping TGn get our standard out. We need unbiased recommendations on
> the interference scenarios we should address and the methodologies to
> quantify them. If we go into a joint meeting with them with ideas in
> hand along with a list of needs, I think we can get the required help
> more effectively than by simply requesting help. As you note, we need
> to decide what levels of co- and adjacent-channel interference we
> should simulate, as well as the threshold levels of sensitivity to our
> interference with other services, both IEEE and non-IEEE. This latter
> is very important in light of the recent refusal of the FCC to proceed
> to summary judgment in the UWB matters currently pending in 802.15.3a.
> I read the response of the FCC to be a warning shot that the IEEE
> needs to consider all potential users in the "radio domain" that any
> IEEE standard device will use, not just IEEE users of that domain.
You raise an interesting point - though we do need to balance ease
of simulation with accuracy so hopefully we would not need to build
complete bluetooth transmitter receiver into our model but will get
meaningful coexistance information. I'm open on the best way to do
this.
> RF impairments: I think your list is very reasonable and that there
> will be lively debate about these topics - I can't think of anything
> to add right now.
I think that in many ways the RF impairments are the most necessary,
since they could stress areas of proposals such as pilot tracking which
need to be stressed, but fortunately also the most straight-forward -
much less complex than even the channel models and integrate well into
the phy sims.
> PHY modeling: I think the models already handle frequency-selective
> multipath-based fading, so I assume you're talking here about flat
> fading. It is relatively simple to require multiple runs with
> specified fade levels. See the note below about simulations.
I may not have been clear with the fading - I think that the problem
is how to incorporate the fading behavior in the system/MAC level
simulations. The phy models them well but we need for the path losses in
the system model to have statistical proprerties to model fading. The
tendency could be to key a distance into the phy model run a bunch of
packets, get a PER and use this in the system simulation. If this is
what we want to do, fine,
but in that case there is no need to have the phy model incorporate
fading
and decorrelation effects. And if results are going to be compared
across proposals they should all have the same behavior.
> MAC modeling: I believe that the usage models are already specifying
> a mix of TCP and UDP traffic, so I think that MAC modeling needs to
set up the
> relevant TCP and UDP parameters needed to properly define these
traffic. I
> think Adrian's group is already down that path and that they envision
> finishing the specification of these parameters in their final usage
> model document (or perhaps in the FR or CC).
>
> General simulation worries: In typical "design by committee" fashion,
> we in TGn have gone to great lengths to try to give ourselves very
> good, accurate tools (channel models, usage models) to aid in getting
> apples-apples comparisons from proposals. This is rapidly leading to
untenably long and
> complex simulation requirements. Do have a look at the current
informative
> section of the usage model document dealing with simulation
> requirements that they intend to make normative. Then think about
> those requirements in light of what we're discussing here and tell me
> if you or your company has the resources to do the required
> simulations for a proposal in January (or March).
I completely agree that we need to balance simulation complexity
with accuracy. The one thing that I would see that would be
disappointing is if the channel and usage models entail significant
effort to implement but due to variations in rf/circuit impairments and
systems modeling methodologies the results were still not comparable.
I'd think it would be better in that case to use simpler simulation
methodologies to at least save the time.
> My suspicion is that even the largest companies will have a difficult
> time coming up with all the necessary simulations in time and that
> smaller companies will be stuck with only partial proposals because
they simply
> don't have the resources. We've been struggling with parts of this
issue
> in the HTSG CM telecons and I believe that the MAC issues will only
> make the problems far worse. Then add in the kinds of interference
scenarios that we
> should examine: see my concern? I think we've paid too little
attention to
> creeping functionality coupled with a "head in the sand" attitude
> about simulation methodologies.
I agree. Previous paragraph applies.
>
> OK, I'll step off the soapbox now. Thanks very much for your thorough
> thoughts on this issue. Based on the two issues we've pending now for
> Thursday in the channel model telecon (K-factors and Doppler power
> spectrum), I don't think there's time for an in-depth discussion, but
> I'd be happy to put in a short segment in the agenda to introduce the
> topic and push for a larger agenda time in the next call (which
> currently has only stadium models on the agenda). Also, with your
> permission, I'd like to post this thread on the reflector to start to
> get some dialog going: I'd like people to be thinking about this
before Albuquerque.
>
> Regards,
> Colin
>
>
>
>
>
> -----Original Message-----
> From: Jeff Gilbert [mailto:gilbertj@atheros.com]
> Sent: Sunday, October 19, 2003 2:11 AM
> To: Vinko Erceg; Lanzl, Colin
> Subject: Simulation methodology issues / group
>
>
> Hi Vinko and Colin,
>
> Greetings. I wanted to get your thoughts on something I've
> been thinking about in relation to the 11n process - that is the
simulation
> methodologies and how to work towards comparable simulation
> results between different TGn proposals. It seems that we want to
> balance accuracy with simplicity. Thus we want to propose the
> simplest mechanism that provides reasonable accuracy. The usage
> models and channel models go a long way to specifying key components,
> however the parts of the simulation between the channel model and the
> usage models are left open - i.e. how the channel models are used and
> performance is evaluations. Do you think that is will be an issue?
If so
> how do you think is best to address? Potentially include into the
> Functional
> Requirements and Comparison Criteria or perhaps a simulation
methodology
> subcomittee? Not sure how the best way to achieve the desired goal
without
> slowing down the process is - comments would be welcomes. Anyhow I've
> listed some ideas below - please let me know any thoughts - things
I've
> missed, things you think don't matter, etc.
>
> Best Regards,
>
> Jeff
>
> ----------------------------
>
> PHY
> Recieve SNR normalization - to make sure that the basic
SNR
> tested is comparable.
>
> Max output power per PA (We'd need to fix this
20dBm?)
>
> Antenna gain (assume 0dB?)
>
> Receiver noise floor (-98 to -96 dBm?)
>
> EIRP limitations (couples with antenna gain and output
> power)
> Critical for determining beam forming gains
> (Assume ISM bands - high power limits?)
>
> RF Impairments
> We need a balance because these are implementation
> specific but some uniform level needs to be
> included to make a fair analysis
>
> Phase-noise - would effect utility of different pilot
> schemes
> If phasenoise is not included then very simple
pilots
> can be included - if it is included then the
> "trackibility" of the pilots is emphasized
> more
>
> Non-linearities
> These could effect the relative performance of one
> proposal vs. another and what rates can be
> achieved. If it is not included then we may
> end up with techniques more aggressive than
> can be effectively included.
>
> Frequency offset - mandate testing over +-20ppm as for
> 11a?
>
> Timing offset - make sure there is a random packet
> arrival time jitter
>
> Modeling of adj/co/alt interference
> Assume no adj channel interference?
> Co-channel just compute effective receive level at
the
> interference location. Just flat, not
> frequency selective?
>
> Specifically add this signal back in vs. just
> reduce the received
> SNR. If we specifically add back in we'd need
> a 2-d table of
> interferer distance, desired user distance to
> generate PER -
> complicated.... Table grows with number of
> users.
>
>
> Phy / MAC modeling -
> This could have a significant impact on the effects
> of variability.
>
> The channel model can incorporate fading where it goes
> through good and bad periods. We need to determine
> what level of detail needs to be used to map this to
> system simulations. For instance at a given location
pair
> do we assume a constant PER or do we add back the PER
> variability? Perhaps opt for constant PERs for
> simplicity but
> know that it may not capture variability. Many of the
> applications spec max PER - simplest thing it to
average
> this over whole run. It's optimistic though.
>
> The same would apply for interference modeling - is it
> static or dynamic fading?
>
> MAC
> TCP Stack parameters? Window sizes etc will effect the
amount
> of aggregation you can get - though few of the models
use
> TCP - only really local file transfer which is TCP @
> 30Mbps
>
>
>
This message was sent from the 802.19 email reflector.