802.16j 2009 multivano man lan
TRANSCRIPT
IEEE Std 802.16j™-2009(Amendment to
IEEE Std 802.16-2009)
IEEE Standard forLocal and metropolitan area networks
Part 16: Air Interface for BroadbandWireless Access Systems
Amendment 1: Multihop RelaySpecification
IEEE3 Park AvenueNew York, NY 10016-5997, USA
12 June 2009
IEEE Computer Societyand theIEEE Microwave Theory and Techniques Society
Sponsored by theLAN/MAN Standards Committee
802.16jT
M
IEEE Std 802.16j™-2009(Amendment to
IEEE Std 802.16-2009)
IEEE Standard forLocal and metropolitan area networks
Part 16: Air Interface for Broadband Wireless Access SystemsAmendment 1: Multihop Relay Specification
SponsorLAN/MAN Standards Committee of theIEEE Computer Society
and theIEEE Microwave Theory and Techniques Society
Approved 13 May 2009
IEEE-SA Standards Board
®
Abstract: This amendment specifies OFDMA physical layer and medium access control layer enhancements to IEEE Std 802.16 for licensed bands to enable the operation of relay stations. Keywords: broadband wireless access (BWA), MAN, microwave, mobile, multihop relay, OFDM, OFDMA, radio, standard, wireless access systems (WAS), WirelessMAN®, wireless metropolitan area network
The Institute of Electrical and Electronics Engineers, Inc.3 Park Avenue, New York, NY 10016-5997, USA
Copyright © 2009 by the Institute of Electrical and Electronics Engineers, Inc.All rights reserved. Published 12 June 2009. Printed in the United States of America.
IEEE and 802 and WirelessMAN are registered trademarks in the U.S. Patent & Trademark Office, owned by The Institute of Electrical and Electronics Engineers, Incorporated.
PDF: ISBN 978-0-7381-5921-8 STD95915Print: ISBN 978-0-7381-5922-5 STDPD95915
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher.
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards through a consensus development process, approved by the American National Standards Institute, which brings together volunteers representing varied viewpoints and interests to achieve the final product. Volunteers are not necessarily members of the Institute and serve without compensation. While the IEEE administers the process and establishes rules to promote fairness in the consensus development process, the IEEE does not independently evaluate, test, or verify the accuracy of any of the information or the soundness of any judgments contained in its standards.
Use of an IEEE Standard is wholly voluntary. The IEEE disclaims liability for any personal injury, property or other damage, of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the publication, use of, or reliance upon this, or any other IEEE Standard document.
The IEEE does not warrant or represent the accuracy or content of the material contained herein, and expressly disclaims any express or implied warranty, including any implied warranty of merchantability or fitness for a specific purpose, or that the use of the material contained herein is free from patent infringement. IEEE Standards documents are supplied “AS IS.”
The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard. Every IEEE Standard is subjected to review at least every five years for revision or reaffirmation. When a document is more than five years old and has not been reaffirmed, it is reasonable to conclude that its contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have the latest edition of any IEEE Standard.
In publishing and making this document available, the IEEE is not suggesting or rendering professional or other services for, or on behalf of, any person or entity. Nor is the IEEE undertaking to perform any duty owed by any other person or entity to another. Any person utilizing this, and any other IEEE Standards document, should rely upon his or her independent judgment in the exercise of reasonable care in any given circumstances or, as appropriate, seek the advice of a competent professional in determining the appropriateness of a given IEEE standard.
Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to specific applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate action to prepare appropriate responses. Since IEEE Standards represent a consensus of concerned interests, it is important to ensure that any interpretation has also received the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration. A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board Operations Manual shall not be considered the official position of IEEE or any of its committees and shall not be considered to be, nor be relied upon as, a formal interpretation of the IEEE. At lectures, symposia, seminars, or educational courses, an individual presenting information on IEEE standards shall make it clear that his or her views should be considered the personal views of that individual rather than the formal position, explanation, or interpretation of the IEEE.
Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation with IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments. Comments on standards and requests for interpretations should be submitted to the following address:
Secretary, IEEE-SA Standards Board445 Hoes LanePiscataway, NJ 08854USA
Authorization to photocopy portions of any individual standard for internal or personal use is granted by The Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center. To arrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy portions of any individual standard for educational classroom use can also be obtained through the Copyright Clearance Center.
Introduction
This introduction is not part of IEEE Std 802.16j-2009, IEEE Standard for Local and metropolitan area networks—Part 16: Air Interface for Broadband Wireless Access Systems—Amendment 1: Multihop Relay Specification.
This amendment updates and expands IEEE Std 802.16, specifying OFDMA physical layer and mediumaccess control layer enhancements to IEEE Std 802.16 for licensed bands to enable the operation of relaystations. Subscriber station specifications are not changed. As of the publication date, the current applicableversion of IEEE Std 802.16 is IEEE Std 802.16-2009, as amended by IEEE 802.16j-2009.
Conformance test methodology
The multipart conformance test documents for IEEE Std 802.16 are designated by “IEEE Standard 802.16/ConformanceXX.”
Notice to users
Laws and regulations
Users of these documents should consult all applicable laws and regulations. Compliance with theprovisions of this standard does not imply compliance to any applicable regulatory requirements.Implementers of the standard are responsible for observing or referring to the applicable regulatoryrequirements. IEEE does not, by the publication of its standards, intend to urge action that is not incompliance with applicable laws, and these documents may not be construed as doing so.
Copyrights
This document is copyrighted by the IEEE. It is made available for a wide variety of both public and privateuses. These include both use, by reference, in laws and regulations, and use in private self-regulation,standardization, and the promotion of engineering practices and methods. By making this documentavailable for use and adoption by public authorities and private users, the IEEE does not waive any rights incopyright to this document.
Updating of IEEE documents
Users of IEEE standards should be aware that these documents may be superseded at any time by theissuance of new editions or may be amended from time to time through the issuance of amendments,corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of thedocument together with any amendments, corrigenda, or errata then in effect. In order to determine whethera given document is the current edition and whether it has been amended through the issuance ofamendments, corrigenda, or errata, visit the IEEE Standards Association website at http://ieeexplore.ieee.org/xpl/standards.jsp, or contact the IEEE at the address listed previously.
For more information about the IEEE Standards Association or the IEEE standards development process,visit the IEEE-SA website at http://standards.ieee.org.
iv Copyright © 2009 IEEE. All rights reserved.
Errata
Errata, if any, for this and all other standards can be accessed at the following URL: http://standards.ieee.org/reading/ieee/updates/errata/index.html. Users are encouraged to check this URL forerrata periodically.
Interpretations
Current interpretations can be accessed at the following URL: http://standards.ieee.org/reading/ieee/interp/index.html.
Patents
Attention is called to the possibility that implementation of this standard may require use of subject mattercovered by patent rights. By publication of this standard no position is taken with respect to the existence orvalidity of any patent rights in connection therewith. The IEEE is not responsible for identifying EssentialPatent Claims for which a license may be required, for conducting inquiries into the legal validity or scopeof Patents Claims or determining whether any licensing terms or conditions provided in connection withsubmission of a Letter of Assurance, if any, or in any licensing agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that determination of the validity of any patentrights, and the risk of infringement of such rights, is entirely their own responsibility. Further informationmay be obtained from the IEEE Standards Association.
Copyright © 2009 IEEE. All rights reserved. v
ParticipantsThis document was developed by the IEEE 802.16 Working Group on Broadband Wireless Access, which develops the WirelessMAN® Standard for Wireless Metropolitan Area Networks.
IEEE 802.16 Working Group OfficersRoger B. Marks, Chair
Jose Puthenkulam, Vice ChairPeiying Zhu, Secretary
Primary development was carried out by the Working Group’s Relay Task Group.
Relay TG OfficersMitsuo Nohara, Chair
Peiying Zhu, Vice ChairMike Hart, Technical Editor
Jung Je Son, Technical Editor
The following members of the IEEE 802.16 Working Group on Broadband Wireless Access participated in the Working Group Letter Ballot in which the draft of this standard was prepared and finalized for IEEE Ballot:
Ray Abrishami Edward AgisSassan AhmadiDong Hyun AhnJunBae Ahn Dov AndelmanReza ArefiPhillip BarberKevin BaumAdrian Boariu Eckard BogenfeldAchim BrandtDale BranlundTerri Brooks Sean CaiJames Carlo Jaesun ChaSuchang ChaeJae Hwan ChangSungcheol Chang Remi ChayerDavid ChenWei-Peng ChenPaul ChengAik Chindapol Hua (Mary) Chion Jaehee ChoJaeweon ChoKihyoung ChoMyeon-Gyun ChoHokyu Choi Hyoung-Jin Choi Hyung-Nam ChoiIn-Kyeong ChoiJinsoo ChoiJoonyoung ChoiYang-Seok Choi Yong-Hoon Choi Chie Ming ChouJoey Chou Jerry Chow
Jimmy ChuiTakafumi ChujoJin Young Chun Young-Uk ChungErik Colban David Comstock Jose CostaSteven CrowleyMark Cudak George CummingsPranav Dayal Carlos De SegoviaUpkar DhaliwalYoshiharu Doi Lester EastwoodCarl EklundPer Elmdahl Michael ErlihsonYu-Chang Eun Torsten Fahldieck Peretz Feder Shulan FengMo-Han FongAvraham Freedman I-Kang FuDan GalPieter-Paul Giesberts Rob GlassfordMariana GoldhamerReza GolshanDavid GrandblaiseDaqing GuZion Hadad GeneBeck HahnShkumbin Hamiti Jung Ho Han Seishi HanaokaKeisuke Higuchi Minnie HoChang-Lung HsiaoChing-Tarng Hsieh
Yu-Tao HsiehHsien-Tsung HsuYuan-Ying Hsu Teck HuCancan HuangJunhong HuiJohn HumbertYerang Hur In Seok Hwang Bin-Chul IhmTetsu Ikeda Tetsushi IkegamiJaehyuk JangKlutto Milleth Jeniston Deviraj Hyung Joon Jeon Moo Ryong JeongSunggeun Jin Brian JohnsonKerstin JohnssonDavid JohnstonPanyuh JooYoung-Ho JungTakeo Kanai Hyunjeong KangSeung Hyun KangOfer Kelman Brian Kiernan Bong Ho KimChangkyoon Kim Hyung Kee Kim Kyeongsoo KimRonny (Yong-Ho) KimSang Youb KimSungkyung KimYoung Kyun Kim Young-Il Kim Young-jae KimYoungho KimTakaaki KishigamiItzik KitroserAli Koc
vi
Copyrig ht © 2009 IEEE. All rights reserved.
Changhoi Koo Havish KoorapatyThanasis Korakis Gokhan Korkmaz Toshiyuki KuzeByung-Jae Kwak Jin Sam Kwak Dong Seung KwonYeong-Hyeon Kwon Jonathan Labs Pierre LamoureuxHyun LeeHyunjeong Lee Jin LeeKi-Dong LeeKyu Ha LeeMi Hyun LeeSang-Ho Lee Seung Joon Lee Sukwoo LeeWookbong Lee Yong Su LeeYoun-Tai LeeYung-Ting Lee Matty Levanda Guangjie LiJiang Li Jun Li Richard LiShaohua Li Thomas LiAeri LimGeunhwi Lim Hyoung Kyu Lim Kwangjae LimTzu-Ming LinZhibin Lin Stefan LindgrenHang Liu Michael LivschitzTitus LoKanchei Loa Jianmin LuYanling LuMichael Lynch Mohammad MadihianDavid MaezGiovanni Maggi Shashikant Maheshwari Ronald MaoDjamal-Eddine Meddour Scott MigaldiChan Ho Min Shantidev Mohanty Andreas MolischJames MollenauerOllivier Mont-Reynaud Sungho MoonWillem Mulder Yukimasa Nagai Ayman NaguibKenichi Nakamura
Michiharu Nakamura Eric NjedjouMinseok Noh John NorinPaul Odlyzko Changyoon Oh Min-Seok OhMasato Okuda Kim Olszewski Philip OrlikDavid ParanchychD. S. Park Jeongho ParkVijay Patel Roger PetersonPaul PigginRobert Popoli Darcy Poulin Scott ProbascoXin Qi Nanjian (Jeff) QianFei Qin Hongyun Qu Arvind RaghavanShyamal Ramachandran Ranga K. Reddy Fang-Ching RenMaximilian Riegel Kwanhee Roh Won Il RohZhigang RongAdel RouzPhilip RubinHerbert Ruck Kiseon RyuAryan SaedYousuf Saifullah Kenji SaitoSumeet SandhuIoannis SarrisJoerg Schaepperle Gary SchlangerGamini Senarath Jigar Shah Zheng ShangAriel Sharon Wern-Ho Sheen Peretz ShekalimGang ShenMatthew Sherman Jaejeong (Brian) ShimD. J. Shyy James SimkinsKathiravetpillai SivanesanSten SjobergJung Je Son Yeongmoon SonTing-Chen (Tom) Song Young Seog Song Roshni SrinivasanKenneth Stanwood
David Steer Aram SukiasyanSheng Sun Yong Sun Jaroslaw J. SydirJohn SydorMineo Takai Yukihiro TakataniPek Yew Tan Jeffrey Tao Rakesh TaoriShawn Taylor Koon Hoo Teo Timothy ThomeWen Tong Arnaud TonnerreShiau-He TsaiRainer Ullmann David UrbanSunil VadgamaLucia ValbonesiRichard van Leeuwen Rath VannithambyMuthaiah VenkatachalamDorin ViorelEugene VisotskyFrederick VookArthur Wang Guo Qiang WangLei Wang Michael Wang Shu-Shaw WangStanley Wang Yanhong WangFujio WatanabeAlfred Wieczorek Geng Wu Xuyong WuYingzhe Wu David XiangChengjie XieHua XuLing Xu Akiyoshi YagiJen-Shun Yang Rongzhen YangXiangying YangYunsong Yang Vladimir Yanover Hua-Chiang YinHujun Yin Chulsik Yoon Aeran YounJungnam Yun Sangboh Yun Masaaki YuzaJinyun ZhangKaibin Zhang Hongming ZhengHua Zhou Yuefeng Zhou Chenxi Zhu
Copyright © 2009 IEEE. All rights reserved
. vii
The following members of the individual balloting committee voted on this standard. Balloters may have voted for approval, disapproval, or abstention.
Osama Aboulmagd Iwan Adhicandra Thomas Alexander Butch Anton Danilo Antonelli Youngkyo Baek Israfil Bahceci Mohammad Baligh Phillip Barber Parag Bhatt Harry Bims Gennaro Boggia Adrian Boyer Nancy S. Bravin William Byrd Sean Cai Jing Cao Juan Carreon Wei-Peng Chen Yung-Mu Chen Aik Chindapol Jaeweon Cho Hokyu Choi Keith Chow Takafumi Chujo Kevin Coggins Erik Colban Charles Cook Todor Cooklev Jose Costa Russell Dietz Thomas Dineen Carlo Donati Carl Eklund Darwin Engwer Shulan Feng C. Fitzgerald Mo-Han Fong Andre Fournier Prince Francis Avraham Freedman Devon Gayle Michael Geipel Pieter-Paul Giesberts Wee Goh Mariana Goldhamer Sergiu Goma Randall Groves C. GuyMike Hart Robert F. Heile Yerang Hur Tetsushi Ikegami Atsushi Ito
Raj Jain Jaehyuk Jang Junghoon Jee Shinkyo Kaku Hyun Jeong Kang Piotr Karocki Stuart J. Kerry Eunkyung Kim Sang Youb Kim Yongbum Kim Young-Il Kim Itzik Kitroser Jeremy Landt Kyu Ha Lee Mi Hyun Lee Sungjin Lee Li LiJan-Ray Liao Arthur Light Chiwoo Lim Hyoung-Kyu Lim Kanchei Loa Daniel Lubar G. LuriMichael Lynch Jianglei Ma Syam Madanapalli Roger B. Marks Jon Martens Peter Martini Craig Matsuno W. Kyle Maus Sean Mcbeath Steven Methley Gary Michel Wade Midkiff Apurva Mody Jose Morales Ronald G. Murias Michael S. Newman Richard Noens Mitsuo Nohara John Notor Robert Novak Satoshi Obara Satoshi Oyama David Paranchych Jeongho Park Sung-Eun Park David Pechner Paul Piggin Riku Pirhonen Subburajan Ponnuswamy Venkatesha Prasad Michael Probasco
Arvind Raghavan Maximilian Riegel Robert Robinson Won Il Roh Herbert Ruck Randall Safier John Sargent Shigenobu Sasaki Bartien Sayogo Ernest Seagraves Nimal Senarath Jaejeong (Brian) Shim Shusaku Shimada Kathiravetpillai Sivanesan Sten Sjoberg Jung Je Son Yeongmoon Son Yi Song Amjad Soomro Kenneth Stanwood Thomas Starai David Steer Walter Struppler Alourdes Sully Sheng Sun Zhifeng Tao Rakesh Taori Lai King Anna Tee Wen Tong Mark-Rene Uchida Rainer T. Ullmann Sunil Vadgama Dmitri Varsanofiev Prabodh Varshney Sophie Vrzic Nico Waes Guo Qiang Wang Lei Wang Michael Wang Stanley Wang Chris Williams Geng Wu Xuyong Wu Hua-Chiang Yin Derek Yu Dongsheng Yu Hyunkyu Yu Jun Yuan Jungnam Yun Hang Zhang Hua Zhou Chenxi Zhu Peiying Zhu Wenhao Zhu
viii
Copyri ght © 2009 IEEE. All rights reserved.
When the IEEE-SA Standards Board approved this standard on 13 May 2009, it had the following membership:
Robert M. Grow, ChairSteve M. Mills, Past Chair
Thomas Prevost, Vice ChairJudith Gorman, Secretary
*Member Emeritus
Also included are the following nonvoting IEEE-SA Standards Board liaisons:
Satish K. Aggarwal, NRC RepresentativeMichael Janezic, NIST RepresentativeHoward Wolfman, TAB Representative
Lisa PerryIEEE Standards Project Editor
Michael D. KipnessIEEE Standards Program Manager, Technical Program Development
John BarrKaren BartlesonVictor BermanTed BurseRichard DeBlasioAndy DrozdMark Epstein
Alexander GelmanJim HughesRich HulettYoung Kyun KimJoseph L. Koepfinger*John KulickDavid Law
Ted OlsenGlenn ParsonsRon PetersenThomas PrevostNarayanan RamachandranJon RosdahlSam Sciacca
C
opyright © 2009 IEEE. All rights reserved. ix
Contents
1. Overview.............................................................................................................................................. 2
1.1 Scope............................................................................................................................................ 21.2 Purpose......................................................................................................................................... 2
1.3.4 Air interface nomenclature and compliance .................................................................... 21.6 Multihop relay.............................................................................................................................. 2
3. Definitions ........................................................................................................................................... 3
4. Abbreviations and acronyms ............................................................................................................... 5
6. MAC common part sublayer................................................................................................................ 6
6.3 Data/Control plane....................................................................................................................... 66.3.1 Addressing and connections ............................................................................................ 6
6.3.1.1 Point-to-multipoint (PMP)............................................................................... 66.3.1.2 Multihop relay.................................................................................................. 6
6.3.2 MAC PDU formats .......................................................................................................... 76.3.2.1 MAC header formats ....................................................................................... 76.3.2.2 MAC subheaders and special payloads ......................................................... 226.3.2.3 MAC management messages......................................................................... 24
6.3.3 Construction and transmission of MAC PDUs.............................................................. 816.3.3.2 Concatenation ................................................................................................ 816.3.3.8 MR construction and transmission of MAC PDUs ....................................... 81
6.3.4 ARQ mechanism............................................................................................................ 846.3.4.6 ARQ operation............................................................................................... 86
6.3.5 Scheduling services........................................................................................................ 896.3.5.2 UL request/grant scheduling .......................................................................... 89
6.3.6 Bandwidth allocation and request mechanisms ............................................................. 896.3.6.1 Requests ......................................................................................................... 896.3.6.2 Grants............................................................................................................. 916.3.6.3 Polling............................................................................................................ 936.3.6.5 Contention-based CDMA BRs for WirelessMAN-OFDMA......................... 946.3.6.6 CDMA BRs in relay networks....................................................................... 956.3.6.7 Dedicated relay uplink channel allocation..................................................... 966.3.6.8 Downlink flow control for relay networks with distributed scheduling........ 97
6.3.7 MAC support of PHY .................................................................................................. 1006.3.7.3 DL-MAP message........................................................................................ 1006.3.7.4 UL-MAP message........................................................................................ 1016.3.7.7 R-MAP......................................................................................................... 101
6.3.9 Network entry and initialization .................................................................................. 1016.3.9.1 Scanning and synchronization to the DL..................................................... 1036.3.9.2 Obtain DL parameters.................................................................................. 1036.3.9.9 Registration.................................................................................................. 1046.3.9.15 RS neighbor station measurement report..................................................... 1066.3.9.16 Second stage access station selection .......................................................... 1076.3.9.17 Path creation and tunnel establishment........................................................ 1096.3.9.18 RS operation parameters configuration ....................................................... 1096.3.9.19 Network entry state machine for the MR system ........................................ 112
6.3.10 Ranging ........................................................................................................................ 1146.3.10.3 OFDMA-based ranging ............................................................................... 114
6.3.14 Quality of service (QoS) .............................................................................................. 132
Copyright © 2009 IEEE. All rights reserved. xi
6.3.14.2 Service flows................................................................................................ 1326.3.14.9 Service flow management............................................................................ 1326.3.14.10 QoS support for tunnel mode operation....................................................... 138
6.3.16 MAC support for HARQ ............................................................................................. 1396.3.16.4 DL HARQ in MR systems with RSs operating in centralized
scheduling mode .......................................................................................... 1396.3.16.5 UL HARQ in MR systems with RSs operating in centralized
scheduling mode .......................................................................................... 1476.3.16.6 HARQ for multihop scheduling RSs ........................................................... 1496.3.16.7 HARQ for an RS group ............................................................................... 1496.3.16.8 HARQ support on RS UL_DCH ................................................................. 153
6.3.20 Sleep mode for mobility-supporting MS ..................................................................... 1536.3.20.10 MS sleep mode support in MR systems....................................................... 153
6.3.21 MAC HO procedures ................................................................................................... 1546.3.21.1 Network topology acquisition...................................................................... 1546.3.21.2 HO process................................................................................................... 1566.3.21.4 Mobile relay station handover ..................................................................... 160
6.3.22 Multicast and broadcast services (MBS) ..................................................................... 1646.3.22.5 MBS in an MR network............................................................................... 164
6.3.23 MS idle mode (optional) .............................................................................................. 1656.3.23.1 MS idle mode initiation ............................................................................... 1656.3.23.5 MS paging listening interval........................................................................ 1656.3.23.6 BS Broadcast paging message ..................................................................... 1666.3.23.9 Network reentry from idle mode ................................................................. 1676.3.23.10 MRS paging group update ........................................................................... 167
6.3.28 Relay path management and routing ........................................................................... 1686.3.28.1 Embedded path management for relay ........................................................ 1686.3.28.2 Explicit path management for relay............................................................. 1696.3.28.3 Relaying support for combined ranging and initial topology discovery ..... 1716.3.28.4 R-link monitoring and reporting procedure for relay path management ..... 1716.3.28.5 Path management for multicast services...................................................... 1726.3.28.6 Neighbor path metric for relay..................................................................... 172
6.3.29 Relay station neighborhood discovery......................................................................... 1726.3.29.1 Repeatable R-amble transmission and monitoring scheme ......................... 1736.3.29.2 Pre-planned R-amble transmission and monitoring scheme........................ 173
6.3.30 Interference measurement in MR systems................................................................... 1746.3.30.1 Interference prediction by RS neighborhood measurement ........................ 1746.3.30.2 Optional interference detection and measurement by RS sounding ............ 174
6.3.31 RS broadcast message relaying.................................................................................... 1756.3.32 RS de-registration ........................................................................................................ 1776.3.33 MR location information ............................................................................................. 1776.3.34 RS grouping ................................................................................................................. 179
6.3.34.1 MS movement among access stations that share the same BSID................ 181
7. Security sublayer.............................................................................................................................. 182
7.1 Architecture ............................................................................................................................. 1827.1.6 Centralized Security Control in Multihop Relay System ............................................ 182
7.1.6.1 MS security control...................................................................................... 1827.1.6.2 RS security control....................................................................................... 1827.1.6.3 Protection of non-authenticated PKM messages ......................................... 182
7.1.7 Distributed security control in a multihop relay system .............................................. 1837.1.7.1 Protection of SS’s management messages................................................... 1837.1.7.2 Sharing HMAC/CMAC in management tunnel........................................... 183
xii Copyright © 2009 IEEE. All rights reserved.
7.1.8 Security zone management .......................................................................................... 1847.2 PKM protocol .......................................................................................................................... 184
7.2.2 PKM Version 2 ............................................................................................................ 1847.2.2.2 Key derivation.............................................................................................. 1847.2.2.3 Associations ................................................................................................. 1857.2.2.4 Security context ........................................................................................... 1857.2.2.7 AK transfer .................................................................................................. 186
7.4 Key usage................................................................................................................................. 1877.4.3 Security zone keys usage ............................................................................................. 187
7.4.3.1 SZK usage.................................................................................................... 1877.4.3.2 SZKEK usage .............................................................................................. 187
7.5 Cryptographic methods............................................................................................................ 1877.5.1 Data Encryption methods............................................................................................. 187
7.5.1.2 Data encryption with AES in CCM mode ................................................... 1877.5.2 Encryption of TEK....................................................................................................... 188
7.5.2.5 Encryption of AK with AES key wrap ........................................................ 1887.5.2.6 Security zone keys encryption ..................................................................... 188
7.5.4 Derivation of TEKs, KEKs, and message authentication keys.................................... 1887.5.4.4 Cipher-based MAC ...................................................................................... 188
7.5.7 Calculation of HMAC/CMAC digests in a security zone............................................ 1897.8 PKMv2..................................................................................................................................... 189
7.8.1 PKMv2 SA-TEK 3-way handshake............................................................................. 1897.8.1.1 PKMv2 SA-TEK-Response for RS ............................................................. 189
7.8.4 Relay multicast rekeying algorithm............................................................................. 1897.8.4.1 MRS rekeying algorithm ............................................................................. 192
8. Physical layer (PHY) ....................................................................................................................... 192
8.4 WirelessMAN-OFDMA PHY ................................................................................................. 1928.4.4 Frame structure ............................................................................................................ 192
8.4.4.6 UL transmission allocations......................................................................... 1928.4.4.8 TDD frame structure of MR-BS and RS ..................................................... 1928.4.4.9 R-FCH channel ............................................................................................ 2008.4.4.10 R-Zone prefix............................................................................................... 2018.4.4.11 FDD frame structure of MR-BS and RS...................................................... 203
8.4.5 Map message fields and IEs......................................................................................... 2048.4.5.3 DL-MAP IE format...................................................................................... 2048.4.5.4 UL-MAP IE format...................................................................................... 2108.4.5.10 R-MAP message .......................................................................................... 216
8.4.6 OFDMA subcarrier allocations.................................................................................... 2318.4.6.1 Downlink (DL) ............................................................................................ 231
8.4.7 OFDMA ranging.......................................................................................................... 2348.4.7.5 OFDMA ranging in an MR system.............................................................. 234
8.4.8 Space-Time Coding(STC) (optional)........................................................................... 2348.4.8.1 STC using two antennas .............................................................................. 2348.4.8.8 Cooperative relaying.................................................................................... 235
8.4.9 Channel coding ............................................................................................................ 2368.4.10 Control mechanisms .................................................................................................... 237
8.4.10.4 Power control in MR networks.................................................................... 2378.4.12 Channel quality measurements .................................................................................... 237
8.4.12.5 Channel quality measuring and reporting in an MR system........................ 2378.4.16 Optional HARQ support .............................................................................................. 238
8.4.16.3 UL ACK channel ......................................................................................... 238
Copyright © 2009 IEEE. All rights reserved. xiii
9. Configuration ................................................................................................................................... 239
9.5 RS configuration ...................................................................................................................... 239
10. Parameters and constants ................................................................................................................. 239
10.1 Global values ........................................................................................................................... 23910.4 Well-known addresses and identifiers ..................................................................................... 241
11. TLV Encodings................................................................................................................................ 242
11.1 Common encodings ................................................................................................................. 24211.1.2 Authentication tuples ................................................................................................... 242
11.1.2.1 HMAC tuple ................................................................................................ 24211.1.2.2 CMAC tuple................................................................................................. 24311.1.2.3 Short-HMAC Tuple ..................................................................................... 244
11.1.3 MAC version encoding................................................................................................ 24411.1.4 Service flow descriptors............................................................................................... 24511.1.13 Path management message encodings ....................................................................... 245
11.1.13.1 Path ID encoding...................................................................................... 24511.1.13.2 Path Addition TLV................................................................................... 24511.1.13.3 Path CID Binding Update TLV................................................................ 24611.1.13.4 Path Info TLV .......................................................................................... 246
11.1.14 SA_SZK_Update tuple .............................................................................................. 24611.1.15 DCD and UCD contents ............................................................................................ 247
11.3 UCD management message encodings ................................................................................. 24811.4 DCD management message encodings ................................................................................. 24811.6 RNG-RSP message encodings .............................................................................................. 249
11.6.1 CID list......................................................................................................................... 25011.7 REG-REQ/RSP management message encodings ................................................................ 250
11.7.25 MR-BS and RS MAC feature support ..................................................................... 25011.7.25.1 RS MAC feature support.................................................................................... 25111.7.25.2 MR MAC header and extended subheader support ........................................... 251
11.8 SBC-REQ/RSP management message encodings ................................................................ 25211.8.3 Physical parameters supported................................................................................ 252
11.8.3.5 WirelessMAN-OFDMA specific parameters...................................................... 25211.8.17 Relay data early arrival report threshold................................................................. 25711.8.18 RS downlink processing delay................................................................................ 25811.8.19 Minimum RS forwarding delay in direct relay zone TLV...................................... 25811.8.20 Minimum RS forwarding delay TLV...................................................................... 25911.8.21 Station information ................................................................................................. 259
11.9 PKM-REQ/RSP management message encodings ............................................................... 25911.9.40 AK-Parameters ....................................................................................................... 25911.9.41 SZK-Parameters ..................................................................................................... 26011.9.42 SZKEK-Parameters ................................................................................................ 260
11.11 REP-REQ management message encodings......................................................................... 26111.12 REP-RSP management message encodings.......................................................................... 26211.13 Service flow management encodings.................................................................................... 263
11.13.1 SFID ........................................................................................................................ 26311.13.2 CID .......................................................................................................................... 26411.13.4 QoS parameter set type............................................................................................ 26411.13.34 PDU SN extended subheader for HARQ reordering............................................... 26411.13.43 Per-RS QoS ............................................................................................................. 26511.13.44 CIDs added into tunnel TLV................................................................................... 265
xiv Copyright © 2009 IEEE. All rights reserved.
11.13.45 CIDs removed from tunnel TLV............................................................................. 26611.15 HO management encodings .................................................................................................. 266
11.15.4 Preamble index .......................................................................................................... 26611.17 MOB_PAG-ADV management message encodings ............................................................ 266
11.17.3 RS transmit frame number ......................................................................................... 26611.17.4 Paging interval ........................................................................................................... 267
11.22 RS_NBR_MEAS-REP message encoding ........................................................................... 26711.22.1 Preamble index with least signal strength.................................................................. 267
11.23 MR_NBR-INFO management message encoding ................................................................ 26711.24 R-link channel descriptor (RCD) TLV encoding .................................................................. 268
11.24.1 Generic channel description ...................................................................................... 26811.24.2 Reserved preamble indexes for mobile relay station ................................................. 26911.24.3 Preamble reselection thresholds for mobile relay station .......................................... 269
11.25 RS_Config-CMD message TLV encoding ........................................................................... 27011.25.1 Generic configuration................................................................................................ 27011.25.2 MBS configuration .................................................................................................... 27211.25.3 Cooperative diversity configuration .......................................................................... 27211.25.4 Local CID allocation configuration........................................................................... 27311.25.5 RS group configuration ............................................................................................. 274
11.25.5.1 Mode-1....................................................................................................... 27411.25.5.2 Mode-2....................................................................................................... 275
11.25.6 RS paging group......................................................................................................... 27611.25.7 Frame configuration mode ......................................................................................... 27611.25.8 R-amble transmission and monitoring configuration................................................. 276
11.25.8.1 MR-BS centralized control mode.............................................................. 27611.25.8.2 RS autonomous control mode ................................................................... 27711.25.8.3 R-amble measurement report .................................................................... 279
11.25.9 Multiple frame structure configurations .................................................................. 27911.25.10 Direct relay zone configuration ............................................................................... 28211.25.11 RS UL access link configuration ............................................................................. 28311.25.12 Non-transparent RS operating in centralized scheduling mode .............................. 28311.25.13 STR RS configuration ............................................................................................. 284
11.26 MS_Context-REQ/RSP management message encodings.................................................... 28511.27 Location information request and response (MR_LOC-REQ/RSP) messages encodings.... 286
11.27.1 The position of the RS............................................................................................... 28611.27.2 Positions of neighbor stations.................................................................................... 28711.27.3 Report period ............................................................................................................. 28711.27.4 BSIDs of neighbor stations........................................................................................ 288
12. System profiles ................................................................................................................................ 288
12.4 Fixed WirelessMAN-OFDMA .............................................................................................. 28812.4.3 WirelessMAN-OFDMA and WirelessHUMAN(-OFDMA) System PHY ................. 288
12.4.3.1 Common features of PHY profiles .............................................................. 288
Annex A (informative) Bibliography .......................................................................................................... 289
Annex P (informative) QoS parameters for a tunnel ................................................................................... 290
Copyright © 2009 IEEE. All rights reserved. xv
List of figures
Figure 21a—Relay MAC PDU format ............................................................................................................ 7Figure 23a—Header format of relay MAC PDU with payload....................................................................... 8Figure 34a—Extended MAC signaling header type II format ...................................................................... 13Figure 34b—RS BR header format ............................................................................................................... 14Figure 34c—RS UL_DCH signaling header format...................................................................................... 15Figure 34d—MR Acknowledgement header format ..................................................................................... 17Figure 34e—MR HARQ error report header format ..................................................................................... 18Figure 34f—MR Code-REP header format ................................................................................................... 19Figure 34g—Tunnel BR header format ......................................................................................................... 20Figure 34h—DL flow control header format................................................................................................. 21Figure 47a—Example of fragmentation and packing of relay MAC PDUs.................................................. 84Figure 52a—ARQ Tx block state in MR-BS................................................................................................. 88Figure 52b—Reducing latency in relaying traffic by transmitting BW request header
on R-UL before packets arrive.................................................................................................. 91Figure 52c—Periodic bandwidth grant with RS scheduling information...................................................... 92Figure 55a—Reducing latency in relaying traffic via RS polling ................................................................. 93Figure 55b—Periodic polling with RS scheduling information .................................................................... 94Figure 55c—BW request/allocation signaling for an RS in centralized scheduling mode ........................... 95Figure 55d—Sample topology for illustrating the use of DL Flow Control Header ..................................... 99Figure 55e—Example DL flow control message sequence—Superordinate RS handles flow
control locally ........................................................................................................................... 99Figure 55f—Example DL flow control message sequence—Superordinate RS requests flow control
from MR-BS ........................................................................................................................... 100Figure 65a—RS initialization overview ...................................................................................................... 102Figure 84a—Handling REG-RSP first reception at an RS .......................................................................... 104Figure 84b—Handling REG-REQ first reception from RS at an MR-BS................................................... 104Figure 84c—Handling REG-REQ first reception at an RS operating in distributed security and local
CID allocation mode .............................................................................................................. 105Figure 84d—Handling REG-REQ at a MR-BS with subordinate RS operating in local CID
allocation mode...................................................................................................................... 106Figure 86a—Perform neighbor measurement report at a RS ...................................................................... 107Figure 86b—Handling RS_NBR_MEAS-REP first reception at an MR-BS.............................................. 107Figure 86c—Handling RS_AccessRS-REQ first reception at an RS .......................................................... 108Figure 86d—Perform access station selection at an MR-BS....................................................................... 108Figure 86e—Handling RS_NBR_MEAS-REP retransmission at an MR-BS ............................................. 108Figure 86f—Handling RS_Config-CMD first reception at an RS .............................................................. 110Figure 86g—Handling RS_Config-CMD retransmission at an RS............................................................. 110Figure 86h—Configure operation parameters to an RS at an MR-BS ........................................................ 111Figure 86i—Obtaining and maintaining synchronization with R-MAP at an RS ....................................... 111Figure 86j—Network entry state machine at a MR-BS............................................................................... 112Figure 86k—Network entry state machine at an RS ................................................................................... 113Figure 99a—Handling CDMA ranging code at a transparent RS ............................................................... 122Figure 99b—Handling CDMA ranging code or MR_RNG-REP message at a scheduling station ............ 122Figure 99c—Handling RNG-REQ at a transparent RS ............................................................................... 123Figure 99d—Handling CDMA ranging code or MR_RNG-REP message at a superordinate RS with
unique BSID operating in centralized scheduling mode (part 1)........................................... 123Figure 99e—Handling CDMA ranging code or MR_RNG-REP message at a superordinated RS with
unique BSID operating in centralized scheduling (part 2) .................................................... 124Figure 99f—Handling CDMA ranging code or MR_RNG-REP message at a superordinated RS with
unique BSID operating in centralized scheduling (part 3) .................................................... 124Figure 99g—Handling CDMA ranging code at a non-transparent RS with unique BSID in centralized
scheduling mode (part 1) ..................................................................................................... 125
Copyright © 2009 IEEE. All rights reserved. xvii
Figure 99h—Handling CDMA ranging code at a non-transparent RS with unique BSID in centralized scheduling mode (part 2) ....................................................................................................... 125
Figure 99i—Handling RS_BR header at an MR-BS ................................................................................... 126Figure 99j—Handling MR_Code-REP header at the MR-BS..................................................................... 126Figure 99k—Handling RNG-REQ at a non-transparent RS with a unique BSID except local CID
allocation mode...................................................................................................................... 126Figure 102a—SS upstream transmission adjustment at a non-transparent RS with unique BSID in
centralized scheduling mode.................................................................................................. 131Figure 102b—SS upstream transmission adjustment at a transparent RS performing uplink..................... 131Figure 102c—Handling MR_RNG-REP with Report Type = 1 at an MR-BS ........................................... 131Figure 140a—Example of Initial transmission of HARQ burst .................................................................. 142Figure 140b—Example of initial transmission and retransmission of HARQ burst ................................... 143Figure 140c—Example of DL HARQ operation for a tunnel ..................................................................... 145Figure 140d—HARQ operation for non-transparent RS group................................................................... 150Figure 149a—Serving station initiated transfer (Intra-MR) ........................................................................ 158Figure 149b—Serving station initiated transfer (Inter-MR)........................................................................ 158Figure 149c—Target station initiated transfer (Intra-MR) .......................................................................... 159Figure 149d—Target station initiated transfer (Inter-MR).......................................................................... 159Figure 150a—MRS HO process .................................................................................................................. 161Figure 154a—CID range allocation example, (a) contiguous integer block, (b) bit partition method........ 169Figure 154b—R-amble transmission pattern as per the pre-planned scheme instructed by MR-BS .......... 173Figure 154c—Relaying DCD/UCD procedure............................................................................................ 176Figure 154d—DCD/UCD broadcasting procedure with an RS operating in centralized scheduling
mode....................................................................................................................................... 176Figure 154e—Relay location report (part 1)................................................................................................ 178Figure 154f—Relay location report (part 2) ................................................................................................ 178Figure 154g—Relay location report (part 3) ............................................................................................... 179Figure 174a—Relay multicast rekeying algorithm...................................................................................... 191Figure 234a—Example of configuration for a transparent relay frame structure........................................ 194Figure 234b—Example of configuration for a transparent relay frame structure: MR-BS and RS have
partitioned UL subframe in the frequency domain ............................................................... 195Figure 234c—Example of minimum configuration for a non-transparent TTR relay frame structure ....... 197Figure 234d—Example of configuration for non-transparent TTR relay frame structure;
MR-BS and RS have partitioned the UL subframe in the frequency domain ...................... 198Figure 234e—Example of minimum configuration for a STR relay frame structure coexisting with
TTR RS in TDD mode.......................................................................................................... 200Figure 245a—An example implementation of the alternate R-amble transmission monitoring scheme
for synchronization, N = 4 and Ks = 2.................................................................................. 233Figure 245b—An example implementation of the combined scheme for neighborhood monitoring and
synchronization, N = 4, L =8, Ks = 2, Km = 3 ..................................................................... 234Figure 263a—Mapping of data subcarriers for 3-antenna RS ..................................................................... 235Figure 263b—Mapping of data subcarriers for 4-antenna RS..................................................................... 235Figure 282a—A logical block example of local STC Encoding at RS ....................................................... 236
xviii Copyright © 2009 IEEE. All rights reserved.
List of tables
Table 1—Air interface variant nomenclature and compliance ........................................................................ 2Table 6a—Description of relay MAC header fields ........................................................................................ 8Table 15—Type field encodings for MAC signaling header type II ............................................................... 9Table 17—Feedback type and feedback content ........................................................................................... 10Table 18a—3 bit differential fast feedback encoding per differential CQI report
with seven levels of quantization............................................................................................... 12Table 18b—2 bit differential feedback encoding per differential CQI report
with three levels of quantization ................................................................................................ 12Table 18c—Extended Type field encodings for extended MAC signaling header type II............................ 13Table 18d—Description of fields in RS BR header ...................................................................................... 14Table 18e—Description of fields in RS UL_DCH signaling header............................................................. 15Table 18f—Description of fields in MR acknowledgement header .............................................................. 17Table 18g—Description of fields in MR HARQ error report header............................................................ 18Table 18h—Description of fields in MR Code-REP header ......................................................................... 19Table 18i—Description of fields in Tunnel BR header ................................................................................. 20Table 18j—Description of fields in DL Flow Control header....................................................................... 21Table 37a—QoS subheader format................................................................................................................ 22Table 37b—Allocation subheader format...................................................................................................... 23Table 37c—Fragmentation subheader format ............................................................................................... 23Table 37d—Packing subheader format.......................................................................................................... 24Table 38—MAC management messages....................................................................................................... 24Table 44—RNG-RSP message format .......................................................................................................... 26Table 50—PKM message codes .................................................................................................................... 27Table 75—PKMv2 Group-Key-Update-Command message attributes ........................................................ 28Table 78a—PKMv2 AK Transfer message ................................................................................................... 28Table 78b—PKMv2 AK Transfer ACK........................................................................................................ 29Table 96—Action codes and actions ............................................................................................................. 36Table 154—MOB_PAG-ADV message format ............................................................................................ 37Table 166a—R-link channel descriptor (RCD) message format................................................................... 38Table 166b—MR_NBR-INFO message format ............................................................................................ 39Table 166c—MR Ranging report (MR_RNG-REP) message format ........................................................... 44Table 166d—RS configuration command (RS_Config-CMD) message format........................................... 46Table 166e—RS_NBR_MEAS-REP message format .................................................................................. 49Table 166f—MR_LOC-REQ message format .............................................................................................. 50Table 166g—MR_LOC-RSP message format .............................................................................................. 51Table 166h—MS_SCN-INF message format................................................................................................ 52Table 166i—MS_SCN-CLT message format................................................................................................ 53Table 166j—MS_INFO-DEL message format.............................................................................................. 54Table 166k—CLK-SYNC message format ................................................................................................... 54Table 166l—MR_ASC-REQ message format............................................................................................... 55Table 166m—MR_ASC-RSP message format.............................................................................................. 56Table 166n—RS_MOB_MEAS-REQ message format................................................................................. 57Table 166o—HARQ_CHASE_ER-REP message format ............................................................................. 58Table 166p—HARQ_IR_ER-REP message format ...................................................................................... 59Table 166q—MR_SLP-INFO message format ............................................................................................. 60Table 166r—RS_AccessRS-REQ message format ....................................................................................... 63Table 166s—–RS-SCH message format........................................................................................................ 64Table 166t—RS_Member_List_Update message format.............................................................................. 65Table 166u—MR_PBBR-INFO message format .......................................................................................... 67Table 166v—MR_Generic-ACK message format ........................................................................................ 68Table 166w—RS Access MAP message format ........................................................................................... 69Table 166x—Reduced SUB-DL-UL-MAP ................................................................................................... 71
Copyright © 2009 IEEE. All rights reserved. xix
Table 166y—Reduced HARQ-MAP ............................................................................................................. 72Table 166z—DL Allocation Reference IE .................................................................................................... 73Table 166aa—RS_BW_Alloc_IE format ...................................................................................................... 73Table 166ab—DL Transmit Reference IE format ......................................................................................... 75Table 166ac—RS Relay MAP message format............................................................................................. 76Table 166ad—MOB_INF-IND message format ........................................................................................... 77Table 166ae—MS_Context-REQ message Format ....................................................................................... 78Table 166af—MS_Context-RSP message format ......................................................................................... 79Table 166ag—MT_Transfer message format................................................................................................ 80Table 170a—ARQ Feedback IE format for Tunnel packet ........................................................................... 85Table 182a—Ranging and automatic adjustment procedure in transparent mode ...................................... 117Table 182b—Ranging and automatic adjustments procedure with a non-transparent RS with unique
BSID in centralized scheduling mode ................................................................................... 118Table 182c—Ranging and automatic adjustments procedure with a scheduling RS operating in normal
CID allocation mode .............................................................................................................. 119Table 182d—Ranging and automatic adjustments procedure with a scheduling RS operating with option
to request permission from MR-BS ...................................................................................... 120Table 182e—Ranging and automatic adjustments procedure with scheduling RS operating in local CID
allocation mode...................................................................................................................... 121Table 183a—Ranging and automatic adjustment procedure with transparent RS ...................................... 128Table 183b—Ranging and automatic adjustment procedure with a non-transparent RS with unique
BSID in centralized scheduling mode ................................................................................... 129Table 183c—Ranging and automatic adjustment procedure with a scheduling RS ................................... 130Table 195a—The aggregated HARQ channel tile encoding ....................................................................... 146Table 201a—SA Identifications at multihop relay system with Distributed Security Control ................... 183Table 207a—SZK context ........................................................................................................................... 185Table 207b—SZKEK content...................................................................................................................... 186Table 318a—R-Zone_Prefix format ............................................................................................................ 201Table 318b—R-Zone_Prefix format for FFT size 128 ................................................................................ 202Table 321—OFDMA DL-MAP_IE format ................................................................................................. 205Table 328—Extended-3 DIUC code assignment for Extended-2 DIUC = 15 ............................................ 206Table 330—OFDMA STC DL Zone IE format........................................................................................... 207Table 337—HARQ, and Sub-MAP and R-MAP Pointer IE format............................................................ 208Table 375a—MR_DL-MAP MONITOR IE format .................................................................................... 209Table 375b—DL Burst Transmit IE format ................................................................................................ 210Table 378—PAPR Reduction/Safety Zone/Sounding Zone Allocation IE format ..................................... 211Table 381—Extended UIUC code assignment for UIUC = 15 ................................................................... 212Table 385—Extended-3 UIUC code assignment for Extended-2 UIUC = 05 ............................................ 212Table 426a—UL_Burst_Receive_IE format ............................................................................................... 213Table 426b—RS MIMO UL IE format ....................................................................................................... 214Table 426c—MR UL-MAP MONITOR IE format ..................................................................................... 216Table 436a—R-MAP message format......................................................................................................... 217Table 436b—R-link specific IE format ....................................................................................................... 218Table 436c—R-link specific IE types.......................................................................................................... 218Table 436d—RS_UL_DCH assignment IE format ..................................................................................... 219Table 436e—RS_UL_DCH HARQ RETX IE format................................................................................. 221Table 436f—RS HARQ DL IE format ........................................................................................................ 222Table 436g—UL relay zone configuration IE format.................................................................................. 224Table 436h—HARQ ACKCH Region allocation for Relay Data IE format............................................... 225Table 436i—MR_DL-MAP MONITOR IE format..................................................................................... 226Table 436j—MR UL-MAP MONITOR IE format...................................................................................... 227Table 436k—RS_CQICH_Control IE format ............................................................................................. 227Table 436l—Aggregated HARQ ACK region allocation IE format ........................................................... 228Table 436m—RS MIMO UL IE format ...................................................................................................... 229
xx Copyright © 2009 IEEE. All rights reserved.
Table 548a—ACK/NAK Encoding for multihop relay for HARQ, with vector indices provided in Table 548 ........................................................................................................................... 238
Table 554—Parameters and constants ......................................................................................................... 239Table 558—CIDs......................................................................................................................................... 241Table 559—Type values for common TLV encodings ............................................................................... 242Table 560—HMAC Tuple definition .......................................................................................................... 242Table 562—CMAC Tuple ........................................................................................................................... 243Table 563—CMAC Tuple definition........................................................................................................... 243Table 564—Short-HMAC Tuple ................................................................................................................. 244Table 565—Short-HMAC Tuple definition ................................................................................................ 244Table 567a—DCD encodings ...................................................................................................................... 247Table 567b—UCD encodings...................................................................................................................... 247Table 571—UCD PHY-specific channel encodings—WirelessMAN-OFDMA ........................................ 248Table 575—DCD channel encodings .......................................................................................................... 248Table 585—RNG-RSP message encodings................................................................................................. 249Table 604a—AK-Parameters definition ...................................................................................................... 259Table 604b—SZK-Parameters definition .................................................................................................... 260Table 604c—SZKEK-Parameters definition ............................................................................................... 260Table 607—CC values................................................................................................................................. 263Table 608a—CIDs added into tunnel sub-attributes.................................................................................... 265Table 608b—CIDs removed from tunnel sub-attributes ............................................................................. 266Table 616a—MS_Context-REQ/RSP message encodings.......................................................................... 285Table 616b—AK Context encodings........................................................................................................... 285Table 616c—SA Descriptor encodings ....................................................................................................... 286Table 616d—TEK parameters encodings.................................................................................................... 286Table 639—Minimum performance requirements for all profiles .............................................................. 288Table P.1—The value of aggregated QoS parameters admitted into a tunnel............................................. 290
Copyright © 2009 IEEE. All rights reserved. xxi
IEEE Standard forLocal and metropolitan area networks
Part 16: Air Interface for BroadbandWireless Access SystemsAmendment 1: Multihop Relay SpecificationIMPORTANT NOTICE: This standard is not intended to ensure safety, security, health, orenvironmental protection in all circumstances. Implementers of the standard are responsible fordetermining appropriate safety, security, environmental, and health practices or regulatory requirements.
This IEEE document is made available for use subject to important notices and legal disclaimers. Thesenotices and disclaimers appear in all publications containing this document and may be found under theheading “Important Notice” or “Important Notices and Disclaimers Concerning IEEE Documents.”They can also be obtained on request from IEEE or viewed at http://standards.ieee.org/IPR/disclaimers.html.
NOTE—The editing instructions contained in this amendment define how to merge the material containedherein into the existing base standard and its amendments to form a comprehensive standard.
The editing instructions are shown bold italic. Four editing instructions are used: change, delete, insert, andreplace. Change is used to make small corrections in existing text or tables. The editing instruction specifiesthe location of the change and describes what is being changed by either using strikethrough (to remove oldmaterial) or underscore (to add new material). Delete removes existing material. Insert adds new materialwithout disturbing the existing material. Insertions may require renumbering. If so, renumbering instructionsare given in the editing instruction. Replace is used to make large changes in existing text, subclauses,tables, or figures by removing existing material and replacing it with new material. Editorial notes will notbe carried over into future editions because the changes will be incorporated into the base standard.
Copyright © 2009 IEEE. All rights reserved. 1
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
1. Overview
1.1 Scope
1.2 Purpose
1.3.4 Air interface nomenclature and compliance
Insert the following rows in Table 1 as follows:
Insert new subclause 1.6 as follows:
1.6 Multihop relay
Multihop relay (MR) is an optional deployment that may be used to provide additional coverage or performance advantage in an access network. In MR networks, the BS may be replaced by a multihop relay BS (MR-BS) and one or more relay stations (RS).
Traffic and signaling between the SS and MR-BS are relayed by the RS thereby extending the coverage and performance of the system in areas where RSs are deployed. Each RS is under the supervision of an MR-BS. In a more than two hop system, traffic and signaling between an access RS and MR-BS may also be relayed through intermediate RSs. The RS may be fixed in location (i.e., attached to a building) or, in the case of an access RS, it may be mobile (i.e., traveling with a transportation vehicle). The SS may also communicate directly with the MR-BS.
The various MR features defined throughout this standard permit a multihop relay system to be configured in several modes.
The protocols (including the mobility features) on the access link remain unchanged. New functionality has been specified on the relay link to support the MR features.
Two different modes (centralized and distributed scheduling) are specified for controlling the allocation of bandwidths for an SS or an RS. In centralized scheduling mode, the bandwidth allocation for an RS’s subordinate stations is determined at the MR-BS; conversely in distributed scheduling mode, the bandwidth allocation of an RS’s subordinate stations is determined by the RS, in cooperation with the MR-BS.
Two different types of RS are defined, namely transparent and non-transparent. A non-transparent RS can operate in both centralized and distributed scheduling mode, while a transparent RS can only operate in centralized scheduling mode.
Table 1—Air interface variant nomenclature and compliance
Designation Applicability PHYspecification System features Duplexing
alternative
WirelessMAN-OFDMA MR
Licensed bands below 11 GHz 8.4 — TDD
2 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
A transparent RS communicates with the superordinate station and subordinate station(s) using the same carrier frequency. A non-transparent RS may communicate with the superordinate station and subordinate station(s) using the same or different carrier frequencies.
The MAC layer includes extensions to signaling to support functions such as network entry (of an RS, and of an SS through an RS), bandwidth request, forwarding of PDUs, connection management, and handover.
Two different security modes are defined (see Clause 7). The first one, referred to as the centralized security mode, is based on key management between an MR-BS and an SS. The second security mode, referred to as the distributed security mode, incorporates authentication and key management between an MR-BS and a non-transparent access RS and between the access-RS and an SS.
An RS may be configured to operate either in normal CID allocation mode, where primary management, secondary, and basic CIDs are allocated by the MR-BS or in local CID allocation mode where the primary management and basic CID are allocated by the RS. The network management of RS shall use secondary management connection and shall follow the management reference model as defined in 1.4.1.
The PHY includes extensions to the OFDMA-PHY layer (see 8.4) for transmission of PHY PDUs across the relay link between the MR-BS and the RS.
3. Definitions
Insert the following new definitions in alphabetical order and renumber appropriately:
3.97 access link: A radio link between an MR-BS or RS and an MS, or between an MR-BS or RS and a subordinate RS during network entry. The access link is either an uplink or downlink.
3.98 access RS: A relay station that serves as an access station.
3.99 access station: A station that provides a point of access into the network for an MS or RS. An access station can be a base station (BS), relay station (RS), or multihop relay BS (MR-BS).
3.100 centralized scheduling: A mode of operation applicable to multihop relay where a multihop relay BS (MR-BS) determines the bandwidth allocations and generates the corresponding MAPs [or dictates the information used by relay stations (RSs) to generate their MAPs] for all access and relay links in the MR-cell.
3.101 distributed scheduling: A mode of operation applicable to multihop relay where the MR-BS and each RS in the MR-cell (with or without information from the MR-BS) determine the bandwidth allocations and generate the corresponding MAPs for the access link to/from their subordinate SSs and/or relay links to/from their subordinate RSs.
3.102 DL access zone: A portion of the DL subframe in the MR-BS/RS frame used for MR-BS/RS to MS or RS (except TTR RS in TDD mode) transmission. The DL access zone may consist of the entire downlink subframe, depending on the method used to separate the transmissions on the access and relay links.
3.103 DL relay zone: A portion of the DL subframe in the MR-BS/RS frame used for MR-BS/RS to RS transmission. A frame may have no DL relay zone, depending on the method used to separate the transmissions on the access and relay links.
3.104 infrastructure station: An MR-BS or RS.
3.105 intermediate RS: A relay station that is located on a path between an MR-BS and an access RS.
Copyright © 2009 IEEE. All rights reserved. 3
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
3.106 management tunnel CID (MT-CID): An identifier taken from the connection identifier (CID) space managed by an MR-BS that uniquely identifies a management tunnel connection between the MR-BS and an access RS.
3.107 MR-BS frame: Frame structure for DL transmission/UL reception by MR-BS.
3.108 multihop relay base station (MR-BS): A generalized equipment set providing connectivity, management, and control of relay stations and subscriber stations. See also: base station (BS), relay station (RS).
3.109 non-transparent RS: A relay station that transmits DL frame-start preamble, FCH, MAP message(s) and channel descriptor (DCD/UCD) messages.
3.110 relay link (R-link): A radio link between an MR-BS and an RS or between a pair of RSs. This can be a relay uplink or downlink.
3.111 relay station (RS): A generalized equipment set, dependent on a multihop relay base station (MR-BS) providing connectivity, to other RSs or subscriber stations (SS). An RS may also provide management and control of subordinate RSs or SSs. The air interface between an RS and an SS is identical to the air interface between a BS and an SS. See also: multihop relay base station (MR-BS), base station (BS), subscriber station (SS).
3.112 relay zone: A portion of a frame used for the relay link.
3.113 round trip delay (RTD): The round trip delay time between communicating stations (i.e. such as between an RS and its superordinate station).
3.114 RS frame: Frame structure for DL/UL transmission/reception by RS.
3.115 RS receive/transmit transition gap (RSRTG): The minimum receive-to-transmit turnaround gap required at an RS. RSRTG is measured from the time of the last sample of the received burst to the first sample of the transmitted burst at the antenna port of the RS.
3.116 RS transmit/receive transition gap (RSTTG): The minimum transmit-to-receive turnaround gap required at an RS. RSTTG is measured from the time of the last sample of the transmitted burst to the first sample of the received burst at the antenna port of the RS.
3.117 scheduling RS: A relay station that serves as a scheduling station; i.e., a non-transparent RS with unique BSID and operating in distributed scheduling mode.
3.118 scheduling station: In centralized scheduling mode, the scheduling station is always the MR-BS. In distributed scheduling mode, the scheduling station of a given MS/RS is the first station along the route to the MR-BS that transmits MAPs; i.e., either a non-transparent RS or the MR-BS itself.
3.119 security zone (SZ): A group consisting of one or more RSs and the MR-BS that share key material for the protection of MAC management messages produced and processed by members of the group.
3.120 security zone key (SZK): A group key shared by the MR-BS and a group of RSs within the same security zone. The SZK is a head of key hierarchy used to satisfy the security requirements such as integrity protection for MAC management messages within a defined security zone.
3.121 simultaneous transmit and receive (STR) relaying: A relay mechanism where transmission to subordinate station(s) and reception from the superordinate station, or transmission to the superordinate station and reception from subordinate station(s) are performed simultaneously.
4 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
3.122 STR RS: A non-transparent relay station capable of performing STR relaying.
3.123 time-division transmit and receive (TTR) relaying: A relay mechanism where transmission to subordinate station(s) and reception from the superordinate station, or transmission to the superordinate station and reception from subordinate station(s) is separated in time.
3.124 transparent RS: A relay station that does not transmit DL frame-start preamble, FCH, MAP message(s) or channel descriptor (DCD/UCD) messages.
3.125 transparent zone: A portion of the DL subframe in the MR-BS/RS frame for an RS operating in the transparent mode used for MR-BS/RS to MS transmission. A DL subframe may, or may not, have a transparent zone.
3.126 TTR RS: A non-transparent relay station that performs TTR relaying.
3.127 tunnel CID (T-CID): An identifier taken from the connection identifier (CID) space that uniquely identifies a transport tunnel connection.
3.128 UL access zone: A portion of the UL subframe in the MR-BS/RS frame used for MS or RS (except TTR RS in TDD mode) to MR-BS/RS transmission. A frame may have no UL access zone, or the UL access zone may consist of the entire uplink subframe, depending on the method used to separate the transmissions on the access and relay links.
3.129 UL relay zone: A portion of the UL subframe in the MR-BS/RS frame used for RS to MR-BS/RS transmission. A frame may have no UL relay zone, or the UL relay zone may consist of the entire uplink subframe, depending on the method used to separate the transmissions on the access and relay links.
4. Abbreviations and acronyms
Insert the following abbreviations and acronyms in alphabetical order:AC authentication controlFRS fixed relay stationHR handover rangingIR initial rangingIS infrastructure stationMRS mobile relay stationMR-BS multihop relay base stationRS relay stationRTD round trip delayR-ACK relay ACKR-DL relay downlinkR-FCH relay zone frame control headerR-MAP relay zone MAPR-RTI relay receive/transmit transition intervalR-TTI relay transmit/receive transition intervalR-UL relay uplinkR-Zone relay zoneTDU tunnel data unit
Copyright © 2009 IEEE. All rights reserved. 5
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
6. MAC common part sublayer
6.3 Data/Control plane
6.3.1 Addressing and connections
6.3.1.1 Point-to-multipoint (PMP)
Change 6.3.1.1 as indicated:
Each air interface in an SS shall have a 48-bit universal MAC address, as defined in IEEE Std 802®. This address uniquely defines the air interface of the SS. It is used during the initial ranging process to establish the appropriate connections for an SS. It is also used as part of the authentication process by which the BS and SS each verify the identity of the other. The definition and usage of the MAC address defined above for the SS and the BS shall be applicable for the RS and the MR-BS respectively.
Connections are identified by a 16-bit CID. At SS initialization, two pairs of management connections, basic connections (UL and DL) and primary management connections (UL and DL), shall be established between the SS and the BS, and a third pair of management connections (secondary management, DL, and UL) may be optionally generated. The three pairs of management connections reflect the fact that there are inherently three different levels of QoS for management traffic between an SS and the BS. The basic connection is used by the BS MAC and SS MAC to exchange short, time-urgent MAC management messages. The primary management connection is used by the BS MAC and SS MAC to exchange longer, more delay-tolerant MAC management messages. Table 38 specifies which MAC management messages are transferred on which of these two connections. In addition, it also specifies which MAC management messages are transported on the broadcast connection. Finally, the secondary management connection is used by the BS and SS to transfer delay-tolerant, standards-based [Dynamic Host Configuration Protocol (DHCP), Trivial File Transfer Protocol (TFTP), SNMP, etc.] messages. Messages carried on the secondary management connection may be packed and/or fragmented. For the OFDM, and OFDMA PHYs, management messages shall have CRC. Use of the secondary management connection is required only for managed SS. The identification, establishment, and usage of the connection defined above for the SS and the BS shall be applicable for the RS and the MR-BS respectively. In addition, the multicast management connection is used by the MR-BS to transfer MAC management messages to a group of RSs.
The CIDs for these connections shall be assigned in the RNG-RSP, REG-RSP, RS_Config-CMD (RS only),or MOB_BSHO-REQ/RSP for pre-allocation in handover. When CID pre-allocation is used during HO, a primary management CID may be derived based on Basic CID without assignment in the messages (see 6.3.21.2.11). The message dialogs provide three CID values. The same CID value is assigned to both members (UL and DL) of each connection pair.
Insert new subclause 6.3.1.2 as follows:
6.3.1.2 Multihop relay
Addressing and connections as perceived by an SS served by an RS or MR-BS are defined in the same manner as in 6.3.1.1. This subclause specifies the additional addressing and connection definitions that apply to multihop relay systems. A non-transparent RS shall be assigned a Base Station ID. The format of the Base Station ID is defined in 6.3.2.3.2.
Connections may span multiple hops and may pass through one or more intermediate RSs. These connections shall be identified by the connection ID (CID) as specified in 6.3.1.1 and the CIDs shall be
6 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
unique within an MR cell. All the CID connection types specified in PMP mode shall be supported between the MR-BS and MS.
An additional type of connection called a tunnel connection may be established between the MR-BS and an access RS, or between the MR-BS and a superordinate station of an RS group (see 6.3.34). Tunnel connections shall be used for transporting relay MAC PDUs from one or more connections between the MR-BS and an access RS and may pass through one or more intermediate RSs. It is not required that all connections shall pass through a tunnel connection. MAC PDUs from connections that do not pass through a tunnel are forwarded based on the CID of the connection. There shall be two types of tunnel connections. Management tunnel connections, identified using the MT-CID, shall be used exclusively for transporting MAC PDUs from management (basic, primary, or secondary) connections. Transport tunnel connections, identified using the T-CID, shall be used exclusively for transporting MAC PDUs from transport connections. The MR-BS shall allocate the T-CID and MT-CID using the DSA messages. MT-CID is bidirectional and T-CID is unidirectional.
Insert new subclause 6.3.1.3.1 as follows:
6.3.1.2.1 Addressing scheme for relaying
In the procedure of network entry and initialization for a new RS, the MR-BS may pre-allocate a range of management CIDs to an RS. The operation for pre-allocation of these CIDs is described in 6.3.9.18.2.
6.3.2 MAC PDU formats
Insert the following paragraph at the end of 6.3.2:
MAC PDUs sent on a relay link through a tunnel shall be constructed into a relay MAC PDU of the form illustrated in Figure 21a. Each relay MAC PDU shall begin with a fixed length relay MAC header (see 6.3.2.1.1.1). The relay MAC header shall be followed by zero or more extended subheaders and the payload. The payload shall consist of zero or more subheaders and zero or more MAC PDUs as defined in Figure 20. In the case of management tunnel, the payload may consist of zero or more subheaders and one MT_Transfer MAC message. A relay MAC PDU may contain a CRC as described in 6.3.3.5.2. Implementation of CRC capability is mandatory for MR systems and the presence of a CRC is indicated in the relay MAC header. When a relay MAC PDU contains a CRC, the CRCs of individual MAC PDUs within the payload shall be omitted but the CI bit setting and LEN values are retained. If omitted, the egress station of the tunnel shall calculate the CRCs and attach them to the individual MAC PDUs if the CI bit of the MAC PDU header within the relay MAC PDU is set.
Figure 21a—Relay MAC PDU format
6.3.2.1 MAC header formats
Insert new subclause 6.3.2.1.1.1 as follows:
6.3.2.1.1.1 Relay MAC header format
The header of the relay MAC PDU shall be of the format defined in Table 6a and further illustrated in Figure 23a.
Relay MAC Header Payload CRC
(optional)
Copyright © 2009 IEEE. All rights reserved. 7
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Figure 23a—Header format of relay MAC PDU with payload
Table 6a—Description of relay MAC header fields
Name Length (bits) Description
HT 1 Shall be set to zero.
EC/AC 1 Encryption control if CID in the relay MAC header is T-CID. 0 = Payload is not encrypted1 = Payload, except subheaders inserted on the relay link, is encrypted.Authentication control if CID in the relay MAC header is MT-CID.0 = Payload starting with MAC header defined in Table 3.1 = Payload starting with MT_Transfer message defined in Table 166ag.
RMI 1 Relay Mode IndicatorShall be set to 1.
ASH 1 Allocation subheader1=present; 0=absent
GMSH 1 UL: grant management subheader (GMSH)1 = present, 0 = absentDL: reserved, shall be set to 0.
FSH 1 Fragmentation subheader (FSH)1=present; 0=absent
PSH 1 Packing subheader (PSH)1=present; 0=absent
HT
= 0
(1)
EC/A
C (1
)
RM
I (1)
HCS (8)
CID (LSB) (8)
CID (MSB) (8)
LEN (4)
LEN LSB(8)
GM
SH (U
L)(1
)
FSH
(1)
PSH
(1)
QSH
(1)
ESF
(1)
ASH
(1)
CI (
1)
EKS (2)
8 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
6.3.2.1.2.2 MAC signaling header type II
Change the last row of Table 15 as indicated:
6.3.2.1.2.2.1 Feedback header
Change the first paragraph of 6.3.2.1.2.2.1 as indicated:
The feedback header is sent by an MS/RS either as a response to a Feedback Polling IE (see 8.4.5.4.28) or as an unsolicited feedback. When sent as a response to a Feedback Polling IE, the MS/RS shall send a feedback header using the assigned resource indicated in the Feedback Polling IE. When sent as unsolicited feedback, the MS/RS can either send the feedback header on currently allocated UL resource or request additional UL resource by sending an Indication flag on the fast-feedback channel or the enhanced fast-feedback channel (refer to 8.4.5.4.10.11) or by sending a BR ranging code.
QSH 1 QoS subheader (QSH)1=present; 0=absent
ESF 1 Extended subheader fieldIf ESF=0, the extended subheader is absent.If ESF=1, the extended subheader is present and immedi-ately follows the relay MAC header.The ESF is applicable in both the DL and UL.
CI 1 CRC indicator. 1 = CRC is included in the relay MAC PDU by appending it to the relay MAC PDU payload after encryption, if any.0 = No CRC is included.
EKS 2 Encryption key sequence. The index of the traffic encryp-tion key (TEK) of the access RS operating in distributed security mode and initialization vector (IV) used to encrypt the payload. This field is only meaningful if the EC/AC field is set to 1; otherwise, it shall be set to zero.
LEN 12 Length. The length in bytes of the relay MAC PDU includ-ing the relay MAC header and the CRC if present.
CID 16 T-CID or MT-CID.
HCS 8 Header Check Sequence.
Table 15—Type field encodings for MAC signaling header type II
Type field MAC header Type (with HT/EC=0b11) Reference figure Reference table
1 ReservedExtended relay MAC Signaling Header Type II Figure 34a Table 18a
Table 6a—Description of relay MAC header fields (continued)
Name Length (bits) Description
Copyright © 2009 IEEE. All rights reserved. 9
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Change the two paragraphs before Table 17 of 6.3.2.1.2.2.1 as indicated:
The feedback header may be used by the MS/RS to provide its feedback(s). An MS/RS receiving a feedback header on the DL shall discard the PDU.
The support of feedback header is OFDMA-PHY-specific and shall be negotiated between the BS and SS (or between the MR-BS and RS) as part of the registration dialog (REG-REQ/RSP).
Change Table 17 as indicated:
Table 17—Feedback type and feedback content
Feedback type
(binary)Feedback contents Description
1110 Early/Late Indication (1bit) +
Arrival Delta (8 bits) +
CID (16 bits)
Access link transmission status feedback
This feedback header type is sent by RS to MR-BS to provide access link transmission status for data. The feedback is used when MR-BS provides a target transmission time of the MAC PDU and the RS detects any abnormality in transmitting the MAC PDU. The RS may report missed transmission due to late arrival of a MAC PDU or abnormal early arrival of a MAC PDU in respect to transmission time.
Early/Late Indication: 0: Early Indication 1: Late Indication
Arrival Delta: Number of frames RS received frames early or late based on Early/Late Indication. For Late indication, this value is the difference in frame number between the target transmission time and frame in which the MAC PDU arrives at the RS. For Early indication, this value is the difference between the transit delay of the MAC PDU through the RS and the early detec-tion threshold as set by the “Relay Data Early Arrival Report Threshold” TLV in the SBC-RSP.
CID: CID of transport connection between RS and MR-BS
1111 Aggregated MS CQI parameters, in the form of either:
Full CQICH reporting: 6×5 bits
or
Differential CQICH reporting: if N_agg = 0 then 10×3 bits if N_agg = 1 then 16×2 bits
Aggregated MSs CQICH codewords relayed by RS.
N_agg is defined in MR-Fast-Feedback region allo-cation IE.
1110-1111 Reserved for future use —
10 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Insert new subclause 6.3.2.1.2.2.1.2 as follows:
6.3.2.1.2.2.1.2 Fast feedback reporting in an MR system
In a multihop relay system with RSs operating in centralized scheduling mode, an MR-BS may configure an RS to report on the relay link either full or differential fast feedback reporting using the feedback header defined in 6.3.2.1.2.2.1. Differential fast feedback reporting uses fewer bits; therefore the RS can map multiple MS’s fast feedback information on to the feedback header defined by Figure 30.
Differential feedback reporting can be used to report either physical CINR feedback or effective CINR feedback. If differential feedback reporting is performed on effective CINR, then the RS shall perform the differential operation based on the “label” of Table 517.
If an access RS receives a codeword other than physical or effective CINR feedback (e.g., indication flag feedback, MIMO mode feedback or AMC mode transition) on the CQICH channel or Feedback Header from an MS, then the access RS shall not perform the differential operation on the special codeword and shall send the special codeword indication to the MR-BS. The access RS stores the received special codeword and forwards the latest received special codeword to the MR-BS when the MR-BS requests full feedback reporting. When a CINR codeword is followed by a special codeword, differential operation shall be resumed. When an MR-BS receives a special codeword indication, the MR-BS may request full feedback reporting from the RS. An MR-BS may also request full feedback reporting periodically.
An MR-BS may allocate resources on the relay link for forwarding MS CQI parameter reports using a Feedback polling IE as defined in Table 413.
An MR-BS configures the RSs type of reporting (full or differential) using the RS_CQICH_Control IE (see 8.4.5.10.9). An access RS performs differential feedback reporting on behalf of an MS. An access RS extracts the MS’s fast feedback channel information from either the CQICH_Allocation_IE or CQICH_enhanced_allocation_IE transmitted in the UL-MAP. When an access RS performs differential feedback reporting, it uses the N_agg field of the RS_CQICH_Control IE for aggregating differential feedback reporting.
The 32-bits payload of “feedback header without CID field” defined in Figure 32 is constructed by aggregating the payload bits from Table 18a or Table 18b, starting from the most significant bits to the least significant bits. The payloads 0b100 and 0b10, respectively, are used to indicate that the access RS received special codewords from the MS. The access RS aggregates the payloads of the corresponding MSs in the 32-bits feedback header in the UL relay zone, starting with the MSB and ending with LSB. The aggregation is performed in the order of the feedback information received in the UL access zone by the RS. Dummy payload bits corresponding to dummy MSs are set to zero, and these bits may be used to fill the payload of the feedback header.
Copyright © 2009 IEEE. All rights reserved. 11
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
An access RS stores the last received full feedback information of the MSs and performs differential feedback reporting based on the received feedback information and last stored full feedback information. An access RS quantizes the difference into either seven or three steps according to Table 18a or Table 18b, respectively. If the difference of the two full feedback information is outside the range of the differential quantization steps, then the RS reports the closest quantization step.
When an access RS is requested to transmit differential feedback reporting, it transmits the differential feedback information to the superordinate RS according to the same order in which it receives the fast feedback reporting from the MSs in the fast feedback region of the UL access zone.
Intermediate RSs simply forward to the superordinate station the fast feedback information received in the relay zone. When an RS forwards the fast feedback information to a superordinate station, it puts the differential fast feedback information corresponding to its access zone before the fast feedback information received in the relay zone.
Insert new subclause 6.3.2.1.2.2.2 as follows:
6.3.2.1.2.2.2 Extended MAC signaling header type II
This type of MAC header is only supported on the R-UL. There is no payload following the MAC header. The Extended MAC signaling header type II is illustrated in Figure 34a. Table 18c describes the encoding of the 3-bit extended type field following the type field.
Table 18a—3 bit differential fast feedback encoding per differential CQI report with seven levels of quantization
Quantization step Payload bits
+3 0b000
+2 0b001
+1 0b010
0 0b011
–1 0b101
–2 0b110
–3 0b111
Special codeword indication 0b100
Table 18b—2 bit differential feedback encoding per differential CQI report with three levels of quantization
Quantization step Payload bits
+1 0b00
0 0b01
–1 0b11
Special codeword indication 0b10
12 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Figure 34a—Extended MAC signaling header type II format
Insert new subclause 6.3.2.1.2.2.2.1 as follows:
6.3.2.1.2.2.2.1 RS bandwidth request header (RS BR)
The RS BR header may be sent by a non-transparent RS operating in centralized scheduling mode to the MR-BS to request bandwidth on its access link for the purposes of transmitting messages composed by the RS (such as RNG-RSP, MOB_NBR-ADV, DCD, and UCD). This header shall not be transmitted by a scheduling RS. The RS BR header is illustrated in Figure 34b.
Table 18c—Extended Type field encodings for extended MAC signaling header type II
Extended Type field MAC header type Reference figure Reference table
0 RS BR header Figure 34b Table 18d
1 RS UL_DCH signaling header Figure 34c Table 18e
2 MR Acknowledgment header Figure 34d Table 18f
3 MR HARQ error report header Figure 34e Table 18g
4 MR Code-REP header Figure 34f Table 18h
5 Reserved — —
6 Tunnel BR header Figure 34g Table 18i
7 DL Flow Control Header Figure 34h Table 18j
HT
= 1
(1)
EC
= 1
(1)
Typ
e =
1 (1
)
Extended Type (3)
HCS (8) Header Content LSB (8)
Header Content (16)
Header Content MSB (10)
Copyright © 2009 IEEE. All rights reserved. 13
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Figure 34b—RS BR header format
Insert new subclause 6.3.2.1.2.2.2.2 as follows:
6.3.2.1.2.2.2.2 RS UL DCH signaling header (RS UL_DCH)
A non-transparent RS may request dedicated uplink resources for signaling and data transmissions instead of explicit BW request and allocation for each transmission. The dedicated uplink channel is allocated after receiving the RS_UL_DCH assignment IE. The assignment is a periodic allocation of uplink bandwidth and no subsequent periodic UL-MAP IE is needed in UL-MAP or R-MAP. For the rate based DCH request, the RS only specifies an average required data rate without a specific allocation frequency. The MR-BS or superordinate station determines a specific BW size and frequency configuration in response to the rate based request.
Table 18d—Description of fields in RS BR header
Name Length (bit) Description
TID 4 Transaction Identifier. MR-BS when allocating resources in response to an RS BR header shall include the same TID in the RS_BW_Alloc_IE as in the RS BR header. The counter used to generate the transaction ID shall be unique per CID per MR-BS.
DIUC 4 Indicates the DIUC used by RS to transmit the message. The MR-BS shall allocate sufficient resources based on the indicated DIUC to send the message from the RS using RS_BW_Alloc_IE.
BR 10 Requested amount of bandwidth in unit of bytes.
CID 16 Basic CID of the RS for which the RS bandwidth request header is sent.
HCS 8 Header Check Sequence (same usage as HCS entry in Table 5).
HT
= 1
(1)
EC
= 1
(1)
Typ
e =
1 (1
)
Extended Type = 0 (3)
HCS (8)
CID LSB (8)
CID MSB (8)
TID (4)
BR LSB (8)
DIUC (4)
BR MSB(2)
14 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
The RS requests a dedicated uplink resource by specifying Relay Link DCH Request through the RS UL_DCH signaling header. The RS confirms the successful reception of the RS_UL_DCH assignment IE by specifying DCH Assignment Acknowledgement (ACK).
It may also be used by an intermediate RS operating in centralized scheduling mode to request HARQ retransmission resource from the MR-BS by specifying HARQ Retransmission Request. The MR-BS responds with RS_UL_DCH HARQ RETX IE.
The format of this header is illustrated in Figure 34c and described in Table 18e.
Figure 34c—RS UL_DCH signaling header format
Table 18e—Description of fields in RS UL_DCH signaling header
Name Length (bits) Description
HT 1 Shall be set to 1
EC 1 Shall be set to 1
Type 1 Shall be set to 1
Extended Type 3 Shall be set to 001 for RS UL_DCH signaling header
DCH TYPE 4 0000 = Relay Link DCH Request0001 = DCH Assignment Acknowledgement (ACK)0010 = HARQ retransmission request0011–1111 = Reserved
if (DCH TYPE == 0000){ — Relay Link DCH Request
Request Type 2 00 = DCH Request Incremental01 = DCH Request Aggregate10 = DCH Request Rate Based11 = Reserved
if(Request Type == 00){ — DCH Request Incremental
HT
= 1
(1)
EC
= 1
(1)
Typ
e =
1 (1
)
Extended Type = 1 (3)
HCS (8)
Header Content (8)
Header Content (16)
DCH TYPE (4)
Header Content (6)
Copyright © 2009 IEEE. All rights reserved. 15
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Bandwidth request 16 Number of bytes requested by the RS
N 4 Allocation repeats once every N frames
}elseif (Request Type == 01){ DCH Request Aggregate
Bandwidth Request 16 Number of bytes requested by the RS. Zero in this field indicates DCH release request
N 4 Allocation repeats once every N frames
}elseif (Request Type == 10){ — DCH Request Rate Based
Average rate 20 Average data rate in units of bytes per second18 MSB bits: magnitude2 LSB bits: base-10 exponent
} — —
RS CID 8 8 LSBs of Basic CID of RS
} else if (DCH TYPE == 0001) {
— DCH Assignment Acknowledgement (ACK)
Frame Number 8 8-bit LSBs of the frame in which the RS_UL_DCH assignment IE is received
DCH resource ID 3 The value of DCH resource ID in the corresponding RS_UL_DCH assignment IE
RS CID 8 8 LSBs of Basic CID of RS
Reserved 11 Shall be set to 0
} else if (DCH TYPE == 0010) {
— HARQ retransmission request
RS CID 8 8 LSB of Basic CID of the RS requiring HARQ retransmission
Number of bursts 2 —
for (i=0;i< Number of bursts; i++) {
— —
DCH resource ID 3 ID of the DCH resource that needs HARQ retransmission
DCH ACID 4 HARQ channel require retransmission
Reserved 1 Shall be set to 0
} — —
Padding variable Shall be set to 0
} — —
HCS 8 Header check sequence
Table 18e—Description of fields in RS UL_DCH signaling header (continued)
Name Length (bits) Description
16 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Insert new subclause 6.3.2.1.2.2.2.3 as follows:
6.3.2.1.2.2.2.3 MR Acknowledgment header
An MR acknowledgment header may be sent by an RS as a response to a MAC management message received from the MR-BS or its superordinate RS that requires acknowledgment. When an acknowledgement is required, unsolicited uplink bandwidth may be provided to the RS to send this header to the MR-BS or its superordinate RS as an indication of the message reception. The MR acknowledgment header shall be sent on the same CID as the received MAC management message. The MR acknowledgment header is illustrated in Figure 34d. The support of MR acknowledgement header is optional for both MR-BS and RS and shall be negotiated during network entry of an RS using REG-REQ and REG-RSP message.
Figure 34d—MR Acknowledgement header format
Table 18f—Description of fields in MR acknowledgement header
Name Length (bits) Description
Rsv 2 Reserved
ACK Message Type 8 The MAC message type of the message received by the RS from the MR-BS or its superordinate RS.
Transaction ID 8 8 LSB of the Transaction ID included in the MAC management message re-ceived from the MR-BS. If Transaction ID is not included, set this field to zero. The counter used to generate the transaction ID shall be unique per CID per MR-BS.
CID 16 The same CID as the received MAC management message.
HCS 8 Header Check Sequence (same usage as HCS entry in Table 5).
HT
= 1
(1)
EC
= 1
(1)
Typ
e =
1 (1
)
Extended Type = 2 (3)
HCS (8)
CID LSB (8)
Rsv (2)
CID MSB (8)
ACK Message Type (8)
Transaction ID (8)
Copyright © 2009 IEEE. All rights reserved. 17
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Insert new subclause 6.3.2.1.2.2.2.4 as follows:
6.3.2.1.2.2.2.4 MR HARQ error report header
In case of centralized scheduling, the MR HARQ Error Report header may be transmitted by RS to provide ACK/NAK to MR-BS when RS is unable to decode the HARQ DL data successfully. The RS may send this header to MR-BS or superordinate RS as an unsolicited feedback in UL relay zone. Intermediate RS forwards the MR HARQ Error report header toward the MR-BS. The header format is illustrated in Figure 34e.
Figure 34e—MR HARQ error report header format
Table 18g—Description of fields in MR HARQ error report header
Name Length (bit) Description
Frame Number 4 Least significant 4 bits of frame number where the DL HARQ burst is received by the RS
DL HARQ ACK/NAK bitmap 14 RS transmits ACK/NAK Bitmap of DL HARQ data of previous frame. The order of Bitmap from MSB to LSB follows the order of DL HARQ subburst
CID 16 Basic CID of the RS
HCS 8 Header Check Sequence (same usage as HCS entry in Table 5)
HT
= 1
(1)
EC
= 1
(1)
Typ
e =
1 (1
)
Extended Type =3 (3)
HCS (8)
CID LSB (8)
CID MSB (8)
Frame Number LSB (4)
DL HARQ ACK/NAK Bitmap LSB (8)
DL HARQ ACK/NAK
Bitmap MSB (6)
18 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Insert new subclause 6.3.2.1.2.2.2.5 as follows:
6.3.2.1.2.2.2.5 MR Code-REP header
MR Code-REP header, illustrated in Table 18h, is used by a non-transparent RS operating in centralized scheduling mode to request the MR-BS to generate CDMA Allocation IEs with the following fields set to zero: Frame Number Index, Ranging Code, Ranging Symbol, and Ranging Subchannel. This header may also be used for requesting permission from the MR-BS to accept MSs attempting network entry.
Figure 34f—MR Code-REP header format
Table 18h—Description of fields in MR Code-REP header
Name Length (bits) Description
Frame Number Index 4 LSBs of relevant frame number
Number of Received IR CDMA Codes
4 Number of CDMA initial ranging code that requires no correction
Number of Received HR CDMA Codes
4 Number of CDMA handover ranging code that requires no correction
Number of Received BR CDMA Codes
6 Number of CDMA bandwidth request ranging codes
Basic CID 16 RS basic CID
HCS 8 Header Check Sequence (same usage as HCS entry in Table 5)
HT
= 1
(1)
EC
= 1
(1)
Typ
e = 1
(1)
Extended Type = 4 (3)
HCS (8)
CID LSB (8)
CID MSB (8) Number of Received BR
CDMA Codes (6)
Frame Number Index (4)
Number of Received IR CDMA
Codes (4)
Number of Received
HR CDMA Codes MSB
(2)
Number of Received
HR CDMA Codes LSB
(2)
Copyright © 2009 IEEE. All rights reserved. 19
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Insert new subclause 6.3.2.1.2.2.2.6 as follows:
6.3.2.1.2.2.2.6 Tunnel BR header
When tunnel mode is used by scheduling RSs and when QoS subheader is used, the RS may send tunnel BR (Bandwidth Request) to the superordinate scheduling station to request bandwidth. The scheduling type field and priority field are used to indicate the QoS type of bandwidth requested, and the CID field is tunnel CID.
The tunnel BR header is illustrated in Figure 34g.
Figure 34g—Tunnel BR header format
Table 18i—Description of fields in Tunnel BR header
Name Length (bit) Description
Data delivery service type 3 0: UGS; 1: RT-VR; 2: NRT-VR; 3:BE; 4:ERT-VR; 5–7: Reserved
Priority 3 Priority defined in 11.13.5
BR 12 Requested amount of bandwidth (128 byte/bit)
CID 16 Tunnel CID which requires the bandwidth
HCS 8 Header check sequence (same usage as HCS entry in Table 5)
HT
= 1
(1)
EC
= 1
(1)
Typ
e =
1 (1
)
Extended Type = 6 (3)
HCS (8)
CID LSB (8)
CID MSB (8)
BR LSB (8)
Data delivery service type (3)
Priority (3)
BR MSB (4)
20 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Insert new subclause 6.3.2.1.2.2.2.7 as follows:
6.3.2.1.2.2.2.7 DL flow control header
The DL flow control header is used to perform DL flow control between a scheduling RS and its scheduling station. This header is sent by an RS to its superordinate RS or MR-BS to report the number of bytes that the RS can receive in the DL direction. See 6.3.6.7.1.3 for the usage of this message.
Figure 34h—DL flow control header format
Table 18j—Description of fields in DL Flow Control header
Name Length(bit) Description
Reserved 2 Set to 0.
Credit 8 Indicates the state of the flow control protocol and number of bytes of DL traffic that the superordinate RS or MR-BS can send to the subordinate RS. 0–254: Flow control is in controlled state. The value indi-cates the number of bytes of DL traffic that can be safely received according to the following formula: Credit × 256 255: Flow control is in the uncontrolled state.
Reserved 8 Set to 0.
Basic CID MSB 8 MSB of Basic CID of the station whose traffic is to be flow controlled.
Basic CID LSB 8 LSB of Basic CID of the station whose traffic is to be flow controlled.
HCS 8 Header Check Sequence.
HT
= 1
(1)
EC
= 1
(1)
Typ
e =
1 (1
) Extended
Type = 7 (3)
HCS (8)
Basic CID LSB (8)
Basic CID MSB (8)
Credit (8)
Reserved = 0 (8)
Reserved = 0 (2)
Copyright © 2009 IEEE. All rights reserved. 21
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
6.3.2.2 MAC subheaders and special payloads
Insert new subclause 6.3.2.2.8 as follows:
6.3.2.2.8 Relay MAC PDU subheaders
Five types of subheaders may be present in a relay MAC PDU: Fragmentation subheader, Packing subheader, QoS subheader, Grant management subheader and Allocation subheader. The Packing and Fragmentation subheaders are mutually exclusive and shall not both be present within the same relay MAC PDU. When multiple subheaders are present in the same relay MAC PDU, they shall be ordered as follows: Grant management subheader, QoS subheader, Fragmentation or Packing subheader, and Allocation subheader. All subheaders in the relay MAC PDU are not encrypted.
Extended subheaders may also be present in a relay MAC PDU. When present, the extended subheader shall always appear immediately after the Relay MAC header, and before all other subheaders. All extended subheaders are not encrypted.
Insert new subclause 6.3.2.2.8.1 as follows:
6.3.2.2.8.1 QoS subheader (QSH)
The QoS subheader is specified in Table 37a. The QoS subheader may be used for relay MAC PDU on relay link in a transport tunnel.
Insert new subclause 6.3.2.2.8.2 as follows:
6.3.2.2.8.2 Allocation subheader
The MR-BS may include the allocation subheader in a relay MAC PDU. When operating in centralized scheduling mode, the MR-BS shall use the Allocation subheader to indicate the frame in which the RS shall relay the MAC PDU. When included, the MR-BS shall use one allocation subheader per RS for the relay link, and one or more allocation subheader for the access link. The allocation subheaders corresponding to the relay link shall precede the ones for access link. If there are multiple intermediate RSs, the allocation subheader associated with the RS that is nearest to the MR-BS shall be included first. The access RS shall use the continuation bit in the allocation subheader to detect whether there is a subsequent allocation subheader.
Table 37a—QoS subheader format
Syntax Size (bit) Notes
QoS Subheader() { — —
Data delivery service 3 0:UGS; 1: RT-VR; 2: NRT-VR; 3:BE; 4:ERT-VR; 5–7: Reserved
Priority 3 Priority is as defined in 11.13.5
Reserved 2 —
} — —
22 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
When operating in distributed scheduling mode, the MR-BS may include the Allocation subheader to indicate the frame in which the RS shall transmit an MBS MAC PDU over the access link. When included, MR-BS shall use only one Allocation subheader per MBS MAC PDU. The access RS shall transmit the MBS MAC PDU over the access link in the target transmission frame specified in Allocation subheader.
The allocation subheader format is specified in Table 37b. When used in distributed scheduling mode for MBS MAC PDU, only the target transmission frame field shall be used.
Insert new subclause 6.3.2.2.8.3 as follows:
6.3.2.2.8.3 Fragmentation subheader (FSH)
The FSH in a relay MAC PDU indicates the location of a fragment of a TDU originating from the ingress station of the tunnel. The format of the fragmentation subheader is specified in Table 37c.
Table 37b—Allocation subheader format
Syntax Size(bits) Notes
Allocation subheader{ — —
Target Transmission Frame 6 LSB 6 bits of frame number of the frame that RS shalltransmit the MAC PDU.
Allocation Index 6 Allocation Index pointing to DL-MAP_IE in the RS_Relay-MAP and the RS_Access-MAP message.
Number of MAC PDUs 3 Number of MAC PDUs in this allocation.
Continuation 1 1: Another Allocation subheader follows0: This is the last Allocation subheader for the RS.
} — —
Table 37c—Fragmentation subheader format
Syntax Size(bits) Notes
Fragmentation subheader{ — —
More fragments (MF) flag 1 MF is set for all fragments of the same TDU except the last one.
TDU sequence number (TSN) 7 The sequence number of the TDU to which this fragment belongs.
Fragment offset (FO) 12 The offset of the fragment relative to the beginning of the TDU.
Reserved 4 Shall be set to zero.
} — —
Copyright © 2009 IEEE. All rights reserved. 23
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Insert new subclause 6.3.2.2.8.4 as follows:
6.3.2.2.8.4 Packing subheader (PSH)
The PSH in a relay MAC PDU indicates the location and the length of a fragment of a TDU originating from the ingress station of the tunnel. The format of the packing subheader is specified in Table 37d.
6.3.2.3 MAC management messages
Change Table 38 as indicated:
Table 37d—Packing subheader format
Syntax Size(bit) Notes
Packing subheader{ — —
More fragments (MF) flag 1 MF is set for all fragments of the same TDU except the last one
TDU sequence number (TSN) 7 The sequence number of the TDU to which this fragment belongs
Fragment offset (FO) 12 The offset of the fragment relative to the beginning of the TDU
Fragment Length 12 The length of the fragment
} — —
Table 38—MAC management messages
Type Message name Message description Connection
0 UCD UL Channel Descriptor Fragmentable broad-cast or RS Primary Management or RS Multicast Management
1 DCD DL Channel Descriptor Fragmentable broad-cast or RS Primary Management or RS Multicast Management
70 RCD R-link channel descriptor RS Primary Manage-ment, RS Multicast Management
71 MR_NBR-INFO MR_NBR-INFO RS Primary Management
72 MR_RNG-REP MR Ranging report RS Basic
73 RS_Config-CMD RS configuration command RS Primary Management
74 RS_NBR_MEAS-REP
RS neighbor station measurement report RS Basic
75 MR_LOC-REQ MR location information request RS Primary Management
24 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
An extended set of MAC management messages specific to an MR system are defined and listed in Table 38. These messages may be exchanged between an RS and its superordinate station on either the RS’s primary management, RS’s basic or RS’s multicast management connections in addition to the non-MR system specific messages.
76 MR_LOC-RSP MR location information response RS Primary Management
77 MS_SCN-INF MS scanning inform RS Basic
78 MS_SCN-CLT MS scanning completion RS Basic
79 MS_INFO-DEL MS context information delete RS Basic
80 CLK-SYNC RS clock synchronization RS Multicast Manage-ment
81 MR_ASC-REQ MR association request RS Basic
82 MR_ASC-RSP MR association report RS Basic
83 RS_MOB_MEASREQ
RS group measurement request RS Multicast Manage-ment
84 HARQ_Chase_ER-REP
RS chase HARQ error report RS Basic
85 HARQ_IR_ER-REP
RS IR HARQ error report RS Basic
86 MR_SLP-INFO MS sleep mode information RS Basic
87 RS_AccessRS-REQ
RS access station selection request RS Basic
88 RS-SCH RS scheduling information RS Basic
89 RS_Member_List_Update
RS group member list update RS Multicast Management
90 MR_PBBR-INFO MR piggybacked bandwidth request information RS Basic
91 MR_Generic-ACK Generic ACK of received message RS Basic
92 RS_Access-MAP MAP information in centralized scheduling mode RS Basic, RS Multicast Management
93 RS_Relay-MAP R-MAP information in centralized scheduling mode RS Basic
94 MOB_INF-IND Mobile information indication RS Basic
95 MS_Context-REQ MS’s context request RS Basic
96 MS_Context-RSP MS’s context response RS Basic
97 MT_Transfer Transfer of MAC management messages in man-agement tunnel
RS Management Tunnel
98–255 — Reserved —
Table 38—MAC management messages (continued)
Copyright © 2009 IEEE. All rights reserved. 25
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
6.3.2.3.6 RNG-RSP (ranging response) message
Change Table 44 as indicated:
Change the paragraph of 6.3.2.3.6 as follows:
Preamble Index Override Preamble Indices of new target BS(s), and RS(s) where the MS or RS should redo ranging. If the TLV includes two or more Preamble Indices, the first one in the list is the most preferable and the second is the next preferable. When the TLV is used with Downlink frequency override TLV, the MS or RS should redo ranging on the new DL channel identified by the Preamble Indices.
Insert the following text at the end of 6.3.2.3.6:
The following parameter may be included in the RNG-RSP message for the purpose of assigning CDMA ranging codes to an RS:
RS CDMA Codes TLV (see 11.6)
The MR-BS may include the following TLV parameter to identify re-entry process management messages that may be omitted during an RS handover:
RS Network Entry Optimization (see 11.6)Identifies entry or re-entry process management messages that may be omitted during the current entry or re-entry attempt.
During network re-entry, the RS shall not enter Normal Operation with Target MR-BS until completing receiving all network reentry, MAC management message responses as indicated in this TLV.
The following parameter may be included in the RNG-RSP message when the MRS is attempting to perform network re-entry or handover:
CID List TLV (see 11.6.1)
The RNG-RSP message transmitted to an RS may contain the following TLVs:
Path Addition (see Table 11.1.13.2)Specification of the path addition operations
Table 44—RNG-RSP message format
Syntax Size (bit) Notes
RNG-RSP_Message_Format() { — —
Management Message Type = 5 8 —
Reserved 87 Shall be set to zero
H-FDD Group Indicator 1 0: Group 11: Group 2
TLV Encoded Information variable TLV-specific
} — —
26 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Path CID Binding Update (see 11.1.13.3)Specification of the path/CID binding operations including adding the binding between CIDs to the specific path.
The following parameter may be included in the RNG-RSP message that an RS sends to its serving MR-BS when an MS is attempting to perform association at the RS:
Association Info TLV (see 11.6)Specification of the MS’s uplink quality that may be used by the MS’s serving MR-BS as a factor to determine whether to recommend the RS as the MS’s HO target station.
6.3.2.3.7 REG-REQ (registration request) message
Insert the following text at the end of 6.3.2.3.7:
When an RS enters the network, the REG-REQ shall contain the following TLVs:
MR-BS and RS MAC feature support (see 11.7.25)
RS MAC feature support (see 11.7.25.1)
6.3.2.3.8 REG-RSP (registration response) message
Insert the following text at the end of 6.3.2.3.8:
In response to a REG-REQ from an RS, the REG-RSP shall contain the following TLV:
MR-BS and RS MAC feature support (see 11.7.25)
6.3.2.3.9 Privacy key management (PKM) messages (PKM-REQ/PKM-RSP)
Insert the following rows in Table 50:
6.3.2.3.9.19 PKMv2 SA-TEK-Response message
Insert the following at the end of 6.3.2.3.9.19:
In MR systems, a PKMv2 SA-TEK-Response message sent to an RS shall include the following TLV:
SA_SZK_Update (see 11.1.14)TLV that specifies a security zone SAID and corresponding SZK, and SZKEK parameters.
Table 50—PKM message codes
Code PKM message type MAC management message name
34 PKMv2 AK Transfer PKM-RSP
35 PKMv2 AK Transfer Ack PKM-REQ
36–255 Reserved —
Copyright © 2009 IEEE. All rights reserved. 27
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
6.3.2.3.9.25 PKMv2 Group-Key-Update-Command message
Change Table 75 as indicated:
Insert new subclause 6.3.2.3.9.29 as follows:
6.3.2.3.9.29 PKMv2 AK transfer message
In an MR system with an RS operating in distributed security mode, the MR-BS shall send an SS’s AK in the PKMv2 AK Transfer message to the access RS operating in distributed security mode.
Table 75—PKMv2 Group-Key-Update-Command message attributes
Attribute Contents
Key Sequence Number AK sequence number for GKEK/SZKEK update mode, GKEK/SZKEK sequence number for GTEK/SZK update mode.
GSAID Security association identifier.
Key Push modes Usage code of PKMv2 Group-Key-Update-Command message.
In MR systems, GTEK update mode corresponds to SZK update mode, and GKEK update mode corresponds to SZKEK update mode.
Key Push Counter Counter one greater than that of older generation.
GTEK/SZK-Parameters “Newer” generation of GTEK-related parameters relevant to GSAID. The GTEK-Parameters is the TEK-Parameters for multicast, broadcast service, or MBS.In MR systems, SZK-related parameters relevant to security zone SAID.
GKEK/SZKEK-Parameters “Newer” generation of GKEK-related parameters for multicast, broadcast service, or MBS.In MR systems, SZKEK-related parameters relevant to SAID for encrypting SZK.
HMAC/CMAC Digest Message integrity code of this message.
Table 78a—PKMv2 AK Transfer message
Attribute Contents
Key Sequence Number RS AK sequence number
SAID MS/subordinate RS’s primary SAID
SAID RS primary SAID
AK-Parameters AK related parameters defined in Table 11.9.40
Frame Number An absolute frame number in which the old PMK and all its associate AKs should be discarded
(one or more) SA-Descriptor(s) Each compound SA-Descriptor attribute specifies SAID additional properties of the SA
Nonce A random number generated in an MR-BS
HMAC/CMAC Digest Message authentication digest
28 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Insert new subclause 6.3.2.3.9.30 as follows:
6.3.2.3.9.30 PKMv2 AK transfer ACK
An RS operating in distributed security mode shall send a PKMv2 AK Transfer Ack message to the MR-BS in reply to PKMv2 AK Transfer message in order to securely acknowledge key reception.
6.3.2.3.10 DSA-REQ message
Insert the following text at the end of 6.3.2.3.10:
In multihop relay systems with scheduling RSs, DSA-REQ is used for two other purposes—one for admission control and one for path management. Such DSA-REQ is only sent over relay links from an MR-BS or an RS to its subordinate RS.
In multihop relay systems with scheduling RSs, MR-BS may send a DSA-REQ to all the RSs on the path to request an admission control decision. This DSA-REQ is processed by each RS on the path and forwarded to its subordinate RS. The CID of the associated service flow is included in the CID TLV field of the Service Flow Parameters TLV and is either the transport CID for the service flow or the tunnel CID of the tunnel into which the service flow is mapped. The DSA-REQ pertaining to a tunnel shall not contain the SFID TLV field of the Service Flow Parameters TLV. The MR-BS and RS shall generate DSA-REQ in the form shown in Table 79, except that the CID used in the MAC header is the primary management CID of MR-BS/RS’s subordinate RS.
This DSA-REQ sent over relay link for the purpose of admission control may contain the following TLV, if explicit path management is used:
Path ID (see 11.1.13.1)Specification of the ID of the path that shall be traversed by the service flow
This DSA-REQ sent over relay link for the purpose of admission control may contain the following TLV, if embedded path management is used and the systematic CID is not assigned locally by the RS:
Path Info (see 11.1.13.4)Specification of the ordered primary management CID list of the RSs on the path that shall be traversed by the service flow
Table 78b—PKMv2 AK Transfer ACK
Attribute Contents
Key Sequence Number RS AK sequence number
SAID Access RS primary SAID
Key Sequence Number MS/subordinate RS’s AK sequence number
SAID MS/subordinate RS’s primary SAID
Nonce A same random number included in the PKMv2 AK Transfer message
HMAC/CMAC Digest Message authentication digest
Copyright © 2009 IEEE. All rights reserved. 29
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
In multihop relay systems, a DSA-REQ may also be sent by the MR-BS to populate the path information to every RS on the path and/or distribute the binding information between connections and a selected path. The MR-BS shall generate DSA-REQs in the form shown in Table 79. When an RS that is not the access RS for the path receives a DSA-REQ, that RS shall also generate a DSA-REQ in the form shown in Table 79 and send this DSA-REQ to the subordinate RS on the path.
The DSA-REQ message sent over relay link for the purpose of path management may contain the following TLVs:
Path Addition (see 11.1.13.2)Specification of the path addition operations
Path CID Binding Update (see 11.1.13.3)Specification of the path/CID binding operations including adding the binding between CIDs to the specific path.
This DSA-REQ sent over relay link for the purpose of path management shall not contain the following TLVs:
Service Flow Parameters (see 11.13)Specification of the service flow’s traffic characteristics and scheduling requirements
The DSA-REQ message sent over relay link shall not contain the following TLV:
Convergence Sublayer Parameter Encodings (see 11.13.18) Specification of the service flow’s CS specific parameters
6.3.2.3.11 DSA-RSP message
Insert the following text at the end of 6.3.2.3.11:
In multihop relay systems with scheduling RSs, upon receiving a DSA-REQ from its superordinate station to request an admission control decision, an access RS or an intermediate RS that cannot accept the requested service flow shall reply with a DSA-RSP to MR-BS. This DSA-RSP sent over relay link follows the form shown in Table 80, except that the CID used in the MAC header is the primary management CID of the RS that sends the DSA-RSP message.
This DSA-RSP message sent over relay link for the purpose of admission control shall contain the following TLV if the confirmation code is OK/success:
Service Flow Parameters (see 11.13)The specification of the service flow that can be supported by all the RSs on the path. The DSA-RSP pertaining to a tunnel shall not contain the SFID TLV field of the Service Flow Parameters TLV.
In multihop relay systems with scheduling RSs, a DSA-RSP may also be sent by an RS to confirm the path management operation requested in the correspondent DSA-REQ. The RS shall generate the DSA-RSP in the form shown in Table 80 except that the CID used in the MAC header is the primary management CID of the RS that sends the DSA-RSP message.
This DSA-RSP message sent over the relay link for the purpose of path management shall not contain the following TLV:
Service Flow Parameters (see 11.13)The specification of the service flow that can be supported by all the RSs on the path
30 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
The DSA-RSP message sent over the relay link shall not contain the following TLV:
Convergence Sublayer Parameter Encodings (see 11.13.18) Specification of the service flow's CS specific parameters
6.3.2.3.12 DSA-ACK message
Insert the following text at the end of 6.3.2.3.12:
In multihop relay systems with scheduling RSs, upon receiving a DSA-RSP from an access RS for the purpose of admission control, the MR-BS shall send a DSA-ACK to all the RSs on the path. This DSA-ACK is processed by each intermediate RS on the path, and forwarded to its subordinate RS using the primary management CID of the subordinate RS. The CID of the associated service flow is included in the CID TLV field of the Service Flow Parameters TLV together with any modified service flow parameter. The CID is either the transport CID for the service flow or the tunnel CID of the tunnel into which the service flow is mapped. The MR-BS and RS shall generate DSA-ACK in the form shown in Table 81, except that the CID used in the MAC header is the primary management CID of MR-BS/RS’s subordinate RS.
This DSA-ACK sent over relay link may contain the following TLVs:
Service Flow Parameters (see 11.13)Specification of the traffic characteristics and scheduling requirements of any modified service flow parameters. The DSA-ACK pertaining to a tunnel shall not contain the SFID TLV.
6.3.2.3.13 DSC-REQ (DSC request) message
Insert the following text at the end of 6.3.2.3.13:
In multihop relay systems with scheduling RSs, DSC-REQ is used for two other purposes—one for admission control and one for path management. Such DSC-REQ is only sent over relay links from MR-BS or an RS to its subordinate RS.
In multihop relay systems with scheduling RSs, the MR-BS may send a DSC-REQ to all the RSs on the path to request an admission control decision. This DSC-REQ is processed by each RSs on the path and forwarded to its subordinate RS using the primary management CID of the subordinate RS. The CID of the service flow is included in the CID TLV field of the Service Flow Parameters TLV and is either the transport CID for the service flow or the tunnel CID of the tunnel into which the service flow is mapped. The DSC-REQ pertaining to a tunnel shall not contain the SFID TLV field of the Service Flow Parameters TLV. The MR-BS and RS shall generate DSC-REQ in the form shown in Table 82, except that the CID used in the MAC header is the primary management CID of MR-BS/RS’s subordinate RS.
This DSC-REQ sent over relay link for the purpose of admission control may contain the following TLVs, if explicit path management is used:
Path ID (see 11.1.13.1)Specification of the id of the path that shall be traversed by the service flow.
This DSC-REQ sent over relay link for the purpose of admission control may contain the following TLV, if embedded path management is used and the systematic CID is not assigned locally by the RS:
Path Info (see 11.1.13.4)Specification of the ordered primary management CID list of the RSs on the path that shall be traversed by the service flow.
Copyright © 2009 IEEE. All rights reserved. 31
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
In multihop relay systems, a DSC-REQ may also be sent by MR-BS to update the binding between CIDs to a specified path, or to distribute the updated service flow parameter for a connection that is bound to the specified path. The MR-BS shall generate DSC-REQs in the form shown in Table 82. When an RS that is not the access RS on the relay path receives such DSC-REQ, that RS shall also generate a DSC-REQ in the form shown in Table 82 and send this DSC-REQ to its subordinate RS on the path.
The DSC-REQ message sent over relay link for the purpose of path management may contain the following TLVs:
Path CID Binding Update (see 11.1.13.3)Specification of the path/CID binding operations including changing of service flow parameter of the CIDs bound to the specific path.
This DSC-REQ sent over relay link for the purpose of path management shall not contain the following TLVs:
Service Flow Parameters (see 11.13)Specification of the service flow’s traffic characteristics and scheduling requirements.
This DSC-REQ sent over relay link for the purpose of admission control may contain the following TLV if the admission control is applied to a tunnel, and meanwhile the included individual MS CIDs are added into or removed from the tunnel.
CIDs Added into Tunnel (see 11.13.44)The CIDs to be added into the specified tunnel.
CIDs Removed from Tunnel (see 11.13.45)The CIDs to be removed from the specified tunnel.
6.3.2.3.14 DSC-RSP (DSC response) message
Insert the following text at the end of 6.3.2.3.14:
In multihop relay systems with scheduling RSs, upon receiving DSC-REQ from its superordinate station for the purpose of admission control, an RS may reply with a DSC-RSP to MR-BS using its primary management CID. The DSC-RSP sent over relay link follows the form as shown in Table 83, except that the CID used in the MAC header is the primary management CID of the RS that sends the DSC-RSP message.
This DSC-RSP message sent over relay link for the purpose of admission control shall contain the following TLV if the confirmation code is Ok/success:
Service Flow Parameters (see 11.13)The specification of the service flow that can be supported by all the RSs on the path. The DSC-RSP pertaining to a tunnel shall not contain the SFID TLV.
In multihop relay system with scheduling RSs, a DSC-RSP may also be sent by an RS to confirm the path management operation requested in the correspondent DSC-REQ. The RS shall generate the DSC-RSP in the form shown in Table 83 except that the CID used in the MAC header is the primary management CID of the RS that sends the DSC-RSP.
The DSC-RSP message sent over relay link for the purpose of path management shall not contain the following TLV:
Convergence Sublayer Parameter Encodings (see 11.13.18) Specification of the service flow’s CS specific parameters.
32 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
This DSC-RSP sent over relay link for the purpose of path management shall not contain the following TLVs:
Service Flow Parameters (see 11.13)Specification of the service flow’s traffic characteristics and scheduling requirements.
6.3.2.3.15 DSC-ACK (DSC acknowledge) message
Insert the following text at the end of 6.3.2.3.15:
In multihop relay systems with scheduling RSs, upon receiving a DSC-RSP from an access RS for the purpose of admission control, the MR-BS shall send a DSC-ACK to all the RSs on the path. This DSC-ACK is processed by each RS on the path and forwarded to its subordinate RS using the primary management CID of the subordinate RS. The CID of the associated service flow is included in CID TLV field of the Service Flow Parameters TLV together with any modified service flow parameter, and is either the transport CID for the service flow or the tunnel CID of the tunnel into which the service flow is mapped. The MR-BS and RS shall generate DSC-ACK in the form shown in Table 84, except that the CID used in the MAC header is the primary management CID of MR-BS/RS’s subordinate RS.
This DSC-ACK sent over relay link may contain the following TLVs:
Service Flow Parameters (see 11.13)Specification of the traffic characteristics and scheduling requirements of any modified service flow parameters. The DSC-ACK pertaining to a tunnel shall not contain the SFID TLV.
6.3.2.3.16 DSD-REQ message
Insert the following text at the end of 6.3.2.3.16:
In multihop relay systems with scheduling RSs, DSD-REQ is used for the deletion of a tunnel or individual service flow that is not mapped to a tunnel or for the purpose of path management. Such DSD-REQ is only sent over relay links from MR-BS or an RS to its subordinate RS.
In multihop relay systems with scheduling RSs, while deleting a tunnel or an individual service flow that is not mapped to a tunnel, the MR-BS may send a DSD-REQ to all the RSs on the path. The DSD-REQ message is processed by each intermediate RS and forwarded to its subordinate RS using the primary management CID of the subordinate RS. The MR-BS and RS shall generate DSD-REQ in the form shown in Table 85, except that the CID used in the MAC header is the primary management CID of the MR-BS/RS’s subordinate RS. For a tunnel connection, the MR-BS shall set the Service Flow ID field in the DSD-REQ to an SFID that is not used in the MR-BS cell.
This DSD-REQ message sent over relay link for the deletion of individual service flow that is not mapped into a tunnel or the deletion of a tunnel may contain the following TLVs, if explicit path management scheme is used:
Path ID (see 11.1.13.1)Specification of the id of the path that shall be traversed by the service flow.
The DSD-REQ sent over relay link for the deletion of individual service flow that is not mapped to a tunnel or the deletion of a tunnel may contain the following TLV, if embedded path management is used and the systematic CID is not assigned locally by the RS:
Path Info (see 11.1.13.4)Specification of the ordered primary management CID list of the RSs on the path that shall be traversed by the service flow.
Copyright © 2009 IEEE. All rights reserved. 33
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
This DSD-REQ sent over relay link for the purpose of deletion of a tunnel shall contain the following TLV.
CID (see 11.13.2)The CID of the tunnel to be removed.
In multihop relay systems with scheduling RSs, a DSD-REQ is also sent by MR-BS to remove a path and/or remove the binding between connections and a selected path. The MR-BS shall generate DSD-REQs in the form shown in Table 85. The MR-BS shall set the Service Flow ID in the DSD-REQ to an SFID that is not used in the MR-BS cell. The RS that is not the access RS on the relay path shall also generate a DSD REQ in the form shown in Table 85 and send it to the next RS on the path.
The DSD-REQ message sent over relay link for the purpose of path management may contain the following TLVs:
Path ID (see 11.1.13.1)Specification of the path to be completely removed.
Path CID Binding Removal (see 11.1.13.3)Specification of the path/CID binding operations including removing the binding between CIDs to the specific path.
6.3.2.3.17 DSD-RSP message
Insert the following text at the end of 6.3.2.3.17:
In multihop relay systems with scheduling RSs, upon receiving DSD-REQ from MR-BS, the access RS replies with a DSD-RSP to MR-BS using its primary management CID. The DSD-RSP sent over relay link follows the form as shown in Table 86, except that the CID used in the MAC header is the primary management CID of the access RS that sends the DSD-RSP.
In multihop relay systems with scheduling RSs, a DSD-RSP may also be sent by an RS to confirm the path management operation requested in the correspondent DSD-REQ. An RS shall generate the DSD-RSP in the form shown in Table 86 except that the CID used in the MAC header is the primary management CID of the RS that sends the DSD-RSP.
6.3.2.3.23 SBC-REQ (SS and RS basic capability request) message
Change the text in the first paragraph of 6.3.2.3.23 as indicated:
The SBC-REQ shall be transmitted by the SS or RS during initialization. An SS or RS shall generate SBC-REQ messages in the form shown in Table 92.
An SS or RS shall generate SBC-REQ messages including the following parameter:
Basic CID (in the MAC header)The connection identifier in the MAC header is the Basic CID for this SS or RS, as assigned in theRNG-RSP message.
All other parameters are coded as TLV tuples.
The Basic Capabilities Request contains the SS or RS Capabilities Encodings (11.8) that are necessary to acquire NSP information and for effective communication with the SS or RS during the remainder of the initialization protocols. NSP information is solicited in the SBC-REQ message when the SBC-REQ includes the SIQ TLV (11.8.9) with bit 0 set to 1.
34 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
The following parameter shall be included in the Basic Capability Request if the SS or RS is intended to solicit NSP information:
Service Information Query (see 11.8.9)
The following parameter shall be included in the Basic Capabilities Request only if the SS is not intended to solicit NSP information:
Physical Parameters Supported (see 11.8.3)
Insert the following at the end of 6.3.2.3.23:
The following parameter shall be included in the SBC-REQ message when the message is relayed from an SS to the MR-BS by a scheduling RS operating in local CID allocation mode:
Station Information TLV (see 11.8.21)
This following parameters shall be included in the SBC-REQ message sent by all RS types.
RSRTG (see 11.8.3.5.27)
RSTTG (see 11.8.3.5.28)
This following parameters shall be included in the SBC-REQ message sent by an RS when the RS supports the capability to support the centralized scheduling mode of operation:
Minimum RS forwarding delay in direct relay zone TLV (see 11.8.19)
Minimum RS forwarding delay TLV (see 11.8.20)
6.3.2.3.24 SBC-RSP (SS and RS basic capability response) message
Insert the following after the first paragraph of 6.3.2.3.24:
An MR-BS shall generate the SBC-RSP messages for an RS in the same format as a BS generates SBC-RSP messages for an SS. The set of compound TLVs that shall or may be included are the same and may contain additional common encodings (see 11.1.13) and MR specific sub-TLVs (see 11.8).
The following parameters may be included in the SBC-RSP message when the message is relayed from an MR-BS to the SS by a scheduling RS operating in local CID allocation mode:
Path Addition (see 11.1.13.2)
Path CID Binding Update (see 11.1.13.3)
Station Information TLV (see 11.8.21)
MR-cell carrier configurations (see 11.8.3.5.26)
6.3.2.3.26 DREG-CMD (de/reregister command) message
The DREG-CMD message shall be transmitted by the BS on an SS/RS’s Basic CID to force the SS/RS to change its access state. The BS may transmit the DREG-CMD message unsolicited or in response to a DREG-REQ message. Upon receiving a DREG-CMD message, the SS/RS shall take the action indicated by the action code.
Copyright © 2009 IEEE. All rights reserved. 35
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Change Table 96 as indicated:
Change the explanation text of the “REQ-duration” field as indicated:
REQ-duration
Waiting value for the DREG-REQ message re-transmission (measured in frames) if this is included with action code 0x06 in DREG-CMD. If serving BS includes REQ-duration in a DREG-CMD message including an Action Code = 0x05, the MS may initiate an Idle Mode request through a DREG-REQ with Action Code = 0x01, request for MS De-Registration from serving BS and initiation of MS Idle Mode, at REQ-duration expiration.
If the RS receives the DREG-CMD message with Action Code = 0x06, it resends DREG-REQ message after REQ-duration timer expiry.
6.3.2.3.47 MOB_BSHO-REQ (BS HO Request) message
Insert the following at the end of 6.3.2.3.47:
The MOB_BSHO-REQ message shall include the following parameter encoded as TLV tuple for MRS:
Preamble Index (see 11.15.4)
Table 96—Action codes and actions
Action codes(hexadecimal) Action
00 SS shall immediately terminate service with the BS and attempt network entry with another BS; or RS shall immediately terminate service with the MR-BS and attempt net-work entry with another MR-BS.
01 SS shall listen to the current BS (or RS shall listen to current MR-BS) but shall not transmit until a RES-CMD message or DREG-CMD with action Code 02 or 03 is received.
02 SS shall listen to the current BS (or RS shall listen to current MR-BS) but only transmit on the basic, and primary management connections.
03 SS/RS shall return to normal operation and may transmit on any of its active connec-tions.
04 This option is valid only in response to a DREG-REQ message with De-Registration Request Code = 0x00. The SS shall terminate current Normal Operations with the BS; or the RS shall terminate current Normal Operation with the MR-BS.
05 MS shall begin MS idle mode initiation. See 6.3.23.1.
06 This option is valid only in response to a DREG-REQ message with De-Registration Request Code = 0x01. The behavior of MS to this action code is described in 6.3.23.1. The RS may retransmit the DREG-REQ message after the time duration (REQ-duration) provided in the message; MR-BS transmission of a subsequent DREG-CMD message with Action Code 03 shall cancel this restriction.
07–0xFF Reserved
36 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
6.3.2.3.49 MOB_BSHO-RSP (BS HO Response) message
Insert the following at the end of 6.3.2.3.49:
The MOB_BSHO-RSP message shall include the following parameter encoded as TLV tuple for MRS:
Preamble Index (see 11.15.4)
6.3.2.3.51 MOB_PAG-ADV (BS broadcast paging) message
Change Table 154 as indicated:
Table 154—MOB_PAG-ADV message format
Syntax Size (bits) Notes
MOB_PAG-ADV_Message_format() { — —
Management Message Type = 61 8 —
Num_Paging_Group_IDs 16 Number of Paging Group IDs in this message
for (i=0; i<Num_Paging_Group_IDs; i++) { — —
Paging Group ID 16 —
} — —
Num_MACs 8 Number of MS MAC addresses
for (j=0; j<Num_MACs; j++) { — —
MS MAC Address hash 24 The hash is obtained by computing a CRC24 on the MS 48-bit MAC address. The polynomial for the calculation is 0x1864CFB
Action Code 2 Paging action instruction to MS 0b00=No Action Required 0b01=Perform Ranging to establish location and acknowledge message 0b10=Enter Network 0b11=Reserved
Stop Paging 1 0b0= paging start command0b1= paging stop command
PLI Count 3 Number of the PLIs of its superordinate station that have elapsed at the current receiving frame.The maximum value of PLI Count is ‘0b10’. 0b11: The PLI Count field shall be ignored by the RS.
Reserved 62 —
} — —
Padding variable Padding bits to ensure octet aligned
TLV Encoded Information variable TLV specific
} — —
Copyright © 2009 IEEE. All rights reserved. 37
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Insert the following text into the parameter list following Table 154:
Stop PagingWhen this bit is set to 1, the RS shall stop sending Broadcast Paging message.
PLI CountThis field indicates to the RS the number of PLIs of its superordinate station that have elapsed. The RS shall determine its own paging retry count according to the “PLI Count” and the “Paging Retry Count” of MR-BS. When an RS relays the MOB_PAG-ADV message to its subordinate RSs, the “PLI Count” value shall be increased by one if the receiving RS has missed one more MOB_PAG-ADV message transmission over the access link.
Paging Interval (see 11.17.4)This TLV informs the RS about the Paging Listening Interval for each paged MS, including paging cycle and paging offset. When the Paging Interval TLV is not included, Stop Paging and PLI Count shall be set to 0.
Insert new subclauses 6.3.2.3.60 to 6.3.2.3.87:
6.3.2.3.60 R-link channel descriptor (RCD) message
The RCD message consists of TLVs that define the characteristics of the relay link between an RS and its superordinate station. It is transmitted to subordinate RSs using the RS’s primary management CID or multicast management CID on an event basis when one of the parameters relating to the characteristics of the relay link are changed.
In centralized scheduling mode, the MR-BS shall construct the RCD for all RSs. In distributed scheduling mode, the MR-BS and scheduling RS shall individually construct the RCD message that relates to the relay link that they control and scheduling RSs may use information provided to them in the RS_Config-CMD message in order to construct the message with the necessary TLVs.
Upon receiving an RCD message an RS shall respond to the sending station with an MR_Generic-ACK message. If the sending station does not receive the ACK before the expiry of a T58 timer, started on sending of the RCD, then it may resend the RCD message.
Upon reception of all ACK messages the sending station may then apply the new configuration and indicate that this is in effect by changing the configuration change count parameter in the R-MAP message.
Table 166a—R-link channel descriptor (RCD) message format
Syntax Size (bit) Notes
RCD_Message_Format(){ — —
Management Message Type = 70 8 —
RCD configuration change count 8 —
Transaction ID 16 —
TLV Encoded Information variable TLV specific
} — —
38 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
RCD configuration change count
Incremented by one (modulo 256) by the MR-BS or the scheduling RS whenever any of the values of this channel descriptor change. If the value of this count in a subsequent RCD remains the same, the receiving RS can quickly deduce that the remaining fields have not changed and may be able to disregard the remainder of the message.
Transaction ID
The counter used to generate the transaction ID shall be unique per CID per MR-BS or scheduling RS.
The RCD message may include the following TLVs:
Relay UL allocation start time (see 11.24.1)
Reserved preamble indexes for mobile relay station (see 11.24.2)
Preamble reselection thresholds for mobile relay station (see 11.24.3)
DCD encodings (see 11.1.15)
UCD encodings (see 11.1.15)
The RCD message shall include the following TLVs:
HMAC/CMAC Tuple (see 11.1.2)
The HMAC/CMAC Tuple shall be the last attribute in the message
6.3.2.3.61 MR_NBR-INFO message
The MR_NBR-INFO shall be transmitted by the MR-BS to an RS. The message shall be transmitted on the RS’s primary management CID. The message format for the MR_NBR-INFO message shall be in accordance with Table 166b.
Table 166b—MR_NBR-INFO message format
Syntax Size(bits) Notes
MR_NBR-INFO_Message_Format(){ — —
Management Message Type = 71 8 —
Action Type bitmap 4 Bit [0]: if set to 1, information about all the neighboring stations is present.Bit [1]: if set to 1, the neighbors listed here shall be appended to the existing neighbor list.Bit [2]: if set to 1, neighbors listed here shall be deleted from the existing neighbor list.Bit [3]: if set to 1, information about neighbors listed here shall be updated as indicated.
if((Action Type bitmap [0] == 1)||(Action Type bitmap[1]==1)) {
— —
Copyright © 2009 IEEE. All rights reserved. 39
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Skip-optional-fields bitmap 8 Bit [0]: if set to 1, omit Operator ID field.Bit [1]: if set to 1, omit NBR BS ID field.Bit [2]: if set to 1, omit HO process optimization field.Bit [3]: if set to 1, omit QoS related fields.Bit [4]: if set to 1, omit Relay zone offsetBit [5]–[7]: Reserved.
if (Skip-optional-fields-[0]==0){
Operator ID 24 Unique ID assigned to the operator
} — —
Fragmentation Index 4 Indicates the current fragmentation index
Total Fragmentation 4 Indicates the total number of fragmentations
N_NEIGHBORS 8 Number of neighbors for this RS
for(j=0; j<N_NEIGHBORS;j++){ — —
Length 8 Length of message information within the iteration of N_NEIGHBORS in bytes.
PHY Profile ID 8 Aggregated IDs of Co-located FA Indicator, FA Configu-ration Indicator, FFT size, Bandwidth, Operation Mode of the starting subchannelization of a frame and Channel Number.
if(FA Index Indicator == 1){
FA Index 8 This field, Frequency Assignment Index, is present only when the FA Index Indicator in PHY Profile ID is set. Otherwise, the neighbor Station has the same FA Index or the center frequency is indicated using the TLV encoded information.
}
if(Station EIRP Indicator ==1){
Station EIRP 8 Signed Integer from –128 to 127 in unit of dBm This field is present only if the Station EIRP indicator is set in PHY Profile ID. Otherwise, the Station has the same EIRP as the serving Station.
} — —
if(Skip-optional-fields[1]==0){ — —
Neighbor BSID 24 BSID of neighbor.
} — —
Preamble Index/Subchannel Index 8 This parameter defines the OFDMA PHY specific preamble
if(Skip-optional-fields[2]==0){ — —
Table 166b—MR_NBR-INFO message format (continued)
Syntax Size(bits) Notes
40 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
HO Process Optimization 8 The HO Process Optimization provided as part of this message is indicative only. HO process requirements may change at time of actual HO. For each Bit location, a value of “0” indicates the associated reentry management mes-sages shall be required, a value of “1” indicates the reen-try management message may be omitted. Regardless of the HO Process Optimization TLV settings, the target Sta-tion may send unsolicited SBC-RSP and/ or REG-RSP management messages:Bit 0: Omit SBC-REQ/RSP management messages during reentry processingBit 1: Omit PKM Authentication phase except TEK phase during current re-entry processingBit 2: Omit PKM TEK creation phase during re-entry pro-cessingBit 3: Omit Network Address Acquisition management messages during current re-entry processingBit 4: Omit Time of Day Acquisition management mes-sages during current reentry processingBit 5: Omit TFTP management messages during current re-entry processingBit 6: Full service and operational state transfer or sharing between serving station and target station (All static and dynamic context, e.g., ARQ window contents, timer, counters, state machinesBit 7: Omit REG-REQ/RSP management messages dur-ing current reentry processing
} — —
if(Skip-optional-fields[3]==0){ — —
Scheduling Service Supported 8 Bitmap to indicate if Station supports a particular schedulingservice. 1 indicates support, 0 indicates not support:Bit 0: Unsolicited Grant Service (UGS)Bit 1: Real-time Polling Service (rtPS)Bit 2: Non-real-time Polling Service (nrtPS)Bit 3: Best EffortBit 4: Extended real-time Polling Service (ertPS)If the value of bit 0 through bit 4 is 0b00000, it indicates no information on service available.Bits 5–7: Reserved; shall be set to zero.
} — —
If (Skip-optional-fields[4]==0){
Relay zone offset 8 The offset of the Relay zone that has the R-FCH and R-MAP, offset measured in number of OFDMA symbols after the preamble.
Table 166b—MR_NBR-INFO message format (continued)
Syntax Size(bits) Notes
Copyright © 2009 IEEE. All rights reserved. 41
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Relay zone offsetThe offset of the Relay zone that has the R-FCH and R-MAP, offset measured in number of OFDMA symbols after the preamble.
}
DCD Configuration Change Count 4 This represents the 4 LSBs of the Neighbor Station cur-rent DCD configuration change count.
UCD Configuration Change Count 4 This represents the 4 LSBs of the Neighbor Station cur-rent UCD configuration change count.
TLV Encoded Neighbor information variable TLV specific
} — —
}
if (Action Type bitmap[2] == 1){ — —
Delete_N_NEIGHBORS 8 Number of neighbors shall be deleted for this RS
for (j=0; j<Delete_N_NEIGHBORS;j++){ — —
Preamble Index 8 Indicates the deleted neighbors
} — —
} — —
if (Action Type bitmap [3]== 1){ — —
Skip-optional-fields bitmap 8 Bit [0]: if set to 1, omit Relay zone offset Bit [1]–[7]: Reserved.
Update_N_NEIGHBORS 8 Number of updated neighbors for this RS
for (j=0; j< Update_N_NEIGHBORS;j++) {
— —
Length 8 Length of message information within the iteration of Update_N_NEIGHBORS in bytes
Preamble Index 8 Indicates the updated neighbor
if (Skip-optional-fields[0]==0){ — —
Relay zone offset 8 The offset of the Relay zone that has the R-FCH and R-MAP, offset measured in number of OFDMA symbols after the preamble.
}
TLV Encoded Information variable TLV specific
} — —
}
Table 166b—MR_NBR-INFO message format (continued)
Syntax Size(bits) Notes
42 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
The following TLV parameters may be included if Action Type bitmap[3] is set to 1:
DCD Configuration Change CountRepresents the 4 LSBs of the Neighbor access station current DCD configuration change count.
UCD Configuration Change CountRepresents the 4 LSBs of the Neighbor access station current UCD configuration change count.
For each advertised Neighbor access station, the following TLV parameters may be included:
Mobility Feature SupportedSame as in 11.7.13.1.
The following TLV parameters may be included:
DCD_settingsThe DCD_settings is a TLV value that encapsulates a DCD message (excluding the generic MAC header and CRC) that may be transmitted in the advertised access station downlink channel. This information is intended to enable fast synchronization of the MS with the advertised access station downlink. The DCD settings fields shall contain only neighbor’s DCD TLV values that are different from the current access station corresponding values. For values that are not included, the MS shall assume they are identical to the corresponding values of the current access station. The duplicate TLV encoding parameters within a Neighbor access station shall not be included in DCD setting.
UCD_settingsThe UCD_settings is a TLV value that encapsulates a UCD message (excluding the generic MAC header and CRC) that may be transmitted in the advertised access station downlink channel. This information is intended to enable fast synchronization of the MS with the advertised access station uplink. The UCD settings fields shall contain only neighbor’s UCD TLV values that are different from the current access station’s corresponding values. For values that are not included, the MS shall assume they are identical to the current access station’s corresponding values. The duplicate TLV encoding within a Neighbor access station shall not be included in UCD setting.
PHY Mode ID (see 11.18.2)A 16-bit value that specifies the PHY parameters, including channel bandwidth, FFT size, cyclic prefix, and frame duration.
The MR_NBR-INFO shall contain the following TLVs:
HMAC/CMAC Tuple (see 11.1.2) The HMAC/CMAC Tuple shall be the last attribute in the message.
Copyright © 2009 IEEE. All rights reserved. 43
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
6.3.2.3.62 MR_Ranging-REP message
This message is used by a transparent RS or a non-transparent RS with a shared BSID to report to the MR-BS/superordinate RS the received CDMA ranging codes from SSs. This message shall be transmitted on the RS’s basic CID.
Table 166c—MR Ranging report (MR_RNG-REP) message format
Syntax Size(bit) Note
MR_RNG-REP_Message_Format() { — —
Management Message Type = 72 8 —
Report Type 1 0 = report CDMA code, 1 = report UL traffic mea-surement and/or Mode 1 or Mode 2 handover measurement
if (Report Type == 0) { — —
Size of Remaining CDMA codes 6 Amount of uplink bandwidth in bytes for CDMA codes remaining at the RS ready to be forwarded
H-FDD Group Indicator 1 0: Group 1, 1: Group 2
Frame Number Index 8 LSBs of relevant frame number
} else { — —
UL Measurement type 1 Shall be set to 1 if UL measurement is for Mode 1 or Mode 2 handover measurements else set to zero
Report CINR 1 Report CINR (0 = not report, 1 = report)
Report RSSI 1 Report RSSI (0 = not report, 1 = report)
RCID Type 2 0b00=Normal CID 0b01=RCID 11 0b10=RCID 7 0b11=RCID3
Reserved 2 Shall be set to zero
} — —
while(data remains){ — —
if(Report Type == 0) { — —
Ranging Code 8 Indicates the CDMA Code sent by the SS/RS
Ranging Symbol 8 Indicates the OFDMA symbol used by the SS/RS
Ranging subchannel 7 Identifies the Ranging subchannel used by the SS/RS
Channel Measurement 6 The mean CINR measured on the CDMA ranging code
} else { — —
RCID_IE() variable SS basic CID
44 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Size of Remaining CDMA Codes
The required bandwidth for sending remaining CDMA codes received by the RS but not forwarded due to lack of bandwidth.
Channel Measurement
The mean CINR measured on the CDMA ranging code shall be quantized in 1 dB increments, ranging from a minimum of –10 dB (encoded 0x00) to a maximum of 53 dB (encoded 0x3F) (see 8.4.11.3).
SS CINR mean
SS CINR mean shall be interpreted as a single value from –16 dB to 47.5 dB in units of 0.5 dB.
if(Report CINR == 1) { — —
SS CINR mean 8 Mean CINR measurement
} — —
if(Report RSSI == 1) { — —
SS RSSI mean 8 Mean RSSI measurement
} — —
} — —
Include TA 1 Include timing adjust (0=absent, 1=present)
Include PLA 1 Include power level adjust (0=absent, 1=present)
Include OFA 1 Include offset frequency adjust (0=absent, 1=present)
if(include TA ==1) { — —
Timing Adjust 32 Tx timing offset adjustment (signed 32-bit)
} — —
if(include PLA ==1) { — —
Power level Adjust 8 Tx Power level adjustment (signed 8-bit, 0.25 dB units).
} — —
if(include OFA ==1) { — —
Offset Frequency Adjust 32 Tx frequency offset adjustment (signed 32-bit, Hz units).
} — —
} — —
} — —
Table 166c—MR Ranging report (MR_RNG-REP) message format (continued)
Syntax Size(bit) Note
Copyright © 2009 IEEE. All rights reserved. 45
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
SS RSSI meanThe value shall be interpreted as an unsigned byte with units of 0.25 dB, such that 0x00 is interpreted as –103.75 dBm, an RS shall be able to report values in the range –103.75 dBm to –40 dBm
Timing AdjustThe amount of time required to adjust SS/RS transmission so the bursts will arrive at the expected time instance at the access station. Units are PHY specific (see 10.3).
Power Level AdjustSpecifies the relative change in transmission power level that the SS/RS is to make in order thattransmissions arrive at the access station at the desired power. When subchannelization is employed, the subscriber shall interpret the power offset adjustment as a required change to the transmitted power density.
Offset Frequency AdjustSpecifies the relative change in transmission frequency that the SS/RS is to make in order to better match the access station. (This is fine-frequency adjustment within a channel, not reassignment to a different channel.)
6.3.2.3.63 RS configuration command (RS_Config-CMD) message
The RS_Config-CMD message consists of TLVs that provide configuration parameters that are applicable to an RS, or to members of an RS group. It shall be sent by MR-BS to an RS on the RS’s primary management CID or an RS group using a multicast management CID. The message is used during network entry (configuration phase) or during operational mode to update the configuration of a RS. Upon receiving the message, the RS shall configure the parameters accordingly and respond with the MR_Generic-ACK message.
If the MR-BS does not receive an acknowledgment from an RS, it may retransmit the message before the Frame Number Action takes effect, while using for the Transaction ID the same value as in the initial transmission. If it is not possible to perform the retransmission before the Frame Number Action takes effect, the MR-BS may transmit the message with a later Frame Number Action. If at certain frame number the RS has received more than one message, then the messages that have older Transaction ID values shall be discarded.
Transaction IDThe counter used to generate the transaction ID shall be unique per CID per MR-BS.
Table 166d—RS configuration command (RS_Config-CMD) message format
Syntax Size(bit) Note
RS_Config-CMD_Message_Format { — —
Management Message Type = 73 8 —
Transaction ID 16 —
Frame Number Action 8 8-bit LSBs of the frame number
TLV Encoded Information variable TLV specific
} — —
46 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Frame Number ActionThis field contains the 8-bit LSBs of the frame number at the access station when the configuration shall be applied.
The RS_Config-CMD message may include the following TLVs for RS configuration:
Preamble index (see 11.25.1)
R-amble index (see 11.25.1)
BSID (see 11.25.1)
RS EIRP (see 11.25.1)
RS Frame Offset (see 11.25.1)
RS waiting time for Paging (see 11.25.1)
RS paging group (see 11.25.6)
The RS_Config-CMD message may include the following TLVs for MBS configuration:
RS waiting time for MBS (see 11.25.2)
Relay data early arrival report threshold (see 11.25.2)
The RS_Config-CMD message may include the following TLVs for RS operating in cooperative diversity mode:
Antenna assignment for cooperative diversity (see 11.25.3)
The RS_Config-CMD message may include the following TLVs for a scheduling RS operating in local CID allocation mode:
Contiguous CID allocation (see 11.25.4)
Bit partition CID allocation (see 11.25.4)
The RS_Config-CMD message may include the following TLVs for RS group configuration:
Assign/Remove multicast RS group CID (see 11.25.5)
Event-triggered reporting for access RS (see 11.25.5.1)
Periodic reporting for access RS (see 11.25.5.1)
Enable RSSI-based event-trigger (see 11.25.5.2)
Enable CINR-based event-trigger (see 11.25.5.2)
Enable TA-based event-trigger (see 11.25.5.2)
The RS_Config-CMD message may include the following TLV for configuration of the subchannel groups used by an RS on its access downlink:
Access downlink used subchannel indicator (see 11.25.1)
The RS_Config-CMD message may include the following TLV to indicate the mechanism to determine the frame configuration of the superordinate station. During the configuration phase of the network entry procedure this TLV shall be included in the RS_Config-CMD message.
Frame configuration mode (see 11.25.7)
Copyright © 2009 IEEE. All rights reserved. 47
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
The RS_Config-CMD message may include the following TLVs for R-amble configuration:
R-amble monitoring in centralized control mode (see 11.25.8.1)
Enable/Disable R-amble transmitting for synchronization (see 11.25.8.2)
Enable/Disable R-amble monitoring in random mode (see 11.25.8.2)
Enable/Disable R-amble transmitting for advertisement purpose (see 11.25.8.2)
The RS_Config-CMD message may include the following TLVs for multiple frame configuration:
DL subframe configuration (see 11.25.9)
UL subframe configuration (see 11.25.9)
The RS_Config-CMD message may include the following TLV for UL access link configuration:
Access UL allocated subchannels bitmap (see 11.25.11)
The RS_Config-CMD message may include the following TLVs for Direct Relay Zone configuration:
Direct Relay Zone configuration (see 11.25.10)
The RS_Config-CMD message may include the following TLVs for informing the scheduling RS of the TLVs to use in its RCD message:
DCD encodings (see 11.1.15)
UCD encodings (see 11.1.15)
The RS_Config-CMD message may include the following TLV for non-transparent RS operating in centralized scheduling mode:
RS DL fixed forwarding delay (see 11.25.12)
RS UL fixed forwarding delay (see 11.25.12)
The RS_Config-CMD message may include the following TLV for STR RS configuration:
RS second carrier configuration for TDD mode (see 11.25.13)
RS second DL carrier configuration for FDD mode (see 11.25.13)
RS second UL carrier configuration for FDD mode (see 11.25.13)
The RS_Config-CMD message shall contain the following TLVs:
HMAC/CMAC Tuple (see 11.1.2)
The HMAC/CMAC Tuple shall be the last attribute in the message
48 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
6.3.2.3.64 RS neighbor station measurement report (RS_NBR_MEAS-REP) message
This message may be transmitted by an RS to the MR-BS or superordinate RS on its primary management CID.
N_FrequencyNumber of frequency reported on.
N_Amble_IndexNumber of amble reported on. The amble is either a preamble or an R-amble.
The Report Response TLV shall include the physical CINR or RSSI of the preamble index.
This message shall include the following TLV:
Report Response (see 11.12)
Preamble with the least signal strength (see 11.22)This TLV is used for an RS to report the preamble index with the least signal strength. This information will help an MR-BS to assign a preamble to an RS that would cause the least interference to its neighborhood.
The RS_NBR_MEAS-REP message shall contain the following TLVs:
Table 166e—RS_NBR_MEAS-REP message format
Syntax Size (bit) Notes
RS_NBR_MEAS-REP_Message_Format(){ — —
Management Message Type = 74 — —
N_Frequency 8 Number of frequency reported on
for(n=0,n<N_Frequency) { — —
Carrier center frequency 24 RS should measure and report the signal in the specified carrier center frequency (kHz)
N_Amble_Index 8 Number of amble reported on
for (i=0, i< N_Amble_Index, i++){ — —
Amble Type 1 0: indicates the preamble index1: indicates the R-amble index
Amble Index 7 The 7 LSB of the preamble or R-amble index corresponds to the RSSI values in the neighbor list
Report Response TLVs variable TLV specific
} — —
} — —
TLV Encoded Information variable TLV specific
} — —
Copyright © 2009 IEEE. All rights reserved. 49
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
HMAC/CMAC Tuple (see 11.1.2) The HMAC/CMAC Tuple shall be the last attribute in the message.
6.3.2.3.65 Location information request and response messages
The location information defined in 6.3.2.3.65.1 is based on the World Geodetic System of 1984 (WGS84) datum [B50].1
6.3.2.3.65.1 MR location information request (MR_LOC-REQ) message
The MR_LOC-REQ message may be transmitted by an MR-BS to an RS to request the location information of the RS. This message can also be transmitted by an RS to the MR-BS to request the location of MR-BSs, BSs, and/or other RSs. The MR_LOC-REQ message shall be generated in the format shown in Table 166f.
The MR_LOC-REQ message can be set to any report mode as specified in Table 166f. When an RS sends the MR_LOC-REQ message, the report mode field shall be set to '0b00' (meaning non-periodic).
When the Report Mode is periodic report, the MR_LOC-REQ message shall contain the following TLV.
Report Period TLV (see 11.27.3)
When the MR_LOC-REQ message is transmitted by an RS to the MR-BS, it shall contain the following TLV.
Neighbor Station BSID TLV (see 11.27.4)
The MR_LOC-REQ message may contain the following TLVs.
HMAC/CMAC Tuple (see 11.1.2)The HMAC/CMAC Tuple shall be the last attribute in the message.
1The numbers in brackets correspond to those of the bibliography in Annex A.
Table 166f—MR_LOC-REQ message format
Syntax Size (bits) Notes
MR_LOC-REQ_Message_Format() { — —
Management Message Type = 75 8 —
Report Mode 2 0b00: Once0b01: Periodic report0b10: End periodic reporting (no MR_LOC-RSP message shall be transmitted in this case)0b11: Reserved
Reserved 6 Shall be zero
TLV Encoded Information variable TLV specific
} — —
50 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
6.3.2.3.65.2 MR_LOC-RSP message
The MR_LOC-RSP message shall be transmitted in response to a MR_LOC-REQ message. The transmitter sends MR_LOC-RSP message based on the report mode indicated in the MR_LOC-REQ message. The transmitter of this message shall generate the MR_LOC-RSP message in accordance with the format shown in Table 166g.
When the MR_LOC-RSP message is transmitted by an RS to the MR-BS, it shall contain one of the following TLVs.
Absolute Position (Long Format) TLV (see 11.27.1)
Absolute Position (Short Format) TLV (see 11.27.1)
Relative Position TLV (see 11.27.1)
When the MR_LOC-RSP message is transmitted by the MR-BS to an RS, it shall contain one of the following TLVs.
Neighbor Station BSID and Absolute Position (Long Format) (see 11.27.2)
Neighbor Station BSID and Absolute Position (short Format) (see 11.27.2)
Neighbor Station BSID and Relative Position (see 11.27.2)
The MR_LOC-RSP message may contain the following TLVs.
HMAC/CMAC Tuple (see 11.1.2)The HMAC/CMAC Tuple shall be the last attribute in the message.
6.3.2.3.66 MS scanning inform (MS_SCN-INF) message
An MS_SCN-INF message may be transmitted by an MR-BS to inform an access RS of MS scanning operation. An MR-BS includes the information of scanning intervals of MS(s) in an MS_SCN-INF message.
Table 166g—MR_LOC-RSP message format
Syntax Size (bits) Notes
MR_LOC-RSP_Message_Format() { — —
Management Message Type = 76 8 —
TLV Encoded Information variable TLV specific
} — —
Copyright © 2009 IEEE. All rights reserved. 51
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
An MR-BS shall generate MS_SCN-INF message in the format shown in Table 166h. The MS_SCN-INF message shall be transmitted on the RS’s basic CID.
Transaction IDThe counter used to generate the transaction ID shall be unique per CID per MR-BS.
The MS_SCN-INF message shall contain the following TLVs:
HMAC/CMAC Tuple (see 11.1.2) The HMAC/CMAC Tuple shall be the last attribute in the message.
Table 166h—MS_SCN-INF message format
Syntax Size (bits) Notes
MS_SCN-INF_Message_Format(){ — —
Management Message Type = 77 — —
Transaction ID 16 —
RCID Type 2 0b00=Normal CID0b01=RCID110b10=RCID70b11=RCID3
N_MS 6 Number of MSs
for (i=0, i< N_MS, i++){ — —
RCID_IE() variable Basic CID of MS
Start frame 8 Frame number from which the MS starts the first scanning interval
Scan duration 8 Duration (in units of frames) where the MS may perform scanning
Interleaving interval 8 Duration in frames. The period interleaved between scanning intervals when MS shall perform normal operation
Scan iteration 8 The number of iterating scanning interval
} — —
TLV Encoded Information variable TLV specific
} — —
52 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
6.3.2.3.67 MS scanning completion (MS_SCN-CLT) message
An MS_SCN-CLT message may be transmitted by an MR-BS to inform an access RS that the group of intervals of MS is terminated. An MR-BS shall generate MS_SCN-CLT messages in the format shown in Table 166i. MS_SCN-CLT message shall be transmitted on the RS’s basic CID.
The MS_SCN-CLT message shall contain the following TLVs:
HMAC/CMAC Tuple (see 11.1.2) The HMAC/CMAC Tuple shall be the last attribute in the message.
6.3.2.3.68 MS context information delete (MS_INFO-DEL) message
An MR-BS may transmit an MS_INFO-DEL message to an RS that is an old access station and controlled by the MR-BS when the MR-BS recognizes that MS attaches to a new access station or that Resource retain timer expires.
Table 166i—MS_SCN-CLT message format
Syntax Size (bits) Notes
MS_SCN-CLT_Message_Format(){ — —
Management Message Type = 78 8 —
RCID Type 2 0b00=Normal CID0b01=RCID110b10=RCID70b11=RCID3
N_MS 6 Number of MSs
for (i=0, i< N_MS, i++){ — —
RCID_IE() variable Basic CID of MS
} — —
TLV Encoded Information variable TLV specific
} — —
Copyright © 2009 IEEE. All rights reserved. 53
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
An MR-BS shall generate MS_INFO-DEL messages in the format shown in Table 166j.
Transaction IDThe counter used to generate the transaction ID shall be unique per CID per MR-BS.
The MS_INFO-DEL message shall contain the following TLVs:
HMAC/CMAC Tuple (see 11.1.2) The HMAC/CMAC Tuple shall be the last attribute in the message.
6.3.2.3.69 RS clock synchronization (CLK-SYNC) message
In MR network systems that require the MR-BS and non-transparent RSs to transmit the frame-start DL preamble synchronously, the CLK-SYNC message may be broadcast on the relay link by the MR-BS on the RS multicast management CID.
Table 166j—MS_INFO-DEL message format
Syntax Size (bits) Notes
MS_INFO-DEL_Message_Format(){ — —
Management Message Type = 79 8 —
Transaction ID 16 —
MS_ID 16 Basic CID of MS
TLV Encoded Information variable TLV specific
} — —
Table 166k—CLK-SYNC message format
Syntax Size(bits) Notes
CLK-SYNC_Message_Format(){ — —
Management Message Type = 80 8 —
Fraction GPS time 24 Fraction GPS time for frame-start DL preamble of current frame, where fraction GPS time is defined as:
The value is quantized with quantization step given by frame duration/224.
}
fractionGPStime
GPStime frameduration GPStimeframeduration----------------------------------------×–
=
54 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
6.3.2.3.70 MR association request (MR_ASC-REQ) message
An MR-BS may send this message to negotiate the association parameters over relay links.
MS MAC AddressMAC address of the MS for which the association parameters are negotiated
Scanning TypeRequested association level (see 6.3.21.1.3)
The MR_ASC-REQ message shall contain the following TLVs:
HMAC/CMAC Tuple (see 11.1.2) The HMAC/CMAC Tuple shall be the last attribute in the message.
6.3.2.3.71 MR association response (MR_ASC-RSP) message
The MR_ASC-RSP message is used in the following two cases: a) In distributed scheduling mode, an RS transmits an MR_ASC-RSP message in response to the
MR_ASC-REQ messageb) In centralized scheduling mode, the MR-BS may send an unsolicited MR_ASC-RSP message to an
RS.
Table 166l—MR_ASC-REQ message format
Syntax Size (bits) Notes
MR_ASC-REQ_Message_Format(){ — —
Management Message Type = 81 8 —
MS MAC Address 48 —
Scanning type 2 0b00: Reserved0b01: Scanning with Association level0;0b10: Scanning with Association level1;0b11: Scanning with Association level2.
Reserved 6 Shall be set to zero
TLV Encoded Information variable TLV specific
} — —
Copyright © 2009 IEEE. All rights reserved. 55
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
MS MAC AddressMAC address of the MS for which the association parameters are negotiated.
Scanning TypeOffered association level (see 6.3.21.1.3).
Rendezvous timeOffset calculated from the frame where MR_ASC-RSP is transmitted by the neighbor RS. The neighbor RS is expected to provide non-contention-based Ranging opportunity at the frame specified by Rendezvous time parameter.
CDMA codeA unique code assigned to the MS, to be used for association with the neighbor RS. Code isfrom the initial ranging codeset.
Transmission opportunity offsetA unique transmission opportunity in units of OFDMA symbol duration from the start of the frame specified by the Rendezvous time that is assigned to the MS for association with the neighbor RS.
The MR_ASC-RSP message shall contain the following TLVs:
HMAC/CMAC Tuple (see 11.1.2) The HMAC/CMAC Tuple shall be the last attribute in the message.
Table 166m—MR_ASC-RSP message format
Syntax Size (bits) Notes
MR_ASC-RSP_Message_Format(){ — —
Management Message Type = 82 8 —
MS MAC Address 48 —
Scanning Type 2 0b00: Reserved0b01: Scanning with Association level0;0b10: Scanning with Association level1;0b11: Scanning with Association level2.
if(Association Level > 0){ — —
Rendezvous time 8 Units are frame.
CDMA code 8 From initial ranging code set
Transmission opportunity offset 8 Units of OFDMA symbol duration
} — —
Reserved 6 Shall be set to zero
TLV Encoded Information variable TLV specific
} — —
56 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
6.3.2.3.72 RS_MOB_MEAS-REQ message
If the reporting Mode 1 (6.3.34.1.1) is used, an MR-BS shall transmit RS_MOB_MEAS-REQ message to request all or part of RSs in the same RS group for reporting their measurement results. This message shall be transmitted by the MR-BS on an RS multicast management CID to all RSs in the same RS group.
The format of the RS_MOB_MEAS-REQ message is depicted in Table 166n.
The RS_MOB_MEAS-REQ message shall contain the following TLVs:
HMAC/CMAC Tuple (see 11.1.2) The HMAC/CMAC Tuple shall be the last attribute in the message.
Table 166n—RS_MOB_MEAS-REQ message format
Syntax Size (bit) Notes
RS_MOB_MEAS-REQ_Message_Format(){ — —
Management Message Type = 83 8 —
SS CID 16 Basic CID of the SS that requested to report its measurement
Report metric 3 Bitmap indicating presence of certain metrics:Bit 0: SS RSSI meanBit 1: SS CINR meanBit 2: Timing Adjust
Report Frame 4 The measurement result is reported from the frame in which this message was received. A value of zero means that MR_RNG-REP is sent in the next frame.
RS_Report_Type 1 “0”: Part of RSs in the same RS group shall report“1”: All RSs except for the designated RS in the same RS group shall report
if(RS_Report_Type==0){ — —
RCID Type 2 0b00=Normal CID0b01=RCID110b10=RCID70b11=RCID3
N_RS 6 Number of RSs that need to report the mea-surement results
for(j=0;j<N_RS;j++){ — —
RCID_IE() variable Basic CID of the RS that needs to report the measurement result for the specified SS
} — —
} — —
TLV Encoded Information variable TLV specific
} — —
Copyright © 2009 IEEE. All rights reserved. 57
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
6.3.2.3.73 HARQ error report messages for multihop relay
When an RS receives an HARQ burst in error, the RS may report the error using the HARQ error report message. To specify the burst that is in error, the RS shall include the CID as well as the ACID in case of Chase HARQ, and include the CID, ACID and the SPID in case of IR HARQ, in the MAC message. Usage of HARQ error report message is described in 6.3.16.4.1.
HARQ error report messages are shown in Table 166o and Table 166p. Table 166o is the HARQ_CHASE_ER-REP message format. Table 166p is the HARQ_IR_ER-REP message format.
The HARQ_CHASE_ER-REP message shall contain the following TLVs:
HMAC/CMAC Tuple (see 11.1.2) The HMAC/CMAC Tuple shall be the last attribute in the message.
Table 166o—HARQ_CHASE_ER-REP message format
Syntax Size (bits) Notes
HARQ_Chase_ER-REP_Message_Format(){ — —
Management Message Type = 84 8 —
Num_HARQ_Data 4 —
RCID Type 2 0b00 = Normal CID0b01 = RCID110b10 = RCID 70b11 = RCID 3
for(i=0; i<Num_HARQ_Data; i++){ — —
RCID_IE() variable —
ACID 4 —
} — —
Padding variable Padding to reach byte boundary
TLV Encoded Information variable TLV-specific
} — —
58 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
The HARQ_IR_ER-REP message shall contain the following TLVs:
HMAC/CMAC Tuple (see 11.1.2) The HMAC/CMAC Tuple shall be the last attribute in the message.
6.3.2.3.74 MS sleep mode information message (MR_SLP-INFO)
An MR-BS may send the MR_SLP-INFO message to an RS to inform the RS about its subordinate MS(s) sleep mode information. This message conveys sleep mode information for the MSs attached through the RS. If any of an MS’s connection is removed from the sleep mode to idle mode, the MR-BS sends MR_SLP-INFO with Delete-Sleep-Info=1 for that particular MS. This removes only the corresponding sleep information from the RS.
Table 166p—HARQ_IR_ER-REP message format
Syntax Size (bits) Notes
HARQ_IR_ER-REP_Message_Format(){ — —
Management Message Type = 85 — —
Num_HARQ_Data 4 —
RCID Type 2 0b00 = Normal CID0b01 = RCID110b10 = RCID 70b11 = RCID 3
For(i=0; i<Num_HARQ_Data; i++){ — —
RCID_IE() variable —
ACID 4 —
SPID 2 —
} — —
Padding variable —
TLV Encoded Information variable TLV-specific
} — —
Copyright © 2009 IEEE. All rights reserved. 59
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Table 166q—MR_SLP-INFO message format
Syntax Size (bits) Notes
MR_SLP-INFO_Message_Format() { — —
Management Message Type = 86 8 —
Transaction ID 16 —
RCID Type 2 0b00 = Normal CID0b01 = RCID110b10 = RCID 70b11 = RCID 3
Number of MS 6 Number of MSs included in the message.
for (i=0; i<Number of MS; i++) { — —
RCID_IE() variable Identification of an MS
Number of Classes 8 Number of power saving classes
Delete-Sleep-Info 1 —
Reserved 7 —
for (i=0; i<Number of Classes; i++) { — —
Definition 1 —
Operation 1 —
Power_Saving_Class_ID 6 —
if (Operation == 1) { — —
Start_frame_number 7 —
Reserved 1 —
} — —
if (Definition == 1) { — —
Power Saving Class Type 2 —
Direction 2 —
Traffic_triggered_wakening_flag 1 —
TRF-IND_Required 1 —
Reserved 2 —
Initial sleep window 8 —
Listening window 8 —
Final-sleep window base 10 —
Final-sleep window exponent 3 —
Number_of_CIDs 3 —
for (i=0; i<Number_of_Sleep_CIDs; i++ { — —
60 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
The following parameters shall be included in the message:
Transaction IDUnique identifier set by the sender for identifying this transaction.The counter used to generate the transaction ID shall be unique per CID per MR-BS.
Number of MSTotal number of MS in the message.
Definition0 = Definition of Power Saving Class absent; in this case the message shall request activation or deactivation of Power Saving Class identified by Power_Saving_Class_ID.1 = Definition of Power Saving Class present.
Operation0 = Deactivation of Power Saving Class (for types 1 and 2 only).1 = Activation of Power Saving Class.
Power_Saving_Class_IDAssigned Power Saving Class identifier. The ID shall be unique within the group of Power Saving Classes associated with the MS. This ID may be used in further MR_SLP-INFO messages for activation / deactivation of Power Saving Class.
Start_frame_numberStart frame number for first sleep window.
Power Saving Class TypePower Saving Class Type of a connection.
DirectionDefines the directions of the class’s CIDs.0b00 = Unspecified. Each CID has its own direction assign in its connection creation. Can be DL, UL, or both (in the case of management connections).0b01 = Downlink direction only.
CID 16 —
} — —
} — —
If (TRF-IND_Required) { — —
SLPID 10 —
Reserved 6 —
} — —
} — —
} — —
TLV Encoded Information variable TLV specific
} — —
Table 166q—MR_SLP-INFO message format (continued)
Syntax Size (bits) Notes
Copyright © 2009 IEEE. All rights reserved. 61
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
0b10 = Uplink direction only.0b11 = Reserved.
Traffic_triggered_wakening_flag (for Type I only)0 = Power Saving Class shall not be deactivated if traffic appears at the connection as described in 6.3.20.2.1 = Power Saving Class shall be deactivated if traffic appears at the connection as described in 6.3.20.2.
TRF-IND_RequiredFor Power Saving Class Type I only.1 = BS shall transmit at least one TRF-IND message during each listening window of the Power Saving Class.This bit shall be set to 0 for other types.
Initial-sleep windowAssigned initial duration for the sleep window (measured in frames). For Power Saving Class type III, it is not relevant and shall be encoded as 0.
Listening windowAssigned Duration of MS listening window (measured in frames). For Power Saving Class type III, it is not relevant and shall be encoded as 0.
Final-sleep window baseAssigned final value for the sleep interval (measured in frames). For Power Saving Class type II, it is not relevant and shall be encoded as 0. For Power Saving Class type III, it is the base for duration of single sleep window requested by the message.
Final-sleep window exponentAssigned factor by which the final-sleep window base is multiplied in order to calculate the final-sleep window. The following formula is used: final-sleep window = final-sleep window base × 2^(final-sleep window exponent).For Power Saving Class type III, it is the exponent for the duration of single sleep window requested by the message.
SLPIDThis is a number assigned by the BS whenever an MS is instructed to enter sleep mode.
The MR_SLP-INFO message shall include the following parameters encoded as TLV tuples:
HMAC/CMAC Tuple (see 11.1.2)The HMAC/CMAC Tuple shall be the last attribute in the message.
62 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
6.3.2.3.75 RS access station selection request (RS_AccessRS-REQ) message
This message shall be transmitted by an MR-BS to an RS to indicate the access station to which the RS shall attach, if the second stage access station selection procedure as described in 6.3.9.16 is used during the initial network entry.
Preamble IndexThe preamble Index of the access station that shall be attached by the RS.
Transaction IDThe counter used to generate the transaction ID shall be unique per CID per MR-BS.
The RS_AccessRS-REQ message shall contain the following TLVs:
HMAC/CMAC Tuple (see 11.1.2) The HMAC/CMAC Tuple shall be the last attribute in the message.
Table 166r—RS_AccessRS-REQ message format
Syntax Size (bits) Notes
RS_AccessRS-REQ_Message_Format {
— —
Management Message Type = 87 8 —
Preamble Index 8 Preamble Index of the access station to which the RS shall attach
Transaction ID 16 —
TLV Encoded Information variable TLV specific
} — —
Copyright © 2009 IEEE. All rights reserved. 63
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
6.3.2.3.76 RS Scheduling (RS-SCH) message
This message may be used for the coordination of the uplink allocation across the infrastructure stations. It is sent by an scheduling station to a subordinate scheduling RS and is applicable to the non-tunnel case.
CIDIndicates the CID that shall be used for the allocation.
RS UL Allocation Frame OffsetIndicates the number of frame, starting from the next frame, in which the bandwidth grant for RS is valid.
BandwidthIndicates the size of the allocation, in units of bytes.
The RS-SCH message shall contain the following TLVs:
HMAC/CMAC Tuple (see 11.1.2) The HMAC/CMAC Tuple shall be the last attribute in the message.
6.3.2.3.77 RS_Member_List_Update message
The superordinate station of the RS group may transmit an RS_Member_List_Update message on the RS’s basic CID or the RS multicast management CID of the RS group to update the group members with the CIDs for which they shall be forwarding traffic. This message may be transmitted whenever there is a change in the CID list of the RS group members. The RSs receiving the message may respond with an MR_Generic-ACK or MR Acknowledgement Header for confirmation.
If the MR-BS does not receive an acknowledgment from an RS, it may retransmit the message before the Frame Number Action takes effect, while using for the Transaction ID the same value as in the initial transmission. If it is not possible to perform the retransmission before the Frame Number Action takes effect, the MR-BS may transmit the message with a later Frame Number Action. If at certain frame number
Table 166s—–RS-SCH message format
Syntax Size (bits) Notes
RS-SCH_Message_Format() { — —
Management Message Type = 88 8 —
N_CID 8 The number of CIDs included
for(i=0;i<N_CID; i++){ — —
CID 16 The CID for the MS
RS UL Allocation Frame Offset 8 In terms of number of frames
Bandwidth 8 In number of bytes
} — —
TLV Encoded Information variable TLV specific
} — —
64 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
the RS has received more than one message, then the messages that have older Transaction ID values shall be discarded.
Table 166t—RS_Member_List_Update message format
Syntax Size (bit) Notes
RS_Member_List_Update_Message_Format {
— —
Management Message Type = 89 8 —
Frame Number Action 4 The 4-bits LSB of the frame number at the superordi-nate station when the configuration shall be applied by all RS group members.
Configured_para_type 4 b0 = 1: RS sends acknowledgement if the message is received.b0 = 0: RS does not send acknowledgement if the mes-sage is receivedb1 = 1: data forwarding on a per CID basis b1 = 0: RSs in the group shall forward all datab2–b3: Reserved
if(b0 of Configured_para_type ==1){ — —
Transaction ID 16 —
} — —
if (b1 of Configured_para_type == 1 ) { — —
Number_RS 5 Number of RS group members involved with the CID list update
RCID type of MS Basic CID 2 0b00: Normal CID0b01: RCID110b10: RCID70b11: RCID3
Reserved 1 —
for (i=0;i<Number_RS;i++) { — —
RCID_IE() variable Reduced Basic CID of the RS group member.
N_CID_Add_designated 8 Number of connections for which the RS is the designated RS. If Mode2 is used this value is zero.
N_CID_Add_non_designated 8 Number of connections for which the RS is a non- designated RS.
for (j=0;j<N_CID_Add_designated;j++) { — —
Basic CID flag 1 1: Include Basic CID0: Do not include Basic CID
if(Basic CID flag == 1){ — —
RCID_IE() variable Reduced basic CID of the MS
} — —
Copyright © 2009 IEEE. All rights reserved. 65
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Transaction IDThe counter used to generate the transaction ID shall be unique per CID per MR-BS
The RS_Member_List_Update message may include the following parameter encoded as TLV-tuples:
HMAC/CMAC Tuple (see 11.1.2)
CID 16 For this CID of MS the RS is designated. Irrespective of the current RS assignment for a given CID, the indi-cated RS would be a designated RS for this CID and shall forward data and measurements.
} — —
for(j=0;j<N_CID_Add_non_designated;j++){
— —
Basic CID flag 1 1: Include Basic CID0: Do not include Basic CID
if(Basic CID flag == 1){ — —
RCID_IE() variable Reduced basic CID of the MS
} — —
CID 16 For this CID of the MS the RS is non-designated. Irre-spective of the current RS assignment for a given CID, the indicated RS would be a non-designated RS for this CID and shall forward only traffic data.
} — —
N_CID_Remove 8 Number of CIDs to be removed from the forwarding list
for(j=0;j<N_CID_Remove;j++){ — —
RCID_IE() variable MS basic CID to be removed
} — —
} — —
Padding variable Padding to reach byte boundary
TLV Encoded Information variable TLV specific
} — —
Table 166t—RS_Member_List_Update message format (continued)
Syntax Size (bit) Notes
66 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
6.3.2.3.78 MR piggybacked bandwidth request information (MR_PBBR-INFO) message
This message is used by the MR-BS to notify a scheduling RS with centralized security control of the information contained in an encrypted piggybacked BW request. This message is transmitted by the MR-BS on the RS’s basic CID.
The MR_PBBR-INFO message shall include the following parameter encoded as TLV tuples:
HMAC/CMAC Tuple (see 11.1.2.)
6.3.2.3.79 MR generic acknowledgement (MR_Generic-ACK) message
An RS may send this message to acknowledge the receipt of any of the following messages: MS_SCN-INF MS_INFO-DEL MR_SLP-INFO RS_AccessRS-REQ RCD RS_Member_List_Update RS_Config-CMD DCD UCD
Table 166u—MR_PBBR-INFO message format
Syntax Size(bits) Note
MR_PBBR-INFO_Message_Format(){ — —
Management Message Type = 90 8 —
N_PB-BR_INFO 8 Number of PB-BR Information.
for (i=0; i<N_PB-BR_INFO; i++) { — —
CID 16 The CID shall indicate the connection for which uplink bandwidth is requested.
PN_Flag 1 0: indicates Packet Number field is invalid. 1: indicates Packet Number field is valid.
Packet Number 31 Packet Number that is attached to MAC PDU containing the grant management subheader.
Grant Management Subheader Information
16 See Table 20
} — —
TLV Encoded Information variable TLV specific
} — —
Copyright © 2009 IEEE. All rights reserved. 67
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
This message is transmitted on the RS’s basic CID. If this message is required to acknowledge the receipt of any specific message, unsolicited uplink bandwidth may be provided to RS to transmit this message to the superordinate station. The message format of MR_Generic-ACK message is shown in Table 166v.
The following parameters shall be included in the message:
Transaction IDTransaction ID is taken from corresponding MAC management message that is being acknowledged.The counter used to generate the transaction ID shall be unique per CID per MR-BS.
The MR_Generic-ACK message may include the following parameter encoded as TLV tuples:
HMAC/CMAC Tuple (see 11.1.2)The HMAC/CMAC Tuple attribute contains a keyed message digest (to authenticate the sender). The HMAC Tuple attribute shall be the final attribute in the message.
6.3.2.3.80 RS access MAP (RS_Access-MAP) message
The MR-BS shall generate this message for each non-transparent RS operating in centralized scheduling mode within its MR-cell. This message shall be sent to the RS on the RS’s basic CID or RS multicast CID for RS group. It contains allocation information for the RS to transmit in the access zone. Upon receiving an RS_Access-MAP message, the RS shall compose an FCH, and possibly the associated MAPs such as the DL/UL-MAP, compressed DL/UL-MAP, SUB-DL-UL-MAPs, and HARQ MAP, etc., based on the RS_Access-MAP and other related configuration messages.
Table 166v—MR_Generic-ACK message format
Syntax Size(bits) Note
MR_Generic-ACK_Message_Format(){ — —
Management Message Type = 91 8 —
Transaction ID 16 —
TLV Encoded Information variable TLV specific
} — —
68 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Table 166w—RS Access MAP message format
Syntax Size(bits) Notes
RS _Access-MAP_Message_Format{ — —
Management Message Type = 92 8 —
Indicator 12 Bit 0: 0: Parameters of DL_Frame_Prefix remainsame with the latest Configuration, 1: The parameters of DL_Frame_Prefix are updated.Bit 1: 0: RS shall use Normal map format, 1: RS shall use Compressed map formatBit 2: 0: DL-MAP not included, 1: DL-MAP includedBit 3: 0: UL-MAP not included, 1: UL-MAP includedBit 4: 0: SUB-DL-UL-MAP not included, 1: SUB-DL-UL-MAP includedBit 5: 0: HARQ-MAP not included, 1: HARQ-MAP includedBit 6: 0: RS BW-ALLOC IE not included, 1: RS BW-ALLOC IE includedBit 7: 0: DL_Transmit_Reference_IE not included, 1: DL_Transmit_Reference_IE includedBit 8: H-FDD MAP Indicator. 0: MAP1 (Group-1), 1: MAP2 (Group-2)Bit 9–11: Reserved
Frame number 4 4 LSB of the frame number in which the corresponding message(s) shall be transmitted by the RS on the access link.
if(bit 0 of Indicator == 1 ) { — —
Used subchannel bitmap 6 “Used subchannel bitmap” in DL Frame Prefix.
Repetition Coding Indication 2 “Repetition Coding Indication” in DL Frame Prefix.
Coding Indication 3 “Coding Indication” in DL Frame Prefix.
} — —
if(bit 2 of Indicator == 1) { — Information for RS DL-MAP or Compressed DL-MAP.
DCD Count 8 “DCD Count” in DL-MAP or Compressed DL-MAP.
No. OFDMA Symbols 8 “No. OFDMA Symbols” in DL-MAP orCompressed DL-MAP.
DL IE count 8 Number of DL-MAP IE.
For (i = 0; i < DL IE count; i++) { — —
if(RS DL fixed forwarding delay is not set and DIUC <= 12){
— —
DL_Allocation_Reference_IE() variable —
} — —
DL-MAP_IE () variable “DL-MAP IE” in DL-MAP or Compressed DL-MAP.
} — —
} — —
Copyright © 2009 IEEE. All rights reserved. 69
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
if(bit 3 of Indicator == 1 ) { — Information for RS UL-MAP or Compressed UL-MAP
UCD Count 8 “UCD Count” in UL-MAP or Compressed UL-MAP
UL IE count 8 Number of UL-MAP IE
For (i = 0; i < UL IE count; i++) { — —
UL-MAP_IE () variable “UL-MAP IE” in UL-MAP or Compressed UL-MAP
} — —
} — —
if(bit 4 of Indicator == 1) { — SUB-DL-UL-MAP information
Nr of SUB-MAP 2 Number of SUB-DL-UL-MAP
For (i = 0; i < Nr of SUB-MAP; i++) { — —
Reduced SUB-DL-UL-MAP() variable —
} — —
} — —
if(bit 5 of Indicator == 1) { — HARQ-MAP information
Nr of HARQ-MAP 2 Number of HARQ-MAP
For (i = 0; i < Nr. Of HARQ-MAP; i++) { — —
Reduced HARQ-MAP() variable —
} —
} — —
if(bit 6 of Indicator == 1) { — —
Nr of IE 4 Number of IE
For(i=0;i<Nr. of IE; i++){ — —
RS_BW_Alloc_IE() variable —
} — —
} — —
if(bit 7 of Indicator ==1) { — —
RCID type 2 0b00: Normal CID0b01: RCID 110b10: RCID 70b11: RCID 3
CID_based_forwarding_enabled 1 0b0: disabled0b1: enabled
Nr of IE 4 Number of IE
For(i=0; i<Nr. of IE; i++) { — —
Table 166w—RS Access MAP message format (continued)
Syntax Size(bits) Notes
70 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
The RS_Access-MAP message may include the following parameter encoded as TLV tuples:
HMAC/CMAC Tuple (see 11.1.2)
DL_Transmit_Reference_IE () variable —
} — —
} — —
Padding variable Padding to reach byte boundary
TLV Encoded Information variable TLV specific
} — —
Table 166x—Reduced SUB-DL-UL-MAP
Syntax Size(bits) Notes
Reduced SUB-DL-UL-MAP() { — —
RCID_Type 2 “RCID_Type” in SUB-DL-UL-MAP.
HARQ ACK offset indicator 1 “HARQ MAP ACK offset indicator” in SUB-DL-UL-MAP.
If (HARQ ACK offset indicator == 1){ — —
DL HARQ ACK offset 8 “DL HARQ ACK offset” in SUB-DL-UL-MAP.
UL HARQ ACK offset 8 “UL HARQ ACK offset” in SUB-DL-UL-MAP.
} — —
DL IE count 8 “DL IE count” in SUB-DL-UL-MAP.
For (i = 0; i < DL IE count; i++) { — —
if(RS DL fixed forwarding delay is not set and DIUC <= 12){
— —
DL_Allocation_Reference_IE() variable —
} — —
DL-MAP_IE () variable “DL-MAP IE” in SUB-DL-UL-MAP.
} — —
OFDMA Symbol offset 8 “OFDMA Symbol offset” in SUB-DL-UL-MAP.
Subchannel offset 7 “Subchannel offset” in SUB-DL-UL-MAP.
Table 166w—RS Access MAP message format (continued)
Syntax Size(bits) Notes
Copyright © 2009 IEEE. All rights reserved. 71
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
The MR-BS may transmit the DL_Allocation_Reference_IE when sending RS-Access-MAP messages to the RS to inform the RS of the bandwidth allocation given to the RSs’ access zone. Each DL Allocation Reference IE is associated with a DL MAP IE with DIUC 0–12. When included, the DL_Allocation_Reference_IE shall be included before the associated DL-MAP_IE. The associated DL-MAP_IE includes a data burst allocation that is referenced by the DL Allocation Reference IE.
UL IE count 8 Number of UL-MAP IE.
For (i = 0; i < UL IE count; i++) { — —
UL-MAP_IE () variable “UL-MAP IE” in SUB-DL-UL-MAP.
} — —
} — —
Table 166y—Reduced HARQ-MAP
Syntax Size(bits) Notes
Reduced HARQ-MAP() { — —
Compact UL-MAP appended 1 “Compact UL-MAP appended” in HARQ-MAP
DL IE count 6 “DL IE count” in HARQ-MAP
For (n = 0; n < DL IE count; n++) { — —
Compact DL-MAP IE() variable “Compact DL-MAP IE” in HARQ-MAP
} — —
if (Compact_UL-MAP appended == 1){ — —
UL IE count 6 Number of compact UL-MAP IE
For (n = 0; n < UL IE count; n++) { — —
Compact UL-MAP_IE() variable “Compact UL-MAP IE” in HARQ-MAP
} — —
} — —
} — —
Table 166x—Reduced SUB-DL-UL-MAP (continued)
Syntax Size(bits) Notes
72 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Table 166z—DL Allocation Reference IE
RS_BW_Alloc_IE is transmitted to an RS from MR-BS in RS_Access-MAP message. This IE provides the allocation to RS for transmission of messages composed by the RS over the access link to MSs. An RS may modify the CID in the DL-MAP-IE pointed by RS_BW_Alloc_IE.
Syntax Size(bits) Notes
DL_Allocation_Reference_IE(){ — —
Num_Connections 4 Number of connections included in the associated allocation.
For(i=0;i<Num_Connections;i++){ — —
CID 16 CID of connection.
Num_Received_Frame 4 —
For(j=0;j<Num_Received Frame; j++){ — —
Received_Frame 4 LSB of frame number where the MAC PDUs are received by the RS.
Num_MAC PDU 4 Total data allocated for this connection, in unit of MAC PDU.
} — —
} — —
Padding variable Padding to reach byte boundary.
} — —
Table 166aa—RS_BW_Alloc_IE format
Syntax Size(bits) Notes
RS_BW_Alloc_IE () { — —
Type 2 0b00:Response for RS BR header0b01:RS broadcasting RNG-RSP0b10: unsolicited DL bandwidth allocation to RS by MR-BS0b11:Reserved
if(Type==0x00){ — —
TID 4 Transaction ID.
DL-MAP IE index 8 RS shall transmit message on the burst described by the DL MAP IE within the DL-MAP message described in the RS_Access-MAP.
}else if(Type==0x01){ — —
Frame Number Index 4 LSBs of relevant frame number.
Copyright © 2009 IEEE. All rights reserved. 73
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
An MR-BS or RS may send RS_Access-MAP including DL_Transmit_Reference_IE to the immediate subordinate RSs to indicate the bursts to be forwarded by Ns and Nr in the IE. If CID_based_forwarding_enable is set to 1, the CID-based forwarding scheme shall be used by encoding the CID table in the CID loop of the MAP IE(s) to be forwarded. Otherwise, the data forwarding shall be performed as follows. The first Lk included in DL_Transmit_Reference IE refers to number of bytes in the burst that is forwarded by Subset-k. The second Lk refers to the next Lk bytes after the bytes indicated by the first Lk, etc.
Number of rejected SS 4 Number of rejected SS (i.e., RNG-RSP message with status “Abort”)
INC RNG SUC 1 Include bandwidth for RNG-RSP message with sta-tus “success” (0b1:no, 0b1:yes).
IND DFO 1 Include bandwidth for RNG-RSP message contain-ing downlink frequency override (0b1:no, 0b1:yes).
DL-MAP IE index 8 RS shall transmit message on the burst described by the DL MAP IE within the DL-MAP message described in the RS_Access-MAP.
}else if(Type==0x10){ — —
Message Type 2 0b00: DCD0b01: UCD0b10–0b11:Reserved
DL-MAP IE index 8 RS shall transmit message on the burst described by the DL MAP IE within the DL-MAP message described in the RS_Access-MAP.
} — —
} — —
Table 166aa—RS_BW_Alloc_IE format (continued)
Syntax Size(bits) Notes
74 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Table 166ab—DL Transmit Reference IE format
RCID_IE()This field indicates the reduced basic CID of the RS. RSs are enumerated according to the order they are listed, e.g., the first RCID_IE() in the list becomes RS 0, etc., to be used as reference to the subset members.
Subset_IndexThis field indicates the subset members of which will forward the burst indicated by Lk or the designated MAP IEs. Subset-k contains RS j, where {j : uj = 1 with uj the j'th bit of [uN-1 ... u1 u0]=binary(k,N). Here, binary(k,N) denotes the binary representation of k with N bits, e.g., for N = 2, Subset-1 = {RS 0}, Subset-2 = {RS 1}, and Subset-3 = {RS 0, RS 1}. For example, if Subsets 1 and 3 are included and CID-based forwarding is disabled, the bursts lengths L1 and L2 for Subsets 1 and 3, respectively, are included in the MAP IE.
Syntax Size(bits) Notes
DL_Transmit_Reference_IE () { — —
Number_RS 4 Number of RSs involved in the DL Transmit Refer-ence IE.
for(i=0;i<Number_RS;i++){ — —
RCID_IE() variable Reduced RS basic CID.
} — —
Ns 8 The first index of DL-MAP IE in the RS_Access-MAP the RS(s) shall forward.
Nr 8 Indicate the number of subsets in the lists as well as the number of MAP IEs in RS_Access-MAP the RS(s) shall forward.
for(k=1;k<=Nr;k++){ — —
Subset_Index Number_RS bits
The index, k, of the subset sk.
} — —
if(CID_based_forwarding_enabled ==0){ — —
for(k=1;k<=Nr;k++){ — —
Lk 16 Burst length in bytes to be forwarded by members of subset sk
} — —
} — —
Padding variable Shall be set to 0
} — —
Copyright © 2009 IEEE. All rights reserved. 75
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
6.3.2.3.81 RS Relay MAP (RS_Relay-MAP) message
The MR-BS shall generate this message for each non-transparent RS in its MR-cell operating in centralized scheduling mode with one or more subordinate RSs. This message contains allocation information for the RS to transmit in the relay zone to its subordinate RSs. This message shall be sent using basic CID for RS or multicast CID for RS group. Upon receiving an RS_Relay-MAP message, the RS shall compose an R-FCH and R-MAP based on the RS_Relay-MAP and other related configuration messages. MR-BS may transmit DL_Allocation_Reference_IE when sending RS_Relay-MAP messages to RS to inform RS the bandwidth allocation of RSs’ relay zone. Each DL Allocation Reference IE is associated with a DL MAP IE with DIUC 0–12. When included, the DL_Allocation_Reference_IE shall be included before the associated DL-MAP_IE. The associated DL-MAP_IE includes a data burst allocation that is referenced by the DL Allocation Reference IE.
Table 166ac—RS Relay MAP message format
Syntax Size(bits) Notes
RS_Relay-MAP_Message_Format{ — —
Management Message Type = 93 8 —
Frame number 8 8 LSB of the frame number in which the corre-sponding message(s) shall be transmitted by the RS on the relay link.
R_Zone_Prefix Change Indication 1 R_Zone_Prefix is used for RS relay zone. 0: All the parameters in R_Zone_Prefix remain same with the latest configuration. 1: The parameters in R_Zone_Prefix are updated.
Unsolicited DL BW Indication 1 Unsolicited DL bandwidth allocated in the R-MAP for sending RCD message(0: not included, 1: included).
H-FDD R-MAP Indicator 1 0: MAP1 (Group-1), 1: MAP2 (Group-2).
Reserved 1 Shall be zero
if (R_Zone_Prefix Change Indication == 0b1) {
— —
R_Zone_Location 8 “R_Zone_Location” in R-FCH.
Used subchannel bitmap 6 “Used subchannel bitmap” in R-FCH.
FEC Code type and modulation type 4 “FEC Code type and modulation type” in R-FCH.
Repetition Coding Indication 1 “Repetition Coding Indication” in R-FCH.
} — —
DL IE count 6 Number of DL-MAP_IE.
For (i = 0; i < DL IE count; i++) { — —
if(RS DL fixed forwarding delay is not set and DIUC <= 12){
— —
DL_Allocation_Reference_IE() variable —
} — —
76 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
The RS_Relay-MAP message may include the following parameter encoded as TLV tuples:
HMAC/CMAC Tuple (see 11.1.2)
6.3.2.3.82 MOB_INF-IND message
This message may be used for the MR-BS to notify the scheduling RS that it shall provide or cancel providing bandwidth allocation for the MS to send an RNG-REQ message during HO.
DL-MAP_IE () variable “DL-MAP_IE” in R-MAP.
} — —
UL IE count 6 Number of UL-MAP_IE.
For (i = 0; i < UL IE count; i++) { — —
UL-MAP_IE () variable “UL-MAP_IE” in R-MAP.
} — —
R-link IE count 6 —
For (i=1; i<= R-link count; i++) { — —
R-link specific IE () variable “UL-MAP_IE” in R-MAP.
} — —
If(Unsolicited DL BW Indicator==0b1){ — —
DL-MAP IE index 8 RS shall transmit the RCD message on the burst described by the DL MAP IE index within the R-MAP message described in the RS_Relay-MAP.
} — —
Padding variable Padding to reach byte boundary.
TLV Encoded Information variable TLV specific.
} — —
Table 166ad—MOB_INF-IND message format
Syntax Size(bits) Notes
MOB_INF-IND_Message_Format{ — —
Management Message Type = 94 8 —
MS MAC Address 48 —
Action_Indicator 1 0: Cancel, 1: Allocate
Reserved 7 —
Table 166ac—RS Relay MAP message format (continued)
Syntax Size(bits) Notes
Copyright © 2009 IEEE. All rights reserved. 77
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
MS MAC Address MAC address of the MS for which the RS shall provide or cancel providing Fast_Ranging IE.
Action Indicator An indicator to indicate the RS shall provide Fast_Ranging IE for the MS when the Action Indicator == 1 or cancel providing Fast_Ranging IE for the MS when Action Indicator == 0.
Action Time Action time, in units of frame, in which the RS provides Fast_Ranging IE for the MS. This parameter only exists when Action Indicator == 1.
The MOB_INF-IND message may include the following parameter encoded as TLV tuples:
HMAC/CMAC Tuple (see 11.1.2)
6.3.2.3.83 MS_Context-REQ message
This message is used to notify or request MS context to MR-BS or RS. This message is transmitted by RS or MR-BS using the RS’s basic CID.
Type:Notification: This type of message may be sent by a serving RS to its superordinate MR-BS in distributed security mode or by MR-BS to the target RS in both centralized and distributed security mode to notify of MS context. When this type of message is sent by the serving RS, it
If(Action_Indicator ==1){ — —
Action Time 8 Acting time when the RS provides Fast_Ranging IE for the MS
} — —
TLV encoded information variable HMAC/CMAC Tuple
} — —
Table 166ae—MS_Context-REQ message Format
Syntax Size(bits) Notes
MS_Context-Request_Message_Format{ — —
Management Message Type = 95 8 —
Transaction ID 16 —
Type 1 0x0: Notification0x1: Request
Reserved 7 Shall be set to 0
TLV encoded information variable —
} — —
Table 166ad—MOB_INF-IND message format (continued)
Syntax Size(bits) Notes
78 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
shall contain the MS context that the MR-BS does not possess. The SA descriptors TLV is part of the MS context included in this type of message. When the MR-BS relays it to the target RS, it shall add MS context it possesses.Request: This type of message may be sent by a target RS to its superordinate MR-BS in both distributed and centralized security mode or by MR-BS to the serving RS in distributed security mode.
The following parameters shall be included in the MS_Context-REQ of type=0 (notification) message:
SS MAC address TLV
The following parameters may be included in the MS_Context-REQ of type=0 (notification) message:BSID TLV
SBC-RSP encodings TLV
REG-RSP encodings TLV
AK context TLV
SA Descriptors TLV
Service Flow information TLV
The following parameters shall be included in the MS_Context-REQ of type=1 (request) message:
SS MAC address TLV
The following parameters may be included in the MS_Context-REQ of type=1 (request) message:
BSID TLV
The MS_Context-REQ message shall include the following parameter encoded as TLV tuples:
HMAC/CMAC Tuple (see 11.1.2)
6.3.2.3.84 MS_Context-RSP message
This message is used to notify or request MS context to MR-BS or RS. This message is transmitted by RS or MR-BS with using the RS’s basic CID.
Table 166af—MS_Context-RSP message format
Syntax Size(bits) Notes
MS_Context-Request_Message_Format{ — —
Management Message Type = 96 8 —
Transaction ID 16 —
Type 1 0x0: Acknowledgement0x1: Response
Reserved 7 Shall be set to 0
TLV encoded information variable —
} — —
Copyright © 2009 IEEE. All rights reserved. 79
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Type:Acknowledgement: This type of message may be sent by a target RS or MR-BS as an acknowledgement to MS_Context-REQ (Type=0).Response: This type of message may be sent by MR-BS or the serving RS as a response to MS_Context-REQ (Type=1). When this type of message is sent by the serving RS, it shall contain the MS context that the MR-BS does not possess. The SA descriptors TLV is part of the MS context included in this type of message. Then, the MR-BS relays it to the target RS after adding MS context it possesses.
The following parameters may be included in the MS_Context-RSP of type=1 (response) message:
SS MAC address TLV
BSID TLV
SBC-RSP encodings TLV
REG-RSP encodings TLV
AK context TLV
SA Descriptors TLV
Service Flow information TLV
The MS_Context-RSP message shall include the following parameter encoded as TLV tuples:
HMAC/CMAC Tuple (See 11.1.2)
6.3.2.3.85 MT_Transfer message
MT_Transfer message is applicable to a management tunnel connection in distributed security mode. That is, this message can only be used in a relay MAC PDU. A relay MAC header instead of a generic MAC header is placed before MT_Transfer message. An ingress station of a management tunnel may carry multiple MAC management messages from the connections belonging to the same management tunnel in an MT_Transfer message and deliver the message in a relay MAC PDU over the relay link to the egress station. This message is transmitted by the MT-CID of the management tunnel.
Table 166ag—MT_Transfer message format
Syntax Size (bits) Notes
MT_Transfer_Format(){ — —
Management Message Type = 97 8 —
Number of management messages 8 —
for(i=0;i<Number of management messages; i++){
— —
Management message without HMAC/CMAC TLV
variable Each message includes a MAC header
} — —
HMAC/CMAC TLV variable TLV specific
} — —
80 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Number of management messagesThe number of the MAC management messages encapsulated in this message
Management message without its HMAC/CMAC TLVIndividual MAC management message encapsulated in this message. The original HMAC/CMAC TLV in the management message is removed before it is encapsulated into this message.
The MT_Transfer message shall include the following parameter encoded as TLV tuples:
HMAC/CMAC Tuple (see 11.1.2)
6.3.3 Construction and transmission of MAC PDUs
6.3.3.2 Concatenation
Insert the following after the first paragraph of 6.3.3.2:
In MR networks, multiple MAC PDUs may be concatenated into a single transmission on both the relay link and the access link. Multiple relay MAC PDUs can be concatenated into a single transmission on the relay link.
Insert new subclause 6.3.3.8:
6.3.3.8 MR construction and transmission of MAC PDUs
Two modes for forwarding MAC PDUs belonging to a connection are specified within the standard. The tunnel mode is described in 6.3.3.8.1, and the CID based forwarding mode in 6.3.3.8.2.
The mode of RS operation (transparent or non-transparent), the type of scheduling (centralized or distributed) and the number of hops from the MR-BS to the MS/SS, determine which forwarding modes may be used.
In the case of a transparent RS in a two-hop topology, CID based forwarding shall be used.
The tunnel mode and the CID based forwarding mode may be used for non-transparent RSs.
When considering forwarding modes, it shall be assumed that RSs operating in centralized and distributed scheduling shall not be mixed along a single path i.e., it shall not be allowed for an RS to apply centralized scheduling if there is an RS on the same path with distributed scheduling and vice versa.
The above description does not apply to RS group operation.
MAC PDUs from connections that are not assigned to traverse a tunnel are constructed according to 6.3.3.1 through 6.3.3.7, and RSs forward those MAC PDU based on the CID of the connection.
Insert new subclause 6.3.3.8.1:
6.3.3.8.1 Transmission using tunnels
One or more tunnels may be established between the MR-BS and the access RS after the network entry is performed.
All MAC PDUs from a connection that is assigned to traverse a tunnel shall be transmitted through that tunnel. The mode for constructing and forwarding MAC PDUs from connections that traverse a tunnel is
Copyright © 2009 IEEE. All rights reserved. 81
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
called tunnel mode. In the tunnel mode, MAC PDUs that traverse a tunnel shall be encapsulated in a relay MAC PDU with the relay MAC header carrying the T-CID or MT-CID of the tunnel. Refer to 6.3.2 and 6.3.2.1.1.1 for the definition of the relay MAC PDU and relay MAC header, respectively. Multiple MAC PDUs from connections that traverse the same tunnel can be concatenated into a relay MAC PDU for transmission. The station at the ingress of the tunnel is responsible for encapsulating the MAC PDUs into relay MAC PDU, and the station at the egress of the tunnel is responsible for removing the relay MAC header. Stations through which a tunnel traverses may forward the relay MAC PDUs based on the T-CID or MT-CID in the relay MAC header. In this mode, multiple relay MAC PDUs, potentially from different tunnels traversing an RS can be concatenated into a single PHY burst.
When tunnel mode is used with an RS operating in centralized scheduling mode, Allocation Subheaders shall be included in relay MAC PDUs on the downlink to enable the receiving RS to match the MAC PDUs in the relay MAC PDU payloads with the IEs in the MAP messages it receives from the MR-BS to broadcast in the access and relay zones. Before forwarding a relay MAC PDU to the next station, the RS shall remove Allocation Subheader related to itself and calculate the CRC if needed. When operating in tunnel modes with centralized scheduling, the RS shall not forward packets that it cannot match with the MAP it is instructed to broadcast. Similarly, if the relay MAC PDUs or the MAP for a certain frame fails to arrive, it shall not forward any packets. If relay MAC PDUs fail to arrive or arrive in error, the RS shall replace the CIDs in the MAP IEs with its own CID (RS basic CID). If the MAP fails to arrive for a certain frame, the RS may transmit an STC DL zone IE and drop the MAC PDUs that are scheduled to be transmitted in that frame.
Insert new subclause 6.3.3.8.2:
6.3.3.8.2 Transmission using station CID
There are two schemes for RS to forward received data without using tunnels. The first one is called CID based forwarding and the other is burst-based forwarding. In the CID based forwarding scheme, the forwarding of MAC PDUs by each RS is performed based on the CID contained in the MAC PDU header. When forwarding using this scheme, the inclusion of CID in the DL-MAP is optional. When operating in centralized scheduling mode, if the RS DL fixed forwarding delay TLV or the RS UL fixed forwarding delay TLV is included in RS_Config-CMD message, the RS shall forward each MAC PDU at the frame determined by the receiving frame of the MAC PDU plus the fixed delay specified in the TLV. If the RS DL fixed forwarding delay TLV is not included in RS_Config-CMD, the MR-BS shall include DL Allocation Reference IEs in RS_Relay-MAP and RS_Access-MAP messages.
For transparent RSs, the MR-BS shall send the RS_Member_List_Update (see 6.3.2.3.77) to update the CID list of the transparent RSs for CID based forwarding in both DL and UL. If the MR-BS does not receive MR_Generic-ACK message from all RSs designated in the RS_Member_List_Update message after the Frame Action Number, the burst-based forwarding scheme may be used to replace its original forwarding rules to forward the data to the MS.
In burst-based forwarding scheme, the forwarding of the bursts is performed by encoding the forwarding rules in MAP IEs. In DL, the data burst that are scheduled to be relayed by the RS is described by the DL-MAP_IE with the RS primary management CID. The MR-BS shall send the forwarding rules to the RS via R-MAP including the DL_Burst_Transmit_IE (see 8.4.5.3.33). The RS shall forward the data in allocations defined by those DL-MAP_IEs indicated by the DL_Burst_Transmit_IE. In UL, the data bursts that are scheduled to be relayed by the RS(s) is described by the UL-MAP_IE with UL_Burst_Receive_IE (see 8.4.5.4.30). The RS shall receive the data in allocations defined by those UL-MAP_IEs following the UL_Burst_Receive_IE and forward to its superordinate station in the next available allocation, defined by the UL-MAP_IE, in UL relay zone.
82 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Insert new subclause 6.3.3.8.3 as follows:
6.3.3.8.3 Fragmentation and packing of relay MAC PDU
In tunnel mode, a tunnel data unit (TDU) is defined as a set of concatenated MAC PDUs encapsulated in a relay MAC PDU at the ingress station. When the functions of fragmentation and packing of a TDU are enabled, a fragmentation subheader (FSH) (see 6.3.2.2.8.3) is inserted in the relay MAC PDUs. A TDU sequence number (TSN in Table 37c and Table 37d) is assigned to each TDU by the ingress station. During the fragmentation or packing processes, the value of TSN remains the same for all the fragments from the same TDU.
A TDU may be fragmented or multiple TDUs may be packed at the ingress station or at an intermediate RS before being encapsulated in the relay MAC PDU. When only one TDU or only one fragmented TDU is encapsulated in a relay MAC PDU, an FSH is inserted before the TDU or the TDU fragment. The length of the fragmented TDU can be interpreted from the length field specified in the relay MAC header. The more fragment (MF) flag is used to indicate whether the fragment is the last fragment of the TDU. Fragment offset is used to specify the location of the fragment relative to the beginning of the TDU. When more than one TDU or fragments of TDUs are encapsulated in a relay MAC PDU, a PSH (see 6.3.2.2.8.4) is placed before each TDU or fragments of TDUs. The TDUs or fragmented TDUs packed into a relay MAC PDU may originate from the same or different TDUs (i.e., with the same or different TDU sequence number). The length field in the PSH represents the length of the TDU or the fragmented TDU.
When an intermediate RS receives multiple fragments with the same TDU sequence number from its previous hop station, it may pack or fragment the received TDUs or fragments of TDUs before forwarding them to its next hop station. The intermediate RS may send a fragment of a TDU without waiting until the entire TDU is received. Alternately, an intermediate RS may reassemble the fragments with the same TDU sequence number and contiguous offsets into one larger fragment before forwarding them to the next hop station.
The egress station reassembles the fragments with the same TDU sequence number and then retrieves individual MAC PDUs from the assembled TDU.
When an egress station receives a fragment with a new TDU sequence number, it shall start a timer T72. The egress station shall reset the associated timer T72, if it has received all the fragments of the TDU before the expiration of this timer T72.
For distributed security mode with enabled relay MAC PDU encryption, the egress station shall discard all the fragments of this TDU at the expiration of the timer T72 if the egress station is unable to reassemble the full TDU.
For centralized security mode and distributed security mode with disabled relay MAC PDU encryption, the egress station can start to retrieve and forward MAC PDUs from the received fragments of the TDU without waiting until the entire TDU is reassembled. At the expiration of the timer T72, the egress station shall discard any fragments of the TDU, if no MAC PDUs can be retrieved from these fragments.
Figure 47a shows one example of fragmentation and packing of relay MAC PDUs at the ingress station, intermediate RS, and egress station of a tunnel.
Copyright © 2009 IEEE. All rights reserved. 83
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Figure 47a—Example of fragmentation and packing of relay MAC PDUs
6.3.4 ARQ mechanism
Insert new subclause 6.3.4.2.2:
6.3.4.2.2 ARQ Feedback IE for Tunnel packet
Table 170a defines the ARQ Feedback IE for tunnel packet used between MR-BS and RS by the receiver to signal positive or negative acknowledgments. A set of IEs of this format may be transported either as a packed payload (“piggybacked”) within a packed MAC PDU or as a payload of a standalone MAC PDU. The ARQ feedback IE contains R-ACK and/or R-NAK information corresponding to the tunnel packets for all of relay link. ‘LAST_TSN’ in the ARQ feedback IE indicates the highest TSN among the TDUs that have been received by the receiver, and ‘TSN’ indicates the TSN of an error TDU or an error TDU fragment having a lesser sequence number than ‘LAST_TSN’. All of TDUs or TDU fragments not indicated by error are considered as positive acknowledged in the transmitter. The ARQ feedback IE can be applied to both two-link ARQ and hop-by-hop ARQ mode.
R-CRCRelay MAC header FS
H Relay MAC header P
SH
PS
H R-CRC
R-CRCRelay MAC header FS
H R-CRCRelay MAC header P
SH
PS
H
Ingress RSR-MAC PDUconstruction
Intermediate RS R-MAC PDUconstruction
Egress RSR-MAC PDUconstruction
MPDU to be sent by ingress station
TDU created by ingress station
Relay MAC PDU sent by ingress station in frame k and k+1
Fragments of TDUs or TDUs received by intermediate RS
Relay MAC PDUs sent by intermediate RS
Fragments of TDUs or TDUs received by egress station
TDUs reassembled by the egress station
MPDU recovered by egress station
84 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Table 170a—ARQ Feedback IE format for Tunnel packet
LAST TSNTSN value indicates the highest sequence number of the TDU among all the TDUs that have been successfully received by receiver.
TSNTSN value indicates the sequence number of the TDU that has not been received successfully in the receiver. TSN shall be less sequence number than ‘Last_TSN’.
N_ERROR_TDUNumber of error TDUs or TDU fragments. When N_ERROR_TDU =0, all TDUs with equal and lesser TSN values have been successfully received by the receiver.
FIFI(Fragment Indicator) represents whether the TSN value of the TDU is fragmented or not.
Syntax Size (bits) Notes
ARQ_feedback_IE(LAST){ variable —
T-CID 16 The ID of the tunnel connection
LAST 1 0 = More ARQ feedback IEs in the list1 = Last ARQ feedback IE in the list
LAST_TSN 7 —
FI 1 0x0 = Unfragmented0x1 = fragmented
if(FI==1){ — —
R-ACK_S_FO 12 Start offset in byte of a TDU fragment with R-ACK
R-ACK_E_FO 12 End offset in byte of a TDU fragment with R-ACK
} — —
N_ERROR_TDU 7 Number of error TDUs or TDU fragments
For(i=0;i<N_ERROR_TDU;i++){ — —
TSN 7 —
FI 1 0x0 = Unfragmented0x1= Fragmented
if(FI==1){ — —
R-NAK_S_FO 12 Start offset in byte of a TDU fragment with R-NAK
R-NAK_E_FO 12 End offset in byte of a TDU fragment with R-NAK
} — —
} — —
Padding — Padding to reach byte boundary
} — —
Copyright © 2009 IEEE. All rights reserved. 85
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
R-ACK_S_FOIf FI =1, R-ACK_S_FO value indicates start point of the TDU fragment in byte that has been received.
R-ACK_E_FOIf FI =1, R-ACK_E_FO value indicates end point of the TDU fragment in byte that has been received.
R-NAK_S_FOIf FI =1, R-ACK_S_FO value indicates start point of the TDU fragment in byte that has not been received.
R-NAK_E_FOIf FI =1, R-ACK_E_FO value indicates end point of the TDU fragment in byte that has not been received.
6.3.4.6 ARQ operation
Insert new subclause 6.3.4.6.4:
6.3.4.6.4 ARQ modifications for relaying
In MR systems, there are three ARQ modes. The first mode is a end-to-end ARQ mode that is performed between an MR-BS and an MS; the second mode is a two-link ARQ mode that is performed both between a MR-BS and an access RS and between access RS and MS; and the third mode is hop-by-hop ARQ that is performed between each adjacent station where an adjacent station is either an MR-BS, RS, or MS. The support of ARQ mode is performed during the RS network entry.
In the end-to-end ARQ mode, the ARQ operation is same as 6.3.4. An RS does not have an additional ARQ functionality.
In other ARQ modes, ARQ operation between access RS and MS is same as 6.3.4. In two-link ARQ mode, the ARQ operation is divided into two links that are relay link between MR-BS and access RS and access link between access RS and MS. In hop-by-hop ARQ mode, the ARQ operation is divided over each link and between access RS and MS. Two-link ARQ is applicable in both tunnel- and non-tunnel based forwarding while hop-by-hop ARQ is applicable in only tunnel-based forwarding mode. These modes are supported by a scheduling RS operating in distributed security mode. The detailed procedure for two-link ARQ mode is described in the 6.3.4.6.4.1. The detailed procedure for hop-by-hop ARQ mode is described in 6.3.4.6.4.2.
Insert new subclause 6.3.4.6.4.1:
6.3.4.6.4.1 Two-link ARQ mode
For access link, the ARQ state machine runs between the access RS and the MS. For relay link, the ARQ state machine runs between the MR-BS and the access RS. The MR-BS schedules retransmission to access relay station when ARQ block or TDU is corrupted in the relay link. The RS schedules retransmission to MS when ARQ block is corrupted in the access link. When an intermediate RS exists between MR-BS and access RS, it just forwards the ARQ block and ARQ feedback information between MR-BS and access RS. In non-tunnel case, the ARQ feedback IE described in the 6.3.4.2.1 is used by MR-BS and access RS to ACK/NAK to corresponding data transmitted between MR-BS and access RS. In tunnel packet mode, ARQ feedback IE for tunnel packet described in 6.3.4.2.2 is used. Both ARQ feedback IEs are transported either as a packed payload (“piggybacked”) within a packed MAC PDU or as a payload of a standalone MAC PDU defined in 6.3.4.2.
86 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
In downlink ARQ operation, when MR-BS sends ARQ block or TDU to access RS, it waits for the ARQ feedback IE from access RS. When ARQ block or TDU is corrupted in the relay link, access RS sends NAK to MR-BS, and MR-BS schedules the retransmission of the corresponding ARQ block or TDU to access RS. When MR-BS receives R-ACK from access RS, it waits for the ACK from the MS relayed by access RS. Access RS may modify the ARQ feedback IE received from MS to inform only ACK to MR-BS. When MR-BS receives ACK from MS, it clears the buffer corresponding to ARQ block or TDU. When ARQ block is corrupted in the access link, access RS shall not send NAK to MR-BS and shall schedule the retransmission of ARQ blocks to MS. Access RS shall discard the ARQ block when ARQ block transmission failed in the access link after a timeout of the ARQ_BLOCK_LIFETIME. MR-BS or Access RS discards the corresponding ARQ block or TDU after the timeout of its ARQ_BLOCK_LIFETIME. MR-BS and RS ARQ_BLOCK_LIFETIME are independently operated in MR-BS and RS respectively.
In uplink ARQ operation, when access RS receives ARQ block correctly from MS, RS sends ARQ block or TDU to MR-BS. When MR-BS receives ARQ block or TDU correctly, MR-BS sends R-ACK to access RS and the access RS sends ACK to MS. When ARQ block or TDU is corrupted in the relay link, the retransmission shall be scheduled from access RS to MR-BS. Access RS discards the corresponding ARQ block after a timeout of ARQ_BLOCK_LIFETIME in access RS.
Insert new subclause 6.3.4.6.4.2:
6.3.4.6.4.2 Hop-by-hop ARQ mode
In this mode, the intermediate RSs are involved in the ARQ operation and ARQ state machine runs between adjacent stations. The ARQ state machine between adjacent stations is the same as defined in 6.3.4.6.2 and 6.3.4.6.3.
In downlink ARQ operation, when MR-BS/superordinate RS sends TDU to the subordinate RS, it waits for ARQ feedback IE for tunnel packets. When TDU is corrupted in the relay link, the subordinate RS sends back R-NAK, and the MR-BS/superordinate RS schedules the retransmission of TDU to the subordinate RS. When the MR-BS receives R-ACK from the subordinate RS, it waits for an ACK from the MS relayed by the intermediate RSs. Access RS may modify the ARQ feedback IE received from MS to inform only ACK to MR-BS. When MR-BS receives ACK from MS, it clears the buffer corresponding to ARQ blocks. When superordinate RS receives R-ACK from the subordinate RS, it clears the buffer corresponding to TDU.
When ARQ block is corrupted between the MR-BS/superordinate RS and subordinate RS, the superordinate RS, after receiving R-NAK, shall not relay R-NAK to superordinate station. Instead MR-BS/superordinate RS shall schedule the retransmission of TDU to subordinate RS. The MR-BS/RS shall discard the TDU when TDU retransmission failed on a link after the timeout of its ARQ_BLOCK_LIFETIME. MR-BS and RS ARQ_BLOCK_LIFETIME is independently operated in MR-BS and RS respectively.
In uplink ARQ operation, when an access RS receives the ARQ block correctly from MS, the RS sends TDU to the superordinate station. When MR-BS/RS receives TDU correctly, MR-BS/RS sends R-ACK to the subordinate RS. When TDU is corrupted in the relay link, the retransmission shall be scheduled from the subordinate RS to its superordinate RS/MR-BS. The MR-BS/RS discards the corresponding TDU after a timeout of its ARQ_BLOCK_LIFETIME.
ARQ feedback IE for tunnel packet described in 6.3.4.2.2 is used on the relay link. ARQ feedback IE for tunnel packets are transported either as a packed payload (“piggybacked”) within a packed Relay MAC PDU or as a payload of a stand alone Relay MAC PDU.
Copyright © 2009 IEEE. All rights reserved. 87
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Insert new subclause 6.3.4.6.4.3:
6.3.4.6.4.3 ARQ State machine
The ARQ state machine operation in access RS and receiver in MR-BS is the same as described in 6.3.4.6.2 and 6.3.4.6.3. In case of transmitter state machine in MR-BS, an ARQ block or TDU may be in one of the following five states—not sent, outstanding for R-ACK, outstanding for MS-ACK, waiting for retransmission, and data discard. Outstanding for R-ACK is the state waiting for receiving acknowledged from access RS. When R-ACK received, the state transits to outstanding for MS-ACK. In this state, MR-BS receives MS-NACK or after ARQ_BLOCK LIFE_TIME, the state transits to discard. If MR-BS receives MS-ACK in the state of outstanding for R-ACK or waiting for retransmission, the state transits to done. Other state transition descriptions are the same as transmitter state machine defined in 6.3.4.6.2.
The ARQ Tx block state sequence in MR-BS is shown in Figure 52a.
Figure 52a—ARQ Tx block state in MR-BS
Not sent Outstanding for R-ACK
Outstanding for MS-ACK
Waiting for Retransmission
ARQ_RETRY_TIMEOUT or R-NACK
Done
Discarded
Retransmit
ARQ_BLO
CK_LIFETIME AR
Q_B
LOCK
_LIF
ETIM
E
Transmit
R-AC
K
MS-ACK
AR
Q_B
LOC
K_LIFETIM
E
R-ACK
MS-A
CK
MS-
ACK M
S-ACK
88 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
6.3.5 Scheduling services
6.3.5.2 UL request/grant scheduling
Insert the following at the end of 6.3.5.2:
In MR systems with scheduling RSs, an RS-SCH message may be used to ensure QoS requirements for UGS, ertPS, and rtPS are met.
6.3.5.2.1 Unsolicited grant service (UGS)
Insert the following text at the end of 6.3.5.2.1:
In an MR system with scheduling RSs, to meet a UGS service flow’s need, the MR-BS and RSs along the path shall grant fixed size bandwidth to its subordinate station on a real-time periodic basis.
The MR-BS or RS may send RS scheduling information (RS-SCH) in advance to its subordinate RS to indicate when and how much bandwidth it will schedule for the service in the future.
6.3.5.2.2 Real-time polling service (rtPS)
Insert the following at text at the end of 6.3.5.2.2:
In an MR system with scheduling RS, to meet an rtPS service flow’s need, the MR-BS and RSs along the path shall poll its subordinate station on a real-time periodic basis. The MR-BS or an RS may send RS scheduling information (RS-SCH management message) to its subordinate RS to indicate when it will schedule a poll in the future.
6.3.5.2.2.1 Extended rtPS
Insert the following text at the end of 6.3.5.2.2.1:
In an MR system with scheduling RS, to meet an Extended rtPS service’s need, the MR-BS and RSs along the path shall grant dynamic size bandwidth to its subordinate station on a real-time periodic basis. The MR-BS or RS may send RS scheduling information (RS-SCH management message) to its subordinate RS to indicate when and how much bandwidth it will schedule for the service in the future.
6.3.6 Bandwidth allocation and request mechanisms
Insert the following text at the end of the last paragraph in 6.3.6:
The additional methods are described in the following subclauses.
6.3.6.1 Requests
Insert the following text at the end of 6.3.6.1:
The bandwidth request message, mechanism, and capability defined above for the SS and BS shall be applicable for the RS and the scheduling station respectively. Capability of incremental BRs is only mandatory if the RS is a scheduling RS.
Copyright © 2009 IEEE. All rights reserved. 89
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Insert new subclause 6.3.6.1.1:
6.3.6.1.1 Bandwidth request handling in relay networks with distributed scheduling
A scheduling station directly handles the bandwidth requests it receives from subordinate stations.
A non-transparent RS may receive bandwidth requests from its subordinate stations via the MAC signaling header, the grant management subheader or the CDMA bandwidth request code. Of these, only the grant management subheader may be encrypted.
Depending on whether the RS is capable of decrypting MAC PDUs, there are two ways to handle the grant management subheader. RSs capable of decrypting MAC PDUs shall handle all bandwidth requests locally; while RSs incapable of decrypting MAC PDUs shall handle all bandwidth requests locally except for the grant management subheader. For this type of RS, the encrypted grant management subheader is forwarded to and decrypted by the MR-BS and returned to the RS using an MR_PBBR-INFO message.
When AES-CCM is used as the encryption algorithm, the MR-BS shall set the PN_Flag = 1 and indicate the packet number in the MR_PBBR-INFO message. The packet number is taken from the encrypted MAC PDU that contains the grant management subheader. When other encryption algorithms are used, the PN_Flag and Packet Number shall be set to zero.
When the RS receives an MR_PBBR-INFO message with PN_Flag = 1, it checks the packet number to see if any aggregate bandwidth requests arrived after that packet since these would supersede the bandwidth request information in the MR_PBBR-INFO. If the MR_PBBR-INFO is not superseded or the PN_Flag = 0, the RS shall add the quantity of bandwidth requested in the MR_PBBR-INFO to its current perception of the bandwidth needs of the connection.
Although some RSs cannot decrypt MAC PDUs, all RSs can detect the presence of a grant management subheader by checking the type field of the GMH. When an RS detects a grant management subheader but cannot decrypt the MAC PDU, it may decide to allocate a small amount of bandwidth to the associated connection as a temporary measure.
The MR-BS may also disable piggybacked bandwidth requests for stations attached to an RS incapable of MAC PDU decryption. This is done by sending the appropriate Capabilities for Construction and Transmission of MAC PDUs TLV in an SBC-RSP message or Request/Transmission Policy TLV in a DSA-REQ/RSP message.
To forward traffic upstream, an RS may request uplink bandwidth via a stand-alone bandwidth request header or piggyback the request on the relay MAC PDUs. An RS may combine the bandwidth requests that arrive from subordinate stations together with the bandwidth needs of queued packets into one bandwidth request header per QoS class.
The RS may transmit a BW request header soon after it receives a BW request header from one of its subordinate stations (timed to yield an uplink allocation sequential to the arrival of those packets) instead of waiting for the actual packets to arrive in order to reduce delay in relaying traffic (see Figure 52b).
90 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Figure 52b—Reducing latency in relaying traffic by transmitting BW request header on R-UL before packets arrive
Insert new subclause 6.3.6.1.2:
6.3.6.1.2 Bandwidth request handling in relay networks with centralized scheduling
In systems with RSs operating in centralized scheduling mode, the MR-BS shall determine the bandwidth allocations (i.e., MAPs) for all links in its MR-cell. As a result, non-transparent RSs shall receive the MAPs from the MR-BS for the links to/from their subordinate stations before they can transmit them.
For the same reason, RSs shall forward all bandwidth request headers and bandwidth request CDMA ranging code information they receive from subordinate stations to the MR-BS. The RS shall not combine bandwidth request amounts from different sources since the MR-BS shall know the details of each bandwidth request in order to assign uplink bandwidth along the appropriate path.
If the RS has available uplink bandwidth, it shall simply forward the bandwidth request information to its superordinate station. Otherwise, the RS shall request uplink bandwidth from the MR-BS using CDMA ranging codes or dedicated RS CDMA ranging codes (see 6.3.6.6.1).
If the RS needs bandwidth for a MAC management message on its access/relay downlink to a subordinate station, the RS shall either send an RS CDMA ranging code dedicated for that purpose or an RS BR header. In response, the MR-BS shall allocate bandwidth for a management message in the DL-MAP it sends to the RS for broadcast on the access link and notify the RS of this resource by inserting the appropriate IE in the R-MAP.
6.3.6.2 Grants
Insert new subclause 6.3.6.2.1:
6.3.6.2.1 Bandwidth grant handling in relay networks with distributed scheduling
The bandwidth grant messages and procedures defined in 6.3.6.2 for the SS and BS shall be used by the SS/RS and the scheduling station respectively. However, MR-BSs/RSs may use additional signaling to improve relay performance, as described in the remainder of this subclause. If the bandwidth request comes from an RS, the superordinate station shall address the bandwidth grant to the RS’s Basic CID. The scheduling RS may schedule a MAC PDU or relay MAC PDU on the bandwidth allocation it receives.
MS RS MR-BS BW REQ GMH
BW REQ GMHUL-MAP
UL-MAP
MAC PDUsMAC PDUs
Copyright © 2009 IEEE. All rights reserved. 91
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
A scheduling station may send its subordinate scheduling RSs uplink scheduling information ahead of time via an RS-SCH management message. This message indicates when a given uplink bandwidth allocation will be granted to the subordinate RS (i.e., in how many frames), the size of the allocation, and the intended CID. The actual bandwidth grant is issued to the subordinate RS using a Data Grant IE in an upcoming UL-MAP. In the case of periodic bandwidth grants, the scheduling information need only be sent once (see Figure 52c).
When an RS receives an RS-SCH management message with uplink scheduling information from its superordinate station (MR-BS or RS), it shall look up the “next hop” of the given CID. Based on this scheduling information and the “next hop” of the CID, the RS can determine the appropriate bandwidth allocations and associated RS UL allocation frame offset on the uplinks it controls. The RS sends its own RS-SCH management messages to its subordinate RSs to inform them of the bandwidth allocation decisions it makes.
Figure 52c—Periodic bandwidth grant with RS scheduling information
Insert new subclause 6.3.6.2.2:
6.3.6.2.2 Bandwidth grant handling in relay networks with centralized scheduling
In relay networks with centralized scheduling, when an MR-BS allocates bandwidth to forward a packet to/from a given station, it shall allocate bandwidth on all links (relay and access) that make up the path to/from that station taking into account the processing delay and link qualities at each RS along the path as well as the multihop frame structure. To create this continuous forwarding of a packet, the MR-BS shall allocate bandwidth on consecutive links along a path taking into consideration the intermediate station’s processing time. Each RS informs the MR-BS of its minimum forwarding delay capability using the SBC-REQ message during the RS’s network entry process.
MS RS MR-BS RS SCH Message
Data 1
UL-MAP (Data Grant IE)
UL-MAP (Data Grant IE)
Data 1
Data 1
UL-MAP (Data Grant IE)
UL-MAP (Data Grant IE)
Data 1
92 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
6.3.6.3 Polling
Insert new subclause 6.3.6.3.4 as follows:
6.3.6.3.4 Polling handling in relay network
The polling procedure defined in 6.3.6.3 for the SS and the BS may be used between the SS/RS and scheduling station respectively. If an RS is regularly polled, it can transmit a bandwidth request header on the relay uplink to its superordinate station as soon as it detects impending uplink traffic in order to reduce delay (see Figure 55a).
An MR-BS or RS may inform a subordinate RS of upcoming polling via an RS-SCH management message (see Figure 55b).
Figure 55a—Reducing latency in relaying traffic via RS polling
MS BW REQ code
RS MR-BS
CDMA Allocation IEUL-MAP
BW REQ HeaderBW REQ Header
UL-MAPUL-MAP
MAC PDUsMAC PDUs
Copyright © 2009 IEEE. All rights reserved. 93
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Figure 55b—Periodic polling with RS scheduling information
In relay networks with centralized scheduling, only the MR-BS may establish a polling process with an SS or RS in the MR-cell. When the MR-BS polls an SS/RS, it shall setup the polling process so that each intermediate RS along the route from the target SS/RS is polled sequentially so that the response arrives to the MR-BS in the minimum amount of time.
6.3.6.5 Contention-based CDMA BRs for WirelessMAN-OFDMA
Insert the following text at the end of 6.3.6.5:
The contention-based BR mechanisms defined in the previous paragraphs for the SS and the BS shall be applicable for the scheduling RS and the MR-BS respectively.
Insert new subclause 6.3.6.5.1:
6.3.6.5.1 Contention-based CDMA BR handling in relay networks with centralized scheduling
When a non-transparent RS with unique BSID receives one or more bandwidth request CDMA ranging codes in a frame from its subordinate SSs, it shall forward an MR Code-REP header using its RS basic CID to the MR-BS. The MR Code-REP header shall indicate the number of bandwidth request CDMA ranging codes the RS received. Upon receiving an MR Code-REP header from a non-transparent RS, the MR-BS shall insert CDMA Allocation IEs with certain fields zeroed out into the UL-MAP that it assigns to that RS to broadcast on the access link. These CDMA_Allocation_IEs shall have zeros in the fields for Frame Number Index, Ranging Code, Ranging Symbol, and Ranging Subchannel. When a non-transparent RS receives its assigned UL-MAP from the MR-BS containing CDMA_Allocation_IEs with zeroed out fields, the RS shall fill in these fields with the appropriate ranging code and transmit region information and then broadcast this updated UL-MAP on the access link in accordance with the timing specified in 6.3.31.
When a transparent RS receives one or more bandwidth request CDMA ranging codes from its subordinate SSs within one frame, it shall forward as many codes as possible (along with their transmit regions and
MS RS MR-BS RS SCH Message
Bandwidth Request
UL-MAP (Polling)
UL-MAP (Polling)
Bandwidth Request
Bandwidth Request
UL-MAP (Polling)
UL-MAP (Polling)
Bandwidth Request
94 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
channel adjustment information) within the MR_RNG-REP message based on the available uplink bandwidth. If there is not enough bandwidth for all code information, the RS shall indicate in the MR_RNG-REP message the size of remaining codes to be reported. Based on this number, the MR-BS can allocate uplink bandwidth for the remaining code information. Using the code and transmit region information the MR-BS shall generate the appropriate CDMA_Allocation_IEs that prompt the SSs to forward their bandwidth request headers on the access uplink. If management messages are relayed on the uplink, the MR-BS shall insert an UL_Burst_Receive_IE in front of the CDMA_Allocation_IE in the UL-MAP. The UL_Burst_Receive_IE shall contain either the RS basic CID of the assigned RS or the multicast management CID. The MR-BS shall also create bandwidth allocations along the relay path from the assigned RS for the purpose of forwarding these SS bandwidth request headers to the MR-BS (see Figure 55c).
Figure 55c—BW request/allocation signaling for an RS in centralized scheduling mode
Insert new subclause 6.3.6.6:
6.3.6.6 CDMA BRs in relay networks
In relay networks with centralized scheduling, the MR-BS shall assign unique RS CDMA ranging codes to each RS in its MR-cell in order to reduce overhead and latency of various processes. In distributed scheduling mode, this assignment is optional. RS CDMA ranging codes are assigned to the RS during its initial ranging process by sending an RS_CDMA_Codes TLV in the RNG-RSP.
MS RS MR-BS
BR header or CDMA BR
UL-MAP
CDMA BR ranging
UL-MAP
MR_RNG-REP message
UL-MAP
BR header
UL-MAP
BR header
UL-MAP
Data packet
UL-MAP
Data packet
UL-MAP
Copyright © 2009 IEEE. All rights reserved. 95
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
When an RS transmits its unique RS CDMA ranging code dedicated for bandwidth request to its superordinate station, the superordinate station shall relay this code in the uplink direction. Each intermediate RS shall do the same until the code reaches the MR-BS. When the MR-BS receives an RS CDMA ranging code, it shall look up which RS sent the code (there is a one-to-one mapping between RS CDMA ranging codes and RSs in the MR-cell) and create the appropriate bandwidth allocations on the relay links along the path from the RS to the MR-BS. This requires that each RS inform the MR-BS of its processing time.
Insert new subclause 6.3.6.6.1:
6.3.6.6.1 Unique RS CDMA code allocation
The MR-BS may assign unique CDMA ranging codes to each RS in its MR-cell so that it can immediately determine the purpose and the originator of the code. Some codes allow the RS to quickly inform the MR-BS that it is engaged in a ranging process with one of its downstream stations and receive bandwidth from the MR-BS on which to continue or complete the process. Other codes allow the RS to quickly inform the MR-BS that bandwidth allocations are needed along the path from the RS to the MR-BS on which to forward a specific type of message.
The RS may be assigned several unique CDMA ranging codes in RNG-RSP for communicating the following requests to the MR-BS:
— Non-transparent RS with unique BSID and operating in centralized scheduling mode needs BW on its access downlink (to SS) on which to send a RNG-RSP message. In this case, the RS does not send an RS BR header to the MR-BS.
— Transparent RS or non-transparent RS with shared BSID needs BW on the relay uplinks along the path to the MR-BS on which to send an MR_RNG-REP message that contains the attributes of one CDMA ranging code and all adjustment information.
— Non-transparent RS with unique BSID and operating in centralized scheduling mode needs BW on its relay downlink (i.e., to its subordinate RS) on which to send a RNG-RSP message. In this case, the RS does not send RS BR header to the MR-BS.
— RS needs BW on the relay uplinks along the path to the MR-BS on which to forward a 6-byte header
— RS needs BW on the relay uplinks on which to forward an HARQ error report.
Insert new subclause 6.3.6.7:
6.3.6.7 Dedicated relay uplink channel allocation
After RS network entry and initialization, the RS may be assigned a dedicated uplink channel (RS UL_DCH) by its scheduling station.
If the RS is not allocated a dedicated relay uplink channel, it may request one. The dedicated relay uplink channel is assigned via an RS_UL_DCH assignment IE in the R-MAP and is available starting the next frame after it is received by the RS.
When a dedicated channel is established for an RS, it impacts the bandwidth requirements on all the relay uplink channels along the path to the MR-BS. In centralized scheduling, the MR-BS may allocate a dedicated relay uplink channel for each hop along the path. If these already exist, the MR-BS shall adjust their size to accommodate the new RS. In distributed scheduling mode, the RS’s superordinate station shall inform the next upstream station along the path to the MR-BS of the new bandwidth requirements so that it can make the proper adjustments to the dedicated channel between them. This process shall continue all the way to the MR-BS.
96 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
The initial (and minimum) size of a dedicated relay uplink channel shall be large enough for a management message. This size and/or allocation interval can be increased or decreased based on traffic load. The RS may calculate the traffic load periodically or in response to specific events.
When an SS adjusts its service flow requirements, it impacts the bandwidth requirements on all the dedicated relay uplink channels along the path to the MR-BS. In centralized scheduling, the MR-BS may adjust the dedicated channel sizes along the path from the SS based on the service flow parameters contained in the signaling exchange of the DSA, DSC, or DSD processes.
In distributed scheduling, the service flow adjustment is communicated to the MR-BS via DSA, DSC, or DSD messages. In response, the MR-BS may adjust the dedicated relay uplink channel of the subordinate RS that constitutes the “next hop” along the path to the SS by sending a new RS_UL_DCH assignment IE. This IE contains size adjustment and the basic CID of the access RS of the SS. Based on this information, the RS can determine whether the “next hop” to the SS contains yet another dedicated relay uplink channel that needs to be adjusted.
The dedicated resources for all RS UL_DCH shall be allocated consecutively before the non-dedicated RS UL bursts.
When successfully receiving an RS_UL_DCH assignment IE in the R-MAP, an RS shall send a DCH Assignment ACK in the form of an RS UL_DCH signaling header with DCH TYPE=0001 to its scheduling station. This RS UL_DCH signaling header shall appear in the first position of the PHY burst specified by the RS_UL_DCH assignment IE in the first frame in which the dedicated uplink resource is activated.
The RS UL_DCH signaling header with DCH Assignment ACK contains the frame number in which the RS_UL_DCH assignment IE was received. After sending an RS_UL_DCH assignment IE to an RS, the scheduling station shall receive the RS UL_DCH signaling header with DCH Assignment ACK and finish updating resources for the dedicated uplink channel. If the scheduling station fails to receive the RS UL_DCH signaling header with DCH Assignment ACK, it shall transmit the RS_UL_DCH assignment IE again.
When the scheduling station removes a dedicated uplink channel that is assigned to a particular RS, the RS shall send an RS UL_DCH signaling header with DCH Assignment ACK utilizing any of its other uplink allocations.
Insert new subclause 6.3.6.8:
6.3.6.8 Downlink flow control for relay networks with distributed scheduling
When scheduling RSs are employed in an MR network, the MR-BS may configure individual RSs to send flow control messages to regulate the flow of DL traffic. The MR-BS shall configure DL flow control within the MR-Cell using the REG-REQ/RSP message. Within these messages, the MR-BS shall indicate whether DL flow control is enabled or not.
When flow control is enabled within an MR-cell, flow control is performed independently on traffic destined for each RS in the MR-cell. Flow control of the traffic destined for an RS is performed on the link between the RS and its superordinate station. In this case, the superordinate station is the transmitter and the RS is the receiver. In addition, when the path between the RS and MR-BS has more than two hops, flow control of the traffic destined for an RS shall be performed between its superordinate RS and the MR-BS. In this case, the MR-BS is the transmitter and the superordinate RS is the receiver.
The DL flow control protocol shall operate in one of two states. The first state is called uncontrolled state. In uncontrolled state, the transmitter may send traffic without restriction. The second state is called controlled state. In controlled state, the receiver grants credit to the transmitter specifying the amount of DL traffic that
Copyright © 2009 IEEE. All rights reserved. 97
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
it can safely accept from the transmitter. When flow control is first enabled, it shall begin in the uncontrolled state between all transmitters and receivers in the MR-Cell.
When DL flow control is enabled within an RS, the RS shall monitor the flow of DL traffic in order to determine whether it is necessary to control the flow of DL traffic coming into it. When an RS determines that it is necessary to control the flow of DL traffic, it shall send a DL Flow Control Header (see 6.3.2.1.2.2.2.7) to its superordinate station indicating the amount of credit that it is granting the superordinate station. This header shall be sent using the subordinate RS’s Basic CID. The credit shall be specified as the number of bytes of DL traffic that the RS can safely receive. This message indicates to the superordinate that flow control is transitioning into the controlled state.
When an RS receives a DL_Flow_Control Header from its subordinate RS, it performs one of the following actions:
— If the CID specified in the DL_Flow_Control Header is the Basic CID of its immediate subordinate station, the RS examines the credit field in the header. If the credit field contains a value other than 0b11111111, it limits the amount of data that it transmits to the subordinate RS to the amount of bytes specified in the credit field. If the credit field contains a value of 0b11111111, the RS turns off flow control for traffic destined for the subordinate RS that sent the DL_Flow_Control Header.
— If the CID specified in the DL_Flow_Control Header is not the Basic CID of its immediate subordinate RS, the RS that received the DL_Flow_Control Header forwards it without modification to its superordinate station. This forwards the DL_Flow_Control Header all the way to the MR-BS. In response, the MR-BS may adjust the flow of packets to the RS specified by the basic CID.
When the MR-BS receives a DL_Flow_Control Header it examines the credit field in the header. If the credit field contains a value other than 0b11111111 the MR-BS limits the amount of data that it transmits to the RS whose Basic CID was specified in the header to the number of bytes specified in the credit field. If the credit field contains a value of 0b11111111, the MR-BS shall change the state of flow control to the uncontrolled state for the RS whose Basic CID was specified in the header.
When the MR-cell topology contains paths that are longer than 2 hops, it is possible for the receiver of a DL Flow Control Header to be an RS. When such an RS receives a DL Flow Control Header from its subordinate it may in turn send a DL Flow Control Header to the MR-BS, using the Basic CID of the subordinate RS that has requested flow control. The superordinate RS may indicate the same credit value or a different credit value depending on its internal state. It may also decide not to send a DL Flow Control Header to the MR-BS.
When flow control is in the controlled state, the receiver that initiated flow control shall send DL Flow Control Headers updating the number of bytes of DL traffic that it can safely receive. When the receiver determines that flow control is no longer necessary, it shall send a DL_Flow_Control Header with a credit value of 0b11111111, indicating the transition to uncontrolled state. Upon receiving a DL_Flow_Control Header with a credit value of 0b11111111, the transmitter may go back to sending DL traffic to the receiver in an unrestricted manner.
Figure 55d shows a sample topology that is used to illustrate the flow control process.
98 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Figure 55d—Sample topology for illustrating the use of DL Flow Control Header
Figure 55e illustrates an example flow of DL Flow control message flows. This example assumes the topology in Figure 55d. In this example, RS1 determines that it is congested and sends a DL_Flow_Control Header to RS3 using its Basic CID and indicating that it can accept no more than 500 bytes of data. RS3 limits the amount of data that it send to RS1 to 500 bytes, but decides that it has enough room in its buffers that it need not ask the MR-BS to control the flow of data to RS1. At some later point in time, RS1 has cleared its buffers and sends another DL_Flow_Control Header to RS3 indicating that flow control is off. RS3 resumes sending data to RS1 without flow control.
Figure 55e—Example DL flow control message sequence—Superordinate RS handles flow control locally
Figure 55f illustrates a second example flow of DL Flow control message flows. This example also assumes the topology in Figure 55d. In this example, RS1 determines that it is congested and sends a DL Flow Control Header to RS3 using its Basic CID and indicating that it can accept no more than 500 bytes of data. RS3 limits the amount of data that it sends to RS1 to 500 bytes. At some later point in time, RS3 determines that the amount of data destined for RS1 has exceeded an acceptable limit and sends a DL_Flow_Control-Header to the MR-BS. It sends this header on the Basic CID of RS1, in order to indicate to the MR-BS that it should limit the flow of packets to RS1. In this example, RS3 indicates to the MR-BS that it can receive no more than 1000 bytes of data destined for RS1. When the MR-BS receives the DL_Flow_Control Header it
RS1
RS3
RS2
RS4
MR-BS
RS1 RS3 RS4 MR-BS
DL_Flow_Control Header - Basic CID of RS1 - 500 bytes
RS3 sends no more than 500 bytes to RS1
DL_Flow_Control Header - Basic CID of RS1 - Flow control off
RS3 begins to send to RS1 without restriction
Copyright © 2009 IEEE. All rights reserved. 99
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
limits the amount of data destined for RS1 that it sends to 1000 bytes. It does not limit the amount of data that it sends to RS2 even though this data flows through RS3. At some later point in time, RS1 has cleared its buffers and sends another DL Flow Control Header to RS3 indicating that flow control is off. RS3 resumes sending data to RS1 without flow control. RS3 also sends a DL_Flow_Control Header to the MR-BS indicating the flow control for RS1 is turned off. The MR-BS resumes sending data destined for RS1 without flow control.
Figure 55f—Example DL flow control message sequence—Superordinate RS requests flow control from MR-BS
6.3.7 MAC support of PHY
6.3.7.3 DL-MAP message
Change subclause 6.3.7.3 as indicated:
The DL-MAP message defines the usage of the DL intervals on the access zone and transparent zone for a burst mode PHY.
RS1
DL_Flow_Control Header- Basic CID of RS1- 500 bytes
RS3RS3 sends nomore than500 bytes toRS1
RS4 MR-BS
DL_Flow_Control Header- Basic CID of RS1- 1000 bytes
RS4 forwardsthe DL FlowControl Header
MR-BS sendsno more than1000 bytes toRS1, MR-BScontinues tosend data toRS2 withoutrestriction
DL_Flow_Control Header- Basic CID of RS1- Flow control off
RS3 begins tosend data toRS1 withoutrestriction
DL_Flow_Control Header- Basic CID of RS1- Flow control off
RS4 forwardsthe DL FlowControl Header
MR-BSbegins tosend data toRS1 withoutrestriction
100 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
6.3.7.4 UL-MAP message
Change subclause 6.3.7.4 as indicated:
The UL-MAP message defines the UL usage on the access zone in terms of the offset of the burst relative to the Allocation Start Time (units PHY-specific).
Insert new subclause 6.3.7.7:
6.3.7.7 R-MAP
The R-MAP message defines the usage of downlink and uplink intervals on the relay link for the OFDMA-PHY.
The format of R-MAP message is defined in 8.4.5.10.
6.3.9 Network entry and initialization
Change subclause 6.3.9 as indicated:
Systems shall support the applicable procedures for entering and registering a new SS or a new node to the network. All network entry procedures described hereunder through and including 6.3.9.13 apply only to PMP operation. MR systems shall support the applicable procedures for entering and registering a new RS to the network. All network entry procedures described hereunder through and including 6.3.9.19 apply only to RS.
The procedure for initialization of an SS and an RS shall be as shown in Figure 65 and Figure 65a, respectively. This These figures shows the overall flow between the stages of initialization in an SS and an RS. This These shows no error paths and isare shown simply to provide an overview of the process. The more detailed finite state machine representations of the individual sections (including error paths) are shown in the subsequent figures. Timeout values are defined in 10.1.
Insert the following figure after Figure 65:
Copyright © 2009 IEEE. All rights reserved. 101
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Figure 65a—RS initialization overview
The procedure can be divided into the following phases:
a) Scan for DL channel and establish synchronization with the BS
a1) Perform the first stage access station selection (RS only)
b) Obtain Tx parameters (from UCD message)
c) Perform ranging
d) Negotiate basic capabilities
Obtain uplink parameters
Ranging and automatic
adjustments
Negotiate basic capabilities
RS authorization and key exchange
Operational
Register with MR-BS
Downlink synchronization
established
Uplink parametersacquired
Ranging and automatic
adjustmentscomplete
Basic capabilities negotiated
Authorizationcomplete
Registrationcomplete
RS operation parameters
configuration
Configurationcomplete
Neighbour station measurement
report
Second Stage Access Station
Selection complete
Can be skipped duringRS network re-entry
Scan for downlink channel
Second Stage Access Station
Selection
Neighbour station
measurement reported
Path creation and tunnel
establishment
Establish IP connectivity
Establish time of day
Transfer operational parameters
102 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
e) Authorize SS/RS and perform key exchange
f) Perform registration
f1) Obtain neighbor station measurement report (RS only)
f2) Perform the second stage access station selection (RS only)
f3) Path creation and tunnel establishment (RS only)
g) Establish IP connectivity
h) Establish time of day
i) Transfer operational parameters
j) Set up connections (SS only)
k) Configure operation parameters (RS only)
Implementation of phase e) is optional. This phase shall be performed if both SS and BS (or both RS and MR-BS) support Authorization Policy. Implementation of phases g), h), and i) at the SS/RS is optional. These phases shall only be performed if the SS has indicated in the REG-REQ message that it is a managed SS/RS. Implementation of phase a1), f1), f2), f3) are optional. The MR-BS may instruct the RS to omit phases d), e), f), f1), f2), f3), k) by the RS network entry optimization TLV in the RNG-RSP message.
Each SS contains the following information when shipped from the manufacturer:
— A 48-bit universal MAC address (per IEEE Std 802) assigned during the manufacturing process. This is used to identify the SS to the various provisioning servers during initialization.
— Security information as defined in Clause 7 (e.g., X.509 certificate) used to authenticate the SS to the security server and authenticate the responses from the security and provisioning servers.
6.3.9.1 Scanning and synchronization to the DL
Insert new subclause 6.3.9.1.1 as follows:
6.3.9.1.1 MR-BS and RS behavior during scanning and synchronization to the DL
The RS shall follow the same scanning and synchronization procedure as that specified for the SS. In addition, the RS may store preamble indexes and corresponding signal strength information in order to report the stored values to the serving MR-BS after registration by sending an RS_NBR_MEAS-REP message during the neighbor station measurement report phase upon request. The MR-BS indicates this request for this information through the RNG-RSP message during initial ranging.
6.3.9.2 Obtain DL parameters
Insert new subclause 6.3.9.2.1:
6.3.9.2.1 First stage access station selection
The MR-BS and the RS may transmit the TLV encoded parameter end-to-end Metric in the DCD message to support first stage access station selection in the MR network. The use of these TLV encodings is defined in 11.4 in Table 574. The RS attempting network entry may obtain the DCD TLV encodings sent by neighboring RSs and MR-BSs to select an access station. The RS shall then proceed with the rest of the network entry procedure as defined in Figure 65a with the selected access station.
Copyright © 2009 IEEE. All rights reserved. 103
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
6.3.9.9 Registration
Insert new subclause 6.3.9.9.2:
6.3.9.9.2 MR-BS and RS behavior during registration
When an RS performs registration, MR-BSs and RSs shall follow the same steps as specified in 6.3.9.9 with the modification described in Figure 84a and Figure 84b. Once the RS has sent a REG-REQ to the MR-BS, it shall wait for a REG-RSP. Figure 84a shows the waiting procedure that shall be followed by the RS.
Figure 84a—Handling REG-RSP first reception at an RS
Figure 84b—Handling REG-REQ first reception from RS at an MR-BS
T 67 as skip pin g m ea surem ent rep ort
W a it for R S_ Co nfi g-C M D
W ait fo r RE G- RSP
RE G-R SP
St op T6
Perform ne igh bo r m easure me nt repo rt
P erform ne igh bo rm eas . re port?
N oYes
Set RS capabilities supported in REG-RSP
AuthorizationPolicy support ?
Yes
Wait for REG-REQ
REG-REQ
Stop T17
No
Calculate HMAC/CMAC over REG-REQ
HMAC/CMAC Valid?Yes
REG-RSP with Response = 1(Message Auth. Failure) to SS
No
Wait for REG-REQREG-RSP with Response = 0 (OK)
Perform neighbormeas. report
Wait for RS_NBR_MEAS-REP
NoYes
Next stage as indicated by RNG/REG-RSP
Start T64
104 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
The RS operating in distributed security and |local CID allocation mode shall perform the operations shown in Figure 84c and the MR-BS shall perform the operations shown in Figure 84d.
Figure 84c—Handling REG-REQ first reception at an RS operating in distributed security and local CID allocation mode
REG-REQ to MR-BS
AuthorizationPolicy support ?
Yes
Wait for REG-REQ
REG-REQ
Stop T17
No
CalculateHMAC/CMAC over REG-REQ
HMAC/CMAC Valid?
Yes REG-RSP with Response = 1(Message Auth. Failure) to SS
No
Wait forREG-REQStart T6
Wait for REG-RSP with matching primary CID
REG-RSP to SS
REG-RSP with matching primary CID
HMAC/CMAC Valid?
RS Auth. Failure
YesNo
CalculateHMAC/CMAC over REG-RSP
Stop T6
Copyright © 2009 IEEE. All rights reserved. 105
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Figure 84d—Handling REG-REQ at a MR-BS with subordinate RS operating in local CID allocation mode
Insert new subclause 6.3.9.15 as follows:
6.3.9.15 RS neighbor station measurement report
The MR-BS may request the RS to do neighbor measurements during network entry or re-entry using the RS network entry optimization TLV in the RNG-RSP message.
The neighbor station measurement report can include the following:— The signal strength and preamble index of neighbor non-transparent stations with unique BSIDs.— Signal strength and R-amble indexes of neighbor transparent stations or non-transparent stations
with shared BSIDs.
If the measurement is not required, after registration RS shall skip the neighbor station measurement report phase and second stage access selection phases and go to the next stage as indicated by RS network entry optimization TLV in the RNG-RSP message.
The RS obtains the neighbor monitoring scheme parameters from the RS_Config-CMD message. If the RS is a mobile RS, and the RCD message provides the TLV “preamble indexes reserved for mobile RSs,” the mobile RS shall report the signal strengths and preamble indices of these preambles. After an RS_Config-CMD is sent to an RS to inform it of the monitoring scheme, the MR-BS shall not change the frame configuration of the superordinate station of the RS before the RS enters into operational mode.
The RS shall use the available neighborhood measurement mechanisms defined in 6.3.29, 6.3.30, and 8.4.6.1.1.4. The RS shall then send the measurements to the MR-BS using the RS_NBR_MEAS-REP message (6.3.2.3.64) and start a T67 timer. This measurement report is used by the MR-BS during the second stage access station selection stage to select a new access station (or to continue with the current access station). After receiving the RS_NBR_MEAS-REP message, the MR-BS shall stop the T64 timer. The MR-BS may assign the RS a preamble index based on the report from the RS. (see Figure 86a and Figure 86b).
REG-REQ
Wait for REG-REQ
HMAC/CMAC Valid?
EndYes
No
CalculateHMAC/CMAC over REG-REQ
Set SS capabilit iessupported in REG-RSP
Establish provisionedconnections3
Managed SS?No
Start T13
Yes
Wait for TFTP -CPLT
REG-RSP with Response=0 (OK) to RS
106 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Figure 86a—Perform neighbor measurement report at a RS
Figure 86b—Handling RS_NBR_MEAS-REP first reception at an MR-BS
Insert new subclause 6.3.9.16 as follows:
6.3.9.16 Second stage access station selection
The optional second stage access station selection procedure, the necessity of which is indicated by the RS network entry optimization TLV in the RNG-RSP message, happens after the neighbor station measurement report and before the RS operation parameter configuration. During this operation, the MR-BS shall determine the path (i.e., access station) for this RS based on the RS’s neighbor station measurements and other information such as path loading. If the current access station is not changed, RS shall continue network entry with this station and skip second stage access selection phase. If the current access station is changed and is located in the same MR-cell, the MR-BS shall send the RS_AccessRS-REQ message to the RS to indicate the preamble index of the selected access station and start T73 timer. The RS shall respond with the MR_Generic-ACK message, the MR-BS shall stop T73 timer and then start T70 timer. Afterwards, the MR-BS and the RS shall perform network re-entry as described in 6.3.9. Once T70 expires, the MR-BS shall release resources allocated to the corresponding RS. If initial network entry is required for the RS due to the failure in the network reentry with the selected access station, the original access station shall be the first candidate to entry. (See Figures 86c, Figure 86d, and Figure 86e.)
RS_NBR_MEAS-REP
Perform neighbor measurement report
Wait for RS_AccessRS-REQ
Start T6 7 as performing measurement report
RS_NBR_MEAS-REP
Wait for RS_NBR_MEAS-REP
Perform access station selection
Stop T64
Copyright © 2009 IEEE. All rights reserved. 107
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
.
Figure 86c—Handling RS_AccessRS-REQ first reception at an RS
Figure 86d—Perform access station selection at an MR-BS
Figure 86e—Handling RS_NBR_MEAS-REP retransmission at an MR-BS
Wait for RS_AccessRS-REQ
Network re-entry via the selected access station
RS_AccessRS-REQ
Stop T67 as performing measurement report
MR_Generic-ACK
Perform access station selection
Change access station?NoYes
Perform operation parameter configuration
Wait for RNG-REQ from the same RS
Determine access station
Start T73
RS_AccessRS-REQ
MR_Generic-ACK
Wait for MR_Generic-ACK
Start T70
Stop T73
Wait for RNG-REQ from the same RS
Start T70
Wait for RNG-REQ from the same RS
RS_NBR_MEAS-REP
Stop T70
RS_AccessRS-REQ
108 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Insert new subclause 6.3.9.17 as follows:
6.3.9.17 Path creation and tunnel establishment
This step may be performed to create a path, to establish tunnels and to bind the tunnels to this path after a RS completes the procedure of access RS selection. The tunnels, if established, could only be management tunnel and transport tunnel for the single tunnel case.
These tunnels are established using DSA-REQ/RSP management message. The path creation and binding of tunnel CIDs to the established path shall be performed as per 6.3.28.2.
Insert new subclause 6.3.9.18 as follows:
6.3.9.18 RS operation parameters configuration
6.3.9.18.1 Parameter configuration
During this phase, the MR-BS shall determine the RS’s operation parameters and send an RCD message to inform the RS of the relay link characteristics and an RS_Config-CMD message to configure the parameters at the RS (see 6.3.2.3.63) and start a T68 timer. RS_Config-CMD message shall contain all the information that is required for RS to change to operational mode. It may also contain parameters for proper RS operation, such as the preamble index, R-amble index, the allocated management CID if the RS is operating in local CID allocation mode, RS frame offset, RS second carrier configuration (if supported), etc. The RS shall respond by sending an MR_Generic-ACK message to the MR-BS, stop the T67 timer, and wait for the frame indicated by the Frame Number Action in the RS_Config-CMD message. After receiving the MR_Generic-ACK message from the RS, the MR-BS shall stop the T68 timer and start the remaining steps as indicated below to complete the network entry process and enter the operational state. The RS shall apply the configuration specified in the RS_Config-CMD message at the time indicated by the Frame Number Action. If the T68 timer expires before the MR-BS receives an MR_Generic-ACK message from the RS, the MR-BS shall retransmit the RS_Config-CMD message to the RS. If the RS receives an RS_Config-CMD message before entering the operational state, it shall follow the procedure defined in 6.3.2.3.63. (See Figures 86f, Figure 86g, and Figure 86h.)
The remaining steps prior to changing to the RS operational state for different RS types are indicated as follows:
— A TTR RS first obtains the R-FCH/R-MAP location using the RS_Config-CMD message sent as described above. It shall then decode the R-FCH and R-MAP messages within the relay zone.
— A transparent RS or STR RS shall receive the R-MAP message from the access station in the access zone, or in the relay zone if the RS coexists with a TTR RS, in order to retain R-MAP synchronization.
— A TTR RS may maintain its synchronization by listening to the R-amble transmitted by its superordinate station (see 8.4.6.1.1.4).
— A STR RS may maintain its synchronization by listening to the frame start preamble or the R-amble of its superordinate station.
— A transparent RS may maintain its synchronization by listening to the preamble transmission from its superordinate station.
In the operational state, a non-transparent RS shall start transmitting its own frame start preamble at the frame indicated by the Frame Number Action in the RS_Config-CMD message. Whether an RS transmits an R-amble depends on the instruction received in the RS_Config-CMD message (see 8.4.6.1.1.4).
Copyright © 2009 IEEE. All rights reserved. 109
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
The frame number used by the non-transparent RS with unique BSID shall take into account the RS Frame Offset TLV. If an RS Frame Offset is not provided, the RS shall use the same frame number as its superordinate station, i.e., the RS shall consider the RS Frame Offset is zero.
Frame configuration during operational mode may be done either in a quasi-static manner (default mode) using the RS_Config-CMD message, or in a dynamic manner using R-FCH (see 8.4.4.9). The Frame Configuration mode TLV may be transmitted in RS_Config-CMD message to indicate the mechanism that shall be followed for determining the frame structure in the upcoming frame(s). During the configuration phase of the network entry procedure, this TLV shall be included in the RS_Config-CMD message.
For additional configuration parameters and their usage see 6.3.2.3.63.
Figure 86f—Handling RS_Config-CMD first reception at an RS
Figure 86g—Handling RS_Config-CMD retransmission at an RS
RS_Config-CMD
MR_Generic-ACK
Yes
No
Stop T67
Wait for RS_Config-CMD
RS is operational
Stop Lost DL-MAP
Stop Lost UL-MAP interval
Stop T1
Stop T12
Non-transparent TTR mode?
RS_Config-CMD
MR_Generic-ACK
RS is operational
Wait for Action Frame Number
RS is operational
Action Frame Number
110 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Figure 86h—Configure operation parameters to an RS at an MR-BS
Figure 86i—Obtaining and maintaining synchronization with R-MAP at an RS
Insert new subclause 6.3.9.18.2:
6.3.9.18.2 Management CID allocation
The CID allocation TLV in the RS_Config-CMD is used by the MR-BS to allocate the management CID range to a subordinate RS operating in local CID allocation mode. Local CID allocation mode allows an RS to assign CIDs from this range to its subordinate stations. If the CID allocation TLV is included in the RS_Config-CMD message, the RS shall assign the management CIDs that are assigned by the MR-BS to its subordinate stations (MS or RS) in the RNG-RSP during the initial ranging process.
When an RS is operating in local CID allocation mode and the embedded path management scheme is used, the pre-allocated management CIDs shall be decided based on the contiguous integer block or bit partitioning methods shown in 6.3.28.1.
Start T68
Wait for MR_Generic-ACK
RS_Config-CMD
MR_Generic-ACK
Stop T68
Perform operation parameter configuration
Wait for Action Frame Number
RS is operational
Action Frame Number
R-MAP
Synchronize to R-MAP
Start Lost R-MAP
R-MAP synch. established
Synchronized
R-MAP
Reset Lost R-MAP
Synchronized
Timeout Lost R-MAP
Synchronize to another accessstation
Copyright © 2009 IEEE. All rights reserved. 111
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Insert new subclause 6.3.9.19 as follows:
6.3.9.19 Network entry state machine for the MR system
Figure 86j describes the network entry process on the MR-BS side. Figure 86k describes the network entry process on the RS side.
Figure 86j—Network entry state machine at a MR-BS
Wait forCDM A initial
rangingco de
Wait forR N -RE Q
Wait forSB C-RE Q
SS A uthentication
And Keyexchang e
Wait forR EG-RE Q E nd
Got C DM A I nit ia l ranging cod eCDM A Initia l rang ing code
(send R NG-RSP( abo rt))
SS Ranging Respo nseProcessing Time’ passed
(T9 expires ) Send R NG -RSP (Abort)o r Got R NG- REQ/Handle RNG -R EQ
retransm ission ( send R NG-RSP(Ab ort)
(T 17 expires or auth. fa i lure)Send RNG -RSP (Abort)
(T 17 expires)Send RNG-RSP( Ab ort) or R ES- CM D
Got CDM A initia l rang ing code /H and le C DM A initia l rang ing code
(send RNG -R SP (success)or CDM A Alloca tion IE )
Got RNG- REQ/Handle RNG -REQ(send RNG -R SP (success))
(Auth . Sup ported )Got SBC -R EQ/Hand le SBC -R EQ
Authent icated from PKM
Got R NG -RE Q/Hand le RNG- R EQ re transmissio n
(send RNG -R SP (success))
Got SBC -REQ /Handle SBC - REQ
re transmission
(Auth. not supported )Got SBC -RE Q/
Handle SBC - RE Q retransm issio n
Got CDM A init ia l rangin g code /Hand le CDM A in itial ran ging code
(send RNG -RSP (co ntinue))
( Auth. not supp orted )Got SBC -R EQ /
Handle SBC -REQretransm issio n
Wait forR _NBR-
MEA S-R EP
(T 64 exp ires )Send RNG- RSP( Abort) or RE S-C M D
(Perform RS neighb or m easurem ent report )Got REG -R EQ /Hand le RE G-R EQ
(T 68 expires )Send RNG- RSP( Ab ort)
(Perform RS neighb or measurement rep ort Got R EG- RE Q/
Hand le REG -RE Q retransmissio n
(Access sta tio n unchanged )Got RS _NBR_M E AS -R EP/
Send R S_Conf ig-C M D
Got RS_NBR_ M E AS-RE P /Retrans mit R S_ Config- CM D Wait for ACK
(Access sta tio n changed )Got RS_ NBR_M EAS-RE P/Send RS _AccessRS- RE Q
Wait forR N -RE Q
from the same R
Got RS_ NBR_M EAS-RE P/Hand le retransm issio n
(Send RS _AccessRS- RE Q)
(T70 expires )Send RNG -RSP(Ab ort)
Got ACK
Wait for ACK
Got ACK
Go t RS_NBR _M E AS-R EP/R etransm it RS _AccessR S-R EQ
( T73 expires)Send RNG -R SP (Abo rt)
Wait for Action Fra me
Numbe
Roperational
Action Frame Numb er
112 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Figure 86k—Network entry state machine at an RS
Scan
downlinkchannel
Wait forRNG-RSP or
CDMAAllocation IE
Wait forSBC-RSP
SSAuthentication
And Keyexchange
Wait forREG-RSP
End
(T18 expired and retries exhausted) or(received RNG-RSP(abort) from BS)
(T17 expires and retries exhausted) or(received RNG-RSP(abort) from BS)
(T6 expires and retries exhausted)or ( RNG-RSP(abort) or
RES-CMD from
Establish DL sync/Got UL parameters
Got CMDA Allocation IE/Send RNG-REQ with ranging CID
( for normal network entry) orSend RNG-REQ with RS basic CID
(for 2nd access station selection)
Auth. supportedGot SBC-RSP/Handle SBC- RSP
Authenticated from PKM/Send REG- REQ, Start T6
T18 expired and have more retries /Send SBC-REQ
T6 expired and have more retries/Send REG-REQ
Auth. not supported ENDGot SBC-RSP/Handle SBC-RSP
Wait forranging
opportunity
Got ranging opportunity/Send CDMA code
Received RNG-RSP(continue)
or T3 expired
(T3 expired and retries exhausted) or(received RNG-RSP(abort))
Wait forRNG-RSPwith MAC
address
T3 expired andhave more retries
(T 3 expired and retries exhausted)or (received RNG-RSP(abort))
Got RNG -RSP with MAC address /Handle RNG-RSP (Send SBC- REQ)
Got REG-RSP/Handle REG-RSP
Got RNG-RSP (abort)with Preamble Index/
Scan another access station
Wait forRS_AccessRS-
REQ or RS_Config-
CMDGot RS_Config-CMD/
Handle RS_Config-CMD
Got RS_AccessRS-REQ/Handle RS_AccessRS-REQ
T 67 expired and have more retries/Send RS_NBR_MEAS-REP
Got RS_Config-CMD/Handle RS_Config-CMD retransmission
(Send MR_Generic-ACK)
Wait for Action Frame
Number
RSoperational
Action Frame Number
Copyright © 2009 IEEE. All rights reserved. 113
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
6.3.10 Ranging
6.3.10.3 OFDMA-based ranging
6.3.10.3.1 Contention-based initial ranging and automatic adjustments
Insert new subclause 6.3.10.3.1.1 as follows:
6.3.10.3.1.1 MR-BS and RS behavior during contention-based initial ranging
When an SS performs initial ranging in systems with transparent RSs directly attached to MR-BSs, then MR-BS and transparent RSs shall perform the following tasks (see Table 182a):
— The RS shall monitor the Ranging Channel specified in the UL-MAP broadcasted by the MR-BS for initial ranging codes. When the RS detects one or more codes in a frame received on the access link, it shall send the codes it receives with sufficient strength and their adjustment information (e.g., time, power, frequency corrections) in an MR_RNG-REP message on the RS basic CID to the serving MR-BS within T71 interval. (See Figure 99a.)
— When an MR-BS first receives a CDMA ranging code directly or via an MR_RNG-REP message, it shall set the T60 timer and wait for other MR_RNG-REP messages to arrive with the same ranging code attributes from other subordinate RSs. Once the T60 timer expires, the MR-BS shall determine the most appropriate path (direct or via an RS) on which to communicate with the SS that originated the code. Algorithms or policies to select the path are out of scope of this standard (see Figure 99b):
— If adjustments are required, the MR-BS shall transmit the RNG-RSP to the SS and the process shall repeat.
— When the ranging code requires no further adjustment, the MR-BS shall provide an allocation in the access uplink for the SS to forward a RNG-REQ with its MAC address by inserting a CDMA_Allocation_IE in the UL-MAP.
— If management messages are relayed on the uplink, the MR-BS shall precede the CDMA_Allocation_IE with an UL_Burst_Receive_IE containing the access RS’s basic CID or the multicast management CID. A transparent RS, whose CID matches the RS basic CID or the multicast management CID of the UL_Burst_Receive_IE, shall receive the RNG-REQ on a burst specified by the CDMA_Allocation_IE and relay it to the MR-BS on the RS basic CID (see Figure 99c).
When an SS performs initial ranging in systems with transparent RSs attached to non-transparent RSs that have unique BSIDs and operating in centralized scheduling mode, the MR-BS, superordinate station (a non-transparent RS operating in centralized scheduling mode), and transparent RSs shall perform the following steps:
— The transparent RSs shall monitor the Ranging Channel specified in the UL-MAP broadcasted by the superordinate station, for initial ranging codes.
— When the RS detects one or more codes in a frame received on the access link, it shall send the codes it receives with sufficient strength and their adjustment information (e.g., time, power, frequency corrections) in an MR_RNG-REP message on the RS basic CID to the superordinate station within T71 interval (see Figure 99a).
— When superordinate station first receives a CDMA ranging code directly or via an MR_RNG-REP message, it shall set the T60 timer and wait for other MR_RNG-REP messages to arrive with the same ranging code attributes from other subordinate RSs (see Figure 99d and Figure 99e).
— Once the T60 timer expires, if adjustments are required, the superordinate station shall request bandwidth on the access downlink on which to send a RNG-RSP to the SS.
114 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
— When the ranging code requires no further adjustment, the superordinate station shall request bandwidth on the access uplink on which the SS can transmit a RNG-REQ containing its MAC address by following the procedure in 6.3.6.1.2.
When an SS performs initial ranging in systems operating in centralized scheduling mode with some non-transparent RSs sharing BSIDs, then the superordinate station (the MR-BS or a non-transparent RS operating in centralized scheduling mode), and the non-transparent RSs sharing BSIDs shall perform the same steps outlined in the previous paragraph but with the following modifications:
— If management messages are relayed on the uplink, the MR-BS shall precede the CDMA_Allocation_IE with an UL_Burst_Receive_IE containing the access RS’s basic CID or multicast management CID in the RS_Access-MAP message that is sent to the RSs. The access RSs and the superordinate station shall remove the UL_Burst_Receive_IE when composing the (compressed) UL-MAP that the RSs broadcast. A non-transparent RS, whose CID matches the RS basic CID or the multicast management CID of the UL_Burst_Receive_IE, shall receive the RNG-REQ on a burst specified by the CDMA_Allocation_IE and relay it to the MR-BS on the RS basic CID.
— If adjustments are required, the superordinate station shall transmit the RNG-RSP to the SS directly or to non-transparent RSs with the RS basic CID or the multicast management CID, which shall relay the received RNG-RSP to the MS with the ranging CID.
When an SS performs initial ranging in systems with transparent RSs attached to scheduling RSs, or when an SS performs initial ranging with non-transparent RSs sharing BSIDs with other access stations, then the superordinate scheduling station, and the non-transparent RSs sharing BSIDs shall perform the same steps as transparent RSs, as described above, with the following modifications:
— The scheduling RS shall perform adjustments directly with the SS with no interaction with the MR-BS. Instead of forwarding a MR_RNG-REP to the MR-BS, the RS may decide on the most appropriate adjustments.
— When the scheduling RS receives a ranging code successfully, the communication between the RS and the MR-BS shall follow the procedures defined in this subclause for initial ranging in systems using scheduling RS. If the MAC messages are relayed between the scheduling RS and the MS/SS, this RS shall provide bandwidth allocations for relaying the MAC messages between itself and the MSs/SS.
When an SS performs initial ranging in systems using non-transparent RSs with unique BSIDs and centralized scheduling mode, MR-BSs and non-transparent RSs shall perform the following tasks (see Table 182b):
— The RS shall monitor the Ranging Channel for initial ranging codes. The Ranging Channel is specified in the UL-MAP that the MR-BS sends to the RS to broadcast on the access link.
— When the RS detects a ranging code on its access link, it shall determine whether or not adjustments are necessary (see Figure 99g).
— If adjustments are necessary, the RS shall request bandwidth on the access downlink on which to send a RNG-RSP to the SS by sending either an RS CDMA ranging code (see code 1 in 6.3.6.6.1) or an RS BR header to the MR-BS. The MR-BS shall create the necessary allocation in the DL-MAP transmitted by the RS and notify the RS of this allocation via an RS_BW_Alloc_IE in the RS_Access-MAP (see Figure 99i).
— If adjustments are not necessary, the RS shall request bandwidth on the access uplink on which the SS can transmit a RNG-REQ containing its MAC address by following the procedure in 6.3.6.1.2. In response, the MR-BS shall either continue or abort the process (see Figure 99j).
— If the MR-BS chooses to continue, it shall insert a CDMA_Allocation_IE in the UL-MAP that is transmitted by the RS (which the RS fills out before broadcasting). The MR-BS may also
Copyright © 2009 IEEE. All rights reserved. 115
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
create an allocation on the access downlink for the RS to transmit an RNG-RSP to the SS with success status.
— If the MR-BS chooses to abort, it shall create an allocation for the RS to transmit an RNG-RSP to the SS with abort status with a frequency override if necessary. The MR-BS shall notify the RS of the allocation for the RNG-RSP by inserting an RS_BW-ALLOC_IE in the R-MAP.
— Upon receiving the RNG-REQ containing the SS MAC address with ranging CID, the access RS shall relay it to the MR-BS on its RS basic CID, and start a T66 timer. In response, the MR-BS shall send an RNG-RSP with the SS's CID assignments to the RS on the RS basic CID, create an allocation for a RNG-RSP in the DL-MAP it sends the RS for broadcast on the access link, and notify the RS of this allocation by inserting an RS_BW_Alloc_IE in the RS_Access-MAP. If the T66 timer expires before the RNG-RSP is received, the RS shall stop the procedure. Otherwise, the access RS shall relay this RNG-RSP to the SS on the ranging CID (see Figure 99k).
When an SS performs initial ranging in systems using scheduling RS, MR-BSs and scheduling RS shall perform the following tasks (see Table 182c, Table 182d, and Table 182e):
— The RS shall monitor the Ranging Channel specified in its UL-MAP. — When the RS detects a ranging code on its access link, it shall perform adjustments directly with the
SS as specified in 6.3.10.3.1 with no interaction with the MR-BS (see Figure 97).— When the RS receives a ranging code successfully, it shall either proceed without permission or
request permission from the MR-BS.— If the RS requires permission form the MR-BS, it shall first request permission of the MR-BS
for the SS to enter the network by sending an MR Code-REP header to the MR-BS. The MR-BS shall respond by sending an RNG-RSP to the RS containing the number of accepted SSs (see Table 182d).
— Once the RS receives permission to allow the SS to enter the network or if it decides to proceed without requesting permission, the RS shall provide bandwidth on the access uplink on which the SS can send an RNG-REQ containing its MAC address by inserting a CDMA_Allocation_IE in the UL-MAP.
— When the RS receives an RNG-REQ with an SS MAC address with ranging CID, it shall either assign CIDs to the SS or request them from the MR-BS.— If the RS is in local CID allocation mode, it shall assign and forward CIDs to the SS via an
RNG-RSP (see Table 182e, Figure 98).— If the RS is not in local CID allocation mode, it shall forward the RNG-REQ containing the SS
MAC address to the MR-BS on its RS basic CID after removing the TLVs it manages and start the T66 timer. If the SS is accepted, the MR-BS shall assign CIDs and send them in a RNG-RSP to the RS on the RS basic CID. If the T66 timer expires before the RNG-RSP is received, the RS shall stop the procedure. Otherwise, the access RS shall fill in the TLVs it manages and forward the RNG-RSP to the SS on the ranging CID (see Table 182c, Table 182d, and Figure 99k).
When an RS performs initial ranging, MR-BSs and RSs shall follow the steps indicated by the type of system in previous sections of this subclause with the following modifications:
— Upon receiving a UCD message containing an RS_Initial_Ranging_Code TLV from an MR-BS or non-transparent RS, the ranging RS shall use the “RS Initial Ranging” code instead of the “Initial Ranging” code.
— After receiving an RS Initial Ranging code, the MR-BS or non-transparent RS may send an RNG-RSP containing status = 2 (abort) with preamble indexes of candidate neighbor access stations.
— Upon receiving an RNG-RSP containing status abort with preamble indexes, the ranging RS shall scan for a DL channel of candidate neighbor access stations and performs initial ranging.
— If a transparent RS hears an RS initial ranging code, it shall recognize that it belongs to an RS and ignore it.
116 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
The message sequence chart (Table 182a, Table 182b, Table 182c, Table 182d, and Table 182e) and flow charts (Figure 99a, Figure 99b, Figure 99c, Figure 99d, Figure 99e, Figure 99f, Figure 99g, Figure 99h, and Figure 99i) define the CDMA initial ranging and adjustment process that shall be followed by compliant SSs, access RSs, and MR-BSs.
Table 182a—Ranging and automatic adjustment procedure in transparent mode
MR-BS RS MS
Time to send the initial ranging opportunity
UL-MAP
Receive Ranging Code
Wait for MR_RNG-REP from RSs
CDMA Ranging CodeReceive Ranging Code Transmit randomly selected Initial
Ranging code in a randomly selected Ranging Slot from available Ranging Region
MR_RNG-REP Receive MR_RNG-REP Send MR_RNG-REP containing adjustment information, status, ranging code attributes with RS basic CID
Time to send initial ranging opportunity
Send map containing Initial Ranging IE
Send map containing Initial Ranging IE
Receive Ranging Code
Wait for MR_RNG-REP from RSs
MR_RNG-REP Receive MR_RNG-REP
RNG-RSP
compare channel performance and select the best path. send RNG-RSP containing adjustment information, status, ranging code attributes with ranging CID.Status = Continue
RNG-RSPSend RNG-RSP containing status, ranging code attributes with ranging CID.Status = Success
UL-MAP
RNG-REQReceive RNG-REQ
RNG-RSPIdentify MS and its connecting RS. Send RNG-RSP containing management CIDs with ranging CID.
Send MR_RNG-REP containing status, ranging code attributes with RS basic CID
RNG-REQReceive RNG-REQ
Forwards the RNG-REQ to BS with RS basic CID
Receive RNG-RSP message with Ranging Code and Ranging Slot matching sent values. Adjust Time&Power parameters
Receive RNG-RSP message with Ranging Code and Ranging Slot matching sent values.
Transmit RNG-REQ containing MS MAC address and continue with regular Initial network entry.
Receive RNG-RSP message with matching MS MAC address.
Send UL-MAP containing CDMA_Allocation-IE.
Receive Ranging CodeUL-MAP
CDMA Ranging Code
Transmit randomly selected Initial Ranging code in a randomly selected Ranging Slot from available Ranging Region
UL-MAP
UL-MAP
Copyright © 2009 IEEE. All rights reserved. 117
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Table 182b—Ranging and automatic adjustments procedure with a non-transparent RS with unique BSID in centralized scheduling mode
MR-BS RS MS
Time to send the initial ranging opportunity in RS
access Link RS_Access-MAP
UL-MAP
Dedicated RS CDMA code / RS BR HDR
CDMA Ranging CodeReceive Ranging Code Transmit randomly selected Initial
Ranging code in a randomly selected Ranging Slot from available Ranging Region
Time to send initial ranging opportunity
Send map containing Initial Ranging IE with
RS basic CID
Send map containing Initial Ranging IE with RS basic CID
Receive MR _Code-REP MR_Code-REP header
RNG-RSP
RS_Access-MAP
RNG-REQReceive RNG-REQ
RNG-RSPIdentify MS and its connecting RS. Send RNG-RSP containing management CIDs with RS basic CID
Send MR_Code-REP header with RS basic CID
RNG-REQReceive RNG-REQ
Forward the RNG-REQ to BS with RS Basic CID
Receive RNG-RSP message with Ranging Code and Ranging Slot matching sent values. Adjust Time&Power parameters
Receive RNG-RSP message with Ranging Code and Ranging Slot matching sent values.
Transmit RNG-REQ containing MS MAC address and continue with regular Initial network entry.
Receive RNG-RSP message with matching MS MAC address.
Send RS UL-MAP containing CDMA_Allocation-IE with RS basic CID
Receive Ranging Code
RS_Access-MAP
CDMA Ranging Code
Transmit randomly selected Initial Ranging code in a randomly selected Ranging Slot from available Ranging Region
UL-MAP
UL-MAP
Relay the received MAP with broadcast CID
Send Dedicated RS CDMA code/RS BR HDR in order to send RNG-RSP to MS
RS_BW-ALLOC_IESend RNG-RSP containing adjustment information, status, ranging code attributes with ranging CID.Status = Continue
Relay the received MAP with broadcast CID
Relay the received MAP with broadcast CID
Receive RNG-RSP
Relay the received RNG-RSP with ranging CID RNG-RSP
118 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Table 182c—Ranging and automatic adjustments procedure with a scheduling RS operating in normal CID allocation mode
UL-MAP
MR-BS RS MS
Time to send the initial ranging opportunity
UL-MAP
CDMA Ranging CodeReceive Ranging Code Transmit randomly selected Initial
Ranging code in a randomly selected Ranging Slot from available Ranging Region
Time to send initial ranging opportunity in RS access link
Send map containing Initial Ranging IE with a broadcast
Connection ID
Send map containing Initial Ranging IE
Receive Ranging CodeStatue=Success
UL-MAP
RNG-REQReceive RNG-REQ
RNG-RSPIdentify MS and its connecting RS. Send RNG-RSP containing management CIDs with RS Basic CID.
RNG-REQReceive RNG-REQ
If RNG-REQ has ranging CID and MS MAC address, then RS relays it to BS with
RS Basic CID
Receive RNG-RSP message with Ranging Code and Ranging Slot matching sent values. Adjust Time&Power parameters
Receive RNG-RSP message with Ranging Code and Ranging Slot matching sent values.
Transmit RNG-REQ containing MS MAC address and continue with regular Initial network entry.
Receive RNG-RSP message with matching MS MAC address.
Send UL-MAP containing CDMA_Allocation-IE.
CDMA Ranging Code
Transmit randomly selected Initial Ranging code in a randomly selected Ranging Slot from available Ranging Region
Receive RNG-RSP
RNG-RSPRelay the RNG-RSP to MS with ranging CID
RNG-RSPIf status is success in RNG-RSP, send RNG-RSP containing success status with ranging CID
RNG-RSPSend RNG-RSP with Time&Power Corrections and original Ranging Code and Ranging Slot Status = Continue
Copyright © 2009 IEEE. All rights reserved. 119
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Table 182d—Ranging and automatic adjustments procedure with a scheduling RS operating with option to request permission from MR-BS
UL-MAP
MR-BS RS MS
Time to send the initial ranging opportunity
UL-MAP
CDMA Ranging CodeReceive Ranging Code Transmit randomly selected Initial
Ranging code in a randomly selected Ranging Slot from available Ranging Region
Time to send initial ranging opportunity in RS access link
Send map containing Initial Ranging IE with a broadcast
Connection ID
Send map containing Initial Ranging IE with a broadcast
Connection ID
Receive Ranging CodeStatue=Success
UL-MAP
RNG-REQReceive RNG-REQ
RNG-RSP
Identify MS and its connecting RS. If MS is accepted, send RNG-RSP containing management CIDs with RS basic CID, otherwise, send RNG-RSP with abort status
RNG-REQReceive RNG-REQ
If RNG-REQ has ranging CID and MS MAC address, then RS relays it to BS with
RS Basic CID
Receive RNG-RSP message with Ranging Code and Ranging Slot matching sent values. Adjust Time&Power parameters
Receive RNG-RSP message with Ranging Code and Ranging Slot matching sent values.
Transmit RNG-REQ containing MS MAC address and continue with regular Initial network entry.
Receive RNG-RSP message with matching MS MAC address.
Send UL-MAP containing CDMA_Allocation-IE.
CDMA Ranging Code
Transmit randomly selected Initial Ranging code in a randomly selected Ranging Slot from available Ranging Region
Receive RNG-RSP
RNG-RSPRelay the RNG-RSP to MS with Ranging CID
RNG-RSPIf status is success in RNG-RSP, send RNG-RSP containing success status with ranging CID
RNG-RSPSend RNG-RSP with Time&Power Corrections and original Ranging Code and Ranging Slot Status = Continue
MR Code-REP headerReceive MR Code-REP
header
May send MR Code-REP header to MR-BS for
permission of admission
RNG-RSPCheck availability to admit a new MS entry. Then, send RNG-RSP containing Number of accepted SSs TLV
Receive RNG-RSP
120 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Table 182e—Ranging and automatic adjustments procedure with scheduling RS operating in local CID allocation mode
MR-BS MS RS
UL-MAP
CDMA Ranging Code
RNG-RSP
UL-MAP
RNG-REQ
RNG-RSP
[Time to send the initial ranging opportunity]
Send map containing Initial Ranging IE with a broadcast Connection ID
Transmit randomly selected Initial Ranging code in a randomly selected Ranging Slot from available Ranging Region
[Receive Ranging Code]Send RNG-RSP with Time & Power Corrections and original Ranging Code and Ranging Slot Status = Continue
RNG-RSP
Receive RNG-RSP message with Ranging Code and Ranging Slot matching sent values. Adjust Time & Power parameters UL-MAP
[Time to send the initial ranging opportunity]
Send map containing InitialRanging IE with a broadcast Connection ID
CDMA Ranging Code
Transmit randomly selected Initial Ranging code in a randomly selected Ranging Slot from available Ranging Region
[Receive Ranging Code]Status = Success
If status is success in RNG-RSP, send RNG-RSP containing success status with ranging CID.
Send UL-MAP containing CDMA_Allocation-IE.
Receive RNG-RSP message with Ranging Code and Ranging Slot matching sent values.
Transmit RNG-REQ containing MS MAC address and continue with regular Initial network entry
[Receive RNG-REQ]
Identify MS and its connectingconnecting RS. Send RNG-RSP containing management CIDs with ranging CID.
Receive RNG-RSP message with matching MS MAC address.
Copyright © 2009 IEEE. All rights reserved. 121
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Figure 99a—Handling CDMA ranging code at a transparent RS
NOTE—Means ranging is within the tolerable limits of the scheduling station.2
Figure 99b—Handling CDMA ranging code or MR_RNG-REP message at a scheduling station
2Notes in text, tables, and figures are given for information only and do not contain requirements needed to implement the standard.
MR_RNG-REP message to superordinate station
End
CDMA Ranging Code
Wait for CDMA Ranging Code
Wait for uplink bandwidth allocation
Uplink bandwidth request to superordinate station
Timeout T71
Start T71
End
Uplink bandwidth allocation
Stop T71
Wait for CDMA Ranging Codeor MR_RNG-REP message
CDMA Ranging Code
Wait for MR_RNG-REP message with matching ranging code attributes
MR_RNG-REP message with matching ranging code attributes
Timeout T60
Select the designated access stationfor the ranging code attributes
Initial/HandoverRanging purpose?PeriodicNeed adjustment ?
Bandwidth request
Yes
End
No
(optional) RNG-RSP with status = 3 (success) to SS
Wait for RNG-REQ with RS basic CID
Good Enough?(Note)
YesNo
RNG-RSP with status= 1 (continue) to SS
continue or abort?continue
RNG-RSP with status= 2 (abort) to SS
End
abort
Good Enough?(Note)
RNG-RSP with status= 3 (success) to SS
End
Yes No
Start T60 as triggeringby CDMA code
CDMA_Allocation_IE to SS
MR_RNG-REP message
Start T60 as triggering by message
122 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Figure 99c—Handling RNG-REQ at a transparent RS
Figure 99d—Handling CDMA ranging code or MR_RNG-REP message at a superordinate RS with unique BSID operating in centralized scheduling mode (part 1)
RNG-REQ with RS basic CID to MR-BS
Wait for RNG-REQ containing SS MAC address with ranging CID
End
End
Wait for RNG-RSP containing matching MACaddress with ranging CID
RNG-REQ containing SS MAC address
Start T3
Timeout T3
Stop T3
RNG-RSP with matching MAC address
Select the designated access station for the ranging code attributes
Initial/HandoverRanging purpose?Periodic
Need adjustment?
Bandwidth request
Yes
End
No
Perform Initial/handover rangingPerform periodic ranging
Wait for CDMA Ranging Codeor MR _RNG-REP message
CDMA Ranging Code
Wait for MR_RNG-REP message with matching ranging code attributes
MR_RNG-REP message with matching ranging code attributes
Timeout T60
Start T60 as triggering by CDMA code
MR_RNG-REP message
Start T60 as triggering by message
Copyright © 2009 IEEE. All rights reserved. 123
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Figure 99e—Handling CDMA ranging code or MR_RNG-REP message at a superordinated RS with unique BSID operating in centralized scheduling (part 2)
Figure 99f—Handling CDMA ranging code or MR_RNG-REP message at a superordinated RS with unique BSID operating in centralized scheduling (part 3)
Perform initial/handover ranging
RS BR header or dedicated CDMA code to MR-BS
Wait for RS_BW-ALLOC_IE
RNG-RSP with status= 1 (continue) to SS
continue or abort?continue
RNG-RSP with status= 2 (abort) to SS
End
abort
End
Wait for CDMA Ranging Code
Timeout T3
MR-Code-REP header to MR-BS
Good Enough?(Note)
YesNo
CDMA_Allocation-IE withzeroed out fields
Wait for CDMA_Allocation-IE withzeroed out fields
RS_BW-ALLOC_IE
abort
Wait for RNG-REQ
CDMA_Allocation-IE
fill in the corresponding information intoCDMA_Allocation-IE
status?success
RNG-RSP with status= 3 (success) to SS
Stop T3
RS_BW-ALLOC_IE
Start T3
Stop T3Stop T3
End
Timeout T3
RS BR header or dedicated CDMA code to MR-BS
Wait for RS_BW-ALLOC_IE
RNG-RSP with status= 1 (continue) to SS
continue
RNG-RSP with status= 2 (abort) to SS
End
abort
End
Wait for CDMA Ranging Code
Timeout T3
Start T3
RNG-RSP with status= 3 (success) to SS
Status?success
End
Stop T3
RS_BW-ALLOC_IE
Perform periodic ranging
124 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Figure 99g—Handling CDMA ranging code at a non-transparent RS with unique BSID in centralized scheduling mode (part 1)
Figure 99h—Handling CDMA ranging code at a non-transparent RS with unique BSID in centralized scheduling mode (part 2)
Wait for CDMA Ranging Code
Initial/Handover Ranging Code
RS BR header or dedicated CDMA code to MR-BS
Wait for RS_BW-ALLOC_IE
RNG-RSP with status= 1 (continue) to SS
continue or abort?continue
RNG-RSP with status= 2 (abort) to SS
End
abort
End
Wait for CDMA Ranging Code
Timeout T3
MR-Code-REP header to MR-BS
Good Enough?(Note)
YesNo
CDMA_Allocation-IE withzeroed out fields
Wait for CDMA_Allocation-IE withzeroed out fields
RS_BW-ALLOC_IE
abort
Wait for RNG-REQ
CDMA_Allocation-IE
Fill in the corresponding information intoCDMA_Allocation-IE
status?success
RNG-RSP with status= 3 (success) to SS
Stop T3
RS_BW-ALLOC_IE
Start T3
Stop T3Stop T3
End
Timeout T3
Wait for CDMA Ranging Code
RS BR header or dedicated CDMA code to MR-BS
Wait for RS_BW-ALLOC_IE
RNG-RSP with status= 1 (continue) to SS
continue
RNG-RSP with status= 2 (abort) to SS
End
abort
End
Wait for CDMA Ranging Code
Timeout T3
Start T3
Periodic Ranging CodeBandwidth Request Ranging Code
Need adjustment?Yes
End
No
RNG-RSP with status= 3 (success) to SS
Status?success
End
Stop T3
RS_BW-ALLOC_IE
Copyright © 2009 IEEE. All rights reserved. 125
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Figure 99i—Handling RS_BR header at an MR-BS
Figure 99j—Handling MR_Code-REP header at the MR-BS
Figure 99k—Handling RNG-REQ at a non-transparent RS with a unique BSID except local CID allocation mode
Wait for RS BR header
RS_BW-Alloc_IE to RS
End
Wait for MR_Code-REP header
MR_Code-REP header
End
success or abort? successabort
Wait for RNG-REQ with RS basic CID
Unsolicited RS_BW-ALLOC_IE
CDMA_Allocation-IE with certain fields zeroed out to MS
(Optional)Unsolicited RS_BW-ALLOC_IE
RNG-REQ with RS basic CID to MR-BS
Wait for RNG-REQ containing SS MAC address with ranging CID
End
End
Wait for RNG-RSP containing matching MACaddress with ranging CID
RNG-REQ containing SS MAC address
Start T3
Timeout T3
RNG-RSP with ranging CID to SS
Stop T3
RNG-RSP with matching MAC address
Start T66
Stop T66
126 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
6.3.10.3.2 Periodic ranging and automatic adjustments
Insert new subclause 6.3.10.3.2.1:
6.3.10.3.2.1 MR-BS and RS behavior during periodic ranging
When an SS initiates periodic ranging in systems with RSs, MR-BSs and RSs shall perform the same tasks outlined in 6.3.10.3.1.1 (depending on the type of system) with the following modifications (see Table 183a, Table 183b, and Table 183c):
— Periodic ranging codes are used instead of initial ranging codes.— The process stops once the access station receives the code information and forwards an RNG-RSP
to the SS.
When an RS initiates periodic ranging, the MR-BSs and RSs shall perform the same tasks outlined in 6.3.10.3.1.1 (depending on the type of system) with the following modifications:
— Periodic ranging codes are used instead of initial ranging codes. Also, the MR-BS may assign a dedicated RS CDMA periodic ranging code to the RS.
— The process stops once the access station receives the code and forwards an RNG-RSP to the RS.
In some cases, the superordinate station of an SS/RS may want to initiate ranging based on the channel measurements from data traffic or a CDMA-based bandwidth request ranging code received from the SS/RS. To initiate the periodic ranging process, the superordinate station shall send an unsolicited RNG-RSP to the SS/RS.
— If the superordinate station is a transparent RS receiving a CDMA-based bandwidth request, the MR-BS and the RS shall follow the procedure defined in 6.3.10.3.1.
— If the superordinate station is a transparent RS or non-transparent RS in an RS group, it shall transmit an MR_RNG-REP to the MR-BS on the RS basic CID to request that the MR-BS send an unsolicited RNG-RSP with the necessary adjustments to the SS (see Figure 99a, Figure 99b, Figure 102b, and Figure 102c).
— If the superordinate station is a non-transparent RS in centralized scheduling mode, it shall request bandwidth from the MR-BS on which to send the unsolicited RNG-RSP (see Figure 99h and Figure 102a).
— If the superordinate station is a scheduling RS, it shall send the RNG-RSP directly to the SS without interaction with the MR-BS.
The flow charts (Figure 102a, Figure 102b, and Figure 102c) and message sequence chart (Table 183a, Table 183b, and Table 183c) on the following pages define the CDMA periodic ranging and adjustment process that shall be followed by compliant SSs, access RSs, and MR-BSs.
Copyright © 2009 IEEE. All rights reserved. 127
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Table 183a—Ranging and automatic adjustment procedure with transparent RS
MR-BS RS MS
[Time to send the Periodic Ranging opportunity]
UL-MAP
[Receive Ranging Code]
Wait for MR_RNG-REP from RSs
CDMA Ranging Code[Receive Ranging Code] Transmit randomly selected Periodic
Ranging code in a randomly selected Ranging Slot from available Ranging Region
MR_RNG-REP [Receive MR_RNG-REP ]Send MR_RNG-REP containing adjustment information, status, ranging code attributes with RS basic CID
[Time to send periodic ranging ]opportunity
Send map containing Periodic Ranging IE
Send map containing Periodic Ranging IE
[Receive Ranging Code]
Wait for MR_RNG-REP from RSs
MR_RNG-REP [Receive MR_RNG-REP ]
RNG-RSP
compare channel performance and select the best path. send RNG-RSP containing adjustment information, status, ranging code attributes with ranging CID.Status = Continue
RNG-RSPSend RNG-RSP containing status, ranging code attributes with ranging CID.Status = Success
Send MR_RNG-REP containing status, ranging code attributes with RS basic CID
Receive RNG-RSP message with Ranging Code and Ranging Slot matching sent values. Adjust Time&Power parameters
Receive RNG-RSP message with Ranging Code and Ranging Slot matching sent values.
[Receive Ranging Code]UL-MAP
CDMA Ranging Code
Transmit randomly selected Periodic Ranging code in a randomly selected Ranging Slot from available Ranging Region
UL-MAP
128 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Table 183b—Ranging and automatic adjustment procedure with a non-transparent RS with unique BSID in centralized scheduling mode
MR-BS RS MS
[Time to send the periodic ranging opportunity in RS
access Link] RS UL-MAP
UL-MAP
Dedicated RS CDMA code / RS BR HDR
CDMA Ranging Code[Receive Ranging Code] Transmit randomly selected periodic
Ranging code in a randomly selected Ranging Slot from available Ranging Region
[Time to send periodic ranging opportunity in RS access link]
Send map containing periodic Ranging IE with
RS basic CID
Send map containing periodic Ranging IE with RS basic CID
RS BR header
RNG-RSP
RS_BW-ALLOC_IE
May send RS BR HDR in order to send RNG-RSP to MS Status = Success
Receive RNG-RSP message with Ranging Code and Ranging Slot matching sent values. Adjust Time&Power parameters
Receive RNG-RSP message with Ranging Code and Ranging Slot matching sent values.
Send RNG-RSP containing adjustment information, status, ranging code attributes with ranging CID.Status = Success
[Receive Ranging Code]
RS UL-MAP
CDMA Ranging Code
Transmit randomly selected periodic Ranging code in a randomly selected Ranging Slot from available Ranging Region
UL-MAP
Relay the received MAP with broadcast CID
Send Dedicated RS CDMA code/RS BR HDR in order to send RNG-RSP to MS
RS_BW-ALLOC_IESend RNG-RSP containing adjustment information, status, ranging code attributes with ranging CID.Status = Continue
Relay the received MAP with broadcast CID
RNG-RSP
Copyright © 2009 IEEE. All rights reserved. 129
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Table 183c—Ranging and automatic adjustment procedure with a scheduling RS
UL-MAP
MR-BS RS MS
[Time to send the periodic ranging opportunity]
UL-MAP
CDMA Ranging Code[Receive Ranging Code] Transmit randomly selected periodic
Ranging code in a randomly selected Ranging Slot from available Ranging Region
[Time to send periodic ranging opportunity in RS access link]
Send map containing periodic Ranging IE
Send map containing periodic Ranging IE
[Receive Ranging Code]
Receive RNG-RSP message with Ranging Code and Ranging Slot matching sent values. Adjust Time&Power parameters
Receive RNG-RSP message with Ranging Code and Ranging Slot matching sent values.
CDMA Ranging Code
Transmit randomly selected periodic Ranging code in a randomly selected Ranging Slot from available Ranging Region
RNG-RSP
send RNG-RSP containing adjustment information, status, ranging code attributes with ranging CID success status
RNG-RSPSend RNG-RSP containing adjustment information, status, ranging code attribute with ranging CIDStatus = Continue
130 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Figure 102a—SS upstream transmission adjustment at a non-transparent RS with unique BSID in centralized scheduling mode
Figure 102b—SS upstream transmission adjustment at a transparent RS performing uplink
Figure 102c—Handling MR_RNG-REP with Report Type = 1 at an MR-BS
Wait for Upstream Data
Upstream Data
Require correction?
End
No
RS BR header to MR-BS
Wait for RS_BW-ALLOC_IE
RNG-RSP with status= 1 (continue) to SS
Status?continue
RNG-RSP with status= 2 (abort) to SS
End
abort
Yes
Start T62
Timeout T62
End
RNG-RSP with status= 3 (success) to SS
End
success
Stop T62
RS_BW-ALLOC_IE
End
MR_RNG-REP with report type = 1 to MR-BS
Wait for Upstream Data
Upstream Data
Require correction?
End
No
Yes
Wait for MR_RNG-REP with report type = 1
MR_RNG-REP with report type = 1
Unsolicited RNG-RSP to SS
End
Copyright © 2009 IEEE. All rights reserved. 131
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
6.3.10.4 CDMA HO ranging and automatic adjustment
Insert new subclause 6.3.10.4.2 as follows:
6.3.10.4.2 MR-BS and RS behavior during handover ranging
If the MR-BS is prenotified of the upcoming HO MS and the MS’s superordinate station is a non-transparent RS with unique BSID and scheduling is centralized, the MR-BS shall insert Fast Ranging IE in the UL-MAP that it sends to the RS to broadcast on the access link. The MR-BS shall also provide bandwidth along the relay path on which to forward the RNG-REQ to the MR-BS.
If the MR-BS is prenotified of the upcoming HO MS and the MS’s superordinate station is a scheduling RS, the MR-BS shall send a MOB_INF-IND message with Action_Indicator=1 to the RS indicating the RS to provide bandwidth for the MS to send an RNG-REQ by using a Fast_Ranging IE and indicating when the RS provides the Fast_Ranging IE. When the RS receives the MOB_INF-IND message, it shall provide Fast Ranging IE for the MS based on the Action Time in the MOB_INF-IND message. Afterward, if the MR-BS is notified that the MS has rejected or cancelled the HO to the RS, it may send a MOB_INF-IND message with Action_Indicator=0 to the RS. When the RS receives the message, it shall cancel providing bandwidth for the MS to send an RNG-REQ.
If the MR-BS is prenotified of the upcoming HO MS and the MS’s superordinate station is a transparent RS, the MR-BS shall insert the Fast Ranging_IE in the UL-MAP, and if management messages are relayed, the MR-BS shall precede the Fast Ranging IE with an UL_Burst_Receive_IE assigned to the RS basic CID. When a transparent RS finds its RS basic CID in an UL_Burst_Receive_IE, it shall listen for the RNG-REQ on the burst specified by the Fast Ranging IE that follows the UL_Burst_Receive_IE and relay the RNG-REQ to the MR-BS on the RS basic CID.
6.3.14 Quality of service (QoS)
6.3.14.2 Service flows
Insert the following text at the end of 6.3.14.2:
In MR networks, a service flow may traverse one or more RSs.
6.3.14.9 Service flow management
6.3.14.9.3 Dynamic service addition (DSA)
6.3.14.9.3.1 SS-initiated DSA
Insert new subclause 6.3.14.9.3.1.1 as follows:
6.3.14.9.3.1.1 MR-BS and RS behavior during SS-initiated DSA
In an MR network with scheduling RS, before admitting the service flow and sending DSA-RSP to the requesting SS, the MR-BS requests for admission control decision from the intermediate RSs in the following way:
— If the service flow maps to an existing tunnel with service flow parameters associated, and the service flow parameters for the tunnel are changed, the MR-BS shall send a DSC-REQ to all the RSs on the path to obtain their admission control decision. The CID in the service flow parameters shall be the tunnel CID. If the tunnel is for the uplink direction, the individual SS CIDs to be added into the tunnel shall be included in the CID in the tunnel TLV in the DSC-REQ. Only the access RS
132 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
processes the CID in the tunnel TLV and uses such information to map the individual uplink SS CID into the tunnel. Other intermediate RSs ignore it and just simply forward.
— If the service flow is not mapped to a tunnel, the MR-BS shall send a DSA-REQ using the requested QoS parameter set to all the RSs on the path to obtain the admission control decision. The CID in the service flow parameters shall be the CID of the individual service flow.
— The MR-BS may include Per-RS QoS TLV in DSC-REQ to RS. If RS receives Per-RS QoS TLV, RS shall use values in Per-RS QoS TLV instead of the ones in the service flow parameters.
— If the service flow maps to the single transport tunnel of an access RS and the tunnel has no service parameter associated, the MR-BS shall send a DSA-REQ using the requested QoS parameter set to all the RSs on the path to obtain admission control decision. The CID in the service flow parameters shall be the CID of the individual service flow. If the service flow is an uplink service flow, the access RS shall map the service flow to the tunnel and create the QoS subheader for this service flow during forwarding.
The DSA/DSC-REQ is first sent from MR-BS to its subordinate RS using its primary management CID.
— Upon receiving the DSA/DSC-REQ, if the RS’s resource condition can support the requested QoS parameter set, the RS forwards the message to its subordinate RS using the primary management CID of the subordinate RS.
— If the RS cannot support the requested QoS parameter set, the RS sends a DSA/DSC-RSP with CC set to reject-RS-not-supported-parameter-value to MR-BS indicating that it cannot support the requested QoS parameter set without forwarding the DSA/DSC-REQ to its subordinate RS. The RS may add the acceptable QoS parameter to the DSC-RSP.
— In order to ensure that the DSA/DSC-REQ messages from MR-BS to the RSs follow the same path as the packet associated with the tunnel or individual SS transport connection, the following information is included in the DSA/DSC-REQ depending on different path management scheme. — With explicit path management scheme, a Path_ID TLV identifying the path that the MR-BS
chooses to route the connection is included in the DSA/DSC-REQ. The intermediate RSs shall use path ID to decide the next hop to forward the DSA/DSC-REQ.
— With embedded path management, when the systematic CID is not allocated locally by the RS, a Path Info TLV shall be included in the DSA/DSC-REQ to inform each RS of the primary CID of its subordinate RS. Otherwise, each RS selects the next hop for forwarding the DSA/DSC-REQ messages based on the transport CID that is included in the service flow parameters.
If MR-BS receives DSA/DSC-RSP from the access RS within T59, it shall send DSA-RSP to the requesting SS. Meanwhile MR-BS shall also send a DSA/DSC-ACK with the admitted service flow parameter to all the RSs on the path. The path used to route the DSA/DSC-ACK from the RSs shall be the same as the path used to route the corresponding DSA/DSC-REQ from the RSs.
In a two-hop MR network with scheduling RSs operating in distributed security mode, when a DSA-REQ message is sent from an SS, the access RS and the MR-BS may deal with the message in the following way:
— The RS may add the acceptable QoS parameter set to the DSA-REQ if it cannot support the requested QoS parameter set. It then sends the DSA-REQ to the MR-BS using the primary management CID of the SS.
— The RS may include Per-RS QoS TLV in the DSA-REQ to the MR-BS. The Per-RS QoS TLV in this case represents the maximum latency at the RS to relay the requested QoS parameter set. If the MR-BS receives Per-RS QoS TLV, the MR-BS shall consider the value in Per-RS QoS TLV and ones in the requested QoS parameter set.
— The RS may get the updated SF parameters and confirmation code from DSA-RSP and DSA-ACK sent from the MR-BS and the SS, respectively.
Copyright © 2009 IEEE. All rights reserved. 133
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
— Upon receiving the DSA-REQ from the SS via the RS, the MR-BS sends back a response to the SS in the same way defined for non-relay systems. The admission control algorithm is out of scope of this standard.
— If the service flow is mapped to a tunnel and the service flow parameters for the tunnel is changed, the MR-BS shall send a DSC-REQ to the access RS before sending DSA-RSP to the SS in the same manner as defined above.
6.3.14.9.3.2 BS-initiated DSA
Insert new subclause 6.3.14.9.3.2.1 as follows:
6.3.14.9.3.2.1 MR-BS and RS behavior during BS-initiated DSA
In an MR network with scheduling RS, MR-BS may initiate a DSA-REQ to an SS to set up an individual service flow or to an RS to set up a tunnel service flow. Before sending DSA-REQ to an SS, the MR-BS requests all the RSs on the path for an admission control decision using DSA/DSC-REQ.
The procedures of sending and processing the DSA/DSC-REQ and DSA/DSC-RSP are the same as those defined for SS-initiated DSA procedure defined in 6.3.14.9.3.1.
After processing the DSA/DSC-REQ, the access RS replies with a DSA/DSC-RSP using its own primary management CID directly to the MR-BS. The MR-BS then shall send DSA-REQ to the SS. Meanwhile MR-BS shall also send a DSA/DSC-ACK with the admitted service flow parameter to all the RSs on the path. The processing procedures of DSA/DSC-ACK message on each RS on the path are the same as those defined for SS initiated DSA procedure.
In a two-hop MR network with scheduling RSs operating in distributed security mode, when an MR-BS initiates a DSA-REQ message to an SS via an access RS, the access RS and the MR-BS may deal with the message in the following way.
— If the service flow is mapped to a tunnel and the service flow parameters for the tunnel are changed, the MR-BS shall send a DSC-REQ to the access RS before sending the DSA-REQ to the SS in the same manner as defined above.
— The MR-BS may include Per-RS QoS TLV in the DSA-REQ to RS. If the RS receives Per-RS QoS TLV, the RS shall use values in Per-RS QoS TLV instead of the ones in the service flow parameters.
— When the RS can support the requested QoS parameter set, it sends the DSA-REQ to the SS using the primary management CID of the SS.
— When the RS cannot support the requested QoS parameter set in the DSA-REQ, it sends DSA-RSP with CC set to reject-RS-not-supported-parameter-value to the MR-BS indicating that it can support the requested QoS parameter set. The DSA-RSP may contain the acceptable QoS parameter set the RS can support.
— The RS may get the updated SF parameters and confirmation code from DSA-RSP and DSA-ACK sent from the SS and the MR-BS, respectively.
134 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
6.3.14.9.4 Dynamic service change (DSC)
6.3.14.9.4.1 SS-initiated DSC
Insert new subclause 6.3.14.9.4.1.1 as follows:
6.3.14.9.4.1.1 MR-BS and RS behavior during SS-initiated DSC
In an MR network with scheduling RS, before admitting the changes of the service flow and sending DSC-RSP to the requesting SS, the MR-BS requests for admission control decisions from the intermediate RSs in the following way:
— If the service flow is mapped to an existing tunnel and the service flow parameters for the tunnel are changed, the MR-BS shall send a DSC-REQ to all the RSs on the path to obtain their admission control decision. The CID in the service flow parameters shall be the tunnel CID. If the tunnel is for the uplink direction, the individual SS CIDs to be added into or removed from the tunnel shall be included in the CID added into tunnel TLV or CID removed from tunnel TLV in the DSC-REQ. Only the access RS processes the CID added into tunnel and CID removed from tunnel TLV and uses such information to map or remove the individual uplink SS CID into or from the tunnel. Other intermediate RSs ignore them and just simply forward.
— If the service flow is not mapped to a tunnel, the MR-BS shall send a DSC-REQ using the requested QoS parameter set to all the RSs on the path to obtain their admission control decision. The CID in the service flow parameters shall be the CID of the individual service flow.
— If the service is mapped to the single transport tunnel of an access RS and the tunnel has no service parameter associated, the MR-BS shall send a DSC-REQ using the requested QoS parameter set to all the RSs on the path to obtain their admission control decision. The CID in the service flow parameters shall be the CID of the individual service flow.
— The MR-BS may include Per-RS QoS TLV in DSC-REQ to RS. If RS receives Per-RS QoS TLV, RS shall use values in Per-RS QoS TLV instead of the ones in the service flow parameters.
Such DSC-REQ is first sent from MR-BS to its subordinate RS using its primary management CID.
— Upon receiving such DSC-REQ, if the RS resource condition can support the requested QoS parameter set, the RS forwards the message to its subordinate RS using the primary CID of the subordinate RS.
— If the RS cannot support the requested QoS parameter set, the RS sends a DSC-RSP with CC set to reject-RS-not-supported-parameter-value to MR-BS indicating that it cannot support the requested QoS parameter set, without forwarding it to the next hop. The RS may add the acceptable QoS parameter to the DSC-RSP.
In order to ensure that the DSC-REQ messages from MR-BS to the RSs follow the same path as the packet associated with the tunnel or individual SS transport connection, the same procedure as defined for SS initiated DSA in 6.3.14.9.3.1 is applied.
If MR-BS receives DSC-RSP from the access RS within T59, it shall send DSC-RSP to the requesting station. Meanwhile MR-BS may also send a DSC-ACK with the admitted service flow parameter to all the RSs on the path. The path used to route the DSC-ACK shall be the same as the path used to route the corresponding DSC-REQ.
In a two-hop MR network with scheduling RSs operating in distributed security mode, when a DSC-REQ message is sent from an SS, an access RS and the MR-BS may deal with the message in the following way:
Copyright © 2009 IEEE. All rights reserved. 135
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
— The RS may add the acceptable QoS parameter set to the DSC-REQ if it cannot support the requested QoS parameter set. It then sends the DSC-REQ to the MR-BS using the primary management CID of the SS.
— The RS may include Per-RS QoS TLV in the DSC-REQ to the MR-BS. The Per-RS QoS TLV in this case represents the maximum latency at the RS to relay the requested QoS parameter set. If the MR-BS receives Per-RS QoS TLV, the MR-BS shall consider the value in Per-RS QoS TLV and ones in the requested QoS parameter set.
— The RS may get the updated SF parameters and confirmation code from DSC-RSP and DSC-ACK sent from the MR-BS and the SS, respectively.
— Upon receiving the DSC-REQ from the SS via the RS, the MR-BS sends back a response to the SS in the same way defined for non-relay systems. The admission control algorithm is out of scope of this standard.
— If the service flow is mapped to a tunnel and the service flow parameters for the tunnel is changed, the MR-BS shall send a DSC-REQ to the access RS before sending DSC-RSP to the SS in the same manner as defined above.
6.3.14.9.4.2 BS-initiated DSC
Insert new subclause 6.3.14.9.4.2.1 as follows:
6.3.14.9.4.2.1 MR-BS and RS behavior during BS-initiated DSC
In an MR network with scheduling RS, before the MR-BS sends DSC-REQ to an SS or RS to modify an existing service flow, the MR-BS request for admission control decision as defined in 6.3.14.9.4.1. After receiving DSC-RSP from the access RS, the MR-BS then shall send DSC-REQ to the SS or access RS.
Meanwhile MR-BS shall also send a DSC-ACK with the admitted modified service flow parameter to all the RSs on the path. The processing procedures of DSC-ACK message on each RS are the same as those for SS initiated DSC procedure.
In a two-hop MR network with RSs operating in distributed scheduling and security mode, when an MR-BS initiates a DSC-REQ message to an SS via an access RS, the access RS and the MR-BS may deal with the message in the following way:
— If the service flow is mapped to a tunnel and the service flow parameters for the tunnel is changed, the MR-BS shall send a DSC-REQ to the access RS before sending the DSC-REQ to the SS in the same manner as defined above.
— The MR-BS may include Per-RS QoS TLV in DSC-REQ to RS. If the RS receives Per-RS QoS TLV, the RS shall use values in Per-RS QoS TLV instead of the ones in the service flow parameters.
— When the RS can support the requested QoS parameter set, it sends the DSC-REQ to the SS using the primary management CID of the SS.
— When the RS cannot support the requested QoS parameter set in the DSC-REQ, it sends DSC-RSP with CC set to reject-RS-not-supported-parameter-value to the MR-BS indicating that it cannot support the requested QoS parameter set. The DSC-RSP may contain the acceptable QoS parameter set the RS can support.
— The RS may get the updated SF parameters and confirmation code from DSC-RSP and DSC-ACK sent from the SS and the MR-BS, respectively.
136 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
6.3.14.9.5 Connection release
6.3.14.9.5.1 SS-initiated DSD
Insert new subclause 6.3.14.9.5.1.1 as follows:
6.3.14.9.5.1.1 MR-BS and RS behavior during SS-initiated DSD
In an MR network with scheduling RS, upon receiving a DSD-REQ from an SS for an existing service flow, the MR-BS shall send DSD-REQ to all the RSs on the path if the service flow is not mapped into a tunnel or if the service flow is mapped to the single transport tunnel of an access RS and the tunnel has no service parameter associated; otherwise, if change of service flow parameters of the tunnel is required, the MR-BS shall send a DSC-REQ to all the RSs on the path to inform such change. The MR-BS may also receive a DSD-REQ from an RS for a tunnel. Such DSD/DSC-REQ is first sent from MR-BS to its subordinate RS using its primary management CID. The RS processes it and forwards it to its subordinate neighboring RS using the primary management CID of its subordinate RS. This procedure is repeated by each RS, until the DSD/DSC-REQ reaches the access RS. After processing the DSD/DSC-REQ, the access RS replies with a DSD/DSC-RSP using its own primary management CID directly to the MR-BS.
In order to ensure that the DSD/DSC-REQ messages from MR-BS to the RSs follow the same path as the packet associated with the tunnel or individual SS transport connection, the same procedure as defined for SS initiated DSA in 6.3.14.9.3.1 is applied here.
In a two-hop MR network with scheduling RSs operating in distributed security mode, when a DSD-REQ message is sent from an SS, the access RS relays it to the MR-BS using the primary management CID of the SS. After processing the DSD-REQ, the MR-BS replies with a DSD-RSP using the SS primary management CID. When the access RS receives the DSD-RSP, it deletes the service flow information and relays it to the SS. If the service flow is mapped to a tunnel and the service flow parameters for the tunnel is changed, the MR-BS shall send a DSC-REQ to the access RS in the same manner as defined above.
6.3.14.9.5.2 BS-initiated DSD
Insert new subclause 6.3.14.9.5.2.1 as follows:
6.3.14.9.5.2.1 MR-BS and RS behavior during BS-initiated DSD
In an MR network with scheduling RS, in addition to sending DSD-REQ to the SS, the MR-BS shall send DSD-REQ to all the RSs on the path if the service flow is not mapped to the tunnel or if the service flow is mapped to the single tunnel of an access RS and the tunnel has no service flow parameter associated; otherwise the MR-BS shall send a DSC-REQ to all the RSs on the path if the service flow parameters is changed for the tunnel. The procedures of sending and processing the DSD/DSC-REQ and the responding DSD/DSC-RSP are the same as those defined for SS-initiated DSD procedure in 6.3.14.9.5.1.
In MR network with distributed scheduling, when a tunnel between MR-BS and an RS needs to be removed, the MR-BS shall send a DSD-REQ to this RS and all the intermediate RSs. The procedure of sending and processing the DSD-REQ and the corresponding DSD-RSP are the same as those defined for SS-initiated DSD procedure.
In a two-hop MR network with scheduling RSs operating in distributed security mode, when an MR-BS initiates a DSD-REQ message to an SS via an access RS using the primary management CID of the SS, the access RS relays it to the SS using the primary management CID of the SS. When the access RS receives a DSD-RSP sent from the SS, it deletes the service flow information and relays it to the MR-BS. If the service flow is mapped to a tunnel and the service flow parameters for the tunnel are changed, the MR-BS shall send a DSC-REQ to the access RS in the same manner as defined above.
Copyright © 2009 IEEE. All rights reserved. 137
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Insert new subclause 6.3.14.10 as follows:
6.3.14.10 QoS support for tunnel mode operation
In multihop relay systems, one or more transport tunnel connections may be established between the MR-BS and an access RS. In the single transport tunnel case, the single transport tunnel may be assigned a set of service flow parameters; otherwise, each transport tunnel shall be assigned a set of service flow parameters.
Insert new subclause 6.3.14.10.1:
6.3.14.10.1 Tunnel service flows
Each transport tunnel is associated with a tunnel service flow and a set of service flow parameters. No Service Flow Identifier (SFID) is needed for a tunnel. The service flow parameters specify the QoS requirement of the tunnel. The service flow parameters associated with a tunnel connection is determined by the MR-BS.
Insert new subclause 6.3.14.10.1.1:
6.3.14.10.1.1 Centralized scheduling mode
In case of RSs operating in centralized scheduling mode, the service flow parameters are distributed to all the RS along the path for each tunnel using the procedures defined in 6.3.14.9.3, 6.3.14.9.4, and 6.3.14.9.5.
Insert new subclause 6.3.14.10.1.2:
6.3.14.10.1.2 Distributed scheduling mode
Individual connections for SSs that have the similar QoS requirement may be mapped to the same tunnel. MR-BS shall ensure that the service flow parameters defined for the tunnel meets the QoS requirement of all the individual connections traversing the tunnel. When new individual connections for SS are added to or removed from a tunnel or the QoS requirement of the individual connection for SS is changed, and if this leads to a change of QoS requirement for the tunnel, the MR-BS shall modify the service flow parameters for the tunnel. The service flow management procedures (i.e., DSA, DSC, DSD procedures) for the tunnel connection are described in 6.3.14.9.3, 6.3.14.9.4, and 6.3.14.9.5.
The service flow parameters associated with a tunnel are listed below. Depending on the type of data delivery services, a subset of the following parameters is included:
— Traffic Priority (11.13.5)— Maximum Sustained Traffic Rate (11.13.6)— Maximum Traffic Burst (11.13.7)— Minimum Reserved Traffic Rate (11.13.8)— Vendor-specific QoS parameters (11.13.9)— Tolerated Jitter (11.13.12)— Maximum Latency (11.13.13)— Unsolicited Grant Interval (11.13.19)— Unsolicited Polling Interval (11.13.20)— Type of Data Delivery Services (11.13.24)
138 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Insert new subclause 6.3.14.10.2 as follows:
6.3.14.10.2 QoS subheader (QSH)
The QoS subheader is specified in Table 37a. The QoS subheader shall only be used in tunnel mode with scheduling RS.
When a single transport tunnel is used between an MR-BS and an access RS, the relay MAC header of the tunnel may contain an indication of the QoS subheader. The QoS subheader, when present contains data delivery service type and priority field representing the various QoS priorities corresponding to the data delivery service defined in 11.13.24 and 11.13.5. When a QoS subheader is present, the MR-BS shall set the data delivery service type and priority to the QoS subheader for the downlink while the access RS does the same for the uplink. The tunnel endpoints may aggregate packets with the same data delivery service type and priority into one relay MAC PDU.
6.3.16 MAC support for HARQ
Insert new subclause 6.3.16.4 as follows:
6.3.16.4 DL HARQ in MR systems with RSs operating in centralized scheduling mode
MR-BS schedules an initial transmission of HARQ packet on all the links between MR-BS and MS. DL transmission failure on a relay link is indicated by an encoded ACK/NAK on the UL ACK Channel.
RS_HARQ_DL-MAP_IE as defined in 8.4.5.10.4 shall be used to signal the HARQ burst allocations to the intermediate RSs along the path. MR-BS also allocates bandwidth for relaying upstream ACK/NAK on the UL ACK channel for all the hops from MS to MR-BS.
If a packet fails at any of the intermediate RSs, the RS transmits code C1 defined in the Table 548a as a NAK to the superordinate station and transmits to the subordinate station the pilot subcarriers and may transmit null data subcarriers. It shall not transmit the erroneous packet to the next hop station. Subsequently, the MR-BS may schedule a retransmission on the failed link as well as on all the subsequent links. In case of a HARQ subburst decoding error, the RS replaces the RCID_IE in the corresponding HARQ subburst IE with its own RCID_IE.
MR-BS may schedule multiple retransmissions in advance on the DL access links. The allocation of retransmissions is at the discretion of the MR-BS, but a retransmission may be scheduled no sooner than the preceding transmission plus “HARQ ACK Delay for DL Burst” on the DL access link. The UL ACK channel from the access RS to the MR-BS shall be allocated after the prescheduled retransmission attempts have been acknowledged by the MS. This ACK/NAK delay shall be specified in the ACK_frame_delay field of the RS_HARQ_DL-MAP_IE.
Insert new subclause 6.3.16.4.1 as follows:
6.3.16.4.1 Non-transparent RS
DL transmission failure on a relay link shall be indicated by the orthogonal code on the UL ACK Channel. The MR-BS identifies the RS for retransmission with the help of ACK/NAK encoding suggested in Table 548a. This does not require each RS on the path and MS to send separate ACK/NAK signals back to the MR-BS. Thus, this scheme conserves bandwidth by utilizing the same ACK channel.
When MR-BS sends the first HARQ attempt, it allocates bandwidth over all the links from the MR-BS to the MS. Each RS on the relay path receives the downlink HARQ packet, and decodes it. If the decoding succeeds, it forwards the HARQ packet to the next hop and waits for the UL ACK from the next-hop RS or MS.
Copyright © 2009 IEEE. All rights reserved. 139
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
When an RS receives code C0, indicating that the HARQ packet is successfully received by the subordinate stations or ACK from MS, it sends code C0 to the superordinate station on its UL ACK channel. When an RS receives code Ck, or NAK from the MS, it sends UL ACK code= Ck + 1 or C2 respectively on its UL ACK channel. MR-BS upon receipt of kth hop code sequence (Ck) in UL ACK Channel assumes that packet is lost on the link that is the kth hop, and it will schedule retransmission from (k – 1)th RS. If MR-BS receives code C0, it indicates that the HARQ packet is successfully received by MS. If MR-BS receives code C1, it indicates that the HARQ packet is failed on the first hop.
When DL HARQ burst transmission from kth hop RS to (k+1)th hop RS/MS fails, the ACK/NAK from the (k+1)th hop RS/MS to the MR-BS shall be transmitted on the UL ACKCH Region. MR-BS shall schedule retransmissions on all the links between the kth hop RS and the MS. The procedure of ACK/NAK scheduling corresponding to the retransmission HARQ burst is described in 6.3.16.4.1.2.
When the orthogonal encoded UL ACK scheme is employed (see Table 548a), the UL ACK channel resources shall be assigned from MS to its access RS first and up to MR-BS in reverse order of the DL transmission path. If the MR-BS does not receive ACK code sequence (C0) in the prescribed number of retransmissions, the RSs and MR-BS will discard the packet and clear the queue. BS can then perform normal signaling as if the packet is not received by MS.
MR-BS shall allocate the HARQ region that contains bursts destined to MSs that have the same ACK_frame_delay using RS_HARQ_DL-MAP_IE. Similarly MR-BS shall allocate ACKCH by using HARQ_ACKCH region allocation for Relay Data IE in 8.4.5.10.6.
MR-BS shall indicate the ACK_frame_delay in RS_HARQ_DL-MAP_IE to indicate to the RS the offset from the current frame for transmitting the encoded ACK/NAK.
Insert new subclause 6.3.16.4.1.1 as follows:
6.3.16.4.1.1 HARQ Error Report for Early Retransmission
If the intermediate RS detects an error, it may transmit either MR HARQ Error report header or HARQ Error Report message for early retransmission. Usage of MR HARQ error report header or HARQ Error Report message is implementation specific. MR-BS may decide to retransmit the HARQ burst based on the HARQ Error Report, without waiting for NAK. This is in addition to the NAK sent in the frame where its ACK CH is allocated. In case of MR HARQ Error report header, the order of Bitmap from MSB to LSB follows the order of subburst. In case of HARQ Error Report message, CID, ACID and SPID (in case of IR) shall be reported to the MR-BS. Using this message, the failed transmission can be reported to the MR-BS without any additional delay as long as there is UL bandwidth available.
The HARQ Error Report is sent by an RS in an unsolicited manner using UL bandwidth grant that may be available at the time of the report transmission.
If the RS does not have any UL bandwidth available for sending the error report, then CDMA bandwidth ranging method is used for requesting the UL bandwidth from the MR-BS. The MR-BS allocates a specific RS CDMA ranging code to an RS during initial ranging for the purpose of requesting bandwidth for transmitting HARQ error report. The code is granted by sending RS_CDMA_Codes TLV in RNG-RSP. When an RS needs to send a HARQ Error Report, it sends the allocated CDMA ranging code towards the MR-BS. The MR-BS recognizes the RS with the help of the assigned RS code. Subsequently, it assigns uplink allocation for sending the report.
k 0≠
140 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Insert new subclause 6.3.16.4.1.2 as follows:
6.3.16.4.1.2 ACK/NAK scheduling for HARQ retransmission burst
The MR-BS shall schedule additional UL ACKCH region for relaying ACK/NAK, corresponding to the retransmission burst, from the subordinate stations. This additional UL ACKCH region is allocated by setting “Retx_region_present” within HARQ ACKCH region allocation for Relay Data IE() to 1 (8.4.5.10.6). The UL ACKCH region is divided into two regions: The first ACKCH sub-region is for the ACK/NAKs corresponding to the HARQ bursts related to RS_HARQ_DL-MAP received from the superordinate RS. The second ACKCH sub-region is for relaying the ACK/NAK from the subordinate station corresponding to the retransmitted HARQ subburst.
MR-BS shall provide the offset indicated by the “Retx_ACKCH_offset” field to each RS in the UL ACKCH region for relaying the ACK/NAK for the retransmitted HARQ burst. The RS that performed the retransmission of HARQ burst shall report the ACK/NAK signals to the superordinate RS in the second ACKCH sub-region
When RS has ACK/NAK from the subordinate station corresponding to the retransmitted HARQ subburst, the RS shall relay it to the superordinate station in the second ACKCH sub-region. If RS also has its own ACK/NAK of retransmitted burst that failed at its own link, the RS shall append it after the ACK/NAK received from subordinate station in the second ACKCH sub-region.
Initial and retransmitted HARQ bursts that are transmitted to a subordinate station in frame N shall be acknowledged to the superordinate station in frame N + ACK_frame_delay. All the ACK/NAK received from subordinate stations in the same ACKCH region shall be forwarded to the superordinate station in the same frame along with the ACK/NAK corresponding to the RS HARQ DL MAP. The order of ACKs in an ACKCH region for relay data shall follow the order of the DL HARQ subbursts in the (RS-) HARQ DL MAP IE.
Figure 140a and Figure 140b show examples of the initial transmission and retransmission of an HARQ burst.
In Figure 140a, MR-BS schedules five HARQ bursts for transmission to MSs that are three hops away. When all HARQ bursts are corrupted in different link (relay link and access link), MR-BS receives the encoded ACK/NAK, which indicates the failed link.
Copyright © 2009 IEEE. All rights reserved. 141
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Figure 140a—Example of Initial transmission of HARQ burst
Figure Table 140b describes the HARQ retransmission along with new transmission and corresponding procedure about ACK/NAK reporting. Retransmission is only performed on the failed link and onwards while the ACK/NAK reporting for the retransmission burst is sent back to MR-BS.
In DL HARQ burst transmission, MR-BS schedules transmission of new bursts (6, 7, and 8) and also retransmit bursts (1 to 5) that were failed on relay link and access link in frame N to N + 2.
When MS1 and MS2 received HARQ subbursts (1 to 8) correctly, MS1 and MS2 send ACK to RS2 and RS3 respectively according to corresponding DL HARQ MAP IE in frame N + 3.
In frame N+4, RS2 and RS3 transmit the ACK/NAK to RS1 corresponding HARQ subbursts in the RS HARQ DL IE received from RS1 in the first ACKCH sub-region. However, RS2 and RS3 transmit the UL ACK/NAK for the retransmitted bursts (3, 5) in the second ACKCH sub-region indicated by “retx_ACKCH_offset” field in the HARQ_ACKCH_region_allocation_for_Relay_Data IE in 8.4.5.10.6.
When RS1 receives ACK/NAK from RS2 and RS3, it transmits the ACK/NAK to MR-BS corresponding HARQ subbursts in the RS HARQ DL IE received from MR-BS in the first ACKCH sub-region along with the ACK/NAK for the retransmitted bursts (3, 5) from RS2 and RS3 in the second ACKCH sub-region. RS1 shall also append its own ACK/NAK of retransmitted bursts (1, 4) after ACK/NAK for the retransmitted bursts (3, 5) in the second ACKCH sub-region.
BS
RS1
RS3
MS 2
RS2
MS 1
5 HARQ bursts for RS1
Downlink HARQ burst transmission
Frame NBS
RS1
RS3
MS 2
RS2
MS 1
ACKCH = 3
Frame N+3
Frame N+5
Frame N+4
Frame N+2
Frame N+1
Uplink ACK/NAK transmission
1 542 3
Error
Error
1 3
3Error
4 5
5
ErrorNAK
Error
NAK
C1 C2 C1 C2
C2 C1 C3 C2 C3
BS HARQ DLMAP
4 HARQ bursts for RS2,3RS1 HARQ DLMAP
RS2 HARQ DLMAP1 HARQ burst for MS1
RS3 HARQ DLMAP1 HARQ burst for MS2
ACKCH = 5
ACKCH = 2
ACKCH = 5
MS1 MS2
142 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Figure 140b—Example of initial transmission and retransmission of HARQ burst
Insert new subclause 6.3.16.4.2 as follows:
6.3.16.4.2 Transparent RS
Insert new subclause 6.3.16.4.2.1 as follows:
6.3.16.4.2.1 RS hop-by-hop HARQ
When an MR-BS or RS sends an HARQ subburst to an MS through a transparent RS, the MR-BS shall first transmit the subburst to the RS. If the RS does not receive the HARQ subburst successfully, it shall send a NAK to the MR-BS. The MR-BS shall then retransmit the HARQ subburst to the RS. When the HARQ subburst is successfully received at the RS, the RS shall send an ACK to the MR-BS and save the subburst for subsequent transmission to the MS. Upon receiving the ACK from the RS, the MR-BS shall schedule the RS to transmit the HARQ subburst to the MS. If the MR-BS receives a NAK from the MS, the MR-BS shall schedule the RS to retransmit the HARQ subburst to the MS. The RS shall then retransmit the stored HARQ subburst to the MS.
Insert new subclause 6.3.16.4.2.2 as follows:
6.3.16.4.2.2 RS assisted HARQ
In RS assisted HARQ, the MR-BS shall send an HARQ subburst to the MS directly and inform the RS using an MR_DL-MAP MONITOR IE that it needs to monitor the transmission. The DL MAP MONITOR IE lists the CIDs of all connections monitored by transparent RSs. Based on information in the MR_DL-MAP_MONITOR_IE and DL-MAP, the RS shall monitor the HARQ subburst transmission that is sent to the MS and attempt to decode it. If the RS receives the HARQ subburst correctly, it shall store the subburst for possible retransmission.
The MR-BS shall use the HARQ_ACKCH_region_allocation_for_Relay Data_IE to create an HARQ ACKCH in the UL relay zone. The RS shall send ACK/NAKs to the MR-BS corresponding to the subbursts
ACK Region related toBS HARQ DL-MAP
BS
RS1
RS3
MS2
RS2
MS1
New HARQ burst : 3Retx HARQ burst: 1
Downlink HARQ burst transmission and retransmission
BS
RS1
RS3
MS2
RS2
MS1
ACKCH = 8
ACKCH = 4
Frame N+3
Frame N+4
Frame N+2
Frame N+1
Uplink ACK/NAK transmission
C0 C0 C0C0
Retx_ACKCH_offset for RS1
Retx_ACKCH_offset for RS2
Frame N
872 6
MS1 MS2
Retx
61 2
Retx
New : 4, Retx: 2
BS HARQ DLMAP
RS1 HARQ DL-MAP
31 2 6
Retx
84 7
Retx
New : 3, Retx: 1RS2 HARQ DL MAP
74 5 8
Retx
New : 3, Retx: 1RS3 HARQ DL MAP
C0 C0 C0 C0 C0 C0 C0 C0
C0 C0 C0C0
C0 C0 C0C0 C0 C0 C0 C0
ACK Region of HARQ Retx burstrelayed from subordinate stations
ACKCH = 4
Frame N+5
ACK Region of HARQ Retx burstrelayed from subordinate stations
ACK Region related to RS1 HARQ DL-MAP
ACKCH = 8 Retx_ACKCH_offset for RS3
Copyright © 2009 IEEE. All rights reserved. 143
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
of CIDs it is monitoring. These ACK/NAKs shall be transmitted in the UL ACKCH in the CID order specified by the DL_MAP_MONITOR_IE. If the MR-BS receives a NAK from both the RS and MS, it shall retransmit the HARQ subburst to the MS and the RS shall again monitor the transmission. If the MR-BS receives an ACK from the RS and a NAK from the MS, it shall schedule the RS to retransmit the HARQ subburst to the MS.
In the DL-MAP_MONITOR_IE, the MR-BS may also configure the RS to use encoded ACK/NAKs. In this case, the RS shall listen for ACK/NAKs from the MS as well as the DL HARQ subburst itself. After the RS receives an ACK/NAK from the MS, it shall transmit an encoded ACK/NAK (see Table 548a) to the MR-BS on the ULACKCH. The choice of encoded ACK/NAK depends on the ACK/NAK received from the MS. If the RS receives the HARQ subburst correctly and receives a NAK from the MS, the RS shall send a C2 to the MR-BS. In this case, the MR-BS shall schedule the RS to retransmit the HARQ subburst to the MS. If the RS fails to receive the HARQ subburst and receives a NAK from the MS, the RS shall send a C1 to the MR-BS. The MR-BS shall then retransmit the burst to the MS, and the RS shall again monitor the transmission. If the RS receives an ACK from the MS, it shall send a C0 to the MR-BS regardless if the RS received the HARQ subburst correctly. The RS shall send encoded ACK/NAKs to the MR-BS corresponding to the subbursts of CIDs it is monitoring. These ACK/NAKs shall be transmitted in the UL ACKCH in the CID order specified by the DL_MAP_MONITOR_IE.
Multiple transparent RSs can also be involved in the HARQ process. The schedule of source station transmitting a subburst to multiple transparent RSs can be signaled by using MR_DL-MAP MONITOR IE that points to the burst to be received by the RSs. If an RS fails to decode the burst correctly, it shall not transmit the erroneous packet to the next hop station. In case of hop-by-hop HARQ involving multiple RSs, HARQ data is scheduled and forwarded to the next hop when MR-BS receives an ACK from at least one of the RSs, and the MR-BS shall schedule one or more RSs that sent the ACK to forward the data to the next hop. In case of multiple RSs with prescheduled resources for retransmissions for all the links, one of the RSs can be selected as designated RS per hop, which is responsible for forwarding and reporting status to the MR-BS in addition to the data forwarding. The designated RS waits for the UL ACK from the MS after it forwards the HARQ packet or transmits the pilots to the MS.
If MS sends an ACK, the designated RS reports a C0 code; otherwise the designated RS replies by choosing C2 from Table 548a.
Insert new subclause 6.3.16.4.3 as follows:
6.3.16.4.3 DL HARQ for tunnels through RSs operating in centralized scheduling mode
In case of an HARQ enabled traffic over a tunnel connection, when the access RS receives the tunneled MAC PDU successfully, the access RS unpacks the tunnel packet and forms the HARQ subbursts according to the instructions provided by the MAPs received from MR-BS in order to deliver the burst over the access link.
When HARQ is enabled for the tunnels, HARQ operation is composed of an HARQ process on the relay link and an HARQ process on the access link. HARQ operation on the relay link (between MR-BS and access RS) shall follow 6.3.16.4.1 along with additional procedure described below.
Figure 140c shows an example of operation of a DL HARQ for tunnel. The HARQ tunnel for the relay links follow the procedure described in 6.3.16.4.1, where the “tunnel ACK” reports the status for the relay links. “Aggregated ACK/NAK” reports the status for the access link as will be detailed subsequently.
144 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Figure 140c—Example of DL HARQ operation for a tunnel
When access RS receives the HARQ data subburst correctly, it unpacks the tunneled MAC PDU, forms the access link HARQ data subbursts and performs the HARQ operation on the access link. The HARQ ACK/NAK reporting has to include each individual access link HARQ data subburst so that MR-BS can schedule the retransmission of the corresponding MAC PDUs that are part of the access link HARQ data subburst. The MR-BS shall configure additional HARQ ACK/NAK channels from access RS all the way back to MR-BS to report the MS’s HARQ ACK/NAK signals so that MR-BS can schedule the retransmission of corresponding HARQ data subburst on the access link.
If the tunneled HARQ burst fails at any relay link, the MR-BS neglects the MS’s HARQ ACK/NAK channels reports. The MR-BS takes into account the access link HARQ ACK/NAK reporting only if the relay link HARQ ACK/NAK reporting has been successful. The MR-BS reschedules only those HARQ data subburst transmissions on the access link that have failed.
When the access RS receives the HARQ data subburst correctly from the superordinate station, it shall aggregate the HARQ ACK/NAK signals from MSs according to Table 195a and transmit them to
MR- BS RS0 MS0RS1
MAP(RS0,)
MAP(RS1,MS)
Tunnel data
tunnel ACK
HARQ subburst (MS0 )
MAP( MS0 )
MAP(RS1)
MAP(MS)
Aggregated ACK/NAK
Aggregated ACK/NAK
ACK/NAK from MS0
Tunnel data
tunnel ACK
frame n
frame n+1
frame n+2
frame n+3
frame n+4
frame n+5
Copyright © 2009 IEEE. All rights reserved. 145
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
superordinate RS. When an intermediate RS receives an ACK signal for the HARQ data subburst on the relay link, it shall forward the received aggregated HARQ ACK/NAK signals to its superordinate station. MR-BS assigns the number of aggregated HARQ channels per RS using “Aggregated HARQ ACK region allocation IE.” The number of aggregated HARQ channels is given by ceiling(M/3), where M is the number of access link HARQ data subbursts pertaining to the tunneled data that have to be reported.
The access RS aggregates the individual ACK/NAK reports of each HARQ data subburst pertaining to the tunnel that has been scheduled for (re)transmission. The order in which the individual ACK/NAK is included in the aggregation process to be transmitted in the Aggregated ACK/NAK channel is based on the order the subburst provided in the MAP. Both the MR-BS and the access RS maintain an updated version of the tunneled packet that shall be used for scheduling the retransmissions. If the MS successfully receives an HARQ data subburst, then both MR-BS and access RS shall update the position indices of the remaining HARQ subbursts of the tunneled packet.
HARQ(Tunnel-CID, i, j) denotes that the jth bit of the ith bitmap of the aggregated HARQ channel that belongs to tunnel CID, Tunnel-CID. The indices of the HARQ data subbursts in the tunneled packet, as well as i and j in HARQ(Tunnel CID, i, j ) start with zero. The HARQ data subburst having the updated position index k (k=0,1, ..., M–1) in the tunnel is reported in the bitmap aggregated HARQ channel by the access RS as:
where i = floor(k/3) and j = k modulo 3.
Each 3-bit aggregated HARQ bitmap uses 1/2 OFDMA slots mapped in a manner similar to the mapping of ACK/NAK channel. Table 195a defines the encoding between the payload bit sequences and the subcarriers modulation for signaling the aggregated HARQ channel.
The MR-BS schedules retransmission of the HARQ data subbursts that have been reported by the access RS on the aggregated HARQ channel as being unsuccessful (NAK). In the rare event that the aggregated HARQ reports are received with errors by the MR-BS, the RS shall perform the retransmissions and aggregation as described subsequently.
Table 195a—The aggregated HARQ channel tile encoding
3-bit aggregated HARQ bitmap Vector Indices per TileTile(0), Tile(1), Tile(2)
000 0,0,0
001 1,1,1
010 2,2,2
011 3,3,3
100 4,4,4
101 5,5,5
110 6,6,6
111 7,7,7
HARQ(Tunnel-CID,i,j)= 0 if MS reports ACK for that HARQ data sub-burst1 if MS reports NAK for that HARQ data sub-burst⎩
⎨⎧
146 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
If due to error in reception of Aggregated HARQ ACK/NAK channel, the kth HARQ data subburst is rescheduled for transmission although it has been received successful by the MS, then the access RS shall change for the kth HARQ data subburst in the HARQ_DL-MAP the CID with its own CID and in order to reduce the interference the data may not be transmitted. If due to error in the reception of the Aggregated HARQ ACK/NAK channel by the MR-BS the mth HARQ data subburst is not rescheduled for transmission although it has not been received successful by the MS, then the access RS shall consider the mth HARQ data subburst as having been successfully delivered to the MS.
Insert new subclause 6.3.16.5 as follows:
6.3.16.5 UL HARQ in MR systems with RSs operating in centralized scheduling mode
MR-BS schedules an initial transmission of HARQ packet on all the links between MR-BS and MS. UL transmission failure on a relay link is indicated by an encoded ACK/NAK on the UL ACK Channel.
Burst allocations for UL HARQ retransmissions shall be signaled to the intermediate RSs on the N-hop path between a source MS and the MR-BS in the HARQ UL MAP IE defined in 8.4.5.4.24. The UL ACK channel for relaying upstream ACK/NAK from RS to MR-BS is allocated using HARQ ACKCH region allocation for Relay Data IE in 8.4.5.10.6.
If a packet fails at any of the intermediate RSs, the RS transmits C1 and null data subcarriers with pilots to the superordinate station. It shall not re-encode the erroneous packet to transmit to the superordinate station. Subsequently, the MR-BS may schedule a retransmission on the failed link as well as on all the subsequent links.
Every ACK/NAK on UL ACK channel is forwarded by superordinate RS(s) and finally to the MR-BS.
MR-BS identifies the multihop link(s) of UL transmission failure by checking the received encoded ACK/NAK.
MR-BS may schedule multiple retransmissions in advance on the UL access links. The allocation of retransmissions is at the discretion of the MR-BS, but a retransmission may be scheduled no sooner than the preceding transmission plus “HARQ ACK Delay for UL Burst” on the UL access link.
Insert new subclause 6.3.16.5.1 as follows:
6.3.16.5.1 Non-transparent RS
When MR-BS schedules a HARQ attempt, it allocates bandwidth over all the links from the MS to the MR-BS. It also allocates bandwidth for the ACK/NAK channel on the relay links between access RS and MR-BS. Each RS on the relay path receives the uplink HARQ burst, and decodes it. If the decoding succeeds, it forwards the HARQ burst to the superordinate RS along with an ACK. In case of multihop, each subsequent RS in the path places an ACK after decoding the burst successfully. If MR-BS receives ACK along with the burst, then it knows that the burst has been received successfully on all the links up to its own subordinate RS. If the decoding fails, the RS only sends an encoded NAK to the superordinate RS. In case of multiple hops, each subsequent RS in the path places encoded NAK according to Table 548a. In case of two hops, encoded NAK is not needed. Encoded NAK informs MR-BS where the packet transmission was unsuccessful. If the RS receives the encoded NAK Cx (x not equal to 0) then it shall send the encoded NAK Cx + 1 to the next hop RS/MR-BS. If MR-BS receives encoded NAK Cx then it knows that the packet failed on the x + 1 hop from the MR-BS, therefore it may schedule retransmission only on the failed links. The MR-BS sends UL-MAP accordingly, allowing retransmission from the last RS onwards, thus, retransmitting only on the links that did not relay the HARQ burst successfully.
Copyright © 2009 IEEE. All rights reserved. 147
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
The receiving RS first looks at the per hop ACK channel. If it receives encoded NAK, it discards any information received in the HARQ, and sends encoded NAK to the next superordinate station. If it receives ACK, it decodes the HARQ burst.
The ACK/NAK to subordinate RSs may be sent in the HARQ ACK Bitmap IE. Each RS generates per hop HARQ ACK bitmap IE for its received HARQ bursts. Each receiving RS/MR-BS keeps its mapping, and generates its HARQ ACK bitmap accordingly. The MR-BS allocates the resource to transmit HARQ ACK bitmap IE. The receiver of the bitmap clears the buffer corresponding to the ACK bits in the bitmap, and saves the buffer corresponding to the NAK bits.
Insert new subclause 6.3.16.5.2 as follows:
6.3.16.5.2 Transparent RS
When the MR-BS chooses to receive a HARQ subburst from the MS through the RS, it shall inform the RS and allocate UL transmission for the RS to relay the burst to the MR-BS. If an RS receives a HARQ subburst from an MS correctly, the RS saves it for any possible retransmission, and sends an ACK signal to the MR-BS using the ACK channel prepared by MR-BS. The MR-BS allocates bandwidth for the RS to relay the HARQ subburst and sends an ACK on HARQ ACK Bitmap IE to the MS directly. The MR-BS shall not send ACK or NAK signal to RS. If the MR-BS cannot decode the subburst relayed by the RS correctly, the MR-BS allocates bandwidth for the RS to retransmit the saved subburst. If the MR-BS decodes the subburst relayed by the RS correctly, it shall not send ACK to RS. When RS receives the request to transmit new HARQ subburst for the same HARQ channel, it interprets that previous HARQ subburst was received successfully. If an RS fails to receive the HARQ subburst from MS correctly, the RS sends a NAK signal to the MR-BS and the MR-BS may send a NAK to the MS. Subsequently, the MR-BS may request the MS to retransmit the HARQ subburst.
It is also possible for the MR-BS to receive the first transmission from an MS directly. In such a case, the MR-BS informs the RS using the MR_UL-MAP_MONITOR IE that it needs to monitor the transmission. The RS, having the information on uplink resource allocations sent in the UL MAP for the MS, monitors the HARQ subburst transmission sent by the MS to the MR-BS directly and attempts to decode it. When the RS receives the HARQ subburst correctly, the RS saves it for a possible retransmission and sends an ACK to the MR-BS. On receiving the ACK from the RS, the MR-BS may send an ACK on HARQ ACK Bitmap IE to the MS directly. If the burst is received incorrectly at the RS, the RS sends a NAK to the MR-BS. If the MR-BS did not receive the HARQ subburst from the MS correctly and received a NAK from the RS, the MR-BS may send NAK on HARQ ACK Bitmap IE to the MS. Subsequently, the MR-BS may request the MS to retransmit the HARQ subburst.
If the MR-BS receives the HARQ subburst from the MS correctly then regardless of the ACK/NAK received from the RS, the MR-BS sends ACK on HARQ ACK Bitmap IE to the MS.
Insert new subclause 6.3.16.5.3 as follows:
6.3.16.5.3 UL HARQ for tunnels through RSs operating in centralized scheduling mode
An UL tunnel has its beginning at the access RS for the corresponding MSs that are part of the tunnel, while the end of the tunnel is at the MR-BS. The access RS shall pack into the tunnel only those MAC PDUs that have been successfully received from the corresponding MSs (including queued MAC PDUs at access RS). The UL transmission across the hops follows the instructions provided in the 6.3.16.5.1 with the exception that the MR-BS may not allocate bandwidth for individual ACK/NAK channels for the subbursts from the MSs whose packets will be forwarded over the tunnel connection. Additionally, MR-BS shall allocate ACK/NAK channels for the tunnel between the superordinate station of the access RS and MR-BS. Upon receiving correctly the tunneled MAC PDU, the MR-BS determines those MAC PDUs that have been
148 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
included and those MAC PDUs that failed on the access link. Subsequently, the MR-BS may schedule the retransmission of those MAC PDUs that have failed on access link.
Optionally, MR-BS may configure additional HARQ ACK/NAK channels from access RS all the way back to MR-BS to report the receiving status of MS's MAC PDU via Aggregated HARQ ACK region allocation IE. This option allows the MR-BS to reduce the latency in scheduling the retransmission of corresponding HARQ data subburst on the access link, by providing the MR-BS with faster reports of failed access links in the case that the tunnel fails on any intermediate RS. The convention used for the aggregation procedure in this situation is the same as that described in 6.3.16.4.3; in the aggregated report, access RS sets for an MS the corresponding bit on zero if the MAC PDU has been received successful and on one if the MAC PDU was received in error.
Insert new subclause 6.3.16.6 as follows:
6.3.16.6 HARQ for multihop scheduling RSs
Hop-by-hop HARQ shall be used for scheduling RSs in both the DL and UL.
In hop-by-hop mode, each hop shall use independent HARQ transactions between adjacent stations (which may be the MR-BS or an intermediate RS). For hop-by-hop HARQ, the HARQ transactions shall adhere to the same protocols and procedures as between a BS and MS in a non-relay network.
Insert new subclause 6.3.16.7 as follows:
6.3.16.7 HARQ for an RS group
Insert new subclause 6.3.16.7.1 as follows:
6.3.16.7.1 DL HARQ for a non-transparent RS group
For the purpose of HARQ operation, the superordinate station of the group provides the scheduling for the entire group of RSs by generating the MAPs for relay link (superordinate station to RSs in the group) and the access link (members of RS group to MSs). The superordinate station may also allocate a shared ACK channel for member RSs to inform their own decoding statuses. If a shared ACK channel is not allocated for the members of RS group, the superordinate station may allocate a shared combined ACK channel for members of RS group to send a codeword based on the combined report obtained from their decoding statuses and the ACK/NAK response from the MS.
If the data subburst transmitted by the superordinate station is received correctly by an RS in the group, it shall forward the data to the MS. If a shared ACK is used for member RSs, then the RSs send ACK to the superordinate station. A monitoring RS is responsible for monitoring one or more MS CID as indicated by the RS_Member_List_Update. If the RS_Member_List_Update is not provided then all RSs in the group are monitoring RSs. If a designated RS does not receive the data correctly, it shall not re-encode and transmit the erroneous data, and shall transmit nothing over the shared ACK channel, if a shared ACK is allocated for the member RSs. The MS receives the superimposed bursts from the group of RSs, as shown in Figure 140d.
Copyright © 2009 IEEE. All rights reserved. 149
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Figure 140d—HARQ operation for non-transparent RS group
Upon decoding the subburst, the MS shall transmit ACK/NAK in the corresponding allocated UL HARQ ACK channel of the access zone for the group of RSs. The monitoring RSs in the group shall monitor this UL HARQ ACK channel. For the relay link the superordinate station allocates a shared combined HARQ ACK channel in a frame after the monitoring RSs receive the ACK/NAK report from MS. A monitoring RS in the group sends a combined report for relay link and access link using the shared combined ACK channel. The combined report is generated using the appropriate codeword sequence according to Table 438a.
If an RS receives an ACK signal from the MS, then RS transmits C0 to superordinate station on the shared combined ACK channel, irrespective of the status of the relay link.
If an RS receives NAK signal from the MS, and the HARQ has been successful for relay link, the RS transmits C2 on the shared combined ACK channel to the superordinate station. This allows the option for the superordinate station to schedule the HARQ retransmission only on the access link. If the MR-BS receives neither C0 nor C2 codeword, then the MR-BS retransmits the burst by itself.
In all other cases, an RS shall transmit nothing.
If the superordinate station is an MR-BS and the group members transmit with the same preamble index as the superordinate station, the HARQ procedures described in 6.3.16.7.2 shall be applied.
Insert new subclause 6.3.16.7.2 as follows:
6.3.16.7.2 DL HARQ for a transparent RS group
For end-to-end operation, the MR-BS sends a HARQ data subburst to the MS directly, and also allocates a shared ACK/NAK channel on the relay link for RS group members to send encoded ACK/NAK reports. The ACKCH region is signaled using HARQ ACKCH region allocation for Relay Data IE() in 8.4.5.10.6. The superordinate station may use MR_DL-MAP MONITOR IE to point to the HARQ subburst to be received by the members of RS group. Optionally, if the RS_Member List Update message is sent to the group, the CID list from this message may be used to associate the group members with the HARQ traffic of the MS. The RSs, having information on the downlink resource allocations sent in the DL MAP for the MS and CID list, monitor the HARQ data subburst transmission sent to MS by superordinate station directly and attempt
Superordinate station
TX MAPs and data
TX MAPs and data Combined signals are detected
ACK/NAK
Codeword
Frame duration
N
N+1
N+2
N+3
RS group MS
Shared ACK channel
Combined ACK Channel
150 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
to decode it. When an RS receives the HARQ subburst correctly, the RS saves it for a possible retransmission. An RS that did not receive the data subburst correctly shall not re-encode an erroneous packet for transmission.
For hop-by-hop operation, HARQ data subburst is scheduled from the MR-BS and forwarded to the MS by the RSs, if an RS receives the HARQ subburst from the MR-BS correctly, then the RS stores HARQ subburst and reports ACK to MR-BS through a shared ACK channel. If an RS fails to decode the subburst correctly, it shall transmit nothing in the ACK channel. If MR-BS receives the ACK from RS group, it schedules RS(s) to forward HARQ subburst to MS. For RSs who report the ACK to MR-BS, it shall forward stored HARQ subburst to MS. For RS who does not report the ACK to MR-BS, it shall not re-encode and transmit the erroneous packet to the MS.
When MR-BS receives ACK/NAK from MS directly, MR-BS informs RSs to reply with ACK signal, after RSs received the HARQ data subburst. The RSs that did not receive the data subburst correctly shall transmit nothing to superordinate station. Thus, MR-BS receives ACK/NAK reports from RS and MS separately. MR-BS retransmits the HARQ data subburst if it did not receive an ACK from either the MS or a member of RS group. If MR-BS receives ACK from RSs and NAK from MS, MR-BS instructs the RSs to retransmit the HARQ data subburst. The RS shall send ACK/NAKs to the MR-BS corresponding to the subbursts of CIDs it is monitoring. These ACK/NAKs shall be transmitted in the UL ACKCH in the CID order specified by the DL_MAP_MONITOR_IE.
The MR-BS may also configure RSs to listen the ACK/NAK reports from the MS using MR_DL-MAP MONITOR IE. After the RSs receives ACK/NAK from the MS, the RSs reply using an encoded ACK/NAK defined in Table 463a through a shared ACK channel prepared by MR-BS. RS shall clear the HARQ subburst depending upon the ACK/NAK information received from MS. If a member of RS group received the HARQ subburst correctly and receives an NAK from MS, then it sends the codeword C2 to MR-BS on the shared ACK channel. If a member of RS group fails to receive the HARQ data subburst and receives an NAK signal from the MS, then the RS sends nothing to the MR-BS. If a member of the RS group receives an ACK from MS then irrespective of whether the RS received the HARQ data subburst correctly or not, it sends C0 codeword to MR-BS. If MR-BS received a C2 codeword it has the option to request the RSs to retransmit the HARQ subburst saved at the RS, or it can retransmit itself. If the MR-BS receives neither C0 nor C2 codeword, then the MR-BS retransmits the burst by itself. The RS shall send encoded ACK/NAKs to the MR-BS corresponding to the subbursts of CIDs it is monitoring. These ACK/NAKs shall be transmitted in the UL ACKCH in the CID order specified by the DL_MAP_MONITOR_IE.
Insert new subclause 6.3.16.7.3 as follows:
6.3.16.7.3 UL HARQ for a non-transparent RS group
When the MR-BS schedules an HARQ attempt, it allocates bandwidth over all the links from the MS to the MR-BS. It also allocates bandwidth for a shared ACK channel on the relay link between members of RS group and the superordinate station in addition to the ACK channels between the superordinate station and the MR-BS. If the HARQ ACK BITMAP IE is not omitted from the HARQ process, superordinate station shall also allocate in advance the resources for the HARQ_ACKBITMAP IE transmission at the appropriate frames, e.g., so the MS can receive the HARQ ACK BITMAP IE within the “HARQ ACK UL Delay for UL burst.” The procedure from superordinate station to MR-BS follows as described in 6.3.16.5.1.
A monitoring RS is responsible for monitoring one or more MS CID as indicated by the RS_Member_List_Update. If the RS_Member_List_Update is not provided then all RSs in the group are monitoring RSs. The members of RS group attempt to decode the uplink HARQ data subburst from the MS. If an RS decodes it successfully, it stores the data subburst, forwards the HARQ data subburst to MR-BS and transmits an ACK signal on the shared ACK channel. If an RS fails to decode the data subburst, it sends nothing to the superordinate station.
Copyright © 2009 IEEE. All rights reserved. 151
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
If the superordinate station receives the ACK signal and detects successfully the data subburst, it transmits ACK on the DL HARQ ACK Bitmap IE for the MS. If the MR-BS receives ACK signal and the data subburst detection fails, it has the option to schedule the HARQ retransmission only for the relay link while sending the ACK on the DL HARQ ACK Bitmap IE for the MS.
If the superordinate station receives nothing on the shared ACK channel, it sends NAK on the DL HARQ ACK Bitmap IE and schedules HARQ retransmission from the MS.
The superordinate station shall send towards the MR-BS the appropriate encoded ACK/NAK signal based on its decoding status and the ACK/NAK signals received from the group members so that the MR-BS may schedule a transmission or a retransmission from the failing hop.
Optionally, if the processing delays at the member RSs do not allow for MS to receive the HARQ ACK BITMAP IE (prepared by the parent) within “HARQ ACK Delay for UL Burst,” the MR-BS may select one of the members as designated RS, and this RS shall be responsible for all HARQ related operations.
If the superordinate station is an MR-BS and the group members transmit with the same preamble index as the superordinate station, the HARQ procedures are described in 6.3.16.7.4.
Insert new subclause 6.3.16.7.4 as follows:
6.3.16.7.4 UL HARQ for a transparent RS group in assisted mode
Members of a transparent RS group can also be involved in the two-hop HARQ process. The schedule of source station transmitting a subburst to members of a transparent RS group may be signaled by using MR UL-MAP MONITOR IE, which points to the burst to be received by the RSs. Optionally, if the RS_Member List Update message is sent to the group, the CID list from this message may be used to associate the group members with the HARQ traffic of the MS. RSs use shared ACK channel to report status to the MR-BS. The MR-BS replies an ACK to the MS if it receives the ACK from the RS; otherwise, it replies NAK to MS. If the MR-BS does not receive the ACK from the RSs, the MR-BS shall arrange data retransmission for the access link. If the MR-BS receives the ACK from the RSs but fails to decode the subburst, the MR-BS shall arrange data retransmission for the relay link.
Insert new subclause 6.3.16.7.4.1 as follows:
6.3.16.7.4.1 Hop-by-hop operation
For hop-by-hop HARQ involving members of a transparent RS group, HARQ data subburst is scheduled from the MS and forwarded to the MR-BS by the RSs. If an RS receives the HARQ subburst from the MS correctly, then the RS stores HARQ subburst and reports ACK to MR-BS on a shared ACK channel. If an RS fails to decode the subburst correctly, it shall transmit nothing in the ACK channel. If MR-BS receives the ACK, it schedules RS(s) to forward HARQ subburst to MR-BS. When an RS reports the ACK to MR-BS, it shall forward stored HARQ subburst to MR-BS. When an RS does not report the ACK to MR-BS, it shall not re-encode the erroneous packet for transmission to the MR-BS.
Insert new subclause 6.3.16.7.4.2 as follows:
6.3.16.7.4.2 End-to-end operation
For end-to-end HARQ involving members of a transparent RS group the resources are prescheduled for all links. The MR-BS allocates UL transmission for the RSs to relay the received subburst from MS to the MR-BS and allocates one shared ACK channel for RSs to send an ACK signal to the MR-BS. If an RS receives the HARQ subburst from the MS correctly, then the RS forwards HARQ subburst to the MR-BS and reports
152 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
an ACK to MR-BS. If an RS fails to decode the subburst correctly, it shall not re-encode the erroneous packet for transmission to the MR-BS, and it shall transmit nothing in the shared ACK channel.
If the MR-BS receives ACK report from RSs but fails to decode the data subburst correctly, it may perform retransmission only for the relay link. If it does not receive ACK from the RSs, it can schedule the retransmission across all hops. If MR-BS receives correctly the HARQ data subburst from the MS, then regardless of the ACK/NAK received from the RS, the MR-BS sends ACK on HARQ ACK Bitmap IE to the MS.
Insert new subclause 6.3.16.8 as follows:
6.3.16.8 HARQ support on RS UL_DCH
The HARQ on RS UL_DCH is a NAK-based HARQ and a hop-by-hop HARQ. The RS_UL_DCH assignment IE configures and updates HARQ operation on RS UL_DCH. The HARQ control field indicates HARQ NAK feedback type on RS UL_DCH, which is either synchronous HARQ NAK or asynchronous HARQ NAK. The NAK shall be sent only when one or more bursts are received in error using RS_UL_DCH HARQ RETX IE. The HARQ configuration for the RS UL_DCH is unchanged and HARQ NAK feedbacks shall be as given in the format of the selected HARQ NAK feedback type.
Packets from multiple MSs/RSs are multiplexed and transmitted through the UL DCH. Each DCH resource block can be used for transmitting a single HARQ burst at a time. For allocation of new UL DCH resource block, a number of DCH ACID is also assigned. Implicit sequential cycling of DCH ACID is used for each occurrence of the periodically assigned resource. The first transmission after enabling HARQ is always HARQ channel 0 (DCH ACID is 0). The DCH ACID is incremented by 1 for each periodic transmission and reset to 0 when the maximum DCH ACID number is reached.
The synchronous NAK and retransmission control signaling are sent by the superordinate station. The superordinate station that receives HARQ UL burst at ith frame may transmit NAK signal at (i+j)th frame. The frame offset “j” is defined by the “HARQ UL Burst ACK Delay” field in the RCD message. The asynchronous NAKs are identified by a set of DCH resource ID and DCH ACID, which identify bursts on RS UL_DCH. The asynchronous NAK may be sent if the feedback delay is variable.
The retransmission may use the existing dedicated resources on the RS UL_DCH or additional resources may be allocated through the RS_UL_DCH HARQ RETX IE. For using the dedicated resource, the retransmission is sent using the same HARQ channel and it is sent on the next occurrence of the same HARQ channel after the NAK signal. Thus, the dedicated resource allocation minimizes signaling overhead for the retransmissions. For using the additional resource, a one-time additional resource is allocated to the HARQ channel that requires retransmission. In this case, the number of DCH ACID shall be large enough to allow for the maximum number of retransmission attempts before the DCH ACID wrap around. When the bandwidth on RS UL_DCH is required to be guaranteed, the additional resources shall be allocated.
In case of centralized scheduling, the intermediate RS may also generate the RS UL_DCH signaling header with HARQ Retransmission Request so that the MR-BS can allocate resources for retransmission.
6.3.20 Sleep mode for mobility-supporting MS
Insert new subclause 6.3.20.10 as follows:
6.3.20.10 MS sleep mode support in MR systems
The sleep mode shall be centrally controlled by the MR-BS. The MR-BS shall be responsible for generating MOB_SLP-RSP, DL sleep control extended subheader, or RNG-RSP with power-saving class parameters (Table 582) messages, which shall be relayed by RSs.
Copyright © 2009 IEEE. All rights reserved. 153
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
For MR, to guarantee the sleep-mode MS receiving traffic indication in time in the presence of processingdelay of RS, which is DR, the MR-BS may transmit MOB_TRF-IND over R-link and access link separately.If multiple RSs exist, the MR-BS shall find the cumulative processing delay of RSs, which is DC, for thepath between the MR-BS and the MS. If RS uses the same frame number that the MR-BS uses, the MR-BSmay send MOB_TRF-IND over the R-DL as a pre-transmission DR or DC frame earlier than the normalMOB_TRF-IND transmission time over access link. The RS delay, DR, is given to MR-BS as a capabilityparameter of SBC-REQ message. If RS uses a different frame number from the number that MR-BS uses,MR-BS may schedule transmission time at the RS in consideration of DR or DC and RS frame offset.
6.3.20.10.1 Centralized scheduling mode
For an MS attached to the MR-BS through an RS, MS sleep mode operates as defined in 6.3.20. AllMOB_SLP-REQ messages generated by MSs attached to an RS shall be relayed to the MR-BS. The MR-BSshall take the additional relay delay into account while it forwards the packets through RS.
6.3.20.10.2 Distributed scheduling mode
In the case of scheduling RSs, before instructing the MS sleep mode parameters by sending MOB_SLP-RSP, DL sleep control extended subheader, or RNG-RSP with power-saving class parameters to the RS’subordinate MSs, the MR-BS shall send an MR_SLP-INFO message to the access RS on the RS’s basic CIDto inform the RS the corresponding MS sleep mode parameters. After receiving this MR_SLP-INFOmessage, the access RS shall send MR_Generic-ACK message to MR-BS to acknowledge that it got theinformation about the sleep context of the CIDs indicated. The MR-BS shall retransmit the MR_SLP-INFOmessage to the access RS on the RS’s basic CID, if it does not receive the MR_Generic-ACK message fromthe corresponding access RS within the T58 timer. MR-BS may do retransmission for a maximum ofMR_SLP-INFO Retry Count. Once MR-BS receives the MR_Generic-ACK message, it shall send amessage, such as MOB_SLP-RSP, DL sleep control extended subheader, or RNG-RSP with power-savingclass parameters, which shall be relayed by RSs, to the RSs’ subordinate MS.
In the distributed security case, an access RS may get sleep mode information from MOB_SLP-RSP sent bythe MR-BS. The received MOB_SLP-RSP is protected with CMAC/HMAC calculated by a key sharedbetween the access RS and the MR-BS. After re-calculating CMAC/HMAC with a key shared between theaccess RS and the MS, the access RS relays the MOB_SLP-RSP to MS.
6.3.21 MAC HO procedures
6.3.21.1 Network topology acquisition
6.3.21.1.1 Network topology advertisement
Insert new subclause 6.3.21.1.1.1:
6.3.21.1.1.1 MR-BSs and RSs behavior during network topology advertisement
The MR-BS and the non-transparent RS shall broadcast information about the infrastructure stations that arepresent in the network using the MOB_NBR-ADV message defined in 6.3.2.3.42. The MR-BS and the RSmay obtain the information to be included in the MOB_NBR-ADV message over the backbone network orover the relay links. Each non-transparent RS can broadcast a different MOB_NBR-ADV message that issuitable for its service area.
To facilitate each non-transparent RS to transmit a MOB_NBR-ADV message suitable for its service area,the MR-BS shall transmit a MR_NBR-INFO message to the RSs over the relay links. The MR_NBR-INFOis a customized, unicast message that is composed by the MR-BS according to the specific neighborhood ofthe receiving RS. In order to compose the MR_NBR-INFO customized for the subordinate RSs, the MR-BS
154 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
may use location information or the interference measurement reports received from the infrastructure stations. In centralized scheduling mode, the RS may inform the MR-BS about the required bandwidth to broadcast the customized MOB_NBR-ADV by transmitting an RS BR header. The RS shall transmit the MOB_NBR-ADV at the region specified in RS_BW-ALLOC IE. In distributed scheduling mode, the RS may autonomously broadcast MOB_NBR-ADV on the access link.
An RS, depending on its capability and depending on the messages that it receives, may choose between one of the following options in generating the MOB_NBR-ADV message:
a) An RS may broadcast the MOB_NBR-ADV message without modifying the neighbor list of the MR_NBR-INFO message, received from the MR-BS.
b) An RS may further customize and compose a MOB_NBR-ADV message that is suitable for its service area by utilizing the information present in the MR_NBR-INFO messages received from the MR-BS as well as any additional information that the RS itself may have obtained, for instance by scanning or measurement.
6.3.21.1.2 MS scanning of neighbor BSs
Insert new subclause 6.3.21.1.2.1 as follows:
6.3.21.1.2.1 MR-BSs and RSs behavior during MS scanning of neighbor BSs
The MR-BS shall control MS scanning. An RS relays MOB_SCN-REQ, MOB_SCN-RSP and MOB_SCN-REP messages between an MS and the MR-BS.
In the case of an scheduling RS, the MR-BS sends MS_SCN-INF message to inform the access RS of MS scanning related information after the MR-BS determines the scanning intervals of MS. The access RS shall transmit MR_Generic-ACK message or MR Acknowledgement header (as defined in 6.3.2.1.2.2.2.3) as an acknowledgement of MS_SCN-INF. In the case of an scheduling RS, the MR-BS shall transmit MOB_SCN-RSP to the MS after it receives MR_Generic-ACK or MR Acknowledgement header from the access RS. Based on MS_SCN-INF message, the access RS schedules MS data transmission.
In the distributed security case, an access RS may get scanning related information from MOB_SCN-RSP sent by the MR-BS. The received MOB_SCN-RSP is protected with CMAC/HMAC calculated by a key shared between the access RS and the MR-BS. After re-calculating CMAC/HMAC with a key shared between the access RS and the MS, the access RS relays the MOB_SCN-RSP to MS.
The MR-BS shall transmit the MS_SCN-CLT message to inform an access RS that the group of intervals of MS is terminated. The access RS shall assume that the MS is no longer in scanning mode when the access RS receives MS_SCN-CLT message or a MAC PDU of MS.
6.3.21.1.3 Association procedure
Insert new subclause 6.3.21.1.3.4 as follows:
6.3.21.1.3.4 MR-BS and RSs behavior during association procedure
In a MR system with the non-transparent RS with unique BSID operating in centralized scheduling mode, when the serving MR-BS decides to recommend that the MS scan neighbor stations with association level 1 or 2, the MR-BS shall notify the neighbor stations of the association parameters (i.e., Rendezvous time, unique CDMA code, Transmission opportunity offset, UL CINR) after sending the MOB_SCN-RSP message.
— If the neighbor station is the serving MR-BS itself, it already owns the association parameters.
Copyright © 2009 IEEE. All rights reserved. 155
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
— If the neighbor station is a RS inside the MR-cell the MS attached to, the serving MR-BS shall notify the neighbor station via a MR_ASC-RSP message.
— If the neighbor station is outside the MR-cell the MS attached to, the serving MR-BS shall notify the neighbor MR-BS via the network backbone. If the neighbor station is a RS, the neighbor MR-BS shall then notify the neighbor station via a MR_ASC-RSP message.
In a MR system with scheduling RS, when the serving MR-BS decides to recommend that the MS scan neighbor stations with association level 1 or 2, it shall obtain association parameters available from the neighbor stations before sending the MOB_SCN-RSP message.
— If the neighbor station is the serving MR-BS itself, the association parameters are already available at the serving MR-BS.
— If the neighbor station is an RS in the same cell as the MS, the serving MR-BS shall send an MR_ASC-REQ message to the RS to request the association parameters.
— If the neighbor station is in a different MR-cell from the MS, the MS’s serving MR-BS shall request the neighbor station’s association parameters from the neighbor MR-BS over the backbone network. If the neighbor station is an RS, the neighbor MR-BS shall then send an MR_ASC-REQ message to the RS.
— Upon receiving an MR_ASC-REQ message from its serving MR-BS, an RS shall reply with an association response (MR_ASC-RSP) message to indicate the association level allocated to the MS. If the allocated association level is 1 or 2, the MR_ASC-RSP shall include the association parameters (i.e., Rendezvous time, CDMA code, and Transmission opportunity offset).
— Upon receiving these association parameters, the serving MR-BS shall determine whether the association parameters satisfy the MSs’ association requirements or not. If they do, the serving MR-BS shall include those association parameters in the MOB_SCN-RSP message.
For MS neighbor scanning with association level 0 and 1, the access station shall perform the same tasks as contention-based initial ranging described in 6.3.10.3.1.1. The associated RS may unsolicitedly report the MS’s uplink quality to its serving MR-BS by sending an RNG-RSP message with association info TLV to its serving MR-BS.
For MS neighbor scanning with association level 2, the transparent RS and non-transparent RS with shared BSID shall perform the same tasks as contention-based initial ranging described in 6.3.10.3.1.1. Instead of sending a RNG-RSP message to the MS, the neighbor non-transparent RS with unique BSID shall send a RNG-RSP message to the MR-BS containing corresponding ranging information to the MR-BS.
6.3.21.2 HO process
Insert new subclause 6.3.21.2.12 as follows:
6.3.21.2.12 MR-BSs and RSs behavior during HO process
An MR-BS shall control handover process, and an RS shall relay handover associated messages between an MS and the MR-BS. After handover in MR networks, the routing information along the old and new path may be updated as per 6.3.28. The QoS information along the old and new path may be updated as per 6.3.14.
6.3.21.2.12.1 MS handover among access stations
If a serving MR-BS recognizes that MS attaches to a new access station or Resource retain timer expires, and the MS’s old access station is an RS that is controlled by the MR-BS, the MR-BS may send the MS_INFO-DEL message to make the RS discard MS context information. Upon receiving the MS_INFO-
156 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
DEL message, the RS shall transmit MR_Generic-ACK or MR Acknowledgement header (as defined in 6.3.2.1.2.2.2.3) as a reply and remove the MS context information.
6.3.21.2.12.2 MS drops during handover
In MR network, if the target MR-BS is informed of MS attachment to a different RS or different MR-BS from what is originally targeted due to the drop, the target MR-BS may send MS_INFO-DEL message to make the original target RS discard MS context information. Upon receiving the MS_INFO-DEL message, the RS shall transmit MR_Generic-ACK message or MR Acknowledgement header as an acknowledgement and remove the MS context information.
6.3.21.2.12.3 MS Context Transfer for HO optimization in MR
When an MS performs optimized HO in an MR network, MS context, such as MS supporting physical parameters and MAC features, Service Flow parameters and Security context (if operating in distributed security mode), should be transferred to the target station. There are two ways to transfer MS context, serving station initiated transfer and target station initiated transfer.
In the serving station initiated transfer for distributed security mode, the serving station may initiate MS_Context-REQ with type=0 (notification), when it receives MOB_MSHO/BSHO-REQ or MOB_HO-IND message.
— When the serving station is the MR-BS and the target station is its subordinate RS, the MR-BS sends the MS_Context-REQ to the target RS.
— When the target station is the MR-BS of the serving station (RS), the serving RS sends the MS_Context-REQ to the MR-BS.
— When the serving RS and target RS are under the same MR-BS, the serving RS sends the MS_Context-REQ message to the target RS through the MR-BS.
— When the serving station is an RS, the RS shall not include MS_Context TLVs that contain context information that the MR-BS also possesses. Instead, the MR-BS shall add the relevant MS_Context TLVs to the received MS_Context-REQ message and send it to the target station.
— In response to the MS_Context-REQ, the target RS or MR-BS send MS_Context-RSP with type=0 (acknowledgement).
— When the target RS does not exist in the same MR-BS, the serving MR-BS communicates with the target MR-BS for MS context via the backbone network. Protocol of backbone network is out of scope of this standard.
In the Serving station initiated transfer for centralized security mode, the MR-BS may send MS_Context-REQ with type=0 (notification) to the target RS, when it sends MOB_BSHO-REQ to MS or it receives MS context over the backbone network, or it receives MOB_MSHO-REQ or MOB_HO-IND message from MS. Then, the target RS sends MS_Context-RSP with type=0 (acknowledgement) to the MR-BS.
Figure 149a and Figure 149b show examples of serving station initiated transfer in MS handover operation in Intra-MR and Inter-MR operating, respectively. In the examples, the MS_Context-REQ message sent by the serving RS contains SS MAC Address TLV, BSID TLV and TLVs related to MS context that the MR-BS does not possess. The BSID TLV represents the target station. Therefore, when the MR-BS receives the MS_Context-REQ from the serving RS, it examines the BSID TLV. If the BSID TLV indicates the MR-BS itself, the MR-BS sends back MS_Context-RSP to the serving RS. If it indicates a subordinate RS of the MR-BS, the MR-BS sends MS_Context-REQ with type=0 to the RS after removing BSID TLV. Then the RS sends back MS_Context-RSP to the serving RS through the MR-BS. If the BSID does not indicate a station within the MR cell, the MR-BS sends a message to the backbone network to inform the target station of MS context.
Copyright © 2009 IEEE. All rights reserved. 157
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
In the case of RSs operating in centralized security mode, message exchanges between the target RS and the MR-BS in the Figure 149a and Figure 149b are performed.
Figure 149a—Serving station initiated transfer (Intra-MR)
Figure 149b—Serving station initiated transfer (Inter-MR)
In the target station initiated transfer for distributed security mode, the target station may initiate MS_Context-REQ with type=1 (request), when it receives a RNG-REQ message containing the Serving BSID TLV from an MS and does not possess context of the MS.
— When the target station is the MR-BS and the serving station is its subordinate RS, the MR-BS sends the MS_Context-REQ to the serving RS.
— When the target station is the RS and the serving station is its MR-BS, the target RS sends the MS_Context-REQ to the MR-BS.
— When the serving RS and target RS are under the same MR-BS, the target RS sends the MS_Context-REQ message to the serving RS through the MR-BS.
— The serving RS and MR-BS send MS_Context-RSP with type=1 (response) in response to the MS_Context-REQ.
— When the serving station is an RS, the RS shall not include MS_Context TLVs that the MR-BS also possesses. Instead, the MR-BS shall add its possessing MS_Context TLVs to the received MS_Context-RSP message and send it to the target station.
— When the serving station does not exist in the same MR cell, the target MR-BS sends request to the serving MR-BS over the backbone network to obtain MS context. Protocol of backbone network is out of scope of this standard.
Target RS MR-BS Serving RS
MS_Context-REQ MS_Context-REQ(*)
MS_Context-RSP MS_Context-RSP(* )
(* ) Note: only applicable in distributed security mode
Target RS MR-BS
MS_Context-REQ
MS_Context-RSP
MR-BS Serving RS
MS_Context-REQ(*)
MS_Context-RSP(* )
backbone
backbone
(* ) Note: only applicable in distributed security mode
158 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
In the target station initiated transfer for centralized security mode, the target RS may send MS_Context-REQ with type=1 (request) to the MR-BS, when it receives a RNG-REQ message containing the Serving BSID TLV from an MS and does not possess context of the MS. Then, the MR-BS sends MS_Context-RSP with type=1 (response) to the target RS. When the serving station does not exist in the same MR cell, the target MR-BS communicates with the serving MR-BS for the MS context via backbone network. Protocol of backbone network is out of scope of this standard.
Figure 149c and Figure 149d show examples of target station initiated transfer in MS handover operation in Intra-MR and Inter-MR operating, respectively. In the examples, the MS_Context-REQ message sent by the target station contains SS MAC Address TLV, BSID TLV. The BSID TLV represents the serving station. Therefore, when the MR-BS receives the MS_Context-REQ from the target RS, it examines the BSID TLV. If the BSID TLV indicates the MR-BS itself, the MR-BS sends back MS_Context-RSP to the target RS. If it indicates a subordinate RS of the MR-BS, the MR-BS sends MS_Context-REQ with type=1 to the RS after removing the BSID TLV. Then the RS sends MS_Context-RSP in response to the MS_Context-REQ and the MS_Context-RSP is sent to the target RS through the MR-BS. The MS_Context-RSP shall contain TLVs related to MS context. If the BSID does not indicate a station within the MR cell, the MR-BS sends a message to the backbone network to inform the serving station of the request for MS context. The message sent to the backbone is out of scope of this standard.
In the case of RSs operating in centralized security mode, message exchanges between the target RS and the MR-BS in the Figure 149c and Figure 149d are performed.
Figure 149c—Target station initiated transfer (Intra-MR)
Figure 149d—Target station initiated transfer (Inter-MR)
Target RS MR-BS Serving RS
MS_Context-RSP MS_Context-RSP(* )
MS_Context-REQMS_Context-REQ(*)
(* ) Note: only applicable in distributed security mode
Target RS MR-BS
MS_Context-RSP
MS_Context-REQ
MR-BS Serving RS
MS_Context-RSP(*)
MS_Context-REQ(*) backbone
backbone
(* ) Note: only applicable in distributed security mode
Copyright © 2009 IEEE. All rights reserved. 159
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
6.3.21.2.12.4 MS HO Optimization in MR in distributed security mode
Depending on MS context that the target RS has obtained as a result of MS context transfer described in 6.3.21.2.12.3, the target RS sends HO Process Optimization TLV to the MS based on 6.3.21.2.10.
Upon receiving RNG-REQ from MS, the following procedures apply:
— If the MR-BS decides to proceed with the full authentication, the MR-BS shall set both bit 1 and bit 2 to 0 in HO Optimization TLV to indicate to perform the full re-authentication and SA-TEK 3-way handshake.
— When the MR-BS sets the HO Optimization bits 1 and bit 2 to 1,if the AK is not present on the target RS, the target RS shall request the MS’s AK and TEK contexts from MR-BS.
— When the MR-BS sets HO Optimization bits 1 and bit 2 to 1 and when the valid AK and TEK is present on the target RS, the target RS shall omit re-authentication and the new TEK generation.
— When the valid AK is present but TEK expiration timer reaches its maximum, the MR-BS shall set the HO Optimization bits 1 to 1 and bit 2 to 0, and initiate the SA-TEK 3-way handshake.
Insert new subclause 6.3.21.4 as follows:
6.3.21.4 Mobile relay station handover
This subclause defines the MRS HO process in which an MRS migrates from the air-interface provided by one access station to the air-interface provided by another access station. The MRS HO process is depicted in Figure 150a.
160 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Figure 150a—MRS HO process
The MRS HO process consists of the same stages as those defined for MS HO process with the following additional stages:
— Access station selection. This stage enables the target MR-BS to indicate access station reselection. The target MR-BS may decide to skip this step if bit 5 in the RS network entry optimization TLV in the RNG-RSP message is set.
— MRS operational parameter configuration. This stage enables the target MR-BS to reconfigure MRS operational parameters. The target MR-BS may decide to skip this step if bit 6 in RS network entry optimization TLV in the RNG-RSP message is set.
— Tunnel connection re-establishment. This stage enables the target MR-BS to re-establish tunnel connections for an MRS. The target MR-BS may decide to skip this step if bit 7 in RS network entry optimization TLV in the RNG-RSP message is set.
— MS CID mapping: This stage is used for the target MR-BS to inform the MRS, which is performing the handover, about the mapping of new CIDs and old CIDs of its subordinate MSs. The MRS shall
RS operation(Cell selection by R-
amble scan)
Downlinksynchronization
established
Scan for target stationdownlink channel
Uplink parametersacquired
Obtain target stationUL parameters
Ranging &automatic
adjustmentscomplete
Ranging & automaticadjustments with
target station
Basic capabilitiesnegotiated
Negotiate basiccapabilities
RS authorizationwith complete
RS authorization &key exchange
Registrationcomplete
RS registration withMR-BS
Path selectioncomplete
Path selection
RS operationalparameter
configurationcomplete
RS operationalparameters
configuration
Tunnel connectionre-establishment
complete
Tunnel connection re-establishment
MS CID mappingcomplete
MS CID mapping
HO decision
Copyright © 2009 IEEE. All rights reserved. 161
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
use this information to swap the new CIDs with the old CIDs before forwarding the MAC PDUs to the subordinate MSs after the handover. This stage shall be omitted for tunnel based forwarding.
6.3.21.4.1 Mobile RS handover process without preamble change
The MRS Handover process hands off all the MSs attached to itself, along with the MRS, to a target MR-BS. It follows the same procedures as described for an MS handover in 6.3.21.2. The procedures, where certain steps are different, are described in this subclause.
6.3.21.4.1.1 HO decision and initiation
When MRS makes a decision for handover, it sends MOB_MSHO-REQ message on its basic CID to the Serving MR-BS. The MR-BS, knowing that the basic CID belongs to an MRS, sends MOB_BSHO-RSP message. The serving MR-BS may send the MAC address of the MRS, along with the MAC addresses, SFIDs and CIDs of the MSs attached to the MRS, to the target MR-BS using the backbone message. The backbone message definition is beyond the scope of this standard. In the tunneling case, the tunnel information shall also be carried, which includes CID(s) and QoS parameter(s) of the tunnel(s).
The serving MR-BS initiates handover for an MRS by sending MOB_BSHO-REQ message on the MRS basic CID.
6.3.21.4.1.2 Network entry/reentry
During network entry/re-entry, the MRS informs the MR-BS that it is an MRS by REG-REQ. The serving MR-BS may exchange backbone messages with the target MR-BS to pass the MAC addresses, SFIDs, and CIDs of all the MSs attached to the MRS. The details of the backbone messages are beyond the scope of this standard.
In the non-tunneling case, the target MR-BS may allocate new CIDs to MSs during ranging procedure with the MRS. If new CIDs are assigned, then MR-BS shall send old and new CID pairs to the MRS by CID list TLV in RNG-RSP. The MRS creates mapping between old and new CID. It replaces old CID with the new CID in the UL MAC PDUs. Similarly, it replaces new CID with the old CID in the DL MAC PDUs.
In the centralized security control mode (7.1.6), the CID used in the CMAC calculation (7.5.4.4.1) by the MR-BS shall be the old CID. In the distributed security control mode (7.1.7), the CID used in the CMAC calculation (7.5.4.4.1) by the MRS shall be the old CID.
In the tunneling case, the target MR-BS may allocate new CIDs to tunnels during the ranging procedure and then send old and new tunnel CID pairs to the MRS by tunnel CID list TLV in RNG-RSP. After getting the relationship of old and new tunnels, MRS can route MS MAC PDU according to the combination of Tunnel CID and MS CID.
6.3.21.4.2 MRS handover with preamble change (Inter MR-BS)
This subclause describes the MRS handover (Inter MR-BS), which hands over an MRS as well as all the MSs attached to it, with a detection of a preamble change. Both of the MR-BS and the MRS maintain a list of MSs that are served through an MRS. An MRS HO begins with a decision for an MRS to handover itself and to make MSs to handover from a serving MR-BS to a target MR-BS. The decision may originate either at the MRS or the serving MR-BS.
The operation of MRS Handover is divided into two steps: a negotiation between an MRS and a serving MR-BS for MRS Handover, and a procedure for MS Handover.
MRS initiates handover by sending MOB_MSHO-REQ message to the serving MR-BS with its basic CID.
162 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
The serving MR-BS recognizes that an MRS is requesting HO from the basic CID in MAC header. Upon reception of MOB_MSHO-REQ message, the MR-BS sends MOB_BSHO-RSP message to the MRS.
If the target MR-BS decides to change the MRS’ preamble after the handover, it sends a preamble index to the serving MR-BS over the backbone. Then the serving MR-BS sends it to the MRS using the Preamble Index TLV in the MOB_BSHO-REQ/RSP messages. If the FA of MRS needs to be changed, on receiving MOB_BSHO-REQ/RSP from serving MR-BS, the MRS may broadcast a MOB_NBR-ADV message regardless of the MOB_NBR-ADV interval, to inform the MSs of the new access link channel characteristics. The MRS itself shall be included in the neighbor station list with the IEs set according to the target access link channel characteristics.
The serving MR-BS exchanges handover decision and initiation stage signaling (6.3.21.2.2) with each MS before the MRS conducts handover and preamble change. The MOB_BSHO-REQ message is sent to the subordinate MSs with the “HO operation mode” set to 1. The operation of MS receiving the MOB_BSHO-REQ follows the procedures in 6.3.21.2. After the MRS transmits MOB_HO-IND to start its own HO, the MRS may unsolicitedly discard the remained MS context information.
When the serving MR-BS attempts a handover, it sends a MOB_BSHO-REQ message to the MRS. The subsequent procedures are the same as MRS initiated handover.
6.3.21.4.3 MRS handover with preamble index changes (Intra MR-BS)
During the movement of an MRS, if there is a preamble collision or co-channel interference strength measured is higher than the preamble (segment) reselection threshold and the interference lasts longer than the duration threshold, the MRS may re-select the preamble (segment) within the preamble-reselection window. Preamble collision and co-channel interference may be measured on R-amble. The parameters governing the preamble (segment) reselection procedure of MRSs is broadcasted in the R-link channel descriptor (RCD) message as TLV of Preamble (segment) reselection threshold.
When the MRS coverage area overlaps with another RSs/BSs coverage area, MR-BS may initiate MRS preamble reassignment procedures as defined in 9.4, using RS_Config-CMD. If the MRS preamble is changed then all the active MS connections are handed over to the same MRS using procedures in 6.3.21. All the associated MSs within the MRS’s serving coverage are switched to the newly assigned preamble index via MOB_BSHO-REQ/RSP. The MRS preamble is changed using the RS_Config-CMD.
The MOB_BSHO-REQ message may carry the same BSID as the serving BS ID in the “Neighbor BSID” field while the “Preamble index/Subchannel index” field is changed to the newly preamble index, under mode=0b000.
After sending out MOB_BSHO-REQ message, the MRS segment reassignment procedure is executed using RS_Config-CMD messages. Alternatively, one MRS may request to join another MRS with the same preamble to form an RS group. The RS group then serves all the MSs that are served by these two MRSs. The procedure to form or delete an RS group is explained in 6.3.34.
6.3.21.4.4 MRS drops during handover
If MRS detects its drop during network re-entry at target MR-BS, MRS shall attempt to resume communication with the serving MR-BS by transmitting new MOB_HO-IND with HO-IND_type=0b01 to cancel handover if the resource_retain_timer has not expired. If the resource_retain_timer has expired, the MRS may attempt network re-entry with its preferred target MR-BS as through cell reselection. If the MRS fails network re-entry with its preferred target MR-BS, the MRS shall perform initial network entry procedure.
Copyright © 2009 IEEE. All rights reserved. 163
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
When performing network entry, MRS shall perform CDMA ranging with target MR-BS using a code from the HO codes domain. Upon target MR-BS sending RNG-RSP with ‘ranging status’ =success, target MR-BS shall provide CDMA_ALLOC_IE with appropriate UL allocation for RNG-REQ from MRS. MRS shall send RNG-REQ with MAC address and HMAC/CMAC. Target MR-BS may now identify that HO attempt by MRS was not coordinated with Serving MR-BS and may request all relevant MRS context and attached MS’s context from Serving BS. Using this information target MR-BS shall now send RNG-RSP with ‘RS network entry optimization TLV’ bitmap and network re-entry may continue as in the typical, non-drop case.
When serving BS detects a drop, it shall react as if a MOB_HO-IND message has been received with HO-IND_type=0b00.
6.3.22 Multicast and broadcast services (MBS)
Insert new subclause 6.3.22.5 as follows:
6.3.22.5 MBS in an MR network
In MR networks, MBS transmission within an MBS zone shall be synchronized. In Multi-MR-BS-MBS case, MR-BSs may be synchronized in network level as described in 6.3.22.2.
All RSs and the MR-BS within the MR cell shall be in the same MBS zone.
To facilitate MBS transmission synchronization, an RS shall report its processing delay (in units of a frame), DR, to the MR-BS as a capability parameter in the SBC-REQ message. When an MBS transmission is necessary, the MR-BS shall first send the MBS data over the relay downlink as a pre-transmission.
When MBS data synchronization with pre-defined relative transmission time is selected, if there is only one RS connecting with the MR-BS, the MR-BS shall first send the MBS data over the relay downlink as a pre-transmission, and then after DR frames, the MR-BS and RS shall synchronously transmit this MBS data over the access link. If there are multiple RSs in the MBS zone at various hop counts from the MR-BS and/or with different processing delays, each RS shall report its processing delay, DR, to the MR-BS as a capability parameter in the SBC-REQ message. The MR-BS shall determine the maximum cumulative delay, DM, of all RSs in the MBS zone based on their positions in the tree and their individual processing delays. The MR-BS shall then calculate the required RS waiting time for MBS transmission, Wm, for each RS based on the value of DM and each RS’s cumulative delay and notify each RS of its waiting time via an RS_Config-CMD message. If the MR-BS detects that the waiting time has changed for a particular RS, it may send an RS_Config-CMD message to that RS to update its waiting time. When RS receives a RS_Config-CMD message with updated waiting time, it shall send either an MR_Generic-ACK message or an MR Acknowledgement header to MR-BS as an acknowledgement for the unsolicited RS_Config-CMD message. The MR-BS may retransmit RS_Config-CMD message with the updated waiting time if it does not receive MR Acknowledgement header before the expiration of T58 timer.
When an MBS transmission is necessary, the MR-BS shall forward the MBS data over the relay downlink as a pre-transmission DM frames before transmitting this MBS data over the access link. Each RS in the MBS zone shall forward the MBS data it receives over the relay downlink. Finally, once the MR-BS has waited DM frames and each RS has waited its specified waiting time, Wm, the MR-BS and RSs shall synchronously transmit the MBS data over the access link.
When MBS data synchronization with target transmission time is selected, the MR-BS shall insert an Allocation subheader in the MBS MAC PDU that is sent to the access RS. The Allocation subheader shall include the target transmission frame number at which the RS shall forward the MBS MAC PDU to the MS. The RS shall remove relay MAC header and subheaders and transmit the MBS data to MS over access link in the target transmission frame. This capability can only be supported in tunnel packet mode. The
164 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
intermediate RS shall relay MBS data to its subordinate RSs based on the constraints of QoS parameters forthe RS’s relay connection for the MBS data. During MBS connection setup for an MS, if a relay path withsuitable characteristics, such as per-hop QoS configuration, is not available to an Access RS, the MR-BSmay initiate the creation of a new relay path to the Access RS with the required characteristics, such as per-hop QoS configuration, using DSA messages. The QoS parameters of any of the constituent per-hopconnections on an existing relay path to an Access RS may be changed by the MR-BS via DSC messages.
If an RS fails to transmit an MBS data burst at its target transmission frame, the RS shall inform the MR-BSof the failure by sending Access Link Transmission Status feedback header (Feedback type 1110). The RSshall include the duration of late arrival for this MBS data burst in unit of frames. In addition, an RS mayprovide early arrival information to the MR-BS by sending Access Link Transmission Status feedbackheader if the RS determines an MBS data burst has arrived earlier than Relay Data Early Arrival ReportThreshold to its target transmission frame. With early arrival detection, the RS shall include the number offrames exceeding the threshold that the MBS data burst has waited to be transmitted. When Relay DataEarly Arrival Report Threshold is set to 0, the early arrival reporting is disabled.
6.3.23 MS idle mode (optional)
Insert the following text after the third paragraph of 6.3.23:
FRS may have same or just a subset of Paging Groups compared to controlling MR-BS. MRS shall beassigned one or more Paging Groups, which shall be different from MR-BS.
6.3.23.1 MS idle mode initiation
Insert the following text after the last paragraph of 6.3.23.1:
In the MR-cell, the intermediate RS shall relay the DREG-REQ/CMD message between the MR-BS andMS.
6.3.23.5 MS paging listening interval
Insert new subclause 6.3.23.5.1 as follows:
6.3.23.5.1 MS paging listening interval in MR system
For MR, all the idle-mode MSs that have the same PLI within the same paging group shall receive theMOB_PAG-ADV at the same time. The RS delay, DR, is given to MR-BS as a capability parameter of SBC-REQ message. If RS uses the same frame number that MR-BS uses, MR-BS may send MOB_PAG-ADVover the R-Link as a pre-transmission DR frame earlier than the normal MOB_PAG-ADV transmission time.MR-BS shall wait for DR frames, and then shall send MOB_PAG-ADV data again over the access link. IfRS uses a different frame number from the number that MR-BS uses, MR-BS may instruct transmissiontime at the RS by including RS transmit frame number TLV in MOB_PAG-ADV.
If multiple RSs with different delay performance exist, MR-BS shall firstly examine the cumulativeprocessing delay, DC, of each path between the MR-BS and the MS, then find the maximum of DC, which isDM. The MR-BS decides modified beginning frame of PLI for itself with DM. Then MR-BS examines theRS waiting time for Paging, Wp for each RS. The waiting time shall be notified in the RS_Config-CMDmessage.
If the RS uses the same frame number that MR-BS uses, the MR-BS may send MOB_PAG-ADV over theR-DL as a pre-transmission DM frame earlier than the normal MOB_PAG-ADV transmission over accesslink.
Copyright © 2009 IEEE. All rights reserved. 165
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
The MR-BS shall wait for DM frames. The RS shall wait for Wp frames, as notified by the MR-BS, andshall send MOB_PAG-ADV again over the access link. If RS uses different frame number from the numberthat MR-BS uses, MR-BS may instruct transmission time at the RS by including RS transmit frame numberTLV in MOB_PAG-ADV.
If the MR-BS detects that the waiting time for an RS needs to be changed, the MR-BS may send anRS_Config-CMD message to notify the RS that it needs to change its waiting time.
6.3.23.6 BS Broadcast paging message
Insert new subclause 6.3.23.6.1 as follows:
6.3.23.6.1 RS Broadcast Paging message
When paging is needed to some MSs in a Paging Group, RSs belonging to the Paging Group shall beinvolved to transmit MOB_PAG-ADV to the MSs. The paging information shall be transmitted by MR-BSto RSs in a relay link. When MR-BS need to transmit paging information to RSs, MR-BS shall calculate thetime to transmit in consideration of RS’s processing delay, DR, and RS frame offset so that RSs have enoughtime to decode and transmit MOB_PAG-ADV and paging delay will be minimized. When MR-BS transmitsa paging information to RSs, it may transmit MOB_PAG-ADV including RS transmit frame number TLV toRSs. When an RS receive MOB_PAG-ADV including RS transmit frame number TLV in a relay link, theRS shall restructure and transmit MOB_PAG-ADV by extracting the TLV and updating the length field atthe frame number as specified by the TLV.
When an RS receives MOB_PAG-ADV message from MR-BS or its upstream RS in the relay link, the RSshall forward the message to its subordinate RSs in the relay link. In centralized scheduling mode, thetransmission time shall be compensated based on the processing delay in each RSs as described in 6.3.23.5.In distributed scheduling mode, a Paging Interval TLV defined in 11.17.4 may be included in theMOB_PAG-ADV message transmitted in the relay link. This TLV informs RS of the Paging ListeningInterval for each paged MS.
When an RS received MOB_PAG-ADV message including the Paging Interval TLV in the relay link, theRS shall reconstruct the MOB_PAG-ADV message by removing the Paging Interval TLV, clearing the“Stop Paging” and “PLI Count” bits, and optionally include the TLVs defined in 11.17.1 and 11.17.2. Thereconstructed MOB_PAG-ADV message is transmitted in MS Paging Listening Interval in the access link.An RS may broadcast one or more broadcast paging messages during the MS Paging Listening Interval inthe access link.
After transmitting the broadcast paging message with Action Code ‘Perform Ranging’ or ‘Enter Network’,if the RS does not receive RNG-REQ from the MS paged until the next MS Paging Listening Interval, theRS shall retransmit the Broadcast Paging message. Every time the RS retransmits the broadcast pagingmessage, it decreases the predefined paging retry count by one.
In order to let MR-BS wait reasonable time for paging response, each RS shall calculate a paging retry countthat is decreased to zero at the closest PLI with its superordinate station. A PLI Count indication field maybe included in the MOB_PAG-ADV message transmitted in the relay link, which is described in 6.3.2.3.51.This field is used for indicating to the subordinate RS how many PLI of its superordinate station has elapsed.The RS shall determine its own paging retry count according to the PLI Count and the Paging Retry Countof MR-BS defined in Table 553.
When an RS relays the MOB_PAG-ADV message to its subordinate RSs, the “PLI Count” value may beincreased by one if the receiving RS will miss one more MOB_PAG-ADV message transmission over theaccess link.
166 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
When an RS receives the RNG-REQ for location updating or network reentry, it shall relay the RNG-REQto the MR-BS, and stop sending Broadcast Paging message. At the same time, it may generate and sendpaging stop command to its subordinate RSs who are still sending the broadcast paging message. The pagingstop command is fulfilled by setting the ‘Stop Paging’ bit in MOB_PAG-ADV described in 6.3.2.3.51.When an RS receives the paging stop command, it shall stop sending Broadcast Paging message, and relaythe paging stop command to its subordinate RSs who are still sending the Broadcast Paging message.
When intermediate RSs receive the relayed RNG-REQ message, they may stop sending Broadcast Pagingmessages. At the same time, it may generate and send a MOB_PAG-ADV with paging stop command to itssubordinate RSs that are still sending the Broadcast Paging message.
When an MR-BS receives the RNG-REQ, it shall stop sending Broadcast Paging message. It may generateand send paging stop command to its subordinate RSs who are still sending the broadcast paging message.
When an MR-BS receives paging stop announcement from paging controller, the MR-BS may generate andsend paging stop command to its subordinate RSs that is still sending the broadcast paging message.
If MR-BS has not received the RNG-REQ after the paging retry count decreases to zero, the MR-BS shallstart timer T63, which is based on the transmission delay from the last hop RS to the MR-BS. If the RNG-REQ is not received after the expiration of T63, the MR-BS regards the MS to be unavailable.
6.3.23.8.2 Location update process
Insert the following text after the first paragraph of 6.3.23.8.2.1:
When MS initiates location update process via Mobile RS, MR-BS may allocate MS the same PG ID that isassigned to MRS.
Insert the following text after the second paragraph of 6.3.23.8.2.1:
In the MR-cell, the intermediate RS shall relay the RNG-REQ/RSP message between the MR-BS and MS.
6.3.23.9 Network reentry from idle mode
Insert the following text after the last paragraph of 6.3.23.9:
In the MR-cell, the intermediate RS shall relay the RNG-REQ/RSP message between the MR-BS and MS.
Insert new subclause 6.3.23.10 as follows:
6.3.23.10 MRS paging group update
An MRS shall be affiliated with one or more paging groups, if the network is supporting MS idle mode. Thepaging groups with which the MRS is affiliated may be assigned to the MRS during initial network entryusing the RS_Config-CMD message. To avoid situations where all idle subordinate MSs3 initiate thelocation update procedure when the MRS hands over to or re-enters the network at a target MR-BS,procedures in the backbone network should be implemented to update the target MR-BS and possibly otherMR-BS with the paging groups of the MRS. If the MR-BS is generating the DCD to be broadcast by theMRS, the target MR-BS may include these paging groups in the DCD message to be broadcast by the MRSafter handover. The target MR-BS and possibly other MR-BS may also include the MRSs’ paging groups intheir own DCD. It is assumed that procedures in the backbone network are implemented to update thepaging controller with the location of the MRS.
3An idle MS is subordinate of an MRS if the MS has selected the MRS as its Preferred BS.
Copyright © 2009 IEEE. All rights reserved. 167
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Insert new subclause 6.3.28 as follows:
6.3.28 Relay path management and routing
Based on the topology information obtained from topology discovery or update process, MR-BS makes centralized calculation for the path between the MR-BS and an access RS for both the uplink and downlink direction. The path creation is subject to the constraints of tree topology (i.e., an RS shall have only one superordinate station) and other constraints such as the availability of radio resource, radio quality of the link, load condition of an RS, etc. The path calculation algorithm is out of scope of this standard.
Either embedded path management or explicit path management may be used.
6.3.28.1 Embedded path management for relay
When the embedded path management is used, the MR-BS shall systematically assign CIDs to its subordinate stations such that the CIDs allocated to all subordinate RSs of any given station is a subset of the allocated CIDs for that station. The network topology is embedded into a systematic CID structure to help RSs to find routing paths without storing all CIDs of subordinate RSs in the routing table.
CIDs are assigned systematically using either contiguous integer block or bit partitioning methods. Bit partition assignment shall only be used to allocate RS primary management CID or RS basic CID. For the contiguous integer block assignment, the CIDs assigned to subordinate stations are within a contiguous range defined by a pair of lower and upper bounds. In the bit partition assignment, a parameter, k, is configured to specify the maximum number of direct subordinate RSs that MR-BS or a superordinate RS could serve is 2 to the power k. The value of this parameter is the same within the MR cell. The MR-BS sets the k LSBs in ascending order to the RSs directly associated to the MR-BS. For other level-n RSs, which need n hops to reach the MR-BS, the MR-BS left shifts k bits of its parent CID and sets the k LSBs according to the arriving sequence of the RS. When the network topology changes, the MR-BS can inform related RSs of updated value of k and n in the RS_Config-CMD message (6.3.2.3.63). Figure shows an example of both methods for systematic CID assignment.
The MR-BS shall be responsible for managing all CID allocations within the MR-cell. By informing the range of systematic CID allocation to the RSs, the MR-BS already specifies the relay routing path of the connection based on assigned CIDs and is not required to provide end-to-end signaling for the purpose of routing table creation. With CID information contained in DL-MAP-IE or MAC header, RS can perform data forwarding to its subordinate RS. When MS moves to the coverage area of another RS connecting to the same MR-BS, its previously assigned systematic CID may not correspond to the routing path implied by the systematic CID assignment. In such case, the MR-BS may update the systematic CID for the MS according to its new routing path. Alternatively, the MR-BS tunnels all the packets for the MS to the RS using the systematic CID assigned to RS.
168 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Figure 154a—CID range allocation example, (a) contiguous integer block, (b) bit partition method
6.3.28.2 Explicit path management for relay
After MR-BS discovers the topology between a newly attached MS or RS and itself, or detects a topology update due to events such as mobility, MR-BS may remove an old path, establish a new path and inform the new path information to all the RSs on the path.
When connections are established or removed, MR-BS may distribute the mapping information between the connection and the path to all the RSs on the path. The connection could be a regular connection established for an MS (as defined in IEEE Std 802.16e) or a connection established for an RS (e.g., basic/primary management CID and tunnel connection). The path management procedures are specified below.
6.3.28.2.1 Path establishment, removal and update
After RS is operational, the MR-BS shall send a DSA-REQ message to distribute the path information to all the RSs on the path. The explicit path information and a uniquely assigned path ID shall be included. The CIDs to be routed on this path and their associated service flow parameters may also be included for path/CID binding operation.
If the MR-BS decides to remove an existing path (e.g., after an MRS handover), it shall send a DSD-REQ message with the path ID. The RSs receiving the DSD-REQ message shall remove all the information related to the path.
Upon receiving the DSA/DSD-REQ, the RS performs the operation as requested in the message, and then sends the request to its subordinate RS using the primary management CID of the subordinate RS that is obtained from the explicit path information included in the DSA/DSD-REQ message, or derived from the path information obtained from previous operation. Such process is repeated until the last RS on the path
MR-BS
00 00 00 01 00 00 00 10
00 00 01 0100 00 01 00 00 00 10 00 00 00 10 01
00 01 00 00
A
H
GFED
CB
00 01 00 01J
00 10 01 00P
00 10 01 01Q
00 01 00 10K
00 01 01 00L
00 10 00 00M
00 10 00 01N
MR-BS
1-1000 1001-2000
401-7001-400 1001-1400 1401-1800
401-500
201-300
101-2001-100
1001-1100
1101-1200
1401-1500
1501-1600
A
QPNMLKJH
GFED
CB
(a)
(b)
Copyright © 2009 IEEE. All rights reserved. 169
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
(i.e., the access RS) is reached. If an intermediate RS fails to process the request, it sends a DSA/DSD-RSP directly to MR-BS with the associated confirmation code. After receiving the DSA/DSD-REQ, the access RS then sends a DSA/DSD-RSP directly back to MR-BS.
The MR-BS may aggregate multiple path management commands into one DSA/DSD-REQ message to save bandwidth. When the paths of different path management commands in the same message divaricates in an RS, the RS separates the path establishment or removal commands into different messages and transmits them to the appropriate next-hop RSs.
6.3.28.2.2 CID to path binding
A routing table that contains the mapping between a CID and one given path needs to be updated when a new tunnel (identified by a Tunnel CID) is generated between the MR-BS and an access RS, or when a new connection (identified by an individual CID) is established for an RS or MS and the new connection is not put into a tunnel. The MR-BS selects a path to carry the traffic for the new connection, and informs all the RSs on the path of the binding between the path ID and the supported CIDs by sending a DSA-REQ message to all the RSs on the specified path. Such DSA-REQ message contains the CIDs of the connections that will be routed through the specified path, the path ID and optionally the service flow parameters for the connection. If the connection is a tunnel connection, the service flow parameters are the aggregate service flow parameters for all the connections put into the tunnel.
For multicast there may be more than one path bound to a single multicast CID.
When an RS on the path receives such a DSA-REQ message, it retrieves the CIDs and path ID information and builds up the routing table that will be used to route the traffic in the future for the specified CIDs. If the SFID and the QoS requirement are also present for certain connection, the RS saves them for scheduling the traffic for the specified CID. This process is repeated until the last RS along the path is reached. The last access RS then replies with the DSA-RSP.
If the MR-BS decides to cancel an existing binding between a path and one or more CID (e.g., after MS or MRS handover to another RS, or MS deregistration, or service flow deletion), it sends a DSD-REQ message with the path ID and the affected CIDs to the associated RSs. The RSs receiving such DSD-REQ shall remove the record of the correspondent mapping.
The processing of DSA/DSD-REQ by the RSs on the path is the same as that defined in 6.3.28.2.1.
The MR-BS may aggregate multiple CID to path binding commands in one DSA/DSD-REQ message to save bandwidth. In addition, when a path is established for one or more connections, the CID to path binding/unbinding procedure can be conducted together with the path establishment procedure by sending a single DSA-REQ or DSD-REQ to save bandwidth.
6.3.28.2.3 Temporary path establishment and CID to path binding during initial network entry
When an access RS does not use tunneling, a new path is determined by the MR-BS during MS/RS network entry, relay path management for forwarding the management messages of other MS/RS network entry procedures can be conducted as defined below.
— When an SS/RS performs initial ranging, it shall follow the steps indicated by the type of system in 6.3.10.3.1.1.
— When an RS receives RNG-RSP message with RS basic CID with path information, it shall bind basic CID and primary CID contained in the message with the path ID and start a timer T65 associated with the path ID. The RNG-RSP and the SBC-RSP messages shall be forwarded to the access RS by following the same mechanism defined for the DSA message in 6.3.28.2.2. If the RS is
170 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
the endpoint of the path, replace RS basic CID with ranging CID, and forward to the MS or RS originating RNG-REQ.
— If T65 expires before the RS receiving DSA-REQ, the RS shall remove the association between the path ID and basic CID and primary CID. Otherwise, the RS shall stop T65 when receiving DSA-REQ with the same path ID.
6.3.28.3 Relaying support for combined ranging and initial topology discovery
A combined initial ranging and initial topology discovery procedure can be conducted as defined below:— When an SS/RS performs initial ranging, it shall follow the steps indicated by the type of system in
6.3.10.3.1.1.— When an MR-BS receives an initial RNG-REQ from an SS/RS, it determines that the SS/RS sending
the RNG-REQ directly attaches to MR-BS and is just one hop away.— When an MR-BS receives a RNG-REQ message with the CID set to the basic CID of an RS, it shall
verify its validity after replacing the basic CID with the ranging CID. Since the MR-BS is already aware of the topology between the selected access RS and itself, by using the same mechanism as defined in this section, it establishes the topology between the SS/RS and itself.
6.3.28.4 R-link monitoring and reporting procedure for relay path management
Computation at the MR-BS of the end-to-end route quality metric for the multihop path between the MR-BS and an RS in its cell may, optionally, be enabled. Optionally, the stability of link quality may be considered as a metric for multihop path selection. A route quality metric may be derived at the MR-BS based on link measurements obtained from a CQI fast-feedback channel (CQICH) and/or from a REP-RSP message carrying an R-link TLV.
In the case of RSs operating in centralized scheduling mode, MR-BS may allocate CQICH to an RS in its cell for reporting CQI on DL transmissions originating at RS’s superordinate RS or MR-BS. Allocation of CQICH for RSs is performed in the relay zone.
In the case of scheduling RS, MR-BS and each RS in an MR cell may allocate CQICH to a subordinate RS. Allocation of CQICH for an RS is performed in the relay zone.
To report R-UL, R-DL and R-Link neighbor measurements, REP-RSP messages with R-Link TLV may optionally be used. An MR-BS may send a REP-REQ message to an RS in its cell requesting RSSI mean and standard deviation or CINR mean and standard deviation measurements. The RS may respond with a REP-RSP message containing R-Link TLV and requested measurements. MR-BS may use the reported measurements for route quality calculations, and optionally for computing the stability of a route.
6.3.28.4.1 Access-link monitoring and reporting procedure for MS path management
Computation at the MR-BS of the overall quality metric for the multihop path between the MR-BS and an MS in its cell may, optionally, be enabled. To enable routing metric computation at the MR-BS, R-link metrics shall be reported to the MR-BS in the REP-RSP message containing R-Link TLV, and access link metrics may optionally be reported to the MR-BS in the REP-RSP message containing Access-Link TLV. The REP-RSP message may be sent to the MR-BS in response to the REP-REQ message or by sending an unsolicited REP-RSP message. Access-link measurements at an MS may optionally be triggered by sending a MOB_SCN-RSP message (6.3.2.3.44) to the MS.
To enable DL CQI reporting, MR-BS may allocate CQICH to MSs in its cell. CQICH is allocated in the access zone on the access link hop, and may optionally be allocated in the relay zone on subsequent hops. Therefore, an RS may send to MR-BS CQI received from an MS in the access zone through a corresponding CQICH in the relay zone. A fast feedback region for reporting MS CQI values in the relay zone to the
Copyright © 2009 IEEE. All rights reserved. 171
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
MR-BS may be allocated by sending, in a unicast manner, a FAST-FEEDBACK allocation IE (8.4.5.4.9) to an RS. Fast feedback slot assignments in this region shall be the same as those in the CQI fast feedback region in the RS access zone.
6.3.28.5 Path management for multicast services
The MR-BS may initiate a multicast distribution tree for the MBS. Alternatively, an MS may initiate a MBS, by sending a DSA-REQ message with the MBS service request to the MR-BS. The procedures for establishing a multicast distribution tree are as follows.
When an MR-BS initiates a MBS or receives a DSA-REQ message with the MBS request from an MS, it checks whether the requested MBS has been created. If not, the MR-BS creates a multicast distribution tree for this MBS and allocates a multicast CID (MCID) to it. The MR-BS also determines the path(s) to carry this multicast service flow. The MR-BS creates the mapping between the determined path and the MCID. The MR-BS informs all the RSs on the path of the binding between the path ID and MCID by sending a DSA-REQ message along path as specified in 6.3.28.2. Each RS along the path stores the path ID and MCID binding information for forwarding multicast data with the MCID. The MR-BS adds this path to the multicast distribution tree and records the number and identification information of the MSs using the path for multicast communications. A multicast distribution tree may consist of multiple paths.
If the multicast distribution tree has been created and an MCID has been allocated to this MBS, the MR-BS determines the path to carry this multicast service flow. If the path is not in the multicast distribution tree, the MR-BS creates the binding between the determined path and the MCID. The MR-BS distributes the path and MCID binding information to all the RSs along the path. The MR-BS adds this path to the multicast distribution tree and records the number and identification information of the MSs using the path for multicast communications. If the path is already in the multicast distribution tree, the MR-BS simply updates the number and identification information of the MSs using the path for the MBS in the multicast tree.
A path may be removed from a multicast distribution tree by the MR-BS. When an MS needs to leave the multicast service, the MS sends a DSD-REQ to the MR-BS to request removing it from the multicast service flow. The MR-BS first updates the number and identification information of the MSs that are receiving the MBS along the path to this requesting MS. The MR-BS determines whether the path can be removed from the tree MCID. If no more MSs use this path for the MBS, the path may be removed from the multicast distribution tree. Otherwise, the path shall not be removed from the multicast distribution tree. If the path is removed from the tree-MCID then the MR-BS removes the binding between the path and the MCID by sending a DSD-REQ along path as specified in 6.3.28.2.
When the parameters for a multicast service flow change, an MR-BS or MS may also send a DSC-REQ message to update these changes. All the RSs in the multicast distribution tree of the MBS are informed of these changes. This is achieved by MR-BS sending a DSC-REQ message to all of the RSs along all the paths in the multicast distribution tree as specified in 6.3.28.2.
6.3.28.6 Neighbor path metric for relay
An end-to-end metric of the path between an RS and its MR-BS may be reported in the MR_NBR-INFO message. The end-to-end metric is carried in the form of a TLV described in 11.4.
Insert new subclause 6.3.29 as follows:
6.3.29 Relay station neighborhood discovery
In order to perform RS neighborhood discovery, the RS may obtain its neighbor information using MR_NBR-INFO message (6.3.2.3.61). Then, it shall scan the preamble or, if present, the R-amble
172 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
transmitted by the existing MR-BS(s) or RS(s), and send the measurement report to the MR-BS using the RS _NBR-MEAS-REP message (6.3.2.3.64).
As not every RS will transmit its own preamble and the existing RSs in an MR network need to perform measurement over the preamble, the MR-BS may instruct the RSs to perform complete neighborhood discovery/measurement, as described further in this subclause.
The neighborhood discovery/measurement can be used in different stages of operation, during initial network entry, during periodic intervals or whenever an MR-BS requires this information. There are two methods to carry out neighborhood measurements:
1) Repeatable R-amble transmission and monitoring scheme2) Pre-planned R-amble transmission and monitoring scheme
6.3.29.1 Repeatable R-amble transmission and monitoring scheme
The transmission and monitoring frames for the R-amble are specified by the MR-BS in the RS_Config-CMD message (6.3.2.3.63). Each RS finds the R-amble sequences from the parameters provided in the RS_Config-CMD message. More details are provided in 8.4.6.1.1.4. The measurement results shall be sent to the MR-BS by using the RS_NBR_MEAS-REP message (6.3.2.3.64) or using any other appropriate measurement report messages, periodically or as requested by the MR-BS.
6.3.29.2 Pre-planned R-amble transmission and monitoring scheme
In this scheme, the MR-BS first sends the RS_Config-CMD message to the RSs that will be involved in the neighborhood measurement mechanism, and the message is either broadcast, multicast or unicast to these RSs. The 8 LSB bits of frame number shall be set to synchronize the starting time to the RSs. If the RSs involved in this mechanism are in a different MR-cell, each of the Start Frame Numbers sent by each MR-BSs shall be synchronized to the same frame time. The Prefix shall be set to “00” and attach the transmit/receive pattern for each iteration. The pattern is indicated by Amble Index, which are the indexes instructed in the RS_Config-CMD message.
Second, the stations follow the instruction to transmit/receive the R-amble at the designated frames in each iteration.
Third, the RSs report their RSSI or CINR measurement results with corresponding amble index by RS_NBR_MEAS-REP to MR-BS.
The pre-planned R-amble transmission opportunities are identified by Monitoring Duration and Interleaving Interval for each iteration. An example is given in Figure 154b, where the Duration = 2, Interleaving Interval = 3 and the Iteration = 2. When the Iteration is more than one, the pattern for each iteration shall be carried in this message. After the last iteration, the RSs shall report the measurement results by RS_NBR_MEAS-REP message defined in 6.3.2.3.64.
Figure 154b—R-amble transmission pattern as per the pre-planned scheme instructed by MR-BS
Copyright © 2009 IEEE. All rights reserved. 173
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Insert new subclause 6.3.30 as follows:
6.3.30 Interference measurement in MR systems
This subclause describes a measurement and reporting procedure with supported messaging mechanism to estimate the interference level in MR network.
6.3.30.1 Interference prediction by RS neighborhood measurement
In order to predict the interference or SINR of the radio links for different MR network topology and radio resource reuse pattern, the following prediction method may be considered based on the RSSI reported by RS_NBR_MEAS-REP message (see 6.3.2.3.64).
1) Prediction of the interference plus noise power received by station #i: The interference plus noise may be the summation of (1) the thermal noise plus background interference power received by station #i and (2) the signal power not intended to be received by station #i but transmitted by the same radio resource.
2) Prediction of the received SINR of station #i: The SINR may be the following ratio:— The total signal power destined to station # i to — The interference plus noise power obtained in step 1)
6.3.30.2 Optional interference detection and measurement by RS sounding
As an option, the path loss and interference between multiple RSs and the MR-BS can be estimated using the UL sounding mechanism (8.4.6.2.7). In order to predict the interferences between different RS cells, the MR-BS needs to collect the interference measurements from the related RSs and possibly from their associated MSs. The interference can be estimated by having one or multiple RSs or MSs transmit UL sounding signals at specific sounding zones and having the other related RSs and BSs measure the related CINR or RSSI of the received sounding signals. An MR-BS may construct a multicast group within its MR-cell that uses a multicast CID to represent the group of the RSs that participate in the interference measurement. Alternatively multiple unicast messages can be sent. This group is called RS_interference_measurement group and shall be setup before any measurement of UL sounding signals by the group. The interference measurement procedure is controlled by the MR-BS for intra-MR-cell interference measurement. For interference measurement performed across clusters of MR-cells, a network control entity is required to coordinate the measurement activities across the MR-cells.
The interference measurement operation within an MR cell is as follows: the MR-BS sends an REP-REQ message to its RS_interference_measurement group. The REP-REQ carries the reporting period, start frame number and the type of measurement reports (either CINR or RSSI). MR-BS sends UL_Sounding_Command_IE to RS_interference_measurement_group as a multicast burst. The MR-BS shall also transmit PAPR_Safety_and_Sounding_Zone_Allocation_IE. When an RS receives such an REP-REQ, it expects to hear the PAPR_Safety_and_Sounding_Zone_Allocation_IE (8.4.5.4.2) starting from the start frame number until the time indicated in the TLV of report period in the REP-REQ message. If an RS specified by the multicast CID in PAPR_Safety_and_Sounding_Zone_Allocation_IE, and indicated by CID in the UL_Sounding_Command_IE, the RS shall transmit the sounding signal at the specified symbol and subcarriers as instructed by the MR-BS. Otherwise, the RSs belonging to the RS_interference_measurement_group shall measure the sounding signals if they are not scheduled to transmit sounding signals in the same symbol. The scheduling of RS PAPR_Safety_and_Sounding_Zone_Allocation_IEs by MR-BS is implementation specific.
The sounding signal sent from different RSs and different MSs can be multiplexed in the same sounding zone. This can be done when the MR-BS or RS serving the MS sends to the MS a separate UL_Sounding_Command_IE with instruction of the sounding signal that may be sent by the MS. The measurement and reporting procedure of the MS UL sounding signal by the RSs in the
174 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
RS_interference_measurement_group remains the same as the RS sounding procedure. The average measurement results are reported. After an MR-BS receives the REP-RSP from all the RSs in its RS_interference_measurement_group, it shall forward it to the network control entity.
When interference across different MR-cells needs to be estimated, the above UL sounding procedure shall be conducted with the coordination of a network control entity that controls multiple BSs. In this case the network control entity shall coordinate the multiple BSs to send PAPR_Safety_and_Sounding_Zone_Allocation_IE and UL_Sounding_Command_IE to their respective RS_interference_measurement_groups and MSs for conducting UL sounding measurement across MR-cells. When the RS sounding signal is to be sent by an RS in one of the MR-cells, the same PAPR_Safety_and_Sounding_Zone_Allocation_IE and UL_Sounding_Command_IE shall be duplicated and sent in the other MR cells, so the RSs in these other cells shall conduct measurement on the UL sounding signal.
Insert new subclause 6.3.31 as follows:
6.3.31 RS broadcast message relaying
For a non-transparent RS operating in centralized scheduling mode, the MR-BS shall generate and send RS_Access-MAP message to the RS over the basic connection of the RS. When the RS receives the RS_Access-MAP message, RS shall compose FCH and possibly the associated MAPs such as DL/UL-MAP message, Compressed DL/UL-MAP, SUB-DL-UL-MAPs message and HARQ MAP message, etc., based on the RS_Access-MAP message. In case of more than two hops, the MR-BS shall generate and send RS-Relay-MAP message to RS over the basic connection of the RS. When RS receives RS-Relay-MAP message, RS shall compose R-FCH and R-MAP based on the RS_Relay-MAP message.
Upon receiving the DCD/UCD message with RS primary CID, as shown in Figure 154c, or RS multicast management CID, the RS shall acknowledge the reception of DCD or UCD messages over primary management connection by sending an acknowledgment header (see 6.3.2.1.2.2.2.3) or MR Generic-ACK message (see 6.3.2.3.79). The Transaction ID of the MR Acknowledgement header or 8 LSB of the transaction ID of the MR_Generic-ACK message shall be set to the Configuration Change Count of the DCD or UCD message. There shall be one MR Acknowledgement header or MR_Generic-ACK message per DCD/UCD message. The MR-BS may retransmit the DCD/UCD message if an acknowledgement header or message is not received at the expiration of T61 timer.
For a centralized scheduling mode RS, as shown in Figure 154d, after receiving an acknowledgement header from the RS corresponding to reception of the DCD/UCD, the MR-BS shall periodically allocate unsolicited bandwidth to the RS to enable it to broadcast the DCD/UCD message over the access link by using an RS_BW-Alloc_IE in the RS-Access-MAP message. To enable the RS to send the DCD/UCD message with fragmentable broadcast CID, if the RS_BW-Alloc_IE is lost, the RS shall request bandwidth by using an RS BR header after the timer T69 expires. For a scheduling RS, the RS shall autonomously broadcast DCD/UCD with fragmentable broadcast CID.
When the DCD and UCD messages are generated by the MR-BS, the MR-BS shall send DCD and UCD messages to either one RS with its primary management CID or multiple RSs with RS multicast management CID. In RS grouping, the superordinate station of the group shall use the multicast CID of the RS group to send RS RS_Access-MAP message.
Copyright © 2009 IEEE. All rights reserved. 175
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Figure 154c—Relaying DCD/UCD procedure
Figure 154d—DCD/UCD broadcasting procedure with an RS operating in centralized scheduling mode
In MR networks, each RS would be assigned to different DCD/UCD messages with the same configuration change count. In this case, each DCD/UCD message may be separated into the common part and the specific part before fragmentation. The common part shall be packed with multicast management CID, and the receiving RS shall buffer the common part until receiving the specific part that shall be packed as a new DCD/UCD message with the RS primary management CID. In the specific part, the message type field, reserved field and configuration change count field shall be the same as the associated common part. The receiving RS shall restructure the common part and the associated specific part to a complete DCD/UCD message, and then broadcast the message with Fragmentable Broadcast CID.
send map with broadcast CID R-MAP
MS
[Receive DCD or UCD]DCD or UCD
Send DCD or UCD with RS primary CID.
Serving MR-BS Access RS
Acknowledgment header Send Acknowledgment header containing DCD or UCD message type and Transaction ID as the 8-bit LSB DCD or UCD count
MS
DL-MAP
DCD/UCD
T69 timer expires
MR-BS RS
RS BW-ALLOC_IE in RS-Access-MAP
send unsolicited MAP IE Periodically
DL-MAP
DCD/UCD
DL-MAP
DCD/UCD
RS BR header
RS BW-ALLOC_IE in RS-Access-MAP
RS BW-ALLOC_IE in RS-Access-MAP
RS BW-ALLOC_IE in RS-Access-MAP
176 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Insert new subclause 6.3.31 as follows:
6.3.32 RS de-registration
In MR networks, an RS may end its service and be removed from the networks. During the RS de-registration process, all subordinate MSs of the RS shall be transferred to another RS or MR-BS prior to RS deregistration. An RS may transmit DREG-REQ to an MR-BS so that it initiates the de-registration procedure and requests handover of all its subordinate MSs. Upon receiving DREG-REQ, the MR-BS decides whether it allows the RS de-registration. If the request is accepted, the MR-BS may transmit DREG-CMD to inform the acceptance and start BS-initiated handover process for the requested MSs. After handover procedures between the MR-BS and the RS’s subordinate MSs are completed, the MR-BS informs the RS that handover is completed by transmitting DREG-CMD. Upon receiving DREG-CMD, the RS starts deregistration process. The MR-BS may initiate the de-registration process by transmitting an unsolicited DREG-CMD message.
If the MR-BS rejects the request (Action Code = 0x06), the MR-BS informs the RS rejection of the request by transmitting DREG-CMD. Upon receiving DREG-CMD with rejection information, the RS continues normal operation. After REQ-duration expires, the RS retransmits DREG-REQ to the MR-BS.
Insert new subclause 6.3.32 as follows:
6.3.33 MR location information
In order to assist RS neighborhood discovery, MR-BS may send an MR_LOC-REQ message to the RS. Upon receiving the MR_LOC-REQ message, the RS shall report its location information by sending an MR_LOC-RSP message to the MR-BS. If the MR_LOC-REQ message containing the report type field 0b01, RS shall periodically send an MR_LOC-RSP message to the serving MR-BS every time interval defined by “Report period.”
In order to obtain the location information of neighbor stations, an RS may send an MR_LOC-REQ message to the MR-BS. Upon receiving the MR_LOC-REQ message, MR-BS shall report the location information of neighboring stations by sending an MR_LOC-RSP message to the RS.
The message sequence charts (Figure 154e, Figure 154f, and Figure 154g) describe the RS location request and report that shall be followed by compliant RSs and MR-BSs.
Copyright © 2009 IEEE. All rights reserved. 177
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Figure 154e—Relay location report (part 1)
Figure 154f—Relay location report (part 2)
RSMR-BS
Transmit location information to MR-BS
MR_LOC-RSP
Request to report location information from RS to MR-BS
MR_LOC-REQ (Report Mode = periodic)
Transmit location information to MR-BS
MR_LOC-RSP
Transmit location information to MR-BS
MR_LOC-RSP
Rep
ort p
erio
dR
epor
t per
iod
RSMR-BS
Transmit location information to MR-BS
MR_LOC-RSP
Request to report location information from RS to MR-BS
MR_LOC-REQ (Report Mode = once)
178 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Figure 154g—Relay location report (part 3)
Insert new subclause 6.3.33 as follows:
6.3.34 RS grouping
The RS grouping method may be used to enable the following operation scenarios:— The operation of an RS in a location where no segment allocation is possible due to interference from
all other segments— The operation of MSs in a region served by multiple short-range RS without incurring high handover
signaling disadvantages— The operation of mobile RSs with dynamic adjustments of coordinated transmission and reception— Macro-diversity within an MR cell applied to individual SSs and individual connections
The grouping of RS and the coordinated operation of RS in a group is determined and controlled by its superordinated station or MR-BS.
— The members of the group are assigned a multicast CID as the RS group ID. The multicast CID is the same for all members in the group. Thus, an RS can be managed individually or as a group using the basic CID and this multicast CID. These IDs are unique within the associated MR-BS. The association of an RS to an RS group is configured using RS_Config-CMD message (see 6.3.2.3.63). The multicast CID of the RS group is used for messages that are addressed to all the members of the RS group, and the basic CID is used for the individual members of the RS group. When the MS performs network entry into an RS group, the MS network entry procedure outlined in 6.3.10.3.1.1 shall be followed. When the MS moves within the RS group, the MS movement procedure outlined in 6.3.34.1 shall be followed. For a transparent (or non-transparent) RS group all the other procedures follow the procedures for the transparent (or non-transparent) RS. For example, if the RS group is non-transparent, the MAPs for the individual RSs shall be received by the RSs according to the associated procedure defined for a non-transparent RS using the multicast CID of the RS group (see 6.3.31).
— The RS group has a superordinate station (non-transparent RS or MR-BS) that is the superordinate station of all RSs in the group. All the RSs in the RS group shall either transmit the same preamble, FCH and MAPs or they all do not transmit any preamble, FCH or MAPs. The MR-BS or the superordinate station carries out resource control and scheduling for the RS group. The non-transparent RS group transmitting with a preamble different from superordinate station’s preamble may be assigned a BSID parameter value. The RS group shall serve only MSs. The radio resources may be shared by the RSs members of the RS group for data burst transmission. The RSs members of the non-transparent RS group shall transmit with the same EIRP parameter value, decided by the MR-BS.
RSMR-BS
MR_LOC-REQ (Report Mode = once)
Transmit neighbor information to RS
MR-LOC-RSP
Request for neighbor RS location information from MR-BS
Copyright © 2009 IEEE. All rights reserved. 179
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
— Removal of an RS from the group: During normal operation of the RS group, each RS continues to monitor the radio environment (e.g., the interference). One example is that for an RS that is located at the edge of the group coverage area, it could detect strong segment interference from other nearby RS(s) or RS groups. When this happens, the MR-BS can reconfigure the RS(s) operate in a different RS operational mode using the TLV described in 11.25.1. For RS grouping, DL/UL reciprocity relied on by SS in the open loop power control may not hold. In this case, the SS power control correction term in Equation (146) may be used to set SS UL TX power to an appropriate level. Computation of the correction term is implementation specific.
— Addition of an RS to an existing group or forming a new group: An RS, at network entry, can a) operate on its own, i.e., it is assigned a dedicated preamble index (implying the segment), b) form a new group or c) join an existing group. The RS may perform measurements such as radio signals from the neighbor stations (the RSs or the MR-BS), and then report to the MR-BS the preferred preamble index selected by the RS (implying the segment). The MR-BS replies by either confirming the preamble sequence index selected by the RS or assigning a different one, indicating whether it should transmit the preamble, and at the same time, providing the corresponding RS group ID. The MR-BS may assign one of the members as the designated RS based on the measured signal qualities at the members. The designated RS may be responsible for certain procedures such as measurement reporting as specified elsewhere in this standard.
— For communication with RS groups, tunnel-based or CID based forwarding can be applied. If the MS/SS is served by an RS group, the tunnel connections shall be established between the MR-BS and the superordinate station of the RS group i.e., the superordinate station is considered as the access station for the tunnel connection that is the end-of-tunnel in DL and beginning-of-tunnel in UL.
— Data forwarding within RS group: For DL, the members of an RS group may be configured to forward traffic data for only specific subordinate terminal stations. This may be done on a per-connection basis. In this way, by specifying scheduling times, two RSs belonging to the same RS group may transmit to two different MSs/SSs at the same time. In addition, transmissions may be scheduled such that multiple RSs in the RS group may transmit to the same MS to exploit macro-diversity. This scheduling may be achieved for RSs operating in centralized scheduling mode by keeping CID list associated with each RS. Each RS would look for the data bound to its subordinated stations or data coming from the subordinate stations in the uplink and forward in the assigned times indicated in the MAP. The list may be updated by the RS_Member_List_Update message defined in 6.3.2.3.77 or DL_Transmit_Reference_IE defined in 6.3.2.3.80. If the MR-BS does not receive MR_Generic-ACK message from all RS group members designated in the RS_Member_List_Update message after the Frame Action Number, DL_Transmit_Reference IE should be used to encode the forwarding rules for the RS group members. The RS group members shall follow the forwarding rules encoded in DL_Transmit_Reference IE, if present, instead of its original forwarding rules to forward the data to the MS. If the RS_Member_List_Update message is not provided by the superordinate station to the RSs members of the RS group, then all RSs members of the group shall transmit according to the MAPs received, without using the per CID transmission. Data forwarding may also follow the procedure defined in 6.3.16.7 for DL HARQ for RS groups.
— For the UL, the UL signaling can be designed such that several member RSs may receive data from multiple MS at the same time. Data forwarding may also follow the procedure defined in 6.3.16.7for UL HARQ for RS groups. This scheduling may be achieved for RSs operating in centralized scheduling mode by keeping an MS list or CID list associated with each RS and forwarding those messages in a specified resource unit (time and frequency). When the MS is same and the resources are the same, it is equivalent to macro-diversity. When the resources are same but the MSs are different, it is equivalent to parallel transmission occurring at different locations.
— Each time a handover occurs or a new terminal joins an RS group, the list of CIDs for the RSs in the group may be updated.
180 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
6.3.34.1 MS movement among access stations that share the same BSID
The stations that share the same BSID (i.e., the non-transparent RSs that transmit the same preamble, FCH or MAPs or transparent RSs that have the same BSID), shall perform measurement of MS signal quality to assist MS movement among stations.
The stations shall measure the signal quality (RSSI, CINR), Timing Adjustment (TA), power and Frequency Adjustment (FA) for each active MS served by these stations to support MS mobility among these stations. All RSs shall use an MR_RNG-REP message to provide MR-BS/superordinate RS with the selected report metrics (RSSI and/or CINR, TA, FA and power adjustment) for each active MS when needed.
Two modes of operation are described in 6.3.34.1.1 and 6.3.34.1.2. The mode of operation and related reporting parameters are configured in RS_Config-CMD in 6.3.2.3.63.
An MR-BS/superordinate RS may select a new designated RS based on the measurement results and use RNG-RSP to adjust the timing and the power level of the MS, in order to fulfill the handover procedure. An MR-BS/superordinate RS may use the RS_Member_List_Update management message to notify the RSs of the changes regarding data forwarding status for the specified MSs.
6.3.34.1.1 Mode 1
For this mode of operation, only those RSs that are marked as designated RSs shall automatically report the measurement results to MR-BS/superordinate RS in an event-triggered or periodic way, for the basic CID of MSs provided in the RS_Member_List_Update.
For event-triggered reporting, the designated RS shall send an MR_RNG-REP message to report its measurement results if the selected triggering condition is met. The trigger condition could be RSSI, CINR, or TA and is specified in RS_Config-CMD message. For periodic reporting, the designated RS shall send an MR_RNG-REP message every REP_INT that is specified in RS_Config-CMD message and the MR-BS/superordinate RS shall periodically allocate uplink resource for the designated RS to report the latest measurement result for each active MS.
In Mode 1, non-designated RSs shall report their measurement results only if the RS_MOB_MEAS-REQ message is received. The MR-BS/superordinate RS shall send RS_MOB_MEAS-REQ message to request all or part of RSs in the same RS group to report their measurement results for a specific MS. The MR-BS/superordinate RS shall allocate uplink resource for the selected non-designated RSs to send their MR_RNG-REP messages at the frame specified in RS_MOB_MEAS-REQ.
6.3.34.1.2 Mode 2
For this mode of operation, an RS may report the measurement results to an MR-BS/superordinate RS using an MR_RNG-REP message in an event-triggered way as indicated below.
If the MR-BS/superordinate RS provides the thresholds values for triggering, the RS shall send the measurement report to MR-BS/superordinate RS in the following instances:
— When the measured RSSI/CINR crosses above RSSI/CINR_T_ADD[i] (i=0,...,NRSSI-1/NCINR-1).— When the measured RSSI/CINR crosses below the RSSI/CINR_T_DEL[i] (i=0,...,NRSSI-1/NCINR-
1).— When the current measured TA exceeds TA_DIFF and the RS has the CID of the MS included in the
RS_Member_List_Update message.
If the MR-BS/superordinate RS does not provide the threshold values for adding/removing an MS, the RS uses its own threshold values to decide when to report the measurement to MR-BS/superordinate RS.
Copyright © 2009 IEEE. All rights reserved. 181
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
7. Security sublayer
7.1 Architecture
Insert the following at the end of 7.1:
In multihop relay system, RS uses the same security architecture and procedures as an SS to provide privacy, authentication and confidentiality between itself and the MR-BS.
MR-BS and a group of RSs in MR cell maintain a set of trusted relationships, called Security Zone, in order to satisfy requirements of multi-hop relay system operation (see 7.1.8).
Insert new subclause 7.1.6 as follows:
7.1.6 Centralized Security Control in Multihop Relay System
7.1.6.1 MS security control
With centralized security control residing in the MR-BS in the multihop relay system, the security association is established between MS/RS and MR-BS without the involvement from the intermediate RS. The RS does not try to decrypt the user data or authenticate the MAC management message it receives from the MS, but simply relays it.
All the MS-related keys are stored and maintained at the MS and MR-BS, and RS does not have any key information associated with the MS.
7.1.6.2 RS security control
With centralized security control residing in the MR-BS in the multihop relay system, the security association is established between RS and MR-BS without the involvement from the intermediate RS. AK security context is shared and maintained at the particular RS and MR-BS, and the intermediate RS does not have this information. The intermediate RS authenticates management messages it receives from other RSs using relay-specific shared keys.
7.1.6.3 Protection of non-authenticated PKM messages
Similar to other MAC management messages, all the PKM messages are exchanged between MS/RS and MR-BS. For the PKM messages that are not protected by the message authentication code from the MS/RS (termed as non-authenticated PKM messages, e.g., Auth Request, Auth Reply, PKMv2 RSA-Request, PKMv2 RSA-Reply), the following procedure may be applied. For all the other cases, the access RS and the intermediate RSs just simply relay the PKM messages.
— Upon receiving a non-authenticated PKM message, the access RS may add the HMAC/CMAC tuple based on the SA established between itself and the MR-BS into the message.
— Upon receiving a non-authenticated PKM message with the presence of HMAC/CMAC tuple, the MR-BS authenticates the message based on the shared SA between itself and the access RS.
— When the MR-BS generates a non-authenticated PKM message to the MS, it may add the HMAC/CMAC tuple based on the SA established between itself and the access RS.
— Upon receiving a non-authenticated PKM message with the presence of HMAC/CMAC tuple, the access RS authenticates the message based on the SA between itself and MR-BS. If the message is valid, it then removes the HMAC/CMAC tuple, and then sends the PKM message to the MS.
182 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Insert new subclause 7.1.7 as follows:
7.1.7 Distributed security control in a multihop relay system
When an access RS is operating in distributed security mode, the authentication key established between SS and MR-BS is distributed to this RS.
During the registration process, an RS can be configured to operate in distributed security mode based on its capability. An RS operating in this mode relays initial PKM messages between the MR-BS and SS/subordinate RS. When the MSK for a subordinate RS/SS is established, the MR-BS shall securely transfer the relevant Authorization Key (AK) of the subordinate RS/SS to its access RS. The access RS derives all necessary keys and starts an SA-TEK 3-way handshake with the SS/subordinate RS if PKMv2 is used.
The access RS operating in distributed security mode runs a secure encapsulation protocol with the MR-BS and SS. TEKs are different for relay and access link and distributed by the MR-BS and the access RS respectively. After processing subheaders, if needed, the access RS shall re-encrypt the relayed MAC PDU.
During authentication, the Security Association (SA) that contains the security pertaining to an SS will be created between an SS, an access RS operating in distributed security mode and the MR-BS. Each SS shall effectively establish an exclusive primary SA with the RS, interacting with the RS as if it were a BS from the SS’s perspective. Each RS shall establish an exclusive primary SA with MR-BS. The scheme for identifying the primary SAIDs is as shown in Table 201a.
Table 201a—SA Identifications at multihop relay system with Distributed Security Control
7.1.7.1 Protection of SS’s management messages
After completing SS authentication and establishing a security association between SS and the access RS (see detail in 7.1.7), MAC management messages on the access link shall contain CMAC/HMAC calculated by a key shared between SS and its access RS, while MAC management messages on relay link shall contain CMAC/HMAC calculated by a key shared between RS and the MR-BS. The old CMAC/HMAC value shall be replaced with new CMAC/HMAC value when access RS relays a management message. If tunneling is used, the MT-CID in the relay MAC header assigned by the MR-BS shall be used in the calculation, otherwise the CID within the GMH shall be used.
7.1.7.2 Sharing HMAC/CMAC in management tunnel
Multiple MAC management messages from the connections belonging to the same management tunnel can be transported by the ingress station in a relay MAC PDU. Instead of carrying individual HMAC/CMAC tuple, if present, for each individual management message, the ingress station may send an MT_Transfer message carrying multiple MAC management messages with only one HMAC/CMAC tuple to authenticate the entire relay MAC PDU. The EC/AC bit in the relay MAC header shall be set to 1 and CID in the relay MAC header shall belong to MT-CID.
Location SA identification
SS SAID (SS Basic CID)
Access RS SAID (Access RS Basic CID), SAID (SS Basic CID)
MR-BS SAID (Access RS Basic CID), SAID (SS Basic CID)
Copyright © 2009 IEEE. All rights reserved. 183
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Insert new subclause 7.1.8 as follows:
7.1.8 Security zone management
The security zone consists of an MR-BS and a number of the RSs. All RSs within a security zone maintain trusted relations, i.e., share common security context for the protection of relay management traffic. A security zone has the following properties:
— RS becomes eligible to join a security zone by the fact of RSs successful authentication to a network.
— RS becomes a member of security zone after a security zone key material is provided to that RS by the MR-BS.
— The MR-BS employs PKMv2 procedures to securely deliver key material to RS.
— Once left, RS shall not be able to operate in a security zone, without reauthentication and key redistribution (i.e., RS shall not have knowledge of keys before it joins and after it leaves the security zone).
7.2 PKM protocol
7.2.2 PKM Version 2
7.2.2.2 Key derivation
Insert new subclause 7.2.2.2.13 as follows:
7.2.2.2.13 Security Zone keys derivation
SZK and SZKEK are randomly generated at the MR-BS. SZKEK and SZK are encrypted by an RS’s KEK and SZKEK respectively, using the same algorithms applied to AK encryption in distributed security mode, and transferred to an access RS during authorization phase, and updated periodically via relay multicast rekeying algorithm.
The security zone keys used for CMAC generation are derived as follows:
CMAC_KEY_SZU|CMAC_KEY_SZD<= Dot16KDF (SZK, “SECURITY_ZONE_KEYS,” 256)
The security zone keys used for HMAC generation are derived as follows:
HMAC_KEY_SZU|HMAC_KEY_SZD<= Dot16KDF (SZK, “SECURITY_ZONE_KEYS,” 320)
The CMAC_KEY_SZ used in SZK multicast update mode is derived as follows:
CMAC_KEY_SZ<= Dot16KDF (SZKEK, “SECURITY_ZONE_UPDATE_KEY,” 128)
The HMAC_KEY_SZ used in SZK multicast update mode is derived as follows:
HMAC_KEY_SZ<= Dot16KDF (SZKEK, “SECURITY_ZONE_UPDATE_KEY,” 160)
184 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
7.2.2.3 Associations
Insert new subclause 7.2.2.3.4 as follows:
7.2.2.3.4 Security zone SA
Security zone SA is a group SA, which contains keying material to secure relay control within a security zone. The primary keying material is SZK and SZKEK, which are provisioned by the MR-BS. Members of a security zone are considered trusted and share common SZK. SZKEK may also be common within security zone.
The contents of Security Zone SA are as follows:
— The SZK, a 160 or 128-bit Security Zone Key, serves as a root for HMAC/CMAC keys derivation.
— The SZKEK, a 128-bit Security Zone Key Encryption Key, serves the same function as SA KEK but for GSA.
The SAID shall be unique within an MR-BS and all RSs.
7.2.2.4 Security context
Insert new subclause 7.2.2.4.5 as follows:
7.2.2.4.5 SZK context
The SZK context includes all the parameters associated with the SZK. SZK is randomly generated by the MR-BS and transferred to the RS under KEK or SZKEK. It is used to sign relay management messages within security zone. The SZK context is described in Table 207a.
Table 207a—SZK context
Parameter Size (bit) Usage
SZK 160 Randomly generated by the MR-BS and transmitted to RS under KEK or SZKEK (in multicast update).
SZK SN 4 The sequence number of SZK. The new SZK SN shall be one greater than the preceding SZK SN.
HMAC_KEY_SZU, CMAC_KEY_SZU
160 or 128 The key that is used for signing DL management messages.
HMAC_PN_SZU, CMAC_PN_SZU, HMAC_PN_RLU, CMAC_PN_RLU
32 Used to avoid UL replay attack on the management connection-when this expires new SZK shall be distributed by the MR-BS.
HMAC_KEY_SZD, CMAC_KEY_SZD
160 or 128 The key that is used for signing DL management messages.
HMAC_PN_SZD, CMAC_PN_SZD, HMAC_PN_RLD, CMAC_PN_RLD
32 Used to avoid DL replay attack on the management connection-when this expires new SZK shall be distributed by the MR-BS.
Copyright © 2009 IEEE. All rights reserved. 185
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Insert new subclause 7.2.2.4.6 as follows:
7.2.2.4.6 SZKEK context
The SZKEK context includes all the parameters associated with the SZKEK. SZKEK is randomly generated at the MR-BS and transferred to the RS encrypted with KEK. It is used to encrypt SZK when multicasting it to all RS within security zone. The SZKEK context is described in Table 207b.
Insert new subclause 7.2.2.7 as follows:
7.2.2.7 AK transfer
In a distributed security model, upon successful authorization of the MS or RS, MR-BS shall send PKMv2 AK Transfer message conveying a set of AK parameters to the relevant Access RS. PKMv2 AK Transfer message may also include multicast/broadcast GSAIDs and associated GTEK-Parameters pairs.
AK parameters shall include AK key material, AK Sequence Number, and AK Lifetime. GKEK parameters shall include GKEK key material, GKEKID, and GKEK Lifetime for the relevant MS. Access RS shall use them during PKMv2 SA-TEK 3-way handshake with MS.
Access RS shall send PKMv2 AK Transfer ACK message to MR-BS in order to acknowledge successful reception of PKMv2 AK Transfer message.
For SAs using a ciphersuite employing DES-CBC, the AK in the AK Transfer message is triple DES (3-DES) encrypted, using a two-key, 3-DES KEK derived from the Access RS AK. For SAs using a ciphersuite employing 128 bits keys, such as AES-CCM mode, the TEK in the AK Transfer message is AES encrypted using a 128-bit key derived for the Access RS AK and a 128-bit block size.
MR-BS may process key pre-distribution to target RS before MS handoff occurs. If target RS does not possess MS’s active AK, MR-BS may deliver an active AK to the RS when receiving an entry/re-entry request from MS.
When RS handover is triggered, the RS may issue re-authentication to MSs that it serves to update the security materials of the MSs.
Table 207b—SZKEK content
Parameter Size (bit) Usage
SZKEK 128 Randomly generated by the MR-BS and transmitted to RS under KEK.
SZKEK Sequence number 4 The sequence number of SZKEK. The new SZKEK sequence number shall be one greater than the preceding SZKEK sequence number.
SZKEK Lifetime — Arrives from MR-BS with SZKEK. When this expires, a new SZKEK shall be distributed.
HMAC_KEY_SZ, CMAC_KEY_SZ
160 or 128 The key that is used for signing group DL SZKEK update messages, calculated by KDF.
HMAC_PN_SZ, CMAC_PN_SZ
32 Used to avoid DL attack on management. When this expires, a new SZKEK shall be distributed.
186 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
7.4 Key usage
Insert new subclause 7.4.3 as follows:
7.4.3 Security zone keys usage
The MR-BS shall generate, maintain and distribute relay security keys to RSs within a security zone. Relay security keys include Security Zone Key (SZK) and Security Zone Key Encryption Key (SZKEK). The RS shall be capable of maintaining two successive sets of relay security keys.
7.4.3.1 SZK usage
SZK is used by the MR-BS and RS to derive security zone message authentication keys, i.e., HMAC/CMAC_KEY_SZU and HMAC/CMAC_KEY_SZD. SZK is updated periodically via relay multicast rekeying algorithm (see 7.8.4).
The MR-BS shall use HMAC/CMAC_KEY_SZD to generate MAC for the relay management messages (except for PKMv2 messages). The MR-BS shall use HMAC/CMAC_KEY_SZU to validate MAC of the relay management messages.
An RS shall use HMAC/CMAC_KEY_SZD to re-generate or validate MAC of the downlink relay management messages sent by the MR-BS or its superordinate RS (except for PKMv2 messages). An RS shall use HMAC/CMAC_KEY_SZU to re-generate or validate MAC of the relay management messages sent by its subordinate RS.
7.4.3.2 SZKEK usage
SZKEK shall be used by the MR-BS to encrypt SZK and authenticate PKMv2 Group-Key-Update-Command message in relay multicast rekeying algorithm SZK update mode. SZKEK is updated periodically via relay multicast rekeying algorithm.
SZKEK shall be used by the MR-BS and RS to derive a key for PKMv2 Group-Key-Update-Command message authentication in SZK update mode, i.e., HMAC/CMAC_KEY_SZ.
7.5 Cryptographic methods
7.5.1 Data Encryption methods
7.5.1.2 Data encryption with AES in CCM mode
Insert new subclause 7.5.1.2.6 as follows:
7.5.1.2.6 Relay MAC PDU encryption with AES in CCM mode
When an access RS operating in distributed security mode is either an ingress or egress station of a tunnel, the payload of relay MAC PDUs in the tunnel may be encrypted based on the RSs’ TEK. Only a single set of PN and integrity check values are included in the encrypted relay MAC PDU. If the EC/AC bit in the relay MAC header is set to 1 and the CID in the relay MAC header belongs to TCID, the payload of the relay MAC PDU is encrypted and the EKS field identifies which RS’s TEK is used. The same AES-CCM encryption rules specified in 7.5.1.2.1 to 7.5.1.2.5 are applied to the tunnel data unit of relay MAC PDU, i.e., including only concatenated MAC PDUs encapsulated in the relay MAC PDU but not extended subheaders and subheaders. Both extended subheaders and subheaders of a relay MAC PDU are not encrypted. A PN is placed after the subheaders of the relay MAC PDU, if present. The nonce construction used for encryption
Copyright © 2009 IEEE. All rights reserved. 187
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
contains the relay MAC header in which all subheader flags are considered as zeros and the length field excludes the length of extended subheaders and subheaders, if present.
7.5.2 Encryption of TEK
Insert new subclause 7.5.2.5 as follows:
7.5.2.5 Encryption of AK with AES key wrap
This method of encrypting the AK shall be used for SAs with the TEK encryption algorithm identifier in the cryptographic suite equal to 0x04. MR-BS encrypts the value fields of the AK in the AK Transfer messages it sends to the access RS operating in distributed security mode. This field is, first, padded with 32-bit nonce and then encrypted using AES Key Wrap Algorithm.
Encryption: C, I = Ek [P||N]
Decryption: P||N, I = Dk [C]
P = 160-bit plaintext AK
N = 32-bit random value
C = 192-bit ciphertext
I = Integrity Check Value
k = the 128-bit KEK
Ek [ ] = AES Key Wrap encryption with key k
Dk [ ] = AES Key Wrap decryption with key k
The AES key wrap encryption algorithm accepts both a ciphertext and integrity check value. The decryption algorithm returns a plaintext key and the integrity check value. The default integrity check value in the NIST AES Key Wrap algorithm shall be used.
Insert new subclause 7.5.2.6 as follows:
7.5.2.6 Security zone keys encryption
SZK and SZKEK shall be encrypted with the cryptographic algorithm defined for TEK or AK encryption (dependent on the particular key length).
7.5.4 Derivation of TEKs, KEKs, and message authentication keys
7.5.4.4 Cipher-based MAC
7.5.4.4.1 Calculation of CMAC value
Insert t new subclause 7.5.4.4.1.1 as follows:
7.5.4.4.1.1 Calculation of CMAC value for Relay
PKM protocol messages shall be authenticated using CMAC/HMAC keys shared between MS/RS and MR-BS only (e.g., CMAC_KEY_U and CMAC_KEY_D). An intermediate RS shall not verify integrity of PKM messages.
188 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
In the case when one CMAC value is shared by the concatenated MAC management messages in a relay MAC PDU as specified in 7.1.7.2, the calculation of the CMAC value of the CMAC tuple in an MT_Transfer message is the same as the method described previously. The CMAC_key_* used in the CMAC value calculation are the CMAC_key_* shared between the access RS and MR-BS. The MAC management message used in the calculation of the CMAC value covers the entire MT_transfer message, i.e., the entire relay MAC PDU.
Insert new subclause 7.5.7 as follows:
7.5.7 Calculation of HMAC/CMAC digests in a security zone
RS follows the same HMAC or CMAC calculation procedure as that for the MS. However, packet number management is different within security zone.
In MR, the MR-BS shall maintain separate Security Zone HMAC/CMAC Packet Number Counter, HMAC/CMAC_PN_SZ*, with every RS within security zone. Any tuple value {HMAC/CMAC_PN_SZ*, HMAC/CMAC_KEY_SZ*, CID} shall not be used more than once. HMAC/CMAC_PN_SZ* shall be used for messages transferred between RS and the MR-BS under the SZK.
RS shall maintain HMAC/CMAC_PN_SZ* with the MR-BS. In addition, RS shall maintain Relay Link HMAC/CMAC Packet Number Counters, HMAC/CMAC_PN_RL*, with its subordinate and superordinate RSs. HMAC/CMAC_PN_RL* shall be used by RS to send one-hop relay management messages (such as DSA and DSC messages) under the SZK.
The RS may also maintain Packet Number Counters of all connections it relays (i.e., a set of CMAC_PN_SZ*). Those PNs may be used by an RS to verify validity of the relayed messages.
The following CMAC_PAD values shall be used for the purpose of replay protection:— CMAC_PAD = 0x7E in case of CMAC_PN_SZ*— CMAC_PAD = 0x7D in case of CMAC_PN_RL*
7.8 PKMv2
7.8.1 PKMv2 SA-TEK 3-way handshake
Insert new subclause 7.8.1.1 as follows:
7.8.1.1 PKMv2 SA-TEK-Response for RS
The PKMv2 SA-TEK-Response for RS shall also include SA_SZK_Update TLV conveying security zone SAID and associated security zone keys. The SZK-Parameters and SZKEK-Parameters attributes contain all of the keying material corresponding to a particular generation of a security zone SAID. This would include the SZK, the SZKEK, the SZK’s key sequence number, the associated SZKEK sequence number and the SZKEK’s remaining lifetime. The SZKEK shall be identically shared within the same security zone. Unlike the PKMv2 Group-Key-Update-Command, the SZK and SZKEK are encrypted with the negotiated TEK encryption algorithm because they are transmitted as a unicast messages.
Insert new subclause 7.8.4 as follows:
7.8.4 Relay multicast rekeying algorithm
The relay multicast rekeying algorithm shall be used to update security zone keys on multiple RSs.
Copyright © 2009 IEEE. All rights reserved. 189
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
The initial SZK and SZKEK distribution is performed by using the PKMv2 SA-TEK 3-way handshake. Once an RS shares the traffic keying material with the MR-BS, the MR-BS updates and distributes the traffic keying material periodically by sending PKMv2 Group-Key-Update-Command messages.
The MR-BS manages the SZK Grace Time. This parameter means time interval (in seconds) starting at the point when any UL or DL PN of a relay group key reached PNlim. Length of a SZK Grace Time shall be shorter than time required for complete exhaustion of relevant packet number space.
The MR-BS manages the SZKEK Grace Time. This parameter means time interval (in seconds) before the estimated expiration of an old distributed SZKEK.
The MR-BS distributes updated group key material by sending PKMv2 Group-Key-Update-Command messages before old distributed key is expired. Two message types are distinguished according to the included Key Push Modes.
The MR-BS transmits the PKMv2 Group-Key-Update-Command message for the SZKEK update mode in order to distribute the new SZKEK. Moreover, the MR-BS transmits the PKMv2 Group-Key-Update-Command message for the SZK update mode in order to distribute the new SZK.
In general, the SZKEK lifetime corresponds to the n (integer being bigger than 1) times of the SZK updates (i.e., the SZKEK shall be updated once while the SZK is updated n times). The MR-BS transmits the PKMv2 Group-Key-Update-Command message for the SZKEK update mode to each RS in a security zone before the current SZKEK expires and the last SZK Grace Time of the corresponding current SZKEK starts. The purpose of the PKMv2 Group-Key-Update-Command message for the SZKEK update mode is to distribute the SZKEK. The PKMv2 Group-Key-Update-Command message for the SZKEK update mode is carried on the Primary Management connection. The HMAC/CMAC Digest attribute’s authentication key is derived from the AK for the SZKEK update mode and SZKEK for the SZK update mode. The MR-BS intermittently transmits the PKMv2 Group-Key-Update-Command message for the SZKEK update mode to each RS in order to reduce the MR-BS’s load in refreshing group key material. The SZKEK is needed to encrypt the new SZK.
190 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Figure 174a—Relay multicast rekeying algorithm
The MR-BS transmits the PKMv2 Group-Key-Update-Command message for the SZK update mode carried on the multicast connection after the each SZK Grace Time starts. The aim of the Key Update Command PKMv2 Group-Key-Update-Command message for the GTEK update mode is to distribute new SZK to all RSs within a security zone.
RSn RS2 RS1 MR-BS
PKMv2 Group-Key-Update-Command(SZKEKy for SZKx+1~SZKx+n)
{Primary management CID:SZKEK update mode}
Keys fromSZKx active
SZKxGrace time
PKMv2 Group-Key-Update-Command(SZKx+2)
{Multicast management CID:SZK update mode}
UL/DLPNlim
reached
SZKEKy-1active
lifetime
SZKEKy-1Grace Time
SZKEKRefreshTimeout
SZKx+n-1Grace time
PKMv2 Group-Key-Update-Command(SZKx+n)
{Multicast management CID:SZK update mode}
UL/DLPNlim
reached
Keys fromSZKx+1 active
SZKEKRefreshTimeout
SZKEKyactive
lifetime
SZKEKyGrace Time
PKMv2 Group-Key-Update-Command(SZKEKy+1 for SZKx+n+1~SZKx+2n)
{Primary management CID:SZKEK update mode}
Keys fromSZKx+n active
SZKEKy+1active
lifetime
Copyright © 2009 IEEE. All rights reserved. 191
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
If UL or DL PN at the RS expires and the RS did not receive new SZK it shall perform reauthentication. If HMAC/CMAC_PN_RL* is about to expire, the RS shall send PKMv2 Key Request message to the MR-BS to initiate multicast rekeying algorithm.
7.8.4.1 MRS rekeying algorithm
In case an RS (i.e., MRS) leaves the security zone, security zone keys shall be updated. In order to avoid SZEK update mode in relay multicast rekeying algorithm, the MR-BS may not include SZKEK parameters during the PKMv2 SA-TEK 3-way handshake with MRS. If SZKEK parameters are omitted, the MR-BS shall always send the PKMv2 Group-Key-Update-Command in SZK update mode on primary management CID of MRS.
8. Physical layer (PHY)
8.4 WirelessMAN-OFDMA PHY
8.4.4 Frame structure
8.4.4.6 UL transmission allocations
Change subclause 8.4.4.6 as indicated:
For TDD mode, the BS and RS shall not allocate more than three ranging allocation IEs (UIUC 12) per frame in the access zone.
Insert new subclause 8.4.4.8 as follows:
8.4.4.8 TDD frame structure of MR-BS and RS
This subclause describes the minimal requirements for a frame structure for an MR-BS and its subordinate RS.
In MR systems where relay links and access links are time separated, RS allowances shall be made for an RSRTG and for an RSTTG. The parameters of RSRTG and RSTTG for an RS are capabilities provided by the RS to MR-BS during RS network entry and shall meet the requirements set in 12.4.3.1.5.
All DL transmissions shall be symbol aligned with the corresponding symbols at the MR-BS. All UL transmissions shall be time advanced such that they are symbol aligned at the receiving station with the corresponding symbols at the MR-BS.
When an RS switches transceiver states from receive to transmit, the R-RTI is the number of symbols between the last symbol that may be transmitted to the RS and the first symbol to be transmitted by the RS in order to make allowances for RSRTG and RTD between the RS and its superordinate station, where symbol times are referenced at the MR-BS. The R-RTI shall be calculated by following equation:
where RTD is the round trip delay between the RS and its superordinate station and OFDMASymbolUnit is the integer number of OFDMA symbols, or .
R-RTI OFDMASymbolUnit RSRTG RTD2
------------+⎝ ⎠⎛ ⎞=
OFDMASymbolUnit x( ) x OFDMA symbol time( )⁄=
192 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
When an RS switches transceiver states from transmit to receive, the R-TTI is the number of symbols between the last symbol that may be transmitted by the RS and the first symbol to be received by the RS in order to make allowances for RSTTG and RTD between the RS and its superordinate station, where symbol times are referenced at the MR-BS. The R-TTI shall be calculated by following equation:
where RTD is the round trip delay between the RS and its superordinate station and OFDMASymbolUnit is the integer number of OFDMA symbols, or
8.4.4.8.1 Frame structure for transparent mode
8.4.4.8.1.1 MR-BS frame structure
An example of the MR-BS frame structure is shown in Figure 234a.
Each frame in the downlink transmission begins with a preamble followed by an FCH, DL-MAP, and possibly UL-MAP. R-MAP is located following MAP or defined as an extension of MAP. The frame structure consists of DL subframe period and optional UL subframe period. In each frame, the TTG shall be inserted between the DL subframe and the UL subframe. The RTG shall be inserted at the end of each frame.
The ranging subchannel in the access zone is used by RSs performing initial ranging and MSs for all ranging operations. The ranging subchannel in the relay zone is used by RSs for ranging operations other than initial ranging.
The DL subframe shall include one access zone and may include one transparent zone for RS to MS transmissions. The MR-BS may also transmit in the transparent zone as well. The transparent zone shall be indicated by an STC_DL_ZONE_IE(), as defined in Table 330. The UL subframe may include a UL access zone and a UL relay zone. The UL relay zone shall be indicated by a PAPR Reduction/Safety Zone/Sounding Zone Allocation IE() with Relay Zone indicator set to 1 (see Table 377), or a UL_Zone_IE() (see 8.4.5.4.7). When the UL relay zone is allocated with a part of subchannels as shown in Figure 234b, the permutation of the zone shall be the same as the UL access zone that is allocated with the remaining subchannels. The OFDMA data mapping of the UL relay zone shall follow 8.4.3.4.
R-TTI 0 if RTD 2⁄ RSTTG≥OFDMASymbolUnit RSTTG RTD 2⁄–( ) if RTD 2 RSTTG<⁄⎩
⎨⎧
=
OFDMASymbolUnit x( ) x OFDMA symbol time( )⁄=
Copyright © 2009 IEEE. All rights reserved. 193
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Figure 234a—Example of configuration for a transparent relay frame structure4
4The impact of propagation delay is not reflected in the figure.
Pre
ambl
e
FCH
DL-
MA
P
DL burst #2
DL burst #3
DL burst #5
DL burst #4
DL
burs
t #6
ss+1s+2s+3
k k+1
DL burst #10 Transmitter mode forcommunicating with MR-BS
s+L
ss+1s+2s+3
s+L
DL
burs
t #1
(car
ryin
g th
e U
L-M
AP)
MR
-BS
Fram
eSu
bcha
nnel
Log
ical
num
ber
RS
Fram
eSu
bcha
nnel
Log
ical
num
ber
DL Access Zone
OFDMA symbol number
DL Subframe
TTGOptional Transparent Zone
Frame j
Pre
ambl
e
FCH
DL-
MA
P
UL Access Zone
Rec
eive
r mod
e
Frame j+1UL Subframe
DL Access ZoneDL Subframe
TTGOptional Transparent Zone
Frame j
RTGUL Relay ZoneUL Access Zone
Frame j+1UL Subframe
R-RTGR-RTG
Receiver mode forcommunicating with MR-BS
Silent/Cooperative Diversityfor RS communicating with
RS/MS
MR-BS communicating withMSs
DL burst #8
DL burst #7
DL burst #9
Ranging subchannel
UL burst #3
MSs communicating with RS
RTG
Ranging subchannel
R-UL burst #2
R-UL burst #1
R-UL burst #4
R-UL burst #5
R-UL burst #3
UL Relay Zone
k+3 k+5 k+7 k+9 k+11 k+13 k+15 k+17 k+28k+25k+22k+19 k+34 k+43k+40
MSs communicating with MR-BS
Ranging subchannel
UL burst #4
UL burst #5
k k+1 k+3 k+5 k+7 k+11 k+13 k+15 k+17 k+28k+25k+22k+19
k+37k+31
k+34 k+43k+40k+37
Safe
ty z
one
UL burst #1
UL burst #2
194 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Figure 234b—Example of configuration for a transparent relay frame structure: MR-BS and RS have partitioned UL subframe in the frequency domain
8.4.4.8.1.2 Relay frame structure
An example of an RS frame structure is shown in Figure 234a.
A transparent RS does not transmit the preamble, FCH and MAP at the beginning of the frame. Instead it receives the preamble, FCH and MAP and optional R-MAP transmission from MR-BS. The detailed allocation for an RS in the access zone is indicated by a MAP message and in the relay zone by an R-MAP message. In each frame, a TTG shall be inserted between the DL subframe and the UL subframe. An RTG shall be inserted at the end of each frame.
The DL subframe shall include one access zone for MR-BS to RS and MS transmissions and may include one transparent zone for RS to MSs transmissions. The UL subframe may include one access zone and may include one relay zone for RS to superordinate station transmissions. STC DL Zone IE() message may indicate additional power adjustment to be applied to transparent zone in order to reduce the absolute received signal level difference experienced by the MSs served in that zone from MR-BS and from RS paths. This power adjustment is done relative to the EIRP value set for the RS and shall not exceed the power levels specified in subclause 8.4.9.6. The ranging subchannel in the access zone is used by MSs for all ranging operations. For monitoring purpose, the relay amble, when present, shall be located at the end of the DL subframe.
8.4.4.8.1.3 Direct relay zone (optional)
A direct relay zone may be optionally assigned by the MR-BS to a transparent RS. Only end-to-end HARQ mode shall be used in the direct relay zone and an RS with a direct relay zone shall not be used for more than
Use
d su
bcha
nnel
s b
y R
Ss
Use
d su
bcha
nnel
s b
y R
Ss
DL SubframeOptional Transparent ZoneDL Access Zone
Pre
ambl
e
FCH
DL-
MA
P
DL burst #2
DL burst #3
DL burst #5
DL burst #4
ss+1s+2s+3
k k+1
Transmitter mode forcommunicating with MR-BS
s+L
DL
burs
t #1
(car
ryin
g th
e U
L-M
AP
)
MR
-BS
Fra
me
Sub
chan
nel L
ogic
al n
umbe
r
OFDMA symbol number
TTG
Frame j Frame j+1
R-RTI
Receiver mode forcommunicating with MR-BS
DL
burs
t #6
DL burst #9
DL burst #7
DL burst #10
DL burst #8
Ranging subchannel
UL Access Zone
k+3 k+5 k+7 k+9 k+11 k+13 k+15 k+17
DL SubframeOptional Transparent ZoneDL Access Zone
ss+1s+2s+3
k k+1
s+L
RS
Fra
me
Sub
chan
nel L
ogic
al n
umbe
r
k+3 k+5 k+7 k+9 k+11 k+13 k+15 k+17 k+19
k+19 k+25 k+28 k+31
UL burst #1
UL burst #2UL burst #3
Ranging subchannel
UL Relay Zone
k+34 k+37 k+40 k+43
R-UL burst #1
R-UL burst #2RTG
UL Subframe
Pre
ambl
e
FCH
DL-
MA
P
k k+1
Frame j Frame j+1
UL Access Zone
k+22 k+25 k+28 k+31
UL burst #5
UL burst #6
UL Relay Zone
k+34 k+37 k+40 k+43
RTGUL Subframe
Pre
ambl
e
FCH
DL-
MA
P
k k+1
R-RTI
Silent for RS communicating with RS/MS
orCooperative Diversity for
MR-BS communicating with MSs
MSs communicating with RS
Saf
ety
zone
MSs communicating with MR-BS
k+22
TTG
UL burst #4
Ranging subchannel
Copyright © 2009 IEEE. All rights reserved. 195
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
two hops. In the direct relay zone, an RS may relay data within a single frame, in which an intermediate RS demodulates and de-interleaves, but not decodes, received bursts and forwards by re-interleaving and re-modulating the bursts. The direct receiving and direct transmitting zones are configured using the RS_Config-CMD message. The RS shall request the MR-BS to allocate a direct relay zone using the SBC-REQ message by including the TLV for the Direct Relay Zone (11.8.3.5.25). The MR-BS shall acknowledge the request by including the TLV for the Direct Relay Zone (11.8.3.5.25) in the SBC-RSP message. The size of FEC blocks of the bursts along the relay path shall be the same as the size of FEC blocks of the bursts in the access link.
8.4.4.8.2 Frame structure for non-transparent TTR mode
Two approaches for supporting relaying are specified for TTR RSs. A TTR RS shall be capable of being configured to support either one of the operations, but shall not be required to support both operations simultaneously. The DL subframe shall include at least one access zone and the UL subframe may include one or more UL access zones and one or more relay zones.
The first approach allows one or more RS or MR-BS frames to be grouped into a multi-frame with a repeating pattern of allocated relay zones. The MR-BS and RSs are assigned to transmit, receive or be idle in each of the relay zones within the multi-frame. As an example, a two-frame multi-frame can be used to assign odd hop RSs to transmit in the DL relay zone of odd number frames and the MR-BS and even hop RSs to transmit in the DL relay zone of even number frames.
The second approach enables a single-frame frame structure consisting of more than one Relay zone. The MR-BS and RSs are assigned to transmit, receive, or be idle in each relay zone within the frame. As an example, the odd hop RSs can be assigned to transmit in one DL relay zone, while the MR-BS and even hop RSs can be assigned to transmit in another DL relay zone.
8.4.4.8.2.1 MR-BS frame structure
An example of the MR-BS frame structure is shown in Figure 234c.
Each MR-BS frame begins with a preamble followed by an FCH and the DL MAP and possibly UL MAP. The DL subframe shall include at least one DL access zone and may include one or more DL relay zones. The UL subframe may include one or more UL access zones and it may include one or more UL relay zones. A relay zone may be utilized by an MR-BS for transmission, reception or idle (i.e., neither transmission or reception) but the MR-BS shall not be required to support multiple modes of operation within the same zone. In each frame, the TTG shall be inserted between the DL subframe and the UL subframe. The RTG shall be inserted at the end of each frame. In the DL access zone, the subchannel allocation, the FCH transmission, and the FCH shall be defined as in 8.4.4.1 and 8.4.4.3.
The first transmitted relay zone in the downlink shall include an R-FCH and an R-MAP.
196 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Figure 234c—Example of minimum configuration for a non-transparent TTR relay frame structure5
5The impact of propagation delay is not reflected in the figure.
Prea
mbl
e
FCH
DL-
MA
P
DL burst #2
DL burst #3
DL burst #5
DL burst #4
ss+1s+2s+3
k k+1
s+L
DL
burs
t #1
(car
ryin
g th
e U
L-M
AP)
MR
-BS
Fram
eS
ubch
anne
l Log
ical
num
ber
DL Access Zone
OFDMA symbol number
DL Subframe
TTGDL Relay Zone
Frame j
Prea
mbl
e
FCH
DL-
MA
P
Frame j+1UL Subframe
RTG
Ranging subchannel
R-UL burst #2
R-UL burst #3
k+3 k+5 k+7 k+9 k+11 k+13 k+15 k+17 k+27k+23k+21k+19 k+33 k+42k+39k+36k+30
DL burst #6
R-F
CH
R-M
AP
R-DL burst #2
R-DL burst #3
R-DL burst #5
R-DL burst #4R-D
L bu
rst #
1
R-DL burst #6
Ranging subchannel
ss+1s+2s+3
s+L
RS
Fram
eS
ubch
anne
l Log
ical
num
ber
DL Access ZoneDL Subframe
TTGDL Relay Zone
Frame j
RTGUL Relay ZoneUL Access Zone
Frame j+1UL Subframe
R-RTIR-TTI
Receiver mode for communicating with MR-BS
Pre
ambl
e
FCH
DL-
MA
P
DL burst #2
DL burst #3
DL
burs
t #5
DL burst #4
k k+1
DL
burs
t #1
(car
ryin
g th
e U
L-M
AP
)
k+3 k+5 k+7 k+11 k+13k+9 k+17 k+19
Transmitter mode for
communicating with MR-BS
k+33 k+42k+39
Pre
ambl
e
FCH
DL-
MA
P
k+27k+23k+21
Ranging subchannel
UL burst #2
UL burst #1
UL burst #4
UL burst #5
UL burst #3
Use
d su
bcha
nnel
s by
RSs
Use
d su
bcha
nnel
s by
RS
s
UL burst #1
UL burst #2
UL burst #3
UL burst #4
UL burst #5
k+30
k+25
k+25
R-UL burst #1
UL Access Zone UL Relay Zone
Copyright © 2009 IEEE. All rights reserved. 197
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Figure 234d—Example of configuration for non-transparent TTR relay frame structure; MR-BS and RS have partitioned the UL subframe in the frequency domain
8.4.4.8.2.2 Relay frame structure
A TTR relay station can either perform relaying on the same carrier frequency or on a separate carrier frequency, depending on its negotiated and configured capability, by time dividing communication with the superordinate station and subordinate station(s).
An example of a TTR RS frame structure is shown in Figure 234c for the case of relaying on the same carrier. For the case of relaying on a separate carrier, the frame structure is the same as illustrated in Figure 234b, except that the communication with the subordinate station(s) is performed on a different carrier frequency to that used by the superordinate station.
Each RS frame begins with a frame start preamble followed by an FCH and a DL-MAP and possibly a UL-MAP. The RS transmits its frame start preamble time aligned with its superordinate station’s frame start preamble and the UL subframe of the RS is aligned to the UL subframe of the MR-BS.
The DL subframe shall include at least one DL access zone and may include one or more relay zones. The UL subframe may include one or more UL access zones and one or more relay zones.
A relay zone may be utilized for either transmission, or reception, or idle but the RS shall not be required to support both transceiver modes within the same zone.
In each frame, the TTG shall be inserted between the DL subframe and the UL subframe. The RTG shall be inserted at the end of each frame.
Pre
ambl
e
FCH
DL-
MA
P
DL burst #2
DL burst #3
DL burst #5
DL burst #4
ss+1s+2s+3
k k+1
s+L
DL
burs
t #1
(car
ryin
g th
e U
L-M
AP
)
MR
-BS
Fra
me
Sub
chan
nel L
ogic
al n
umbe
r
DL Access Zone
OFDMA symbol number
DL Subframe
TTGDL Relay Zone
Frame j
Pre
ambl
e
FCH
DL-
MA
P
UL Access Zone
Frame j+1UL Subframe
RTG
Ranging subchannel
R-UL burst #1
R-UL burst #2
R-UL burst #3
UL Relay Zone
k+3 k+5 k+7 k+9 k+11 k+13 k+15 k+17 k+27k+23k+21k+19 k+33 k+42k+39k+36k+30
DL burst #6
R-F
CH
R-M
AP
R-DL burst #2
R-DL burst #3
R-DL burst #5
R-DL burst #4R-D
L bu
rst #
1
R-DL burst #6
Ranging subchannel
ss+1s+2s+3
s+L
RS
Fra
me
Sub
chan
nel L
ogic
al n
umbe
r
DL Access ZoneDL Subframe
TTGDL Relay Zone
Frame j
RTGUL Relay ZoneUL Access Zone
Frame j+1UL Subframe
R-RTIR-TTI
Receiver mode for communicating with MR-BS
Pre
ambl
e
FCH
DL-
MA
P
DL burst #2
DL burst #3
DL
burs
t #5
DL burst #4
k k+1
DL
burs
t #1
(car
ryin
g th
e U
L-M
AP
)
k+3 k+5 k+7 k+11 k+13k+9 k+17 k+19
Transmitter mode for
communicating with MR-BS
k+33 k+42k+39
Pre
ambl
e
FCH
DL-
MA
P
k+27k+23k+21
Ranging subchannel
UL burst #2
UL burst #1
UL burst #4
UL burst #5
UL burst #3
Safety Zone signaled by MR-
BS in the R-MAP in order for the RS to avoid transmission in the UL Access Zone of MR-BS where the SSs
transmit.
Use
d su
bcha
nnel
s by
RS
sU
sed
subc
hann
els
by R
Ss
UL burst #1
UL burst #2
UL burst #3
UL burst #4
UL burst #5
k+30
k+25
k+25
198 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
The contents of the FCH, DL-MAP and UL-MAP in the access zone transmitted by the RS may or may not be the same as those transmitted in the access zone by the MR-BS.
In the DL access zone, the subchannel allocation, the FCH transmission, and the FCH shall be as defined in 8.4.4.1 and 8.4.4.3.
An R-FCH and R-MAP shall be transmitted in the first DL relay zone that is in transmission mode.
The frame structure of an RS shall be configured by its MR-BS through the RS_Config-CMD message.
For synchronization purpose, the relay amble, when present, shall be located either at the end of the last DL relay zone in which the MR-BS/RS is in transmit mode or at the end of the DL subframe. For monitoring purposes, the relay amble, when present, shall be located at the end of the DL subframe.
Another example of frame configuration is shown in Figure 234d. The MR-BS and RS have partitioned the logical subchannels in the UL subframe in the frequency domain, in order to preserve the coverage area of MR-BS for SSs. In the distributed scheduling, this may be achieved using the RS_Config-CMD message with Zone_Configuration_IE where the same permutation base and permutation zone type for UL is used both for MR-BS and the uplink relay zone of the RS. In order for the SSs that are served by the MR-BS to avoid transmission in the UL relay zone of the RS, MR-BS may signal to these SSs this zone in its UL MAP as a safety zone. Also, the MR-BS signals in the R-MAP a safety zone in order for the RS to avoid transmission in the UL access zone of MR-BS where SSs transmit.
8.4.4.8.3 Frame structure for STR mode
A STR relay station supports simultaneous communication with subordinate station(s) and the superordinate station. Two approaches for supporting relaying are specified for STR RSs.
The first approach uses the BS frame structure defined in 8.4.4.1 for the MR-BS frame and the RS frame. The MR-BS frame structure is the same as the frame structure defined in 8.4.4.1. The RS frame structure is the same as the frame structure defined in 8.4.4.1 on the second carrier of the RS. The RS shall receive data in the DL subframe and transmit data in the UL subframe on the first carrier as a SS.
The second approach uses the frame structure defined in 8.4.4.8.2 for the MR-BS frame and the RS frame, which allows coexistence with TTR RS. An example of an STR frame structure that allows coexistence with a TTR RS is shown in Figure 234e. This frame structure can support more than two hop relaying by including a transmit DL and a receive UL relay zone on the second carrier, as shown in Figure 234e. If the RS is not supporting subordinate RSs then the DL and UL relay zones shown in Figure 234e may not be present.
The arrangement of signaling shall be the same as that described in 8.4.4.1 and 8.4.4.8.2 with the exception that it is possible for the RS frame to be configured such that the RS is both transmitting and receiving at the same time. However, the RS shall not transmit and receive on the same carrier when the interference induced by the transmitter operating in STR mode causes a link performance degradation related to the STR receiver.
Copyright © 2009 IEEE. All rights reserved. 199
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Figure 234e—Example of minimum configuration for a STR relay frame structure coexisting with TTR RS in TDD mode
Insert new subclause 8.4.4.9 as follows:
8.4.4.9 R-FCH channel
If a DL relay zone of a non-transparent RS contains an R-FCH, the R-FCH shall be transmitted using the same approach as that described for the FCH in 8.4.4.1. The R-FCH contains the R-Zone_Prefix as described in 8.4.4.10.
Pre
ambl
e
FCH
DL-
MA
P
DL burst #2
DL burst #3
DL burst #5
DL burst #4
ss+1s+2s+3
k k+1
s+L
ss+1s+2s+3
s+L
DL
burs
t #1
(car
ryin
g th
e U
L-M
AP
)
MR
-BS
Fram
e (C
arrie
r f1)
Sub
chan
nel L
ogic
al n
umbe
rC
arrie
r f2
Sub
chan
nel L
ogic
al n
umbe
r
DL Access Zone
OFDMA symbol number
DL Subframe
TTGDL Relay Zone
Frame j
Pre
ambl
e
FCH
DL-
MA
P
UL Access Zone
Tran
smit
mod
e
Frame j+1UL Subframe
DL Subframe
TTG
Frame j
RTG
Frame j+1UL Subframe
RTG
Ranging subchannel
R-UL burst #2
R-UL burst #1
R-UL burst #4
R-UL burst #5
R-UL burst #3
UL Relay Zone
k+3 k+5 k+7 k+9 k+11 k+13 k+15 k+17 k+27k+24k+21k+19 k+33 k+42k+39k+36k+30
DL burst #6
R-F
CH
R-M
AP
R-DL burst #2
R-DL burst #3
R-DL burst #5
R-DL burst #4R-D
L bu
rst #
1
R-DL burst #6
Ranging subchannel
UL burst #2
UL burst #1
UL burst #4
UL burst #5
UL burst #3
k k+1 k+3 k+5 k+7 k+9 k+11 k+13 k+15 k+17 k+19 k+27k+24k+21 k+33 k+42k+39k+36
ss+1s+2s+3
s+L
Car
rier f
1S
ubch
anne
l Log
ical
num
ber
Rec
eive
mod
e
Receive mode for communicating with MR-BS
k k+1 k+3 k+5 k+7 k+9 k+11 k+13 k+15 k+17 k+19
Transmit mode for communicating with MR-BS
k+27k+24k+21 k+33 k+42k+39k+36
RS
Fram
e (C
arrie
r f1)
k+30
Pre
ambl
e
FCH
DL-
MA
P
DL burst #2
DL burst #3
DL burst #5
DL burst #4DL
burs
t #1
(car
ryin
g th
e U
L-M
AP)
DL Access Zone DL Relay Zone
k+3 k+11
DL burst #6
R-F
CH
R-M
AP
R-DL burst #2
R-DL burst #3
R-DL burst #5
R-DL burst #4R-D
L bu
rst #
1
R-DL burst #6
Ranging subchannel
R-UL burst #2
R-UL burst #1
R-UL burst #4
R-UL burst #5
R-UL burst #3
Ranging subchannel
UL burst #2
UL burst #1
UL burst #4
UL burst #5
UL burst #3
k+30
UL Access Zone UL Relay Zone
200 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Insert new subclause 8.4.4.10 as follows:
8.4.4.10 R-Zone prefix
The R-Zone_Prefix is a data structure transmitted on R-FCH of a DL relay zone. The R-Zone_Prefix includes information regarding the location of the first transmit relay zone in the next frame that contains a transmit relay zone and the information required for decoding R-MAP. In the case of two hop systems, the R-Zone configuration can be done using R-FCH/R-MAP when the relay frame structure has no idle zones and one relay zone. The method for determining whether to use the RS_Config-CMD message or R-FCH for frame configuration is described below.
If RS_config-CMD message contains the Frame_Config_Flag set to 1, the frame configuration TLVs in the RS_Config-CMD message shall be followed to locate the relay zones. Otherwise, for the two hop case only when the Frame_Config_Flag is set to 0, the R-FCH/R-MAP shall be used to determine the frame configuration parameters. In this case, an RS receiving an updated R-FCH at frame-k shall apply the changes at frame k + max(2, Relay UL Allocation Start Time+1). The Relay UL Allocation Start Time is provided from RCD. If an R-FCH is lost, the RS shall attempt to resynchronize again using the location specified by the previous R-FCH. If the synchronization fails, it may try to obtain R-FCH using the last received RS_Config-CMD information. If this fails, the RS shall stop transmitting the frame start preamble, listen to access zone and obtain relay zone information from Gap IE or STC zone switch IE, and synchronize to the R-FCH/R-MAP. Table 318a defines the format of the R-Zone_Prefix for FFT sizes other than 128 and Table 318b defines the format for a FFT size of 128.
Table 318a—R-Zone_Prefix format
Syntax Size(bits) Notes
R-Zone_Prefix_format() { — —
R-Zone_Location 8 The field indicates the location of the first transmit relay zone in the next frame that contains a relay zone.For a two hop case, when the Frame Configuration Mode is set to 0, if the RS receives an updated value of this parameter at frame k, the frame con-figuration changes shall be applied at frame k+max(2, Relay UL Allocation Start Time+1).
Used_subchannel_bitmap 6 Bit 0: Subchannel group 0 Bit 1: Subchannel group 1 Bit 2: Subchannel group 2 Bit 3: Subchannel group 3 Bit 4: Subchannel group 4 Bit 5: Subchannel group 5
R-MAP_Length 5 Length in unit of slot
FEC Code type and modulation type
4 0b0000 = QPSK (CTC) 1/2 0b0001 = QPSK (CTC) 3/4 0b0010 = 16-QAM (CTC) 1/2 0b0011 = 16-QAM (CTC) 3/4 0b0100 = 64-QAM (CTC) 1/2 0b0101 = 64-QAM (CTC) 2/3 0b0110 = 64-QAM (CTC) 3/4 0b0111 = 64-QAM (CTC) 5/6 0b1000-0b1111 = Reserved
Copyright © 2009 IEEE. All rights reserved. 201
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
R-Zone_LocationAn indicator regarding the location of the first transmit relay zone in the next frame that contains a transmit relay zone. The first OFDM symbol in each frame is indexed as 0. The R-Zone location indicates the OFDM symbol index relative to the first OFDM symbol in next frame that contains a transmit relay zone. The unit is 1 OFDM symbol.
R-MAP_LengthThe length in slots of the R-MAP message that immediately follows the R-Zone_Prefix.
FEC Code type and modulation typeAn indicator indicating the modulation and code rate used for R-MAP message.
Repetition_Coding_Indication 1 0: No repetition coding on R-MAP 1: Repetition coding of 2 used on R-MAP
}
Table 318b—R-Zone_Prefix format for FFT size 128
Syntax Size(bits) Notes
R-Zone_Prefix_format() { — —
R-Zone_Location 3 The field (unsigned integer) indicates the OFDM symbol index referenced to the beginning of next frame that con-tains a transmit relay zone in unit of m OFDM symbols where:
m=floor (L/11);
L= Number of OFDM Symbols in one frame; and
OFDM Symbol Index = 3 + R-Zone_Location × m
For a two hop case, when the Frame Configuration Mode is set to 0, if the RS receives an updated value of this parameter at frame k, the frame configuration changes shall be applied at frame k+max(2, Relay UL Allocation Start Time+1).
Used_subchannel_bitmap 1 0: Subchannel 0 is used for segment 0, Subchannel 1 is used for segment 1, Subchannel 2 is used for segment 2,1: Use all subchannels
R-MAP_Length 4 Length in unit of slot
Table 318a—R-Zone_Prefix format (continued)
Syntax Size(bits) Notes
202 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
R-Zone_LocationAn indicator regarding the location of the first transmit relay zone in the next frame that contains a transmit relay zone. The first OFDM symbol in each frame is indexed as 0. The R-Zone location indicates the OFDM symbol index relative to the first OFDM symbol in next frame that contains a transmit relay zone. The unit is 1 OFDM symbol.
R-MAP_LengthThe length in slots of the R-MAP message that immediately follows the R-Zone_Prefix.
FEC Code type and modulation typeAn indicator indicating the modulation and code rate used for R-MAP message.
Insert new subclause 8.4.4.11 as follows:
8.4.4.11 FDD frame structure of MR-BS and RS
For the STR RS operating in the FDD mode, DL/UL carrier frequencies in the link between the RS and its subordinate station shall not be the same as those in the link between the RS and its superordinate station when the interference induced by the transmitter operating in STR mode causes a link adaptation degradation of the link performance related to the STR receiver.
For the TTR and transparent RS operating in the FDD mode, DL/UL carrier frequencies and the channel bandwidth in the link between the RS and its subordinate station shall be the same as those in the link between the RS and its superordinate station. The DL shall not be allocated in access link when there is DL allocation in relay link. The UL shall not be allocated in access link when there is UL allocation in relay link. R-RTI and R-TTI shall apply when RS changes its status between receive from its superordinate station and transmit to its subordinate stations on DL carrier or between transmit to superordinate station and receive from its subordinate stations on UL carrier.
8.4.4.11.1 Frame Structure for transparent mode
When the MR-BS and transparent RS communicate each other in subframe 1 and subframe 2 by using the frame structures defined in 8.4.4.8.1, it may operate in either H-FDD or full duplex FDD. When operating in full duplex FDD, DL subframe and UL subframe of relay link may be overlapped. The access link between the RS and its subordinate SSs shall operate in H-FDD mode according to the frame structure described in
FEC Code type and modulation type
3 0b000 = QPSK (CTC) 1/2 0b001 = QPSK (CTC) 3/4 0b010 = 16-QAM (CTC) 1/2 0b011 = 16-QAM (CTC) 3/4 0b100 = 64-QAM (CTC) 1/2 0b101 = 64-QAM (CTC) 2/3 0b110 = 64-QAM (CTC) 3/4 0b111 = 64-QAM (CTC) 5/6
Repetition_Coding_Indication 1 0: No repetition coding on R-MAP 1: Repetition coding of 2 used on R-MAP
} — —
Table 318b—R-Zone_Prefix format for FFT size 128
Syntax Size(bits) Notes
Copyright © 2009 IEEE. All rights reserved. 203
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
8.4.4.2 with the exception that the DL subframe in the access link shall only contain transparent zone in DL or access zone in UL (i.e., DL subframe shall exclude the preamble and MAP transmission).
8.4.4.11.2 Frame Structure for non-transparent TTR
The TTR RS may communicate with superordinate station in either H-FDD or full duplex FDD mode and it shall communicate with subordinate SSs operating in H-FDD mode only.
If the MR-BS and TTR RS frame structures is the same as the BS frame structure defined in 8.4.4.2, the relay link between the TTR RS and its superordinate station shall operate in Group-2 H-FDD only, where the TTR RS shall listen to DL Subframe 2 and transmit in uplink subframe UL2. The access link between the RS and its subordinate SSs shall operate in Group-1 H-FDD mode only. The common SYNC symbol defined in 8.4.6.1.1.2 or R-amble defined in 8.4.6.1.1.3 may appear in the Group-2 DL Subframe of the superordinate station for the RS synchronization.
When the MR-BS and TTR RS communicate each other in subframe 1 and subframe 2 by using the frame structures defined in 8.4.4.8.2 (with the exception of preamble in subframe 2), it may operate in either H-FDD or full duplex FDD. When operating in full duplex FDD, DL subframe and UL subframe of relay link may be overlapped. The access link between the RS and its subordinate SSs shall operate in H-FDD using the frame structure defined in 8.4.4.2.
8.4.4.11.3 Frame Structure for STR
The MR-BS frame structures and the STR RS frame structures are the same as the BS frame structure defined in 8.4.4.2. The relay link between the RS and its superordinate station shall operate in either H-FDD or FDD on the first DL and UL carriers of the RS. When operating in H-FDD mode, the RS may switch between groups by the same process as the SS. The access link between the RS and its subordinate SSs shall operate in either H-FDD or FDD on the second DL and UL carriers of the RS.
8.4.5 Map message fields and IEs
8.4.5.3 DL-MAP IE format
Insert the following at the end of 8.4.5.3:
The MR-BS or RS may transmit DIUC=13 in the DL-MAP in the access zone for MS not to process the signal transmitted in the downlink relay zone.
204 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Change Table 321 as indicated:
Table 321—OFDMA DL-MAP_IE format
Syntax Size(bits) Notes
DL-MAP_IE() { — —
DIUC 4 —
if (DIUC == 14 { — —
Extended-2 DIUC dependent IE — —
} else if (DIUC == 15) { — —
Extended DIUC dependent IE variable See 8.4.5.3.2 and 8.4.5.3.2.1
} else { — —
if (INC_CID == 1) { — The DL-MAP starts with INC_CID =0. INC_CID is toggled between 0 and 1 by the CID-SWITCH_IE() (8.4.5.3.7)
N_CID 8 Number of CIDs assigned for this IE
for (n=0; n< N_CID; n++) { — —
If ( included in SUB-DL-UL-MAP) { — —
RCID_IE() — For SUB-DL-UL-MAP, reduced CID format is used
} else { — —
CID 16 —
} — —
} — —
} — —
OFDMA Symbol offset 8 —
if (Permutation = 0b11 and (AMC type is 2x3 or 1x6)) {
— —
Subchannel offset 8 —
If(DIUC == 13) { — —
Relay zone indicator 1 0b0: Normal Gap/PAPR/safety zone 0b1: Relay zone indicator
Reserved 2 Shall be zero
} else { — —
Boosting 3 000: normal (not boosted); 001: +6dB; 010: –6dB; 011: +9dB; 100: +3dB; 101: –3dB; 110: –9dB; 111: –12dB;
} — —
No. OFDMA triple symbol 5 Number of OFDMA symbols is given in multiples of 3 symbols
Copyright © 2009 IEEE. All rights reserved. 205
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
8.4.5.3.2.3 DL-MAP Extended-3 IE encoding format
Change Table 328 as indicated:
No. Subchannels 6 —
} else { — —
Subchannel offset 6 —
If(DIUC == 13) { — —
Relay zone indicator 1 0b0: Normal Gap/PAPR/safety zone 0b1: Relay zone indicator
Reserved 2 Shall be zero
} else { — —
Boosting 3 000: normal (not boosted); 001: +6dB; 010: –6dB; 011: +9dB; 100: +3dB; 101: –3dB; 110: –9dB; 111: –12dB;
} — —
No. OFDMA Symbols 7 —
No. Subchannels 6 —
} — —
Repetition Coding Indication 2 0b00 – No repetition coding 0b01 – Repetition coding of 2 used 0b10 – Repetition coding of 4 used 0b11 – Repetition coding of 6 used
} — —
} — —
Table 328—Extended-3 DIUC code assignment for Extended-2 DIUC = 15
Extended-3 DIUC(hexadecimal) Usage
0x0 Power Boosting IE
0x1 MR DL-MAP Monitor IE
0x2 DL_Burst_Transmit_IE
0x13-0xF Reserved
Table 321—OFDMA DL-MAP_IE format (continued)
Syntax Size(bits) Notes
206 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
8.4.5.3.4 STC DL Zone IE format
Insert the following after first paragraph in the 8.4.5.3.4:
The MR-BS or RS may transmit STC_DL_Zone_IE with dedicated pilot bit set to 1 in the access zone for MS not to process the signal transmitted in the downlink relay zone.
Modify Table 330 as indicated:
8.4.5.3.10 HARQ, and Sub-MAP, and R-MAP Pointer IE
Change 8.4.5.3.10 as indicated as follows:
This IE shall only be used by a BS supporting HARQ or SUB-DL-MAP for MSs supporting HARQ, or transmitting R-MAP to RS in DL access zone. There shall be at most four HARQ MAP Pointer IEs in the DL-MAP. There shall be at most 3 SUB-DL-UL-MAP pointer IEs per frame, as specified in 6.3.2.3.55. Table 335 shows the format for the HARQ, and Sub-MAP and R-MAP Pointer IE.
Table 330—OFDMA STC DL Zone IE format
Syntax Size(bits) Notes
STC_DL_Zone_IE() { — —
Extended DIUC 4 STC/DL_Zone_SWITCH = 0x01
Length 4 Length = 0x04
... ... ...
ReservedTransparent relay transmit power adjustment
4 Shall be set to zeroUnsigned integer in the range +7dB to –21dB with 2 dB intervals indicating power adjustment for transparent relay to be applied relative to the assigned EIRP (see 8.4.4.8.1.2). Power adjustment (dB) = 7 - unsigned 4 bit value × 2The value 1111 is used as Relay zone indicator for Non-transparent relay. If the value is set to 1111, Transparent RS shall ignore it.
}
Copyright © 2009 IEEE. All rights reserved. 207
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Change Table 337 as indicated:
MAP VersionIndicates the version of the HARQ MAP, Sub-MAP or R-MAP.
Table 337—HARQ, and Sub-MAP and R-MAP Pointer IE format
Syntax Size(bits) Notes
HARQ_and_Sub-MAP_and_R-MAP_Pointer_IE() {
— —
Extended DIUC 4 HARQ_P = 0x07
Length 4 —
While (data remains) { — —
DIUC 4 Indicates the AMC level of the burst containing aHARQ MAP message
No. Slots 8 The number of slots allocated for the burst containinga HARQ MAP message
Repetition Coding Indication 2 0b00: No repetition coding0b01: Repetition coding of 2 used0b10: Repetition coding of 4 used0b11: Repetition coding of 6 used
MAP Version 2 0b00: HARQ MAPv10b01: Submap0b10: Submap with CID mask included0b11: ReservedR-MAP
If (MAP Version == 0b10) { — —
Idle users 1 Bursts for idle users included in the submap
Sleep users 1 Bursts for sleep users included in the submap
CID Mask Length 2 0b00: 12 bits0b01: 20 bits0b10: 36 bits0b11: 52 bits
CID mask n n = The number of bits of CID mask is determinedby CID Mask Length. When the MAPmessage pointed by this pointer IE includes anyMAP IE for an MS that is not in either Sleepmode or Idle mode, the bit index correspondingto ((Basic CID of the MS) MOD n) in this CIDMask field shall be set to 1. Otherwise, it shall beset to 0.
} — —
} — —
} — —
208 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Insert new subclause 8.4.5.3.32 as follows:
8.4.5.3.32 MR_DL-MAP MONITOR IE
In RS-assisted HARQ as described in 6.3.16.4.2.2, the MR-BS shall send the MR_DL-MAP MONITOR IE to RS. The MR_DL-MAP MONITOR IE provides the list of CIDs of the MS whose transmissions need to be monitored in the DL part of the current frame. When an RS receives a MR_DL-MAP Monitor IE, it shall store the CID list and uses for HARQ data forwarding until the list is updated by another MR_DL-MAP Monitor IE (see Table 375a).
N_CID_encodedThis field specifies the number of CIDs that shall use the encoded ACK/NAK among CIDs list in this IE. The CIDs from the beginning of the list to the value of this field use the encoded ACK/NAK.
N_CID_directThis field specifies the number of CIDs that shall use the direct ACK/NAK among CIDs list in this IE. The CIDs from the N_CID_encoded to the end of the list use the direct ACK/NAK.
Table 375a—MR_DL-MAP MONITOR IE format
Syntax Size(bits) Notes
MR_DL-MAP MONITOR_IE(){ — —
Extended-2 DIUC 4 0x0F(Extended-3 DIUC)
Length 8 Length in bytes
Extended-3 DIUC 4 MR_DL-MAP MONITOR IE = 0x01
Num_RS 8 Number of RSs
for(i=0; i<Num_RS; i++){ — —
RCID_IE variable RS CID
N_CID_encoded 4 Number of CIDs for which RS uses the encoded ACK/NAK
N_CID_direct 4 Number of CIDs for which RS uses the direct feedback
For(i=0; i<N_CID_encoded + N_CID_direct; i++){
— —
RCID_IE(i) variable The CIDs of the connections that RS shall monitor in the current frame
} — —
} — —
} — —
Copyright © 2009 IEEE. All rights reserved. 209
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Insert new subclause 8.4.5.3.33 as follows:
8.4.5.3.33 DL Burst Transmit IE format
An MR-BS may send R-MAP including DL_Burst_Transmit IE to the subordinate RSs to indicate the bursts to be forwarded by Nr in the IE. The Lk included in DL_Burst_Transmit IE refers to the number of bytes in each burst that is forwarded by the RS (see Table 375b).
8.4.5.4 UL-MAP IE format
8.4.5.4.2 PAPR Reduction/Safety Zone/Sounding Zone Allocation IE
Change Table 378 as indicated:
Table 375b—DL Burst Transmit IE format
Syntax Size(bits) Notes
DL_Burst_Transmit_IE(){ — —
Extended-2 DIUC 4 0x0F (Extended-3 DIUC)
Length 8 —
Extended-3 DIuc 4 DL_Burst_Transmit_IE = 0x02
If(included in SUB-DL-UL-MAP){ — —
RCID_IE() variable Reduced RS basic CID
}else{ — —
CID 16 RS basic CID
} — —
Nr 8 Indicate the number of MAP IEs in DL-MAP the transparent RS shall forward
for (k=0; k<Nr; k++) { — —
Lk 16 Burst length in bytes to be forwarded
} — —
Padding to byte alignment variable Shall be set to 0
} — —
210 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Insert the following under Table 378:
Relay zone indicatorIf the relay zone indicator bit is set to 1 then the PAPR Reduction/Safety Zone bit shall also be set to 1. This indicates to the RS that this is a relay zone and it may be allocated bursts. It also indicates to the SS that it shall not be required to transmit in the zone. If the relay zone indicator bit is set to 0, then the RS shall treat the zone as if it is a normal PAPR reduction/safety/sounding zone allocation.
Insert the following at the end of 8.4.5.4.2:
The MR-BS or RS may transmit UIUC=13 in the UL-MAP in the access zone for MS not to process in the uplink relay zone.
Table 378—PAPR Reduction/Safety Zone/Sounding Zone Allocation IE format
Syntax Size (bits) Notes
PAPR_Reduction_Safety_Sounding_Zone_Allocation_IE() { — —
OFDMA symbol offset 8 —
Subchannel offset 7 Not used for Sounding Zone
No. OFDMA symbols 7 —
No. subchannels/SZ Shift Value 7 No. Subchannels for PAPR reduction/ safety zone. Shift value (u) for Sounding Zone
PAPR Reduction/Safety Zone 1 0 = PAPR reduction allocation 1 = Safety zone allocation
Sounding Zone 1 0 = PAPR/safety zone 1 = Sounding zone allocation
ReservedRelay zone indicator 1 Shall be set to zero0b0: Normal Gap/PAPR/safety zone0b1: Relay zone indicator
} — —
Copyright © 2009 IEEE. All rights reserved. 211
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
8.4.5.4.4 UL-MAP Extended IE
8.4.5.4.4.1 UL-MAP Extended IE format
Change Table 381 as indicated:
8.4.5.4.4.3 UL-MAP Extended-3 IE format
Change Table 385 as indicated:
Table 381—Extended UIUC code assignment for UIUC = 15
Extended UIUC (hexadecimal) Usage
00 Power Control IE
01 Reserved
02 AAS UL IE
03 CQICH Allocation IE
04 UL Zone IE
05 UL-MAP Physical Modifier IE
06 Reserved
07 UL-MAP Fast Tracking IE
08 UL PUSC Burst Allocation in Other Segment IE
09 Fast Ranging IE
0A UL Allocation Start IE
0B UL Burst Receive IE
0BC...0F Reserved
Table 385—Extended-3 UIUC code assignment for Extended-2 UIUC = 05
Extended-3 UIUC(hexadecimal) Usage
00 RS MIMO in UL IE
01 MR UL-MAP Monitor IE
0x02–0F Reserved
212 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
8.4.5.4.7 UL Zone Switch IE format
Insert the following after the first paragraph in the 8.4.5.4.7:
When a relay zone is present in the UL subframe, the MR-BS or RS may transmit UL_Zone_IE in the access zone and shall not allocate burst for MS not to process in the uplink relay zone.
8.4.5.4.20 UL-MAP Fast Tracking IE
Insert new subclause 8.4.5.4.20.1 as follows:
8.4.5.4.20.1 UL-MAP Fast Tracking IE handing in an MR system
When RSs are operating in centralized scheduling mode, MR-BS may insert UL-MAP Fast-Tracking IEs with certain fields zeroed out into the UL-MAP that it assigns to that non-transparent RS to broadcast on the access link. The UL-MAP Fast-Tracking IEs shall have zeros in the fields for Power correction, Frequency correction, and Time correction. When the RS receives RS_Access-MAP message from the MR-BS with an assigned UL-MAP containing UL-MAP Fast-Tracking IEs with zeroed out fields, the RS shall fill in these fields with the appropriate adjustment information and then broadcast this updated UL-MAP on the access link.
8.4.5.4.22 HARQ UL-MAP IE
Change 8.4.5.4.22 as indicated:
The HARQ UL MAP IE defines one or more bursts. Each burst is separately encoded.
If MAC tunneling is used, tunnel CID shall be used instead of RCID in the related UL HARQ subburst IE for the corresponding subburst.
Insert new subclause 8.4.5.4.30 as follows:
8.4.5.4.30 UL_Burst _Receive_IE format
Table 426a—UL_Burst_Receive_IE format
Syntax Size (bits) Notes
UL_Burst_Receive_IE() { 16 —
Extended UIUC 4 UL Burst Receive IE = 0x0B
Length 4 Length=1
Nr 8 Number of UL-MAP_IE following cur-rent IE for RS to receive data bursts from subordinate station(s)
} — —
Copyright © 2009 IEEE. All rights reserved. 213
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Insert new subclause 8.4.5.4.31 as follows:
8.4.5.4.31 RS MIMO in UL IE format
In the UL-MAP, a MIMO-enabled MR-BS shall transmit RS MIMO in the UL IE to RS to indicate the MIMO configuration and pilot patterns of the subsequent uplink allocations described in this IE. This IE may be used either for MIMO-enabled RS or for an RS that supports only collaborative SM up to two RSs.
Table 426b—RS MIMO UL IE format
Syntax Size (bits) Notes
RS_MIMO_in_UL_IE() { — —
Extended-2 UIUC 4 0x05 (Extended-3 UIUC)
Length 8 Length in bytes
Extended-3 UIUC 4 RS MIMO in UL IE = 0x00
Num_Assign 4 Number of burst assignment
For (j=0;j<Num_Assign;j++) { — —
Num_CID 2 —
For (i=0; i<Num_CID; i++) { — —
CID 16 RS basic CID
UIUC 4 —
Antenna_Indicator 4 Indicates the antennas used for trans-mission 0: antenna is not used 1: antenna is used
If (single antenna is used) { — —
Pilot Pattern Indicator 1 Indicates pilot pattern 0b0: pilot pattern A 0b1: pilot pattern B
}elseif (dual antennas are used){ — —
Matrix_Indicator 2 Indicates transmission matrix 0b00= Matrix A (see 8.4.8.3.3), pilot A/B 0b01= Matrix A (see 8.4.8.3.3), pilot C/D 0b10= Matrix B (see 8.4.8.3.3) 0b11= Matrix C (see 8.4.8.3.3)
}elseif (three antennas are used){ — —
Matrix_Indicator 2 Indicates transmission matrix 0b00= Matrix A (see 8.4.8.3.4) 0b01= Matrix B (see 8.4.8.3.4) 0b10= Matrix C (see 8.4.8.3.4) 0b11= Reserved
If (Matrix_Indicator==0b00 or 0b01) { — —
214 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Antenna_IndicatorA field that specifies which antenna(s) is/are used for uplink transmission. For example, if this field is set to 0b1100, a 3-antenna RS shall use the first and second antenna for uplink transmissions. The last bit, which shall be set to zero in this case, is skipped.
Pilot Pattern IndicatorA field that specifies which pilot pattern(s) is/are used. When the used antenna number is three, the first antenna shall use pilot pattern A, the second antenna shall use pilot pattern B and the third antenna shall use pilot pattern C. When the used antenna number is four, the first antenna shall use pilot pattern A, the second antenna shall use pilot pattern B, the third antenna shall use pilot pattern C, and the forth antenna shall use pilot pattern D.
Matrix_IndicatorA field that specifies the used MIMO coding matrices, i.e., space-time-frequency coding matrices, for uplink. It may also jointly specify which pilot pattern(s) is/are used. All the uplink MIMO coding matrices in this IE are reused from the downlink, which are defined in 8.4.8.3.3, 8.4.8.3.4, and 8.4.8.3.5.
Antenna_Grouping_Indicator 2 Indicating the index of the antenna grouping index if (Matrix_indicator== 0b00) 0b000~0b010=0b101110~0b110000 in Table 324 else 0b000~0b010=0b110001~0b110011 in Table 324
} — —
}else{ — —
Matrix_Indicator 2 Indicates transmission matrix 0b00= Matrix A (see 8.4.8.3.5) 0b01= Matrix B (see 8.4.8.3.5) 0b10= Matrix C (see 8.4.8.3.5) 0b11= Reserved
If (Matrix_Indicator== 0b00 or 0b01) { — —
Antenna Grouping Index 3 Indicating the index of the antenna grouping index if (Matrix_indicator== 0b00) 0b000~0b010=0b101110~0b110000 in Table 324 else 0b000~0b101=0b110001~0b110110 in Table 324
} — —
} — —
} — —
Duration 10 In OFDMA slots (see 8.4.3.1)
} — —
Padding — Padding to reach byte boundary
} — —
Table 426b—RS MIMO UL IE format (continued)
Syntax Size (bits) Notes
Copyright © 2009 IEEE. All rights reserved. 215
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
8.4.5.4.32 MR_UL-MAP_MONITOR IE
The MR_UL-MAP MONITOR IE provides the list of CIDs of the MS whose transmissions need to be monitored in the UL part of the current frame. When an RS receives a MR_UL-MAP Monitor IE, it stores the CID list and uses for HARQ data forwarding until the list is updated by another MR_UL-MAP MONITOR IE.
Insert new subclause 8.4.5.10 as follows:
8.4.5.10 R-MAP message
This message shall be used in a non-transparent TTR frame structure and may be used in a transparent or non-transparent STR frame structure to signal resource assignments and other control information. If the R-MAP message is presented in the downlink relay zone, it shall immediately follow the R-FCH and shall not be preceded by a MAC header and message type field. The modulation and coding rate for the R-MAP message is indicated in the R-FCH. If the R-MAP message is presented in the downlink access zone, the placement of R-MAP message within a frame shall be the same as SUB-DL-UL-MAP shown in Figure 39. The INC_CID flag in the DL-MAP_IE(s) shall start with INC_CID=0. The message format is shown in Table 436a.
Table 426c—MR UL-MAP MONITOR IE format
Syntax Size(bits) Notes
MR_UL-MAP_MONITOR IE{ — —
Extended-2 UIUC 4 0x05 (Extended-3 UIUC)
Length 8 Length in bytes
Extended-3 UIUC 4 MR UL-MAP Monitor IE = 0x01
Num_RS 8 Number of RSs
for(i=0; i<Num_RS; i++){ — —
RCID_IE variable Reduced MS basic CID
Number of CIDs 4 Number of CIDs in the IE
For(i=0; i<Number of CIDs; i++){ — —
RCID_IE(i) variable The CIDs of the connections that RS shall mon-itor in the current frame
} — —
} — —
Padding variable Padding to reach byte boundary
} — —
216 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
RCD configuration change countMatches the value of the configuration change count of RCD, which describes the configuration of the RS operation.
The CRC-32 value shall be appended to the end of an R-MAP message. The CRC is computed across all bytes of the R-MAP. The CRC calculation is the same as that used for the MAP messages.
Insert new subclauses 8.4.5.10.1 to 8.4.5.10.13 as follows:
Table 436a—R-MAP message format
Syntax Size(bits) Notes
R-MAP format { — —
RCD configuration change count 8 —
RCID_Type 2 0b00 = Normal CID0b01 = RCID 110b10 = RCID 70b11 = RCID 3
Length 11 Length of R-MAP in bytes
DL_IE count 6 Number of DL_IE in the burst
UL_IE count 6 Number of UL_IE in the burst
for(i=0;i<DL_IE count; i++){ — —
DL-MAP_IE variable —
} — —
for(i=0;i<UL_IE count; i++){ — —
UL-MAP_IE variable —
} — —
While(map data remains){ — —
R-link specific IE variable —
} — —
Padding variable Padding to reach byte boundary
} — —
Copyright © 2009 IEEE. All rights reserved. 217
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
8.4.5.10.1 R-link specific IE format
The R-link specific IE format for non-transparent RSs is shown in Table 436b. R-link specific IEs shall not be transmitted to transparent RSs.
The R-link specific IE types are listed in Table 436c.
Table 436b—R-link specific IE format
Syntax Size(bits) Notes
R-link specific IE(){ — —
Type 5 —
Length 4 or 8 Length in bytes. Size of field is either 4 bits or 8 bits depending on IE Type.
IE specific data variable —
} — —
Table 436c—R-link specific IE types
Type(hexadecimal) Usage
00 RS_UL_DCH assignment IE
01 RS_UL_DCH HARQ RETX IE
02 Reserved
03 Reserved
04 RS_HARQ_DL-MAP IE
05 UL relay zone configuration
06 HARQ_ACKCH_Region_for_Relay_Data IE
07 MR_DL-MAP MONITOR IE
08 MR_UL-MAP_MONITOR IE
09 RS_CQICH_Control IE
0A Aggregated HARQ ACK region allocation IE
0B RS_MIMO_in_UL_IE
0C–1F Reserved
218 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
8.4.5.10.2 RS UL DCH assignment IE
This IE is used for the initial allocation and subsequent updates of the uplink dedicated channel on the R-link (see Table 436d).
Table 436d—RS_UL_DCH assignment IE format
Syntax Size(bits) Notes
RS_UL_DCH assignment IE { — —
Type 5 RS UL DCH assignment IE = 0x00
Length 4 —
RCID_IE() variable RS basic CID in RCID_IE format (see 8.4.5.3.20.1)
Update type 2 00 = Normal 01 = Service flow based 10–11 = Reserved
If (Update type == 01) { — If service flow based update
Adjustment type 1 0 = Decrease1 = Increase
Throughput size 24 Amount of throughput update in byte/s
RCID_IE() variable RS basic CID in RCID_IE format (see 8.4.5.3.20.1) of the access RS of the MS that completed the service flow event.
} — —
Assignment type 2 00 = Incremental (Add the specified resource to UL DCH)01 = Aggregate (An aggregate assignment with no resource indicates all UL DCH removal)10 = Removal (Remove the specified resource from UL DCH)11 = Tx profile and settings update
DCH resource ID 3 ID of the DCH resource being assigned or managed
if(Assignment type != 0b10){ if assignment type is not removal
HARQ Control 1 0: Synchronous HARQ NAK1: Asynchronous HARQ NAK
HARQ type 2 0b00 – Disabled0b01 – HARQ Chase0b10 – HARQ CTC IR0b11 – HARQ CC IR
if (HARQ type == 0b10) { — —
NEP 4 —
NSCH 4 —
} else { — —
UIUC 4 —
Repetition coding indication
2 0b00 – no repetition coding0b01 – repetition coding of 20b10 – repetition coding of 40b11 – repetition coding of 6
Copyright © 2009 IEEE. All rights reserved. 219
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
8.4.5.10.3 RS_UL_DCH HARQ RETX IE
The RS_UL_DCH HARQ RETX IE is transmitted to RSs to request the retransmission of HARQ bursts on RS UL_DCH. For asynchronous HARQ NAK operation, the corrupted HARQ bursts are indicated by their corresponding DCH resource ID and DCH ACID. For synchronous HARQ NAK operation, the corrupted HARQ bursts are indicated by only their corresponding DCH resource ID and the superordinate station that receives HARQ UL burst at ith frame shall transmit NAK signal at (i+j)th frame. The frame offset “j” is defined by the “HARQ UL Burst ACK Delay” field in the RCD message. RS_UL_DCH HARQ RETX IE includes either the indication of use of dedicated UL DCH or the allocation of additional resources for retransmission. If Retransmission Type is 0, an RS that receives HARQ NAK feedbacks shall retransmit the corrupted bursts using the existing dedicated resources on RS UL_DCH. The resource from the same DCH resource ID is used. The retransmission is sent using the same HARQ channel and it is sent on the next occurrence of the same HARQ channel after the NAK signal. If Retransmission Type is 1, the corrupted burst is retransmitted in the additional resource specified in the IE and the one time allocation is in the next frame following the IE.
} — —
Number of DCH ACID 4 Maximum number of HARQ channels associated with this assignment
if (Assignment type != 0b11) {
— —
OFDMA symbol offset 8 —
Subchannel offset 8 —
Duration 10 Resources allocated to DCH (in OFDMA slots)
Frequency (N) 4 Allocation repeats once every N frames
} — —
} — —
Padding variable Shall be set to zero
} — —
Table 436d—RS_UL_DCH assignment IE format (continued)
Syntax Size(bits) Notes
220 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
The format of the RS_UL_DCH HARQ RETX IE is shown in Table 436e.
Table 436e—RS_UL_DCH HARQ RETX IE format
Syntax Size(bits) Notes
RS_UL_DCH HARQ RETX IE () { — —
Type 5 RS_UL_DCH HARQ RETX IE = 0x01
Length 4 variable
Number of bursts 3 —
for (i=0;i<Number of bursts; i++) { — —
RSCID variable RS basic CID in RCID_IE format (see 8.4.5.3.20.1)
DCH resource ID 3 ID of the RS UL_DCH resource has transmission failure
HARQ Control 1 0: Synchronous HARQ NAK1: Asynchronous HARQ NAK
if (HARQ Control == 1) { — Asynchronous HARQ NAK
DCH ACID 4 HARQ channel required retransmission
} — —
Retransmission Type 1 0: HARQ retransmission to occur in allocated dedicated UL_DCH1: HARQ retransmission to occur in resource assigned in this IE
if (Retransmission Type == 1) { — HARQ retransmission to occur in resource assigned in this IE
OFDMA Symbol offset 8 —
Subchannel offset 8 —
Duration 10 Resources allocated for HARQ retransmission (in OFDMA slots)
} — —
SPID 2 For CTC IR, specify SPID for retransmission bursts. If HARQ type for the DCH resource does not require SPID, this SPID shall be set to 0.
} — —
Padding variable Shall be set to zero
} — —
Copyright © 2009 IEEE. All rights reserved. 221
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
8.4.5.10.4 RS HARQ DL MAP IE
If MAC tunneling is used, tunnel CID shall be used instead of RCID in the related DL HARQ subburst IE for the corresponding subburst.
Table 436f—RS HARQ DL IE format
Syntax Size(bits) Notes
RS_HARQ_DL-MAP IE { — —
Type 5 RS_HARQ_DL-MAP IE = 0x04
Length 8 Length in bytes
Reserved 3 —
While (data remains) { — —
Boosting 3 0b000: normal (not boosted) 0b001: +6 dB 0b010: –6 dB 0b011: +9 dB 0b100: +3 dB 0b101: –3 dB 0b110: –9 dB 0b111: –12 dB
Region_ID use indicator 1 0: not use Region_ID 1: use Region_ID
If (Region_ID use indicator == 0 ) { — —
OFDMA symbol offset 8 Offset from the start symbol of DL subframe
Subchannel offset 7 —
Number of OFDMA symbols 7 —
Number of subchannels 7 —
Rectangular Subburst Indication 1 Indicates subburst allocations are time-first rectangular. The duration field in each subburst IE specifies the num-ber of subchannels for each rectangular allocation. This is only valid for AMC allocations and all allocations with dedicated pilots. When this field is clear, subbursts shall be allocated in frequency-first manner and the duration field reverts to the default operation.
Reserved 2 —
} else { — —
Region_ID 8 Index to the DL region defined in DL region definition TLV in DCD
} — —
ACK_frame_delay 4 The RS shall transmit encoded ACK/NAK after ACK_frame_delay frames from receiving the DL HARQ MAP.
Reserved 1 Shall be set to zero
222 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
ACK_frame_delay
The BS can specify when the subordinate RS sends encoded ACK/NAK using this parameter, which may be decided by factors such as RS hop-count (how many hops from BS), MS HARQ ACK delay for DL burst and RS processing delay regarding DL burst from superordinate station and UL ACK from subordinate station etc.
Mode 4 Indicates the mode of this HARQ region 0b0000 = Chase HARQ 0b0001 = Incremental redundancy HARQ for CTC 0b0010 = Incremental redundancy HARQ for Convolu-tional Code 0b0011 = MIMO Chase HARQ 0b0100 = MIMO IR HARQ 0b0101 = MIMO IR HARQ for Convolutional Code 0b0110 = MIMO STC HARQ 0b0111–0b1111 Reserved
Subburst IE Length 8 Length, in nibbles, to indicate the size of the subburst IE in this HARQ mode. The MS may skip DL HARQ sub-burst IE if it does not support the HARQ Mode. How-ever, the MS shall decode NAK Channel field from each DL HARQ subburst IE to determine the UL ACK chan-nel it shall use for its DL HARQ burst.
If (Mode == 0b0000) { — —
DL HARQ Chase subburst IE() variable —
} else if (Mode == 0b0001) { — —
DL HARQ IR CTC subburst IE() variable —
} else if (Mode == 0b0010) { — —
DL HARQ IR CC subburst IE() variable —
} else if (Mode==0b0011) { — —
MIMO DL Chase HARQ subburst IE () variable —
} else if (Mode==0b0100) { — —
MIMO DL IR HARQ subburst IE () variable —
} else if (Mode==0b0101) { — —
MIMO DL IR HARQ for CC subburst IE ()
variable —
} else if (Mode == 0b0110) { — —
MIMO DL STC HARQ subburst IE () variable —
} — —
} — —
Padding variable Padding to byte; shall be set to 0
} — —
Table 436f—RS HARQ DL IE format (continued)
Syntax Size(bits) Notes
Copyright © 2009 IEEE. All rights reserved. 223
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
8.4.5.10.5 UL relay zone configuration IE
8.4.5.10.6 HARQ ACK region allocation for Relay Data IE
This IE may be used by the MR-BS to define an ACK channel region on the R-UL to include one or more ACK channel(s) for RS.
In the case of a transparent RS, the RS that receives an HARQ UL subburst from an MS for relaying to the MR-BS at frame i shall transmit the ACK/NAK signal through the ACK Channel in the ACKCH region for UL MS data at frame (i+k). The frame offset k is defined by the “HARQ ACK Delay for UL Burst for MR” field in the UCD message.
In the case of a non-transparent RS, the RS that received the HARQ UL MAP IE shall transmit an ACK/NAK to the superordinate station in the frame when the RS sends the corresponding the HARQ subbursts indicated by HARQ UL MAP IE, which may include a retransmission burst starting from its own RS. The UL HARQ procedure follows the description in 6.3.16.5.1.
The ACK/NAK for UL HARQ transmission is allocated by an HARQ ACK region allocation IE and the order of ACKs in an UL ACKCH shall follow the order of the UL HARQ subbursts in the HARQ UL MAP IE.
Table 436g—UL relay zone configuration IE format
Syntax Size (bits) Notes
UL relay zone configuration IE format() { — —
Type 5 Relay zone configuration IE = 0x05
Length 4 Length = 2 or 4
OFDMA symbol offset 8 This value indicates start symbol offset of all subsequent UL allocations in this R-MAP mes-sage. The reference point of this offset is the start of UL subframe.
No. of OFDMA symbol 7 —
Indicator 1 0x0b0: All subchannels in UL are used 0x0b1: Partial subchannels in UL are used
If(Indicator == 0b1) { — —
Subchannel offset 7 This value indicates start subchannel offset of all subsequent UL data burst allocations in this message (R-MAP).
No. of subchannel 7 —
Reserved 2 Shall be zero
} — —
} — —
224 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Retx_ACHCH_offset
Retx_ACKCH_offset indicates the starting point in the ACKCH region for sending ACK/NAK signals for the retransmitted burst. RS uses this region to forward the ACK/NAK signals of retransmitted burst and along with relaying the ACK/NAK signals of retransmitted bursts received from its subordinate RSs. The RS shall transmit encoded ACK/NAK after ACK_frame_delay frames from receiving the DL HARQ MAP.
When an RS receives an HARQ DL subburst for relaying to MS at frame i, it shall transmit the encoded ACK/NAK signal through ACK Channel in the ACKCH region at frame (i + n) where n is given by the ACK_frame_delay in RS_HARQ_DL-MAP IE that is transmitted by the MR-BS to the RS ACK/NAKs in response to subbursts belonging to RS_HARQ_DL-MAP IEs received in different frames, shall be transmitted in the order in which the MAPs were received.
Table 436h—HARQ ACKCH Region allocation for Relay Data IE format
Syntax Size(bits) Notes
HARQ_ACKCH_Region_allocation_for_Relay_Data IE() {
— —
Type 5 HARQ ACKCH Region for Relay Data IE = 0x06
Length 8 Length in bytes
Direction 1 0 = IE is related to UL HARQ Data IE1 = IE is related to DL HARQ Data IE
If (direction == 1) { — —
retx_region_present 1 0: not present1: present
If (retx_region_present == 1) { — —
N_RS 3 Number_of_RS
For(j=0; j< N_RS; j++){ — —
RCID_IE() variable RS basic CID
Retx_ACKCH_offset 8 —
} — —
} — —
} — —
OFDMA symbol offset 8 —
Subchannel offset 7 —
No. OFDMA symbols 5 —
No. subchannels 4 —
Padding variable Shall be set to 0
} — —
Copyright © 2009 IEEE. All rights reserved. 225
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
If pre-scheduling of retransmissions on the access link on the UL is enabled, only ACK/NAK feedback for non-prescheduled bursts or for pre-scheduled bursts that have reached the maximum number of pre-scheduled attempts is to be forwarded to the MR-BS in the allocated UL HARQ ACKCH region.
8.4.5.10.7 MR_DL-MAP MONITOR IE
In RS-assisted HARQ as described in 6.3.16.4.2.2, the MR-BS shall send the MR_DL-MAP MONITOR IE to RS. The MR_DL-MAP MONITOR IE provides the list of CIDs of the MS whose transmissions need to be monitored in the DL part of the current frame. When an RS receives a MR_DL-MAP Monitor IE, it shall store the CID list and uses for HARQ data forwarding until the list is updated by another MR_DL-MAP Monitor IE.
N_CID_encodedThis field specifies the number of CIDs that shall use the encoded ACK/NAK among CIDs list in this IE. The CIDs from the beginning of the list to the value of this field use the encoded ACK/NAK.
N_CID_directThis field specifies the number of CIDs that shall use the direct ACK/NAK among CIDs list in this IE. The CIDs from the N_CID_encoded to the end of the list use the direct ACK/NAK.
8.4.5.10.8 MR_UL-MAP_MONITOR IE
The MR_UL-MAP MONITOR IE provides the list of CIDs of the MS whose transmissions need to be monitored in the UL part of the current frame. When an RS receives a MR_UL-MAP Monitor IE, it stores the CID list and uses for HARQ data forwarding until the list is updated by another MR_UL-MAP MONITOR IE.
Table 436i—MR_DL-MAP MONITOR IE format
Syntax Size(bits) Notes
MR_DL-MAP MONITOR_IE(){ — —
Extended-2 DIUC 4 MR_DL-MAP MONITOR_IE = 0x07
Length 8 Length in bytes
Num_RS 8 Number of RSs
for(i=0; i<Num_RS; i++){ — —
RCID_IE variable RS CID
N_CID_encoded 4 Number of CIDs for which RS uses the encoded ACK/NAK
N_CID_direct 4 Number of CIDs for which RS uses the direct feedback
For(i=0; i<N_CID_encoded + N_CID_direct; i++){ — —
RCID_IE(i) variable The CIDs of the connections that RS shall monitor in the current frame
} — —
} — —
} — —
226 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
8.4.5.10.9 RS CQICH Control IE
An MR-BS configures the type of RS feedback reporting (full or differential) using the RS_CQICH_Control IE, as defined in Table 436k.
Table 436j—MR UL-MAP MONITOR IE format
Syntax Size(bits) Notes
MR_UL-MAP_MONITOR IE{ — —
Extended-2 UIUC 4 MR UL-MAP Monitor IE = 0x08
Length 8 Length in bytes
Num_RS 8 Number of RSs
for(i=0; i<Num_RS; i++){ — —
RCID_IE variable Reduced MS basic CID
Number of CIDs 4 Number of CIDs in the IE
For(i=0; i<Number of CIDs; i++){ — —
RCID_IE(i) variable The CIDs of the connections that RS shall mon-itor in the current frame
} — —
} — —
} — —
Table 436k—RS_CQICH_Control IE format
Syntax Size(bits) Notes
RS_CQICH_Control IE { — —
Type 5 RS_CQICH_Control IE = 0x09
Length 4 Length in bytes
N_CID 4 Number of RS CIDs
For(i=0; i < N_CID; i ++) { — —
Full_differential_feedback_reporting 1 0 = full feedback reporting1 = differential feedback reporting
If(full_differential_feedback_reporting = 1) { — —
N_agg 1 0 = 3 bits differential feedback 1 = 2 bits differential feedback
} — —
RCID_IE() variable Reduced CID of the RS
} — —
} — —
Copyright © 2009 IEEE. All rights reserved. 227
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
8.4.5.10.10 Aggregated HARQ ACK region allocation IE
This IE may be used by the MR-BS/RS to define a UL region to include one or more aggregated HARQ ACK channel(s). The IE format is shown in Table 436l. Aggregated HARQ ACK channel structure is same as defined in 8.4.5.4.25.
When an RS receives the aggregated HARQ ACK/NAK signals in frame N it shall relay the signals to its superordinate station in frame N+j, where j is defined by “HARQ_ACK_Delay for DL burst” field in DCD message.
Table 436l—Aggregated HARQ ACK region allocation IE format
Syntax Size(bits) Notes
Aggregated HARQ ACK region allocation IE() { — —
Type 5 Aggregated HARQ ACK region allocation IE = 0x0A
Length 8 Length in bytes
OFDMA symbol offset 8 —
Subchannel offset 7 —
No. OFDMA symbols 5 —
No. subchannels 4 —
N_CID_DL 8 Number of DL T-CIDs that are served by this region.
N_CID_UL 8 Number of UL T-CIDs that are served by this region.
For (i = 0; i < N_CID_DL; i++) { — —
CID 16 Tunnel CID
N_ACK_channels 8 No. of aggregated HARQ ACK channels that are allocated to RS to transmit MS’s HARQ ACK/NAK.
} — —
For (i = 0; i < N_CID_UL; i++) { — —
CID 16 Tunnel CID
N_ACK_channels 8 No. of aggregated HARQ ACK channels that are allocated to RS to transmit the reception status report of MS’s MAC PDUs.
}
Padding variable Padding to reach byte boundary
} — —
228 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
8.4.5.10.11 RS MIMO in UL IE format
In the UL-MAP, a MIMO-enabled MR-BS shall transmit RS MIMO in the UL IE to RS to indicate the MIMO configuration and pilot patterns of the subsequent uplink allocations described in this IE. This IE may be used either for MIMO-enabled RS or for an RS that supports only collaborative SM up to two RSs.
Table 436m—RS MIMO UL IE format
Syntax Size (bits) Notes
RS_MIMO_in_UL_IE() { — —
Type 5 RS MIMO in UL IE = 0x0B
Length 8 variable
Num_Assign 4 Number of burst assignment
For (j=0;j<Num_Assign;j++) { — —
Num_CID 2 —
For (i=0; i<Num_CID; i++) { — —
CID 16 RS basic CID
UIUC 4 —
Antenna_Indicator 4 Indicates the antennas used for transmission 0: antenna is not used 1: antenna is used
If (single antenna is used) { — —
Pilot Pattern Indicator 1 Indicates pilot pattern 0b0: pilot pattern A 0b1: pilot pattern B
}elseif (dual antennas are used){ — —
Matrix_Indicator 2 Indicates transmission matrix 0b00= Matrix A (see 8.4.8.3.3), pilot A/B 0b01= Matrix A (see 8.4.8.3.3), pilot C/D 0b10= Matrix B (see 8.4.8.3.3) 0b11= Matrix C (see 8.4.8.3.3)
}elseif (three antennas are used){
Matrix_Indicator 2 Indicates transmission matrix 0b00= Matrix A (see 8.4.8.3.4) 0b01= Matrix B (see 8.4.8.3.4) 0b10= Matrix C (see 8.4.8.3.4) 0b11= Reserved
If (Matrix_Indicator==0b00 or 0b01) {
Antenna_Grouping_Indicator 2 Indicating the index of the antenna grouping index if (Matrix_indicator== 0b00) 0b000~0b010=0b101110~0b110000 in Table 324 else 0b000~0b010=0b110001~0b110011 in Table 324
Copyright © 2009 IEEE. All rights reserved. 229
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Antenna_IndicatorA field that specifies which antenna(s) is/are used for uplink transmission. For example, if this field is set to 0b1100, a 3-antenna RS shall use the first and second antenna for uplink transmissions. The last bit, which shall be set to zero in this case, is skipped.
Pilot Pattern IndicatorA field that specifies which pilot pattern(s) is/are used. When the used antenna number is three, the first antenna shall use pilot pattern A, the second antenna shall use pilot pattern B, and the third antenna shall use pilot pattern C. When the used antenna number is four, the first antenna shall use pilot pattern A, the second antenna shall use pilot pattern B, the third antenna shall use pilot pattern C, and the forth antenna shall use pilot pattern D.
Matrix_IndicatorA field that specifies the used MIMO coding matrices, i.e., space-time-frequency coding matrices, for uplink. It may also jointly specify which pilot pattern(s) is/are used. All the uplink MIMO coding matrices in this IE are reused from the downlink, which are defined in 8.4.8.3.3, 8.4.8.3.4, and 8.4.8.3.5.
}
}else{
Matrix_Indicator 2 Indicates transmission matrix 0b00= Matrix A (see 8.4.8.3.5) 0b01= Matrix B (see 8.4.8.3.5) 0b10= Matrix C (see 8.4.8.3.5) 0b11= Reserved
If (Matrix_Indicator== 0b00 or 0b01) {
Antenna Grouping Index 3 Indicating the index of the antenna grouping index if (Matrix_indicator== 0b00) 0b000~0b010=0b101110~0b110000 in Table 324 else 0b000~0b101=0b110001~0b110110 in Table 324
}
}
}
Duration 10 In OFDMA slots (see 8.4.3.1)
}
Padding variable Padding to reach byte boundary
}
Table 436m—RS MIMO UL IE format (continued)
Syntax Size (bits) Notes
230 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
8.4.6 OFDMA subcarrier allocations
8.4.6.1 Downlink (DL)
8.4.6.1.1 Preamble
Insert new subclause 8.4.6.1.1.3 as follows:
8.4.6.1.1.3 Relay amble
The relay amble, if present, is a repetitive structure with a maximum repetition period given by Equation (61a).
Max RelayAmbleRepetitionPeriod = 40 ms (61a)
For FFT size of 2048 and 1024, the relay amble series shall be obtained by reversing the corresponding preamble series in 8.4.6.1.1, i.e.,
(61b)
where PNi is the related PN sequence length with index of i, and J is 567 and 283 for FFT size of 2048 and 1024, respectively.
For FFT size of 512 and 128, the relay amble series shall be obtained by circle-shifting the corresponding preamble series in 8.4.6.1.1, i.e.,
(61c)
where J is 142 and 35 for FFT size of 512 and 128, respectively, and s is 2 and 1 for FFT size of 512 and 128, respectively.
The index, i, of the relay amble used in each sector/cell shall be the same as that of the preamble used in the access zone.
The relay amble series shall be modulated using boosted BPSK modulation, as specified in 8.4.9.4.3.1.1.
Insert new subclause 8.4.6.1.1.4 as follows:
8.4.6.1.1.4 R-amble Repetition Scheme
The R-amble shall be used for the following two purposes: 1) To acquire/keep in time and frequency synchronization for subordinate RSs. Once synchronization
is acquired during the initial entry/reentry using the frame start preamble, an RS shall keep in sync by monitoring an R-amble transmitted by its superordinate station (RS or MR-BS) at regular intervals. RSs that do not support synchronization of subordinate RSs may not transmit this amble. The RS shall maintain synchronization with its superordinate station at all times. For this reason, every RS shall monitor its superordinate station’s synchronization signal at least every 40 msec.
2) To enable the RS to monitor its neighborhood. This requires monitoring the R-amble transmissions of the neighbors. This monitoring function may be accomplished with less regularity than that required for synchronization.
PNiR j( ) i, 0 1… 113 j, ,, 0 1 … J, , ,= =
PNiR j( ) PNi J j–( ), i 0 1… 113 j, ,, 0 1 … J, , ,= = =
PNiR j( ) i, 0 1… 113 j, ,, 0 1 … J, , ,= =
PNiR j( ) PNi J s– j 1+ +( ) if j=0 1 … s, , , 1–
PNi j s–( ) if j=s s 1 … J, ,+,⎩⎨⎧
=
Copyright © 2009 IEEE. All rights reserved. 231
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
These two objectives shall be accomplished with a combination of two R-amble transmission/monitoring schemes indicated below.
The parameters defined below shall be communicated by an MR-BS to its subordinate RSs using the message described in 6.3.2.3.60. If the MR-BS uses optional common sync, then an RS shall not transmit R-amble in that frame. In that case, the selection of the configuration parameters shall be done not to have such overlapping.
Insert new subclause 8.4.6.1.1.4.1 as follows:
8.4.6.1.1.4.1 R-amble repetition for synchronization
For synchronization, the R-amble repetition pattern is defined using two parameters, offset, Ks and a Synchronization Cycle consists of N consecutive frames.
The Frame_Number parameter used below is that used by the MR-BS. An RS can compute this value based on the relation: Computed_Frame_Number = Frame_Number – Modulo_Frame_Offset, where the Modulo_Frame_Offset is provided in the RS_Config-CMD via a unicast transmission, and the Frame_Number is the frame number used by the RS. The Modulo_Frame_Offset is computed by the MR-BS, and it is given by the modulo N operation applied to the difference between the Frame Number at the RS and the Frame_Number at the MR-BS. Note that Modulo_Frame_Offset is a constant.
Two sequences are defined for transmitting the R-amble. Sequence A transmits the R-amble when the following relation is satisfied 1 = (Computed_Frame_Number modulo N) + 1, while the sequence B transmits the R-amble when Ks = (Computed_Frame_Number modulo N) + 1 relation is satisfied. The time allocation of the relay ambles shall not overlap with the common sync amble related time allocation, when the common sync is used in the system.
Each RS supporting a subordinate RS for synchronization shall transmit the R-amble in either A or B frames, but not in both. An MR-BS may transmit the R-amble in both frames. An RS during initial entry, searches A or B frames for the parent station's R-amble. After determining the R-amble sequence of its parent RS/MR-BS, the RS shall perform synchronization using the detected sequence and shall transmit its R-amble using the complementary sequence. For example, if the RS detects that its parent station transmits using sequence B, then it shall use sequence A for transmitting its R-amble. It may not be necessary to transmit the R-amble if an RS does not support a subordinate RS, and this capability is provided in the configuration message.
Using the frame number as the reference, the MR-BS shall ensure that the Synchronization Cycle is synchronized across the network.
232 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Figure 245a—An example implementation of the alternate R-amble transmission monitoring scheme for synchronization, N = 4 and Ks = 2
An example of pattern generation for transmitting the R-amble is provided in Figure 245a. Note that MR-BS and the Second Tier of relays use the sequences A for transmitting their R-ambles, while in the positions given by sequence B they are performing the synchronization task. On the other hand, the First Tier of RSs are transmitting their R-ambles using B sequences, while they are using the A sequences for synchronization purpose.
Insert new subclause 8.4.6.1.1.4.2 as follows:
8.4.6.1.1.4.2 R-amble repetition for neighborhood monitoring
An R-amble shall be transmitted in every Lth frame with an offset of Km whenever the neighborhood monitoring scheme is specified, unless it is in the monitoring mode as described below. Sequence C transmits the R-amble when the following relation is satisfied Km = (Computed_Frame_Number modulo L) + 1. When the common sync is used, Km shall not be equal to 4k where k = 1,2,3,...
M such monitoring frames forms a Neighborhood Monitoring Cycle, i.e., L × M frames. Out of M possible R-ambles positions for transmission within a Neighborhood Monitoring Cycle, each RS randomly selects one of these positions for monitoring the neighbor RSs. The MR-BS may also follow the same transmission/monitoring scheme.
This monitoring scheme may also be also used for synchronization, if the RS can listen to its parent RS within the required sync time.
Insert new subclause 8.4.6.1.1.4.3 as follows:
8.4.6.1.1.4.3 Parallel Operation of the neighborhood monitoring and synchronization
In order to have synchronization and neighborhood monitoring, the above two schemes may operate together. The choice of these parameters is implementation dependent and some example cases are explained next.
A frame where the RS amble is transmitted
A frame where the RS amble is monitored
A B A B A
MR-BS
First tier RS
Second tier RS
B
Frame Organization
Frame 1 Frame 2 Frame 3 Frame 4 Frame 5 Frame 6 Frame 7 Frame 8 Frame 9A B A B A B
Copyright © 2009 IEEE. All rights reserved. 233
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Figure 245b shows the case where, N = 4, L =8, Ks = 2, Km = 3. The C frames are the frames in which the R-ambles are transmitted for neighborhood monitoring.
Figure 245b—An example implementation of the combined scheme for neighborhood monitoring and synchronization, N = 4, L =8, Ks = 2, Km = 3
For the cases where Km = 1 or Km = Ks, i.e., monitoring frames are the same as the synchronization frames, the monitoring may be done using the synchronization R-ambles. Thus, if an RS uses A frames for transmitting the R-amble and B frames for monitoring, that RS would additionally randomly monitor in one of the A frames out of M such frames. This however means that occasionally R-amble is not transmitted to its subordinate RS and hence the minimum synchronization time increases to 2N frames for that particular instance.
The synchronization R-ambles may also be used for neighborhood monitoring. An RS monitoring in frame A may monitor not only its parent RS/MR-BS, but also all the other RSs that transmit an R-amble in frame A. However, the group of RSs listening in the same frame, cannot monitor each other. For full monitoring of the neighborhood, the monitoring scheme included in 8.4.6.1.1.4.2 shall be used.
8.4.7 OFDMA ranging
Insert new subclause 8.4.7.5 as follows:
8.4.7.5 OFDMA ranging in an MR system
The OFDMA ranging methods defined in 8.4.7 for the SS and the BS shall be applicable for the RS and the MR-BS respectively, except the group of codes shall be between S and [(S + O + N + M + L +P + Q) mod 256].
— The first N + M + L + O codes produced are for regular ranging (see 8.4.7.3). Clock the PRBS generator 144 × (S mod 256) times to 144 × ((N + M + L + O + S) mod 256) – 1 times.
— The next P codes produced are for RS initial ranging. Clock the PRBS generator 144 × ((N + M + L + O + S) mod 256) times to 144 × ((P + N + M + L + O + S) mod 256) – 1 times.
— The next Q codes produced are for RS unique CDMA ranging. Clock the PRBS generator 144 × ((P + N + M + L + O + S) mod 256) times to 144 × ((Q + P + N + M + L + O + S) mod 256) – 1 times.
8.4.8 Space-Time Coding(STC) (optional)
8.4.8.1 STC using two antennas
8.4.8.1.5 UL using STC
Insert the following at the end of 8.4.8.1.5:
8.4.8.1.5.1 UL using STC in an MR system
For RS using three antennas, the MIMO coding matrices defined in 8.4.8.3.4 shall be mapped to the tile according to Figure 263a. One tile shall contain two MIMO coding matrices, i.e., S1 and S2, which can be A1, A2, A3, B1, B2, or B3 defined in 8.4.8.3.4. The elements of the two MIMO coding matrices should be mapped to tile according to Figure 263a, where S1
mn denotes the mth row nth column element of the first
Frame1A
Frame2B
Frame3C
Frame4 Frame5A
Frame6B
Frame7 Frame8 Frame9A
Frame10B
Frame11C
234 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
MIMO coding matrix and S2mn denotes the mth row nth column element of the second MIMO coding
matrix.
Figure 263a—Mapping of data subcarriers for 3-antenna RS
For RS using four antennas, the MIMO coding matrices defined in 8.4.8.3.5 shall be mapped to the tile according to Figure 263b. One tile shall contain two MIMO coding matrices, i.e., S1 and S2, which can be A1, A2, A3, B1, B2, B3, B4, B5, or B6 defined in 8.4.8.3.5. The elements of the two MIMO coding matrices shall be mapped to tile according to Figure 263b, where S1
mn denotes the mth row nth column element of the first MIMO coding matrix and S2
mn denotes the mth row nth column element of the second MIMO coding matrix.
Figure 263b—Mapping of data subcarriers for 4-antenna RS
Insert new subclause 8.4.8.8 as follows:
8.4.8.8 Cooperative relaying
Cooperative relaying can be achieved within an MR-cell using either an MR-BS and one or more RSs or multiple RSs transmitting in cooperation. These RSs are either transparent RSs or non-transparent RSs transmitting the same frame start preamble, FCH and MAPs, or non-transparent using a common
⎥⎥⎥
⎦
⎤
⎢⎢⎢
⎣
⎡
iiii
iiii
iiii
SSSSSSSSSSSS
34333231
24232221
14131211
Antenna 1(Pattern A)iS11
111
+iS
iS12
iS13
iS141
14+iS1
12+iS
113
+iS
iS211
21+iS
iS22
iS23
iS241
24+iS1
22+iS
123+iS
iS311
31+iS
iS32
iS33
iS341
34+iS1
32+iS
133+iS
S Data subcarrier
Null subcarrier
+ Pilot subcarrier
- Pilot subcarrier
Antenna 2(Pattern B) Antenna 3(Pattern C)
General MIMO coding matrix format for 3- antenna RS
⎥⎥⎥
⎦
⎤
⎢⎢⎢
⎣
⎡
iiii
iiii
iiii
SSSSSSSSSSSS
34333231
24232221
14131211
Antenna 1(Pattern A)iS11
111
+iS
iS12
iS13
iS141
14+iS1
12+iS
113
+iS
iS211
21+iS
iS22
iS23
iS241
24+iS1
22+iS
123+iS
iS311
31+iS
iS32
iS33
iS341
34+iS1
32+iS
133+iS
S Data subcarrier
Null subcarrier
+ Pilot subcarrier
- Pilot subcarrier
Antenna 2(Pattern B) Antenna 3(Pattern C)
General MIMO coding matrix format for 3- antenna RS
⎥⎥⎥⎥⎥
⎦
⎤
⎢⎢⎢⎢⎢
⎣
⎡
iiii
iiii
iiii
iiii
SSSSSSSSSSSSSSSS
44434241
34333231
24232221
14131211
Antenna 1(Pattern A)iS11
111
+iS
iS12
iS13
iS141
14+iS1
12+iS
113
+iS
iS211
21+iS
iS22
iS23
iS241
24+iS1
22+iS
123+iS
iS311
31+iS
iS32
iS33
iS341
34+iS1
32+iS
133+iS
S Data subcarrier
Null subcarrier
Pilot subcarrier
+ Pilot subcarrier
- Pilot subcarrier
Antenna 2(Pattern B) Antenna 3(Pattern C)
General MIMO coding matrix format for 4- antenna RS
iS411
41+iS
iS42
iS43
iS441
44+iS1
42+iS
143+iS
Antenna 4(Pattern D)
⎥⎥⎥⎥⎥
⎦
⎤
⎢⎢⎢⎢⎢
⎣
⎡
iiii
iiii
iiii
iiii
SSSSSSSSSSSSSSSS
44434241
34333231
24232221
14131211
Antenna 1(Pattern A)iS11
111
+iS
iS12
iS13
iS141
14+iS1
12+iS
113
+iS
iS211
21+iS
iS22
iS23
iS241
24+iS1
22+iS
123+iS
iS311
31+iS
iS32
iS33
iS341
34+iS1
32+iS
133+iS
S Data subcarrier
Null subcarrier
Pilot subcarrier
+ Pilot subcarrier
- Pilot subcarrier
Antenna 2(Pattern B) Antenna 3(Pattern C)
General MIMO coding matrix format for 4- antenna RS
iS411
41+iS
iS42
iS43
iS441
44+iS1
42+iS
143+iS
Antenna 4(Pattern D)
Copyright © 2009 IEEE. All rights reserved. 235
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
permutation zone during transmission. It is possible to achieve diversity by sending appropriately coded signals across different MR-BS and RS transmit antennas during the transmission of a burst to subordinate stations. The three modes of operation for cooperative relaying are cooperative source diversity, cooperative transmit diversity, and cooperative hybrid diversity.
For cooperative source diversity, the transmitting antennas simultaneously transmit the same signal using the same time-frequency resource. In cooperative transmit diversity mode, STC-encoded signals are transmitted across the transmitting antennas using the same time-frequency resource (refer to 8.4.8 for a list of valid STCs). Cooperative hybrid diversity is identical to cooperative transmit diversity except that at least one value for virtual antenna assignment is assigned to multiple physical antennas.
In a STC DL Zone with STC not set to “0b00”, the RS shall perform STC encoding locally by using the STC Matrix as defined by STC_DL_Zone_IE (or MIMO DL Basic IE or MIMO DL Enhanced IE or HARQ MAP) for its assigned antenna number(s) as indicated in RS_Config-CMD, and in the case of an incorrectly decoded burst, shall not transmit any data nor dedicated pilots, if any. The pilot patterns for each RS antenna shall be based on the permutation, the number of antennas as indicated in STC_DL_Zone_IE, and the antenna assignment. The antenna assignment shall be effective until the next RS_Config-CMD message that includes cooperative diversity configuration. Figure 282a is an example of local STC encoding at the RS, the STC Encoder is identical to the encoder in Figure 258 of 8.4.8.1.
In cooperative relaying, the frames sent by the MR-BS and RS at a given frame time shall arrive at the MS within the prefix interval, similar to MDHO.
Figure 282a—A logical block example of local STC Encoding at RS
8.4.9 Channel coding
Insert new subclause 8.4.9.4.3.3 as follows:
8.4.9.4.3.3 Relay amble pilot modulation
The pilots in the relay amble for 512 FFT, 1k FFT, and 2k FFT shall follow the instructions in 8.4.6.1.1.3 and shall be modulated according to Equation (129a)
(129a)
The pilots in the relay amble for 128 FFT shall follow the instructions in 8.4.6.1.1.3 and shall be modulated according to Equation (129b)
Subchannel Modulation
IFFT Input Packing
STC Encoder
IFFT Filter DAC RF
Cooperative STC Encoder
not used
Re AmblePilotsModulated{ } 4 2 12--- wk–⎝ ⎠⎛ ⎞=
Im AmblePilotsModulated{ } 0=
236 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
(129b)
8.4.10 Control mechanisms
Insert new subclause 8.4.10.4 as follows:
8.4.10.4 Power control in MR networks
A power control algorithm shall be supported in MR networks for the uplink channels from RSs and SSs with both an initial calibration and periodic adjustment procedure without loss of data. Power control of the RS downlink channels shall also be supported.
In the case of RSs operating in centralized scheduling mode, the UL power control algorithm shall be located in the MR-BS and the MR-BS shall control the transmit power on all uplink channels served by the MR-BS and its subordinate RSs. In the case of scheduling RSs, an UL power control algorithm shall be located in both the MR-BS and RSs to control the uplink channels it serves.
This subclause defines how the RS responds to power control messages from the MR-BS and how the MR-BS and RS control the transmit power in MR networks.
8.4.10.4.1 Power control of RS
The RS shall respond to UL power control messages from the MR-BS or RS in the same way an SS responds to power control messages, as specified in 8.4.10.3. The RS shall also be capable of receiving DL power control messages from the MR-BS or RS. DL power control messages define the DL transmit power that the RS shall use.
8.4.10.4.2 Power control of SS
In the case of RSs operating in centralized scheduling mode, the MR-BS shall generate the power control messages for the SS and transmit them to the SS via the RS. RSs shall have the capability to report the channel quality measurement information of their access-uplink channels to an MR-BS or superordinate RS. The MR-BS shall also be responsible for controlling the DL transmit power used at all subordinate RSs.
In the case of transparent RS, an RS may report UL noise and interference levels for the access link via REP-RSP message to its parent MR-BS. The MR-BS may set Offset_BS_perSS based on values in UL_NI-at-RS TLV for an MS attached to this RS to compensate the difference of EIRP and the difference of UL NI values between the MR-BS and the transparent RS.
In the case of scheduling RSs, the RS shall generate the power control messages for the SSs that it serves.
8.4.12 Channel quality measurements
Insert new subclause 8.4.12.5 as follows:
8.4.12.5 Channel quality measuring and reporting in an MR system
The channel quality measurement methods defined in 8.4.12 for the SS and the BS shall be applicable for the RS and the MR-BS, respectively.
Re AmblePilotsModulated{ } 3.55 2 12--- wk–⎝ ⎠⎛ ⎞=
Im AmblePilotsModulated{ } 0=
Copyright © 2009 IEEE. All rights reserved. 237
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
In a multihop relay system with RSs operating in centralized scheduling mode, an MR-BS may request an RS to report the CINR value of its subordinate RS/MSs by sending a REP-REQ message on the RS’s basic CID. The RS shall send a REP-RSP in response.
8.4.16 Optional HARQ support
8.4.16.3 UL ACK channel
Insert new subclause 8.4.16.3.1 as follows:
8.4.16.3.1 ACK / NAK handling for an MR system
When an MR-BS receives the ACK/NAK signal from an MS through an RS in RS assisted HARQ (see 6.3.16.4.2.2) the new sequences based on Table 548a are used. The RS notifies the status of the HARQ subburst at both the RS and the MS with the encoded ACK/NAK signal defined in the Table 548a. When the RS receives an ACK signal from the MS, then irrespective of whether the RS receives the HARQ subburst correctly or not, the RS replies with an ACK to the MR-BS.
The codes in Table 548a are used to identify the link on which an HARQ transmission attempt has failed; refer to 6.3.16.4.1.
For UL HARQ on a two-hop path, only C0 and C1 shall be used.
For DL HARQ on a two-hop path, only C0, C1, and C2 shall be used.
Table 548a—ACK/NAK Encoding for multihop relay for HARQ, with vector indices provided in Table 548
Link Distance/Depth ACK/NAK 1-bit symbol
Vector Indices per TileTile(0), Tile(1), Tile(2) Code#
Any Distance 0(ACK) 0,0,0 C0
1 1(NAK) 1,1,1 C1
2 1(NAK) 2,2,2 C2
3 1(NAK) 3,3,3 C3
4 1(NAK) 4,4,4 C4
5 1(NAK) 5,5,5 C5
6 1(NAK) 6,6,6 C6
7 1(NAK) 7,7,7 C7
238 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
9. Configuration
Insert new subclause 9.5:
9.5 RS configuration
After the measurement report from RS neighborhood discovery process, MR-BS may send an RS configuration command (RS_Config-CMD) message (6.3.2.3.63) to the RS for configuring the preamble segment and IDcell values. The RS sends an MR_Generic-ACK message to the MR-BS for responding with the preamble assignment result.
10. Parameters and constants
10.1 Global values
Change Table 554 as indicated as follows:
Table 554—Parameters and constants
System Name Time reference Minimumvalue
Defaultvalue
Maximumvalue
MR-BS T58 Time the MR-BS waits for MR_Generic-ACK from RS
— — 7 + 4 × (maximum hop count number of the MR system) (frames)
MR-BS T59 Time the MR-BS waits for DSA-RSP from RS
— — << T7
MR-BS, RS
T60 as trig-gered by CDMA code
Wait for MR_RNG-REP mes-sage from the subordinate RS triggering by receiving CDMA ranging code
— 6 frames <T3
MR-BS, RS
T60 as trig-gered by message
Wait for MR_RNG-REP mes-sage from the subordinate RS triggering by receiving MR_RNG-REP message
— T60 as triggering by CDMA code –TFD x ((FNRx – FNMsg) mod 256), where TFD : the frame duration, FNRx : the relevant frame number when receiving message,FNMsg : the frame number in the received message
<T3
MR-BS MR_SLP_INFO_retry_count
Number of retries on MR_SLP-INFO transmission
3 3 16
MR-BS T61 Waiting for ACK from RS for DCD/UCD messages
— — 300 msec
Copyright © 2009 IEEE. All rights reserved. 239
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
RS T62 The timer between RS sending an RS BR header to MR-BS and receiving the allocation for RNG-RSP
— — < T3
MR-BS T63 Maximum duration that BS shall wait to receive relayed RNG-REQ from its subordinate RSs after the paging retry count decrease to zero.
— — —
MR-BS T64 Wait for RS_NBR_MEAS-REP after sending REG-RSP to RS
300 msec 300 msec —
RS T65 Wait for DSA-REQ after receiv-ing RNG-RSP with Path-Addi-tion TLV or Path-CID-Binding-Update TLV
— — —
RS T66 Wait for RNG-RSP from MR-BS after relaying the received RNG-REQ from MS to MR-BS
— (default value of T3) - (RS processing time)
< T3
RS T67 as per-forming measure-ment report
Wait for RS_AccessRS-REQ or RS_Config-CMD after sending RS_NBR_MEAS-REP to MR-BS
— — 1 sec
RS T67 as skip-ping mea-surement report
Wait for RS_Config-CMD after receiving REG-RSP from MR-BS and RS shall skip neighbor measurement step
— — 300 msec
MR-BS T68 Wait for ACK after sending RS_Config-CMD to RS
— — 100 msec
RS T69 Time the RS waits for unsolic-ited RS_BW-Alloc_IE from MR-BS
— — < DCD/UCD inter-val
RS Lost R-MAP Inter-val
Time since last received R-MAP message before RL synchroni-zation is considered lost
— — 600 msec
MR-BS T70 Wait for RNG-REQ message after receiving ACK for RS_AccessRS-REQ message
— — 300 msec
RS T71 Time the RS sends an MR_RNG-REP after the RS detects one or more CDMA codes during contention-based initial ranging
— — < T60 as triggered by CDMA code
MR-BS, RS
T72 Time the egress station of a tun-nel waits for subsequent frag-ments of a TDU before discarding all the received frag-ments of the TDU
— — —
MR-BS T73 Wait for ACK after sending RS_AccessRS-REQ to RS
— — 100 msec
Table 554—Parameters and constants (continued)
System Name Time reference Minimumvalue
Defaultvalue
Maximumvalue
240 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
10.4 Well-known addresses and identifiers
Change Table 558 as indicated:
Table 558—CIDs
CID Value Description
Ranging CID 0x0000 Used by SS and BS during initial ranging process.
Basic or RS basic 0x0001 – m The same value is assigned to both the DL and UL connection.
Primary management or RS primary management
m+1 – 2m The same value is assigned to both the DL and UL connection.
Transport, Secondary Management, Tunnel or Management Tunnel, Multicast management CID
2m+1 – 0xFE9F For the secondary management connection, the same value is assigned to both the DL and UL connection. Tunnel CID is used for tunnel transport connections. Management Tunnel CID is used for tunnel manage-ment connections. Multicast management CID is used for the downlink multicast management services.
Multicast CIDs 0xFEA0 – 0xFEFE For the downlink multicast service, the same value is assigned to all MSs on the same channel that partici-pate in this connection.
AAS Initial Ranging 0xFEFF A BS supporting AAS shall use this CID when allocat-ing a an ASS AAS Initial Ranging period (using AAS Ranging Allocation IE).
Multicast Polling 0xFF00 – 0xFFF9 A BS may be included in one or more multicast polling groups for the purposes of obtaining bandwidth via polling. These connections have no associated service flow.
Normal Mode Multicast 0xFFFA Used in DL-MAP to denote bursts for transmission of DL broadcast information to normal mode MS.
Sleep Mode Multicast 0xFFFB Used in DL-MAP to denote bursts for transmission of DL broadcast information to Sleep mode MS. May also be used in MOB_TRF-IND messages.
Idle Mode Multicast 0xFFFC Used in DL-MAP to denote bursts for transmission of DL broadcast information to Idle mode MS. May also be used in MOB_PAG-ADV messages.
Fragmentable Broadcast 0xFFFD Used by the BS for transmission of management broadcast information with fragmentation. The frag-ment sub header shall use 11-bit FSN on this connec-tion.
Padding 0xFFFE Used for transmission of padding information by SS and BS.
Broadcast 0xFFFF Used for broadcast information that is transmitted on a DL to all SS.
Copyright © 2009 IEEE. All rights reserved. 241
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
11. TLV Encodings
11.1 Common encodings
Change Table 559 as indicated:
Table 559—Type values for common TLV encodings
11.1.2 Authentication tuples
11.1.2.1 HMAC tuple
Change Table 560 as indicated:
Type Name
126 Bi-directional service flow
125 Path ID
124 Path Addition
123 Path CID Binding Update
122 Path Info
121 SA-SZK-Update
120 DCD encodings
119 UCD encodings
Table 560—HMAC Tuple definition
Type Length Value Scope
149 21 See Table 561 DSx-REQ, DSx-RSP, DSx-ACK, REG-REQ, REG-RSP, RES-CMD, DREG-CMD, TFTP-CPLT, MOB_SLP-REQ, MOB_SLP-RSP, MOB_SCN-REQ, MOB_SCN-RSP, MOB_BSHO-REQ, MOB_MSHO-REQ, MOB_BSHO-RSP, MOB_HO-IND, DREG-REQ, MOB_MIH-MSGMR_NBR-INFO, RS_Config-CMD, RS_NBR_MEAS-REP, MS_SCN-INF, MS_SCN-CLT, MS_INFO-DEL, RCD, MR_ASC-REQ, MR_ASC-RSP, HARQ_CHASE_ER-REP, RS_AccessRS-REQ, RS-SCH, RS_Member_List_Update, MR_LOC-REQ, MR_LOC-RSP, RS_NBR_MEAS-REP, RS_MOB_MEAS-REQ, HARQ_IR_ER-REP, MR_SLP-INFO, MR_PBBR-INFO, MR_Generic-ACK, RS_Access-MAP, RS-Relay-MAP, MS_Context-REQ, MS_Context-RSP, MR_INF-IND, MT_Transfer
242 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
11.1.2.2 CMAC tuple
Change Table 562 as indicated:
Change Table 563 as indicated:
Table 562—CMAC Tuple
Type Length Value Scope
141 13 or 19 See Table 563 DSx-REQ, DSx-RSP, DSx-ACK, REG-REQ, REG-RSP, RES-CMD, DREG-CMD, TFTP-CPLT, MOB_SLP-REQ, MOB_SLP-RSP, MOB_SCN-REQ, MOB_SCN-RSP, MOB_BSHO-REQ, MOB_MSHO-REQ, MOB_BSHO-RSP, MOB_HO-IND, DREG-REQ, RNG-REQ, RNG-RSP, MOB_MIH-MSG, SBC-REQ, SBC-RSP, MOB_SCN-REP,MR_LOC-REQ, MR_LOC-RSP,MR_NBR-INFO, RS_Config-CMD, RS_NBR_MEAS-REP, MS_SCN-INF, MS_SCN-CLT, MS_INFO-DEL, RCD, MR_ASC-REQ, MR_ASC-RSP, MOB_RSSCN-RSP, HARQ_CHASE_ER-REP, STA-INFO, RS_AccessRS-REQ, RS-SCH, RS_Member_List_Update, RS_NBR_MEAS-REP, RS_MOB_MEAS-REQ, HARQ_IR_ER-REP, MR_SLP-INFO, MR_PBBR-INFO, MR_Generic-ACK, RS_Access-MAP, RS-Relay-MAP, MS_Context-REQ, MS_Context-RSP, MR_INF-IND, MT_Transfer
Table 563—CMAC Tuple definition
Field Length (bits) Note
Reserved 42 Set to 0
PN type 2 0b00 – CMAC_PN_* 0b01 – Security zone PN0b02 – Relay Link PN0b03 – reserved
When the tuple is sent to or by an SS, these bits shall be set to 0b00
Key Sequence Number 4 AK key sequence number
BSID 48 Only used in case of MDHO zone-optional
CMAC Packet Number Counter,CMAC_PN_*,CMAC_PN_SZ* orCMAC_PN_RL*
32 This context is different UL, DL
CMAC Value 64 CMAC with AES-128
Copyright © 2009 IEEE. All rights reserved. 243
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
11.1.2.3 Short-HMAC Tuple
Change Table 564 as indicated:
Change Table 565 as indicated:
11.1.3 MAC version encoding
Change the table in 11.1.3 as indicated:
Table 564—Short-HMAC Tuple
Type Length Value Scope
140 variable See Table 565 MOB_SLP-REQ, MOB_SLP-RSP, MOB_SCN-REQ, MOB_SCN-RSP, MOB_MSHO-REQ, MOB_BSHO-RSP, MOB_HO-IND, RNG-REQ, RNG-RSP, PKM-REQ, PKM-RSP, MR_LOC-REQ, MR_LOC-RSP
Table 565—Short-HMAC Tuple definition
Field Length (bits) Note
Reserved 42 Set to 0
PN type 2 0b00 – CMAC_PN_* 0b01 – Security zone PN0b10 – Relay Link PN0b11 – Reserved
When the tuple is sent to or by an SS, these bits shall be set to 0b00
HMAC Key Sequence Number 4 —
HMAC Packet Number CounterHMAC_PN_*,HMAC_PN_SZ* orHMAC_PN_RL*
32 Replay counter
Short-HMAC digest variable 0-Truncate HMAC to 8 bytes in Short HMAC Tuple1-Truncate to 10 bytes2-Truncate to 12 bytes
Type Length Value Scope
148 1 Version number of IEEE 802.16 supported on this channel.0: Reserved1–7: Indicates conformance with an earlier and/or obsoleteversion of IEEE Std 802.168: Indicates conformance with IEEE Std 802.16-20099: Indicates conformance with IEEE Std 802.16-2009 and IEEE Std 802.16j-2009910–255: Reserved
PMP:DCD, RNG-REQ
244 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
11.1.4 Service flow descriptors
Change the table in 11.1.4 as indicated:
Insert new subclause 11.1.13 and its related subclauses as follows:
11.1.13 Path management message encodings
The TLV encodings defined in this subclause are specific to the path management related MAC Management messages.
11.1.13.1 Path ID encoding
11.1.13.2 Path Addition TLV
Ordered List of RSsThe ordered list of RSs’ primary management CIDs along the path in the downstream direction. The upstream direction list can be obtained by reverse this ordered list.
Type Length Value Scope
126 variable Compound: Bi-directional service flow DSx-REQ, DSx-RSP, DSx-ACK
Type Length Value Scope
125 2 ID of path DSx-REQ,DSx-RSP, DSx-ACK
Name Type Length Value Scope
Path Addition 124 variable Path ID (unsigned 16-bit)Ordered list of RSs (variable)
DSA-REQ, RNG-RSP,SBC-RSP
Copyright © 2009 IEEE. All rights reserved. 245
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
11.1.13.3 Path CID Binding Update TLV
List of CIDs
A list of CIDs involved in the binding update operation.
11.1.13.4 Path Info TLV
Ordered List of RSs
The ordered list of RSs’ primary management CIDs along the path in the downstream direction. The upstream direction list can be obtained by reverse this ordered list.
Insert new subclause 11.1.14 as follows:
11.1.14 SA_SZK_Update tuple
Name Type Length Value Scope
Path CID Binding Update
123 variable Path ID (unsigned 16-bit)List of CIDs (variable)
DSA-REQ, DSD-REQ, RNG-RSP, SBC-RSP
Name Type Length Value Scope
Path Info 122 variable Ordered list of RSs DSA-REQ,DSC-REQ,DSD-REQ, RNG-RSP
Name Type Length Value Scope
SA-SZK-Update 121 variable See the following table PKM-RSP, REG-RSP
Field Length (bits) Note
SAID 16 Security zone Security Association Identifier
SZK-Parameters variable Security Zone Key related parameters
SZKEK-Parameters (optional) variable Security Zone Key Encryption Key related parameters
246 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Insert new subclause 11.1.15 as follows:
11.1.15 DCD and UCD contents
Table 567a—DCD encodings
Table 567b—UCD encodings
The Downlink_Burst_Profile/Uplink_Burst_Profile are compound TLV encodings that define, and associate with a particular DL interval usage code (DIUC)/ UL interval usage code (UIUC), the PHY characteristics that shall be used with that DIUC/UIUC. Within each Downlink_Burst_Profile/Uplink_Burst_Profile shall be an unordered list of PHY attributes, encoded as TLV values (see 11.4.2/11.3.1.1). Each interval is assigned a DIUC/UIUC by the R-MAP message. A Downlink_Burst_Profile shall be included for each DIUC/UIUC to be used in the R-MAP unless the PHY’s Downlink_Burst_Profile is explicitly known.
Name Type Length Value Scope
DCD encodings 120 variable See Table 567a RCD, RS_Config-CMD
UCD encodings 119 variable See Table 567b RCD, RS_Config-CMD
Field Length (bits) Note
Begin PHY-specific section { — See applicable PHY subclause
for(i=1;i<=n; i++){ — For each DL burst profile 1 to n
Downlink_Burst_Profile variable PHY-specific
} — —
} — —
TLV encodings information for the relay channel
variable DCD channel TLV encodings
Field Length (bits) Note
Begin PHY-specific section { — See applicable PHY subclause
for(i=1;i<=n; i++){ — For each UL burst profile 1 to n
Uplink_Burst_Profile variable PHY-specific
} — —
} — —
TLV encodings information for the relay channel
variable UCD channel TLV encodings
Copyright © 2009 IEEE. All rights reserved. 247
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
11.3 UCD management message encodings
Change Table 571 as indicated:
11.4 DCD management message encodings
Insert the following row into Table 575:
Table 571—UCD PHY-specific channel encodings—WirelessMAN-OFDMA
Name Type (1 byte) Length Value
(variable-length)
Start of ranging codesgroup
155 1 Indicates the starting number, S, of the group of codes used for this UL. If not specified, the default value shall be set to zero. All the ranging codes used on this UL will be between S and ((S+O+N+M+L+P+Q) mod 256) where
N is the number of initial ranging codesM is the number of periodic ranging codesL is the number of BR codesO is the number of HO ranging codesP is the number of RS initial ranging codesQ is the number of RS dedicated codes
The range of values is
RS Initial Ranging Code 219 1 Number of RS initial ranging CDMA codes. Possible val-ues are 0–255.
RS dedicated codes 220 1 Number of RS dedicated codes. Possible values are 0–255.
Table 575—DCD channel encodings
Name Type(1 byte) Length Value Scope
End-to-end metric 64 1 Bit 0–2: Hop count: Number of relay links between the station transmitting this value and the MR-BS.Bits 3–7: Reserved
OFDMA
0 S 255≤ ≤
248 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
11.6 RNG-RSP message encodings
Change Table 585 as indicated:
Insert new subclause 11.6.1 as follows:
Table 585—RNG-RSP message encodings
Name Type(1 byte) Length Value
(variable-length)PHY scope
RS network entry optimization
41 2 Bit 0: Omit SBC-REQ/RSP management messages if set to ‘1’Bit 1: Omit PKM Authentication phase except TEK phase if set to ‘1’.Bit 2: Omit PKM TEK creation phase if set to ‘1’.Bit 3: Omit REG-REQ/RSP management messages if set to ‘1’.Bit 4: Omit neighbor station measurement report if set to ‘1’.Bit 5: Omit access station selection phase if set to ‘1’Bit 6: Omit relay station operational parameter configuration if set to ‘1’Bit 7: Omit tunnel connection re-establishment if set to ‘1’Bit 8–15: reserved.
OFDMA MR
RS CDMA Codes 42 variable The first byte, CDMA Code Index, indicates which RS CDMA code is present in the TLV.
Bit 0: Ranging Response for SSBit 1: Forward a Bandwidth Request Message
from RSBit 2: Ranging Response for RSBit 3: Forward a 6-byte header from RSBit 4: Resource Request for HARQ Error
Report(UL)Bit 5: Dedicated periodic ranging code
The subsequent bytes carry one byte ranging code for each of the bit set in the above bitmap and in the following order:
Ranging Response for SS Forward a Bandwidth Request Message from RS Ranging Response for RS Forward a 6-byte header from RS Resource Request for HARQ Error Report(UL)Dedicated periodic ranging code
OFDMA MR
Number of accepted SSs
43 1 Bit 0–3: Number of accepted new entry SSBit 4–7: Number of accepted handover SS
OFDMA MR
Association info 44 2 Bit 0–7: MS CINR meanBit 8–15: MS RSSI mean
OFDMA MR
Copyright © 2009 IEEE. All rights reserved. 249
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
11.6.1 CID list
The CID List carries a list of the CIDs of the MSs attached to an MRS or the tunnels between an MRS and the MR-BS. It provides a mapping between old CID (assigned by the old MR-BS) and new CID (assigned by the new MR-BS).
11.7 REG-REQ/RSP management message encodings
Insert new subclause 11.7.25 as follows:
11.7.25 MR-BS and RS MAC feature support
This TLV indicates the MR system features supported by the RS and the MR-BS.
The RS indicates which features it can support by using this TLV and setting the appropriate bits to 1. The MR-BS uses this TLV to indicate which of the RSs capabilities may be used and thus sets the appropriate mode of operation at the RS. An RS can set any combination of bits in the REG-REQ message.
If bit 1 is set to 1, then the RS can be an MRS. If bit 2 is set to 0, the RS cannot be an intermediate RS.
An RS sets bit 5 to 0 to indicate that it cannot perform DL flow control and to 1 to indicate that it can perform DL flow control. The MR-BS sets bit 5 to 0 to indicate that DL flow control shall not be performed and to 1 to indicate that DL flow control shall be performed.
Type(1 byte) Length Value
(variable-length)
45 variable See the following table
Field Length Note
Number of CIDS
2 bytes The next two fields shall be repeated Number of CID times
Old CID 2 bytes
New CID 2 bytes
Type Length Value Scope
52 2 Bit 0: NBR-ADV generating supportBit 1: RS mobility support Bit 2: Subordinate RS network entry support Bit 3: Location supportBit 4: Multicast management supportBit 5: DL flow controlBit 6: MOB_SLP-RSP supportBit 7: MOB_SCN-RSP supportBit 8: DSx supportBit 9–15: Reserved
REG-REQ REG-RSP
250 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
In a REG-REQ message bits 6, 7, and 8 are only applicable for an RS that is indicating in the RS MAC feature support TLV that it can operate in distributed security mode. Bit 6, 7, and 8 shall only be set to 1 in a REQ-RSP message if the RS is to be configured in distributed security mode in the RS_Config-CMD message. In this case, setting bit 6 to 1 is used to indicate that the RS shall get MS sleep information from the MOB_SLP-RSP message, otherwise it shall get it from an MR_SLP-INFO message.
Setting bit 7 to 1 is used to indicate that the RS shall get scan information from the MOB_SCN-RSP message, otherwise it shall get it from an MS_SCN-INF message.
Setting bit 8 to 1, is used to indicate that the RS in a two-hop system shall directly get SF parameters from the DSx messages exchanged between the MR-BS and an SS.
11.7.25.1 RS MAC feature support
This TLV indicates the RS MAC features supported by the RS.
The scheduling mode, security mode, local CID allocation mode, path management mode, tunnel mode, ARQ mode, superordinate RS of an RS group are set by the RS_Config-CMD message.
11.7.25.2 MR MAC header and extended subheader support
When bit 3 is set in the REG-RSP message, the RS shall use the MR Acknowledgement header instead of the MR_Generic-ACK message where both options are available for the message being acknowledged.
Type Length Value Scope
53 2 Bit 0: Centralized scheduling mode supportBit 1: Distributed scheduling mode supportBit 2: Centralized security supportBit 3: Distributed security supportBit 4: Local CID allocation supportBit 5: Embedded path management supportBit 6: Explicit path management supportBit 7: Tunnel mode supportBit 8: End-to-end ARQ supportBit 9: Two-link ARQ supportBit 10: Hop-by-hop ARQ supportBit 11: Superordinate RS of an RS group supportBits 12–15: Reserved
REG-REQ
Type Length Value Scope
54 1 Bit 0: Relay MAC headerBit 1: RS BR headerBit 2: RS UL_DCH signaling headerBit 3: MR Acknowledgement headerBit 4: MR HARQ error report headerBit 5: MR Code-REP headerBit 6: QoS subheaderBit 7: Reserved
REG-REQ, REG-RSP
Copyright © 2009 IEEE. All rights reserved. 251
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
If Tunnel mode in MR-BS and RS MAC feature support (11.7.25) is set to 0, then QoS subheader shall not be set to 1. If Tunnel mode in MR-BS and RS MAC feature support (11.7.25) is set to 1 and QoS subheader is set to 0, then Tunnel service flows (6.3.14.10.1) is used.
11.8 SBC-REQ/RSP management message encodings
11.8.3 Physical parameters supported
11.8.3.5 WirelessMAN-OFDMA specific parameters
Insert new subclause 11.8.3.5.20 as follows:
11.8.3.5.20 RS maximum downlink transmit power
The RS shall inform the MR-BS of the maximum EIRP that can be supported on the frame start preamble during network entry. The maximum EIRP parameters are reported in dBm and quantized in 1 dB steps ranging from –128 dBm (encoded 0x00) to 127 dBm (encoded 0xFF). Values outside this range shall be assigned the closest extreme.
Insert new subclause 11.8.3.5.21 as follows:
11.8.3.5.21 MR PHY feature support
This TLV indicates the MR PHY features supported by the RS and the MR-BS.
If the RS supports transmission and reception to and from subordinate station(s) on a different carrier fre-quency to that used for transmission and reception to and from the superordinate station, bit 4 shall be set to 1; otherwise it shall be set to 0. Bit 4 can only be set to 1 if bit 0 is set to 1.
Type Length Value Scope
206 1 RS EIRP SBC-REQ
Type Length Value Scope
207 1 Bit 0: access zone preamble transmission support Bit 1: MBS Data Synchronization with pre-defined relative trans-mission time (6.3.23.3)Bit 2: MBS data synchronization with target transmission time (6.3.23.3)Bit 3: cooperative relay supportBit 4: support of a second carrier frequency at RS (see 8.4.4.7.2.2)Bit 5: support STR RS operation (see 8.4.4.7.2.3)Bits 6–9: Maximum number of HARQ channels supported in UL_DCHBit 10: FDD support in access linkBit 11: H-FDD support in access linkBit 12: FDD support in relay linkBit 13: H-FDD support in relay linkBit 14–15: Reserved
SBC-REQSBC-RSP
252 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
If RS supports STR and TTR, bit 5 shall be set to 1. If RS only supports TTR, bit 5 shall be set to 0.
Bit 5 can only be set to 1 if bits 0 is set to 1.
Insert new subclause 11.8.3.5.22 as follows:
11.8.3.5.22 OFDMA RS MIMO relay uplink support
This field indicates the different MIMO options supported by an RS in the relay uplink when the RS has three or four transmit antennas. A bit value of 0 indicates “not supported,” while 1 indicates “supported.” The TLV field defined in 11.8.3.6.5 shall be used when RS has one or two transmit antennas. In the following TLV field, all the STFC matrices are reused from downlink. The detailed matrix formats are shown in 8.4.8.3.3, 8.4.8.3.4, and 8.4.8.3.5.
Insert new subclause 11.8.3.5.23 as follows:
11.8.3.5.23 OFDMA RS downlink STC encoding support
This field indicates the different STC encoding capabilities by an RS in the downlink. Bits 12 and 13 indicate the number of physical transmit antennas. For all other bits, a bit value of 0 indicates “not supported,” while 1 indicates “supported.” An RS may have STC encoding capabilities that exceed its number of transmit antennas for the purpose of cooperative relay.
Type Length Value Scope
208 2 Bit 0: 3-antenna STFC matrix A Bit 1: 3-antenna STFC matrix B, vertical coding Bit 2: 3-antenna STFC matrix C, vertical coding Bit 3: 3-antenna STFC matrix C, horizontal coding Bit 4: 4-antenna STFC matrix A Bit 5: 4-antenna STFC matrix B, vertical coding Bit 6: 4-antenna STFC matrix B, horizontal coding Bit 7: 4-antenna STFC matrix C, vertical coding Bit 8: 4-antenna STFC matrix C, horizontal coding Bit 9: Capable of antenna selection Bit 10: Capable of antenna grouping Bit 11–15: Reserved
SBC-REQ (see 6.3.2.3.23)
SBC-RSP (see 6.3.2.3.24)
Type Length Value Scope
209 2 Bit 0: 2-antenna STC matrix ABit 1: 2-antenna STC matrix B, vertical codingBit 2: 2-antenna STC matrix B, horizontal codingBit 3: 4-antenna STC matrix ABit 4: 4-antenna STC matrix B, vertical codingBit 5: 4-antenna STC matrix B, horizontal codingBit 6: 4-antenna STC matrix C, vertical codingBit 7: 4-antenna STC matrix C, horizontal codingBit 8: 3-antenna STC matrix ABit 9: 3-antenna STC matrix BBit 10: 3-antenna STC matrix C, vertical codingBit 11: 3-antenna STC matrix C, horizontal codingBits 12 and 13: Number of RS transmit antennas, less oneBit 14–15: Reserved
SBC-REQ (see 6.3.2.3.23)
SBC-RSP (see 6.3.2.3.24)
Copyright © 2009 IEEE. All rights reserved. 253
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Insert new subclause 11.8.3.5.24 as follows:
11.8.3.5.24 Supported second RS carrier configurations
Three TLVs are defined in this subclause to enable the RS to indicate the different second carrier configurations supported. Two of these TLVs enable the supported band configurations to be indicated and the third the minimum separation required between the carrier frequencies used by the RS.
If “support of a second carrier frequency at RS” is indicated in the MR PHY feature support TLV then either one or both of the first two TLVs defined in this subclause shall be present in the SBC-REQ message as well as the third minimum carrier frequency separation TLV.
The following field enables an RS to indicate the predefined second carrier configurations supported by the RS.
Type Length Value Scope
210 3 Bit 0: support band 1Bit 1: support band 2Bit 2: support band 3Bit 3: support band 4Bit 4: support band 5Bit 5: support band 6Bit 6: support band 7Bit 7: support band 8Bit 8: support band 9Bit 9: support band 10Bit 10: support band 11Bit 11: support band 12Bit 12: support band 13Bit 13: support band 14Bit 14: support band 15Bit 15: support band 16Bit 16: support band 17Bit 17: support band 18Bit 18: support band 19Bit 19: support band 20Bits 20–23: Reserved
SBC-REQ (see 6.3.2.3.23)
254 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
The following table defines each of the bands referred to in the table above.
Band number Start frequency (kHz) Bandwidth
(kHz)
Centre frequency step (kHz)
Number of steps in band FFT size
1 2304500 8750 250 364 1024
2 2302500 5000 250 380 512
3 2305000 10000 250 360 1024
4 2306750 and 2346750 3500 250 46 512
5 2307500 and 2347500 5000 250 40 512
6 2310000 and 2350000 10000 250 20 1024
7 2498500 5000 250 756 512
8 2501000 10000 250 736 1024
9 3302500 5000 250 380 512
10 3303500 7000 250 372 1024
11 3305000 10000 250 360 1024
12 3402500 5000 250 780 512
13 3403500 7000 250 772 1024
14 3405000 10000 250 760 1024
15 3602500 5000 250 780 512
16 3603500 7000 250 772 1024
17 3605000 10000 250 760 1024
18 3402500 5000 250 1580 512
19 3403500 7000 250 1572 1024
20 3405000 10000 250 1560 1024
Copyright © 2009 IEEE. All rights reserved. 255
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
In addition to the TLV defined in the previous table, the following field enables support of other undefined bands to be indicated by the RS.
FstartFirst center frequency in the band in units of kHz.
Channel bandwidthBandwidth of each channel in the band in units of kHz.
Center frequency stepCenter frequency step size in units of kHz.
Number of steps in the bandNumber of center frequency steps in the band.
FFT sizeFFT size supported in the band. 0b00 = 128 point FFT; 0b01 = 512 point FFT; 0b10 = 1024 point FFT; 0b11 = 2048 point FFT.
The following field enables the RS to indicate the minimum carrier frequency separation between the carrier frequency being used by the superordinate station and the carrier frequency that shall be used by the RS to communicate with subordinate station(s). The superordinate station shall not assign a second carrier frequency that results in a smaller spacing than that indicated.
Insert new subclause 11.8.3.5.25 as follows:
11.8.3.5.25 Direct Relay Zone for RS
This TLV shall be used to indicate the capability of Direct Relaying Zone as specified in 11.24.6.
Type Length Value Scope
211 variable Number of bands (8 bits)for (i=0;i<Number of bands; i++) {
Fstart (24 bits)Channel bandwidth (15 bits)Centre frequency step (11 bits)Number of steps in the band (14 bits)FFT size (2 bits)Reserved (6 bits)
}
SBC-REQ
Type Length Value Scope
212 3 Minimum carrier frequency separation (units of kHz)
SBC-REQ
Type Length Value Scope
213 1 When Bit0 =1, RS is capable of using the direct relay Zone.Bit 1~Bit 7: Reserved
SBC-REQ, SBC-RSP
256 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Insert new subclause 11.8.3.5.26 as follows:
11.8.3.5.26 MR-cell carrier configuration
This TLV may be used for a STR RS to perform neighbor station measurement report during network entry.
Insert new subclause 11.8.3.5.27 as follows:
11.8.3.5.27 RSRTG
This TLV shall be used to indicate the RSRTG of the RS.
Insert new subclause 11.8.3.5.28 as follows:
11.8.3.5.28 RSTTG
These TLVs shall be used to indicate the RSTTG of the RS.
Insert new subclauses 11.8.17 to 11.8.21 as follows:
11.8.17 Relay data early arrival report threshold
When MBS data synchronization with target transmission time is supported, this TLV defines the threshold used by RS to determine when to send Access Link Transmission Status feedback header when one or more MAC PDUs arrives at the RS too early. When the threshold is included, the RS shall send Access Link Transmission Status feedback header to MR-BS when one or more MAC PDU arrives at the RS earlier than
Type Length Value Scope
214 variable Number of carrier (8 bits) for(i=0;i<Number of bands; i++){ carrier center frequency in kHz (24 bits) channel bandwidth in kHz (16 bits) FFT size (2 bits) Reserved (6 bits) }
SBC-RSP
Type Length Value Scope
215 1 RSRTG in µs SBC-REQ/RSP
Type Length Value Scope
216 1 RSTTG in µs SBC-REQ/RSP
Copyright © 2009 IEEE. All rights reserved. 257
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
the threshold to the target transmission time. When the threshold is set to 0 or if this TLV is not included, the RS shall disable the early arrival reporting.
11.8.18 RS downlink processing delay
The RS downlink processing delay TLV indicates the time delay for an RS to forward timing-related messages such as MOB_PAG-ADV, MOB_TRF-IND to its subordinate RS or MS. When MBS data synchronization with pre-defined relative transmission time is supported, it also indicates the time delay for RS to forward MBS MAP message and MBS data burst. The value is defined as a maximum fixed delay, when the RS receives such timing-related messages or data over the relay link, it shall forward them after this delay time.
The RS downlink processing delay for MBS TLV is used to report the time delay for an RS to forward MBS data burst to its subordinate RS when MBS data synchronization with target transmission time is supported. RS downlink processing delay is defined as the minimum time duration an RS requires to transmit the MBS data upon receiving of the data without any queuing delay.
11.8.19 Minimum RS forwarding delay in direct relay zone TLV
The minimum RS forwarding delay in direct relay zone TLV indicates the delay between an RS receiving and forwarding a data burst when operating in centralized scheduling mode with direct relay zone.
Type Length Value Scope
217 1 In frames.When set to 0, the RS shall not send any Access Link Transmission Status feedback header to MR-BS.
SBC-RSP
Type Length Value Scope
218 1 RS Downlink Processing Delay for MBS (unit: frame) SBC-REQ
219 1 RS Downlink Processing Delay (unit: frame) SBC-REQ
Type Length Value Scope
220 1 RS forwarding delay in DL direct relay zone(unit: OFDMA symbols)
SBC-REQ
221 1 RS forwarding delay in UL direct relay zone(unit: OFDMA symbols)
SBC-REQ
258 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
11.8.20 Minimum RS forwarding delay TLV
The minimum RS forwarding delay TLV indicates the minimum delay between an RS receiving and forwarding a MAC PDU when operating in centralized scheduling mode.
11.8.21 Station information
11.9 PKM-REQ/RSP management message encodings
Insert new subclauses 11.9.40 to 11.9.42 as follows:
11.9.40 AK-Parameters
This attribute is a compound attribute, consisting of a collection of sub-attributes. These sub-attributes represent all the security parameters relevant to a particular Authorization key of MS or RS.
Type Length Value Scope
222 1 RS forwarding delay in DL SBC-REQ
223 1 RS forwarding delay in UL SBC-REQ
Name Type Length Value Scope
Station information 224 10 Bit 0–47: SS MAC addressBit 48–63: SS basic CIDBit 64–79: SS primary management CID
SBC-REQ, SBC-RSP
Type Length Value
50 variable The compound field contains the sub-attributes as defined in Table 604a.
Table 604a—AK-Parameters definition
Field Length(bits) Notes
AK 160 MS/RS’s authorization key
AK Sequence Number 8 MS/RS’s AK sequence number
AK Lifetime — MS/RS’s AK remaining lifetime
Copyright © 2009 IEEE. All rights reserved. 259
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
11.9.41 SZK-Parameters
This attribute is a compound attribute, consisting of a collection of sub-attributes. These sub-attributes represent all the security parameters relevant to a particular generation of SZK.
11.9.42 SZKEK-Parameters
This attribute is a compound attribute, consisting of a collection of sub-attributes. These sub-attributes represent all the security parameters relevant to a particular generation of SAID for encrypting SZK.
SZKEK remaining lifetime is an integer n, which corresponds to a number of remaining SZK updates under this SZKEK.
Type Length Value
51 variable The compound field contains the sub-attributes as defined in the Table 604b.
Table 604b—SZK-Parameters definition
Field Length (bits) Notes
SZK variable Security Zone Key encrypted with KEK derived from AK
SZK Sequence Number 4 SZK Sequence Number
Type Length Value
52 variable The compound field contains the sub-attributes as defined in the Table 604c.
Table 604c—SZKEK-Parameters definition
Field Length (bits) Notes
SZKEK 128 Security Zone Key Encryption Key
SZKEK Sequence Number
8 SZKEK Sequence Number
SZKEK Lifetime — SZKEK remaining lifetime
260 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
11.11 REP-REQ management message encodings
Insert the following table and text at the end of 11.11:
The RS sounding Report period TLV indicates the period of measurement in the unit of frame number. After this period, the RSs in the RS_interference_measurement group shall report to the MR-BS the related measurement results (implementation specific). TLV of RS Sounding Zone-specific CINR requested is needed only when RSs are requested to report CINR measurements (implementation specific); TLV of RS Sounding Zone-specific RSSI requested is needed only when RSs are requested to report RSSI measurements (implementation specific).
When an RS receives a REP-REQ with the TLV of Vector of Stations (type 1.14), it shall report the UL CQI measurement for those stations. The Type of UL CQI measurement shall be specified by the TLV of Type of UL CQI Measurement.
Name Type Length Value
RS sounding Report period 1.10 1 RS sends REP-RSP after the number of frames since receiving the REP-REQ
Start Frame Number 1.11 1 8 LSB bits of the frame number to synchronize the sounding opportunity
RS Sounding Zone-specific CINR request
1.12 1 Bits 0–3: averaging parameter in multiples of 1/16 (range is [1/16,16/16]). Bits 4–7: Reserved, shall be set to zero
RS Sounding Zone-specific RSSI request
1.13 1 Bit 0: Type of zone on which RSSI is to be reported 0: RS reports RSSI on all subcarriers 1: RS reports RSSI on the sub-carriers allocated in the Sound zone allocation IE
Vector of Stations 1.14 2N Basic CIDs of the N reported stations
Type of UL CQI Measurement
1.15 1 Bit 0: 1 = Physical CINR Bit 1: 1 = Effective CINR Bit 2–5: Average Alpha in multiples of 1/32 (range [1/32, 16/32]) Bit 6: 0 = Report the CINR measurement on Pilot subcarriers; 1 = Report the CINR measurement on Data subcarriers Bit 7: Reserved
Copyright © 2009 IEEE. All rights reserved. 261
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
11.12 REP-RSP management message encodings
Insert the following rows into the third table in subclause 11.12 as indicated:
Insert the following text after the third table in subclause 11.12:
When an RS received an REP-REQ with the TLV of Channel type request equal to 0b11, it shall respond to the MR-BS with an REP-RSP with TLVs of Sound reports (type 2.25 or 2.26) after measuring RS or MS sounding signals. The reporting time is indicated in REP-REQ. A vector of N measurement results of all participating RSs is reported by each RS. Moreover, an RS reports CINR or RSSI or both information dependent on whether the corresponding TLV (type 1.12 or 1.13) appears in REP-REQ. The CINR or RSSI report shall be measured on the UL sounding.
When an RS receives a REP-REQ with the TLV of Vector of Stations (type 1.14), it shall respond to the MR-BS with a REP-RSP with TLVs of type 2.27 and 2.28.
Insert the following text at the end of subclause 11.12:
An R-Link TLV may optionally be included in the REP-RSP message to report CQI information for relay links.
The proposed R-Link TLV format is as follows. The frame start preamble is defined as an 8-bit integer. Similar convention is used to index the Relay-amble. Direction is specified as two bits.
REP-REQchannel type
requestName Type Length Value
Channel Type = 11 Vector of neighbor stations
2.24 2N Basic CIDs of the N reported stations
Channel Type = 11 UL Sounding CINR Report
2.25 N CINR for each of the N RS or MS UL sounding signal in the sounding zone
Channel Type = 11 UL Sounding RSSI Report
2.26 N RSSI for each of the N RS or MS UL sounding signal in the sounding zone
Channel Type = 00 Vector of stations 2.27 2N Basic CIDs of the N reported stations
Channel Type = 00 UL CINR Report 2.28 N UL CINR for each of the N RS or MS
Name Type Length Value
R-Link 7 2 bytes 16-bit Integer
262 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
An Access-Link may be optionally included in the REP-RSP message to report DL CQI information for access links. The Access-Link TLV format is as follows. MS CID specifies the identity of the MS for which the measurements are reported. Relay amble index is used to index the DL MS channel measurements.
11.13 Service flow management encodings
Insert a new row at the end of the Table 607 in 11.13 as indicated:
11.13.1 SFID
Insert the following at the beginning of 11.13.1:
The CC = “Ok/success” and CC = “reject-other” can also be used as the confirmation code to confirm the path management operation as defined in subclause 6.3.2.3.11, 6.3.2.3.14, and 6.3.2.3.17.
Syntax Size(bits)
Notes
R-Link{ — —
Direction 2 0b00 = Reserved 0b01 = Uplink 0b10 = Downlink 0b11 = Neighbor measurement
Reserved 6
Source 8 Relay amble index
} — —
Syntax Type Length Notes
Access-Link{ — — —
CID 8.1 2 CID of MS being reported
Source 8.2 N Relay amble indices for which measurements are reported
DL CINR Report 8.3 N CINR report for each relay index
DL SINR Report 8.4 N SINR report for each relay index
} — — —
Table 607—CC values
CC Status
18 reject-RS-not-supported-parameter-value
Copyright © 2009 IEEE. All rights reserved. 263
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
11.13.2 CID
Change the table in 11.13.2 as indicated:
11.13.4 QoS parameter set type
Change the table in 11.13.4 as indicated:
Insert the text in the paragraph after the table in 11.13.4 as indicated:
A BS shall handle a single update to each of the Active and Admitted QoS parameter sets. The ability to process multiple service flow encodings that specify the same QoS parameter set is not required and is left as a vendor-specific function. If a DSA/DSC contains multiple updates to a single QoS parameter set and the vendor does not support such updates, then the BS shall reply with CC 2 (reject-unrecognized-configuration-setting). The Acceptable QoS parameter set may be used for indicating QoS parameters the RS can support when the RS cannot support some of the requested QoS parameters. The QoS parameters appeared in the requested QoS parameter set but not in the acceptable QoS parameter set are by default support by the RS. The requested QoS parameter set is one of Provisioned set, Admitted set, or Active set.
11.13.34 PDU SN extended subheader for HARQ reordering
Change the first paragraph of 11.13.34 as indicated:
This TLV is valid only in HARQ enabled connections. It specifies whether PDU SN extended subheader should be applied by the transmitter on every PDU on this connection. The PDU can be a relay MAC PDU constructed in tunnel mode. This SN may be used by the receiver to ensure PDU ordering.
Type Length Value Scope
[145/146].2
2 CID, T-CID, MT-CID DSx-REQDSx-RSPDSx-ACK
Type Length Value Scope
[145/146].5 1 Bit 0: Provisioned SetBit 1: Admitted SetBit 2: Active SetBit 3: Acceptable SetBit 34–7: Reserved
DSx-REQDSx-RSPDSx-ACK
264 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Insert new subclauses 11.13.43 to 11.13.45 as follows:
11.13.43 Per-RS QoS
The following TLV values shall appear in each Per-RS QoS TLV:
The value of Maximum Latency for the RS specifies the maximum interval between the reception of an MAC PDU at the RS’s Air Interface that is receiving the MAC PDU and the Air Interface that is forwarding the MAC PDU.
11.13.44 CIDs added into tunnel TLV
This field contains a compound attribute whose attributes identify the CIDs to be added into a tunnel and the number of CIDs included as listed in Table 608a.
Name Type(1 byte)
Length(1 byte) Value Scope
Per-RS QoS [145/146].54 variable Compound DSA-REQ/RSPDSC-REQ/RSP
Name Type(1 byte)
Length(1 byte) Value
RS_Basic_CID 54.1 2 RS Basic CID
Maximum Latency for the RS
54.2 4 Milliseconds
Type Length Value Scope
[145/146].55 variable Compound DSA-REQ, DSC-REQ
Table 608a—CIDs added into tunnel sub-attributes
Attribute Content
Number of CIDs The number of CIDs to be added into a tunnel
List of CIDs A list of CIDs to be added into a tunnel
Copyright © 2009 IEEE. All rights reserved. 265
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
11.13.45 CIDs removed from tunnel TLV
This field contains a compound attribute whose attributes identify the CIDs to be removed from a tunnel and the number of CIDs included as listed in Table 608b.
11.15 HO management encodings
Insert new subclause 11.15.4 as follows:
11.15.4 Preamble index
This TLV is used for re-assignment of the preamble during the MRS handover.
11.17 MOB_PAG-ADV management message encodings
Insert new subclause 11.17.3 as follows:
11.17.3 RS transmit frame number
The RS transmit frame number indicates the frame number at which RS shall transmit the message to MS while removing this TLV. When an RS receive MOB_PAG-ADV including this TLV, the RS shall restructure and transmit MOB_PAG-ADV by extracting this TLV and updating the length field at the frame number as specified by this TLV.
Type Length Value Scope
[145/146].56 variable Compound DSC-REQ
Table 608b—CIDs removed from tunnel sub-attributes
Attribute Content
Number of CIDs The number of CIDs to be removed from a tunnel
List of CIDs A list of CIDs to be removed from a tunnel
Name Type Length Value Scope
Preamble Index 150 1 A preamble index assigned to the MRS at the target MR-BS
MOB_BSHO-REQ, MOB_BSHO-RSP
Type Length Value Scope
154 1 byte Unsigned integer for LSB 8 bit of frame number at which RS shall transmit.
MOB_PAG-ADV
266 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Insert new subclause 11.17.4 as follows:
11.17.4 Paging interval
The “Paging Interval” field indicates the assigned paging listening interval for each MS that is paged.
Insert new subclause 11.22 as follows:
11.22 RS_NBR_MEAS-REP message encoding
11.22.1 Preamble index with least signal strength
The preamble index shall be included in the ascending order of its received signal strength at the RS.
Insert new subclause 11.23 as follows:
11.23 MR_NBR-INFO management message encoding
Type Length Value Scope
155 variable;Num_MACs*24
Subsequent (Num_MACs × 24) bits:For(i=0;i<Num_MACs; i++){16 bits - PAGING CYCLE for the paged MS.8 bits - PAGING OFFSET for the paged MS.}
MOB_PAG-ADV(On a Relay Link)
Type Length Value Scope
1 variable b0–b7: num_preambles for (i = 0; i<num_preamble;i++) { preamble index (8 bits) }
RS_NBR_MEAS-REP
Name Type(1 byte) Length (bytes) Scope
DCD Configuration Change count 1 1 MR_NBR-INFO
UCD Configuration Change count 2 1
DCD settings 3 variable
UCD settings 4 variable
PHY Mode ID 5 2
Copyright © 2009 IEEE. All rights reserved. 267
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Insert new subclause 11.24 as follows:
11.24 R-link channel descriptor (RCD) TLV encoding
11.24.1 Generic channel description
This field may be used by an MR-BS to configure one or all RSs.
Name Type Length Value Scope
Ranging Region for operational RS
1 5/10/15/20
The value of TLV consists of up to 4 concatenated sections (one section per Ranging method), each having the follow-ing structure:Bit 0~31, Contains the following fields to describe ranging region: OFDMA symbol offset (8 bits), Subchannel offset (7 bits), No. OFDMA symbols (7 bits), No. subchannels (7 bits), Ranging method (2 bits), Dedicated ranging indicator = ‘0’Bit 31~34, Parameter d that defines periodicity of 2d framesBit 35~39, Allocation phase expressed in frames
RCD
HARQ Ack Region for oper-ational RS
2 4 Bit 0~23, Contains the following fields as in the HARQ ACKCH region allocation IE: OFDMA Symbol offset (8 bits), Subchannel offset (7 bits), No. OFDMA symbols (5 bits), No. subchannels (4 bits)Bit 32~34, Parameter d that defines periodicity of 2d framesBit 35~39, Allocation phase expressed in frames
RCD
Fast Feedback Region for operational RS
3 5 Bit 0~31, Contains the following fields as in the FAST FEEDBACK Allocation IE: OFDMA symbol offset (8 bits), Subchannel offset (7 bits), No. OFDMA symbols (7 bits), No subchannels (7 bits), Reserved (3 bits)Bit 32~34, Parameter d that defines periodicity of 2d framesBit 35~39, Allocation phase expressed in frames
RCD
Sounding Region for oper-ational RS
4 5/10 For 5 bytes per each sounding regionBit 0~31, Contains the following fields as in the PAPR reduction/Safety zone/Sounding zone allocation IE:OFDMA symbol offset (8 bits), Subchannel offset (7 bits), No. OFDMA symbols (7 bits), No. subchannels (7 bits), PAPR Reduction/Safety Zone (1 bit), Sounding Zone bit = ‘0’, Reserved (1 bit)Bit 32~34, Parameter d that defines periodicity of 2d framesBit 35~39, Allocation phase expressed in frames
RCD
HARQ UL burst ACK delay for operational RS
5 1 1 = 1 frame offset2 = 2 frames offset3 = 3 frames offset
RCD
HARQ DL burst delay for opera-tional RS
6 1 = 1 frame offset2 = 2 frames offset3 = 3 frames offset
RCD
Relay UL alloca-tion start time for operational RS
7 Indicates the effective start time of the uplink allocation defined by the R-MAP on R-link
RCD
UL relay zone configuration action frame
8 1 Indicates the effective action frame of the UL relay zone configuration by the R-MAP on R-link
268 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Relay UL allocation start timeUL allocation start time indicates the effective start time of the uplink allocation defined by the R-MAP on R-link. If the effective start time is defined as 0, the uplink allocation defined by the R-MAP is effective in the current frame; if the value is set to N, the uplink allocation defined by the R-MAP in frame i is effective in frame i + N.
UL relay zone configuration action frameUL relay zone configuration action frame indicates the effective action time of the UL relay zone configuration defined by the R-MAP on R-link. If the effective action time is defined as 0, the UL relay configuration defined by the R-MAP is effective in the current frame; if the value is set to N, the configuration defined by the R-MAP in frame i is effective in frame i + N.
11.24.2 Reserved preamble indexes for mobile relay station
This field may be used by an MR-BS to broadcast to relay stations the preamble indexes reserved for the mobile relay stations.
11.24.3 Preamble reselection thresholds for mobile relay station
This field may be used by an MR-BS to broadcast the preamble reselection thresholds for moving relay station.
Name Type Length Value Scope
Reserved preamble indexes for mobile relay station
9 variable Bits 0–3: number of preamble indexes (N) Bit 4–(8N + 3): List of N preamble indexes (8 bits each)
RCD
Name Type Length Value Scope
Preamble rese-lection thresh-olds for mobile relay station
10 2 Bits 0–7: Interference signal strength threshold Bits 8–11: Interference duration threshold in number of Frames Bits 12–15: Window for reselecting the preamble (segment) in unit of 10 frames
RCD
Copyright © 2009 IEEE. All rights reserved. 269
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Insert new subclause 11.25 as follows:
11.25 RS_Config-CMD message TLV encoding
11.25.1 Generic configuration
This field may be used by an MR-BS to configure one or a group of RSs.
Name Type Length Value Scope
RS operational mode 1 3 Bit 0: RS scheduling modeBit 1: RS security modeBit 2: 0 = shared BSID settingBit 3: Embedded path managementBit 4: Explicit path managementBit 5: Burst based forwardingBit 6: Tunnel modeBit 7: Local CID allocation modeBit 8: Superordinate RS of an RS groupBit 9: Use a different carrier frequency for subordinate station communication at the RSBit 10: Operate in STR relaying modeBit 11: Type of RSs served by a superordi-nate station in RS groupingBit 12: Frame configuration settingBit 13: Operate in FDD mode in access linkBit 14: Operate in H-FDD mode in access linkBit 15: Operate in FDD mode in relay linkBit 16: Operate in H-FDD mode in relay linkBit 17–23: Reserved
RS_Config-CMD
Preamble index 2 1 The preamble index assigned to the RS. RS_Config-CMD
R-amble index 3 1 The R-amble index assigned to the RS RS_Config-CMD
BSID 4 4 BSID assigned to the RS RS_Config-CMD
RS EIRP 5 1 The EIRP value to be used by the RS on DL.
RS_Config-CMD
RS Frame Offset 6 1 LSB 8 bits, unsigned integer frame offset value between FN used by the RS’s super-ordinate station and FN that shall be used by the RS Suggested to be used in order to generate different subcarrier randomization sequences (see 8.4.9.4.1.)
RS_Config-CMD
RS waiting time for Paging
7 1 RS waiting time for Paging (unit: frame) RS_Config-CMD
Access downlink used subchannel group indi-cator
8 1 Bit 0: Subchannel group 0 Bit 1: Subchannel group 1 Bit 2: Subchannel group 2 Bit 3: Subchannel group 3 Bit 4: Subchannel group 4 Bit 5: Subchannel group 5 Bit 6 and 7: Reserved
RS_Config-CMD
270 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
RS operational modeWhen Bit 0 is set to 0, the RS shall operate in centralized scheduling mode. When Bit 0 is set to 1, the RS shall operate in distributed scheduling mode.When Bit 1 is set to 0, the RS shall operate in centralized security mode. When Bit 1 is set to 1, the RS shall operate in distributed security mode.When Bit 2 is set to 0, the RS shall share its BSID with other access stations. When Bit 1 is set to 1, the RS shall use a unique BSID.When Bits 3 to 7 are set to 0, the RS shall not use the indicated capability. When Bits 3 to 7 are set to 1, the RS shall use the indicated capability.When Bit 8 is set to 0, the RS is not the superordinate RS of an RS group. When Bit 8 is set to 1, the RS is the superordinate RS of an RS group.When Bit 9 is set to 0, the RS shall use the same carrier frequency for transmission and reception to and from both the superordinate and subordinate station(s).When Bit 9 is set to 1, the RS shall use a different carrier frequency for transmission and reception to and from the subordinate station(s) to that used to transmit and receive to and from the superordinate station.When Bit 10 is set to 1, the interference induced by the transmitter operating in STR mode shall not cause any link adaptation degradation of the link performance of the related STR receiver.When Bit 11 is set to 0, the superordinate station of an RS group serves non-transparent RS members. When Bit 10 is set to 1, the superordinate station of an RS group serves transparent RS members.When Bit 12 is set to 0, the MR-BS configures the frame configuration of the RS using the Frame configuration TLV in RS_Config-CMD. When Bit 12 is set to 1, the MR-BS provides the frame configuration of the superordinate station using Frame configuration TLV in RS_Config-CMD. Bit 12 can only be set to '1' when operating in STR relaying mode.
RS EIRPThe MR-BS shall indicate to the RS the EIRP the RS can utilize on the access DL preamble and advertised in any DCD message transmitted by the RS on the access link. The EIRP parameter is reported in dBm and quantized in 1dB steps ranging from –128 dBm (encoded 0x00) to 127 dBm (encoded 0xFF). Values outside this range shall be assigned the closest extreme.
RS Frame OffsetRS frame offset indicates the offset value between frame number used by the RS’s superordinate station and frame number that shall be used by the RS for whom this message is addressed. When the RS transmits the frame number in its frame, RS shall keep the offset relative to the frame number used by the superordinate station as indicated by this value. The value represents LSB 8 bits, unsigned integer for the frame offset.
RS waiting time for PagingWhen the RS receives MOB_PAG-ADV over the relay link, it shall transmit the message over the access link after this waiting time.
ARQ mode 9 1 0: No ARQ support capability1: ARQ supported2: End-to-end ARQ support3: Two-link ARQ support4: hop-by-hop ARQ support5~255: Reserved
RS Config-CMD
Name Type Length Value Scope
Copyright © 2009 IEEE. All rights reserved. 271
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
11.25.2 MBS configuration
This TLV is sent by an MR-BS to an RS to configure the parameters for MBS.
RS waiting time for MBS
When the RS receives MBS traffic over the relay link, it shall transmit the traffic over the access link after this waiting time.
Relay data early arrival report threshold
When MBS data synchronization with target transmission time is supported, this field defines the threshold used by an RS to determine when to send Access Link Transmission Status feedback header when one or more MAC PDUs arrives at the RS too early. When the threshold is included, the RS shall send Access Link Transmission Status feedback header to MR-BS when one or more MAC PDU arrives at the RS earlier than the threshold to the target transmission time. When this field is set to 0 or not present, RS shall disable the early arrival reporting.
11.25.3 Cooperative diversity configuration
This TLV is sent by an MR-BS to an RS to configure the cooperative diversity mode. The parameters shall be effective in STC DL zones where STC is not “0b00” in the corresponding STC_DL_Zone_IE.
Antenna assignment for cooperative diversity
Indicates which antenna shall be used for playing the role in cooperative diversity by the corresponding RS. For example, if this field (Bit 0–3) is a 0b1000, the relay station shall be playing the role of Antenna #0. As another example, in case the RS has two antennas and this field (Bit 0–3) is 0b1100, two antennas of the RS shall take the roles of Antenna #0 and #1. Each antenna shall transmit pilots based on the permutation number of antennas as indicated in STC_DL_Zone_IE and antenna assignment. The MR-BS shall indicate the effective number of antennas being used for cooperative relaying.
Name Type Length Value Scope
RS waiting time for MBS 10 1 RS waiting time for MBS (unit: frame)
RS_Config-CMD
Relay data early arrival report threshold
11 1 When set to 0, the RS shall not send any Access Link Transmission Sta-tus feedback header to MR-BS. (unit: frame)
RS_Config-CMD
Name Type Length Value Scope
Antenna assignment for cooperative diversity
12 1 Bit 0: Antenna #0Bit 1: Antenna #1Bit 2: Antenna #2Bit 3: Antenna #3Bits 4–7: Reserved
RS_Config-CMD
272 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
11.25.4 Local CID allocation configuration
This TLV is transmitted by the MR-BS to related RSs to update CIDs when CID (re-)allocation is required. Upon receiving, the RS shall (re-)configure CID allocation accordingly.
Name Type Length Value Scope
Contiguous CID allocation
13 variable Compound TLV (non-systematic method) RS_Config-CMD
Basic CID 13.1 4 Bit 0~15:Starting point of the CID numberBit 16~31:End point of the CID number
RS_Config-CMD
Primary management CID
13.2 4 Bit 0~15:Starting point of the CID numberBit 16~31:End point of the CID number
RS_Config-CMD
Secondary management CID
13.3 4 Bit 0~15:Starting point of the CID numberBit 16~31:End point of the CID number
RS_Config-CMD
Transport CID 13.4 4 Bit 0~15:Starting point of the CID numberBit 16~31:End point of the CID number
RS_Config-CMD
T-CID 13.5 4 Bit 0~15:Starting point of the CID numberBit 16~31:End point of the CID number
RS_Config-CMD
MT-CID 13.6 4 Bit 0~15:Starting point of the CID numberBit 16~31:End point of the CID number
RS_Config-CMD
Bit partition CID allocation
14 variable Compound TLV (systematic method) RS_Config-CMD
New CID for the RS 14.1 2 — RS_Config-CMD
Hop count 14.2 1 The new hop count of the RS to the MR-BS RS_Config-CMD
K_Code 14.3 1 The maximum number of direct subordinate RSs is 2 to the power of K_Code (2K_Code).
RS_Config-CMD
Copyright © 2009 IEEE. All rights reserved. 273
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
11.25.5 RS group configuration
11.25.5.1 Mode-1
RSSI thresholdThe RS shall report the measurement result of an MS if the RSSI of the MS is lower than RSSI threshold. The value shall be interpreted as an unsigned with units of 0.25 dB, such that 0x00 is interpreted as –103.75 dBm, an RS shall be able to report values in the range –103.75 dBm to –40 dBm
CINR thresholdThe RS shall report the measurement result of an MS if the CINR of the MS is lower than CINR_threshold. CINR_threshold shall be interpreted as a single value from –16 dB to 47.5 dB in units of 0.5 dB.
TA_DIFF thresholdTA DIFF is the threshold used by the RS for reporting the measurement when TA exceeds it. The range and units of TA_DIFF_threshold are the same as specifications of Tx_timing_offset adjustment (signed 32-bit).
REP_INTThe reporting interval for reporting, in unit of frame.
Name Type Length Value Scope
Assign/Remove multi-cast RS group CID
15 0,2 If (length = 0), Remove multicast CID from the RSIf (length = 2), Assign multicast CID (RS Group ID) to the RSBits 0–15:The multicast management CID that is assigned as multicast for an RS group
RS_Config-CMD
Name Type Length Value Scope
Event-triggered report-ing for access RS
16 6 Bits 0–7: RSSI thresholdBits 8–15: CINR thresholdBits 16–47: TA_DIFF threshold
RS_Config-CMD
Periodic reporting for access RS
17 1 Bits 0–7: REP_INT RS_Config-CMD
274 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
11.25.5.2 Mode-2
NRSSI
Number of reporting add/delete thresholds for RSSI.
RSSI_T_ADD[i]
The RSSI value specifies the add threshold to trigger reporting (8 bit). The value shall be interpreted as an unsigned with units of 0.25 dB, such that 0x00 is interpreted as –103.75 dBm, an RS shall be able to report values in the range –103.75 dBm to –40 dBm.
RSSI_T_DEL[i]
The RSSI value specifies the delete threshold to trigger RS reporting (8 bit). The value shall be interpreted as an unsigned with units of 0.25 dB, such that 0x00 is interpreted as –103.75 dBm, an RS shall be able to report values in the range –103.75 dBm to –40 dBm.
NCINR
Number of reporting add/delete thresholds for CINR.
CINR_T_ADD[i]
The CINR value specifies the add threshold to trigger reporting. The CINR value shall be interpreted from –16 dB to 47.5 dB in units of 0.5 dB (8 bit).
CINR_T_DEL [i]
The CINR value specifies the delete threshold to trigger reporting. The CINR value shall be interpreted from –16 dB to 47.5 dB in units of 0.5 dB (8 bit).
TA_DIFF
TA DIFF is the threshold used by the RS for reporting the measurement when TA exceeds it. The range and units of TA_DIFF_threshold are the same as specifications of Tx_timing_offset adjustment (signed 32-bit).
Name Type Length Value Scope
Enable RSSI-based event-trigger
18 2 × NRSSI For (i = 0; i < NRSSI; i ++){RSSI_T_ADD[i] (8-bit)RSSI_T_DEL[i] (8-bit)}
RS_Config-CMD
Enable CINR-based event-trigger
19 2 × NCINR For (i = 0; i < NCINR; i ++){CINR_T_ADD[i] (8-bit)CINR_T_DEL[i] (8-bit)}
RS_Config-CMD
Enable TA-based event-trigger
20 4 Bit 0~31: TA_DIFF (signed 32-bit). RS_Config-CMD
Copyright © 2009 IEEE. All rights reserved. 275
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
11.25.6 RS paging group
This field may be used by an MR-BS for configuring paging groups in a non-transparent RS.
11.25.7 Frame configuration mode
11.25.8 R-amble transmission and monitoring configuration
11.25.8.1 MR-BS centralized control mode
This field is used for R-amble transmission and monitoring configuration under MR-BS centralized control mode, where the RS shall follow the pattern instructed by MR-BS to transmit/receive the R-amble. The pattern is composed by the amble index, and the RS shall transmit/receive the R-amble according to the field where its amble index is. Start Frame Number is the 8 LSB bits of frame number index used to indicate the starting point of subsequent R-amble transmission/reception opportunities. In order to coordinate the R-amble transmission/reception in different MR-cell, a coordinator in backbone network is needed to ensure the Start Frame Number parameters sent in different MR-cell shall align to the same time. The RS shall start transmitting/receiving the R-amble at the designated the frame number described in “Frame Number Action.”
Name Type Length Value Scope
RS paging group
21 Length is defined as: (Num of Paging
Group ID) × 2
One or more logical affiliation grouping of RS (see 6.3.2.3.55). List of Paging Group IDs with which the RS is logically affiliated. Starting from the first byte, every 2 bytes contains one Paging Group IP value. The Paging Group identifier shall not be ‘0’.
RS_Config- CMD
Name Type Length Value Scope
Frame configuration mode
22 1 Bit 0: set to 1, it indicates that the RS shall use the RS_Config-CMD message to obtain frame configuration. If it is set to 0, R-FCH/R-MAP messages shall be used for determining the frame structure. Bits1–7: Reserved
RS_Config- CMD
276 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Monitoring_DurationThis field is the duration (in units of frames) of the measurement/monitoring/transmission process.
Interleaving IntervalThis field is the period (in units of frames) that is interleaved between the consecutive R-amble transmission/reception opportunities.
Iteration NumberThe requested number of iterating intervals.
N_StationNumber of stations received this message (8 bit unsigned).
N_TransmitterNumber of stations instructed to transmit R-amble, the station may be RS or MR-BS.
Amble index for transmissionThe RS with the index of the R-amble in this list shall transmit the R-amble. (See 8.4.6.1.1.3.)
Amble index for receptionThe RS with the index of the R-amble in this list shall receive the R-amble. (See 8.4.6.1.1.3.)
11.25.8.2 RS autonomous control mode
This field is used for R-amble transmission and monitoring configuration under RS autonomous control mode, where the RS shall autonomously transmit/receive the R-amble without periodic instruction from MR-BS by defining R-amble repetition and monitoring patterns. The deactivation or activation of the functionalities of individual RSs can be done by sending (unicast) this message during initial entry of an RS. In the case of conflict, broadcast message parameters shall supersede the unicast message parameters except for the case of the parameters M and Modulo_Frame_Offset which shall be set only by the unicast message. The detail design of the associated parameters is stated in 8.4.6.1.1.4. When the RS is instructed to transmit/receive the R-amble transmission autonomously, the RS shall send the measurements using standard measurement reporting mechanisms already defined in this document. The RS shall start transmitting/receiving the R-amble at the designated the frame number described in “Frame Number Action.”
Name Type Length Value Scope
R-amble monitoring in centralized control mode
23 variable Monitoring Duration (8-bit unsigned)Interleaving Interval (8-bit unsigned)Iteration Number (8-bit unsigned)N_Station (8-bit unsigned)For(i = 0; i < Iteration Number; i++){N_Transmitterfor(j = 0;j < N_Transmitter; j++){Amble index for transmission}for(j = 0;j < N_Station – N_Transmitter; j++){Amble index for reception}}
RS_Config-CMD
Copyright © 2009 IEEE. All rights reserved. 277
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Synchronization Cycle Length, NThis field is used to indicate the synchronization R-amble period if present (see 8.4.6.1.1.4.1).
Synchronization Frame Offset, KsThe offset of the second R-amble in the synchronization cycle (see 8.4.6.1.1.4.1).
Monitoring DurationThis field is the duration (in units of frames) of the measurement/monitoring/transmission process. If this field is set to 0x00, the monitoring is to be continued until further notice
Modulo_Frame_OffsetThis is the offset provided by the MR-BS to be used when evaluating the Computed_Frame_Nnumber parameter as explained in 8.4.6.1.1.4.1.
Neighbor Monitoring Cycle Length, MThis field is used to indicate the number of neighbor monitoring R-amble frames in an R-amble monitoring cycle (see 8.4.6.1.1.4.2).
Neighbor Monitoring Frame Offset, KmThis field is used to indicate the offset of the R-amble in the neighbor monitoring cycle (see 8.4.6.1.1.4.2)
Neighbor Monitoring Frame Repetition Rate, LThis field is used to indicate the neighbor monitoring R-amble period if present (see 8.4.6.1.1.4.2).
Name Type Length Value Scope
Enable/Disable R-amble transmitting for synchronization
24 0, 3 If (length = 0), all RSs shall stop transmitting R-amble for synchronizationIf (length = 3), all RSs shall start transmitting R-amble for synchronization with following parametersBit 0~7: Synchronization cycle – NBit 8~11: Synchronization frame offset – KsBit 12~19: Modulo_Frame_OffsetBit 20~23: Reserved
RS_Config-CMD
Enable/Disable R-amble monitoring in random mode
25 0, 3 If (length = 0), all RS shall stop R-amble mon-itoring in random modeIf (length = 3), all RS shall start R-amble mon-itoring in random mode with following param-etersBit 0~7: Monitoring DurationBit 8~11: Neighbor monitoring cycle length, MBit 12~15: Neighbor monitoring frame offset, KmBit 16~23: Neighbor monitoring frame repeti-tion rate, L
RS_Config-CMD
Enable/Disable R-amble transmitting for advertisement purpose
26 1 Bit 0:0 - Any RS which does not support subordinate RSs shall transmit the R-amble for advertise-ment purpose1 - Any RS which does not support subordinate RSs shall not transmit the RambleBit 1~7: Reserved
RS_Config-CMD
278 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
11.25.8.3 R-amble measurement report
This field is used by an MR-BS to instruct the RS to report its measurement results.
11.25.9 Multiple frame structure configurations
This field is used by an MR-BS to inform usage of the frame structure to all RSs (see also Bit 12 of RS operational mode TLV in 11.25.1).
Number of frameThis field indicates the number of frames in a multi-frame. This value shall be the same both for DL and UL. A zero value is not valid. If the value is one, this indicates a single frame structure.
Number of zonesFirst zone refers always to access zone for DL subframe configuration.
Name Type Length Value Scope
Neighbor measure-ment report request
27 1 Bit 0: Report Request (0: RSSI, 1:CINR) RS_Config-CMD
Name Type Length Value Scope
DL subframe configuration
28 variable Number of frames (8-bit unsigned)for(i = 0; i< Number of frame; i++){Number of zones (unsigned 2-bit)Reserved (6-bit unsigned)for(j = 0; j< Number of zones; j++){Transceiver mode (unsigned 2-bit)Zone mode (1 bit)OFDMA Symbol Offset (unsigned 7-bit)Zone Duration (unsigned 5-bit)Zone Configuration indicator (unsigned 1-bit)If(Zone Configuration indicator == 1) {Zone Configuration IE() (variable size in bytes)}}}
RS_Config-CMD
UL subframe configuration
29 variable Number of frame (8-bit unsigned)for(i = 0; i< Number of frame; i++){Number of zones (unsigned 2-bit)Reserved (6-bit unsigned)for(j = 0; j< Number of zones; j++){Transceiver mode (unsigned 2-bit)Zone mode (1 bit)OFDMA Symbol Offset (unsigned 7-bit)Zone Duration (unsigned 5-bit)Zone Configuration indicator (unsigned 1-bit)If(Zone Configuration indicator == 1) {Zone Configuration IE() (variable size in bytes)}}}
RS_Config-CMD
Copyright © 2009 IEEE. All rights reserved. 279
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Transceiver modeTransceiver mode in the relay zone is one of either Tx mode (00), Rx mode (01), or Idle mode (10). When the transceiver mode is idle mode, it does not transmit nor receive.
Zone modeIndicates that the zone is assigned to be used for access link (0), or for relay link (1).
OFDMA symbol OffsetThe relay zone starts at the OFDMA symbol Offset, counted after the preamble of the corresponding frame.
Zone DurationThe relay zone ends after the duration starting from the OFDMA symbol offset. The unit of duration is an OFDMA symbol.
Syntax Size (bits) Notes
Zone Configuration IE_Format{ — —
Zone Configuration bitmap 8 Bit 0=1, permutation base includedBit 1=1, range of subchannels includedBit 2=1, STC modeBit 3=1, Cooperative diversity configuration includedBit 4=1, AMC modeBits 5–7: Reserved
if(b0 of Zone Configuration bitmap ==1){ — —
Permutation base 6 DL_PermBase or UL_PermBase to be used in this zone
Permutation type 2 0b00: PUSC permutation0b01: FUSC permutation0b10: Optional FUSC permutation0b11: Adjacent subcarrier permutation
PRBS_ID 2 Values: 0..2. Refer to 8.4.9.4.1
Reserved 6 —
} — —
if(b1 of Zone Configuration bitmap ==1){
if(The IE is in DL-subframe configuration) {
— —
Used subchannel bitmap 6 Bit 0, Subchannel group 0Bit 1, Subchannel group 1Bit 2, Subchannel group 2Bit 3, Subchannel group 3Bit 4, Subchannel group 4Bit 5, Subchannel group 5
Reserved 2 Shall be zero
} — —
if(The IE is in ULL-subframe configuration) {
— —
Min Subchannel index 8 The index of subchannel from which the alloca-tion starts
280 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Max Subchannel index 8 The index of subchannel at which the allocation ends
} — —
} — v
if(b2 of Zone Configuration bitmap ==1){ — —
STC mode 2 0b00: Reserved 0b01: STC using 2/3 antennas 0b10: STC using 4 antennas 0b11: FHDC using 2 antennas
Matrix indicator 2 STC matrix (see 8.4.8.1.4)
if (STC == 0b01 or STC == 0b10) { 0b00 = Matrix A 0b01 = Matrix B 0b10 = Matrix C 0b11 = Reserved}else if (STC == 0b11) { 0b00 = Matrix A 0b01 = Matrix B 0b10–11 = Reserved }
Midamble presence 1 0: Not present 1: MIMO midamble present at the first symbol in STC zone
Midamble boosting 1 0: No boost 1: Boosting (3 dB)
2/3 antennas select 1 0: STC using 2 antennas 1: STC using 3 antennas Selects 2/3 antennas when STC = 0b01
Reserved 1 —
} — —
if(b3 of Zone Configuration bitmap ==1){ — —
Enable cooperative diversity 1 If set to 0, cooperative transmit/hybrid diversity is disabled
if (Enable_cooperative_diversity ==1) {
Antenna assignment for cooperative diversity
4 Bit 0: Antenna #0Bit 1: Antenna #1Bit 2: Antenna #2Bit 3: Antenna #3
} — —
Padding variable Padding to ensure byte alignment.
} — —
if(b4 of Zone Configuration bitmap ==1){ — —
Syntax Size (bits) Notes
Copyright © 2009 IEEE. All rights reserved. 281
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Antenna Assignment If Antenna Assignment is non-zero, then the RS shall implement the STC zone taking the role of the antennas indicated in this field. For example, for an RS with 4 antennas and STC mode = 0b10, if the Bit 0–Bit 3 is 0b0000, then the RS transmits according to the STC mode with 4 transmit antennas, while if the Bit 0–Bit 3 is 0b1001, then the RS takes the role of Antenna #0 and Antenna #3 and transmits pilots based on the antenna assignment and permutations indicated.
11.25.10 Direct relay zone configuration
This field is used by an MR-BS to inform the usage of the direct relay zone to all RSs (see also Bit 12 of RS operational mode TLV in 11.25.1).
AMC mode 2 Indicates the AMC type in case permutation type = 0b11, otherwise shall be set to 0.
AMC type (NxM = N bins by M symbols): 0b00: 1x6 0b01: 2x3 0b10: 3x2 0b11: Reserved
Reserved 6 —
} — —
} — —
Name Type Length Value Scope
DL Direct Relay Zone configuration
30 4 Number of direct relay zones (unsigned 1-bit)For(j=0;j<Number of direct relay zone;j++){Symbol offset for Direct receiving zone j(un-
signed 8-bits)No. OFDMA symbols for Direct receiving zone
j(unsigned 6-bits)Symbol offset for Direct transmitting zone j(un-
signed 8-bits)No. OFDMA symbols for Direct transmitting zone
j(unsigned 6-bits)Reserved(unsigned 3-bits)
}
RS_Config-CMD
UL Direct Relay Zone configuration
31 4 Number of direct relay zones (unsigned 1-bit)For(j=0;j<Number of direct relay zone;j++){Symbol offset for Direct receiving zone j(un-
signed 8-bits)No. OFDMA symbols for Direct receiving zone
j(unsigned 6-bits)Symbol offset for Direct transmitting zone j(un-
signed 8-bits)No. OFDMA symbols for Direct transmitting zone
j(unsigned 6-bits)Reserved(unsigned 3-bits)
}
RS_Config-CMD
Syntax Size (bits) Notes
282 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Number of direct relay zonesThis indicates the number of direct relay zones that include the Direct Receiving and Direct Transmitting zone respectively.
Symbol offset for direct receiving zoneThe OFDMA symbol offset in which direct receiving zone starts for downlink/uplink respectively.
No. of OFDMA symbols for direct receiving zoneThe number of OFDMA symbols that the RS shall demodulate and modulate in the direct relay zone for downlink/uplink respectively.
Symbol offset for direct transmitting zoneThe OFDMA symbol offset in which Direct Relay for transmitting starts for downlink or uplink respectively.
No. OFDMA symbols for direct transmitting zoneThe number of OFDMA symbols that RS shall demodulate and modulate in the direct relay zone for downlink/uplink respectively.
11.25.11 RS UL access link configuration
This field is used by the MR-BS to configure the access UL of the RS.
11.25.12 Non-transparent RS operating in centralized scheduling mode
RS DL fixed forwarding delayThe RS DL fixed forwarding delay shall be used by an RS in centralized scheduling mode to receive and forward MAC PDUs. RS shall forward each MAC PDU to the MS or subordinate RS at the frame determined by receiving frame of the MAC PDU plus RS DL fixed forwarding delay.
Name Type Length Value Scope
Access UL allocated subchannels bitmap
32 9 This is a bitmap describing the physical subchannels allocated to the RS for its UL access traffic, when using the uplink PUSC permutation. The LSB of the first byte shall correspond to subchannel 0. For any bit that is not set, the corresponding subchannel shall not be used by the RS on that segment. When this TLV is not pres-ent, RS is allocated all subchannels.
RS_Config-CMD
Name Type Length Value Scope
RS DL fixed forward-ing delay
35 1 Fixed forwarding delay to be used by RS on DL (unit: frame)
RS_Config-CMD
RS UL fixed forward-ing delay
36 1 Fixed forwarding delay to be used by RS on UL (unit: frame)
RS_Config-CMD
Copyright © 2009 IEEE. All rights reserved. 283
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
RS UL fixed forwarding delayThe RS UL fixed forwarding delay shall be used by an RS in centralized scheduling mode to receive and forward MAC PDUs. The RS shall forward each MAC PDU to the MR-BR or superordinate RS at the frame determined by receiving frame of the MAC PDU plus RS UL fixed forwarding delay.
11.25.13 STR RS configuration
Insert new subclause 11.26 as follows:
Name Type Length Value Scope
RS second carrier configuration for TDD mode
37 6 Bits 0–23: Centre frequency (kHz)Bits 24–38: Bandwidth (kHz)Bits 39–40: FFT size (0b00: 128FFT; 0b01: 512FFT; 0b10: 1024FFT; 0b11: 2048 FFT)Bits 41–48: Reserved
RS_Config-CMD
RS second DL carrier configura-tion for FDD mode
38 6 Bits 0–23: Centre frequency (kHz)Bits 24–38: Bandwidth (kHz)Bits 39–40: FFT size (0b00: 128FFT; 0b01: 512FFT;0b10: 1024FFT; 0b11: 2048 FFT)Bits 41–48: Reserved
RS_Config-CMD
RS second UL carrier configura-tion for FDD mode
39 4 UL centre frequency (kHz) RS Config CMD
284 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
11.26 MS_Context-REQ/RSP management message encodings
Table 616a—MS_Context-REQ/RSP message encodings
Name Type Length Value PHY Scope
SS MAC Address 1 6 SS MAC Address in MAC-48 format OFDMA
SBC-RSP encodings 2 variable SBC-RSP TLV items for HO optimization OFDMA
REG-RSP encodings 3 variable REG-RSP TLV items for HO optimization OFDMA
AK context 4 variable See table OFDMA
SA Descriptors 5 variable See table 616c OFDMA
Service Flow Informa-tion
[145/146]
variable Service flow management encodings (11.13) OFDMA
BSID 6 6 BSID of Target or Serving station OFDMA
Table 616b—AK Context encodings
Name Type Length Value
AK 4.1 20 Encrypted AK Value. See 7.5.2.5 for detail of AK encryption
AK ID 4.2 8 Identifies the AK that used for protecting the message
AK Lifetime 4.3 4 The remaining time period during which the AK shall be valid
AK SN 4.4 1 The Sequence number of root keys(PMK) for the AK
CMAC Key Count 4.5 2 Value of the Entry Counter that is used to guarantee freshness of computed CMAC KEY * with every entry and provide replay protection
Copyright © 2009 IEEE. All rights reserved. 285
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
Table 616c—SA Descriptor encodings
Insert new subclause 11.27 as follows:
11.27 Location information request and response (MR_LOC-REQ/RSP) messages encodings
11.27.1 The position of the RS
This TLV is used to provide the position of the RS.
Name Type Length Value
SAID 5.1 2 Security association identifier is a 16-bit identifier for the SA.
SA type 5.2 1 Type of security association. See Table 599.
SA Service type 5.3 1 Service type of the corresponding security association type. This shall be defined only when SA type is Static SA or Dynamic SA.
Cryptographic suite 5.4 3 Cryptographic suite employed within the SA. See 11.9.14.
Older TEK parameters
5.5 variable TEK parameters. See Table 616d.
Newer TEK parameters
5.6 variable TEK parameters. See Table 616d.
Table 616d—TEK parameters encodings
Name Type Length Value
TEK [5.5/5.6].1 variable Traffic Encryption Key encrypted with the negotiated TEK encryption algorithm. See 7.5.2.
TEK sequence number
[5.5/5.6].2 1 2-bit TEK Sequence Number.
TEK Lifetime [5.5/5.6].3 4 The remaining TEK Lifetime in seconds. Zero means that the corresponding TEK is not valid.
PN Counter [5.5/5.6].4 4 Last value of PN Counter used on DL (for AES CCM cipher suite).
RxPN Counter [5.5/5.6].4 4 Last value of PN Counter used on DL (for AES CCM cipher suite).
286 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
11.27.2 Positions of neighbor stations
These TLVs are used to provide BSIDs or positions of neighbor stations (BSs, MR-BSs as well as RS).
11.27.3 Report period
This TLV is used to provide the report period for periodic reporting mode.
Name Type Length(bytes) Value
Absolute Position(Long Format) 1 15 See Table 613
Absolute Position(Short Format) 2 6 or 8 See Table 614
Relative Position 3 4 or 6 See Table 615
Name Type Length(bytes) Value
Neighbor Station BSID and Absolute Position (Long Format)
4 21 × Nra
aWhere Nr is the number of neighboring stations whose BSIDs and locations are included in the value field.
For (i=0;i<Nr;i++) {48-bit BSID of the neighboring station120-bit Absolute Position defined (long format) in Table 609}
Neighbor Station BSID and Absolute Position (Short Format)
5 14 × Nra For (i=0;i<Nr;i++) {48-bit BSID of the neighboring station64-bit Absolute Position defined (short format) in Table 610}
Neighbor Station BSID and Relative Position
6 12 × Nra For (i=0;i<Nr;i++) {48-bit BSID of the neighboring station48-bit Relative Position defined in Table 611}
Name Type Length(bytes) Value
Report Period 7 2 Report period in units of frame, a value from 0 to 4095 corre-sponding to a range of 1 frame to 4096 frame.
Copyright © 2009 IEEE. All rights reserved. 287
IEEE Std 802.16j-2009 AMENDMENT TO IEEE STD 802.16-2009
11.27.4 BSIDs of neighbor stations
This TLV is used to provide BSIDs of neighbor stations (BSs, MR-BSs as well as RS).
12. System profiles
12.4 Fixed WirelessMAN-OFDMA
12.4.3 WirelessMAN-OFDMA and WirelessHUMAN(-OFDMA) System PHY
12.4.3.1 Common features of PHY profiles
12.4.3.1.5 Minimum performance requirements
Change Table 639 as indicated:
Name Type Length(bytes) Value
Neighbor Station BSID 8 6 × Nra
aWhere Nr is the number of neighboring stations whose BSIDs and locations are included in the value field.
For (i=0;i<Nr;i++) {48-bit BSID of the neighboring station}
Table 639—Minimum performance requirements for all profiles
Capability Minimum performance
RSTTG and RSRTG: TDD≤50 µs
288 Copyright © 2009 IEEE. All rights reserved.
MULTIHOP RELAY SPECIFICATION IEEE Std 802.16j-2009
Insert new bibliographical references in Annex A in alphanumerical order. Renumber as appropriate.
Annex A
(informative)
Bibliography
[B49] Defense Mapping Agency Technical Report. Supplement to Department of Defense World Geodetic System 1984 Technical Report, Part 1. Methods, Techniques, and Data used in WGS 84 Development, 1 December 1987, Second Printing.6
[B50] MIL-STD-2401, World Geodetic System 1984 (WGS 84), http://www.wgs84.com/.
6This document can be found at http://earth-info.nga.mil/GandG/publications/historic/historic.html.
Copyright © 2009 IEEE. All rights reserved. 289
IEEE Std 802.16j-2009
Insert new Annex P as follows:
Annex P
(informative)
QoS parameters for a tunnel
P.1 Example of how to aggregate QoS parameters for a tunnel
Table P.1 shows an example of how to aggregate QoS parameters for a tunnel.
Table P.1—The value of aggregated QoS parameters admitted into a tunnel
Name Aggregated value
Traffic Priority The highest priority among all the service flows’ traffic priority admitted into a tunnel
Maximum Sustained Traffic Rate Sum of all the service flows’ maximum sustained traffic rate admitted into a tunnel
Maximum Traffic Burst Min { Sum of all the service flows’ maximum traffic burst admitted into a tunnel, Maximum allowed size of traffic burst }
Minimum Reserved Traffic Rate Sum of all the service flows’ minimum reserved traffic rate admitted into a tunnel
Maximum Latency Minimum value among all the service flows’ maximum latency values admitted into a tunnel
Tolerated Jitter Minimum value among all the service flows’ tolerated jitter values admitted into a tunnel
Unsolicited Grant Interval Highest common divisor of all the service flows’ unsolicited grant inter-val values admitted into a tunnel
290 Copyright © 2009 IEEE. All rights reserved.