stds-80220-requirements: Corrected: Comments and Changes to 802.20 requirements Document rev2
Dave and all:
I added a few corrections. Please use this corrected version instead.
Thanks.
Mike Youssefmir
ArrayComm, Inc.
Comments and Changes to Document rev2 from Mike Youssefmir, Joanne Wilson, John Chen, Todd Chauvin, Brett Schein and Branislav Meandzija:
Section 1.1
Page 7, Line 9
"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"
Delete the word "binding". For the document to be "binding" it would have to go to Working Group Letter ballot and we do not have time in the schedule for that.
%%%%%%%%%%
Section 1.1
Page 7, Line 10-11
"The requirements also include interoperability with other wireless access systems with intra and inter-systems hand-off support."
Delete sentence. Interoperability and inter-system handoff support has been noted in the open issues section. These requirements cannot be met in a generic way and cannot be achieved simultaneously for multiple systems that are not interoperable with each other. As a mobile system, the 802.20 AI would obviously support intra-system handoff. This is stated elsewhere in the document
%%%%%%%%%%
Section 1.1
Page 7, Line 14-15
Delete "for which the 802.20 PHY and MAC layers shall form the lower protocol layers" in "This document will establish the detailed requirements for the Mobile Broadband Wireless Access (MBWA) systems for which the 802.20 PHY and MAC layers shall form the lower protocol layers."
The scope already states that "an "802.20 system" constitutes an 802.20 MAC and PHY implementation"
%%%%%%%%%%
Section 2
Page8, Line 5
Insert the words "Overview of" into the title of this section to read "Overview of Services and Applications"
%%%%%%%%%%
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.
%%%%%%%%%%
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.
%%%%%%%%%%
Section 2.2.1
Page 10, Line 3-6
"Voice Services are currently among the most profitable services available to the cellular and PCS service providers. These services are highly optimized to provide high quality at very minimal cost to provide. It is expected that MBWA will need to make some accommodation to provide voice services as an integral part of any service offering."
Delete. MBWA is a network optimized for the delivery of data services and not a network optimized for the delivery of voice services. Per the PAR we should focus on optimizing the system for IP data services, which includes Voice over IP.
%%%%%%%%%%
Section 2.2.1
Page 10, Lines 7-12:
"The MBWA system should accommodate VOIP services by providing the capability to transport a variety of industry standards formats to include but not limited to MCGP( per RFC 2705), SIP (per RFC 2543), SIP+. The codec’s to be supported by the PHY/MAC need to include (list), G.726-32, G.729, G.723 with respect to jitter and latency. Budgets for jitter and latency need to be established. The MAC should provide call blocking for supported formats."
Comment: This was discussed on the email group.
Proposal: Replace the text with the following:
"The standard shall support real time latency sensitive applications classes (examples of which include voIP) and the air interface QOS architecture shall provide mechanisms to support such service classes. ZZZZ
We could then repeat the same statement for:
a) streaming applications such as audio/video streaming
b) interactive latency sensitive applications such as online gaming
c) interactive latency insensitive applications such as web browsing
Finally, Dave M suggested inserting a general requirement for ARQ turnaround in the email discussion.
%%%%%%%%%%
Section 2.2.4
Page 10, Line 16
Proposal: Delete "E911".
Reason: This is a regulatory requirement for voice and not data systems. It is also highly US centric and inappropriate in an international standard.
%%%%%%%%%%
Section 2.3.1.1
Page 10, Line 18
Proposal: Delete "Location Services".
Reason: Location Services are not multimedia applications.
%%%%%%%%%%
Section 2.3.1.2
Page 10, Line 19
Proposal: Delete "Priority Access". This is again a U.S. regulatory requirement for Commercial Mobile Radio Services that are primarily used for voice communication. This is an inappropriate requirement for an international standard. Besides, there is no priority access over the Internet. Priority access on an IP-based network would surely be different than on a circuit switched network, and more likely it would be an application under QOS Management, which is already a feature listed elsewhere in the requirements document..
%%%%%%%%%%
Section 2.3.2
Page 10, Line 20-24
"These services are Data-Like services, but currently are not implemented as true "data services." Examples of these services are the current SMS offerings of GSM and CDMA2000 networks, as well as the "instant messaging" type services provided by independent service providers."
Comment: We agree with Bill Young’s previous input.
Delete text because IP already provides a highly successful platform to deliver services such as this over and this should be sufficient. There should not be a requirement to support legacy applications built for non-IP systems on a new 802.20 AI standard.
%%%%%%%%%%
Section 2.3.2.1.1
Page 10, Line 25-30
"SMS Messaging
Definition and Characteristics
"Classic" SMS messaging was first described for 2G systems such as GSM and IS-95 and currently are implemented directly over the cellular infrastructure, without need of data communication networking infrastructure. Several different variations of these services exist, to be described as part of this section."
Proposal: Delete.
Reason: We support the comments previously made by Bill Young.
SMS Messaging was built for legacy circuit-switched, cellular systems and equivalent functionality is already supported or can be supported over an IP system.%%%%%%%%%%
Section 3.1
Page 11, Line 13-17
"The system architecture shall be consistent with the IEE 802.xxx family of standards model and share the upper layers with peer wireless standards (802.11, 802.15, 802.16 etc.). These systems also support interoperability with other wireless access systems with intra and inter-system hand-off support."
Delete "and share the upper layers with peer wireless standards (802.11, 802.15, 802.16 etc.)". Reason: These standards do not have upper layers.
Delete "These systems also support interoperability with other wireless access systems with intra and inter-system hand-off support." This statement is incorrect. These systems do not support inter or even intra-system handoff.
%%%%%%%%%%
Section 3.1
Line 13
"The 802.20 AI shall be optimized for high-speed mobility"
Proposal: Change to "The 802.20 AI shall support high-speed mobility."
Reason: The PAR includes a number of requirements and states that the AI is to be optimized for IP-data transport and supports various vehicular mobility classes. It does not establish for which of the vehicular mobility classes or other parameters the AI should be further optimized. Optimizing for high speed mobility will place stringent requirements on the air interface that could require trading off other performance parameters which could be more important to end users and service providers.
%%%%%%%%%%
Section 3.1.2
Page 11,Line 23-36, Line 1-15
"To facilitate a layered approach, the 802.20 specification shall incorporate a reference partitioning model consisting of the MAC and PHY""
Proposal: Delete entire text in section.
Replace with the following text which defines the limits of 802.20.s responsibilities to define the MAC and PHY layers:
"To facilitate a layered approach, the 802.20 specification shall incorporate a reference partitioning model consisting of the MAC and PHY. This layered approach shall be generally consistent with other IEEE 802 standards and shall remain generally within the scope of other IEEE 802 standards as shown in figures 1 &2."
Delete Figure 1 and insert two new figures consisting of slides 8 & 9
of the slide deck sent by Alan Chickinsky to the requirements group on
Jun 21 2003.
Reason: This section is currently overly detailed and proposes a specific division of capabilities within the MAC and PHY layers that is best addressed in the specification itself. Alan's breakdown and slides are far more instructive in terms of what reference model we should follow.
%%%%%%%%%%
Section 3.2
Page 12-13, Line 17-18,1-2
"The AI shall support open interfaces between any network entities in the AI that may be implemented by service providers and manufacturers as separate systems, sub-systems, or network entities. IETF protocols shall be considered and adopted in these open interfaces, if appropriate."
Replace with: "The AI should not mandate specific interfaces elsewhere in the network beyond the link from the base station and terminal and shall otherwise be agnostic to architectures north of the base station."
Reason: As now stated, the first sentence is confusing and hard to understand. As now stated, this requirement would provide network operators with the flexibility to implement the 802.20 standard in the most cost effective way that they can taking into consideration their existing or planned network architecture.
%%%%%%%%%%
Section 4
Page 13, Line 3
Proposal: Change "System Requirements" to "Functional and Performance Requirements"
Reason: This document should focus on the functional and performance requirements for 802.20 as opposed to setting system level requirements, which are more implementation specific.
%%%%%%%%%%
Section 4.1
Line 6-23:
"Consistent with the 802.20 PAR, tables 1 and 2 define the required air interface data rates and capacity characteristics…."
Proposal: Either Delete Table 1&2 or provide source for the data rates proposed.
Reason: This is significantly different than the PAR and is using different parameters than those used in the PAR. The PAR establishes peak and aggregate data rates and ties these values to spectrum. Additionally, talking about average data rates is meaningless unless one specifies the number of users.
%%%%%%%%%%
Proposal: Delete Voice Capacity from tables.
Reason: The MBWA AI is to be optimized for IP data transport. For data networks, one therefore cannot talk about Erlangs without some notion of the data rates required for these voice applications users. In any case, this issue was discussed on the requirements email list and the consensus was to remove the voice capacity figures fm these tables.
%%%%%%%%%%
Section 4.2
Page 14, Line 13
Proposal: Just before the sentence starting, "Additionally, the AI …" Insert the following sentence: "The interior cell is specified here to ensure that the full effects of interference from adjacent cells is taken into account when determining the spectral efficiency."
%%%%%%%%%%
Section 4.3:
Page 14, Line 28-33
"The AI shall support the means to enable end-to-end QoS within the scope of the AI and shall support a Policy-based QoS architecture. The resolution of QoS in the AI shall be consistent with the end-to-end QoS at the Core Network level. The AI shall support IPv4 and IPv6 enabled QoS resolutions, for example using SBM. The AI shall support efficient radio resource management (allocation, maintenance, and release) to satisfy user QoS and policy requirements."
Proposal: Replace: "SBM" with : "Subnet Bandwidth Manager, (SBM),"
%%%%%%%%%%
Section 4.4
Page 14 Line 32
"Simultaneous Users"
Proposal: Section should be deleted or clarified.
Reason: Requirement is meaningless without, for example, definitions for simultaneous users, assumed channel bandwidth etc
%%%%%%%%%%
Section 4.5 Packet Error Rate
Page 14, Line 1-4
"The physical layer shall be capable of adapting the modulation and coding so as to achieve a packet error rate of 10^-3 or better (based on a 1500-byte packet) for all mobile stations. Use of ARQ shall reduce the packet error rate to 10^-5 or better."
Proposal: Replace paragraph with the following:
"The physical layer shall be capable of adapting the modulation, coding, and power levels to accommodate RF signal deterioration between the BS and user terminals. The air interface shall use appropriate ARQ schemes to ensure that error rates are reduced to a suitably low levels in order to accommodate higher level IP based protocols (for example, TCP over IP)"
Reason: This packet error rate is arguably too conservative. A higher packet error rate can be tolerated by a good ARQ scheme with minimal latency and jitter impact on higher layers. In any case we are getting into an implementation detail.
%%%%%%%%%%
Section 4.6 Link Budget
Page 15, Lines 7-11
"The system link budget shall be appropriate for ubiquitous metropolitan area networks and capable of reusing existing infrastructure with cell sizes typical of macro-cellular wireless networks. Smaller cells shall also be supported to accommodate operational, deployment and capacity considerations. System link budget in excess of 160 dB for all devices and terminals at the data rates specified in the earlier section. 11"
Proposal: Replace paragraph with the following text:
"The system link budget shall be 150-170 dB for all devices and terminals at the data rates specified in the earlier section assuming best practices in terms of base station design, user terminal design, and deployment techniques. "
Reason: Specifying a specific link budget "160 dB" is meaningless without specifying other system level parameters, such as base station antenna gains, and implementation specific power levels. Such implementation specifics are beyond the scope of this document. This proposal provides reasonable flexibility in the link level budget to accommodate different network implementations.
%%%%%%%%%%
Section 4.6 Link Budget
Page 15, Lines 8
Proposal: Replace: "infrastructure" with "cell sites"
Reason: Infrastructure is too general a term for this purpose
%%%%%%%%%%
Section 4.7
Line 15
Change "Air link Reliability" to "Link Adaptation and Power Control" and promote to a section heading. Also this section must then be combined with section 4.17 "Link Adaptation, Power Control, and adaptive power allocation"
%%%%%%%%%%
Section 4.7
Line 20
"Radio system should have sufficient diversity to provide at least 99.9 AI reliability"
This sentence should be clarified or deleted.
Reason: It is not clear what this specification requires of the AI since ireliability will most assuredly be linked with a particular deployment scenario.
%%%%%%%%%%
Section 4.10:
Line 30-31
"Interoperability (including handoff) with other existing mobile wireless systems. Seamless handoff of voice over IP and other packet data services between 802.20 and existing mobile wireless systems."
Proposal: Delete this section.
Reason: This is one of the outstanding philosophical differences and such text should not be included in the document until after the issue is resolved. Also per Dave’s proposal (Jun 26, 2003) on the email list Handoffs to other technologies do not belong in the requirements document.
%%%%%%%%%%
Section 4.11: OTA (Over the air) support including programming and provisioning of end user devices
Proposal: Delete this section.
Reason: We cannot identify any the requirements imposed on the MAC/PHY for over the air download? This is not a MAC/PHY issue.
%%%%%%%%%%
Section 4.12: Billing to support accounting records
Page 16, Line 1
Proposal: Delete this section.
Reason; We cannot identify the requirements imposed on the MAC/PHY for billing of end users?This is not a MAC/PHY issue.
%%%%%%%%%%
Section 4.14 Regulatory Support
Page 16, Line: 4-6
"The standard shall be consistent with regional regulatory requirements such as those described in Part 15, Part 22, and Part 24 of the FCC Rules."
Proposal: Replace with the following text:
The standard shall be consistent with the national regulatory requirements typically adopted for mobile MAN networks, for example those described in Part 22 of the FCC Rules.
Reason: It is not possible to be consistent with all these at the same time. Additionally, these are US regulatory requirements, and the standard is to be develop for use in the global market.
%%%%%%%%%%
Section 4.15 Security
Pages 16-17, line 7 (p16) – 20 (p20)
"Network security in MBWA systems is assumed to have goals similar to those in cellular or PCS systems. These goals are to protect the service provider from theft of service, and to protect the user’s privacy and mitigate against denial of service attacks. Security for these systems is generally broken into Access control, privacy methods, billing and authorization. Provision shall be made for authentication of both base station and mobile terminal, for privacy, and for data integrity consistent with the best current commercial practice."
Proposal: Delete the sentence "Security for these systems is generally broken into Access control, privacy methods, billing and authorization".
Reason: Billing is not a security issue and the rest of the sentence is redundant with the rest of the paragraph
Insert: "802.20 security is expected to be a partial solution complemented by
end-to-end solutions at higher protocol layers such as EAP, TLS, SSL, IPSec, etc."
Reason: Self evident.
%%%%%%%%%%
Section 4.15.3 Billing Consideration
"The system will prevent the unauthorized disclosure of the user identity."
Proposal: Change section title to "User Privacy"
%%%%%%%%%%
Section 4.15.5 Key Management
Proposal: Delete section.
Reason: This section details an implementation specific approaches.
%%%%%%%%%%
Section 4.15.6 Security Algorithm
Page 17
Line 19-20:
"The cryptographic strength of the authentication algorithm shall be independent of the cryptographic strength of the encryption algorithm."
Proposal: Delete.
Reason: This is an implementation specific item.
%%%%%%%%%%
Section 4.16
Page 17
"OA&M"
Proposal: Delete text or list the OA&M features that require AI support and how.
Reason: With the current text, it is ambiguous what is required on the AI. We do not believe that OA&M functions impose an intrinsic requirement on the AI. OA&M functions can be supported at one or more layers above the MAC/PHY, which provides the benefit of allowing those functions to evolve over time without impacting the AI.
%%%%
Section 4.19: Signaling Requirements
Page 18, Line 5-11
"A signaling system for MBWA is key to providing services over the system and tying these services into currently existing 2.5G and 3G infrastructures. This section presents requirements for signaling channels, latencies and other items of interest. "
Proposal: Delete or clarify what precisely is be being proposed. In either case, this topic is included in the list of open issues for the 802.20 working group.
Reason: This section is quite confusing and should be clarified. Additionally, there are a variety of 2.5G/3G infrastructures and they meet different signaling requirements. So, it would be impossible for 802.20 to meet this requirement in a generic way.
%%%%%%%%%%
Section 4.20:
Page 18, Line 17-18
"Handoffs to and from 3G technologies are assumed to be important in this context as well, since MBWA is being designed to co-exist with current 3G systems."
Proposal: Delete this sentence.
Reason: Coexistence with 3G has no relevance to handoff and in any case MBWA is not targeted as an coexisting extension of 3G"
%%%%%%%%%%
Section 4.20.3: IP Level Handoff
Page 18, Line 26-27:
"Regardless of the lower layer handoff types required, it is expected that a higher level handoff utilizing a mechanism such as Mobile IP will be required for MBWA systems. "
Proposal: Delete this sentence.
Reason: We should be network agnostic as possible and therefore not require specific higher-level handoff requirements.
%%%%%%%%%%
Section 5: Functional Requirements
Pages 19 & 20:
General Comment: This section seems appropriate for specifying a particular implementation and contains text that is not appropriate for a requirements document. We believe that this overall section should be substantially limited from its current scope.
%%%%%%%%%%
Section 5.1.1 Duplexing FDD & TDD
"The 802.20 standard shall support both Frequency Division Duplex (FDD) and Time Division Duplex (TDD) frequency arrangements. The MAC and PHY shall exhibit minimal differences between use in the two duplexing cases, with maximum commonality in terms of modulation and coding and in the control messages. "
Proposal: Delete the second sentence.
Reason: There have been several contributions from multiple contributors arguing that in order to achieve an optimized system to meet the performance required by the PAR, the MAC and PHY layers must be jointly optimized.
%%%%%%%%%%
5.1.9 Mobility and PHY
Page 19, Line 22
"The AI shall support various vehicular mobility classes up to 250 km/hr (as defined in ITU-R 21 M.1034-1)"
Proposal: Delete this section.
Reason: The document already establishes mobility requirements in section 4.9.
%%%%%%%%%%
Section 5.1.10
"Space-Time Processing hooks Support & Multiple Antenna Capabilities"
Proposal: Change to Hooks and Support for Multiple Antenna Capabilities.
Reason: The requirements doc should not be specifying coding methods.
%%%%%%%%%%
Section 5.2.1: "MAC Modes of OperationZZZZ
Proposal: Suggest deleting this section and its subsections.
Reason: The requirements doc should specify what needs to be accomplished, not how we are to accomplish them. As a couple of contributions have pointed out, the detailed mechanisms in use by the MAC are heavily dependent on the PHY layer. We should therefore not be specifying modes of operation.
%%%%%%%%%%
Section 5.2.3
Page 20, Line 10-15
"Many emerging service concepts such as multimedia applications, video on demand, and others require that data transmission and delivery performance be bounded to provide a good user experience. To achieve this, there are many efforts in progress to define a Quality of Service "framework" and from that framework to define requirements to assure that such services can be offered. This section is meant to capture relevant QoS work, and to derive appropriate requirements for the 802.20 technology."
Proposal: Delete this text:
Reason: These are instructions to the reader and not requirements on the AI.
%%%%%%%%%%
Section 5.2.12 Mobility and the MAC
Page 21. Line 12-14
"As listed in the PAR, the 802.20 specification should provide robust communications under vehicular mobility conditions up to 250 Km/hr. This section seeks to parameterize this requirement and to derive MAC layer requirements to meet the goal of a robust air interface in these mobility conditions"
Proposal: Delete this section.
Reason: Contradicts text in section 4.9 and provides no additional information or requirements.
%%%%%%%%%%
Section 5.3.1
Page 21,
"OA&M"
Proposal: Delete text or list the OA&M features that require AI support and how.
Reason: With the current text, it is ambiguous what is required on the AI. We do not believe that OA&M functions impose an intrinsic requirement on the AI. OA&M functions can be supported at one or more layers above the MAC/PHY, which provides the benefit of allowing those functions to evolve over time without impacting the AI.
%%%%%%%
Section 5.5.1 RF Channelization
Page 22, Lines 2-4
Page 22, Line 2-4
"The 802.20 RF channel characteristics should be compatible with existing mobile wireless systems (e.g., support band classes, include guard bands, address interference constraints for coexistence with neighboring radio systems)."
Proposal: Delete this section.
Reason: Compatibility has to be clearly defined since this could be read to mean that 802.20 must share the same PHY as existing mobile systems.Additionally, the phrase "constraints for coexistence with neighboring radio systems" cannot be address until after the AI id defined and after the specific neighboring system is identified.This issue is an open issue in the appendix.
%%%%%%%%%%
Section 5.5.2 Hybrid ARQ
Page 22, Lines 7-9
"The system should support incremental redundancy (IR) based soft combining of the physical layer retransmissions. The (re)transmissions of the same information block can use different modulation and coding"
Proposal: Delete this section.
Reason: This is an implementation detail. The design choice might be made based on performance requirements.
%%%%%%%%%%
Section 5.7
Line 17
"The system should have a one -way target latency of 50 msecs from the base station to the end device"
Proposal: Insert: "when the system is under load"
Reason: Target latency should be simply achieved for low situations.
Appendix A
Page 25, Line 27
"table" needs to reference the table in section 1
----- End forwarded message -----