`(12) Patent Application Publication (10) Pub. No.: US 2009/0067377 A1
`(43) Pub. Date:
`Mar. 12, 2009
`TALUKDAR et al.
`
`US 20090067377A1
`
`(54) MEDIUMACCESS CONTROL FRAME
`STRUCTURE IN WIRELESS
`COMMUNICATION SYSTEM
`
`(75) Inventors:
`
`ANUP K. TALUKDAR, Dekalb,
`IL (US); MARK C. CUDAK,
`ROLLING MEADOWS, IL (US);
`KEVIN L. BAUM, ROLLING
`MEADOWS, IL (US); AMITAVA
`GHOSH, BUFFALO GROVE, IL
`(US); STAVROSTZAVIDAS,
`EVANSTON, IL (US); FAN
`WANG, VERNON HILLS, IL
`(US); HUA XU, LAKEZURICH,
`IL (US); XIANGYANG ZHUANG,
`Lake Zurich, IL (US)
`Correspondence Address:
`MOTOROLANC
`600 NORTH US HIGHWAY 45, W4-39Q
`LIBERTYVILLE, IL 60048-5343 (US)
`
`(73) Assignee:
`
`(21) Appl. No.:
`
`MOTOROLA, INC.,
`LIBERTYVILLE, IL (US)
`12/191,042
`
`(22) Filed:
`
`Aug. 13, 2008
`Related U.S. Application Data
`(60) Provisional application No. 60/956,031, filed on Aug.
`15, 2007.
`
`Publication Classification
`
`(51) Int. Cl.
`(2009.01)
`H047 72/04
`(52) U.S. Cl. ........................................................ 370/329
`
`ABSTRACT
`(57)
`A wireless communication infrastructure entity configured to
`allocate radio resources, in a radio frame, to a wireless termi
`nal compliant with a first protocol and to a wireless terminal
`compliant with a second protocol. The radio frame including
`a first protocol resource region and a second protocol resource
`region. The radio frame including a first protocol allocation
`control message that allocates resources within the first pro
`tocol resource region to the wireless terminal compliant with
`the first protocol, and a second protocol allocation control
`message that allocates resources within the second protocol
`resource region to the wireless terminal compliant with the
`second protocol.
`
`100
`
`f03
`
`REMOTE UNIT
`
`
`
`
`
`BASE UNIT
`
`
`
`REMOTE UNIT
`
`BASE UNIT
`
`Intel Corporation Ex. 1012
`Intel Corp v. UNM Rainforest Innovations - IPR2020-01576
`Page 1 of 25
`
`
`
`Patent Application Publication
`
`Mar. 12, 2009 Sheet 1 of 14
`
`US 2009/0067377 A1
`
`100
`
`103
`
`REMOTE UNIT
`
`
`
`110
`
`REMOTE UNIT
`
`BASE UNIT
`
`
`
`BASE UNIT
`
`FIG. I.
`
`Intel Corporation Ex. 1012
`Intel Corp v. UNM Rainforest Innovations - IPR2020-01576
`Page 2 of 25
`
`
`
`Patent Application Publication
`
`Mar. 12, 2009 Sheet 2 of 14
`
`US 2009/0067377 A1
`
`SeC
`-He
`
`—
`FIG. 2
`
`3 0 4.
`
`306
`
`302
`
`% S
`
`5 m S GC
`FIG. 3
`
`406
`
`Intel Corporation Ex. 1012
`Intel Corp v. UNM Rainforest Innovations - IPR2020-01576
`Page 3 of 25
`
`
`
`Patent Application Publication
`
`
`
`Mar. 12, 2009 Sheet 3 of 14
`
`US 2009/0067377 A1
`
`NØØNNØNNØ N |
`
`ØNNØØNØ, {ØNNØNNØ
`
`N
`
`Ç (5) I H.
`
`Intel Corporation Ex. 1012
`Intel Corp v. UNM Rainforest Innovations - IPR2020-01576
`Page 4 of 25
`
`
`
`Patent Application Publication
`
`Mar. 12, 2009 Sheet 4 of 14
`
`US 2009/0067377 A1
`
`600
`
`5 mSeC
`48 SYMBOLS
`
`12 SYMBOLS
`
`DLUL
`16m
`
`DLUL
`16m
`
`604
`
`612
`
`
`
`12 SYMBOLS
`
`5 mSeC
`48 SYMBOLS
`
`16e-UL
`16m-DLUL
`
`DLUL
`16e 16m
`
`DLUL
`166/16m
`
`706 708
`
`FIG. 7
`
`700
`
`/ 2 1 2 2
`
`Intel Corporation Ex. 1012
`Intel Corp v. UNM Rainforest Innovations - IPR2020-01576
`Page 5 of 25
`
`
`
`Patent Application Publication
`
`Mar. 12, 2009 Sheet 5 of 14
`
`US 2009/0067377 A1
`
`806 808
`
`
`
`
`
`HEM-1 16m
`
`16e/HEM-II
`HEM-III 16m
`
`16e HEM-II
`HEM-III 16m
`
`16e HEM
`HEM-III 16m
`
`/www/w/v/www.
`
`Intel Corporation Ex. 1012
`Intel Corp v. UNM Rainforest Innovations - IPR2020-01576
`Page 6 of 25
`
`
`
`Patent Application Publication
`
`Mar. 12
`
`2009 Sheet 6 of 14
`
`US 2009/0067377 A1
`
`
`
`0 I ’0IH
`
`Intel Corporation Ex. 1012
`Intel Corp v. UNM Rainforest Innovations - IPR2020-01576
`Page 7 of 25
`
`
`
`Patent Application Publication
`
`Mar. 12, 2009 Sheet 7 of 14
`
`US 2009/0067377 A1
`
`
`
`, U EBAVNýlyg) ! ER?TT-ºt ENOZOSn#In
`
`
`
`AWW (OWW
`
`| || OBE(III) ugi
`
`
`
`
`
`S). AOWSO
`
`FTi
`
`L?
`
`ITI
`
`N O z-Tic
`
`NOZLO
`TU
`OWOO
`U U
`IWWST
` ITI > ? UU r ITI -U ZU
`
`
`NO WINOISS WWO WWU9.
`
`WWIITO
`
`ZHWO
`
`Intel Corporation Ex. 1012
`Intel Corp v. UNM Rainforest Innovations - IPR2020-01576
`Page 8 of 25
`
`
`
`Patent Application Publication
`
`Mar. 12, 2009 Sheet 8 of 14
`
`US 2009/0067377 A1
`
`
`
`3.
`
`t
`S> n2
`9 as
`co 5C
`S St.
`
`NO WWO
`9Wyd "TOWAS,
`
`:
`
`NOZ OWO
`NOZLOld
`OWOOO AWS AWS
`IWWSTO
`n
`U19
`
`TNW
`NO WWOSS WWO WWU9.
`
`ZHNO
`
`Intel Corporation Ex. 1012
`Intel Corp v. UNM Rainforest Innovations - IPR2020-01576
`Page 9 of 25
`
`
`
`Patent Application Publication
`
`Mar. 12, 2009 Sheet 9 of 14
`
`US 2009/0067377 A1
`
`ENOZ Å LEHVS
`
`
`
`(BA||10BdSHEd 091)
`
`
`
`
`
`O9WAS Ol
`
`IOWAS. Olvi. "9))LL
`
`y
`
`(IOWAS Olvi. "9) LL
`
`Old
`OWOIOO
`IAWS TO
`TWW
`
`ZHWO
`
`Intel Corporation Ex. 1012
`Intel Corp v. UNM Rainforest Innovations - IPR2020-01576
`Page 10 of 25
`
`
`
`Patent Application Publication
`
`Mar. 12, 2009 Sheet 10 of 14
`
`US 2009/0067377 A1
`
`
`
`SWW U9, SONIOTON TOU9.
`TOSWAS. Olvi. "93)).L.L
`
`CD
`s
`8
`
`O
`
`s
`O
`f
`
`N9n>Se
`
`3 59.
`CD of
`Eise
`23:25
`P-52
`n269
`seg332
`d s RC)
`O o
`
`O
`
`c
`
`HO
`
`WWITIO
`
`33N,
`OWOIOO
`IAWSO
`TNW
`ZHWO
`
`>
`
`Intel Corporation Ex. 1012
`Intel Corp v. UNM Rainforest Innovations - IPR2020-01576
`Page 11 of 25
`
`
`
`Patent Application Publication
`
`Mar. 12, 2009 Sheet 11 of 14
`
`US 2009/0067377 A1
`
`
`
`d n1 %
`
`
`
`
`
`2
`
`H
`
`:
`
`% D
`E N N (N N a N
`
`-
`N R
`D
`95
`R9.
`S35
`EoN
`v 2 N"N TSWWE
`Nilesian
`
`COLT
`
`N
`
`Intel Corporation Ex. 1012
`Intel Corp v. UNM Rainforest Innovations - IPR2020-01576
`Page 12 of 25
`
`
`
`Patent Application Publication
`
`Mar. 12, 2009 Sheet 12 of 14
`
`US 2009/0067377 A1
`
`
`
`9 I 'ADIH
`
`Intel Corporation Ex. 1012
`Intel Corp v. UNM Rainforest Innovations - IPR2020-01576
`Page 13 of 25
`
`
`
`Patent Application Publication
`
`Mar. 12, 2009 Sheet 13 of 14
`
`US 2009/0067377 A1
`
`2
`
`
`
`Z I AÐI. H
`
`
`
`
`
`
`
`
`Intel Corporation Ex. 1012
`Intel Corp v. UNM Rainforest Innovations - IPR2020-01576
`Page 14 of 25
`
`
`
`Patent Application Publication
`
`Mar. 12, 2009 Sheet 14 of 14
`
`US 2009/0067377 A1
`
`
`
`22
`
`s
`
`4W
`
`Sg s 2
`
`L
`2 -
`
`Intel Corporation Ex. 1012
`Intel Corp v. UNM Rainforest Innovations - IPR2020-01576
`Page 15 of 25
`
`
`
`US 2009/0067377 A1
`
`Mar. 12, 2009
`
`MEDIUMACCESS CONTROL FRAME
`STRUCTURE IN WIRELESS
`COMMUNICATION SYSTEM
`
`FIELD OF THE DISCLOSURE
`0001. The present disclosure relates generally to wireless
`communications and more specifically to medium access
`control frame structures in wireless communication systems
`with improved latency Support.
`
`BACKGROUND
`0002 An important consideration for advanced wireless
`communication systems is one-way air-interface latency. Air
`interface latency is primarily dependent on the Medium
`Access Control (MAC) frame duration. In the developing
`IEEE 802.16m protocol, for example, the proposed target
`latency is less than approximately 10 msec and some observ
`ers have suggested that a much lower latency may be required
`to compete with other developing protocols, for example,
`with 3GPP Long Term Evolution (LTE). The IEEE 802.16m
`protocol is an evolution of the WiMAX-OFDMA specifica
`tion for the IEEE 802.16e protocol. However, the legacy
`IEEE 802.16e TDD frame structure has a relatively long
`duration and is incapable of achieving the latency targets set
`for IEEE 802.16m.
`0003) Evolutionary wireless communication systems
`should also Support for legacy system equipment. For
`example, some IEEE 802.16e and IEEE 802.16m base sta
`tions and mobile stations are likely to coexist within the same
`network while upgrading to the newer system. Thus IEEE
`802.16e mobile stations should be compatible with IEEE
`802.16m base stations, and IEEE 802.16e base stations
`should support IEEE 802.16m mobile stations. Thus frame
`structures for air-interfaces are proposed with a view to
`achieving lower latency and in Some embodiments to main
`taining backward compatibility.
`0004 A legacy system is defined as a system compliant
`with a subset of the WirelessMAN-OFDMA capabilities
`specified by IEEE 802.16-2004 (specification IEEE Std 802.
`16-2004: Part 16: IEEE Standard for Local and metropolitan
`area networks: Air Interface for Fixed Broadband Wireless
`Access Systems, June 2004) and amended by IEEE 802.16e
`2005 (IEEE Std. 802.16e-2005, IEEE Standard for Local and
`metropolitan area networks, Part 16: Air Interface for Fixed
`and Mobile Broadband Wireless Access Systems, Amend
`ment 2: Physical and Medium Access Control Layers for
`Combined Fixed and Mobile Operation in Licensed Bands,
`and IEEE Std. 802.16-2004/Cor1-2005, Corrigendum 1,
`December 2005) and IEEE 802.16Cor2/D3, where the subset
`is defined by WiMAX Forum Mobile System Profile, Release
`1.0 (Revision 1.4.0: 2007-05-02), excluding specific fre
`quency ranges specified in the section 4.1.1.2 (Band Class
`Index).
`0005. The various aspects, features and advantages of the
`disclosure will become more fully apparent to those having
`ordinary skill in the art upon careful consideration of the
`following Detailed Description thereof with the accompany
`ing drawings described below. The drawings may have been
`simplified for clarity and are not necessarily drawn to scale.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0006 FIG. 1 is a wireless communication system.
`0007 FIG. 2 is a legacy protocol frame mapped to a next
`generation 1:2 Sub-frame.
`0008 FIG. 3 is a frame structure configuration having a
`75% duty cycle.
`
`0009 FIG. 4 is another frame structure configuration hav
`ing a 25% duty cycle.
`0010 FIG. 5 is a super-frame structure configuration.
`0011
`FIG. 6 is a frame having multiple sub-blocks of
`equal duration.
`0012 FIG. 7 is another frame having multiple sub-blocks
`of equal duration.
`0013 FIG. 8 is a frame having multiple sub-blocks of
`equal duration.
`0014 FIG. 9 is a super-frame comprising multiple frames
`of equal duration.
`(0015 FIG. 10 is an exemplary hybrid frame structure.
`0016 FIG. 11 is a frame having first and second protocol
`resource regions.
`0017 FIG. 12 is another frame having first and second
`protocol resource regions.
`0018 FIG. 13 is a frame having first and second protocol
`resource regions.
`0019 FIG. 14 is a frame having first and second protocol
`resource regions.
`0020 FIG. 15 is a frame having first and second protocol
`resource regions.
`0021
`FIG. 16 is a sequence of radio frames having first
`and second resource regions.
`0022 FIG. 17 is another sequence of radio frames having
`first and second resource regions.
`0023 FIG. 18 is another sequence of radio frames having
`first and second resource regions.
`
`DETAILED DESCRIPTION
`0024. In FIG. 1, the wireless communication system 100
`includes one or more fixed base infrastructure units forming a
`network distributed over a geographical region. A base unit
`may also be referred to as an access point, access terminal,
`Node-B, eNode-B, or by other terminology used in the art.
`The one or more base units 101 and 102 serve a number of
`remote units 103 and 110 within a serving area, for example,
`a cell, or within a cell sector. The remote units may be fixed or
`terminal. The remote units may also be referred to as sub
`scriber units, mobile stations, users, terminals, Subscriber
`stations, user equipment (UE), terminals, or by other termi
`nology used in the art.
`0025 Generally, base units 101 and 102 transmit down
`link communication signals 104 and 105 to serving remote
`units on at least a portion of the same resources (time and/or
`frequency). Remote units 103 and 110 communicate with the
`one or more base units 101 and 102 via uplink communication
`signals 106 and 113. The one or more base units may com
`prise one or more transmitters and one or more receivers that
`serve the remote units. The remote units may also comprise
`one or more transmitters and one or more receivers.
`0026. In one embodiment, the communication system uti
`lizes OFDMA or a next generation single-carrier (SC) based
`FDMA architecture for uplink transmissions, such as inter
`leaved FDMA (IFDMA), Localized FDMA (LFDMA), DFT
`spread OFDM (DFT-SOFDM) with IFDMA or LFDMA. In
`OFDM based systems, the radio resources include OFDM
`symbols, which may be divided into slots, which are group
`ings of sub-carriers. An exemplary OFDM based protocol is
`IEEE 802.16(e).
`0027 Generally, the wireless communication system may
`implement more than one communication technology as is
`typical of systems upgraded with newer technology, for
`example, the evolution of GSM to UMTS and future UMTS
`
`Intel Corporation Ex. 1012
`Intel Corp v. UNM Rainforest Innovations - IPR2020-01576
`Page 16 of 25
`
`
`
`US 2009/0067377 A1
`
`Mar. 12, 2009
`
`releases thereof. In FIG. 1, for example, one or more of the
`base units 101 may be legacy technology base stations, for
`example, IEEE 802.16(e) protocol base stations, and other
`base station may be newer generation technologies, for
`example, IEEE 802.16(m) protocol base stations. In these
`cases, it is generally desirable for the new technologies to be
`backward compatible with the legacy technology. For the
`evolution of IEEE 802.16(e), the backward compatibility
`constraint implies that the legacy frame structure, for
`example, the 5 msec duration 802.16(e) frame, must be sup
`ported by 802.16(m) base stations. Additionally, in order to
`efficiently support delay sensitive applications, 802.16(m)
`base stations should be able to service both 802.16(m) and
`legacy terminals within the common frame structure.
`0028 Regarding frame structure, it is generally necessary
`to design frames having a relatively short duration in order to
`reduce latency. Thus to deliver low latency in 802.16m sys
`tems with backward compatibility, it is necessary to develop
`a sub-frame structure based on the legacy 802.16(e) frame. In
`order to address the latency requirements, it is necessary to
`design frames with shorter than 5 msec duration. However, to
`efficiently serve legacy traffic, it is also necessary that 802.
`16(m) systems have 5 msec legacy frames. Thus two broad
`classes of frames would be required for an 802.16(m) system
`having reduced latency and Support for legacy 802.16(e)
`devices. The first class includes a full-frame (having a 5 msec
`duration) with one DL interval and one UL interval similar to
`the 802.16(e) TDD legacy frames. The second class of frames
`includes a sub-frame. For example, a 5 msec frame having N
`DL intervals and NUL intervals. This frame may also contain
`N transmit/receive transition gap (TTG) and receive/transmit
`transition gap (RTG) intervals. N could be kept small, typi
`cally N=2, in order to limit TTG and RTG related overhead.
`According to this exemplary Scheme, the legacy 802.16(e)
`TDD frames can only be a full-frame and the 802.16(m)
`frames are preferably sub-frame 1:2, although they could also
`be full-frames. The h-frames can be either full-frame or sub
`frame 1:2. FIG. 2 illustrates an 802.16(m) sub-frame 1:2 that
`is backwards compatible with a legacy 802.16(e) TDD frame,
`wherein the first and third blocks are downlink blocks and the
`second and fourth blocks are uplink blocks. In general, the
`length of the intervals of the blocks can be different.
`0029. The 802.16(m) 5 msec frame can be perceived to be
`composed of following types of basic regions: e-DL region
`used for transmission of downlink traffic to 802.16(e) termi
`nals; e-UL: region allocated for transmission of data and
`control messages by 802.16(e) terminals; m-DL: region allo
`cated for transmission to 802.16(m) terminals; and m-UL:
`region allocated for transmission by 802.16(m) terminals.
`The e-DL and e-UL regions can also be used for transmis
`sions to/from 802.16(m) terminals. In general, the structures
`of the 802.16(m) region (sub-channel and pilot structures)
`can be different from those of the 802.16(e) regions. Depend
`ing on the population of legacy and newer generation termi
`nals, it may be necessary to allocate the entire 5 msec frame
`for 802.16(e) services or 802.16(m) services.
`0030. Using these different types of regions, various types
`of 5 msec frame structures can be created to suit the traffic
`service requirements. These are: e-frames composed of only
`e-DL and e-UL regions used to serve legacy 802.16(e) TDD
`terminals (802.16(m) terminals can also be served in these
`frames in legacy mode); m-frames composed of m-DL and
`m-UL regions only for serving only 802.16(m) terminals:
`h-frames containing both e-DL/e-UL and m-DL/m-UL
`
`regions for serving 802.16(e) and 802.16(m) terminals. The
`802.16(m) portion and the 802.16(e) portion should be time
`division multiplexed so that the 802.16(m) control channel,
`pilot, and sub-channelization can provide flexibility.
`0031 Depending on the device type population and traffic
`pattern, it may be necessary to treat an m-frame oran h-frame
`as a legacy virtual frame in a cell/sector. The m-DL and m-UL
`regions in these frames may have different Sub-channel/pilot
`structures than the legacy systems; those regions need to be
`treated as “dead Zones', which the legacy terminals should
`not use. The full-frame, being similar in structure to the
`legacy 802.16(e) frame, can be easily mapped to a legacy
`virtual frame with full utilization of the frame resources.
`However, the sub-frame 1:N, which can also be mapped to
`legacy 802.16(e) virtual frame, will contain “dead Zone(s)
`where no 802.16(e) (TDD) transmission can be allowed to
`ensure DL/UL synchronization.
`0032. An 802.16(m) base unit can provide service to
`legacy 802.16(e) terminals in full-frames. To provide service
`in the sub-frame 1:N, the 802.16(m) base unit can map a
`legacy virtual 5 msec frame to Nadjacent Sub-frames and the
`train of Sub-frames can be organized as a train of legacy 5
`msec virtual frames. There are N choices for the time division
`duplex frame (TDD) split position in a legacy virtual frame.
`The system wide synchronization requirement for the TDD
`system imposes additional constraints on the downlink and
`uplink transmission intervals, creating dead Zones during
`which no transmission should be done to and from legacy
`802.16(e) TDD terminals. However, transmissions to and
`from 802.16(m) terminals are possible in these dead Zones.
`FIG. 3 illustrates a first configuration wherein a legacy 802.
`16(e) TDD terminal encounters a 5 msec frame having a 75%
`duty cycle. The frame includes a legacy preamble 302, a DL
`map 304, and a dead Zone 306 during which there is no legacy
`downlink allocation during the 802.16(m) uplink interval.
`FIG. 4 illustrates a second configuration wherein the frame
`includes a dead Zone 406 during which there is no legacy
`uplink allocation during the 802.16(m) downlink interval.
`0033. A generic message structure and its parameters to
`indicate a dead Zone is shown in Table 1.
`
`TABLE 1
`
`Message parameter for dead Zone indication
`
`Parameter
`
`value
`
`location
`dedicated pilot tag
`
`<symbol numbers, <times
`O or 1
`
`0034. In the above message, the parameter “location indi
`cates a position within the frame in time (which may be
`denoted by the symbol number within the frame or absolute
`time or time offset from the start of the frame or offset from
`some other specified time); the interpretation of the parameter
`“location' depends on the value of the parameter “dedicated
`pilot tag. If “dedicated pilot tag is 1, the pilot symbols after
`“location” are dedicated; if it is 0, it indicates that the pilot
`symbols after the “location” are not dedicated pilots. Thus a
`Zone with dedicated pilots can be described by two occur
`rences of this message: the first message with dedicated pilot
`tag=1 and location="T1", followed by a 2" message with
`dedicated pilot tag 0 and location=“T2, where T2>=T1: a
`legacy terminal which has been allocated resources within
`this Zone should use only pilots within its burst for channel
`
`Intel Corporation Ex. 1012
`Intel Corp v. UNM Rainforest Innovations - IPR2020-01576
`Page 17 of 25
`
`
`
`US 2009/0067377 A1
`
`Mar. 12, 2009
`
`estimation. A legacy terminal which has not been allocated
`resources within this Zone will ignore the pilots in this Zone
`and also it will not need to decode any of the data transmis
`sions within the dedicated pilot Zone. This combined with the
`BS not making an allocation to any 16e mobile in the Zone
`indirectly disables or isolates the 16e mobiles from this Zone.
`Thus, 16e mobile effectively ignores whatever is in the Zone.
`0035 An example message which can be used for indicate
`dead zones is the STC DL ZONE IE() of IEEE 802.16e
`specification; the parameters “OFDMA symbol offset and
`"Dedicated pilots’ in this message corresponds to the param
`eters “location' and “dedicated pilot tag in the above generic
`message in Table 1.
`0036) Another message structure and its parameters which
`can be used to implement dead Zones are shown in Table 2.
`
`TABLE 2
`
`Dead Zone message type 2
`
`Parameter
`
`value
`
`<symbol numbers f <times
`Starting symbol
`Starting Sub-channel <sub-carrier numbers f <sub-channel numbers
`Symbol count
`<Number of symbols.> <duration in times
`Sub-channel count
`<number of sub-carriers><number of sub
`channels.>
`
`0037. The four parameters describe a rectangular dead
`Zone of time-frequency resources. In this message, the
`parameter “starting symbol indicates a position within the
`frame in time (which may be denoted by the symbol number
`within the frame or absolute time or time offset from the start
`of the frame or offset from some other specified time) where
`the dead Zone begins; “symbol count' indicates the duration
`of the dead Zone, starting from the “starting symbol. The
`parameter'starting Sub-channel indicates the location in the
`Sub-carrier frequency where the dead Zone begins; this is in
`units of Sub-carrier or sub-channel, which is a group of Sub
`carriers; “sub-channel count indicates the length of the dead
`Zone in the frequency dimension. An example of this generic
`message type is the PAPR Reduction and Safety Zone
`Allocation IE() of the IEEE 802.16e specification. In this
`message, the parameters “OFDMA symbol offset”, “Sub
`channel offset”, “No. OFDMA symbols” and “No. sub-chan
`nels' corresponds to the parameters “starting symbol”, “start
`ing sub-channel”, “symbol count” and “sub-channel count
`of the generic dead Zone message type 2, respectively; the
`PAPR Reduction Safety Zone parameter in the PAPR Re
`duction and Safety Zone Allocation IE() should be set to
`“1” to indicate a reduced interference Zone to the legacy
`terminal; this will effectively direct the terminal not to per
`form any uplink transmission in that Zone.
`0038 Striking a balance between efficient legacy support
`and low-latency 802.16(m) service is challenging with a
`homogeneous frame size. The full-frames discussed above
`provide efficient legacy Support while sacrificing latency per
`formance for 802.16(m) terminals. The sub-frames provide
`low-latency support for 802.16(m) terminals while sacrific
`ing capacity for legacy terminals in the form of dead Zones.
`0039. In one embodiment, a heterogeneous configuration
`contains both full-frames and sub-frames, wherein the full
`frames and sub-frames are interleaved over time. Within a
`cell, the full-frames are primarily used for serving legacy
`terminals present in the cell, whereas the sub-frames are
`primarily used to serve the 802.16(m) terminals. However, for
`
`servicing packets with urgent delay constraints, either frame
`type can be used to service either type of terminal. The full
`frames and the Sub-frames are organized in a repeating pat
`tern, called a Super-frame.
`0040. In the Super-frame of FIG. 5, the interleaving pattern
`consists of two sub-frames 1:2 followed by one full-frame.
`This pattern is generally the same over all sector/cells. The
`first super-frame contains an 802.16(e) TDD virtual frame
`configuration with 75% duty cycle and the 2" super-frame
`contains a 802.16(e) TDD virtual frame configuration with
`25% duty cycle. Generally, for the same 802.16(e) TDD
`virtual frame, the configuration options can be different for
`different base stations. One base station may employ the
`802.16(e) virtual frame to communicate with a legacy termi
`nal while another neighboring base station may employ a 16m
`Sub-frame 1:2 structure to communicate with a 16m base
`station without any undesired interference between uplink
`and downlink transmissions. The proportion of the different
`types of frames and their interleaving patternina Super-frame
`is generally determined by the proportion of 802.16(e) and
`802.16(m) terminals in the system. The configurations may
`be implemented on a system-wide basis to ensure that there is
`no conflict between base unit transmission and reception in
`adjacent cells (e.g., no conflict in TDD TX/RX boundaries
`among adjacent cells).
`0041. Thus a next generation wireless communication
`infrastructure entity, for example, an 802.16(m) base unit in
`FIG. 1, would transmit a super-frame including a plurality of
`frames wherein each frame includes at least two regions. The
`regions are generally some sort of resource that may be allo
`cated to the terminals for uplink or downlink communications
`in the case of a TDD system. The super-frames are generally
`transmitted in a sequence. This Superframe structure must be
`communicated to all base stations in a TDD System to main
`tain synchronization of all sectors and cell in order to ensure
`that there is no conflict between base unit transmission and
`reception in adjacent cells. This structure may be communi
`cated in a control message specifying a configuration charac
`teristic of the regions within each frame of a super-frame. The
`control message may be transmitted to other base stations
`over the land line network or by other means such as radio
`communication links between the base stations. This control
`message may also be transmitted to terminals in at least one
`frame of the Superframe. The message may specify the con
`figuration characteristic of regions within each frame of the
`same Super-frame in which the message occurs, or in the
`frames of another Super-frame, for example a Subsequent
`Super-frame. In one embodiment, the configuration charac
`teristic of the regions within each frame of the Super-frame is
`specified in a control message map or by other means. In any
`case, in Some embodiments, the control message may contain
`a reference number specifying the map applicable for the
`Super-frame, thereby enabling terminals to distinguish
`among versions of the control message containing the con
`figuration characteristic.
`0042. In one embodiment, the configuration characteristic
`of the regions is selected from a group comprising: a number
`regions; region size; region type (e.g., uplink or downlink for
`a TDD system); and the ordering of the regions. Multiple
`characteristics may also be specified. In one embodiment, for
`a TDD system, the control message specifies whether the
`regions of the frame are uplink regions or downlink regions.
`Thus the regions are selected from a group of regions com
`prising: an uplink region and a downlink region. The control
`
`Intel Corporation Ex. 1012
`Intel Corp v. UNM Rainforest Innovations - IPR2020-01576
`Page 18 of 25
`
`
`
`US 2009/0067377 A1
`
`Mar. 12, 2009
`
`message may also specify the number of uplink regions or
`downlink regions within each frame of a Super-frame. In
`Some embodiments, the control message specifies a size of
`uplink regions or downlink regions within each frame of a
`super-frame. In FIG. 5, the frames generally have different
`numbers of resource blocks (a resource block is a downlink or
`uplink transmission interval). For example, the first and sec
`ond 5 msec sub-frames have four resource blocks, and the
`third 5 msec sub-frame has two blocks.
`0043. There are various ways to configure frames that
`provide legacy compatibility and reduce latency based on the
`proposed framework. Another factor to consider in the design
`of a new protocol frame structure is support for both TDD and
`FDD. Preferably, similar frame and sub-frame structures can
`be applied for both TDD and FDD.
`0044. In one embodiment, a frame is divided into multiple
`blocks of equal size, wherein the blocks may support one or
`more protocols, for example, IEEE 802.16(e) and/or 802.16
`(m). Such a frame would enable an 802.16(m) wireless com
`munication infrastructure entity to allocate radio resources to
`both 802.16(e) and 802.16(m) wireless terminals. Generally,
`the radio frame includes a plurality of blocks, including a first
`block and last block, wherein each block comprises a plural
`ity of symbols. In one embodiment, each block comprises
`substantially the same number of symbols. The first block
`includes a first protocol preamble, for example, a legacy
`protocol preamble like 802.16(e). The remaining blocks in
`the frame are devoid of the first protocol preamble.
`0045 Generally, the radio frame includes at least one first
`protocol block and/or at least one second protocol block, for
`example, 802.16(e) and/or 802.16(m) blocks. In some
`embodiment, the frame includes both first and second proto
`col blocks. In another embodiment, the frame includes only
`second protocol blocks, for example, 802.16(m) blocks. The
`radio frame includes an allocation control message for allo
`cating resources within a protocol block. In frames that
`include first and second protocol blocks, the radio frame
`includes a first protocol allocation control message for allo
`cating resources in the first protocol block, and a second
`protocol allocation control message for allocating resources
`in the second protocol block. In one embodiment, the alloca
`tion control message is a first protocol allocation control
`message for allocating resources within a first protocol block
`of a radio frame, for example, a Subsequent frame, that is
`different than the radio frame within which the first protocol
`allocation control message is located. In one embodiment, the
`first allocation control message is located in the first block.
`The first block may be a first or second protocol block, for
`example, an 802.16(e) or 802.16(m) block.
`0046. The sub-blocks may be described based on their
`position in the frame and the characteristics of the sub-block.
`For example, a 5 msec frame supporting both 802.16(e) and
`802.16(m) protocols may be characterized as one of the
`region types discussed above. There are five types of 802.16
`(m) Sub-blocks. Each Sub block has a unique characteristic
`designed to achieve the backward compatibility goals and
`efficient 802.16(m) performance. An 802.16(m) DL Lead
`Sub-Block contains a legacy 802.16(e) pre-amble in the first
`symbol. The remaining symbols of the frame may be allo
`cated to 802.16(m). This sub-block may only be transmitted
`in the first sub-frame. An 802.16(m) DL Lead Compatible
`sub-block also contain a 802.16(e) FCH and 802.16e DL
`MAP in addition to the 16e pre-amble for backward compat
`ibility with legacy terminals. The remaining symbols are
`
`allocated to 802.016(m). The Lead Compatible sub-block
`may be transmitted only in the first sub-frame. An 802.16(m)
`Synchronization Sub-Block contains abroadcast control that
`may be used to synchronize an 802.16(m) terminal and
`describe broader aspects of the 802.16(m) frame. This sub
`block occupies a unique position in the 5 ms frame as a
`reference for synchronization. The second Sub-frame is an
`appropriate, but not necessary, position for this synchroniza
`tion sub-block. An 802.16(m) DLSub-Block is a generic 16m
`sub-block that contains 802.16(m) Downlink data and 802.
`16(m) control. This may be occupying the 2", 3" or 4"
`sub-frames. An 802.16(m) UL Sub-Block is a generic 802.16
`(m) sub-block contains 802.16(m) Downlink data and 802.
`16(m) control. This block may occupy the 2", 3" or 4"
`sub-frame.
`0047. There are five types of 802.16(e) sub-blocks that
`may be allocated in the 802.16(m) frame structure. These
`sub-blocks conform to the legacy specification of 802.16(e)
`frames and cannot be distinguished from legacy 802.16(e)
`frames by a legacy mobile. A Legacy DL Lead Sub-Block is
`identical to legacy frames containing a 802.16(e) pre-amble,
`802.16(e) FCH,802.16(e) DL-MAP. This sub-block will con
`tain 802.16(e) downlink data and would typically contain an
`UL MAP. A legacy DL Secondary Sub-Block is identical to
`legacy 802.16(e) numerology and contains 802.16(e) DL
`data. The Legacy DL Secondary Sub-Block may only follow
`a Legacy DL Lead Sub-Block. A Legacy DL Tertiary Sub
`Block block is identical to a legacy 802.16(e) numerology
`and contains 802.16(e) DL data. The Legacy DL Tertiary
`Sub-Block may only follow a Legacy DL Secondary Sub
`Block. A legacy UL Tertiary Sub-Block contains legacy
`uplink data and may also