IEEE C802.20-04/33
Project
IEEE 802 Executive Committee Study Group on Mobile Broadband Wireless Access
<http://ieee802.org/20>
Title
Comments of Alternatives in the Requirements Document
Date Submitted
2004-03-01
Source(s)
Mike Youssefmir
ArrayComm Inc
2480 N. First Street, Suite 200
San Jose, CA 95131-1014
Voice: N/A
Fax: +1 408-428-9083
Email: mike@arraycomm.com
Joanne Wilson
ArrayComm Inc
2480 N. First Street, Suite 200
San Jose, CA 95131-1014
Voice: +1 202 669-4006
Fax: +1 253 484 –0330
Email: joanne@arraycomm.com
Todd Chauvin
ArrayComm Inc
2480 N. First Street, Suite 200
San Jose, CA 95131-1014
Voice: N/A
Fax: 1 408-428-9083
Email: joanne@arraycomm.com
IEEE C802.20-04/33
Re:
802.20 WG Call for Contributions
Abstract
This document provides summary of delay profiles that major international standard organizations suggested.
Purpose
Contribute to the discussion and development of the 802.20 Requirements and Channel Model.
Notice
This document has been prepared to assist the IEEE 802.20 Working Group. It is offered as a basis for discussion and is not binding
on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after
further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release
The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any
modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards
publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce
in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution
may be made public by IEEE 802 MBWA ECSG.
Patent Policy
The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual
<http://standards.ieee.org/guides/opman/sect6.html#6.3> and in Understanding Patent Issues During IEEE Standards Development
<http://standards.ieee.org/board/pat/guide.html>.
Section 4.1.1 System Spectral Efficiency (bps/Hz/sector)
Option 1: The system spectral efficiency of the 802.20 air interface shall be quoted for the case
of a three sector baseline configuration[1]. It shall be computed in a loaded multi-cellular
network setting, which shall be simulated based on the methodology established by the
802.20 evaluation criteria group. It shall consider among other factors a minimum expected
data rate/user and/or other fairness criteria, and percentage of throughput due to duplicated
information flow. The values shall be quoted on a b/s/Hz/sector basis. The system spectral
efficiency of the 802.20 air interface shall be greater than:
Bandwidth
1.25 MHz
Parameter
Spectral
Efficiency
(b/s/Hz/sector)
Down Link
Up Link
Ø1
Ø2
Ø1
1.2
2.4
0.6
5 MHz
Down Link
Up Link
Ø2
Ø1
Ø2
Ø1
Ø2
1.2
1.2
2.4
0.6
1.2
[1]Since the base configuration is only required for the purpose of comparing system spectral
efficiency, proposals may submit deployment models over and beyond the base
configuration.
Section 4.1.1 System Spectral Efficiency (bps/Hz/sector)
Comments on Option 1
• Designates spectral efficiency requirements based on bandwidths
which are not specifically defined in the requirements
• 1.2 bits/sec/Hz downlink and 0.6 bits/sec/Hz uplink
– Assuming symmetrical FDD or TDD with 50% duty cycle, implies 0.9
bits/sec/Hz, which is inconsistent with 802.20 PAR that requires > 1
bit/sec/Hz/sector (or cell)
• Assumes concept of two phases
– The PAR does not specify phases
– There’s no basis for requiring a multi-phase project that introduces additional
complexities and the potential for interoperability problems.
Section 4.1.1 System Spectral Efficiency (bps/Hz/sector)
Option 2: The system spectral efficiency of the 802.20 air interface shall be quoted for the case
of a three sector baseline configuration[1]. It shall be computed in a loaded multi-cellular
network setting, which shall be simulated based on the methodology established by the
802.20 evaluation criteria group. It shall consider among other factors a minimum expected
data rate/user and/or other fairness criteria, and percentage of throughput due to duplicated
information flow. The values shall be quoted on a b/s/Hz/sector basis. The system spectral
efficiency of the 802.20 air interface shall be greater than X b/s/Hz/sector.
[1]Since the base configuration is only required for the purpose of comparing system spectral
efficiency, proposals may submit deployment models over and beyond the base
configuration.
Section 4.1.1 System Spectral Efficiency (bps/Hz/sector)
Comments on Option 2
•
If Option 2 is chosen with X = 1 bits/sec/Hz/sector
– Simple and straight forward.
– Makes no assumptions about channel bandwidths or size of block assignment
– Makes no assumptions about ratio of uplink to downlink transmission for either FDD or TDD
systems
– Accommodates both symmetrical and asymmetrical FDD and TDD with any duty cycle
– 1 bits/sec/Hz is consistent with our PAR but qualifies it with a per sector restriction
– Proposals can be brought forward and are likely to exceed this bound
•
Can select X somewhat > 1 bit/sec/Hz/sector, but it should be a reasonable number that
allows proposals to make tradeoffs among the various requirements and constraints
 Our recommendation is to select Option 2 with X = 1 bits/sec/Hz/sector
Section 4.1.5 Aggregate Rates
OPTION 1: [
The aggregate data rate for downlink and uplink shall be consistent with the spectral efficiency.
Example Aggregate Data Rates are shown in table 4-1.
Bandwidth
1.25 MHz
Parameter
5 MHz
Down Link
Up Link
Down Link
Up Link
Ø1
Ø1
Ø1
Ø1
Ø2
Ø2
Ø2
Ø2
Aggregate
1.5
3.0
0.75 1.5
6.0
12.0 3.0
6.0
Mbps
Mbps
Mbps
Data
Mbps Mbps Mbps Mbps Mbps
Throughput/se
tor
c
Table 4-1
]
Section 4.1.5 Aggregate Rates
Comments on Option 1
• Since aggregate data rates should be consistent with spectral efficiency, there is no
need for providing example data rates based on (channel?) bandwidths.
• Bandwidths are not specified in the 802.20 requirements
document so that proposals may use whatever best suits the technology
•Assumes concept of two phases
–The PAR does not specify phases
–There’s no basis for requiring a multi-phase project that introduces additional
complexities and the potential for interoperability problems.
Section 4.1.5 Aggregate Rates
OPTION 2: [The aggregate data rate for downlink and uplink shall be consistent with the
spectral efficiency.]
Section 4.1.5 Aggregate Rates
Comments on Option 2
• Simple, straight forward and maintains consistency between two
related requirements
• Makes no assumptions about channel bandwidths or size of block
assignment
• Makes no assumptions about ratio of uplink to downlink
transmission for either FDD or TDD systems
• Accommodates both symmetrical and asymmetrical FDD and TDD
with
any
duty
cycle
 Our recommendation is to select Option 2
4.1.5.1 User Data Rates - Downlink & Uplink
OPTION 1: The AI shall support peak per-user data rates in excess of the values shown in table
4-2. These peak data rate targets are independent of channel conditions, traffic loading, and
system architecture. The peak per user data rate targets are less than the peak aggregate per
cell data rate to allow for design and operational choices. 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.
Bandwidth
1.25 MHz
Parameter
Peak User
Data Rate
Down Link
Up Link
Ø1
Ø2
Ø1
3.0
Mbps
4.5
Mbps
1.5
Mbps
5 MHz
Down Link
Up Link
Ø2
Ø1
Ø2
Ø1
Ø2
2.25
Mbps
12.0
Mbps
18.0
Mbps
6.0
Mbps
9.0
Mbps
4.1.5.1 User Data Rates - Downlink & Uplink
Comments on Option 1
The 802.20 PAR is very specific:
• The scope of the PAR (listed in Item 12) is as follows:
“Specification of physical and medium access control layers of an air interface … with
peak data rates per user in excess of 1 Mbps. It … targets spectral efficiencies, sustained
user data rates and numbers of active users that are all significantly higher than
achieved by existing mobile systems.”
• The PAR neither states nor implies that “target peak data rates (should be) significantly
higher than achieved by existing or future mobile systems”.
• Nevertheless this statement has at least in partBandwidth
been used to justify peak data rates in option
1, namely:
1.25 MHz
5 MHz
Parameter
Peak User
Data Rate
Down Link
Up Link
Ø1
Ø2
Ø1
3.0
Mbps
4.5
Mbps
1.5
Mbps
Down Link
Up Link
Ø2
Ø1
Ø2
Ø1
Ø2
2.25
Mbps
12.0
Mbps
18.0
Mbps
6.0
Mbps
9.0
Mbps
4.1.5.1 User Data Rates - Downlink & Uplink
Comments on Option 1
• Our target spectral efficiencies are > 1bps/Hz range (“phase 1”)
– Implied Aggregate Rates in 1.25Mhz FDD/2.5 MHz TDD: (“1bps/Hz”):
• Downlink: 1.25Mbps, Uplink: 1.25Mbps
• Reasonable number of simultaneously active users: 10
• With 10 simultaneously active users this implies: 125kbps sustained uplink and
downlink
• 3Mbps downlink, 1.5 Mbps uplink
– This is a 24:1 peak to average data rate ratio for the downlink
– This is a 12:1 peak to average data rate ratio for the uplink
– Conclusion: Peak rates will rarely be achievable in practice
– We should therefore not artificially limit proposals to large peak data rates
whose sole purpose is specs-manship and will rarely be seen in practice
• The concept of bandwidth must be clarified given that we are not
requiring specific channel bandwidths
• Finally, the concept of two phases is ill-defined
4.1.5.1 User Data Rates - Downlink & Uplink
OPTION 2: The AI shall support peak per-user data rates in excess of 1 Mbps on the
downlink and in excess of 300 kbps on the uplink. These peak data rate targets are
independent of channel conditions, traffic loading, and system architecture. The peak per
user data rate targets are less than the peak aggregate per cell data rate to allow for design
and operational choices. 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.
Note: Option 2 is the same as Option 1, but without the table.
4.1.5.1 User Data Rates - Downlink & Uplink
Comments on options 2:
• Option 2 is consistent with the PAR.
• Proposals will always have an incentive to promote higher rates that are
achievable because these will lead to higher spectral efficiencies and aggregate
rates which is the clear intention of the PAR and a driving factor behind the
evaluation criteria.
 We recommend the group adopt option 2.
Section 4.1.7 Latency and Packet Error Rate
OPTION 1) [
The system shall support a variety of traffic classes with different latency and packet error
rates performance, in order to meet the end-user QoS requirements for the various
applications, as recommended by ITU [2]. Based on the classification of traffic in
accordance with the QoS architecture as described in Section 4.4.1 [3,4,5,6], appropriate
latency and packet error rate performance targets can be associated with each class.
To support the Expedited Forwarding traffic class, the latency should be as low as possible
while the corresponding packet error rate should be low enough to support real-time
conversational audio/video applications, and near zero for error intolerant, delay sensitive
data
applications
such
as
Telnet,
interactive
games.
For the Best Effort traffic class, the packet error rate performance should comply with the
requirement as stated in IEEE Std. 802 -2001 [7], quoted as follows:
“The probability that a MAC Service Data Unit (MSDU) is not delivered correctly at an
MSAP due to the operation of the Physical layer and the MAC protocol, SHALL be less
than 8 x 10-8 per octet of MSDU length.”]
Section 4.1.7 Latency and Packet Error Rate
Option 2: [Top two paragraphs same as Option 1
For the Best Effort traffic class, it may be useful to consider following two documents:
- IEEE Std. 802 -2001 [Error! Reference source not found.]
- IEEE 802.11-97 (99)
Section 4.1.7 Latency and Packet Error Rate
OPTION 3: [ (since updated on the reflector)
The system shall support a variety of traffic classes with different latency and packet error rate requirements as suggested
in the RFC "Configuration Guidelines for DiffServ Service Classes" http://www.ietf.org/internet-drafts/draft-bakerdiffserv-basic-classes-01.txt.
Class
Attributes of Traffic
----------------------------------------------------------Conversational | Two-way, low delay, low data loss
| rate, sensitive to delay variations.
----------------------------------------------------------Streaming
| Same as conversational, one-way,
| less sensitive to delay. May require
| high bandwidth.
----------------------------------------------------------Interactive | Two-way, bursty, variable
| bandwidth requirements moderate
| delay, moderate data loss rate
| correctable in part.
----------------------------------------------------------Background | Highly tolerant to delay and data
| loss rate has variable bandwidth.
-----------------------------------------------------------
Section 4.1.7 Latency and Packet Error Rate
OPTION 4: [
The system shall support a variety of traffic classes with different latency and packet
error rate requirements as shown in the following table. The classification of traffic
in the table supports the QoS architecture as described in Section XXX
Expedited Forwarding
(EF)
Assured
Best Effort
Forwarding (AF)
(BE)
~ 30 ms (TBR)
~ 30 ms – 10 s (TBR)
>> 10 s (TBR)
3 x 10-2
10-2 – 2.5 x 10-1 (TBR)
2.5 x 10-1 (TBR)
5 x 10-13 (TBR)
5 x 10-13 – 8 x 10-5 (TBR)
8 x 10-5
Traffic classes
Latency
Packet Error Rate for
Error Tolerant
Applications
Packet Error Rate for
Error Intolerant
Applications
Section 4.1.7 Latency and Packet Error Rate
Comments on the options:
•
We already have simple requirements in this area that will meet our needs without
further detail
•
Our PAR specifically says that we are designing a system optimized for IP-data
transport. That means the 802.20 air interface better be able to handle applications over
TCP and UDP that in turn require low error rates and low latency. In addition the current
requirements document requires a MAC layer RTT of <10ms, ensuring the air interface can
support low latency traffic under appropriate RF conditions.
•
We need flexible QoS mechanisms eg. DiffServ, flexible ARQ schemes, etc., that
can be used to create QoS profiles that meet the needs of the applications several
years from now when .20 is first implemented. This is captured in the QoS
requirement.
 We recommend that the group not adopt specific packet error rate and latency
requirements that would be arbitrary and only restrict possible service definitions in
specific deployments.
Section 4.2.3 Performance under
Mobility & Delay Spread
Option 1:
[The system is expected to work in dense urban, suburban and rural outdoor-indoor
environments and the relevant channel models shall be applicable. The system shall NOT be
designed for indoor only and outdoor only scenarios. The system should support a delay
spread of at least 5 micro-seconds. The system should support 95% (TBR) of the channel
models with various delay spread values in each of the above environments.]
OPTION 2:
[The system is expected to work in dense urban, suburban and rural outdoor-indoor
environments and the relevant channel models shall be applicable. The system shall NOT be
designed for indoor only and outdoor only scenarios. The system should support a delay
spread of at least 5 micro-seconds.]
OPTION 3:
[The system shall work in dense urban, suburban, rural outdoor-indoor, pedestrian and vehicular
environments and the relevant channel models shall be applicable. The system shall NOT be
designed for indoor only and outdoor only scenarios.]
 We recommend the group adopt option 3. It is simple, straightforward, and
well defined.
Section 4.5.2 CPE software upgrade
“push”
CPE software upgrade “push” – an operator should have the ability to “push” a
software upgrade to CPE that are currently connected to the network. The packets
that make up the software image should be given a very high priority and should
be coded heavily such that they have a very high chance of arriving error free at
the CPE. The CPE should be capable of holding 2 software loads (the existing
one and a new one) such that an operator can ensure that the “new” software load
has arrived safely at the CPE before deciding to switch from the “old” software load
to the “new” software load.
 Recommend the group delete this section
– This is a feature of the user terminal and backend infrastructure
– It is irrelevant at the MAC/PHY layer
– Need for high priority should be captured within QOS framework
Section 4.5.3 802.1q Tagging
OPTION 1: [DELETE SECTION]
OPTION 2: [
802.1Q tagging must be supported by the system (such that network egress traffic
can be switched by a L2 device to the appropriate L2 termination device for
managing backbone traffic or distinguishing traffic for wholesale partners in a
wholesale environment).]
Comments on Option 2:
– Advocating a specific mechanism for separation of traffic does not allow 802.20 to
maintain a network agnostic approach
– The requirement should be to allow the ability to distinguish and segregate traffic among
multiple services.
– This can be accomplished in many ways allowing use of 802.1q tagging, PPP or MPLS
across the air interface without specifically mandating any particular technology at layer
2
– Eg. 802.16 defines a convergence sublayer when VLAN frames are to be carried over
the air interface without mandating 802.1 q at layer 2
 We recommend to adopt option 1 and delete this section.
Section 4.5.3 802.1q Tagging
Additional options:
New Option 3: [
802.1q tagging, PPP, MPLS or a functionally equivalent upper layer solution must
be +supported by the system. ]
New Options 4: [
The system should include a capability to enable support for multiple higher layer
protocols. Specifically, the air link should be capable of multiplexing/demultiplexing
payloads from different higher layer protocols, where each such protocol may have
a unique formatting of the MAC layer payload. ]