| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Adrian and TGn participants:
I recommend that we keep our focus on completing the FRCC first. We will have our hands full with just getting agreement on what the Functional Requirements and Comparison Criteria should be.
The ideal case would be that the FRCC document itself could specify the all requirements and criteria in a fashion that is unambiguous and clear, thus allowing us to avoid the overhead and complexity of a full 802.11n Simulation Committee.
Three committees (Channel Models, FRCC and Simulation) could generate a lot of conference calls for members. In addition, there is a risk of the FRCC Committee and a Simulation Committee having potentially overlapping scopes which might generate difficulties.
I recommend that the FRCC push forward with the difficult task of reaching consensus on what the requirements and criteria should be. I recommend that the committee do its best to clearly define the requirements and criteria in an unambiguous way such that there is little room for multiple interpretations. If we can achieve this, a separate Simulation Committee is not required, which seemed to be the will of the large majority of members attending the Singapore meeting.
Best regards, Matthew B. Shoemake, Ph.D. IEEE 802.11n Chairperson m.b.shoemake@ieee.org
-----Original Message-----
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 came from the IEEE 802.11 Technical Reflector List Info at http://www.ieee802.org/11
--- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.520 / Virus Database: 318 - Release Date: 9/18/2003
|