as) United States
`a2) Patent Application Publication (10) Pub. No.: US 2009/0067377 Al
`(43) Pub. Date: Mar.12, 2009
`
`TALUKDARetal.
`
`US 20090067377A1
`
`(54) MEDIUM ACCESS CONTROL FRAME
`STRUCTURE IN WIRELESS
`COMMUNICATION SYSTEM
`
`(22)
`
`Filed:
`
`Aug. 13, 2008
`
`Related U.S. Application Data
`
`(75)
`
`Inventors:
`
`ANUP K. TALUKDAR,Dekalb,
`Tl, (US); MARK C. CUDAK,
`ROLLING MEADOWS,IL (US);
`KEVIN IL. BAUM, ROLLING
`MEADOWS,IL (US); AMITAVA
`GHOSH. BUFFALO GROVF,IT.
`(US); STAVROS TZAVIDAS,
`EVANSTON,IT. (US); FAN
`WANG. VERNONHILLS.IL
`(US); HUA XU, LAKE ZURICH,
`IL (US); XIANGYANG ZHUANG,
`Lake Zurich, IL (US)
`
`(60) Provisional application No. 60/956,031, filed on Aug.
`15, 2007.
`
`Publication Classification
`
`(51)
`
`Int.Cl.
`(2009.01)
`HOAW 72/04
`(52) US. CM. vascsscssssssssssssssssssssssssssesssssssssssseessteee 370/329
`
`(57)
`
`ABSTRACT
`
`A wireless communication infrastructure entity configured to
`allocate radio resources, in a radio frame, to a wireless termi-
`nal compliant witha first protocol and to a wireless terminal
`compliant with a second protocol. Theradio frame including
`Correspondence Address:
`MOTOROLA INC
`a first protocol resource region and a second protocol resource
`region. The radio frame includingafirst protocol allocation
`600 NORTH US HIGHWAY45, W4 - 39Q
`control message that allocates resources withinthe first pro-
`LIBERTYVILLE, IT. 60048-5343 (US)
`tocol resource region to the wireless terminal compliant with
`the first protocol, and a second protocol allocation control
`messagethat allocates resources within the second protocol
`resource region to the wireless terminal compliant with the
`second protocol.
`
`(73) Assignee:
`
`MOTOROLA,INC.,
`LIBERTYVILLE,Il. (US)
`
`(21) Appl. No.:
`
`12/191,042
`
`100
`
`103
`
`REMOTE UNIT
`
`
`
`BASE UNIT
`
`BASE UNIT
`
`REMOTE UNIT
`
`ZyXEL Communications Corporation Ex. 1012
`Page 1 of 25
`
`ZyXEL Communications Corporation Ex. 1012
`Page 1 of 25
`
`

`

`Patent Application Publication Mar. 12,2009 Sheet 1 of 14
`
`US 2009/0067377 Al
`
`100
`
`103
`
`BASE UNIT
`
`REMOTE UNIT
`
`REMOTE UNIT BASE UNIT
`
`FIG. 1
`
`ZyXEL Communications Corporation Ex. 1012
`Page 2 of 25
`
`ZyXEL Communications Corporation Ex. 1012
`Page 2 of 25
`
`

`

`Patent Application Publication Mar. 12,2009 Sheet 2 of 14
`
`US 2009/0067377 Al
`
`2.5 msec
`
`FIG. 2
`
`FIG. 3
`
`FIG. 4
`
`ZyXEL Communications Corporation Ex. 1012
`Page 3 of 25
`
`ZyXEL Communications Corporation Ex. 1012
`Page 3 of 25
`
`

`

`AWVas-dsdNs
`
`AWVYs-TINA
`
`AWVesTINA
`
`SAWVYsENs AIWVas-dadNs
`
`Patent Application Publication Mar. 12, 2009 Sheet 3 of 14
`
`US 2009/0067377 Al
`
`WL)
`
`SW
`WAS
`NN
`NNVISA.
`NZEIZNZNZ
`
`°DIA
`
`ZNOILdO‘AWVYS39SUGTWNLUYIA291
`
`
`LNOILdO‘SWVYS99SGTWNLUIA891
`
`
`
`ZyXEL Communications Corporation Ex. 1012
`Page 4 of 25
`
`ZyXEL Communications Corporation Ex. 1012
`Page 4 of 25
`
`

`

`Patent Application Publication Mar. 12,2009 Sheet 4 of 14
`
`US 2009/0067377 Al
`
`
`5 msec
`
`we
`
`:
`
`
`12SYMBOLS
`
`
`
`NN
`
`NO
`
`DL
`
`DLIUL
`
`DUUL
`
`
`48 SYMBOLS
`
`606
`
`608
`
`610
`
`612
`
`we
`
`5 msec
`
`48 SYMBOLS
`
` DL/UL
`
`12 SYMBOLS
`
`SIORK
`
`16e-UL
`16m-DL/UL
`
`DL/UL
`16e/16m
`
`16e/16m
`
`706
`
`708
`
`FIG. 7
`
`ZyXEL Communications Corporation Ex. 1012
`Page 5 of 25
`
`ZyXEL Communications Corporation Ex. 1012
`Page 5 of 25
`
`

`

`Patent Application Publication Mar. 12,2009 Sheet 5 of 14
`
`US 2009/0067377 Al
`
`re
`SPL
`LR
`
`4
`OSSDeSe
`
`NNN
`
`
`
` 20 msec >|
`
`
`
`LZ777a
`
`16e/HEM-I/
`HEN-II/16m
`
`16e/HEM-I/
`HEM-II/16m
`
`16e/HEM-I/
`HEN-I/46m
`
`FIG. 9
`
`ZyXEL Communications Corporation Ex. 1012
`Page 6 of 25
`
`ZyXEL Communications Corporation Ex. 1012
`Page 6 of 25
`
`

`

`Patent Application Publication
`
`Mar. 12, 2009 Sheet 6 of 14
`
`
`
`
`
`
`(4RS
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`ah KN
`
`
`
` a\yyrsNai,+gsSWVYs-wJWVYs-w10-2
`
`
`
`
`
`
`GHpLelizbbblony78[2]9[S[r[ele]+olstiprerjeyblioe[e|z/9/s{rlelej+jo}||Lt]
`
`reeLE0E|62/8¢mheg|ceheenrece02alas
`
`
`
`
`
`
`US 2009/0067377 Al
`
`OlDI
`
`NJ
`
`isSwIG.CA
`
`
`ZyXEL Communications Corporation Ex. 1012
`Page 7 of 25
`
`ZyXEL Communications Corporation Ex. 1012
`Page 7 of 25
`
`
`
`

`

`Patent Application Publication
`
`Mar. 12, 2009 Sheet 7 of 14
`
`US 2009/0067377 Al
`
`NOLLWNWaad10Wal
`OWVW/OSNd
`
`t
`
`NOLLYNWaad10WoL
`OWV/OSNA/OSNd
`
`+
`
`
`
`
`
`ANOZOSNd-1N
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` ATNNOILGOaaAVIN(COW;—
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`oO|22“ateveen[3ee 3NOZ
`
`
`38AVNVV)‘1d891
`
`
`
`S|3OST
`QO-:3E
`YALNIOd d¥W 40 LASENS dV¥W 40 d¥W Wo]
`
`
`LOTldOS_GSLVOIGACYOALAIVSmaraeeee
`
`
`(BALLOdSHAd991)No
`
`
`
`
`°Re
`
`atli?
`Some
`ams
`m
`snd|
`
`HOA
`
`i
`
`J TeWvadd
`
`ZHA0L
`
`ZyXEL Communications Corporation Ex. 1012
`Page 8 of 25
`
`ZyXEL Communications Corporation Ex. 1012
`Page 8 of 25
`
`
`

`

`Patent Application Publication Mar. 12,2009 Sheet 8 of 14
`
`US 2009/0067377 Al
`
`
`
`YALNIOd dVW 40 LASENS dV JO aov
`(JOBWAS 2/} AT8VYSI5Yd “IOSNAS | OL o/b “D"S) OLL
`
` (JOSWAS 2/1 ATavuasaud“IOSWAS LOL v/b "9°3) OLL
`16mDL
`
`FIG,12
`
`P
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`PUSC/AMCpig16mUL (16e
`
`ee
`PERS-PECTIVE)
`
`
`
`
`716mULTRAFFIC
`
` OPTIONALLYALSOINCLUDE
`(DATAMAYBEAMC)MAY
`
`
`
`
`SAFETYORDEDICATED
`
`
`PILOTZONE(16ePERSPECTIVE)
`
`
`—16eDLaaeeee
`
`
`
`
`
`PUSC/FUSC/AMC
`
`Sl SNOZ
`Al ANOZ LOTId}}
`dVW/IN/10 qgalvoldad|}ALaavS ALSAVS
`
`/ALAAVS 10
`n
`Wg)
`
`TTEWVadd
`
`|RUSC
`
`>|
`
`>
`
`
`
`
`
` AClYYsAO
`
`YSLNIOd d¥W 40 LAS8NS dVW 40 dv Wg}
`
`ZHWOL
`
`Y
`
`ZyXEL Communications Corporation Ex. 1012
`Page 9 of 25
`
`ZyXEL Communications Corporation Ex. 1012
`Page 9 of 25
`
`

`

`Patent Application Publication
`
`Mar. 12, 2009 Sheet 9 of 14
`
`US 2009/0067377 Al
`
`=ooO
`
`“9'3) DLL
`
`=<=wmo4
`
`wn
`
`ONIGNTONI
`‘1dWg)
`
`SdVWWd}
`
`
`TOGNAS| OL #/1 “9"S) DLL
`
`
`
`
`
`
`
`
`
`
`
`
` sansa
`
`OWW/OSNd“OSNd
`
`
`
`
`
` OINV/OSNs/ISNd osnd
`
`3NOZLOdG3LVOIdSdYOALS4VS
` NOILINIS30LOTdTANNYHOSNS
`
`(AALLOAdSHad991)
` AOVOTTYOMAN
`
`
`
`NYO(STEISSOdOSTY
`
`
`OSNd‘OWV)NMOHS
`OSTVATIVNOILdO
`71dWg}SQNTONI
`
`da lvoldad
`/ALAAVS 10
`A1eWVvadd
`
`ZHWOL
`
`$
`
`SLL AVDA
`
`(IOSWAS | OL HL DS) OLL
`
`
`
`
`
`
`
`
`
`ANOZOSNd891
`
`OlddVal
`
`
`
`ZyXEL Communications Corporation Ex. 1012
`Page 10 of 25
`
`ZyXEL Communications Corporation Ex. 1012
`Page 10 of 25
`
`
`

`

`Patent Application Publication Mar. 12,2009 Sheet 10 of 14
`
`US 2009/0067377 Al
`
`
`
`(JOAWAS |
`
`FIG.14
`
`
`
`
`
`
`
`
`
`
`
`
`
`ZONE(16ePERSPECTIVE)
` SAFETY
`
`
`
`PUSC,PUSC/AMG
`
`
`
`16mUL
`
`
`
` NEWORLEGACYSUBCHANNEL/PILOTDEFINITIONS
`
` INCLUDING16mMAPS
`
`
` (16ePERSPECTIVE)
`
`
`
`
`OPTIONALLYA\ 16ePUSCZONESHOWNCueFUSCSIBLE
` ieINCLUDE16mDL
`
` PUSC/FUSC/AMC
`ALSOPO
`
`
`dvd
`as1voidsa
`
`/ALadVS 10
`
`
`aTaNvadd
`ZHIOL
`>
`
`PUSC
`
`ZyXEL Communications Corporation Ex. 1012
`Page 11 of 25
`
`ZyXEL Communications Corporation Ex. 1012
`Page 11 of 25
`
`

`

`lication Publication Mar. 12,2009 Sheet 11 of 14
`
`US 2009/0067377 Al
`
`FIG.15
`
`V4)DOWNLINKQQUPLINK E
`
`N
`
`o=
`
`oOXS S
`
`JIESWNVsdd
`
`ZyXEL Communications Corporation Ex. 1012
`Page 12 of 25
`
`ZyXEL Communications Corporation Ex. 1012
`Page 12 of 25
`
`

`

`Patent Application Publication Mar. 12,2009 Sheet 12 of 14
`
`US 2009/0067377 Al
`
`FRAMEFRAMEel
`
`
`-FRAME
`
`FRAME n
`
`FIG.16
`
`TIME
`
`f
`FRAME n-1
`
`ote
`
`ZyXEL Communications Corporation Ex. 1012
`Page 13 of 25
`
`ZyXEL Communications Corporation Ex. 1012
`Page 13 of 25
`
`

`

`Patent Application Publication Mar. 12,2009 Sheet 13 of 14
`
`US 2009/0067377 Al
`
`VLLLLLA
`
`FRAME n+2
`
`zt
`as
`PeLL
`
`NY
`sy
`
`2
`
`VLLLLL
`
`
`
`FROMC71INFRAMEn-1
`LLLSLAFROMC2INFRAMEn-1
`
`
`ZyXEL Communications Corporation Ex. 1012
`Page 14 of 25
`
`ZyXEL Communications Corporation Ex. 1012
`Page 14 of 25
`
`

`

`Patent Application Publication Mar. 12,2009 Sheet 14 of 14
`
`US 2009/0067377 Al
`
`FRAME n+2
`
`=
`
`TOP'1INFRAMEn+2
`
`FIG.18
`
`ae
`=e
`oS=
`Or
`oe
`
`Lu
`
`ZyXEL Communications Corporation Ex. 1012
`Page 15 of 25
`
`ZyXEL Communications Corporation Ex. 1012
`Page 15 of 25
`
`

`

`US 2009/0067377 Al
`
`Mar. 12, 2009
`
`MEDIUM ACCESS 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 framestructures in wireless communication systems
`with improvedlatency support.
`BACKGROUND
`
`[0002] An important consideration for advanced wireless
`communication systemsis one-wayair-interface latency. Air-
`interface latency is primarily dependent on the Medium
`Access Control (MAC) frame duration. In the developing
`JEEE 802.16mprotocol, for example, the proposed target
`latency is less than approximately 10 msec and some observ-
`ers have suggestedthat a much lowerlatency 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 WiIMAX-OFDMAspecifica-
`tion for the TREE 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 stationsare likely to coexist within the same
`
`
`
`
`network while upgrading to the newer system. Thus JEL
`802.16e mobile stations should be compatible with IEEE
`802.16m base stations, and TERE 802.16e base stations
`should support IEEE 802.16m mobile stations. ‘Vhus 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 systemis defined as a system compliant
`
`
`with a subset of the WirclessMAN-OFDMA capabilitics
`
`
`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 T icensed 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 ForumMobile SystemProfile, 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 drawnto scale.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`T
`
`
`
`FIG. 4 is anotherframestructure configuration hav-
`[0009]
`ing a 25% duty cycle.
`[0010]
`FIG. 5 is a super-framestructure 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
`ofequal duration.
`[0015]
`FIG. 10 is an exemplaryhybrid framestructure.
`[0016]
`FIG.11 is a frame havingfirst and second protocol
`resource regions.
`[0017]
`G. 12 is another frame having first and second
`protocol resource regions.
`[0018]
`FIG. 13 is a frame havingfirst and second protocol
`resource regions.
`[0019]
`FIG. 14 is a frame havingfirst and. second protocol
`resource regions.
`[0020]
`FIG. 15 is a frame having Lirst 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 sequenceofradio frames having,
`first and second resource regions.
`[0023]
`FIG. 18 is another sequenceofradio frames having,
`first and second resource regions.
`
`
`
`DETAILED DESCRIPTION
`
`
`
`
`In FIG.1, the wireless communication system 100
`[0024]
`includes one or morefixed baseinfrastructure units forming a
`network distributed over a geographical region. A base unit
`mayalso be referred to as an access point, access terminal,
`Node-B, eNode-B, or by other terminology usedin 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,
`acell, 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-
`nologyused 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 systemuti-
`lizes OFDMA ora next generation single-carrier (SC) based
`FDMA architecture for uplink transmissions, suchas inter-
`leaved EDMA(IFDMA), Localized FDMA (LEDMA), DE'L-
`spread OFDM (DFT-SOFDM)with IFDMA or LFDMA.In
`OFDMbased systems, the radio resources include OFDM
`symbols, which may be divided into slots, which are group-
`ings of sub-carriers. An exemplary OFDM basedprotocol is
`IEEE 802.16(e).
`[0006] FIG.1is a wireless communication system.
`
`[0027] Generally, the wireless communication system may
`[0007]
`FIG.2 is a legacy protocol frame mapped to a next
`generation 1:2 sub-l[rame.
`implement more than one communication technology as is
`typical of systems upgraded with newer technology, for
`[0008] TIG. 3 is a framestructure configuration having a
`75% dutycycle.
`example, the evolution of GSM to UMTSand future UMTS
`
`ZyXEL Communications Corporation Ex. 1012
`Page 16 of 25
`
`ZyXEL Communications Corporation Ex. 1012
`Page 16 of 25
`
`

`

`US 2009/0067377 Al
`
`Mar. 12, 2009
`
`
`
`
`
`releases thereof. In FIG. 1, for example, one or more of the
`
`
`base units 101 may be legacy technologybase stations, for
`example, IEEE 802.16(c) 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,
`lor
`example, the 5 msec duration 802.16(e) frame, must be sup-
`ported by 802.16(m) base stations. Additionally, in order ta
`efficiently support delay sensitive applications, 802.16(m)
`base stations should be able to service both 802.16(m) and
`legacy terminals within the commonframestructure.
`[0028] Regarding [ramestructure,il is generally necessary
`to design frames having a relatively short duration in order to
`reduce latency. ‘hus to deliver low latency in 802.16m sys-
`tems with backward compatibility, it is necessaryto develop
`a sub-framestructure based onthe 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 legacytraffic, 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. Thefirst class includesa full-frame (having a 5 msec
`duration) with one DL interval and one UL interval similar to
`the 802.16(c) TDD legacy frames. The second class offrames
`includes a sub-frame. For example, a 5 msec frame having N
`DLintervals and N ULintervals. 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 orderto limit TTG and RTG related overhead.
`According to this exemplary scheme, the legacy 802.16(c)
`TDD frames can only be a full-frame and the 802.16(m)
`frames are preferably sub-frame1:2, although they could alsa
`be full-frames. The h-frames can beeither full-frame or sub-
`frame 1:2. FIG. 2 illustrates an 802.16(m) sub-[rame 1:2 that
`is backwards compatible with a legacy 802.16(e) TDD frame,
`wherein the first and. third. blocks are downlink blocks andthe
`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
`composedof 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 dala and
`control messages by 802.16(e) terminals; m-DL: regionallo-
`cated for transmission to 802.16(m) terminals; and m-UT.:
`region allocated for transmission by 802.16(m) terminals.
`The e-DI. and e-UT, 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 bedifferent 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 ofregions, 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-ULregions 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 andtraffic
`pattern, it may be necessaryto treat an m-frameor an h-frame
`as a legacyvirtual frame in a cell/sector. The m-DI and m-UT,
`regions in these frames mayhave 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(c) (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-lrame 1:N,
`the 802.16(m) base unit can map a
`legacyvirtual 5 msec frame to N adjacent sub-frames and the
`train of sub-frames can be organized as a train of legacy 5
`msecvirtual frames. There are N choicesfor 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(c) TDD terminals. However, transmissions to and
`from 802.16(m) terminals are possible in these dead zones.
`FIG.3 illustratesa 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 whichthere 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
`
`<symubol number>/<lime>
`Oorl
`
`Intheabove message,the parameter “location” indi-
`[0034]
`cates a position within the frame in time (which may be
`denoted by the symbol numberwithin the frame or absolute
`timeor time offset from the start of the frameor offset from
`someotherspecified time); the interpretation ofthe parameter
`“location” depends on the value of the parameter “dedicated
`pilot tag”. If “dedicatedpilot 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 onlypilots within its burst for channel
`
`ZyXEL Communications Corporation Ex. 1012
`Page 17 of 25
`
`ZyXEL Communications Corporation Ex. 1012
`Page 17 of 25
`
`

`

`US 2009/0067377 Al
`
`Mar. 12, 2009
`
`estimation. A legacy terminal which has not been allocated
`resources within this zone will ignore the pilots in this zone
`and alsoit 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 16c mobile in the zone
`indirectly disables or isolates the 16e mobiles from this zone.
`Thus, 16e mobile effectively ignores whateveris in the zone.
`[0035] An example message whichcanbe usedforindicate
`dead zones is the STC_DL_ZONE_IE( ) of IEEE 802.16e
`specification; the parameters “OFDMA symboloffset” and
`“Dedicatedpilots”in this message corresponds to the param-
`eters “location” and “dedicatedpilot tag”in the above generic
`messagein Table 1.
`[0036] Another message structure and its parameters which
`can be used to implement dead zones are shownin Table 2.
`
`TABLE 2
`
`Dead zone message type 2
`value
`
`Parameter
`
`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]
`Inthe super-frame ofFIG.5, the interleaving pattern
`consists of two sub-frames 1:2 followed by one full-frame.
`This pattern is generally the same overall sector/cells. The
`first super-frame contains an 802.16(e) TDD virtual frame
`contiguration with 75% duty cycle and the 2”super-trame
`contains a 802.16(e) TDD virtual frame configuration with
`25% duty cycle. Generally, for the same 802.16(c) 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
`slaGion without any undesired interference between uplink
`and downlink transmissions. The proportion of the different
`types offrames andtheir interleaving pattern in a super-frame
`is generally determined by the proportion of 802.16(e) and
`802.16(m) terminals in the system. The configurations may
`«symbol number>/<time>
`Starting symbol
`be implemented on a system-wide basis to ensure that there is
`Starting sub-channel <sub-carrier number>/<sub-channel number>
`Symbol count
`<Number of symbols>/<duration in time>
`no conflict between base unit transmission and reception in
`Sub-channel count—<number of sub-carriers>/<oumber of sub-
`adjacent cells (e.g., no conflict in TDD Tx/Rx boundaries
`chamels>
`among, adjacentcells).
`[0041] Thus a next generation wireless communication
`infrastructure entity, for example, an 802.16(m) base unit in
`FIG.1, would transmit a super-frameincluding a plurality of
`frames wherein each frame includesat least two regions. The
`regions are generally somesort of resource that may beallo-
`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 ofthe regions within each frame ofa super-frame. The
`control message maybe 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 mayalso be transmitted to terminals in at least one
`frame ofthe superlrame. ‘The message mayspecily 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 ofthe super-frameis
`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
`ofthe regionsis selected from a group comprising: a number
`regions; region size; regiontype(e.g., uplink or downlink for
`a TDD system); and the ordering of the regions. Multiple
`characteristics mayalso 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 ofregions com-
`prising: an uplink region and a downlink region. The control
`
`[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
`framein time (which may be denoted by the symbol number
`within the frameorabsolute timeor time offset from thestart
`of the frameor 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, whichis a group of sub-
`carriers; “sub-channel count”indicates the length ofthe dead
`zonein the frequency dimension. An exampleofthis 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-
`channeloffset”, “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_Salety_Zone parameter in the PAPR_Re-
`duction_and_Safety_Zone_Allocation_IE( ) shouldbeset to
`“1” to indicate a reduced interference zone to the legacy
`terminal; this will effectively direct the terminal not to per-
`formany uplink transmissionin that zone.
`[0038]
`Striking a balance betweenefficient legacy support
`and low-latency 802.16(m) service is challenging with a
`homogeneous frame size. The full-frames discussed above
`provideefficient legacy support while sacrificing latencyper-
`formance for 802.16(m) terminals. The sub-frames provide
`low-latency support for 802.16(m) terminals while sacrific-
`ing capacityfor 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
`
`ZyXEL Communications Corporation Ex. 1012
`Page 18 of 25
`
`ZyXEL Communications Corporation Ex. 1012
`Page 18 of 25
`
`

`

`US 2009/0067377 Al
`
`Mar. 12, 2009
`
`message mayalso specify the number of uplink regions or
`downlink regions within each frame of a super-frame. In
`some embodiments, the control message specifics a size of
`uplink regions or downlink regions within each frame of a
`super-frame. In FIG. 5, the frames generally have different
`numbers ofresource 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-[rame has twoblacks.
`
`[0043] There are various ways to configure frames that
`provide legacy compatibility and reduce latency based on the
`proposed framework. Anotherfactor to considerin the design
`ofa new protocolframe structure is support for both TDD and
`FDD.Preferably, similar frame and sub-frame structures can
`be applied for both TDD and FDD.
`[0044]
`Inone embodiment, a frameis divided into multiple
`blocks of equal size, wherein the blocks may support one or
`more protocols, [or example, IEEE 802.16(e) and/or 802.16
`(m). Such a frame would enable an 802.16(m) wireless com-
`munication infrastructure entityto allocate radioresources ta
`both 802.16(e) and 802.16(m) wireless terminals. Generally,
`the radio frame includesa plurality of blocks, includinga first
`block and last block, wherein each block comprisesa 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 ofthe first protocol preamble.
`[0045] Generally, the radio [rame includesat least onefirst
`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 bothfirst 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 [or allo-
`cating resources within a protocol block. In frames that
`include first and second protocol blocks,
`the radio frame
`includesa first protocol allocation control messagefor 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
`messagefor allocating resources withina first protocol block
`of a radio frame, for example, a subsequent frame, that is
`different than the radio frame within whichthe first protocol
`allocation control messageis located. In one embodiment, the
`first allocation control message is located in thefirst block.
`Thefirst block may bea first or second protocol block, for
`example, an 802.16(e) or 802.16(m) block.
`[0046]
`‘The sub-blocks maybe 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 arefive 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-amblein thefirst
`symbol. The remaining symbols of the frame may be allo-
`cated to 802.16(m). This sub-block mayonlybe 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-
`MAPin addition to the 16c pre-amble for backward compat-
`ibility with legacy terminals. The remaining symbols are
`
`
`
`allocated to 802.016(m). The Lead Compatible sub-block
`maybe transmitted only in the first sub-frame. An 802.16(m)
`Synchronization Sub-Block containsa broadcast control that
`maybe used to synchronize an 802.16(m) terminal and
`describe broader aspects ofthe 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-black. An 802.16(m) DL Sub-Blockis a generic 16m
`sub-block that contains 802.16(m) Downlink data and 802.
`16(m) conirol. ‘his may be occupying the 2%, 3° or 4”
`sub-frames. An 802.16(m) UL Sub-