stds-80220-requirements: comments on rev5
Hi all,
These are comments on rev5 of the document from Marc Goldberg, Michael
Youssefmir, Samir Kapoor, Joanne Wilson, Arif Ansari and John Fan.
--John
=================================
2.1. Voice over IP
Action: Remove the second sentence relating to call blocking.
Text: "The MBWA shall support VoIP services. QoS shall provide latency,
jitter, and packet loss required to enable the use of industry-standard
codecs."
Rationale: The sentence related to call blocking should be removed because
call blocking is an application layer specific issue. The Requirements
document should specify the classes of supported QoS, but
application-specific exception handling should not be included in the
document.
Call blocking or other exception handling techniques should be handled at a
higher layer for any application that requires special QOS treatment. If
there is an application (such as VoIP) that requires special QoS treatment,
the application shall request it of the air interface via an API. If the air
interface cannot provide the desired QoS, it shall inform the application of
that fact via the API. It is up to the application to take the appropriate
action, e.g., "blocking" the call.
3.1. System Architecture
Action: Change the notations in the bubbles to point to the relevant section
of the text (or remove the bubbles).
Rationale: This figure contains numbers that are not reflected in the
text. The action above was suggested by Mark as a compromise in the 802.20
meeting on 07/23/03.
4.1.2. Spectral Efficiency
Action: Change to downlink sustained spectral efficiency of >1
bps/Hz/sector, as stated in the PAR. Remove the mention of uplink sustained
spectral efficiency.
Rationale: The numbers that appear in the Requirements Document for
sustained spectral efficiency should match the PAR. The PAR is the defining
document we have today for 802.20 and there clearly was no consensus on the
new proposed numbers at the plenary. The degree to which the PAR
requirements are exceeded can be incorporated in the evaluation criteria for
the AI proposals.
4.1.3. Frequency Reuse
Old text: ˇ§The AI shall support universal frequency reuse but also allow
for system deployment with frequency reuse factors of less than or greater
than 1.ˇ¨
Action: Change the text into two sentences.
New Text: "The AI shall support universal frequency reuse. The AI should
allow also for system deployment with frequency reuse factors of less than
or greater than 1."
Rationale: It should be made clear that universal frequency reuse is
mandatory and support for frequency reuse factors of less than one is
recommended though non-mandatory.
4.1.4. Channel Bandwidth
Action: This section should be stricken.
Rationale: The current text requires "multiples of 5 MHz" for deployment.
No rationale for 5Mhz has been given on the reflector. Beyond that, a 5 MHz
minimum bandwidth would limit the applicability of the MBWA AI in many of
the available licensed bands below 3.5 GHz.
4.1.6. Mobility
Action: Remove the phrase "but shall not be optimized for only one
mode".
Text: "The AI shall support different modes of mobility from pedestrian
(3 km/hr) to very high speed (250 km/hr). As an example, data rates
gracefully degrade from pedestrian speeds to high speed mobility."
Rationale: Since the AI supports different mobility modes, it is not
necessary to say that it cannot be optimized.
4.1.7. Aggregate Data Rates ˇV Downlink & Uplink
Action: Remove this table.
Rationale: The sustained spectral efficiency is defined as >1
b/s/Hz/sector in the PAR, so that the expected aggregate data rates
should be >5 Mbps/sector. Hence, the numbers in this table are not
consistent with the numbers in the PAR. This issue of expected
aggregate data rates should be addressed in the evaluation criteria.
Action: Remove the sentence "Average user data rates in a loaded system
shall be in excess of 512Kbps downlink and 128Kbps uplink. This shall
be true for 90% of the cell coverage or greater."
Rationale: These expected per-user data rates are ill-defined because as
discussed on 7/23/03 they depend on the overall combination of coverage and
aggregate capacity and system deployment. Expected per-user rates are not an
intrinsic characteristic of the system. This issue of expected per-user
data rates should be addressed in the evaluation criteria.
4.1.8. Number of Simultaneous Sessions
Action: Change title to "Number of Simultaneous Active Users"
Rationale: The term "session" is inappropriate since it is not clear what it
refers to, e.g., TCP session, application session, etc. Also, the intent of
the current text seems to be to place a minimum requirement on the number of
users that are able to access the system at low latency. This is also the
intent and definition of active users.
Action: Use the definition of active user given in the Appendix.
Text: "The system should support > 100 simultaneous active users per
carrier. An active user is a terminal that is registered with a cell
and is using or seeking to use air link resources to receive and/or
transmit data within a short time interval (e.g., within 50 or 100 ms)."
4.1.9. Latency
Action: Remove the sentence: "The system shall have a one-way target
latency of 20 msecs from the base station to the end-device when the
system is under load."
Rationale: This is attempting to reflect the latency for applications, which
may be better to evaluate in the evaluation criteria, since it will depend
on traffic models, QoS of individual users and load conditions. It is
appropriate to specify latency from the time that a packet is delivered from
the transmitting-side MAC until the time that it is received at the
receiving side MAC. This is reflected in the second paragraph describing
the ARQ loop delay.
4.1.10 Packet Error Rate
Action: Remove the sentence "The packet error rate for 512 byte IP
packet shall be less that 1 percent after error correction and before
ARQ"
Rationale: The current text mixes various levels: the packet is at the
IP level (which may consist of multiple air interface packets), while the
requirement is placing limits on air interface performance before ARQ.
Any packet error rate for IP needs to be after the link-layer ARQ, since
this link-layer ARQ would be used in the system. In this context, it would
make more sense to use the frame error rate rather the packet error rate,
and the frame error rate requirement could be stated before ARQ.
From the requirements point of view, the existing text without this sentence
already captures what is required of the system.
4.1.12 Antenna Diversity
Original text: ˇ§At a minimum, both the Base Station and the Mobile Terminal
shall provide two element diversity. Diversity may be an integral part of an
advanced antenna solution.ˇ¨
Action: Change to ˇ§The Base Station shall provide antenna diversity.
Diversity may be an integral part of an advanced antenna solution. Antenna
diversity shall not be a requirement of the mobile station.ˇ¨
Rationale: This requirement is a vendor specific implementation requirement,
and not related to the MAC/PHY Also this material was not introduced with a
rationale. In fact, Rev3 of the document contained the text ˇ§Antenna
diversity shall not be a requirement of the mobile station.ˇ¨ We should
leave it up to vendors/operators who understand the cost/form factor
tradeoffs whether they support user terminal diversity. For example, there
is a wide variety of 802.11 cards some have diversity/some do not.
4.1.13 Best Server Selection
Action: Delete entire section
Rationale: This material was not introduced with a rationale.
4.1.14 QoS
Action: Delete phrase ˇ§for example, using Subnet Bandwidth Manager.ˇ¨
Rationale: Subnet bandwidth manager (SBM), defined by RFC 2814, addresses
the issue of IntServ RSVP bandwidth reservation over local area networks.
Bandwidth reservation is not a meaningful concept with non-deterministic
physical layers such as one would expect to see in a mobile radio system.
Section 4.4.1 of this document, moreover, calls for a DiffServ QoS model.
4.1.16 Handoff
Action: replace "hard" and "soft" handoff terms with "break-before-make"
And "make-before-break" respectively. Update sections 4.1.16.1-4.1.16.4
accordingly.
Rationale: The latter terms are more appropriate for a packet switched air
interface. Moreover, soft handoff has existing connotations in the context
of CDMA networks (e.g. relating to frame level synchronization between base
stations etc) and use of the new terms avoids any confusion.
4.1.16.5
Action: Replace entire section with the following ˇ§In supporting high speed
mobility in an all IP network, the MBWA air interface shall be designed in a
manner that does not preclude the use of MobileIP or of SimpleIP for the
preservation of IP session state as a subscriber's session is handed over
from one base station or sector to another.ˇ¨
Rationale: As discussed at the 7/22 working group meeting, there are
alternatives to Mobile IP for maintaining IP Session continuity as mobiles
are handed over from one base station to the next by the air interface.
4.2.2 Link Adaptation and Power Control
Action: Add the sentence: "The system will have adaptive modulation and
coding in both the uplink and the downlink"
Rationale: This is text from the other section.
Action: Remove ˇ§The Radio system shall provide at least 99.9 link
reliability.ˇ¨
Rationale: The requirement is deployment specific. The preceding text: ˇ§The
AI shall support automatic selection of optimized user data rates that are
consistent with the RF environment constraints and application requirements.
The AI shall provide for graceful reduction or increasing user data rates,
on the downlink and uplink, as a mechanism to maintain an appropriate frame
error rate performance.ˇ¨ appropriately captures what is necessary at the
requirements level.
4.3 Spectral Efficiency
Action: This should be changed to Section 4.2.5
Rationale: This is a PHY/RF issue, and so should be moved to Section 4.2.
Action: Change ˇ§readily extensible to wider channelsˇ¨ to ˇ§readily
extensible to wider allocationsˇ¨
Rationale: ˇ§Allocationˇ¨ is the proper term for a spectrum block covered by
a particular regulatory regime of license.
4.3.1 Adaptive Modulation and Coding
Action: This should be removed
Rationale: The sentence is captured in "link adaptation"
4.3.2 Layer 1 to Layer 2 Interworking
Action: Remove entire section
Rationale: This is an implementation detail and not an intrinsic
characteristic of the air interface.
4.4.1 CoS/QoS Matched criteria
Action: Remove these sections
Comment: The consensus of the group is that the motivation for these
requirements are very difficult to fathom. Suggest that the author
resubmit with rationale to the correspondence group.
4.5.2 Scheduler
Action: Move this section to its own section (e.g., section 4.6)
Rationale: This does not belong to Layer 3+ support.
4.5.3 MAC Complexity Measures
Original text: "To make the MBWA technology commercially feasible, it is
necessary the complexity is minimized at the MAC, consistent with the goals
defined for the technologies. This section defines complexity measures to
be used in estimating MAC complexity."
Action: Delete this section
Reason: MAC complexity measures should not be addressed by this requirements
document. Our driving goal must be to achieve the performance of the PAR.
Complexity measures even, if they could be articulated in this document, are
not relevant when compared to the overriding goal of achieving performance
for data.