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 Document version 8B

Title: Input to 802.20 Requirements Document version 8B
Alan-
   Will all due respect, I don't think you can adequately define a PHY/MAC layer protocol without understanding what type of services will be deployed over it.... and this will be IP based data services.
These services should drive the definition and conception of the underlying layers, otherwise they end up being defined in a technical "vacuum".
 
Regards,
Jessie
-----Original Message-----
From: Chickinsky, Alan [mailto:alan.chickinsky@ngc.com]
Sent: Wednesday, October 22, 2003 6:04 PM
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 Document 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