stds-80220-requirements: Comments on Requirements Document Rev 3
Dave et al,
Below please find comments on revision 3 of the requiremnts document.
For completeness I have also attached copies of the proposed figures
for figures 1 & 2.
Mike
Michael Youssefmir
ArrayComm, Inc.
Comments and Changes to Document rev3 from Mike Youssefmir, Joanne Wilson, John Chen, Todd Chauvin, Marc Goldburg, Branislav Meandzija, and Brett Schein:
Section 1.2
"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."
Proposal: Delete "for which the 802.20 PHY and MAC layers shall form the lower protocol layers".
Reason: The scope already states that: "an "802.20 system" constitutes an 802.20 MAC and PHY implementation"
%%%%%%%%%%
NEW: Section 2.1
"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 "as an integral part of any service offering".
Reason: MBWA is a network optimized for the delivery of data services and not a network optimized for the delivery of voice services. Hence, the word "integral" could be misinterpreted. Per the PAR we should focus on optimizing the system for IP data services, which includes Voice over IP. The lesson of 802.11 is an important one in this context. Only after significant market penetration and success for data services has the industry moved towards the support of voice services over 802.11.
%%%%%%%%%%
Section 2.1
" When the required QOS cannot be reserved the system will provide signaling to support call blocking. The MAC should provide call blocking for supported formats."
Proposal: Delete this note.
Reason: Such call blocking or other exception handling 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, the application will request it of the air interface via an API. If the air interface cannot provide the desired QoS, it will 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.
The Requirements document should specify the classes of supported QoS, but application-specific exception handling does not belong in the document.
Instead we have proposed the following language in the QOS section:
"The 802.20 air interface will provide an API to higher layer entities for the purpose of requesting QoS attributes on a per-session basis. The API will also provide a mechanism for the air interface to inform higher layer entities whether a particular QoS request is to be honored. It is the responsibility of higher layer entities to take appropriate action based on such messages."
%%%%%%%%%%
NEW: Section 3.1
"System Context Diagram"
Proposal: Promote to a section sub head.
%%%%%%%%%%%%%%%%
NEW: Section 3.1.1
(This is a repetition of my comment on this section over the email list)
"To aid the discussion in this document and in the 802.20 specifications, a straw man Reference Partitioning of the 802.20 functionality is shown in Figure 1. This reference partitioning model is similar to those used in other 802 groups...."
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. These figures are attached separately.
Reason: This section is currently overly detailed and proposes a specific division of capabilities within the MAC and PHY layers that should be addressed in the specification itself and not in the requirements document. Alan's breakdown and slides are far more instructive in terms of what reference model we should follow.
I have attached Alan's Slides to my email on this subject.
Footnote to the new Figure 1 with: "Source: IEEE Std 802-2001, IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, IEEE Std 802 -2001"
Footnote the new Figure 2 with: "Source: IEEE Standard for Information technology, Telecommunications and information exchange between systems, Local and metropolitan area networks: Specific requirements Part 2: Logical Link Control, ANSI/IEEE Std 802.2, 1998 Edition, .Introduction to ANSI/IEEE Std 802.2, 1998 Edition"
%%%%%%%%%%
NEW Section 3.2
"The AI shall support open interfaces between the base station and any other upstream network entities. Any AI interfaces that may be implemented shall use IETF protocols as appropriate."
Proposal: Delete last sentence and replace with:
"The AI should not mandate specific interfaces elsewhere in the network beyond the link between the base station and terminal and shall otherwise be agnostic to architectures and network entities in the network core."
Reason: With the revision, 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.
%%%%%%%%%%
NEW: Section 4.1
"Consistent with the 802.20 PAR, tables 1 and 2 define the required air interface data rates and capacity characteristics.."
Proposal: Delete Table 1&2 and associated footnotes
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.
%%%%%%%%%%
NEW: Section 4.2
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 surrounding adjacent cells is taken into account when determining the spectral efficiency of the air interface."
Reason: This clarifies the meaning of the interior cell and why it is important to consider only the interior cell. Without this sentence the paragraph may be misinterpreted. We have already seen the question, paraphrasing, "why are we only counting interior cells?" in one of the submissions commenting on a revision of this document.
%%%%%%%%%%
NEW: Section 4.4
"Simultaneous Sessions"
Proposal: Delete
Reason: Requirement is meaningless without, a definition for simultaneous sessions.
%%%%%%%%%%
NEW: Section 4.6 Link Budget
"The system link budget shall be 160-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.
Proposal: Replace: 160-170db with 150db-170db.
Reason: Our original proposal was to change 160db to 150db-170db.
The PAR states that MBWA will be appropriate for wide area coverage. As such we need to at least match the performance of PCS systems and at the same time we cannot depend on large antenna gains at the user terminal for truly mobile PC card type applications. So our proposal was to provide an appropriate range around 160 dB, to take into consideration the variety of factors mentioned in this section. Other approaches can be used to provide some flexibility. We disagree with increasing the link budget requirement because 160 dB is already an extremely aggressive target.
%%%%%%%%%%
NEW: Section 4.8
"The Radio system should provide at least 99.9 link reliability"
Proposal: Delete this sentence.
Reason: Without adding more information to the document it is difficult to put this requirement in the proper context. We are dealing with a wireless system so 99.9% link reliability makes little to no sense when you are out of coverage. In addition, if the intention here is to specify error rates, it is likely the case that the coverage/capacity tradeoff is optimized at in-coverage reliability levels far less than 99.9%. For example, ARQ could accommodate packet error rates of 1-2% with little to no impact on latency and jitter performance.
%%%%%%%%%%
Section 4.11 Security
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.
%%%%%%%%%%
NEW: Section 4.16
"OA&M"
Proposal: Delete section.
Reason: 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.
%%%%
NEW: Section 4.19: Signaling Requirements
Proposal: Delete section.
Reason: There are no AI specific requirements for signaling.
%%%%%%%%%%
NEW: Section 4.20.3: IP Level Handoff
"In order to support high speed mobility in an all IP network Mobile IP will have to be supported at a higher level. Integration of Foreign Agent or proxy Mobile IP into the base station or terminal will be required to support a clientless solution. Multiple IP addresses behind a single terminal should also be supported."
Proposal: Replace 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."
Multiple IP addresses behind a single terminal may also be supported."
Reason
At the May meeting of 802.20 two network architectures consistent with industry standards that do not employ Mobile IP were presented and the argument was accepted that 802.20 shall be network architecture agnostic.
%%%%%%%%%%
NEW: Section 4.21.1 MAC Modes of operation
"4.21.1 MAC Modes of Operation (needs detail or it will be eliminated)
4.21.1.1 Random Access MAC (needs detail or it will be eliminated)
Polled "
Proposal: Delete 4.21.1.1 and "Polled". Insert in 4.2.1, "The 802.20 modes for PHY and MAC will be explicitly tied together in order to jointly optimize the performance of the AI."
Reason: Without a higher-level requirement it is not the place of this document to specify a specific type of MAC or choose between a random access or polled MAC. If we are to achieve our performance goals the requirements should allow flexibility in the type of MAC used. We have seen at least two contributions to the 802.20 working group (C802.20-03-27 and C802.20-03-16) that have talked about the importance of tightly coupled MAC and PHY design to achieve optimal performance. At the very least, the performance of the 802.20 AI should be evaluated as a single MAC/PHY entity
%%%%%%%%%%
Section 4.22 Quality of Service and the MAC
Proposal: Change the Section heading to "Quality of Service (QoS) Support"
Delete subsections 4.22.1 through 4.22.10
Insert the following text for section 4.22:
"The 802.20 air interface shall support standard Internet Differentiated Services (DS) QoS to be compatible with other mobile network standards such as 3GPP2. In particular, 802.20 shall support the standard Expedited Forwarding (EF), Assured Forwarding (AF), and Best Effort (BE) DS Per Hop Behaviors (PHBs) as defined by the RFC 2597 and RFC 2598. 802.20 shall also support configuration of the PHBs by a DS API that shall be based on a subset of the information model defined in RFC 3289.
The 802.20 air interface will provide an API to higher layer entities for the purpose of requesting QoS attributes on a per-session basis. The API will also provide a mechanism for the air interface to inform higher layer entities whether a particular QoS request is to be honored. It is the responsibility of higher layer entities to take appropriate action based on such messages."
Reason:
This provides a standards-based approach to supporting QoS on an 802.20 system, consistent with the approach used by other mobile network standards. No material has been provided for the sections related to MAC. If such material is provided it can be included in a separate section of the document, allowing this section to focus solely on QoS Support.
%%%%%%%%%%
NEW: Section 4.22.9 MAC Complexity Measures
"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."
Proposal: Delete this section
Reason: MAC complexity measures should not be addressed by this requirements document. Our driving goal should 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.
%%%%%%%%%%
Sections 4.22.9, 4.23.1
"4.22.9 Additional IP Offerings (needs detail or it will be eliminated"
"4.23.1 OA&M Support (needs detail or it will be eliminated)"
Proposal: Eliminate as suggested
Reason: No AI requirements have been identified for this section.
%%%%%%%%%%
Reference Model.zip