Presentation is loading. Please wait.

Presentation is loading. Please wait.

Doc.: IEEE 802.22-06/0239r0 Submission November 2006 Monique Brown, Motorola, Inc.Slide 1 Proposed Additions & Changes to Document 22-06-0196 (22-06-0238)

Similar presentations


Presentation on theme: "Doc.: IEEE 802.22-06/0239r0 Submission November 2006 Monique Brown, Motorola, Inc.Slide 1 Proposed Additions & Changes to Document 22-06-0196 (22-06-0238)"— Presentation transcript:

1 doc.: IEEE /0239r0 Submission November 2006 Monique Brown, Motorola, Inc.Slide 1 Proposed Additions & Changes to Document ( ) IEEE P Wireless RANs Date: Author: Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEEs name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEEs sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chairhttp://standards.ieee.org/guides/bylaws/sb-bylaws.pdf Carl R. StevensonCarl R. Stevenson as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at >

2 doc.: IEEE /0239r0 Submission November 2006 Monique Brown, Motorola, Inc.Slide 2 Note! The recommendations given here are based on the contents of doc The relevancy of some items may diminish depending on the outcome of this weeks sessions.

3 doc.: IEEE /0239r0 Submission November 2006 Monique Brown, Motorola, Inc.Slide 3 List of Topics Replace parent callsign with 48-bit IEEE MAC address More thoroughly define Subchannel Map field in beacon header Add channel width information Define the process of ceasing transmission

4 doc.: IEEE /0239r0 Submission November 2006 Monique Brown, Motorola, Inc.Slide 4 Addressing Proposal: Replace parent callsign in beacon header with 48-bit IEEE MAC address Why? –Satisfies IEEE 802 requirements –Reduces over-the-air transmission by 2 bytes –Still provides unique identifier for transmitting device Becomes source address of the beacon frame and is stored as a MAC constant (aAddress) MAC address can be mapped to parent callsign through external database

5 doc.: IEEE /0239r0 Submission November 2006 Monique Brown, Motorola, Inc.Slide 5 Changes to Subchannel Map Field Proposal: All unused bits shall be set to zero but shall not indicate unused channels Number of unused bits depends on channel width WRAN will use this information in conjunction with the proposed Channel Width subfield (see next slide) Also, propose to –Reduce the field length from six to five octets, as only five are needed * –Move channel-subchannel relationship text to PHY clause * Removing this octet along with the two octets removed through the use of the 48-bit IEEE MAC address reduces the minimum beacon length from 48 to 45 octets

6 doc.: IEEE /0239r0 Submission November 2006 Monique Brown, Motorola, Inc.Slide 6 New Channel Width Information Proposal: Add a 2-bit subfield (Channel Width) to the beacon header to indicate the width of the occupied channel being protected –Indicates whether the occupied channel width is 6, 7 or 8 MHz wide –WRAN will use this information to interpret the Subchannel Map field Add a new MIB attribute (macChannelWidth) to store this information

7 doc.: IEEE /0239r0 Submission November 2006 Monique Brown, Motorola, Inc.Slide 7 Procedure for Ceasing Transmission Case 1: The PPD stops transmitting abruptly Case 2: The PPD is aware it is about to cease transmission Case 3: An SPD stops transmitting abruptly Case 4: An SPD is aware it is about to cease transmission

8 doc.: IEEE /0239r0 Submission November 2006 Monique Brown, Motorola, Inc.Slide 8 If a PPD ceases transmission…(1) Case 1: The PPD stops transmitting abruptly Recall that the SPD is continuously monitoring the channel Once a pre-determined number of beacons are missed, the MAC will alert the next higher layer that the PPD is no longer protecting its subchannels of interest The behavior of the higher layer cannot be defined here, but we can place the hooks in the MAC to support any scenario(s) we want One possible scenario is that the SPD promotes itself to PPD

9 doc.: IEEE /0239r0 Submission November 2006 Monique Brown, Motorola, Inc.Slide 9 If a PPD ceases transmission… (2) Case 2: The PPD is aware it is about to cease transmission The PPD shall send out an indication in its last beacon * The SPD shall receive the indication and it will again be up to the next higher layer to decide what to do If the SPD does promote itself to PPD, –It shall initially transmit the same beacon payload as the original PPD –All SPDs shall see the new 48-bit IEEE MAC address * and should respond by transmitting a new RTS burst –This update process ensures that the new PPD has the most current subchannel information * See slide 12

10 doc.: IEEE /0239r0 Submission November 2006 Monique Brown, Motorola, Inc.Slide 10 If an SPD ceases transmission…(1) Case 1: The SPD stops transmitting abruptly The PPD shall continue to transmit any information associated with that SPD until the PPD itself ceases transmission

11 doc.: IEEE /0239r0 Submission November 2006 Monique Brown, Motorola, Inc.Slide 11 If an SPD ceases transmission…(2) Case 2: The SPD is aware it is about to cease transmission The SPD shall send a new RTS burst Upon receiving an ACK from the PPD, the SPD shall send out a beacon containing a notification that it is ceasing transmission * The PPD shall receive the notification and should remove all information corresponding to the SPD from its future beacons * See slide 12

12 doc.: IEEE /0239r0 Submission November 2006 Monique Brown, Motorola, Inc.Slide 12 To Support the Cease Tx Procedure Proposal: Add a 1-bit subfield (Cease Tx) to the beacon header to indicate whether the transmitting device plans to cease transmitting –A value of 1 indicates the device will stop transmitting –A value of 0 indicates that the device has no knowledge that it will stop transmitting Add a new MIB attribute (macPPDAddress) to store the 48-bit IEEE MAC address of the PPD –Allows an SPD to realize that the identity of the PPD has changed

13 doc.: IEEE /0239r0 Submission November 2006 Monique Brown, Motorola, Inc.Slide 13 Resulting Beacon Frame Structure Octets: n16 Parameter 1 Source Address LocationTimestampParameter 2 Parameter 3 Subchannel Map Frame Payload Message Integrity Code MHRMAC Payload MFR Bits: Channel WidthCease TxReservedKeep Out Zone MAC beacon frame format: Parameter 2 format: Changes are shown in red.


Download ppt "Doc.: IEEE 802.22-06/0239r0 Submission November 2006 Monique Brown, Motorola, Inc.Slide 1 Proposed Additions & Changes to Document 22-06-0196 (22-06-0238)"

Similar presentations


Ads by Google