idnits 2.17.1 draft-ietf-opsawg-capwap-extension-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (May 09, 2013) is 4005 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4564' is defined on line 596, but no explicit reference was found in the text == Unused Reference: 'RFC5415' is defined on line 600, but no explicit reference was found in the text == Unused Reference: 'RFC5416' is defined on line 604, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4564 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y.F. Chen 3 Internet-Draft D.L. Liu 4 Intended status: Standards Track H. Deng 5 Expires: November 10, 2013 China Mobile 6 Lei. Zhu 7 Huawei 8 May 09, 2013 10 CAPWAP Extension for 802.11n and Power/channel Reconfiguration 11 draft-ietf-opsawg-capwap-extension-00 13 Abstract 15 CAPWAP binding for 802.11 is specified by RFC5416 and it was based on 16 IEEE 802-11.2007 standard. After RFC5416 was published in 2009, 17 there was several new amendent of 802.11 has been published. 802.11n 18 is one of those amendent and it has been widely used in real 19 deployment. This document extends the CAPWAP binding for 802.11 to 20 support 802.11n. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 10, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions used in this document . . . . . . . . . . . . . . 2 58 3. CAPWAP 802.11n support . . . . . . . . . . . . . . . . . . . 2 59 4. CAPWAP extension for 802.11n support . . . . . . . . . . . . 3 60 5. Power and Channel auto reconfiguration . . . . . . . . . . . 6 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 63 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 64 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 65 10. Normative References . . . . . . . . . . . . . . . . . . . . 13 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 68 1. Introduction 70 IEEE 802.11n standard was published in 2009 and it is an amendment to 71 the IEEE 802.11-2007 standard to improve network throughput. The 72 maximum data rate increases to 600Mbit/s physical throughput rate. 73 In the physical layer, 802.11n use OFDM and MIMO to achive the high 74 throughput. 802.11n use multiple antennas to form antenna array 75 which can be dynamically adjusted to imporve the signal strength and 76 extend the coverage. 78 There are couple of capabilities of 802.11n need to be supported by 79 CAPWAP control message such as radio capability, radio configuration 80 and station information. 82 2. Conventions used in this document 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 3. CAPWAP 802.11n support 90 IEEE 802.11n standard was published in 2009 and it is an amendment to 91 the IEEE 802.11-2007 standard to improve network throughput. The 92 maximum data rate increases to 600Mbit/s physical throughput rate. 93 In the physical layer, 802.11n use OFDM and MIMO to achive the high 94 throughput. 802.11n use multiple antennas to form antenna array 95 which can be dynamically adjusted to imporve the signal strength and 96 extend the coverage. 98 802.11n support three modes of channel usage: 20MHz mode, 40Mhz mode 99 and mixed mode.802.11n has a new feature called channel binding. It 100 can bind two adjacent 20MHz channel to one 40MHz channel to improve 101 the throughput.If using 40Mhz channel configuration there will be 102 only one non-overlapping channel in 2.4GHz. In the large scale 103 deployment scenario, operator need to use 20MHz channel configuration 104 in 2.4GHz to allow more non-overlapping channels. 106 In MAC layer, a new feature of 802.11n is Short Guard Interval(GI). 107 802.11a/g use 800ns guard interval between the adjacent information 108 symbols. In 802.11n, the GI can be configured to 400nm under good 109 wireless condition. 111 Another feature in 802.11 MAC layer is Block ACK. 802.11n can use 112 one ACK frame to acknowledge several MPDU receiving event. 114 CAPWAP need to be extended to support the above new 802.11n features. 115 For example, CAPWAP should allow the access controller to know the 116 supported 802.11n features and the access controller should be able 117 to configure the differe channel binding modes. One possible 118 solution is to extend the CAPWAP information element for 802.11n. 120 4. CAPWAP extension for 802.11n support 122 There are couple of capabilities of 802.11n need to be supported by 123 CAPWAP control message such as radio capability, radio configuration 124 and station information. This section defines the extension of 125 current CAPWAP 802.11 information element to support 802.11n. 127 1. 802.11n Radio Capability Information Element. Below is an 128 example of the 802.11n radio capability information element. This 129 802.11n radio capability information element may also be conveyed 130 using the IEEE 802.11 information element by carrying the IEEE 802.11 131 HT element information. 133 0 1 2 3 134 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Element ID | Length | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Radio ID |SupChanl width | Power Save | ShortGi20 | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | ShortGi40 | HtDelyBlkack | Max Amsdu | Max RxFactor| 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 |Min StaSpacing | HiSuppDataRate| AMPDUBufSize | HtcSupp | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | 20MHZ 11gMCS | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | 20MHZ 11gMCS | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | 20MHZ 11gMCS | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | 20MHZ 11gMCS | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | 20MHZ 11aMCS | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | 20MHZ 11aMCS | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | 20MHZ 11aMCS | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | 20MHZ 11aMCS | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | 40MHZ 11gMCS | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | 40MHZ 11gMCS | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | 40MHZ 11gMCS | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | 40MHZ 11gMCS | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | 40MHZ 11aMCS | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | 40MHZ 11aMCS | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | 40MHZ 11aMCS | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | 40MHZ 11aMCS | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Figure 1: 802.11n Radio Capability Information Element 180 1. SupChanl width: The supported bandwith mode. 0x01: 20MHz 181 bandwidth binding mode. 0x02: 40MHz bandwidth binding mode. 182 2. Power Save: 0x00: Static power saving mode. 0x01: Dynamic power 183 saving mode. 0x03: Do not support power saving mode. 184 3. ShortGi20: Whether support short GI. 0x00: Do not support short 185 GI. ox01: Support short GI. 186 4. HtDelyBlkack: Whether block Ack support delay mode. 0x00: Do 187 not support delay mode. 0x01: Support delay mode. 188 5. Max Amsdu: The maximal AMSDU length. 0: 3839 bytes. 1: 7935 189 bytes. 190 6. Max RxFactor: The maximal receiving AMPDU factor. Default 191 value: 3. 192 7. Min StaSpacing: Minimum MPDU Start Spacing. 193 8. HiSuppDataRate: Maximal transmission speed. 195 9. AMPDUBufSize: AMPDU buffer size. 196 10. HtcSupp: Whether the packet have HT header. 197 11. 20MHZ 11gMCS: 128 bitmap.If support should be all zero, 198 otherwise all one. 199 12. 20MHZ 11aMCS: 128 bitmap.If support should be all zero, 200 otherwise all one. 201 13. 40MHZ 11gMCS: 128 bitmap.If support should be all zero, 202 otherwise all one. 203 14. 40MHZ 11aMCS: 128 bitmap.If support should be all zero, 204 otherwise all one. 205 15. 2. 802.11n Raido Configuration TLV. Following figure is an 206 example of 802.11n radio configuration TLV. 208 0 1 2 3 209 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Element ID | Length | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Radio ID | Amsdu Cfg | Ampdu Cfg | 11nOnly Cfg | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | ShortGi Cfg | BandWidth Cfg | MaxSupp MCS | Max MandMCS | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | TxAntenna | RxAntenna | Reserved | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Reserved | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 Figure 2: 802.11n radio configuration 224 1. A-MSDU CFG: 0x00: Disable 0x01: Enalbe 225 2. A-MPDU CFG: 0x00: Disable 0x01: Enalbe 226 3. 11N Only CFG: Whether allow only 11n user access. 0x00: Allow 227 non-802.11n user access. 0x01: Do not allow non-802.11n user 228 access. 229 4. Short GI CFG: 0x00: Disable 0x01: Enable 230 5. Bandwidth CFG: Bandwidth binding mode. 0x00: 40MHz 0x01: 20MHz 231 6. Max Support MCS: Maximal MCS. 232 7. Max Mandantory MCS: Maximal mandantory MCS. 233 8. TxAntenna: Transmitting antenna configuration. 234 9. RxAntenna: Receiving antenna configuration. 235 10. Each TxAntenna and RxAntenna bit represent one antenna, 1 means 236 enable, 0 means disable. 238 3. 802.11n Station Information. Following figure is an example of 239 802.11n station information information element. 241 0 1 2 3 242 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Element ID | Length | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | MAC Address | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 |SupChanl width | Power Save | | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | ShortGi20 | ShortGi40 | HtDelyBlkack | Max Amsdu | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Max RxFactor | Min StaSpacing| HiSuppDataRate | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | AMPDUBufSize | HtcSupp | MCS Set | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | MCS Set | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | MCS Set | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | MCS Set | 261 +-+-+-+-+-+-+-+-+- 263 Figure 3: 802.11n Station Information 265 1. SupChanl width: Supporting bandwidth mode. 0x01: 20MHz 266 bandwidth mode. 0x02: 40MHz bandwidth binding mode. 267 2. Power Save: 0x00: Static power saving mode. 0x01: Dynamic power 268 saving mode. 0x03: Do not support power saving mode. 269 3. ShortGi20: Whether support short GI in 20MHz bandwidth mode. 270 0x00: Do not support short GI. ox01: Support short GI. 271 4. ShortGi40: Whether support short GI in 40MHz bandwidth mode. 272 0x00: Do not support short GI. ox01: Support short GI. 273 5. HtDelyBlkack: Whether block Ack support delay mode. 0x00: Do 274 not support delay mode. 0x01: Support delay mode. 275 6. Max Amsdu: The maximal AMSDU length. 0x00: 3839 bytes. 0x01: 276 7935 bytes. 277 7. Max RxFactor: The maximal receiving AMPDU factor. 278 8. Min StaSpacing: Minimum MPDU Start Spacing. 279 9. HiSuppDataRate: Maximal transmission speed. 280 10. AMPDUBufSize: AMPDU buffer size. 281 11. HtcSupp: Whether the packet have HT header. 282 12. MCS Set: The MCS bitmap that the station supports. 284 5. Power and Channel auto reconfiguration 286 Power and channel auto reconfiguration could avoid potential radio 287 interference and improve the Wi-Fi performance. In general, the 288 auto-configuration of radio power and channel could occurre at two 289 stages: when the WTP power on or during the WTP running time. 291 When the WTP is power-on, it is of necessity to configure a proper 292 channel to the WTP in order to achieve best status of radio links. 293 IEEE 802.11 Direct Sequence Control elements or IEEE 802.11 OFDM 294 Control element defined in RFC5416 should be carried to offer WTP a 295 channel at this stage. Those element should be carried in the 296 Configure Status Response message. If those information element is 297 zero, the WTP will determine its channel by itself, otherwise the WTP 298 should be configured according to the provided information element. 300 When the WTP determines its own channel configuration, it should 301 first scan the channel information, then determine which channel it 302 will work on and form a channel quality scan report. The channel 303 quality report will be sent to the AC using WTP Event Request message 304 by the WTP. The AC can use IEEE 802.11 Direct Sequence Control or 305 IEEE 802.11 OFDM Control information element carried by the configure 306 Update Request message to configure a new channel for the WTP. 308 IEEE 802.11 Tx Power information element is used by the AC to control 309 the transmission power of the WTP. The 802.11 Tx Power information 310 element is carried in the Configure Status Response message during 311 the power on phase or in the Configure Update Request message during 312 the running phase. 314 Channel Scan Procedure. 316 The Channel Scan Procedure is illustrated by the following figure. 318 WTP Configure Status Req AC 319 -------------------------------------------------------> 320 Configure Status Res(Scan Para TLV, Chl Bind TLV) 321 <------------------------------------------------------ 322 or 324 WTP Configure Update Req(Scan Para, Bind TLV) AC 325 <----------------------------------------------------- 326 Configure Update Res 327 -----------------------------------------------------> 329 Figure 4: Channel Scan Procedure 331 The definition of the Scan Para TLV is as follows: 333 0 1 2 3 334 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Element ID | Length | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 |Radio ID | AP oper mode | Scan Type | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Reserved | 341 +---------------------------------------------------------------+ 342 | Report Time | PrimeChlSrvTime | 343 +---------------------------------------------------------------+ 344 | On Channel ScanTIme | Off Channel ScanTime | 345 +---------------------------------------------------------------+ 346 |L|D| Flag | | 347 +---------------------------------------------------------------+ 349 Figure 5: Scan Para TLV 351 Element ID: TBD; Length:18 353 AP oper mode: the work mode of the WTP. 0x01:normal mode. 0x02: 354 monitor only mode. 356 Scan Type: 0x01: active scan; 0x02: passive scan. 358 Report Time: Channel quality report time. 360 PrimeChlSrvTime: Service time on the working scan channel. This 361 segment is invalid(set to 0) when WTP oper mode is set to 2. The 362 maximum value of this segment is 10000, the minimum value of this 363 segment is 5000, the default value is 5000. 365 On Channle ScanTime: The scan time of the working channel. When the 366 WTP oper mode is set to 2, this segment is invalid(set to 0). The 367 maximum value of thi segment is 120, the minimum value of this 368 segment is 60, the default value is 60. 370 L=1: Open Load Balance Scan. D=1: Open Rogue WTP detection scan. 371 Flag: Bitmap, resered for furture use. 373 The definition of the Channel Bind TLV is as follows: 375 0 1 2 3 376 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Element ID | Length | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 |Radio ID | Flag | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Max Cycles | Reserved | Channel Count | 383 +---------------------------------------------------------------+ 384 | Scan Channel Set... | 385 +---------------------------------------------------------------+ 387 Figure 6: Channel Bind TLV 389 Element ID: TBD. Length>=12 391 Flag: bitmap, reserved. 393 Max Cycles: Scan repeat times. 255 means continuous scan. 395 Channel Count: The number of channel will be scanned. 397 Scan Channel Set: The channle information. the format is as follows: 399 0 1 2 3 400 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Channel ID | Flag | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Figure 7: Channle Information Format 407 Channel ID: the channel ID of the channel which will be scanned. 409 Flag: bitmap, reserved for future use. 411 The channle scan procedure: 413 The WTP has two work mode: the first one is normal mode. In this 414 mode, the WTP can provide service for the STA access and scan the 415 channel at the same time. Whether the WTP will scan the channel is 416 determined by the Max Cycles segment in the Channle Bind TLV. When 417 this segment is set to 0, the WTP will not scan the channle. If this 418 segment is set to 255, the WTP will continuous scan the channel. The 419 type of the scan is determined by the Sacn Type segment. In the 420 passive scan type, the WTP monitor the airinterface, based on the 421 received beacon frame to determine the nearby WTPs. In the active 422 scan type, the WTP will send probe message and receive the probe 423 response message. In the normal scan mode, the WTP will use 3 424 parameters: PrimeChlSrvTime, OnChannelScanTIme, OffChannelScnTIme. 425 The WTP will provide access service for the STAs for PrimeChlSrvTime 426 duration and then start to scan the channel for On Channel ScnTime 427 duration. Back to the working channel, provide STA access service 428 for PrimeChlSrvTime, then leave the working channel, start to scan 429 the next channel for Off Channel ScanTime duration. This process 430 will be repeated until all the channel is scanned. 432 When the WTP work in the scan only mode, there is no difference 433 between the working channel and scan channel. Every channel's scan 434 duration will be OffChannelScnTime and the PrimeChlSrvTime and 435 OnChannelScanTime is set to 0. 437 Scan Report. THe WTP send the scan report to the AC through WTP 438 Event Request message. The information element that used to carry 439 the scan report is Channel Scan Report TLV and Neighbor WTP Report 440 TLV. The example definition of the Channel Scan Report TLV is as 441 following figure. The channel scan report may also be conveyed by 442 IEEE 802.11 information element by carrying the IEEE 802.11 beacon 443 report message element. 445 0 1 2 3 446 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Element ID | Length | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Radio ID | Report Count | Channel Scan Report | 451 +---------------------------------------------------------------+ 453 Figure 8: Channel Scan Report TLV 455 Element ID: 133; Length: >= 20. 457 Report Count: the channle number will be reported. The definition of 458 the channel scan report is as follows: 460 0 1 2 3 461 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Channel Number | Radar Statistics | Mean | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Time | Mean RSSI | Screen Packet Count | 466 +---------------------------------------------------------------+ 467 | NeighborCount| Mean Noise | Interference | Self Tx Occp | 468 +---------------------------------------------------------------+ 469 | SelfStaOccp | Unknown Occp | CRC Err Cnt | Decrypt Err Cnt | 470 +---------------------------------------------------------------+ 471 |Phy Err Cnt | Retrans Cnt | 472 +-----------------------------+ 474 Figure 9: Channel Scan Report 476 Channel Number: The channel number. 478 Radar Statistics: Whether detect radar signal in this channel. 0x00: 479 detect radar signal. 0x01: no radar signal is detected. 481 Mean Time: Channel measurement duration. 483 Mean RSSI: The signal strength of the scanned channel. 485 Screen Packet Count: Received packet number. 487 Neighbor Count: The neighbor number of this channel. 489 Mean Noise: the average noise on this channel. 491 Interference: The interference of the channel. 493 Self Tx Occp: The time duration for transmission. 495 Unknown Occp: TBD. 497 CRC Err Cnt: CRC err packet number. 499 Decrypt Err Cnt: Decryption err packet number. 501 Phy Err Cnt: Physical err packet number. 503 Retrans Cnt: Retransmission packet number. 505 The example definition of neighbor WTP report TLV is as follows: 507 The neigbor WTP report message element may also be conveyed using 508 IEEE 802.11 information element by carrying 802.11 neighbor report 509 information element. 511 0 1 2 3 512 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Element ID | Length | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Radio ID | Reserved | Number of Neighbor Report | 517 +---------------------------------------------------------------+ 518 | Neighbor Infor... | 519 +---------------------------------------------------------------+ 521 Figure 10: Neighbor WTP Report TLV 523 Element ID: 134; Length:>=16 525 The definition of Neighbor info is as follows: 527 0 1 2 3 528 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | BSSID | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | BSSID | Channel Number | 533 +---------------------------------------------------------------+ 534 | 2rd Offset | Mean RSSI | Sta Intf | AP Intf | 535 +---------------------------------------------------------------+ 537 Figure 11: Neighbor info 539 BSSID: The BSSID of this neighbor channel. 541 Channel Number: The channel number of this neighbor channel. 543 2rd channel offset: TBD. 545 Mean RSSI: The average signal strength of the channel. 547 Sta Intf: TBD. 549 AP Intf: TBD. 551 6. Security Considerations 553 This document is based on RFC5415/RFC5416 and it doesn't increase any 554 security risk. The security considerations of this document aligns 555 with RFC5415/5416. 557 7. IANA Considerations 559 The extension defined in this document need to extend IEEE 802.11 560 binding message element which is defined in RFC 5416. the 561 corresponding type values need to be defined by IANA. 563 8. Contributors 565 This draft is a joint effort from the following contributors: 567 Gang Chen: China Mobile chengang@chinamobile.com 569 Naibao Zhou: China Mobile zhounaibao@chinamobile.com 571 Chunju Shao: China Mobile shaochunju@chinamobile.com 573 Hao Wang: Huawei3Come hwang@h3c.com 575 Yakun Liu: AUTELAN liuyk@autelan.com 577 Xiaobo Zhang: GBCOM 579 Xiaolong Yu: Ruijie Networks 581 Song zhao: ZhiDaKang Communications 583 Yiwen Mo: ZhongTai Networks 585 9. Acknowledgements 587 The authors would like to thanks Ronald Bonica,Romascanu Dan, Benoit 588 Claise and Margaret Wasserman for their usefull suggestions. The 589 authors also thanks Dorothy Stanley's review and useful comments. 591 10. Normative References 593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 594 Requirement Levels", BCP 14, RFC 2119, March 1997. 596 [RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang, 597 "Objectives for Control and Provisioning of Wireless 598 Access Points (CAPWAP)", RFC 4564, July 2006. 600 [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And 601 Provisioning of Wireless Access Points (CAPWAP) Protocol 602 Specification", RFC 5415, March 2009. 604 [RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and 605 Provisioning of Wireless Access Points (CAPWAP) Protocol 606 Binding for IEEE 802.11", RFC 5416, March 2009. 608 Authors' Addresses 610 Yifan Chen 611 China Mobile 612 No.32 Xuanwumen West Street 613 Beijing 100053 614 China 616 Email: chenyifan@chinamobile.com 618 Dapeng Liu 619 China Mobile 620 No.32 Xuanwumen West Street 621 Beijing 100053 622 China 624 Email: liudapeng@chinamobile.com 626 Hui Deng 627 China Mobile 628 No.32 Xuanwumen West Street 629 Beijing 100053 630 China 632 Email: denghui@chinamobile.com 634 Lei Zhu 635 Huawei 636 No. 156, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan Beiqing Road, Haidian District 637 Beijing 100095 638 China 640 Email: lei.zhu@huawei.com