| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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.
PratikMehta_BTcongress_Coexistence_Dell_Microsoft.pdf