1 / 11

Proposal to Enhance Legacy Support in IEEE C802.16m-08/118r1

This proposal addresses concerns related to legacy support in the Baseline Frame Structure contribution C802.16m-08/118r1. It highlights issues with Proposal 1 and Proposal 2 of Section 11.4.2 specifically, focusing on switching points and fast feedback support. The need for flexibility in switching points and enabling fast feedback for 16m terminals are emphasized to optimize performance. Proposal 2 aims to improve clarity and support for legacy frames within the 802.16m frame structure.

agallagher
Download Presentation

Proposal to Enhance Legacy Support in IEEE C802.16m-08/118r1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Introduction • This contribution raises some concerns we have with respect to the Baseline Frame Structure contribution C802.16m-08/118r1. • In particular, we focus on section 11.4.2 (proposal 1 and proposal 2) which concerns legacy support when both legacy and .16m are operating on the same RF carrier with same channel bandwidth. • We highlight some key issues that must be captured within the particular proposals in order for TGm discussions to move forward.

  2. Issues with section 11.4.2 – Proposal 1

  3. Switching Points • This proposal explicitly states; There shall be only two switching points in each TDD radio frame when supporting legacy systems. • We feel that this sentence unnecessarily constrains the performance of 16m and therefore should be removed or modified to; In the case of coexistence with legacy systems, two switching points may be selected in each TDD radio frame. • Rational; • It automatically disables the “fast feedback structure” for .16m terminals when supporting legacy systems • feedback every 2.5ms • The matter of co-existence is deployment dependent • if there is no coexistence problem with legacy then >2SPs should be supported • When using >2SP supporting legacy terminals, the neighbour systems can be organised without causing mutual interference. (eg: by aligning the SPs)

  4. Switching Points • The number of switching points should not be limited to two • There seems to be strong interest from row 21 of the consolidated spreadsheet, in that, >2SPs may be introduced even when supporting legacy • We understand the coexistence issues and the interference issues >2SPs may cause. However, it can be resolved, for example: • Allow only 2 SPs when coexisting with legacy systems (but only in the coexistence scenario) • Partially puncture the legacy system (not preferable)

  5. Fast Feedback • We need to be able to support fast feedback for .16m terminals as well as supporting legacy terminals when both are operating on the same RF carrier. • It is clear from the proposals submitted to session #53, that fast feedback should be enabled when legacy support is not required as there can be clear benefits such as; • Increased support for high mobility users • Increased efficiency for closed loop feedback schemes • Increased frequency of ACK/NACK feedback (reducing H-ARQ latency) • Reduced frame alignment required • However, when legacy support is enabled, do we want to unnecessarily take this feature (fast feedback) away from the 16m terminals?

  6. Issues with section 11.4.2 – Proposal 2

  7. Clarification • The above Figure is not clear and does not complement the text. Some concerns regarding the above are; • What is the purpose of the 16m Sub-frame that follows the 16m DL-subframe, (highlighted in blue)? • Can it be allocated either DL or UL? • If it is allocated UL then this proposal barely differs from Proposal-1 • Is the 16m Zone (highlighted in pink) restricted to two subframes? If so, what is the rational behind this?

  8. Summary • We need to be able to support fast feedback for .16m terminals as well as supporting legacy terminals when both are operating on the same RF carrier. • We should not constrain 16m performance when there is no coexistence issues • Figure and text of proposal 2 is not very clear. Proposed text shown on next slide. • The number of SPs should be configurable by the Operators to meet the requirements, traffic and spectrum allocations. • We should not unnecessarily compromise the 16m performance to satisfy legacy support, therefore, fast feedback must be enabled for 16m MSs when supporting legacy.

  9. Proposed Text Insert the following text into Frame Structure sub-clause (IEEE C802.16m-08/118r1): --------------------------------------------- Text Start --------------------------------------------------- 11.4.2Frame Structure Supporting Legacy Frames (proposal-2) When legacy support is enabled, the legacy frames and the 802.16m frames are offset by a fixed integer number of mini-frames to allow accommodate of new designs for 802.16m such as system synchronization signal. As shown in Figure 11.4-3 (proposal-2), the 802.16m frame structure supports the legacy frames by having the legacy portion and the 802.16m portion sharing the 802.16m air link in a time-division manner. Such a legacy frame support scheme is applied to TDD, FDD, and H-FDD duplexing schemes, although Figure 11.4-3 (proposal-2) illustrates the scheme in TDD. It can be noted from Figure 11.4-3, within a 802.16m radio frame, the first subframe shall be assigned to DL as this may contain a synchronisation signal. The subsequent subframe(s) within the 802.16m radio frame could be individually allocated either DL or UL. It should also be noted that, it shall be possible to introduce more than 2 switching points when supporting legacy systems.

  10. Figure 11.4-3: Frame Structure Supporting Legacy Frames (TDD)  proposal-2 ----------------------------------------------- Text End ---------------------------------------------------

More Related