Optimizing System Spectral Efficiency in IEEE C802.20 Standard

1. IEEE C802.20-04/33

2. IEEE C802.20-04/33

3. 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: [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.

4. 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.

5. 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.

6. 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

7. 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. Table 4‑1 ]

8. 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.

9. Section 4.1.5 Aggregate Rates OPTION 2: [The aggregate data rate for downlink and uplink shall be consistent with the spectral efficiency.]

10. 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

11. 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.

12. 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 part been used to justify peak data rates in option 1, namely:

13. 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

14. 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.

15. 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.

16. 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.”] I recommend against any options that set specific 4.1.7 Latency and Packet Data Rates ----------------------------------- 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. While no absolute meaningful latency and packet data rates can be set as any specific +numbers would be arbitrary and would only restrict possible service definitions in +specific deployments, current work in progress within the IETF ( RFC Configuration +Guidelines for DiffServ Service Classes, draft-baker-diffserv-basic-classes-02, expires +August 2004) defines a framework for packet data rates and delay relative to DiffServ +Classes. Thus, the following traffic classes shall be supported: 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. ----------------------------------------------------------- Traffic classes shall be marked as follows: ------------------------------------------------------------------ | Service | DSCP | DSCP | Application | | Class name | name | value | Examples | |===============+=========+=============+==========================| | Conversational| EF,CS5 |101010,101000| IP Telephony | |---------------+---------+-------------+--------------------------| | |AF31,AF32|011010,011100|Broadcast TV, Pay per view| | Streaming |AF33, CS4|011110,100000|Video surveillance | |---------------+---------+-------------+--------------------------| | Interactive |AF21,AF22|010010,010100|Client/server transactions| | |AF23, CS3|010110,011000|peer-to-peer signaling | |---------------+---------+-------------+--------------------------| | Background | DF,(CS0)| 000000 | Undifferentiated | | | | | applications | |---------------+---------+-------------+--------------------------| DiffServ QoS mechanisms that SHOULD be used are as follows for the supported traffic classes: ------------------------------------------------------------------ | Service | DSCP | Conditioning at | PHB | Queuing| AQM| | Class | | DS Edge | Used | | | |===============+======+===================+=========+========+====| | Conversational|EF,CS5|Police using sr+bs | RFC3246 |Priority| No | |---------------+------+-------------------+---------+--------+----| | | AF31 | Police using sr+bs| | | | | |------+-------------------| | | Yes| | | AF32 | Police sum using | | Rate | per| | Streaming | AF33 | sr+bs | RFC2597 | |DSCP| | |------+-------------------| | |----| | | CS4 |Police using sr+bs | | | No | |---------------+------+-------------------+---------+--------+----| | | AF21 | | | | Yes| | | AF22 | Using srTCM | | | per| | Interactive | AF23 | (RFC 2697) | RFC2597 | Rate |DSCP| | |------+-------------------| | |----| | | CS3 |Police using sr+bs | | | No | |---------------+------+-------------------+---------+--------+----| | Standard | DF | Not applicable | RFC2474 | Rate | Yes| |---------------+------+-------------------+---------+--------+----|

17. 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)

18. 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-baker-diffserv-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. -----------------------------------------------------------

19. 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 I recommend against any options that set specific 4.1.7 Latency and Packet Data Rates ----------------------------------- 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. While no absolute meaningful latency and packet data rates can be set as any specific +numbers would be arbitrary and would only restrict possible service definitions in +specific deployments, current work in progress within the IETF ( RFC Configuration +Guidelines for DiffServ Service Classes, draft-baker-diffserv-basic-classes-02, expires +August 2004) defines a framework for packet data rates and delay relative to DiffServ +Classes. Thus, the following traffic classes shall be supported: 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. ----------------------------------------------------------- Traffic classes shall be marked as follows: ------------------------------------------------------------------ | Service | DSCP | DSCP | Application | | Class name | name | value | Examples | |===============+=========+=============+==========================| | Conversational| EF,CS5 |101010,101000| IP Telephony | |---------------+---------+-------------+--------------------------| | |AF31,AF32|011010,011100|Broadcast TV, Pay per view| | Streaming |AF33, CS4|011110,100000|Video surveillance | |---------------+---------+-------------+--------------------------| | Interactive |AF21,AF22|010010,010100|Client/server transactions| | |AF23, CS3|010110,011000|peer-to-peer signaling | |---------------+---------+-------------+--------------------------| | Background | DF,(CS0)| 000000 | Undifferentiated | | | | | applications | |---------------+---------+-------------+--------------------------| DiffServ QoS mechanisms that SHOULD be used are as follows for the supported traffic classes: ------------------------------------------------------------------ | Service | DSCP | Conditioning at | PHB | Queuing| AQM| | Class | | DS Edge | Used | | | |===============+======+===================+=========+========+====| | Conversational|EF,CS5|Police using sr+bs | RFC3246 |Priority| No | |---------------+------+-------------------+---------+--------+----| | | AF31 | Police using sr+bs| | | | | |------+-------------------| | | Yes| | | AF32 | Police sum using | | Rate | per| | Streaming | AF33 | sr+bs | RFC2597 | |DSCP| | |------+-------------------| | |----| | | CS4 |Police using sr+bs | | | No | |---------------+------+-------------------+---------+--------+----| | | AF21 | | | | Yes| | | AF22 | Using srTCM | | | per| | Interactive | AF23 | (RFC 2697) | RFC2597 | Rate |DSCP| | |------+-------------------| | |----| | | CS3 |Police using sr+bs | | | No | |---------------+------+-------------------+---------+--------+----| | Standard | DF | Not applicable | RFC2474 | Rate | Yes| |---------------+------+-------------------+---------+--------+----|

20. 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.

21. 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, andwell defined.

22. 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

23. 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.

24. 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. ]