IEEE C 802 20 03110 Project IEEE 802

  • Slides: 31
Download presentation
IEEE C 802. 20 -03/110 Project IEEE 802. 20 Working Group on Mobile Broadband

IEEE C 802. 20 -03/110 Project IEEE 802. 20 Working Group on Mobile Broadband Wireless Access <http: //grouper. ieee. org/groups/802/20/> Title Detailed Discussion of SRD issues Date Submitted 2003 -11 -11 Source(s) John Humbert 6220 Sprint Parkway, MS KSOPHD 0504 - 5 D 276 Overland Park, KS 66251 Re: System Requirements Document Abstract Detailed discussion of the issues that need to be resolved to get consensus Purpose Detailed issues discussion 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. 20. 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/sect 6. html#6. 3> and in Understanding Patent Issues During IEEE Standards Development <http: //standards. ieee. org/board/pat/guide. html>. Voice: (816) 210 -9611 Fax: (913) 794 -0420 Email: jhumbe [email protected] com

C 802. 20 -03/110 Detailed Discussion of SRD issues John Humbert 11/11/03 -2 -

C 802. 20 -03/110 Detailed Discussion of SRD issues John Humbert 11/11/03 -2 -

SRD Status update C 802. 20 -03/110 • Open issues: – System Architecture, Spectral

SRD Status update C 802. 20 -03/110 • Open issues: – System Architecture, Spectral Efficiency, Block Assignments (formally Channel Bandwidth), Duplexing, Aggregate Data Rates, Number Simultaneous Active users, Latency, FER, Antenna Diversity, Best Server Selection, Qo. S, Performance under mobility & Delay Spread, MAC/PHY Measurements, IP Level HO. 802. 1 Q Tagging, OA&M support, MAC Complexity, Call Blocking, Priority Access (new section), Multicarrier Support (new). -3 -

Support for Different Block Assignments (4. 1. 3) C 802. 20 -03/110 • Questions

Support for Different Block Assignments (4. 1. 3) C 802. 20 -03/110 • Questions as to whether or not a Proposal needs to support all of the block assignments. – According to the Author's the intent was not to specify a specific BW. – -Need to verify language -4 -

Support for Different Block Assignments (4. 1. 3) C 802. 20 -03/110 – The

Support for Different Block Assignments (4. 1. 3) C 802. 20 -03/110 – The AI shall support deployment of 802. 20 systems in the following sized block assignments: FDD Assignments 2 x 1. 25 MHz 2 x 10 MHz 2 x 20 MHz TDD Assignments 2. 5 MHZ 10 MHZ 20 MHz 40 MHz The individual 802. 20 AI proposals may optimize their MAC and PHY designs for specific bandwidth and Duplexing schemes. This section is not intended to specify a particular channel bandwidth. Proposals do not need to fit into all block assignments. -5 -

Sustained Spectral Efficiency(4. 1. 2) C 802. 20 -03/110 • Should there be targets

Sustained Spectral Efficiency(4. 1. 2) C 802. 20 -03/110 • Should there be targets for Higher speeds? • Need to come to consensus on the definition of a Cell. – The current definition has it as one sector in a 3 sector system and then treats an omni antenna as 1 sector. – The other definition combines all sectors • Need to Clarify the definition of System Bandwidth -6 -

Sustained Spectral Efficiency (4. 1. 2) • 4. 1. 2 C 802. 20 -03/110

Sustained Spectral Efficiency (4. 1. 2) • 4. 1. 2 C 802. 20 -03/110 Spectral Efficiency (b/s/Hz/cell) • Sustained spectral efficiency is computed in a loaded multicellular network setting. It is defined as the ratio of the expected aggregate throughput (taking out all PHY/MAC overhead) to all users in an interior cell divided by the system bandwidth. The sustained spectral efficiency calculation shall assume that users are distributed uniformly throughout the network. For the purpose of evaluation, proposals should be limited to at most three sectors to maintain consistency with current deployment practices. The values of the number of sectors and the number of antennas must be clearly disclosed to allow for comparisons between various proposals. Proposed minimum values are – downlink > 2 b/s/Hz/sector @ 3 km/hr – uplink > 1 b/s/Hz/sector @ 3 km/hr -7 -

Sustained Spectral Efficiency (4. 1. 2) C 802. 20 -03/110 • 4. 1. 2

Sustained Spectral Efficiency (4. 1. 2) C 802. 20 -03/110 • 4. 1. 2 • Sustained spectral efficiency is computed in a loaded multi-cellular network setting. It is defined as the ratio of the expected aggregate throughput (taking out all PHY/MAC overhead) to all users in a sector divided by the system bandwidth (the aggregate spectral allocation in use across the entire system). The sustained spectral efficiency calculation shall assume that users are distributed uniformly throughout the network and shall include a specification of the minimum expected data rate/user. A fair comparison of the spectral efficiencies of different air interfaces can best be achieved for a single specified baseline configuration. Spectral Efficiency (b/s/Hz/cell) To facilitate the subsequent evaluation of different proposals for the 802. 20 air interface, the spectral efficiency of the 802. 20 air interface shall be quoted as b/s/Hz/sector for a three sector baseline configuration. Within this subsequent evaluation, proposals may submit respective deployment models over and beyond the base configuration. Consistent with the PAR requirement that is stated on a per cell basis and the definitions shown in Appendix A, the sustained spectral efficiency of the 802. 20 air interface shall be greater than 1 -8 b/s/Hz/sector.

TDD & FDD (4. 1. 4) C 802. 20 -03/110 • Do proposals need

TDD & FDD (4. 1. 4) C 802. 20 -03/110 • Do proposals need to one or both forms of Duplexing? • Neither the PAR, nor the 802. 20 SRD (rev 8 c) provide an explicit requirement that technology proposals support both FDD and TDD modes. Thus, • It is reasonable to assume, that this is not a requirement. i. e. , proposals may support either (FDD/TDD) or both. -- if this is the consensus requirement, it should be clearly stated in the SRD. -9 -

TDD & FDD (4. 1. 4) C 802. 20 -03/110 • Current Text –

TDD & FDD (4. 1. 4) C 802. 20 -03/110 • Current Text – The standard shall support both Frequency Division Duplexing (FDD) and Time Division Duplexing (TDD). -An AI proposal may support either a Frequency Division Duplexing or Time Division Duplexing or both. -10 -

Aggregate Data Rates (4. 1. 6) C 802. 20 -03/110 • IS there a

Aggregate Data Rates (4. 1. 6) C 802. 20 -03/110 • IS there a need to maintain same UL/DL ratio between peak and aggregate data rates? • Need to ensure the values in this section are consistent with the PAR and other sections of the SRD. • Aggregate data rates depend on the overall combination of coverage and aggregate capacity and system deployment. -11 -

Aggregate Data Rates (4. 1. 6) C 802. 20 -03/110 • The aggregate data

Aggregate Data Rates (4. 1. 6) C 802. 20 -03/110 • The aggregate data rate for downlink and uplink shall be consistent with the spectral efficiency. An example of a 5 MHz FDD channel is shown in Table 1 below. Description Outdoor to Indoor Expected Aggregate Data Rate Downlink Uplink > 10 Mbps/Sector > 5 Mbps/Sector -12 -

C 802. 20 -03/110 Number of Simultaneous Active users (4. 1. 7) • MAC

C 802. 20 -03/110 Number of Simultaneous Active users (4. 1. 7) • MAC has two types of traffic. – One that is time critical (Voice/streaming) and one that can accept delays (data). So are we saying > 100 voice or > 100 of some combination. If it is some combination, we need to specify what the ratio is. -13 -

C 802. 20 -03/110 Number of Simultaneous Active users (4. 1. 7) • Current

C 802. 20 -03/110 Number of Simultaneous Active users (4. 1. 7) • Current Text – The system [MAC] should support > 100 simultaneous active users per [? ? Mhz/sector] of [channel bw/sector. An active user is a terminal that is registered with a cell and is using or seeking to use air link resources to receive and/or transmit data within a short time interval (e. g. , within 50 or 100 ms). -14 -

C 802. 20 -03/110 Latency-ARQ Loop Delay (4. 1. 9) • Is 10 ms

C 802. 20 -03/110 Latency-ARQ Loop Delay (4. 1. 9) • Is 10 ms the right value? – If ACK/NACK information is transferred in a physical frame. Limiting the delay within 10 ms results in limiting the size of a physical frame to less than 2. 5 ms. – This requirement will highly restrict physical design of MBWA. – The size of a physical frame should be determined considering not only delay factor but also many other factors. – Section needs to be modified based on Anna’s input. -15 -

C 802. 20 -03/110 Latency-ARQ Loop Delay (4. 1. 9) • The AI shall

C 802. 20 -03/110 Latency-ARQ Loop Delay (4. 1. 9) • The AI shall minimize the round-trip times (RTT) and the variation in RTT for acknowledgements, within a given Qo. S traffic class. The RTT over the airlink for a MAC data frame is defined here to be the duration from when a data frame is received by the physical layer of the transmitter to the time when an acknowledgment for that frame is received by the transmitting station. The airlink MAC frame RTT, which can also be called the “ARQ loop delay, ” shall be less than 10 ms. Fast acknowledgment of data frames allows for retransmissions to occur quickly, reducing the adverse impact of retransmissions on IP packet throughput. This particularly improves the performance of gaming, financial, and other real-time low latency transactions. -16 -

Performance under mobility & C 802. 20 -03/110 Delay Spread (4. 2. 3) •

Performance under mobility & C 802. 20 -03/110 Delay Spread (4. 2. 3) • During the meeting in Singapore, Jin-Weon Chang has presented a contribution (C 802. 20 -03/77, jointly by DS Park & Joseph Cleveland) on the delay spread profiles for mobile channels. In some of the channel models that were specified by ITU, 3 GPP or COST 259, the delay spread can be larger than 10 microseconds. Thus, it may be too limited if the future 802. 20 system can only work in channel environments that have delay spreads of 5 microseconds or less. • The suggestion was to have a high-level requirement that would ensure the system could perform satisfactorily in the mobile channel environments, with a high enough probability, without mentioning any parameter related to the channel models. • Specifying the link reliability by itself is difficult because it naturally depends on the channels models employed and we are not specifying these in the requirements document. -17 -

Performance under mobility & C 802. 20 -03/110 Delay Spread (4. 2. 3) •

Performance under mobility & C 802. 20 -03/110 Delay Spread (4. 2. 3) • Current text: – "The system should support a delay spread of at least 5 micro-seconds. " • Proposed Text – "The system should support a delay spread contained within the 802. 20 channel models. – The system should support a delay spread of at least 5 micro-seconds. The upper limit for comparing the degradation caused by delay spread is bounded by the channel models selected for 802. 20. – "The system should support a delay spread of at least 5 micro-seconds with 100% link Reliability. “ – "The system shall support a delay spread of at least 5 micro-seconds. " -18 -

Antenna Diversity (4. 1. 11) C 802. 20 -03/110 • Is this section a

Antenna Diversity (4. 1. 11) C 802. 20 -03/110 • Is this section a duplication of section 4. 1. 10? • The antenna number of Mobile Terminal should not be defined in the requirements Document. • Need for the AI to support diversity -19 -

Antenna Diversity (4. 1. 11) C 802. 20 -03/110 • 4. 1. 10 Support

Antenna Diversity (4. 1. 11) C 802. 20 -03/110 • 4. 1. 10 Support for Multi Antenna Capabilities (Closed) – Interconnectivity at the PHY/MAC will be provided at the Base Station and/or the Mobile Terminal for advanced multi antenna technologies to achieve higher effective data rates, user capacity, cell sizes and reliability. As an example, MIMO. • 4. 1. 11 Antenna Diversity – Latest Proposal • At a minimum, the Air Interface shall provide support for receive diversity. – Option 1 • At a minimum, both the Base Station and the Mobile Terminal shall provide two element diversity. Diversity may be an integral part of an advanced antenna solution. – Option 2 • Delete Section – Duplicates requirements in Section 4. 1. 0 – Option 3 • The Base Station shall provide antenna diversity. Diversity may be an integral part of an advanced antenna solution. Antenna diversity shall not be a requirement of the mobile station. – Option 4 • The base station shall provide support for multiple antenna processing -20 -

802. 1 Q Tagging (4. 5. 2) C 802. 20 -03/110 • Specifies a

802. 1 Q Tagging (4. 5. 2) C 802. 20 -03/110 • Specifies a particular architecture • Next generation broadband wireless networks need to support partnered networks and consumer based retail mass market purchase and enabling on line network service provisioning models. -21 -

802. 1 Q Tagging (4. 5. 2) C 802. 20 -03/110 • Most recent

802. 1 Q Tagging (4. 5. 2) C 802. 20 -03/110 • Most recent Proposal – 802. 1 Q tagging must be supported by the system (such that network egress traffic can be switched by a L 2 device to the appropriate L 2 termination device for managing backbone traffic authentication vlans and or captive portal redirection to enable purchase and provision retail models or distinguish traffic for wholesale partners in a wholesale environment). -22 -

Priority Access (New) C 802. 20 -03/110 • Should this be part of QOS

Priority Access (New) C 802. 20 -03/110 • Should this be part of QOS functionality? • Is this a requirement for 802. 20? • Needed for Emergency situations -23 -

Priority Access (New) C 802. 20 -03/110 • Most Recent Proposal – The Air

Priority Access (New) C 802. 20 -03/110 • Most Recent Proposal – The Air Interface shall provide priority access to authorized Mobile Terminals. -24 -

IP level HO (4. 5. 1. 1) C 802. 20 -03/110 • Further discussion

IP level HO (4. 5. 1. 1) C 802. 20 -03/110 • Further discussion required – Contribution C 802. 20 -03/95 – Other HO proposals • Intra – 802. 20 • Between Technology -25 -

IP level HO (4. 5. 1. 1) C 802. 20 -03/110 • Current Proposal

IP level HO (4. 5. 1. 1) C 802. 20 -03/110 • Current Proposal – "802. 20 shall support L 2 to L 3 communication of helpful hints that can facilitate faster handoff performance and other potential benefits based on the use of such hints" • Option 1 • [Delete requirement] • Option 2 – [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 Mobile. IP or of Simple. IP 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 one terminal may also be supported. ] -26 -

Mac Complexity Measures (4. 5. 5) C 802. 20 -03/110 • Should this be

Mac Complexity Measures (4. 5. 5) C 802. 20 -03/110 • Should this be a requirement? – MAC complexity measures should not be addressed by this requirements document. Our driving goal must 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 -27 -

Mac Complexity Measures (4. 5. 5) C 802. 20 -03/110 • Option 1 –

Mac Complexity Measures (4. 5. 5) C 802. 20 -03/110 • Option 1 – Delete Section • Option 2 – 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. -28 -

System Architecture (Section 3. 1) C 802. 20 -03/110 • Associated Issues – The

System Architecture (Section 3. 1) C 802. 20 -03/110 • Associated Issues – The current text limits architectures to Point-to-multipoint. – Need to allow other network topologies like mash or a hybrid of Mesh and P-MP. – Also language was proposed to require support for Micro and Pico cells. -29 -

System Architecture(3. 1) C 802. 20 -03/110 • Most Recent Proposal – The 802.

System Architecture(3. 1) C 802. 20 -03/110 • Most Recent Proposal – The 802. 20 systems must be designed to provide ubiquitous mobile broadband wireless access in a cellular architecture. The system architecture must be one of the following architectures: 1) Point to multipoint topology 2) Mesh network topology 3) Hybrid of both mesh and point to multipoint. The 802. 20 system must support non-line of sight outdoor to indoor scenarios. The system must be designed to enable a cellular architecture (macro/micro/Pico cells) with allowance for indoor penetration. -30 -

Other Open Sections C 802. 20 -03/110 • These sections are currently open, however

Other Open Sections C 802. 20 -03/110 • These sections are currently open, however there has been little, if any, activity within the CG. – Multi-carrier Support – Call Blocking • This will likely be removed as a requirement – Mac/PHY Measurements – Duplexing – OA&M Support – QOS (Sections 4. 1. 14 & 4. 4. 1) – FER – Best Server Selection -31 -