February 2007doc.: IEEE 802.22-07/0093r0
IEEE P802.22
Wireless RANs
Date: 2007-02-06
Author(s):
Name / Company / Address / Phone / email
William Rose / WJR Consulting Inc. / 3 Tunxis Road, W. Hartford, CT06107 / 860-313-8098 /
Minutes
The call began at: 6:05 PM EST
Greg Buchwald, Vice Chairman led the meeting.
1.Attendance:
Chris Clantan
Soo-Young Chang
Yuchun Wu
Greg Buchwald
Steve Kuffner
David Mazzarese
Jerry Kalke
Zhou Wu
Monique Brown
Tian Yu
Steve Shellhammer
2.Approve Agenda - Completed
3.There were no minutes to approve.
4.Continue discussions on open items for draft document (See David Mazzarese’s email at end of agenda. Decisions and status of open items have been noted in Bold in email below))
- Discussion on RTS/ANP: It was decided that the group did not have enough time to discuss this and review it on the reflector. It was decided that a one week delay, along with email discussions on the reflector, is in order. David M. suggested reading his comments on collision, consecutive transmissions, etc.
- Monique Brown: Section 5.5 - diagram figure 5 has changed drastically – synch header and PHY header are removed. Question: The initialization bit is in the PHY header. If it is moved to the MAC header, does it cause a problem? David M – this is a good question – for the SPD to decide it is going to transmit, we may want to transmit a short PHY header to just send the initialization bit. After some discussion, it was decided to add one octet / byte for a short PHY header.
- Section 6.1.1 Table 1 with has many TBD’s in it. This table contains the parameters for TV channels, etc. Greg Buchwald will do this.
- Discussion on complex modulation text changes/additions
The discussion turned to the following item from David’s email. Original text from David M is in italics.
.RTS burst format &ANP burst format
a.RTS burst format and sequence(s)
b.ANP burst format and sequences(s)
c.Feasible turnaround (and processing) time (5 symbols = 0.5205 ms proposed)
d.Delay or no delay of SPD transmission after ACK?
David M: – should we allow one more beacon before the SPD sends it information? Soo-Young: For the case where another SPD wants to send a beacon, consider the case of we have a lot of SPDs and another …. We don’t need RTS for next frame, but for the next frames, another SPD may want to send aggregation data / payload information so we better have RTS for the next frame. David M: Confused about what is next frame. Soo- Young: After the SPD beacon, we can have a RTS period after an RTS beacon – not my understanding from the document. Monique: Better for the PPD to not be off the channel that long. For security, multiple SPD’s are not allowed to be sent in a row. Steve K: The beacon channel could be hijacked, so we do not have a receive period after a SPD beacon; the PPD always takes control. David M: After getting an RTS, it waits one frame to listen for the SPD – one frame delay. Questions: What if there are several SPDs – how do they avoid collisions? How do we decode it in time? Monique: Use multiple bits in the frame header. It must be more robust.
Steve Shellhammer: What if after a beacon there are multiple SPD’s? Is there a random backoff to stop collisions. Monique: Not sure if it is aloha or other random backoff. Right now it is aloha. Steve – that is fine. David: If same manufacturer they still need to come up in the same 40mS, and that is very low probability.
5.New business: None from the call; Greg indicated the proposed meeting schedule for the March Plenary. Goal is to have a draft for circulation at the end of the March, 2007 meeting.
6.Other business / topics of discussion: None
7.Next Call: Tuesday, February 13, 2007, 6PM EST
8.Call adjourned: 7:12PM EST
Submissionpage 1William Rose, WJR Consulting Inc.