stds-80220-requirements: Comments on Versions 2 and 3 of the Requirements
Here are some comments from
Ayman, Arak, and myself...
Jim
Section 1.1
"These requirements are consistent with the PAR document (see
section 1.3 below) and shall constitute the top-level binding
specification for the 802.20 standard"
%%%%%%%%%%
There was a
comment to delete the word "binding" from this sentence.
While we don't have a problem with the deletion itself, the comment
mentions that there is no time to ballot the requirements document.
Its important to keep in mind that there is not yet an approved schedule
or workplan for the group. Given the importance of the requirements,
selection criteria, etc, to the project, a quick ballot cycle may be
appropriate as a consensus building vehicle.
Section 1.1 Strikeout of
"interoperability " clause.
I notice that
in Version 3 this clause has been removed. More specifically the clause
"interoperability with other wireless access systems with intra and
inter-systems handoff support" This is the beginning of a
number of comments intended to strike out sections about dealing with
inter/intra system handoffs. Given that 802.20 is targeted for
vehicular velocities up to about 250 km/hr, a mobile user could
conceivably be going through cells at a very great pace. Some
method to seamlessly (not just keeping the IP 4-tuple) maintain
connections will be needed. Restore sections related to handoffs,
that have been deleted in Rev 3.
Section 2
Title Text "Overview of Services and Applications"
Add "and
Related Requirements" to the end of the title.
Note, that we
do not necessarily advocate drafting out detailed requirements for each
and every application. Nonetheless, we should not lose sight of the fact
that services and applications can and will exert certain requirements on
the MAC and PHY. For instance, in order to make argument that services
such as voice can be implemented via VoIP and QoS, we first need to
define what QoS is, a point that is even made later in the suggested list
of changes.
Section 2
Page 9, Line 2-5
After: "The AI shall support interoperability between an IP Core
Network and IP enabled mobile terminals."
Insert: "This allows applications including, but not limited to,
full screen, full graphic web browsing, e- mail, file upload and download
without size limitations (e.g., FTP), video and audio streaming, IP
Multicast, VPN connections, VoIP, instant messaging and on- line
multiplayer gaming."
This sentence was originally submitted by Scott Migaldi and Jim Mollenaur
and provides a nice overview of applications used over an Internet
service.
Remove
or Define/clarify full screen
%%%%%%%%%%
Section 2.1
Page 9, Lines 11- 30
We should delete this exhaustive listing since we have little to say
about the applications themselves and we are not inserting requirements
into this section anyway.
Another
unresolved issue. Noted that in Draft 3, these lines have already been
crossed out. The section on Applications may have requirements
inserted in so far as these affect MAC and PHY.
Sections 2.4.x
E911 and many
other sections have been deleted in response to a comment made in e-mail
and not discussed. Some of these need to remain. For example,
E911, is composed of location services and priority access. While
location services may be provided above the MAC, there is a need to
provide MAC hooks to deliver priority access. To provide priority
access we will need a requirement on the airinterface to provide such a
mechanism.
Restore priority access section and add:
"The Air Interface shall include provision to provide priority
access to mobile stations."
Section 2.4.5 3G Service
Application Extensions for MBWA
Since MBWA is
being designed to operate in concert with 3G services it will be
necessary to define a requirement for it. Do not delete the
section.
Section 3.2 Version 3 edited
version
The phrase
"Any AI Interfaces" has a typo. remove "AI"
Section 4
Section 4's
title has been changed. Change back to "System
Requirements" This section was meant to capture system
behavior as well as performance requirements.
Section 4.5 Packet Error
Rate
Looking at
version 3 and a comment that resulted in the editing shown.
Capability is not useful unless it is used. Change the first line
to read: "The physical layer shall adapt..."
ARQ methods are a tool to achieve improved packet error rate. There
are other tools as well, and no need to mandate that all technology
submissions use ARQ. Change the second sentence to say:
"The air interface may use appropriate ARQ..."
Perhaps, we can be more specific about what PER can be expected after
PHY/MAC. PHY/MAC should have mechanisms to support a range of PER
from 10^-2 to 10^-6.
Section 4.11
Section 4.11
has been deleted from Version 3. Restore. Good handoff
techniques will be required, given the high vehicular mobility PAR
requirements (250km/hr).
Sections 4.11, 4.12, 4.13
These sections were meant to capture security requirements. The edited
text is too weak to be useful.
Add
To Control Access, a cyptographically generated..." shall be
specified.
The mobile station and base station shall provide base station
controllable Over the air Message Integrity Mechanisms.
The mobile station and base station shall provide network controllable
privacy mechanisms.
Section 4.19
Signaling
This section
has been removed in version 3. Non-Data-Channel signaling is an
important capability that helps to assure a robust air interface
design. There is a need for ms to bs signaling channels to be
implemented that are not necessarily part of the user data stream.
Restore sections and requirements will be drafted.
..................................................................................
James
D. Tomcik
QUALCOMM,
Incorporated
(858)
658-3231 (Voice)
(619)
890-9537 (Cellular)
From:
San Diego, CA
PGP:
5D0F 93A6 E99D 39D8 B024 0A9B 6361 ACE9 202C C780
..................................................................................