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