Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Dear A&M&M :-), I would agree with Mark on this one. I believe that backwards compatibility is definitely something we should strive for. Converging the fixed and mobile services will definitely be easier if, for example, both services use the same PHY. I definitely believe that some of the PHYs can support mobility while maintaining backwards compatibility to the fixed system. I have no problem in stating that in a PAR. I'm not yet sure what changes will be required for the MAC. But again, backwards compatibility should be a goal. I also agree with Avi on the speed issue. I would rather we start with the existing standard and see what level of mobility can be obtained rather than set a target which could require a change to the standard to reach it. Shawn -----Original Message----- From: Avi Freedman [mailto:avif@hexagonltd.com] Sent: Sunday, November 03, 2002 3:16 PM To: Marianna Goldhammer; Mark Klerer; 'Kiernan, Brian G.'; r.b.marks@ieee.org Cc: stds-802-mobility@ieee.org; stds-802-16-mobile@ieee.org; stds-802-sec@ieee.org Subject: stds-802-mobility: Re: stds-802-16-mobile: Creating Unique Identities for the two mobility PARs Dear M&M I tend to agree with Mark's spirit, in the sense that a distinction can be made between the two mobility groups based on the fact that 802.16 is working on adding mobility functionality to the 16a standard, while ECSG is an blank slate. But I also agree with Marianna that backward compatibility was never the issue. Perhaps indicating the 250kmh speed in the 802.15 PAR conveyed the wrong idea, and might have caused a misinterpretation of the intention. However, speed has to be included in the PAR, as it is an essential measure of a mobile system performance. Maybe a minimal speed of 90kmh should be set and higher speed should be considered as "best effort" Avi ----- Original Message ----- From: "Marianna Goldhammer" <marianna.goldhammer@alvarion.com> To: "Mark Klerer" <M.Klerer@flarion.com>; "'Kiernan, Brian G.'" <Brian.Kiernan@interdigital.com>; <r.b.marks@ieee.org> Cc: <stds-802-mobility@ieee.org>; <stds-802-16-mobile@ieee.org>; <stds-802-sec@ieee.org> Sent: Sunday, November 03, 2002 12:17 PM Subject: RE: stds-802-16-mobile: Creating Unique Identities for the two mobility PARs > Dear Mark, > > I think that we disagree on the 802.16 scope. We are not looking for > "backward compatibility" with our existing 802.16a standard. > > We are looking to improve the existing 802.16a standard, to support > high speed, high data rates mobility. > > We think that we can take advantage of > 80% of 802.16 MAC, by adapting > it to support mobility. > > And we do not target "pedestrian mobility". We know, due to work done > within 802.16 SG, that even the existing 802.16a OFDM and OFDMA > PHY work at very high speeds. > > I think that a key difference issue is the data rate. We look to converge > the > fixed and mobile wireless service, based on high data rates provided by > both BS and CPE equipment. We will be able to target mobile terminals, > as well as to provide mobile symmetrical feeding for moving "Hot Spots". > > > Regards, > > Marianna > > > -----Original Message----- > From: Mark Klerer [mailto:M.Klerer@flarion.com] > Sent: Sunday, November 03, 2002 1:44 AM > To: 'Kiernan, Brian G.'; 'r.b.marks@ieee.org' > Cc: 'stds-802-mobility@ieee.org'; 'stds-802-16-mobile@ieee.org'; > stds-802-sec@ieee.org > Subject: stds-802-16-mobile: Creating Unique Identities for the two mobility > PARs > > > Roger, Brian > > In response to the SEC chair's request that we work toward defining unique > identities of the two mobility PARs, I would like to suggest the following. > > The 802.16 Study Group has the charter of allowing the evolution of 802.16 > compliant systems toward supporting mobility. To that end it would appear > logical that changes to the PHY and MAC be fully backward compatible with > the existing specification and that no a priori statement be made about the > station speed that can be supported by such a system. I would like to > suggest that the PAR therefore focus on these aspects and that the project > scope be described as: > > To amend the 802.16 standard to support combined fixed and mobile operation > from within a single system. The extension will address PHY and MAC changes, > that are fully backward compatible, while supporting mobile subscriber > operation and roaming between 802.16 base-stations or their sectors. This > amendment will allow high spectral efficiency (3~4 bits/s/Hz), macrocell > sizes and NLOS operation. > > The ECSG PAR's objective, on the other hand, is to develop a standard that > is optimized for broadband wireless data mobility without any a priori > assumptions about the technologies used to realize that objective. The PAR, > therefore, states the design objective of developing a spectrally efficient > solution that will support mobility classes up to 250 Km/h. I believe that > there are no changes required in the wording of that PAR. > > In essence we then have two PARs with, one addressing the need for a > solution optimized for full vehicular mobility and the other the need for > extending the capabilities of 802.16 systems to support a level of mobility. > > > This is a new proposal that I believe should allow the SEC to approve both > PARs. I am copying the two mobility groups in order to get their reaction to > this proposal and see if they will agree to such PARs. If this is acceptable > we could formally revise the PAR on Monday or Tuesday and approach the SEC > on Friday with a consensus position. > > > Regards > > Mark Klerer > Chair - MBWA-ECSG > 135 Route 202/206 South > Bedminster, NJ 07921 > > . E-mail: m.klerer@flarion.com > ( Phone: 908-997-2069 > 6 Fax: 908-997-2050 > > > This mail was sent via mail.alvarion.com > > **************************************************************************** ******** > This footnote confirms that this email message has been scanned by > PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. > **************************************************************************** ******** >