Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: stds-80220-requirements: Input to 802.20 Requirements Documen t version 8B

Title: Input to 802.20 Requirements Document version 8B
Alan,
 
In my vision we should design the radio to meet the applications.
 
Ignoring IP level and the applications behind may drive you to a less performing design.
 
At the contrary, will be good to have the operators opinion about the percentage (from total capacity) of traffic types, as IP multicast and IP ANY cast.
 
Marianna
 
 
-----Original Message-----
From: Chickinsky, Alan [mailto:alan.chickinsky@ngc.com]
Sent: Thursday, October 23, 2003 3:04 AM
To: 'JEWITT Jessie / FTR&D / US'; 'Stds-80220-Requirements (E-mail)'
Cc: POPESCU Paul / FTR&D / US; ZHOU Jenny / FTR&D/ US; BERTIN Philippe FTRD/DMR/REN; SRIVASTAVA Anish / FTR&D / US
Subject: RE: stds-80220-requirements: Input to 802.20 Requirements Documen t version 8B

Jessie-
 
A lot of your comments are directed toward IP and IP related features.  I need to point out that IP is a layer 3 and above protocol.  802.20 is only specifying layer 1 and part of layer 2. 
 
We on 802.20, unless specified otherwise, support all 802.1 protocols.
 
alan
-----Original Message-----
From: JEWITT Jessie / FTR&D / US [mailto:jessie.jewitt@rd.francetelecom.com]
Sent: Wednesday, October 22, 2003 8:32 PM
To: 'Stds-80220-Requirements (E-mail)'
Cc: POPESCU Paul / FTR&D / US; ZHOU Jenny / FTR&D/ US; BERTIN Philippe FTRD/DMR/REN; SRIVASTAVA Anish / FTR&D / US
Subject: stds-80220-requirements: Input to 802.20 Requirements Document version 8B
Importance: High


Hello,
   Based upon the recent input we (France Telecom) gave for the requirements, plus a general reading of the most recent document (8B), you will find below

some comments. For details of these requirements, please see the document we submitted:

*  The AI must support IPv6 services, and hence also support ANYCAST. Shall support MobileIP v4/v6.
*  Would like to see more symmetrical uplink/downlink, with sustained spectral efficiency at  2bps/Hz/sector.
* Latency: Will need to support IPPM metrics (one-way) currently being standardized at the IETF.
* QoS:As the 802.20 AI will be used to deploy IP based services, and the fact that QoS is currently being defined at IETF by the prevalent DiffServ model (RFC 2474/75), we will require mapping

of the 3 types of classes: AF, EF, BE and the subdivisions within based upon the DSCP to the 802.20 MAC layer. End-to-end QoS must be assured for 3 different scenarios: 1) General resource availability

over 802.20, 2) Handover between similar access technology, and 3) Handover between dissimilar access technology. Please see section 2.3 in our input document for full set of requirements.

* Support for IP level handoff according to J. Manner, M. Kojo, "Mobility Related Terminology", draft-ietf-seamoby-mobility-terminology-04.txt  (work in progress at IETF). Why are you proposing to

delete the section of IP level handoff??
* Antennae Diversity/Repeaters:  I've expressed in a previous email that these are implementation details, not requirements. We need to quantify the requirements that would drive such solutions, for

example quality of reception, loss of signal, coverage, # of users, etc.
*  Security algorithm: requirement as stated is vague and open to interpretation.
* Receiver sensitivity: same comment as above.
* Synchronization between base stations would be good, but will accept optional if that is the general concensus.
* 802.1q-> propose that you leave this in. Even though it is tied to a specific architecture, you claim to support this architecture. Also, as it is ubiquitous, it is worth mentioning. What about 802.1p?

* CPE software upgrade: shouldn't this be in sync with what is happening at OMA and SDR forum?
* OA&M support: "The air interface will provide necessary infrastructure in order for a network operator to monitor the performance of the 802.20 air interface." Oh my, this is quite ambiguous!

We need to clearly specify what OA&M info is required. I see you've gotten a good start in the list provided. I'll need to get back to you on this one.

* Requirement for link layer service interface for reporting info to/from link layer to higher layers... not just for QoS but for more general handover considerations.

* Scheduling mechanisms: what does, ".... so long as the standard control messages, data formats, and system constraints are observed" really mean? This is ambiguous.

* Agree with Lucent's comment about interworking. This MUST be specified!!!!


Thanks for taking these comments into consideration,
Jessie JEWITT
France Telecom R&D





This mail passed through 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.
************************************************************************************
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.
************************************************************************************