IEEE C802.16m-07/215r1
Project
IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16>
Title
IEEE 802.16m TDD frame structure with legacy support
Date
Submitted
2008-01-16
Source(s)
Zexian Li
Nokia
zexian.li@nokia.com
Xin Qi, Shashikant Maheshwari, Adrian
Boariu
xin.qi@nsn.com
shashi.maheshwari@nsn.com
adrian.boariu@nsn.com
Nokia Siemens Networks
Re:
IEEE 802.16m-07/047, “Call for Contributions on Project 802.16m System Description
Document (SDD)”. Target topic: “Proposed 802.16m Frame Structure with special attention to
legacy support”.
Abstract
Proposal for IEEE 802.16m TDD frame structure with legacy support
Purpose
Discuss and accept the proposal into the baseline SDD document
Notice
Release
Patent
Policy
This document does not represent the agreed views of the IEEE 802.16 Working Group or any of its subgroups. It
represents only the views of the participants listed in the “Source(s)” field above. It is offered as a basis for
discussion. It is not binding on the contributor(s), who reserve(s) the right to add, amend or withdraw material
contained herein.
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.16.
The contributor is familiar with the IEEE-SA Patent Policy and Procedures:
<http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and
<http://standards.ieee.org/guides/opman/sect6.html#6.3>.
Further information is located at <http://standards.ieee.org/board/pat/pat-material.html> and
<http://standards.ieee.org/board/pat>.
IEEE 802.16m TDD frame structure with legacy support
1 Introduction
This contribution proposes flexible and backward compatible frame structures for 802.16m. In the current
16m SRD document [1], Section 5.1 is dedicated to describe the requirements of legacy support where the
legacy WirelessMAN-OFDMA refers to WiMAX Forum Mobile System Profile, Release 1.0 (Revision 1.4.0:
2007-05-02) [2]. Obviously there will be no problem if the legacy BS and 16m BS are operating on different
carrier frequencies; hence in this contribution we consider the scenario where the same BS is used to support
both 16e and 16m MSs with the same carrier frequency. That is to say, the same frame is proposed to
1
IEEE C802.16m-07/215r1
support both 16e and 16m MSs simultaneously. In addition, shorter frame structure is also proposed to
support multiple 16m zones in one frame.
In principle, there are different ways to support the mixture of 16e MSs and 16m MSs, for example, the MSs
can be separated in
1. Time domain;
2. Frequency domain by different subcarriers;
3. Combination of the above schemes.
In order to minimize the complexity, in case it is possible to support both 16m and 16e MSs using the
current 16e frame structure, it is not necessary to change the current frame structure. However, if there are
new features defined in 16m which will break the current 16e frame structure, we have to introduce 16m and
legacy 16e zones within the current TDD frame structure and provide service to both 16m and 16e terminals
by using flexible zone switching schemes defined in 802.16e standard.
As indicated in [1], IEEE 802.16m should provide mechanisms to enable multi-hop relays. Hence, in this
contribution, frame structure example for both BS and RS is included as well.
2 Frame structure
In order to support both 16e MSs and 16m MSs, based on 802.16e TDD frame structure, in the proposed
frame structure, the key points are listed as following:
 Extend current 802.16e frame to have one or more 802.16m zones in both DL and UL subframes.
 Define pointers inside of 802.16e DL-MAP/UL-MAP messages or separate FCH/MAPs for different
16m zones.
o If separate 16m FCH/MAPs are used in 16m zones, 802.16m MAP message can be freely
defined.
 The same ranging codes/slots can be used by both 802.16e and 802.16m terminals or separate
ranging codes/slots can be defined exclusively for 802.16m terminals.
 Multiple 16m zones can be embedded in one frame.
 16m MS can get the location of 16m zones at initial network entry, and directly go to 16m zones in
the following frames.
Different implementation examples are given for the scenarios in which there is one or more 16m zones
embedded in one 16e frame.
The first example is illustrated in Figure 1 in which there is one 16m DL (UL) zone defined in 16e DL (UL)
subframe. One possible way to define the 16m zones according to the current 16e specification is to use
Zone Switch IE in DL-/UL-MAP message. Therefore, the new 16m zone can be indicated by the Zone
Switch IE in the MAP messages. 16e MSs can be excluded from 16m zones and 16m MSs are able to find
out 802.16m related control and user messages in 16m zones. 16m MSs can learn the location of 16m zones
via the pointer or during initial network entry or other ways. Of course, the order of 16m and 16e UL (DL)
zones can be exchanged as well depending on the implementation scenarios.
2
IEEE C802.16m-07/215r1
FCH/MAPs
Preamble
Frame j
DL 16m
DL 16e
DL subframe
UL 16m
UL 16e
UL subframe
Figure 1 Example: one 802.16m UL/DL zone embedded in one 802.16e frame
In order to improve the latency performance, shorter “16m frame” can be introduced as well by introducing
more than one 16m zones in one frame (i.e. 5 ms time period). One example is to have two 16m DL (UL)
zones included in one frame as illustrated in the examples of Figure 2 and. Figure 3.
DL 16m
FCH/MAPs
FCH/MAPs
Preamble
Frame j
DL 16m
DL subframe
UL 16m
UL 16m
UL subframe
Figure 2 Example: two 802.16m DL/UL zones embedded in one frame
There are following options which can be implemented with above frame structure:

FCH/MAPs in front of 2nd 16m Zone is optional. If implemented, it provides opportunity to apply
measurement feedback sooner rather than waiting for whole frame duration. However, it may
introduce some overhead.

HARQ feedback latency can be reduced by sending the ACK/NAK in the same frame. 16m MS will
have one DL (UL) zone period to perform decoding operation. If size of DL and UL zone is not
equal then different MSs will have different time available for decoding operation and it may not be
fair.

16m MS is either configured to read only one MAP or can read both MAPs.

16e MS can be supported by having separate 16e Zone in the Frame.
Figure 3 shows another alternative to introduce multiple “shorter 16m frames”. This alternative provides
additional time for HARQ burst decoding because of having another “shorter 16m frame” in between.
However, it introduces more gaps comparing to the case in Figure 1 and Figure 2 resulting in degraded
efficiency.
3
IEEE C802.16m-07/215r1
UL 16m
DL 16m
FCH/MAPs
UL 16m
DL 16m
FCH/MAPs
Preamble
Frame j
Figure 3 Alternative Example: two 802.16m DL/UL zones embedded in one frame
Figure 4 shows the example in which two 802.16m DL/UL zones embedded in one frame with legacy
support.
UL 16m
16e UL
DL 16m
FCH/MAPs
UL 16m
16e DL
DL 16m
FCH/MAPs
Preamble
Frame j
Figure 4 Alternative Example: two 802.16m DL/UL zones embedded in one frame with legacy support
If more “shorter 16m frames” are introduced in 5 ms frame, then number of symbols available in UL will be
less and will impact the uplink channel performance.
The detail of necessary messages and/or IEs to support the proposed frame structure will be worked out
once high level frame structure is agreed.
2.1 Frame structure with relay support
16m frame structure should enable the support of 16m RS and 16j RS in order to provide services to both
16m and 16e MSs attached to those relays. Support of Relay in the 16m frame structure is described in
Figure 5. A separate zone is configured for communication between BS and RS. Transmissions from RS
and BS to attached MSs are time aligned.
In order to support 16e MSs, 16e zone can be configured within DL/UL 16m zones.
4
IEEE C802.16m-07/215r1
DL 16m
R-FCH/MAPs
FCH/MAPs
BS
Preamble
Frame j
DL Relay
UL 16m
DL subframe
UL Relay
UL subframe
FCH/MAPs
RS
Preamble
Frame j
DL 16m
Relay reception
UL 16m
DL subframe
Relay
transmission
UL subframe
Figure 5: Example 16m Frame structure with Relay Support
3 Legacy support
As shown in SRD [1], IEEE 802.16m shall provide the ability to disable legacy support. In this section we
discuss about how BS can tell MS the BS’s capabilities, i.e., supporting 16e only, 16m only and support
both.
In the current 802.16e standard, “MAC version encoding” is a TLV parameter which specifies the version of
IEEE 802.16 to which the message originator conforms.
Table 1 MAC version encoding [3]
As observed from the table, in the scenarios of PMP, “MAC version encoding” is included in DCD and
RNG-REQ message, which means MS can get the BS version information from DCD and BS can get MS
version information from RNG-REQ. Following the same principle, a new value, e.g. 9 can be defined to
“indicate conformance with IEEE Std 802.16m-xxxx”.
It is a reasonable extension to the current 16e standards and a workable solution as well if the BS supports
both 16e and 16m MSs. However, the problem is that if just relying only on this TLV, the legacy support can
not be disabled according to the rule although in the standard it says “The BS may attempt to communicate
5
IEEE C802.16m-07/215r1
with the SS per the version specified by the SS, or may decline to interoperate with the SS.” But how to
solve the problem is still open and few options are proposed below:
 After receiving the RNG-REQ message with “MAC version” TLV indicates that the MS is a 16e
terminal, 16m BS can response in RNG-RSP “status = abort” to ask MS to go for different frequencies.
The 16m BS needs to allocate some resources for RNG-REQ/RNG-RSP messages and also has to deal
with the contention in the Ranging Region.
 Replace the 16eDL-MAP with 16mDL-MAP – 16m BS continues to use 16e preamble and FCH.
However, 16m BS shall transmit 16mDL-MAP. 16e MS will look for 16e DL-MAP which they will
never receive and therefore switch the channel after “Lost DL-MAP” Timer expiry.

If the need of new preamble is justified, the new preamble can be used to disable legacy support.
4 Summary
This contribution proposes multiple options of frame structure to provide legacy support, support of
“shorter 16m frame” and relay support.
5 Proposed Text Changes for SDD
[Insert the following section in 16m SDD]
11.x Frame structure
Frame structure with legacy support is illustrated in Figure xxx. The frame structure allows one or more
zones to be configured both in DL and UL subframes. Only the first zone of the DL and UL subframes
provide support for legacy MSs. Each zone may have FCH and MAPs at the beginning to allow potential
improvement e.g. fast feedback.
DL 16e/m
FCH/MAPs
FCH/MAPs
Preamble
Frame j
DL 16m
DL subframe
UL 16e/m
UL 16m
UL subframe
Figure xxx: Example of frame structure with legacy support using different zones in DL and UL subframes.
Figure yyy shows an example of a frame structure that supports multiple switching transmit/reception points
within the frame duration in order to support high mobility MSs. Between two consecutive switching points,
multiple zones may be configured.
6
IEEE C802.16m-07/215r1
DL 16e/m
FCH/MAPs
FCH/MAPs
Preamble
Frame j
UL 16m
DL 16m
UL 16e/m
Figure yyy: Another example of frame structure that supports alternate DL/UL subframes
11.x.1 Frame structure with relay support
Support of Relay in the 16m frame structure is described in Figure zzz. A separate zone is configured for
communication between BS and RS. Transmissions from RS and BS to attached MSs are time aligned.
DL 16e/m
R-FCH/MAPs
FCH/MAPs
BS
Preamble
Frame j
DL Relay
DL subframe
UL 16e/m
UL Relay
UL subframe
FCH/MAPs
RS
Preamble
Frame j
DL 16e/m
Relay reception
DL subframe
UL 16e/m
Relay
transmission
UL subframe
Figure zzz: Example of frame structure with relay support
------------------------------------------------------------------------------------------------------------------------------------
6 Reference:
[1] IEEE 802.16m System Requirements, 80216m-07_002r4.pdf.
[2] WiMAX Forum™ Mobile System Profile, Release 1.0 Approved Specification (Revision 1.4.0:19 2007-05-02),
http://www.wimaxforum.org/technology/documents.
[3] DRAFT Standard for Local and metropolitan area networks, Part 16: Air Interface or Broadband Wireless Access
Systems, P802.16Rev2/D2 (December 2007).
7