RE: [802-11Technical] RE: HTSG Usage Model Special Committee
- To: Pratik_Mehta@Dell.com, Adrian.P.Stephens@intel.com, swhitesell@vtech.ca, owner-stds-802-19@majordomo.ieee.org
- Subject: RE: [802-11Technical] RE: HTSG Usage Model Special Committee
- From: garth.hillman@amd.com
- Date: Thu, 10 Jul 2003 10:33:34 -0500
- cc: Mike.Moreton@synad.com, bbjerke@qualcomm.com, stds-802-11@ieee.org, stds-802-19@ieee.org, jrosdahl@ieee.org, shoemake@ti.com, coffey@ti.com, Liam_Quinn@Dell.com
- Sender: owner-stds-802-19@majordomo.ieee.org
I am a little (actually allot!) behind in my email so I may be redundant but:
1) Video Conferencing using a headset. This falls into the category of BT (headset) coexistence with WLAN (video conferencing) but is more generally an example of a class of applications which have simultaneous peer-to-peer (ad hoc/direct link) and peer-to-AP (infrastructure) communication. The question is could it be done with only one technology namely 802.11. If the DL mode being proposed in TGe is simultaneous rather than stand alone then it may be covered.
2) LARGE multi-family dwelling complexes (as was shown in one of our TGn presentations) - would this be classified as residential or ??
3) Cordless telephone function (as opposed to coexistence). I assume this is already considered as simply VoIP.
Garth
-----Original Message-----
From: Pratik_Mehta@Dell.com [mailto:Pratik_Mehta@Dell.com]
Sent: Thursday, July 10, 2003 8:51 AM
To: Adrian.P.Stephens@intel.com; swhitesell@vtech.ca;
owner-stds-802-19@majordomo.ieee.org
Cc: Mike.Moreton@synad.com; bbjerke@qualcomm.com; stds-802-11@ieee.org;
stds-802-19@ieee.org; jrosdahl@ieee.org; shoemake@ti.com; coffey@ti.com;
Liam_Quinn@Dell.com
Subject: RE: [802-11Technical] RE: HTSG Usage Model Special Committee
I agree with your categorization. Also that #3 is more difficult to wrap
our hands around, and that working with 802.19 will be beneficial to define
the appropriate usage scenarios -- while the special HTSG Usage committee is
still in session. To that end, Steve was bringing up the use of cordless
phones, I added some scenarios for Bluetooth, and you've brought up several
others in #3.
Thnx,
-pm.
-----Original Message-----
From: Stephens, Adrian P [mailto:Adrian.P.Stephens@intel.com]
Sent: Thursday, July 10, 2003 2:16 AM
To: Mehta, Pratik; swhitesell@vtech.ca; owner-stds-802-19@majordomo.ieee.org
Cc: Mike.Moreton@synad.com; bbjerke@qualcomm.com; stds-802-11@ieee.org;
stds-802-19@ieee.org; jrosdahl@ieee.org; shoemake@ti.com; coffey@ti.com;
Quinn, Liam
Subject: RE: [802-11Technical] RE: HTSG Usage Model Special Committee
Hello Pratik,
Thanks for this presentation. I think the Bluetooth / 802.11 coexistence
mechanisms described there should be equally applicable to 802.11n (High
Throughput) operating at 2.4 GHz.
I rank compatibility/coexistence into the following scale:
1. Interoperation with legacy devices (i.e. a BSS containing a mixture of
legacy and new devices)
2. Co-channel 802.11 fairness. Overlapping legacy and new devices share
the medium fairly. No new-legacy communication attempted.
3. Tolerates yyy as interferer where yyy is: 802.15.1/Blutooth, 802.15.x,
802.16.x, Cordless phone, microwave oven, Cell phone ...
We do have a requirement in our PAR for a mode of operation that
is compatible with legacy devices. We also have a practical requirement
that we have to tolerate legacy interference because there will be
deployments of 802.11 where we cannot control deployment of legacy
BSS.
3. Is the harder one. I'm hoping we benefit from the work that
.19 is currently doing with .15.3a to define some specific coexistence
scenarios for 802.11n too. So, I'm expecting that .19 will work
with us to create a set of coexistence scenarios for us to address.
Best Regards,
Adrian
Adrian P Stephens
Tel: +44 1954 204610 (home)
Tel: +44 771 276 3448 (mobile)
> -----Original Message-----
> From: Pratik_Mehta@Dell.com [mailto:Pratik_Mehta@Dell.com]
> Sent: 09 July 2003 14:58
> To: Stephens, Adrian P; swhitesell@vtech.ca;
> owner-stds-802-19@majordomo.ieee.org
> Cc: Mike.Moreton@synad.com; bbjerke@qualcomm.com;
> stds-802-11@ieee.org;
> stds-802-19@ieee.org; jrosdahl@ieee.org; shoemake@ti.com;
> coffey@ti.com;
> Liam_Quinn@Dell.com
> Subject: RE: [802-11Technical] RE: HTSG Usage Model Special Committee
>
>
> One scenario (or a couple) can be derived from the attached
> presentation
> made at the recent Bluetooth conference. If the attachment
> does not come
> through the reflector, please let me know what to do to get it to go
> through.
>
> The term "coexisting with legacy 802.11", connotates "backwards
> compatibility" rather than "coexistence" -- the former being
> a stronger
> descriptor, while coexistence can be perceived to be a weaker level of
> compatibility. Does this jell with the group's thinking?
>
> Regards,
> -pm.
>
> -----Original Message-----
> From: Stephens, Adrian P [mailto:Adrian.P.Stephens@intel.com]
> Sent: Wednesday, July 09, 2003 5:30 AM
> To: swhitesell@vtech.ca; owner-stds-802-19@majordomo.ieee.org
> Cc: Mike Moreton; Bjorn Andre Bjerke; stds-802-11@ieee.org;
> stds-802-19;
> jrosdahl@ieee.org; Matthew B. Shoemake; Sean Coffey
> Subject: RE: [802-11Technical] RE: HTSG Usage Model Special Committee
>
>
> Hello Steve,
>
> Thankyou for making your point. I still need to understand
> how coexistence
> scenarios should be specified. I think the HTSG Usage Model
> committee is
> likely to define coexistence scenarios for "legacy"
> 802.11. I think it has the relevant knowledge to do this by itself.
>
> The coexistence with non-802.11 equipment is harder to define.
> Hopefully we can benefit from the 802.15.3a ongoing work.
>
> I expect the coexistence requirements defined by .19 will
> translate into
> specific investigations rather than fit into the framework of
> simulation
> we'll be using for our other criteria.
>
> Identifying the generic characteristics of classes of devices
> is something
> that perhaps 802.19 could do. I.e. what is the typical tx mask for a
> cordless phone, what is its typical dwell time, what is its typical
> CIR/PER performance?
>
>
>
> Best Regards,
>
> Adrian P Stephens
> Intel Corporation
>
> Tel: +44 771 276 3448 (Mobile)
> Tel: +44 1223 763457 (Office)
>
>
>
>
> > -----Original Message-----
> > From: swhitesell@vtech.ca [mailto:swhitesell@vtech.ca]
> > Sent: 07 July 2003 17:15
> > To: owner-stds-802-19@majordomo.ieee.org
> > Cc: Mike Moreton; Bjorn Andre Bjerke; stds-802-11@ieee.org;
> > stds-802-19; jrosdahl@ieee.org; Matthew B. Shoemake; Sean Coffey
> > Subject: [802-11Technical] RE: HTSG Usage Model Special Committee
> >
> >
> >
> >
> > Adrian
> >
> > I wasn't able to participate in the July 1 conference call, but I
> > would like to re-iterate a point I made during the initial
> formation
> > meeting for the group. I believe your home use scenarios should
> > include a cordless telephone in the environment. Homes that have
> > WLANs are also very likely to have 2.4 or 5.8 GHz cordless
> phones in
> > them. The vast majority of the ones we (VTech) make use FHSS
> > technology.
> > I'm not sure whether that is true across the telecommunications
> > industry, but I would be willing to try and find out if you like.
> >
> > Steve
> >
> > Stephen R Whitesell
> > Senior Technical Consultant - Standards VTech Chair, TIA TR-41
> >
> >
> >
> >
> >
> >
> >
> >
> > owner-stds-802-19@majordomo.ieee.org on 07/04/2003 06:19:15 AM
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > To: "Mike Moreton" <Mike.Moreton@synad.com>, "Bjorn
> > Andre Bjerke" <bbjerke@qualcomm.com>,
> > stds-802-11@ieee.org, "stds-802-19"
> > <stds-802-19@ieee.org>
> >
> > cc: jrosdahl@ieee.org, "Matthew B. Shoemake"
> > <shoemake@ti.com>, "Sean Coffey"
> > <coffey@ti.com>(bcc: Steve
> > Whitesell/ENG/VTNCAN/VTECH)
> >
> >
> >
> > Subject: RE: HTSG Usage Model Special Committee
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Hello Mike and Bjorn and all,
> >
> > Thanks for these contributions. At the meeting this week,
> > we came out
> > with an initial list
> > of deployment environments - not as detailed as Bjorn's. We also
> > discussed the question as to how many simulation targets we
> wanted,
> > and agreed that "5" was a suitable number. So, when we create our
> > scenarios, we'll probably include elements from more than
> one of the
> > deployment environments listed below into the one model.
> >
> > For example, we'll probably have a "home" model that
> includes a device
> > in the same room as the AP, plus one in a different room. This is
> > both a realistic usage model, and exercises the technology with
> > different channel conditions.
> >
> > I like Mike's classification. I think we'll start off with a large
> > list of applications
> > and then realise that we can lump applications together into groups
> > like this.
> >
> > I think another thing we need to do is to agree on definitions for
> > some terms. I've variously used: "use case", "scenario",
> "simulation
> > target". Vinko has a "channel model"
> > and Bjorn has added: "deployment environment". If someone wants to
> > come up with some definitions that relate these and throw out the
> > baggage, I'd be very grateful.
> >
> > I spoke with Mary Cramer after the telecon. She will come up with a
> > first draft of a usage model document, I'll have a first
> hack at it
> > (and see if I can include Bjorn's input), and then put it
> out to those
> > who volunteered at the meeting (cc everybody) for their input.
> > Hopefully we can complete this by the next meeting to give
> the meeting
> > an input paper to discuss.
> >
> > The minutes from the previous meeting will be issued in due course
> > (I'll notify separately).
> >
> > It appears that the IEEE 802 mailer daemon rejects headers
> with >1024
> > B. My list of Usage model participants transgresses this
> limit. So,
> > if you want to email to the group, can I suggest that you
> "blind copy"
> > the list of names from the minutes (which won't go into the header)
> > and put a smaller list in the other address fields. FYI - I've done
> > this with this message which may explain why you get two copies.
> >
> >
> > Best Regards,
> >
> > Adrian P Stephens
> > Intel Corporation
> >
> > Tel: +44 771 276 3448 (Mobile)
> > Tel: +44 1223 763457 (Office)
> >
> >
> >
> >
> > -----Original Message-----
> > From: Mike Moreton [mailto:Mike.Moreton@synad.com]
> > Sent: 04 July 2003 08:12
> > To: Bjorn Andre Bjerke; Stephens, Adrian P; Youngsu Kim;
> > Bobby Jose; Chiu Ngo; Chris Hansen; Colin Lanzl; Craig
> > Hornbuckle; Dov Andelman; Eldad Perahia; Frank Howley; Garth
> > Hillman; Irina Medvedev; Jason Ellis; Javier Delprado;
> > jimlans@mobilian.com; Jim Tomcik; jrosdahl@ieee.org;
> > kevin@proxim.com; Kotecha, Lalit; Law Choi Look (Choi); Majid
> > Malek; Malik Audeh; Mary Cramer; PJohansson@acm.org; Paul
> > Feinberg; Qinghua Li; Rahul Malik; Robert.Huang@am.sony.com;
> > Roberto Aiello; Rolf Devegt; Sanjeev Sharma; Sean Coffey;
> > Steve Halford; Timothy Wong; Tkashi Ishidoshiro; Tomer
> > Bentzion; Tomoko Adachi; Vinko Erceg; Wayne King; Woo-Yong
> > Choi; Xiaolin Lu; Yashuhiko Inoue
> > Cc: jrosdahl@ieee.org; Matthew B. Shoemake; Sean Coffey;
> > stds-802-11@ieee.org; stds-802-19
> > Subject: RE: HTSG Usage Model Special Committee
> >
> >
> >
> > Bjorn,
> >
> >
> >
> > There are some very different requirements amongst the
> > applications in your "Data" section, which got me wondering
> > whether it might be helpful to split all the applications
> > into six groups, depending on the combination of their
> > bandwidth requirements, with how tight their QoS requirements are.
> >
> >
> >
> > For example
> >
> >
> >
> > Category 1 - High bandwidth, tight QoS
> >
> > Interactive gaming
> >
> > Video conferencing
> >
> >
> >
> > Category 2 - High bandwidth, medium QoS
> >
> > Video streaming,
> >
> > File serving
> >
> >
> >
> > Category 3 - High bandwidth, loose QoS
> >
> > File backup
> >
> >
> >
> > Category 4 - Low bandwidth, tight QoS
> >
> > Voice over IP
> >
> >
> >
> > Category 5 - low bandwidth, medium QoS
> >
> > Audio streaming
> >
> >
> >
> > Category 6 - low bandwidth, loose QoS
> >
> > Instant messaging
> >
> >
> >
> > I'd venture to say that category 6 applications don't
> > need to be included in the models.
> >
> >
> >
> > Mike Moreton
> >
> > Synad Technologies Ltd.
> >
> >
> >
> > -----Original Message-----
> > From: Bjorn Andre Bjerke [mailto:bbjerke@qualcomm.com]
> > Sent: 03 July 2003 21:02
> > To: Stephens, Adrian P; Youngsu Kim; Bobby Jose; Chiu
> > Ngo; Chris Hansen; Colin Lanzl; Craig Hornbuckle; Dov
> > Andelman; Eldad Perahia; Frank Howley; Garth Hillman; Irina
> > Medvedev; Jason Ellis; Javier Delprado; jimlans@mobilian.com;
> > Jim Tomcik; jrosdahl@ieee.org; kevin@proxim.com; Kotecha,
> > Lalit; Law Choi Look (Choi); Majid Malek; Malik Audeh; Mary
> > Cramer; Mike Moreton; PJohansson@acm.org; Paul Feinberg;
> > Qinghua Li; Rahul Malik; Robert.Huang@am.sony.com; Roberto
> > Aiello; Rolf Devegt; Sanjeev Sharma; Sean Coffey; Steve
> > Halford; Timothy Wong; Tkashi Ishidoshiro; Tomer Bentzion;
> > Tomoko Adachi; Vinko Erceg; Wayne King; Woo-Yong Choi;
> > Xiaolin Lu; Yashuhiko Inoue
> > Cc: jrosdahl@ieee.org; Matthew B. Shoemake; Sean Coffey;
> > stds-802-11@ieee.org; stds-802-19
> > Subject: HTSG Usage Model Special Committee
> >
> >
> >
> > Hi all,
> >
> > Here are some thoughts on how to start developing a set
> > of usage models for 802.11n.
> >
> > The definition of a usage model and its purpose as
> > accepted by the participants in the June 17 teleconference
> > are as follows:
> >
> > 1. Usage Model - a detailed model of expected realistic
> > deployments and applications of 802.11n devices and networks.
> > 2. Purpose - the purpose of the usage models is to
> > provide a basis for the development of functional
> > requirements and comparison criteria for proposals to the HTSG.
> >
> > As the definition implies, a usage model is made up of
> > two parts, namely
> > * a deployment environment, and
> > * a set of applications typically associated with the
> > particular deployment environment.
> >
> > As a first step in the process of defining a simple but
> > adequately realistic set of usage models, I thought it would
> > be useful to separately list all deployment environments and
> > applications that have been mentioned during our discussions
> > so far (plus some that perhaps haven't been mentioned).
> >
> > The next steps would be:
> > * Map applications to deployment environments (channel
> > and interference models for each environment to be developed
> > by the channel modeling special committee)
> > * Develop detailed specifications for each application,
> > e.g., traffic type, data rate, packet size, arrival model,
> > load, delay requirements, etc.
> > * Derive requirements for the technology from the
> > combination of deployment environments and application requirements
> >
> > Of course, we will have to narrow the long list of
> > possible environments and applications down to a manageable
> > number of combinations, but rather than deciding on that
> > number up front, let us first see how many distinctly
> > different environments and applications we are faced with. In
> > making the following two lists, I took the liberty of
> > borrowing from earlier presentations given to the HTSG by
> > Adrian Stephens and Javier del Prado.
> >
> >
> > Deployment environments
> >
> > 1. Residential:
> > * Intra-room communications
> > * Room-to-room communications
> > * Indoor-to-outdoor (e.g., for using a lap-top/TV on the patio,
> > etc.)
> >
> > 2. Enterprise:
> > * Enclosed offices
> > * Sea of cubicles
> > * Meeting room
> > * Large factory floor
> > * Hospital
> > * Warehouse
> > * Classroom/lecture hall
> > * Campus (i.e., indoor-to-outdoor as well as outdoor
> > access point for outdoor users)
> >
> > 3. Hot spot:
> > * Airport
> > * Library
> > * Convention center
> > * Hotel
> > * Shopping mall
> > * Train station/bus terminal
> > * Drive-in windows
> > * Sports stadium/concert hall
> > * City square (e.g., Verizon's plans for adding hot
> > spots to Manhattan phone booths)
> > * Public park
> >
> > 4. "Wireless cable":
> > * Residential neighborhood (e.g., TV/phone/Internet
> > connection via pole-top access points)
> >
> > 5. Mobility:
> > * Hot spots on trains, buses, air planes
> > * Curb-to-car communications
> > * Car-to-car communications
> >
> >
> >
> > Applications
> >
> > 1. Video:
> > * SDTV
> > * HDTV
> > * Video conferencing
> > * Internet video streaming
> >
> > 2. Voice/audio:
> > * Wireless VoIP
> > * Audio/music (Hi-fi stereo and multichannel - 5.1, 7.1 etc)
> > * MP3/AAC audio
> >
> > 3. Data:
> > * Web browsing/content downloading
> > * E-mail
> > * E-commerce transactions
> > * Instant messaging/chat
> > * File backup
> > * File server
> > * Interactive gaming
> > * Telemetry
> >
> > Please add, correct and/or modify the above list and
> > circulate to the whole committee. Looking forward to the discussion!
> >
> >
> > Regards,
> > Bjorn
> >
> >
> >
> >
> >
> > --
> > Bjorn A. Bjerke +1.781.276.0912 (direct)
> > Qualcomm, Inc. +1.781.276.0901 (fax)
> > 9 Damonmill Sq., # 2A bbjerke@qualcomm.com
> > Concord, MA 01742, USA www.qualcomm.com
> > <http://www.qualcomm.com/>
> >
> >
> >
> >
> >
>
> This message was sent from the 802.19 email reflector.
>
>
This message came from the IEEE 802.11 Technical Reflector List
Info at http://www.ieee802.org/11
This message was sent from the 802.19 email reflector.