Singapore TG3a Minutes - Welcome to Mentor€¦ · Web viewIEEE P802.15. Wireless Personal Area Networks. Project IEEE P802.15 Task Group 4a for Wireless Personal Area Networks

January 2006 IEEE P802.15-06-0062-01-004a/r2

IEEE P802.15Wireless Personal Area Networks

Project IEEE P802.15 Task Group 4a for Wireless Personal Area Networks (WPANs)

Title 802.15.4a Waikoloa Interim Meeting Minutes – Revision 2

Date Submitted

19 January 2006

Source [Patrick Houghton][Aether Wire & Location, Inc.][Sunnyvale, CA]

Voice: [408-400-0785]Fax: [408-400-0786]E-mail: [[email protected]]

Re: 802.15.4a Task Group Waikoloa Meeting Minutes

Abstract Minutes of Task Group 4a in Waikoloa

Purpose Minutes of Task Group 4a in Waikoloa

Notice This document has been prepared to assist the IEEE P802.15. 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 acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15.

CONTENTS

Session 1 – Monday, 16 January 2006 Session 2 – Monday, 16 January 2006Session 3 – Monday, 16 January 2006Session 4 – Tuesday, 17 January 2006Session 5 – Tuesday, 17 January 2006Session 6 – Tuesday, 17 January 2006Session 7 – Tuesday, 17 January 2006Session 8 – Wednesday, 18 January 2006Session 9 – Wednesday, 18 January 2006Session 10 – Wednesday, 18 January 2006Session 11 – Thursday, 19 January 2006Session 12 – Thursday, 19 January 2006Session 13 – Thursday, 19 January 2006

Submission Page 1 Patrick Houghton, Aether Wire

January 2006 IEEE P802.15-06-0062-01-004a/r2

MONDAY, 16 JANUARY 2006 – Session 1

Session 1 AM2

802.15 TG4a Minutes – 16 January 2006 – AM2 – Interim – Waikoloa, Hawaii

1.1 MEETING CALLED TO ORDER by Pat Kinney at 10:30am HST.

Chair: Pat KinneyCo-Technical Editor: Jay BainCo-Technical Editor: Ismail Lakkis Acting Secretary: Zafer Sahinoglu

Opening report, review of goals and agenda: Pat Kinney

Pat Kinney: The chair went over the agenda of the week. There will be no evening meetings.

1.1 DISCUSS MEETING OBJECTIVES: Pat Kinney

Review the outcome of the LB33 Categorizing and dividing the comments Discuss and resolve the comments Work with 802.19 to come up with a suitable coexistence strategy and CA document Work with 802.18 to address regulatory issues with Ofcom et al Discuss TG4a Activity Between Jan and Mar Meetings Revise Project Plan

1.2 REVIEW AND APPROVE AGENDA Document 05/699r3: Pat Kinney

Andy M: There was an approved motion that was not put into the draft yet. Therefore the approval is postponed until Tuesday morning.

1.3 LB 33 STATUS REPORTS FROM TECHNICAL EDITOR(S)

Bob reported the results as 126-YES, 41-No, 20-Abstain Return rate 79.6%, Absentee Rate: 10.7%, Affirm Rate: %75.45 (Bob) see Doc # 0017r0 All comments need to be addressed (Bob)

Doc # 0017r0 is presented by Pat that shows the circulation and LB procedure, the scope and purpose of the IEEE 802.15.4a. The purpose does not specify data rate. The chair presented the meeting objectives from Doc # 0017r0, slide 4. Progress since Vancouver is reported by the chair (Doc# 0017r0, slide 5).


January 2006 IEEE P802.15-06-0062-01-004a/r2

All comments will be addressed until no comment is resolvable anymore. Then, the process will go the sponsor ballot. The working group will forward the draft to the executive committee (Pat Kinney).

The chair asked the technical editors to report their status Vern: There were some NO votes because of the TBDs in the draft. If we were to polish

all the TBDs, we would be behind the schedule Jay: Comments will be consolidated into a single document and posted.

Pat Kinney (Chair) The most of the NO votes are from people not actively participating in TG4a. They did

not have a complete understanding of some sections in the draft and the reasoning behind because of missing information.

Analyzing the comments will show what can be done to make the draft better. There was a decent in the band-plan. We did our best to resolve it. It now rises again in

the LB33. We will resolve coexistence issues.

1.4 FORMATION OF BALLOT RESOLUTION COMMITTEE

The committee will consist of the technical editors Ranging Committee leaders: Vern, Zafer MAC leader: Jay Bain CSS leader: Rainer

We will break the comments into different groups in PM1 (Monday).

1.5 RANGING ANNEX REPORT

1.6 REGULATORY REPORT

Dr. Kohno as a response the chairs request: DAA is still under consideration. Latest information will be given in the afternoon session. DAA is not approved in Japan yet.

No objection to recess. The meeting recessed.

1.7 RECESS: Pat Kinney - recessed the group at 12:30pm HST.

---------------------------------

MONDAY, 16 JANUARY 2006 – Session 2


January 2006 IEEE P802.15-06-0062-01-004a/r2

Session 2 PM1

802.15 TG4a Minutes – 16 January 2006 – PM1 – Interim – Waikoloa, Hawaii

2.1 MEETING CALLED TO ORDER by Pat Kinney at 1:30pm HST.


Pat K: Called session of TG4a to order.

2.2 REGULATORY REPORT

Doc# 06/023r0 presented by Dr. Kohno, NICT – It summarized progress and schedule of Japanese regulations.

2.3 COMMENT RESOLUTION: CATEGORIZATION EFFORT

The chair invited Jay Bain (MAC technical editor) to explain the comment resolution process.

Jay explained the way the comments were collected and merged into a single file There are total 823 individual comments. Discussion on eliminating some of the existing options

Dr Kohno: Is it OK to take options out after we have higher than 75% approval? The chair (Pat Kinney): it is possible. If the removal of an option changes more NO

votes into YES than YES into NO, we should eliminate those options. Matt Wellborn: Having options does not add to the implementation cost Vern: Another way is to have a framework to support options. Andy: People did not understand that there was just one mandatory mode. We can

structure the whole thing differently and have a section that indicates the mandatory mode.

Pat: In chapter 5 it should be explained too. It should also inform the user of what we did and why we did.

Jay reported that he was currently working on formatting the comment database document. After this make-up effort is completed, the document will be posted officially. The doc # is 06-030r0

Discussion on DAA Vern: We should not be doing DAA. Some comments already complained about the

complexity of the prospective 4a radio.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Andy: I think the DAA stuff is beyond the scope of 4a. Joe: 4a does not allow frequency notching. The distinction between DAA and

coexistence should be made clear. Pat: What would it take us to do DAA Joe: Might be a very low granularity detect and avoid mechanism. You might want to

put hooks in and postpone it. Vern: For a non-coherent device DAA is not going to talk. Kohno-san: It can be shared in a common signaling mode. In a mandatory mode, such

an active DAA may not be needed. Andy: Let's just provide hooks for it. We should not be legislating mechanisms. Kai: I still don't know how to detect victim receivers. Vern: Let's just say it is not a cheap radio call that it is not 4a type of radio Joe: Simple transmission control should be mandatory. Simple intelligence gathering

should be optional. M. Wellborn: There are no definitions and requirements of DAA. DAA is outside the

scope of the standard. Pat: Coordinator determines the frequency. I am adding some MAC commands. I am

giving them the capability to adapt to future uses of DAA. Vern: As an engineer I am not keen on DAA, for standardization providing hooks is

better than skipping it. Jon Adams: If there is a simple hook, it would be great. There is an article that addresses

issues with the DAA. There are fundamental problems with the DAA to begin with. Yamaguchi-san: It is difficult to detect receivers. There are increasing number of

regulators asking for whether such a mechanism to prohibit transmissions when necessary. To make sure that coexistence happens after certain time, it is important to find a coexistence solution. Time table information can be provided and devices download it and schedule their transmissions. The question is how many devices can work in that way.

Pat: We are uniquely ad-hoc here and this suggestion may not support the ad-hoc case. Jon Adams: There was a system trying to make DAA, multi-mega watt radar. Timing is

a problem. It is very hard to know when the victim is ON or not. It is just a hard problem. Anything more than providing simple hooks would be premature.

Vern: The NO voter requested full protection. Can we get both sides happy? Jon Adams: A mechanism now not part of the standard picks the channel to use. We can

write an annex. STRAW POLL-1 (by Vern): Do we wish to empower the technical editors to resolve

the DAA comments by implementing the MAC commands/ management entity to allow detection of signals to be transmitted to controller and to stop transmitting?

o 20 YES, 7 NO Kohno-san: If 4a does not have DAA, it is still compliant to the US regulations. In Japan

and Europe (may be), it might not be the case. Therefore, it is not necessary, but recommended. We should be careful for the final decision. If 15.4a contradicts for example with 802.18, nobody will use 4a.

Vern: To solve a DAA problem in a 4a sub-group, it will take an undesirably long time.


January 2006 IEEE P802.15-06-0062-01-004a/r2

2.4 RECESS

Pat Kinney: Recessed meeting at 3:10pm HST until 3:40pm HST.

---------------------------------

SESSION 3 – MONDAY, 16 JANUARY 2006

Session 3 PM2




Pat K: Called session of TG4a to order.

3.2 UWB COMMENT RESOLUTION: CATEGORIZATION EFFORT

Matt Wellborn initiated the effort to categorize the comments. He quickly read through all the TR comments.

3.3 RECESS

Pat Kinney: Recessed meeting at 6:10pm HST until 8:00am HST tomorrow morning.

---------------------------------

SESSION 4 – TUESDAY, 17 JANUARY 2006

Session 4 AM1


January 2006 IEEE P802.15-06-0062-01-004a/r2

802.15 TG4a Minutes – 17 January 2006 – AM1 – Interim – Waikoloa, HAWAII


Chair: Pat KinneyCo-Technical Editor: Vern BrethourCo-Technical Editor: Ismail Lakkis Secretary: Patrick Houghton

Pat K: Pat Kinney calls session to order @ 8:07. Reviewed letter ballot results. We passed by a close margin. We are affirmed. We are addressing the comments. We want to make the draft a better draft, and go for fewer no votes. There will be some non-reconcilable no-votes, but we want to have a better standard. Yesterday, we went through about 70% of the comments and looked for common themes. DAA was one of the big issues. Today we’re going to get into more details. We may change some comments from E to TR and TR to E, etc. We will come up with mechanisms to resolve issues. For some of the major issues, we will send out email straw polls. We will put a short time frame on these straw polls and give 2 to 3 days time limit. We will use this as input to the technical editors. Almost everybody who voted “NO” do not attend these meetings regularly. We need to get their input even if they are not attending our meetings. Will now turn floor to Vern Brethour.

Passed floor to Vern Brethour for discussion on letter ballot comments.

4.2 LETTER BALLOT COMMENTS

Vern Brethour: Need to get a comment ID structure. Document 06/030r1. Has a comment ID field, which is upgraded from yesterday. Yesterday, Matt gave us an overview of comments. Yesterday, we sorted on TR (technical with required response). Some people used TR for things that were really E (editorial comments). Today, we changed the ratings to be more reflective.

Yesterday, there were a lot of “NO” votes related to band plan. There were some discussions with Matt and Ismail regarding resolving the issues on band plan. Ismail will present on his responses to bandplan. We also need to respond to no-voters regarding too many options. We need to do an email straw poll on that. We didn’t approve minutes from Vancouver. The key part of Vancouver was the framework we set up. Vern’s original proposal was shot down, but Matt’s compromise passed unanimously. The minutes captured Matt’s compromise language on Vern’s framework, but didn’t get put into the spec.

Asked for comments on where we are. No comments, so put Doc. 06/030r1.

Matt: Suggest we capture the discussion. Yesterday was too free form.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Vern: We will capture on the document. There are 800 editorial comments, so do not want to get bogged down on these. Want to focus on TR.

Matt: Some of the page numbers and section numbers are wrong in the comments. Is there a master list of comments? T to E changes can be done by the technical editors off-line. May also be best to sort by page number at this time.

Vern: This is sorted someway, but not sure how.

Matt: Suggest by page number.

Vern: Asked secretary to capture categories Too many options Stuff missing Aloha Protocol issues UWB Bandplan Exceeding the PAR 15.4-2003 vs. 15.4b issues CSS Mandatory Channel Coexistence General PHY MAC Issues UWB Issue Sub GHz

Jay: Suggest we keep a record then make changes in the data base and capture in minutes.

Pat K: Would prefer that you keep a separate data base.

Matt: Suggest we have an additional column.

Vern: Running out of space on screen.

Michael: There are also some E that should be T or TR.

Vern: Changed 357, 358, 359, 369 from TR to E. There are also some comments that are identical, we could collapse. This is why we have over 800 comments. There are a number of these occurrences.

Matt: Don’t worry about making the comment database pretty. When you resolve one, you get the other comment number for free.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Vern: When we get down to Monique’s comment, regarding broken links. Lots of these editorial comments.

Vern: Regarding Comment 507, this is an issue on sub-GHz, but more of an editorial.

Pat K: Maybe we should have definition of different UWB PHYs in description.

Matt: Suggest we go the other way, just becomes another line in the table of center frequencies. The only technical difference was a different PSD limit.

Vern: We have about a dozen comments on band plan.

Matt: If we start dealing with sub-GHz, then we need to deal with other frequency bands that are not allowed in some areas.

Andy: Purely a regulatory matter. No harm in having sub-GHz as an option.

Vern: We have agreement in here on this. Just concerned with how others view this.

Matt: We need to deal with this in a Framework document. We could see classes of devices that implement different center frequencies. There are bandplans that fit different regulatory environments around the world. Maybe this “Framework” is in the overview section. There should also be a “Pulse shape” section in the framework. Need to layout in the Framework section. People are overwhelmed by number of options, because they don’t understand how they fit together. Some of these options can be handled in a very general way.

Jay: This is a good suggestion.

Pat K: This is actually dealing with the organization of the document. Keeps the reader from jumping right into the details.

Matt: More of a powerpoint for the TG4a.

Pat K: There is a part in Clause 5. We don’t put any shells in Clause 5.

Jay: So we will put a detailed comment in Clause 6. In the early part of 6 is where this belongs.

Matt: Is there any general comments on a framework?

Pat K: Coming down to some good ideas. Would like Jay to capture some of these ideas for changing the draft.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Vern: We are now on 507. How to handle sub-GHz is how we launched this much larger discussion. Oyvind is picking at one part of a weakness in our spec. To fix this, we are making a framework on Bandplan, Pulseshapes, data rates, preambles. Any other general classes?

Matt: Think FEC is a good addition. This should be a free standing category in the framework.

Jay: Asked Matt to do the first draft of the document.

Matt: Will do this Framework.

Jay: Will incorporate into Draft.

Matt: Suggest a framework section on ranging mechanisms.

Vern: We need a framework to say ranging and private ranging.

Mike: Public ranging vs. private ranging.

Vern: Monique is insisting on this.

Zafer: Private and non-private are in the draft.

Matt: What about TOA vs. TDOA?

Vern: Prefer not to have that in the Framework.

Matt: The Framework is not a list, but a hierarchy. Should define how to get from default to option mode. Why do we have 14 pre-ambles, etc. Need to define how to get from the default state to a option state.

Pat K: There are two different misunderstandings, one is where we have an error, the other is where we mis-stated.

Vern: We have a framework and within Framework is bandplan, pulse-shape, preamble, FEC, public vs. private, ranging, data rates.

Jay: Matt will generate document number and post this frame work. We will have this document number in the proposed resolution.

Vern: Comment 849 is answered by having a Framework.

Pat K: Clause 5 is informational. It is a way to get to the right part of the document.

Jay: Need to start capturing the responses to these comments.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Matt: Framework document is 06/039r0.

Jay: Going back to 849. In response, we agree in principle. See document 06/039r0.

Vern: The last sentence in 849 says we have exceeded the PAR.

Matt: In the framework, we are looking at the overall goals. Part is to have a low-complexity mandatory mode that has flexibility to meet regulatory restrictions, coexistence, scalability, etc. Will add an introduction in the framework that addresses this.

Vern: Agree, but how do we handle the people that look at the options and see those options as infringing on their turf.

Matt: Maybe we had a set of applications that called for more data rate. Need to reference the CFA.

Ismail: Highest data rate is 26 Mbits, not the speeds of other WPAN PHYs.

Matt: We need to define that we are not doing high data rate PHY and need to emphasize the low duty cycle for that high data rates.

Vern: Going on, there are lots of comments on “Missing Stuff”. We agree with this. We need to fix. Lots of TR’s are E comments. Our draft refers to 15.4b as if it was a spec. This is upsetting a number of the people in 15.4b.

Patrick: Isn’t this more of an editorial not TR?

Vern: We need to make a statement that this is running off of 15.4b, not 15.4, so we need to be clear about this and this will clear up about 20 comments. This has to be clear that it is running off of 15.4b. By the time we are done, 15.4b will be done.

Michael: Still would consider it an E, not TR.

Vern: Many comments about TBDs. We need to fix these – we agree.

Matt: Jason is complaining about Zigbee having multiple modes, but the market doesn’t think this is a problem.

Pat K: Having separate bands is also the case in 802.16, 802.11 as well as 802.15.4.

Matt: This is best captured in the framework.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Pat K: Suggest, we reference 15.4 then change back to 15.4b when they pass. It’s more work, but cleaner.

Vern: Comment 836 is regarding CSS, which is one of a number of TRs on CSS.

Jay: Column N is topic.

Pat K: What about column L & M?

Jay: Tool came up with this. Not sure what they are for.

Vern: 288, 465, 659, Accept or accept in principle.

Ismail: comment 509 is regarding framework and is addressed there. Regarding rolling sub GHz into other UWB.

Vern: Comment 510, 511 is regarding low and high-band UWB. We disagree with this is having common low-band. However, the low-band is not available worldwide. Oyvind is suggesting a high-band device doesn’t have to implement low-band. We need to discuss this. There is a suggestion to move mandatory band to the high-UWB band. Suggest that Ismail can deal with this.

Matt: Comment 512 can be done by having a “Band Group” or differentiate frequency band from channel.

Jay: This is really a MAC issue.

Matt: We are overloading these terms. We need to clean up. This is editorial.

Pat K: We should make sure we are in compliance with the IEEE dictionary.

Vern: 513, and 514, we agree in principle.

Vern: Matt’s comment 857 is going to be dealt with in Ismail’s session. The topic is UWB.

Vern: Matt’s comment 858 is also regarding bandplan, as is Naiel’s comment 895.

Pat K: 896 is again regarding mandatory channel – suggestion for high UWB band for mandatory channel.

Matt: Regarding comment 85, we agree in principle. We need to have a consistent definition for bandwidth. We maybe should use 10dB for bandwidth instead of 3dB.

Pat K: Suggest we handle one more comment then recess.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Vern: Patrick needs to address comment 86 – is there a country where sub-GHz UWB Phy is legal?

Pat K: Recess until 10:30am.

4.3 RECESS: Pat Kinney recessed the meeting at 10:05am HST until 10:30am for AM2.

---------------------------------


Session 5 AM2




Pat Kinney: Passed floor to Ismail for comment resolution.

5.2 COMMENT RESOLUTION

Ismail: Now on Comment 87 by Ed Callaway regarding 6.1.2.2.

Jay: Channel pages are not clear right now. His comment claims we are missing some parts. This is editorial comment.

Ismail: Comment 390 regarding the same section. Calls this a TR.

Pat K: This is 15.4b vs. 15.4. We accept this in principle.

Ismail: 391 is more on CSS.

Jay: Rainer needs to resolve this.

Ismail: Comment 579 on Bandplan.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Matt: This is not really for Framework, this is for UWB Bandplan.

Ismail: Comment 580 is Framework, comment 779 is UWB Bandplan. 502 is Bandplan.

Pat K: Consider this to be coexistence as well as bandplan. Would like to have both. This is bandplan itself, but also coexistence. This is more complex, but there are a number of things being addressed in this comment.

Ismail: Comment 16 and 892, 852, 840, 841, 884 are all UWB Bandplan, no coexistence and no framework issues. 837 is bandplan. 289, 290 are missing stuff (accept in principle).

Ismail: Comment 863 – On missing SIFS and MIFS. General PHY issues.

Ismail: Comment 4 – data rate should be optional.

Pat K: This is a MAC issue. This is only mandated by this PHY. We should accept this in principle.

Ismail: 596 – missing stuff. 597 – parameter to primitive.

Pat K: 597 gets back to optional primitive issues – MAC issues.

Ismail: 598 – missing stuff.

Ismail: 674 – Primitives of MAC.

Pat K: Definitely MAC issues.


Ismail: 91 – more missing stuff.

Ismail: 476 – general PHY.

Ismail: 496 is CSS.

Ismail: 589, 881 – missing stuff.

Ismail: 387, 388 – 4b vs. 4 – accept in principle.

Ismail: 389 – UWB Bandplan



January 2006 IEEE P802.15-06-0062-01-004a/r2

Ismail: 5 – MAC issues.

Zafer: Is this for backwards compatibility?

Jay: Is the implication that this only applies with UWB. We agree. We can change that this only applies if UWB.

Pat K: Suggest we just accept the comments.


Ismail: 97 – is this missing stuff?

Vern: The content to these bits are in the minutes of Vancouver, but they never made it to the draft. This is also ranging.

Ismail: 476 is CSS.

Ismail: 397 and 398 are really Editorial, not TR.

Ismail: 775 Zafer suggests combining two octets to one octet.

Pat K: We didn’t agree to change to one octet. Should we put this under General PHY?

Ismail: 399 – 15.4 vs. 15.4b. Accept in principle.

Ismail: 523 – Oyvind is concerned about sending messages back. Default should be default preamble?

Jay: Don’t really know length of preamble, so responder will know how to respond.

Pat K: Believe this is a framework issue. Oyvind doesn’t seem to understand how we are working.

Matt: This should be addressed in the Preamble section of the Framework.

Ismail: 525 – this is editorial.

Ismail: 498 – close to Zafer’s comment. General PHY.

Ismail: 655 – same thing as 498 (both Nanotron).

Ismail: 689 – Laurent wants clarity on Symbol – specify in microseconds? General PHY.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Ismail: 526 and 527 – Oyvind. General PHY and MAC issues.

Ismail: 528 – Oyvind is Editorial, not TR.

Ismail: 529 – Accept and clarify definition?

Vern: This should be under ranging. Most of the preamble issues are regarding ranging.

Pat K: We should say we accept this in principle.

Ismail: 530 – 15.4b vs. 15.4 issue. Accept in principle.

Ismail: 877, 878 are both General PHY.

Ismail: 6 is really editorial.

Ismail: 7 – general PHY.

Pat K: Agree in principle to 7.


Ismail: 602 – General PHY.

Ismail: 603 – General PHY and CSS – two different comments in here.

Ismail: 116 – mostly missing stuff, but also ranging and General PHY. Suggest General PHY.

Ismail: 400 is really editorial.

Ismail: 401 – missing stuff

Ismail: 402 – General PHY

Pat K: Suggest we accept in principle. 2.4GHz PHY should be exempt from this.

Ismail: 403 – really editorial.

Ismail: 468 – This is CSS issue. Rainer needs to address.

Ismail: 531, 704 – Oyvind & Chipcon says CSS violates the PAR. This should be a PAR issue.

Pat K: Will resolve PAR issues.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Ismail: 118 – CSS issue and also General PHY.

Ismail: 146 – CSS vs UWB?

Pat K: Looks like Framework issue.

Ismail: 349 – 15.4b vs. 15.4 issue. Accept in principle.

Ismail: 404 – Editorial.

Ismail: 532 – General PHY

Ismail: 533 – really a technical comment – not editorial. This is a CSS issue.

Ismail: 120 – CSS Issue.

Ismail: 405, 534, 535, 536 – looks like a CSS issue.

Vern: We should flag 537 as a tool problem so we can explore issue with Oyvind.

Ismail 129, 408 – CSS issue.

Ismail: 409 – Missing stuff.

Ismail: 410 – CSS issue.

Ismail: 411 – Editorial not TR

Ismail: 716, 717, 412, 413, 662, 663, 245, 414, 466, 467, 415, 416 – CSS Issue

Ismail: 581, 582 – PAR Issues, but may also be tool problem

Ismail: 469 – UWB Bandplan.

Ismail: 669 – PAR issue.

Ismail: 483 – CSS issue.

Ismail: 484 – CSS issue

Ismail: 605 – Framework

Ismail: 606 – PAR issues


January 2006 IEEE P802.15-06-0062-01-004a/r2

Ismail: 247 – CSS Issue

Ismail: 250 – Framework issue

Ismail: 778 – PAR issue.

Ismail: 417, 418 – CSS issue


Ismail: 690 – Laurent has a Ranging issue.

Vern: He has an issue with keeping his crystal stable. We will get back to him.

Ismail: 539 – Chipcon has issue with General PHY

Matt: Talking about symbol itself, not length.

Vern: Suggest we reject this one. He says it costs too much, we don’t believe it will cost that much.

Ismail: 540, 541 – Missing stuff and Ranging

Zafer: Suggest we reject. Bad idea.

Ismail: 859 – Matt issue. This is UWB General.

Matt: We talked about this yesterday. There are good reasons to have low PRFs. We can leave this open, but not require we generate full amplitude.

Vern: We were planning on having an email straw poll to judge support for this feature.

Ismail: 485 – UWB issue

Ismail: 486, 251 – framework

Ismail: 251, 499, 656 – Framework

Matt: May be better to use a parameterized table. Most people don’t like 8 significant digits.

Ismail: 584 – Ranging issue.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Vern: 758 is marked editorial, but looks like TR. Lots of issues, but handled in other comments as well.

Ismail: 542, 421, 487, 585 – Ranging issue.

Ismail: 422 – Ranging issue

Vern: Suggest we accept this one.

Ismail: 488 – Ranging

Vern: Suggest we reject

Pat K: Proposed reject – we want to be careful in rejects.

Vern: Jay wants to have us vote for “Proposed Rejects”.

Ismail: 607 – Missing Stuff and Ranging

Ismail: 156 – General UWB

Ismail: 254 – Ranging

Zafer: Suggest we accept in principle, but appears more editorial.

Ismail: 423 – UWB issue

Ismail: 424 – framework

Ismail: 425 – UWB Issues for Phil Orlik

Ismail: 426 – UWB Issue

Ismail: 470 – UWB Issue – pulse shape and chipping rates.

Ismail: 490 – Aloha Protocol issue

Ismail: 702 – NICT suggests using time interleaved preamble to improve ranging accuracy – Ranging issue.

Pat K: Suggest we make this informative text.

Michael: Not sure if this is true.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Pat K: We should put this as UWB General and move on.

Ismail: 427 – MAC issue

Jay: Not sure if it belongs in that section.

Ismail: 428 – CCA and Aloha we will call the same thing.

Pat K: Called Recess at 12:35pm until 1:30pm.

5.3 RECESS: Pat Kinney recessed the meeting at 12:35pm HST

---------------------------------


Session 6 PM1

802.15 TG4a Minutes – 17 January 2006 – PM1 – Interim – Waikoloa, HAWAII


Chair: Pat KinneyCo-Technical Editor: Jay BainCo-Technical Editor: Ismail Lakkis Secretary: Patrick Houghton

Pat K: Passed floor to Jay Bain for comment resolution. Still focusing on T and TR comments. This is a slight change – we were supposed to be talking about CSS.


Jay Bain: 861 – UWB General.

Jay: 136 – Framework

Jay: 429, 430 – UWB General

Jay: 860 – UWB General



January 2006 IEEE P802.15-06-0062-01-004a/r2


Zafer: This is Phil’s comment which is in line with Matt’s comment. Suggest we accept

Jay: 432, 549 –UWB General

Pat K: Suggest we agree in principle to 549.


Pat K: Suggest this is more of an editorial issue, but leave as TR


Jay: 862 – Bandplan



Jay: 491 – Missing Stuff

Jay: 493, 494, 609 – Framework

Pat K: 609 also touches on too many options.





Jay: 434 – Really an editorial comment

Jay: 435, 436 – UWB General – need a technical definition

Jay: 438 – really an Editorial

Jay: 439 – missing stuff

Jay: 440 – Editorial


January 2006 IEEE P802.15-06-0062-01-004a/r2




Jay: 866 – Framework & UWB

Jay: 867 – UWB General and CSS


Jay: 611 – should be 6.8a – Similar to 610 comment – Framework

Jay: 442, 443, 444 – UWB General

Pat K: Recessed for 15 minutes for TG3a vote at 2:10pm.

---------------------------------

Jay Bain: TG3a is still in discussion

Pat K: Reconvened meeting at 2:15pm

Jay: 868 – Too many options.

Pat K: We will send out a straw poll on Chaos.


Jay: 727 – MAC issue


Jay: 729 – UWB Chaotic



Pat K: Recess for 15 minutes for TG3a Vote. Recessed meeting at 2:20pm

--------------------------------------


January 2006 IEEE P802.15-06-0062-01-004a/r2

Pat K: Reconvened meeting at 2:30pm


Jay: 448, 449 – Missing Stuff

Jay: 451, 733, 450 – UWB Chaotic


Zafer: this is PHY spreading and hopping sequences.




Jay: 695 – UWB General and Framework

Zafer: This is regarding a Reed Solomon Decoder.

Jay: 552, 870 – UWB General and Framework

Jay: 492, 735, 871 – Missing stuff


Jay: 1 – Missing stuff


Jay: 150, 613 – UWB General and General PHY

Pat K: Not sure if FEC helps with small packets.


Jay: 455 – Really an editorial




January 2006 IEEE P802.15-06-0062-01-004a/r2

Jay: 873 – Accept in principle – Sub GHz

Jay: 495, 616 – Sub GHz – is this allowed anywhere?

Patrick: Will resolve



Pat K: Believe 614 also belongs in MAC

Jay: 457 is an editorial comment

Jay: 666 – CSS issue


Jay: 875 – proposed reject – UWB General

Jay: 876 – This text is from 15.4, proposed reject – General PHY

Jay: 738 – Proposed reject – General PHY

Jay: 153 – Accept in principle – UWB General

Jay: 155 – Agee to change to absolute power – General PHY

Jay: 458 – really an editorial comment

Jay: 9, 740, 157, 701, 880, 890, 891, 459 – CCA issue (Aloha)

Jay: 557, 707 – Framework and MAC

Jay: 460, 461, 558 – MAC

Jay: 708 – this is an accepted 15.4 baseline term. Proposed reject.

Jay: 709, 19 – MAC issue

Jay: 462 – Editorial issue

Jay: 559 – missing stuff for ranging


January 2006 IEEE P802.15-06-0062-01-004a/r2

Jay: 11 – MAC



Jay: 22 – Missing Stuff, ranging

Jay: 710 – MAC

Jay: 13 – missing stuff and ranging


Jay: 711 – Ranging issue

Jay: 204, 206 – Ranging

Jay: 164 – Ranging

Jay: 24 – 4b vs.4

Jay: 657 – Ranging

Jay: 742 – MAC

Jay: 208, 209 – Ranging

Jay: 165, 883– MAC issues, need to fix the columns

Zafer: this is MAC issue. The table needs to be fixed.

Jay: 33 – MAC and Ranging

Jay: 166 – General PHY and MAC issue

Vern: Whoever resolves this needs to go to the section and figure out why this is ambiguous.Pat K: Now recess. We will drop comment resolution until tomorrow.

6.3 RECESS: Pat Kinney recessed the meeting at 3:35pm HST. We will reconvene at 4:00pm


January 2006 IEEE P802.15-06-0062-01-004a/r2

---------------------------------


Session 7 PM2




Pat Kinney: Opened the floor for ranging informative annex. At 5pm we have joint meeting with 802.15 coexistence TAG. Agenda for tomorrow shows us starting at 8:30am. We start at 8am tomorrow. There will be a new Agenda posted. Now Ivan Reide will present on location systems.

Passed floor to Ivan Reide

7.2 UWB RANGING AND LOCATION

Ivan: Presented document 06/033r0 – Ranging and Location.

Joe Decuir: Question on Slide with Clock Independent FFD Ranging.

Ivan: If don’t know home time, then ask when you received signal and compensate.

Matt: You are going to estimate frequency error between two clocks.

Ivan: Don’t want to wait too long.

Patrick: We do our radio like this, so we can validate that it works well.

Ismail: What is the time of round trip?

Ivan: Transaction should take place in a millisecond or so, so the clock shouldn’t drift much.

Vern: What is your motivation? Is this informational for an informational annex?


January 2006 IEEE P802.15-06-0062-01-004a/r2

Ivan: I am a user of these devices, so would like to see this functionality. The application could do location if you send this information.

Vern: Would you be happy if everything you got came from a single vendor?

Ivan: No. Would like to see this as a standard, not a proprietary scheme.

Vern: Then you are enlarging our scope. We had this as an additional feature for FFDs.

Ivan: We can handle clock distribution with a broadcast. As far as I am concerned, you can put this in an informational annex. But would like to see the primitives available.

Pat K: We haven’t changed our protocol at all if you multicast the time information.

Ivan: Very little change. Would like to see time-stamp the message.

Zafer: Don’t we already have time stamping?

Pat K: Don’t know how accurate that is.

Zafer: What additional is required?

Ivan: Not much. Just need to have people look at the spec to see what has to do.

Pat K: Any questions or comments? This is up on the website right now.

Ivan: There is also a mathcad simulation as well.

Pat K: Not on the system.

Ivan: Not able to put in a powerpoint, but Pat K has a copy.

Pat K: If you want the mathcad version, see me or Ivan.

Pat K: Need to have Steve Shellhammer for coexistence discussion, so we can give the floor to Camillo Gentile on an informational annex. Passed floor to Camillo Gentile.

7.3 ANNEX D – LOCATION TOPICS

Camillo: Don’t have a document number yet. Presented preliminary document. Will have an hour on Thursday to go over this document.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Pat K: The purpose of this annex is to educate the reader of this standard to the applications they can do. It is purely informational – there are no “shalls”.

Zafer: Is this document still open to contributions?

Pat K: Yes, since it is informative. We can keep adding until we have a standard.

Pat K: We are now in a joint meeting. This is informal. We spent a lot of time yesterday talking about coexistence. We also need agreements to our two groups as far as coexistence with what. Would like Steve’s thoughts on a higher level. Passed floor to Steve Shellhammer for discussion on coexistence.

7.4 COEXISTENCE

Steve: The rules tell you what you have to do. Can pull up 802 rules on coexistence. Everything else is optional. Need to coexist with other approved standards in 802. If you are operating in a band that is shared by other approved standard, then you need to demonstrate coexistence.

Vern: Being willing to coexist with IEEE standards, other devices have no standing? Is that beyond the scope of 802.19.

Steve: No one is saying that everything has to work with everything else.

Tom Seip: Not required to coexist with non-IEEE standards, but it helps if you pay attention to them.

Joe Decuir: Paying attention to other non-IEEE standards makes sense from an end-user standpoint.

Steve: This group can vote to pay attention to non-IEEE standards, but 802.19 will not require this.

Pat K: There is a difference between regulatory and coexistence. For example 802.16 is one that may coexist.

Steve: 802.16 is approved from DC to light so this is unique.

Pat K: Have some good examples in 802.11b.

Joe Decuir: Something that is more regulatory than coexistence, cell phone manufacturers want 3GHz band for 3G.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Ismail: 802.16 is DC to 11 GHz. How does this coexist.

Steve: Seems like the actual standard is done by the Wimax community.

Andy McGowan: We should look at 802.11 for coexistence.

Pat K: Detect and avoid has been thrown at us by Europe and Japan.

Andy: There are two different levels of coexistence. There is low duty cycle and detect and avoid.

Pat K: Is it 1% duty cycle or 10% duty cycle?

Andy: Still under discussion.

Pat K: What duty cycle did 802.15.4b use?

Steve: looking at 868 MHz and 915 MHz. Used 10% for 915 MHz. In all these, you will get more arguments for assumptions. 802.15.4b did not update their coexistence document, so we are not happy about that.

John McCorkle: DAA has not been proven. It is not in any regulations. It is a moving target. There are technical disputes in the ITU whether it can be done at all in a low-cost device.

Andy: We are talking about putting hooks in for DAA.

Joe Decuir: Dr. Kohno is asking to make a presentation tomorrow. There are some things we can do, but we need to add some frames. Explicit model is to take what is in 802.11.h and simplify.

Pat K: We are not trying to describe or implement DAA.

Ismail: DAA is meaningful if we plan to make multiple channels mandatory. Since we are only one mandatory band, implementing DAA does not make any sense.

Pat K: We can tell the system to shut down.

Kohno: We have a session tomorrow morning on DAA. We need to focus on coexistence with other radios, not just IEEE approved ones.

Pat K: That gets to what Andy McGowan wanted.

Andy: For discussion on DAA, have a woman working for him that is running that discussion reflector. Let me know and I’ll get you on the reflector.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Pat K: 802.11h addressed radar by saying detecting radar is beyond their scope.

Andy: Problem with radar is to work with radar people to get a DAA method that is acceptable to them.

John McCorkle: We went over a lot of this yesterday. There was a paper given in 3a that talked about antenna sizes and other issues. Not going to detect a victim with a dish when you have a small antenna.

Andy: Systems that you have to detect are not outdoor systems, they are indoor systems.

Pat K: UWB is limited to indoor in Europe?

Andy: Yes. There are no fixed outdoor devices.

Vern: What if I have an optional device that can do DAA?

Steve: Doesn’t matter what I think. I have one vote from TAG.

Pat K: 802 executive committee will look at coexistence document.

Steve: CA document is to make the information available in the voting pool.

Tom Seip: We do not make a value judgement

Vern: If I have a DAA package that is all optional that is very complex and works very well. How are you going to tell me I’m not a standard?

Steve: Never said will not make this a standard. You said you made a very good CA document with an optional system. Will probably vote for it.

Tom Seip: will probably not like an optional solution.

Steve: The working group decides which systems need to be analyzed and the TAG provides suggestions.

Pat K: May be worthwhile to have a hook in the MAC to limit duty cycle. Spatial separation and interferer need to be considered. 802.16 and ECMA 368 may be interesting since that is an approved standard.

Matt: Also need to look at other standards for sub-GHz.

Tom Seip: Coexistence means you have to have “use” language.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Steve: Wimax doesn’t listen to anything, they just transmit.

Andy: Will send the email address for details of duty cycles of Wimax systems.

Pat K: We are similar in power levels to ECMA 368, so there are a lot of things to describe and address.

Steve: Encourage you to work with the TAG before the next document gets published.

Matt: Is the CA document letter balloted?

Steve: Don’t vote on the CA document per se. You vote on the draft. The CA document is a separate document. 15.4b puts it in as an informative annex, which means that it exists for perpetuity.

Pat K: What do we do to avoid the wrath of the TAG.

Steve: Keep us informed.

Pat K: We had some good discussion on regulatory and coexistence. Any parting comments? We are about to recess for the day.

It is now 6:10pm. We recess for until tomorrow morning at 8am in Queen Rooms 5 and 6.

7.5 RECESS: Pat Kinney recessed the meeting at 6:10pm HST.

---------------------------------

SESSION 8 – WEDNESDAY, 18 JANUARY 2006

Session 8 AM1



Chair: Pat KinneyCo-Technical Editor: Vern BrethourCo-Technical Editor: Jay Bain


January 2006 IEEE P802.15-06-0062-01-004a/r2

Secretary: Patrick Houghton

Pat Kinney: Have a presentation on improving data performance, then we have a presentation by Prof. Kohno on regulatory. We have a plenary where the discussion will be on 3a. This afternoon, we are back to comment resolution with Vern Brethour.

Passed floor to Serhat Erkucuk for Code Shift Keying for UWB-PHY

8.2 STUDY OF PER PERFORMANCES WITH MULTIPLE PICONETS

Serhat Erkucuk: Presented Document 05/045r0. This is for information only.

Pat K: Any questions or comments?

Ismail: You are using the guard bands for additional data?

Serhat: Yes

Ismail: You need to take into account that the collision will never take place the way you describe it. If you look at slide 10 in case 2, the slot S is not in a fixed position for the two users, so you will not have the collisions this way.

Serhat: The collisions are randomized. They do not utilize the whole symbol time.

Ismail: It makes the interference better, but it makes the multipath mitigation worse, so it is a trade off.

Serhat: Agree.

Andy M: Why is the instantaneous packet error rate such an important criteria?

Serhat: For the continuous PER, the importance of instantaneous PER – we are having two SOPs starting at the same time, so packet errors may be more.

Andy: We are using aloha, so there is vanishing probability that we will have collisions. Wouldn’t you need to take into account average PER?

Serhat: With Aloha, the PER loss may be compensated.

Andy: Agree that instantaneous PER may be better, just not sure it will be relevant.

Serhat: In the beginning, the PER losses may be compensated.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Pat K: Any other questions or comments? Hearing and seeing none, pass the floor to Prof. Kohno for discussion on coexistence and regulatory

8.3 REGULATORY AND COEXITENCE ISSUES

Kohno: Presented document 6/049r0.

Ismail: What is LDC?

Kohno: Low Duty Cycle operation. This is not yet defined in Europe and Japan. This has been postponed until April in Europe.

Kohno: Passed floor to Joe Decuir for further discussion on DAA.

Joe: Presented Document 06/047r0 on SIMPLE DAA SUPPORT

Pat K: The current 802.14 MAC has primitives that are similar to this. In a FFD, can do an energy detect or scan. Have the primitives to collect information from a FFD.

Kohno: Any questions for Joe?

Bin Zhen: difficult for RFD to listen to channel?

Joe: Need to decide which is optional and what is required. Not required in all conditions and countries. We should not require to be implemented in all devices. May only require the piconet controller to do the listening.

Pat K: In 15.4, energy detect is only for FFDs. Sensor can be a RFD as well, so recommend that we put this feature on FFDs. Wisair only puts DAA on FFDs as well.

Joe: Piconet controllers as FFDs can ask other piconet controllers what they see. A revision of ECMA work is to transfer information on victim receivers through the network.

Kohno: Currently, there is necessity of implementation of DAA is mainly for piconet coordinator, which is a FFD.

Kohno: continued with document 06/049r0, slide 10.

Michael: 4G signals are going to be everywhere, so you will be detected everywhere you are.

Kohno: Cellular operators are a licensed system, which need to be protected. Priority is for licensed operators. The level of the 4G signal is not that high, then don’t need to worry about detection.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Joe: Mobile operators are the biggest opponents. We can have a false detection of a distant signal, but we will easily see a remote user with almost a watt of power.

Ismail: There is no way if I can tell if there is an interferer with energy detector, unless we detect something that is 50dB higher than us. Don’t see how this can be done at low cost.

Joe: This is technically a hard problem. No way we will have this in a low cost 4a device.

Michael: If we put the option in the standard, then regulators will look at that and not let the equipment in the country without that option. You can only use that band where 4G is not there.

Kohno: Need to look at it from the perspective of the 4G operator. If you can provide a better scenario for compromise, can take that idea to the regulators.

Michael: If put GPS receiver in FFD and just turn off the radio if in a city with 4G.

Ismail: We can put the hooks as Joe described in his presentation.

Pat K: The primitives across the stack are straightforward. How we do the DAA is out of scope.

Joe: Out of scope of the normative part of the standard. But we can put an informative part of the standard in the regulatory annex or a zigbee white paper.

Andy M: An annex can draw comments and no-votes.

Joe: If we don’t have it, we will still get comments and no-votes.

Pat K: We need to make a good attempt to defend our position. Standard doesn’t tell you how to implement regulatory acceptance. All standard tells you how to talk among different devices and how to share information.

Kohno: So we have 25 minutes more. We should describe coexistence issues. There are a number of technical requirements and comments.

Joe: You mentioned that they may have standards for LDC performance in Japan? Will Japan have standards for DAA?

Kohno: At the end of March, we will have some regulation, but we can continue to discuss DAA. Hopefully by the end the year, we will have firm rules.

Joe: If there are draft versions, can you bring them here, so we can use them for reference?

Kohno: On Slide 20 is some language that can be used as an example.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Pat K: This document is incorrectly put on the server. It has some Japanese text. It is looking at the master in Japanese. Regarding LDC, we don’t know what the threshold is yet. Right now there is a 1% duty cycle on 868 MHz devices in Europe. This is to assist in coexistence. This limits activity. This hurt the 20kbit per second device. Higher data rate helps with low duty cycle. In Steve Shellhammer’s comments, he asked how you got 1%. Right now, duty cycle is done outside of the scope of the MAC and PHY. We don’t know and we don’t care as a standard. We may want to investigate if we want to put an optional duty cycle limitation in the MAC. We may want to consider that for compliance and coexistence.

Kohno: If standard is far from the regulatory, then it is useless. International standard should be compliant with the rest of the world as well.

Andy M: We have two issues. One is applications issues with duty cycles. Second, what is the impact of the victim device in the presence of a 4a device vs. WGN at the same power level?

Pat K: We talk about LDC. If we were going to go before a regulatory authority, what duty cycle would we pick that would be acceptable to us? ERC 7001 for 868 MHz is 1% duty cycle.

Mike: Why don’t we match the EIRP required? Why do we put a duty cycle?

Kohno: Because we need some guideline. If you can provide a better way, we can use that as well.

Pat K: At 2.4GHz, can have 100x the power at 1% duty cycle.

Mike: Might pick a duty cycle that is above the level they are looking for.

Andy M: Are we talking about duty cycle for device or for the entire piconet?

Pat K: Always defined as per device. With a piconet coordinator, that becomes the limiting device. With a true mesh, the duty cycle becomes higher since not limited by the controller.

Kuor Hsin: This is more of a frequency mask. To achieve this is a combination of frequency mask and transmit power.

Kohno: Where will this be described?

Pat K: We will have a regulatory and coexistence annex.

Kohno: The letter ballot is valid. We are looking for a second letter ballot?


January 2006 IEEE P802.15-06-0062-01-004a/r2

Pat K: The next step is to recirculate the letter ballot. We want to get more people accepting the document. We want to reduce no-votes. We also have the threat of incurring more no-votes. We may drop below the 75% level.

Kohno: Other groups have requested further letter ballots.

Pat K: Minimum is one recirculation. To get to the sponsor level, we need to show we have addressed all comments and tried to resolve all “NO” Comments.

Patrick: What happens if we go below 75%?

Pat K: Then the version is not valid and we go back to the prior version that was approved at 75%.

Kohno: This ends my session.

Pat K: Thanks for Prof. Kohno for stepping forward at the last minute. Patricia Martigne was not able to make this meeting. Any questions or comments?

Pat K: If no opposition, will recess until 1:30pm this afternoon.

8.4 RECESS: Pat Kinney recessed the meeting at 10:00am HST for the 802 Plenary Meeting.

---------------------------------


Session 9 PM1



Chair: Pat KinneyCo-Technical Editor: Vern BrethourCo-Technical Editor: Jay Bain Secretary: Patrick Houghton


January 2006 IEEE P802.15-06-0062-01-004a/r2

Pat Kinney: We have comment resolution with Vern Brethour. Jean of France Telecom has a presentation, but we will do after comment resolution.

Passed floor to Vern Brethour for Comment Resolution

9.2 COMMENT RESOLUTION.

Vern Brethour: Want to talk about strategy to deal with no-vote clusters. Has a word document that will be put on the server, but not done yet. Yesterday, we started down T or TR comment. We were not trying to solve, we were just trying to bin them up. We finished the last quarter off-line last night. There were no new categories made last night. This morning, we went through that excel sheet and made a set of clusters.

1. Aloha issues – Pat Kinney2. Exceeded Scope of PAR – Pat Kinney3. Missing Stuff – Jay Bain will accumulate and assign4. Bandplan – Ismail and Matt Welborn – a potential solution will be presented in PM2 on

Wednesday.5. Framework – Will be presented by Matt Welborn later in PM1. Within the Framework are

several sub topics. Frequency Bands Pulse Shapes Data Rates Preambles FEC Configurations Public Ranging vs. Private Ranging

6. General PHY – Issues that apply to both CSS and UWB – Phil Orlik7. CSS – Rainer (except for exceeding the PAR)8. UWB – Phil Orlik9. Sub GHz – Patrick Houghton (fewer no-votes than expected)10. MAC – Jay Bain11. Ranging – Vern & Zafer12. Tool Problem – Jay to resolve13. CCA – Pat K for first sort (most for Aloha) (surprising large cluster of no-votes)14. 15.4b vs. 15.4-2003 as the base text – write an explanation about WHY we are using 15.4b

as a baseline15. Testing the patience of the group: Chaos, UWB Chirp, UWB Continuous Spectrum, Low

PRF Pulses.

Andy M: High Amplitude does not require high amplitude pulses, it allows high amplitude pulses. This is an implementation issue. Believe this will have an impact on the straw poll. We would get agreement if we position this as purely a matter of PRF and not amplitudes.

Kohno: In the morning session today, we are supporting lower PRF.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Vern: We can say this is not high amplitude, but looks like it. Passed floor to Matt Welborn.

Pat K: This week have heard from a lot of people that there were TBDs in this draft of the letter ballot. They feel that we should not have as many TBDs. In 40 days, we received more input from people that never came into this room than we had in the last two years. We got diversity into our session. Concerned that if we get recirculation, we will get rejected. Would like the next letter ballot to go out very solid. Propose that we do not go for recirculation in March. Propose that we work with those no-voters, we go out for a recirculation after March. Goal is to turn around half of the no-voters. Have three recirculations in the current schedule. If we do a good job, we reduce the recirculations from three to two.

Matt Welborn: Asked to present a method to market to voters. Document 06/039r0

Patrick: Should group all UWB bands together since they are using same modulation.

Matt: Could re-order list.

Andy: Will high band radio be required to do low band interoperability.

Matt: There are parts of the world that will not allow low-band, so all these bands should be able to operate independently, e.g. a CSS radio doesn’t need to implement high-band UWB and a sub-GHz radio doesn’t have to implement low-band UWB, etc.

Zafer: In 15.4, is there any frequency band, e.g. 2.4 GHz, that is considered baseline?

Pat K: No

Matt: This is a simple modulation for the UWB bands. We got comments that there are a lot of pulse shapes, but that is a benefit of UWB. We will define a baseline pulse, but at the same time, a strength of the standard is the flexibility of optional pulse shapes are easy to generate. Plan to finish this process in a final document.

Vern: You said, by presenting it this way, we can make more understandable. Feel free to use more space.

Matt: We should take the opportunity as to why we did things this way. If we put text as to why things are good, we will help convince people.

Vern: Thanks for doing this. One point is to make it harsh in clause 5. Won’t get any no-votes that say it is too few options. We agreed in Vancouver that options would only kick in if networks were homogeneous. Inclination is to mandate behavior by applications.

Matt: We should start out with the mandatory mode and have allowed deviations from baseline.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Pat K: We don’t do applications in the MAC, but we can say that commands can only be done in the mandatory mode. For form the network and disband the network would be in mandatory mode.

Vern: would like to see all commands need to be done in baseline mode of behavior.

Andy M: What do you mean by all commands?

Pat K: Only two types of traffic – commands and data.

Andy M: A ranging request would be a command?

Pat K: Yes.

Andy M: A network has established itself and has to go to the mandatory band to do a ranging?

Pat K: This is not to address bands, only waveforms.

Matt: Options should be offering potential benefits.

Vern: This is harsh, but there is no command flow that is invisible to any node.

Andy M: A little problem that could evolve is how does the receiving node know whether the next packet is commands or data?

Vern: This backdoor mandates that the radio has to operate in both modes.

Andy M: Agree with having mandatory entry and exit modes, but command traffic is in mandatory mode.

Patrick: There are some applications where the primary reason for operation is location. If ranging requests are commands, then this requires continuous operation in mandatory mode.

Vern: Good point.

Matt: Goal is interoperability and flexibility. If we want to provide a way for the piconet to broadcast a beacon with a few commands in the mandatory mode, that makes sense.

Vern: Disagree with Matt. If an application decides to set up a non-interoperable piconet, that is OK, but don’t want to have standard make it easy.

Matt: Don’t see what the problem is. Don’t think we should force behavior.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Vern: Don’t want to lose control of standard.

Pat K: Don’t want to see improper performance of network because of optional modes.

Patrick: Devices will have beaconing anyway. This will have to be in mandatory mode, so no need to burden a piconet to operate in mandatory mode.

Pat K: May want to mandate that devices have beaconing in mandatory mode.

Vern: Suggest a recess and come up with a mandatory mode. Seems like command traffic mandate is hard to get agreement on.

Pat K: Agree with that. We are in recess at 3:07pm until 4:40pm. Will have continued comment resolution and presentation by France Telecom on regulatory in Europe.


---------------------------------


Session 10 PM2



Chair: Pat KinneyCo-Technical Editor: Jay BainCo-Technical Editor: Vern Brethour Secretary: Patrick Houghton

Pat Kinney: We recessed to have technical editors come up with wording on behavior of devices. Passed floor to Vern Brethour


Vern: Wants to discuss proposed motion that the TG4a draft specification require all complaint nodes (when in receive mode) to be capable of always receiving traffic sent with the mandatory


January 2006 IEEE P802.15-06-0062-01-004a/r2

waveform. Just to be clear, the word “always” means that even when a node is operating in an optional mode, it can also receive signals transmitted in the mandatory waveform. This is harsh, but I can now tell no-voters who say that I’ve lost control of standard with too many options that I have a solution.

Pat K: Would like to read motion that was adopted in Vancouver. “Motion that TG4a require all UWB implementations within a band, use the mandatory waveform for establishing and/or joining an IEEE 802.15.4a network. Optional waveforms can only be used between devices within a given PAN after the PAN coordinator determines that all nodes in that PAN are capable of supporting the optional waveform. This motion does not apply to the data rates. Moved by Matt Welborn and seconded by Phil Orlik.

Joe Decuir: The center of the mandatory band is in the low band. That band may be unavailable.

Patrick: The motion stipulates “within a band”, so could operate in another band, such as high band or sub-GHz band.

Jae Hyun: What about band and data rates?

Pat K: Does not apply to data rates or frequency bands. This motion was passed by unanimous consent.

Patrick: Confirm that this was minuted and passed by unanimous consent.

Vern: So the piconet had to be homogeneous to run. Would like to add stronger language. If you build a radio that complies with the November resolution and build the radio now, it is the same level of complexity. Always means always.

Andy M: Always doesn’t always mean always.

Vern: Agree.

Patrick: Need to have language that allows radios to stay in optional mode for some period of time.

Vern: Disagree.

Pat K: As long as doesn’t mandate that receive two packets at once.

Jay: While you are receiving a valid packet, you don’t have to be listening to other one.

Pat K: When in the receive mode and device is not in the process of receiving a packet, the device must be capable of receiving a mandatory waveform.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Vern: New Text of proposed motion – The TG4a draft spec require all compliant nodes (when in receive mode, and not receiving a packet) to be capable of always receiving traffic sent with the mandatory waveform.

Kohno: Not clear on reason for this.

Pat K: Receiver is just listening. Hasn’t heard a preamble yet.

Jay: It is in receive until it determines which one is present.

Andy M: I think that the burden of the receiver with optional mode You can always listen in non-coherent mode, so you will listen.

Patrick: Can we drop “always”?

Vern: No, because we don’t want to have duty cycle.

Pat K: Hearing no more discussion, would like to hear objections.

Patrick: Don’t like “always” language.

Pat K: How many valid voters are in the room. We have 18 voters in the room.

Vern: Move that the TG4a draft spec require all compliant nodes when in receive mode, and not receiving a packet, to always be capable of receiving traffic sent with the mandatory waveform.

Zafer: Second motion.

Kohno: Why do we need this motion?

Vern: This is to resolve some no-votes regarding issue that we have too many options and losing interoperability.

Pat K: Any more discussion?

Jae Hyun: Mandatory waveform? Not band or data rate?

Pat K: Yes, only for waveform.

Kohno: Would like to know number of no-voters who are affected by this issue? How many will we deal with?


January 2006 IEEE P802.15-06-0062-01-004a/r2

Pat K: Two issues with optional behavior. One is cost. We can deal with this because it is optional. The second issue is that too many options affects interoperability. This is a valid argument. We believe this is the best compromise to bring those no-votes to yes.

Jae Hyon: This is a small portion of the comments.

Vern: Believe it is not a small portion. Many comments on large number of options.

Pat K: We had 800 comments, but not all 800 comments were tied to no-votes. A significant number of TRs were tied to this issue.

Jae Hyon: Have many options, but none as well established.

Pat K: We can discuss this, and you can move to table this, but would like to push for resolution. The ballot resolution committee recommends that this is the best way to resolve.

Jae Hyon: Think there is a better way to deal with these issues.

Matt Welborn: Is there a motion on the floor?

Pat K: Read motion – that the TG4a draft spec require all compliant nodes when in receive mode, and not receiving a packet, to always be capable of receiving traffic sent with the mandatory waveform.

Ismail: This implements low band as mandatory.

Pat K: No mention of band. This only covers waveform.

Matt: Understand the motion and speak against it. I would like to see the group make an effort to better explain options to no-voters. This may cripple those options, but not resolve those no-votes.

Vern: This is to improve interoperability.

Andy M: Move that we add a sentence similar to the Vancouver motion to explicitly state that this motion does not refer to data rates or frequency band.

Vern: Second the amendment to the motion. Amendment: This motion does not refer to data rate or frequency band

Pat K: Discussion on motion to amend.

Jae Hyon: Before this mandatory waveform, the mandatory mode must be resolved first.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Pat K: There is no mandatory mode mentioned up there.

Jae Hyon: What is the mandatory waveform?

Pat K: Can we say receive state and resolve your issue? Is there any opposition to the amendment to the motion? Seeing and hearing none, the motion is amended as stated. Are there any comments on the motion as amended? This motion is extended behavior of motion that was passed in November.

Zafer: The motion that was approved in Vancouver is that nodes enter networks in mandatory mode, so there should be no technical issues with this motion.

Matt: Even in the baseline standard of a TG4 device do we mandate that devices can’t go into powersave modes?

Pat K: There is no mention of states, just waveforms.

Vern: There is no requirement to receive the mandatory waveform when sleeping, transmitting or receiving other packets.

Matt: Still believe it has the effect of severely limiting the performance of optional modes.

Rainer: We run the risk of not resolving no-votes while alienating those supporters of the options.

Pat K: Do you have language that can fix the motion?

Matt: How will you resolve this? Some of the comments are based on misconceptions. We need to explain to no-voters that this does not increase complexity. Some comments are not based on sound technical reasoning, they are more emotional. We need to do a better job of supporting options. We shouldn’t take the easy way out and slashing and burning options. We should do a better job of explaining the utility of these options.

Michael McLaughlin: Some waveforms may work better than others.

Vern: This is a sensitivity issue.

Andy M: Nothing in the standard says that you have to listen in maximum sensitivity.

Huan Bang Li: We should limit this functionality to the FFD. The RFD cannot decide anything.

Vern: Do you want to amend the motion?

Huan Bang Li: Yes.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Pat K: Can we say that the motion require FFD nodes?

Huan Bang: Yes

Andy M: Can only FFD nodes control association and disassociation with the network?

Shinhara: Second motion.

Pat K: Discussion on motion to amend. Any discussion? Any objection? Motion to amend carries by uanimous consent. Is there any opposition to the motion? Yes.

Vern: Motion that the TG4a draft spec require all compliant FFDs when in receive mode, and not in the process of receiving a packet, to always be capable of receiving traffic sent with the mandatory waveform. This motion does not refer to data rate or frequency band.

Pat K: 14 for, 3 against, 5 abstain. Motion carries by 82%

Pat K: Passed floor to Jean Schwoerer of France Telecom for European regulation.

10.3 LDC LIMITATIONS FOR EUROPE

Jean: Presented document 6/051r0, European regulations and LDC operation.

Pat K: What is the thought behind 0.5% per hour and 1% per hour? Do you think that 1% is too high? In the 868 MHz the duty cycle is 1%.

Jean: We tried 1% and it was not well received. They wanted 0.1% duty cycle for LDC.

Pat K: Question for Prof. Kohno – will this be acceptable to Japan?

Kohno: Still under discussion. Hope to harmonize with Europe.

Ismail: If 1% impacts Wimax so much, it is too fragile to be deployed. This is saying that whenever UWB is active, Wimax doesn’t operate.

Jean: That is correct. Wimax can get signal of -100dBM.

Matt: My laptop can have -41dBM and jam Wimax.

Jean: Wimax is there and protected by Wimax.

Matt: Any laptop can jam Wimax at 2m. It doesn’t do anything to protect Wimax.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Jean: This is the distinction between intentional and un-intentional emitters.

Pat K: It looks like Wimax is not a very robust system.

Kohno: When will you analyze 4G?

Jean: For the moment, 4G has been considered in list of services that must be protected against UWB as well as Wimax.

Michael: Is the x-axis on page 4, is this the RSSI of the Wimax signal? Is the UWB signal constant?

Jean: Yes.Ismail: At 2 meters, this is a protection of -85 dBM. If bandwidth is 7mbits and throughput is 7mbits.

Pat K: We need to show coexistence with 802.16 since this is a IEEE standard. Now we go to discussion on band plan. Pass floor to Ismail Lakkis.

10.4 BAND PLAN

Ismail: Presented Document 06/059r0 – Updated Band Plan for TG4a. Revised adopted band plan and proposed modification to high band.

Matt: This is a preferable band plan. Makes for easier interoperability between high band and low band UWB. Is there still good alignment between Wimedia bands and 507 bands?

Ismail: Wimedia is revising their band as well.

Joe: Which one fits Wimedia better in the high band? Bands 9, 10 & 11 fit well right now. Can we get this by regulators and get past this group.

Ismail: The ECMA document is freely open to anybody. Band 9 starts as 7.392, so pretty close.

Matt: This gives same symbol rates. Easier implementation.

Vern: If you want to use band 3, you haven’t lost anything if you use a filter.

Joe: Based on the discussion, there is a consensus to adopt the new lower band plan at 499.2 MHz. We may have a little issue in the higher band.

Pat K: Should we change to this or should we send out an email feeler, or not consider this?


January 2006 IEEE P802.15-06-0062-01-004a/r2

Joe: If we were in a quorum group, we should divide this up into accepting the two bands.

Pat K: We are a quorum.

Michael: Center frequencies are a little lower, so a little less attenuation.

Matt: Couple of questions – maybe we should hold off for a little bit. Do you have any indications that this will resolve any no-votes? Is there a way we could resolve.

Ismail: Gadi is ok with 499.2. Haven’t heard back from Staccato. Gadi said he liked 499.2 better than 442.

Vern: Gadi was not that unreasonable – Soren was.

Joe: Trying to identify the ECMA signal is not going to be easy.

Ismail: Agree.

Joe: Move that we adopt the low band plan as described in Doc 06/059r0 on slide number 4.

Vern: Second motion.

Pat K: Discussion on motion? Any objections? Hearing and seeing none, the motion carries by unanimous consent. We now have a new band plan.

Vern: Please show slide for upper band. Would like to go to 499.2 for the optional High Band plan.

Matt: Like that better as well. Should resolve some no-votes.

Vern: Move to adopt upper band plan as described on slide 10 of Doc 06/059r1.

Matt: Second motion.

Pat K: Discussion on motion?

Huan Bang Li: Disagree with this band plan because it will restrict its use in Japan.

Joe: As a chip designer, this is preferable. For shipping worldwide, the 507 version is preferable. Haven’t worked through the arithmetic to see how this will resolve no-votes from ECMA group.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Vern: Can knock off 100 MHz with filter and meet Japan regulations. If you rely solely on pulse formation, you won’t get to Japan regulations.

Ismail: Need to be 30 dB down?

Matt: Need to have filter to get rid of interference.

Andy: Can we get accommodation from Japan regulation in the low band?

Kohno: That is possible.

Vern: Matt’s comment is that it will be difficult to turn ECMA crowd.

Kohno: The number 3 sub-band is not available in Japan.

Matt: This is a nominal band plan. We would need a filter in that band anyway.

Kohno: The prior plan is closer to Japan regulations.

Matt: The prior plan would still need to have accommodation to meet Japanese regulations.

Kohno: This band plan is non-compliant with proposed Japanese regulation.

Ismail: What if we change Band 3 to 7.3 GHz? The frequency separation is 3dB bandwidth.

Matt: What if we describe in more realistic way to meet regulation in Japan.

Joe: Made some of the Wimedia crowd happier in the low band and made the chip design easier.

Michael: So we make band 3, but make narrower.

Joe: Is there any reason for 494 and 499.2 and 507? are all derivatives of a crystal? Is there another crystal that works better?

Ismail: Yes, but that is a crystal that Wimedia doesn’t want.

Pat K: Any further discussion? Any opposition? There is opposition. So we will take a vote. Tokens in support of motion on the floor.

7 in favor, 7 opposed, 4 abstain. 50% in favor. We need 75%, so the motion fails. The motion is closed, so discussion is open again.

Ismail: These may be misleading numbers. Is there a way to fix for Japan?


January 2006 IEEE P802.15-06-0062-01-004a/r2

Joe: We want the advantages of fitting worldwide and we want simpler chip design. What would happen to the low band if we went to 507?

Ismail: Have tried that scenario, but exceed 4.8 by16.5. This will be a more important band.

Pat K: Further discussion?

Kohno: One question to Pat K., we want to increase number of yes votes. We may reduce no-votes, but get more yes-voters to change to no-votes. The prior plan was acceptable to Japanese regulation, so getting a plan that does not have Japanese regulation support will likely not get more yes-votes. Even some voters who say yes, can change to no when letter ballot goes out.

Pat K: That is correct. The ballot resolution committee is trying to come up with compromises that work.

Vern: Would like to walk out with 499.2 so the PLL works. We will define the filters so it complies with Japanese regulation.

Kohno: Is filter design in the standard?

Vern: If we do that, will you support it?

Kohno: That is not the right way to have a standard, we are dictating implementation.

Vern: Can’t get to Japanese regulation with pulse generation.

Kohno: Please make statement.

Vern: Move that TG4a adopt the upper band plan with the separation of 499.2 MHz between bands with the center frequencies of the bands as called out in Doc 06/059r1 on slide 10; in addition, that the corners of the bands 3, 4 and 5 are specified to be fully compliant with Japanese regulations.

Kohno: Second Motion.

Pat K: Discussion? Any opposition? Seeing and hearing no opposition, the motion carries by unanimous consent.

Pat K: We are now in recess until 8am tomorrow morning

10.5 RECESS: Pat Kinney recessed the meeting at 6:10pm until 8am HST tomorrow morning.


January 2006 IEEE P802.15-06-0062-01-004a/r2

---------------------------------

SESSION 11 – THURSDAY, 19 JANUARY 2006

Session 11 AM1




Pat Kinney: Jay Bain will be up this morning. We have four meetings today, which will complete us for the week. Would like to address some of the issues that came up this week. We would like to talk about DAA. Cost of DAA is beyond the scope of this group. If the regulatory environment requires this, it is regulatory. If it doesn’t, then it is implementation. As far as coexistence goes, haven’t heard any consensus that DAA is a viable coexistence tool. Joe Decuir has been working on primitive commands that would leverage what 802.11h has been doing to attack a similar problem. The group had no objections to adding some primitives to allow the 802.15.4a that would allow the network to convey DAA information. Our standard would not mandate DAA, but would support DAA mechanisms. The costs would be adding some primitives. Joe did presentation 06/047r1 on DAA and shows the primitives in slide 8. 802.15.4 already has primitives that do similar things. The MAC allows for scanning for another 15.4 device or do a scan for energy detect. Those primitives are already there. Don’t know if this will resolve no-votes, but may be a good compromise. Up to the implementer to implement DAA. 802.11h had to throw in support to avoid radar in 5GHz region. It is beyond the scope to describe details on DAA, but will describe how to convey results. May also be beyond standard to determine recourse if detect energy. After Joe Decuir, Rainer Hach will give a presentation. Since Joe isn’t here yet, any discussion on DAA?

Vern: Probably won’t buy us a single no-vote, but it is the right thing to do.

Pat K: We have three objectives. We can say that we did our best, It makes the standard better, may get some yes-votes.

Matt: Also gives us some points that we thought about coexistence.

Pat K: Initial point of DAA is to avoid Wimax. As Ismail pointed out, if sensitivity is so poor, how can we detect it?


January 2006 IEEE P802.15-06-0062-01-004a/r2

11.2 DAA PRESENTATION

Pat K: Started Joe’s presentation 06/047r1.

Matt: Also need pulse shape.

Jay Bain: On slide 7, is this a “Should” or “Shall”.

Pat K: Asking a question that the standard shouldn’t ask. We are making these commands optional. Passed floor to Joe Decuir.

Joe: Piconet controllers can be made solely responsible for DAA.

Pat K: Controller doesn’t decide anything, it is the layers above.

Joe: It comes from the piconet controller.

Pat K: It comes from above it in the application. We give information, we do not make decisions.

Andy M: As long as we just have a few bits in the MAC, we can support OFDM granularity. We can make these commands and reports extensible, so we can extend from one bit to two or three bits.

Jay: More concerned about error messages. None of these messages go over the air.

Pat K: Some messages go PHY to MAC and some go node to node.

Joe: The only thing that is proposed here are two more over the air messages.

Andy M: My suggestion is that we have one extension bit to keep the over the air load at a minimum. We have information on granularity of bands that can be set with the final bit.

Pat K: Agree that we make it extensible.

Joe: Agree with Andy. These radios do not have ability to look for spectrum. If they could, they could distinguish narrowband energy from broadband energy. Needs to get out of way of licensed, but probably not other unlicensed UWB.

Matt: Take issue with the idea that you don’t need to coexist with other UWB.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Pat K: Like to do general comment. Extensibility is a property that we try to embrace when possible. We are giving legs to standard.

Joe: Continued with presentation.

Pat K: Need to make sure that energy detect is a peak hold.

Joe: That is already there.

Pat K: We should have extensible bits to show what the bandwidth is.

Joe: Take some points from 802.11h that leaves much of this to the implementer.

Ismail: Is this mandatory in FFD?

Joe: That would be my bias.

Matt: Would disagree with mandatory energy detect.

Ismail: If we make it mandatory and no one has an idea of how to implement, then that is dangerous to the standard.

Zafer: Can we add measurements?

Joe: Made this more atomic – on or off.

Pat K: In 15.4, we make the complexity in the upper layers.

Zafer: Is this a time stamp or a time window?

Joe: Designates in superframe times – a dwell time.

Matt: Wouldn’t advocate putting something like this in the standard. DAA has so many complications. Primitives are fine, they don’t cost anything. Our theme is multiple band, simple radios, etc.

Kai: We are being burdened by other entities to try to solve a problem that belongs to another system. We are talking about signals that are tens of dBs below background noise. If these other systems are too fragile, they should be decertified. We are spending time trying to solve a problem that is someone elses.

Dave Leeper: There are people who think DAA is silly and some who think DAA is what all future radios will all have. Would like to make the radio future ready.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Matt: OK with putting primitives, but have issue with complicating the radio.

Dave: If we have place holders for DAA, we may be able to raise power levels in the future.

Pat K: We agree in principle to the concept here. Suggest that there is a special message that says 802.16 detect.

Joe: Can live with the application in or out of the standard, but standard should have hooks for it.

Pat K: Recognition of primitives will be mandatory for FFDs and optional for RFDs. Energy detect would be mandatory for FFD and optional for RFD. Beyond ED, other mechanisms are outside the scope of the standard.

Joe: This is pretty much what is in 802.15.4.

Pat K: Propose that this group accept in principal the guidance from document 06/047r1 – slide 8. The balloting resolution committee is empowered to implement the concepts defined in this document with the explicit request that commands and primitives are mandatory for FFDs and optional for RFDs. Furthermore, DAA beyond energy detect, is beyond the scope of this standard.

Joe: This does not propose any new device primitives.

Pat K: Also empowers balloting resolution committee to devise any necessary primitives to implement these commands.

Kai: Agree with this. Would like to put a second step into this.

Joe: In response to the ballot comments on DAA, we can say we have hooks, but implementation of DAA is beyond scope of standard.

Jay: Would like to get a motion on the screen.

Pat K: Reviewed proposal.

Jean: Do you need to implement ED with LDC?

Pat K: Yes, FFDs need to implement ED.

Jean: Preamble detect is the same?

Pat K: No. ED is a different feature – how strong is the signal. Any other comments on the proposal?


January 2006 IEEE P802.15-06-0062-01-004a/r2

Vern: Is the guidance in 06/047r1 clear enough?

Pat K: put focus on Slide 8. Is there a motion?

Joe: Move that this group accept in principal the guidance from document 06/047r1 – slide 8. The balloting resolution committee is empowered to implement the concepts defined in this document with the explicit request that commands and primitives are mandatory for FFDs and optional for RFDs. Furthermore, DAA beyond energy detect, is beyond the scope of this standard.

Jay: Second motion.

Pat K: Discussion?

Vern: Still looking at slide 8.

Andy M: Looking for an interpretation of the last sentence.

Pat K: There are a lot of valid technical arguments against DAA for this type of device. Would like to take this off the table. Just want to have hooks.

Joe: This is detection support. Deciding what to avoid is beyond scope.

Kai: Suggest that we say “beyond the scope of the current version”.

Pat K: That is redundant. We can’t project future revisions.

Vern: Slide 8 as read it, doesn’t have extension bit. We are calling out specific slide in specific presentation. Should I amend the motion to include the extension bit?

Jay: We are presuming that from the discussion.Vern: That is not specified – may as well do it now. Move to amend motion in addition to guidance in Slide 8 that we have an extension method or mechanism.

Joe: Second the amendment to the motion.

Jay: Called TLV – Type, Length, & Value

Pat K: Is there any opposition to the amendment? Seeing and hearing none, the amendment is approved by unanimous consent.

Pat K: Motion as amended: Move that this group accept in principal the guidance from document 06/047r1 – slide 8 with the addition of an extension method or mechanism. The


January 2006 IEEE P802.15-06-0062-01-004a/r2

balloting resolution committee is empowered to implement the concepts defined in this document with the explicit request that commands and primitives are mandatory for FFDs and optional for RFDs. Furthermore, DAA beyond energy detect, is beyond the scope of this standard.

Pat K: Any discussion on motion? Any opposition? Seeing and hearing no opposition, the motion carries by unanimous consent.

Kai: Suggest a follow-on to this motion. Move that the chair of 802.15.4a be directed to liaison with 802.16 regarding DAA.

Pat K: This is really in Steve Shellhammer’s camp. Maybe we work with 802.19 TAG for coexistence between 802.15.4a and 802.16. We can do a motion to carry to the workgroup. We can bring up in the Plenary tomorrow.

Kai: Asked chair what the best path is.

Pat K: Believe it will carry more weight if the 802.15 work group make a formal request to the TAG to do this.

Kai: DAA will be a shared responsibility.

Dave: We are a part 15 device, we are not allowed to interfere with licensed services.

Kai: Move that TG4a request that 802.15 WG direct the 802.19 TAG to work with 802.16 and 802.15 to define mutual coexistence mechanisms between 802.16 standards and 802.15.4a draft standard.

This puts us on the record as being serious about coexistence and recognizes this as a shared responsibility.

Dave Leeper: Second motion.

Pat K: Discussion?

Bin Zhen: Is this only for 802.16?

Dave: Is it appropriate to add the following two sentences regarding the FCC report and order? Rationale “The 2002 FCC Report & Order indicated that emission limits on ultrawideband could be liberalized once the industry has experience with it. The mechanisms outlined in this section are included as placeholders to facilitate this future possibility.”

Pat K: Agree. Will not have this as part of the motion, but will use as an informational discussion point to the WG. Also suggest that we put draft standards following 802.15.4a.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Pat K: Any other discussion? Any opposition to the motion? Seeing and hearing none, the motion carries by unanimous consent.

Pat K: Any other discussion points before recess? Rainer will be up in AM2. We are recessed until 10:30am.

11.6 RECESS: Pat Kinney recessed the meeting at 10:00am until 10:30am HST.

---------------------------------


Session 12 AM2




Pat Kinney: Would like to make some agenda changes. Now up to rev.4 in the agenda. We had DAA in this morning. Propose that Rainer lead us in discussion on CSS. Remainder of AM2 for Ismail for UWB comment resolution. PM1 we will have Jay Bain do general comment resolution. In PM1 also have ballot resolution committee. Prof Kohno isn’t here, so Pat K will talk about coexistence. Camillo will talk about Ranging annex in PM2. PM2 should be a short session.

Is there any discussion on the Agenda?

Vern: What does wrap-up mean at 1:30pm? Jay is not going to be able to do much with list of 800 no-votes. Do we poll for general guidance and ask for conference call schedule?

Pat K: Which ballot resolution technical editor have responsibility, etc. We find out who is working on what and empower those people on the ballot resolution committee. Any more discussion on proposed agenda? Seeing and hearing none, chair is willing to amend the agenda?

Vern: See nothing on the screen to preclude early adjournment. See Jay having 90 minutes to do 30 minutes of work.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Pat K: Made changes as suggested. Looks like we can adjourn in PM1.

Jay Bain: Move to approve agenda as amended.

Vern: Second.

Pat K: Seeing and hearing no objections, motion carries by unanimous consent

Passed floor to Rainer Hach for discussion on CSS Comment Resolution.

12.2 CSS COMMENTS OVERVIEW

Rainer: Presented document 06/065r0 on CSS Specific Comment Clusters and Overview. Got 36 comments addressing CSS. In about 8 categories.

Pat K: There are two arguments to limit size to 127 bytes. First is to allow dirt cheap devices to operate without maintaining the clock – shorter duration means don’t need good crystal. If you have higher data rate, that is not a valid argument anymore. Longer make packet size, the longer on air, so larger allocation of spectrum. There are some valid arguments that shorter packet implementations are better, but agree with Rainer that longer packets are more user friendly. Just want to remind committee that in 802.15.4, the packet size is 40 bytes. Don’t recall any application that required 128 bytes. Only time that wanted larger packets, was when downloaded revisions. Agree with Rainer that this is a general phy topic, not a CSS topic.

Rainer: Continue with presentation. Suggest that we postpone decision about this until the time between the meetings. The CSS PHY will follow the overall PHY at this point.

Pat K: Regarding the issue with violating the PAR, our draft amendment allows the user options. If the user wants precision ranging, we offer that option. If user wants enhanced communication, then we have the option for that. UWB has regulatory limits on power, which impacts ability to enhance communication range. CSS has issues with reliably getting precise ranging, which impacts another part of the PAR (Project Approval Request). We have met PAR, but we meet different parts of the PAR with different optional devices.

Rainer: Group of comments on sensitivity.

Pat K: Is there sufficient information delivered to this group on CSS?

Shimada: There is a current channelization of 2.4GHz in 15.4. We need to clarify how to coexist with existing standard.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Pat K: Two concerns I heard were coexistence and channelization. Using same frequencies as used by 802.11b,g and 802.15.4. The mechanism of informing PHY of which band to use is taken from 802.15.4b. The ability to coexist with legacy 15.4 and 802.11 in the 2.4GHz band has to be done in the coexistence assurance document. It will be done and will be shown between legacy devices in this proposed draft.

Coexistence will be done in the standards process. The mechanism of informing the PHY of which frequency band will use will be based on the 802.15.4b changes. 802.15.4b is in the sponsor ballot. It looks like it will be adopted and will become 802.15.4 since it is a revision, not an amendment. Does this address your question?

Shimada: There is a known description in the document of 15.4a, but the 2.4GHz CSS is an overlay on the current 802.15.4 PHY, so there is no way to combine these different PHYs.

Pat K: This is not true. You can combine two different channelization schemes using the same frequencies.

Shimada: The current document doesn’t show how these services are differentiated.

Pat K: Disagree, this group will define what coexistence mechanisms are done between 802.11 and 802.15.4 devices.

Shimada: Only 2.4GHz CSS coexistence has to be defined.

Pat K: There are differences between amendments and revisions.

Shimada: We have 802.15.4 devices already in the marketplace. CSS should include something to clarify how they will be used in conjunction with existing devices.

Pat K: This is either a coexistence issue, which will be addressed, or the frequencies used by 15.4a devices are different from the frequencies used by the 15.4 devices. It is legal in the standard to share bands.

Shimada: That is one way to notify the voters how this 2.4GHz requires different channelization.

Pat K: Are you advising the TG that having 2.4GHz CSS will generate no-votes?

Shimada: Yes

Pat K: There is precedence for having standards that share the same band.

Shimada: This is a contentious issue in 802.16 as well.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Pat K: We need to move on, so would like to summarize. You are asking the 2.4GHz CSS Technical editor to add explanation on how to coexist with current services.

Shimada: Yes.

Pat K: Any other discussions? Is there sufficient information given to this group that it will empower the ballot resolution committee to answer comments? Hearing and seeing no other comments, agree with Rainer that he does not need to go through all the comments.

Pass floor to Ismail Lakkis.

12.3 COMMENT RESOLUTION – BAND PLAN AND DAA

Ismail: Document 06/030r2 – comment list

Matt: There is no convolutional coding, just Reed Solomon?

Ismail: Yes.

Matt: The average pulse rate is 15Mbits, so can’t signal higher than that unless you increase the pulse rate.

Ismail: Channel data rate is from 0.8 to 27. Other comments regarding data rates – left for Pat K to take care of. Another issue was the scrambler.

Michael: That is an implementation issue.

Matt: Need to have a specified seed for LFSR. Start scrambling after the headers. Should run at symbol rate or as slow as possible.

Ismail: 16 meg will be enough for most cases.

Andy M: Doubt we need a bit scrambler. Having position and bit scramblers shouldn’t impact performance.

Matt: Agree with Andy.

Andy M: From packet to packet, how do we deal with scrambling? Do they start with the same seed?

Matt: We should have different seeds for different piconets.

Ismail: We have six of them.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Pat K: At this point, would like to propose that technical editors resolve this over conference calls between now and Denver. Is there any opposition to this process? Hearing and seeing none, Ismail is empowered to deal with this.

Ismail: Regarding chaotic waveforms. Section 8.8.3.3.5. Waveform was described by 4 differential equations. If we can make the content random instead of chaotic and leave the implementation to the implementer.

Jae Hyon: That is fine. There is no chaotic generator on the receiver side.

Ismail: Is there any objection to including this in the weekly conference call?

Pat K: Seeing and hearing no objection, you are empowered to deal with Chaotic as well.

Ismail: Then we are done.

Pat K: This concludes the scheduled business for AM2. Is there any other business in this time slot? Seeing and hearing none, we are recessed until 1:30pm.


---------------------------------


Session 13 PM1




Pat Kinney: This afternoon, we will do overall comment resolution. Then we have time slotted for coexistence and regulatory. Camillo will do ranging. We should get out of here by 4pm. Passed floor to Vern Brethour.


January 2006 IEEE P802.15-06-0062-01-004a/r2


Vern: Document 06/069r0 – approach to T and TR clusters.

1. CCA and Aloha issues – Pat K2. Exceeding scope of PAR – Pat K3. Missing Stuff – Jay Bain4. Band Plan – Ismail Lakkis5. Framework – Matt Welborn6. General PHY – Phil Orlik 7. UWB – Ismail8. CSS – Rainer9. Sub-GHz – Patrick10. MAC – Jay Bain11. Ranging – Vern 12. Tool Problems – Jay13. Using 15.4b vs 15.4 – Pat K14. Super Cluster – Jay

Vern: Tech editors will break up the shotgun comments

Pat K: Looked through comments and tried to see if there are significant technical changes that are needed. We got answers from the group. The next step is to finish the comments and finish the draft. The next draft has to be very complete and very solid. Has to address all concerns of no and yes voters. Any areas that you would like the ballot resolution committee to talk about right now?

Andy M: What is the procedure of comments? Will they be posted before Denver or will there be a running list?

Vern: Don’t have a plan yet, but will likely do incrementally.

Pat K: If you look at comment resolution document, there are spaces for resolution. It will be revised a number of times.

Rainer: By when with the question about payload size be decided?

Pat K: It has been changed to a general PHY, so it will be taken by Phil Orlik.

Michael: When is the next ballot?

Pat K: The next recirculation will happen after Denver.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Andy M: There was one technical “No” comment that was a suggestion to abolish error correction coding. Impression was to reject immediately. Do we have a method to deal with these issues?

Ismail: The FEC is systematic, so the receiver can ignore it and consider that no FEC has to be done.

Michael: Move that we adopt the strategy described in document 06/069r0 for resolving T and TR comments.

Ismail: Second motion.

Pat K: There is a motion on the floor for resolving T and TR comments. Any discussion? Any objections? Hearing and seeing none, the motion carries by unanimous consent. We will continue with weekly conference calls.

Andy M: Those calls for ballot resolution committee or for all interested parties?

Pat K: Anybody can attend, but focus is not new business, but ballot resolution.

Andy M: Anyone outside US on ballot resolution committee?

Vern: Huan Bang Li has been participating.

Ismail: Will send an email suggesting two times – one early in the morning, one late in the afternoon – to deal with asia and the US.

Michael: Suggest 6pm central time

Pat K: Suggest on Thursdays. Anyone in favor of a call next week? Seeing and hearing none, we will start the calls the week after next.

Pat K: Next step is discussion on coexistence and regulatory.

13.3 COEXISTENCE AND REGULATORY

Pat K: Patricia Martigne is no longer able to take the position of lead. Matt Welborn has volunteered to take on coexistence and regulatory. Matt understands the time commitment required. Would like Jean to help with Europe and Prof. Kohno to help with Japan. Since Matt is not here, we will table this discussion for now.

Pat K: Passed floor to Camillo Gentile for discussion on ranging.


January 2006 IEEE P802.15-06-0062-01-004a/r2

13.4 RANGING ANNEX

Camillo: Presented document 06/070r0 – Ranging Annex

Vern: Don’t think we need to add to topic of RSSI. There’s been lots of ink spilled on this.

Camillo: What about NFER?

Vern: Only one champion for that – Rick Roberts, so we can forget about it.

Camillo: What about angle of arrival?

Vern: Only one champion – Ivan Reed – so we can drop it. Just say it exits – one line and a reference.

Camillo: Coherent delay estimation with low sampling rate.

Ismail: This is more of an implementation issue. We can let this go.

Pat K: If this is helpful to understand the standard, then it is worthwhile.

Vern: This is an implementers choice. Suggest we drop this or punt to discussion on the reflector.

Ismail: Agree

Camillo: Last topic is timing crystal drift.

Pat K: Drift can happen quickly.

Ismail: Just track it, or you lost lock.

Camillo: Timing offset impacts tracking.

Vern: We’re not going to dwell on it. Enough said on this.

Michael: Regarding effect of different reply times on accuracy – is this from end to start?

Camillo: End of one packet to beginning of next packet.

Rainer: Suggest using end of received packet to end of transmitted packet, so can use the same marker.


January 2006 IEEE P802.15-06-0062-01-004a/r2

Vern: If radios have to interoperate, they have to use the same marker. We can deal with this later.

Pat K: If no other questions or comments, then go to next items. We’ve discussed conference calls between now and Denver. We’ve discussed what will happen – ballot resolution committee will discuss disposition of comments – accept, accept in principal and reject. We will also be sending emails to those who gave no-vote comments and see if they are willing to change no-vote to yes-vote. We will do a projection of what the vote will be with the recirculation once we get feedback from no-voters.

On project plan, will redo as part of this vote results. We have three draft recirculations in the process. If we do a good job with the upcoming draft, then we should be able to get through with only one more recirculation – before May in Jacksonville, FL. In July in San Diego, we will do final comment resolution. We should be able to get to sponsor ballot at that point.

At the end of our July meeting, which is a plenary, we should go to a sponsor ballot. At that point, we will start preparing a sponsor ballot. We need 75% of all voting members to get sponsor ballot passed. IEEE SA drives this one. Bob Heile and Pat K will pick the sample pool for the sponsor ballot.

We should have good attendance for the next two or three sessions, which should help with comment resolution. Any questions on project plan?

Huan Bang Li: What is the criteria for going to sponsor ballot?

Pat K: We need 75% or greater approval and all comments have been addressed. We have tried to resolve no-voters to agree to changes. We have no new No-voters. Either they are not going to change or have changed. If there are NEW no voters, then we need to address them. We are not going to get 100%. High 80% or 90% is a good number.

Michael: Data base of excel doesn’t record whether comment was associated with yes or no.

Pat K: Can’t get a TR if you voted “Yes”. There are three types of comments – Editorial, Technical and Technical Requirement, which says you voted “No” and this is a requirement to change your vote from “No” to yes. If you voted “YES” then this is not a TR, it is a T comment. Suggest that Jay add a column to show how the commentator voted.

Rainer: Can votes of “NO” be changed to abstain?

Pat K: Yes. Some no-voters can disappear and not reply back. When go to sponsor ballot, will look at if you responded sincerely to all comments – no flippant responses. Any more concerns or questions regarding project plan?


January 2006 IEEE P802.15-06-0062-01-004a/r2

Closing report will talk about conference calls and say that we will work with 802.16 for coexistence.

Is there any other business?

Patrick: Did not approve minutes from Vancouver.

Andy M: Move to approve minutes.

Vern: Second motion.

Pat K: Any discussion? Any objection? Hearing and seeing none, motion passes by unanimous consent.

Ismail: Move to adjourn.

Richard Wilson: Second motion.

Pat K: Any objections? Hearing and seeing none, meeting is adjourned until Denver in March.

13.5 RECESS: Pat Kinney adjourned the meeting at 3:00pm.

---------------------------------


Documents

Singapore TG3a Minutes - Welcome to Mentor€¦ · Web viewIEEE P802.15. Wireless Personal Area Networks. Project IEEE P802.15 Task Group 4a for Wireless Personal Area Networks