November 2001 IEEE P802.15.3 doc:. 01/459r1
IEEE 802.15 Wireless Personal Area Networks
Project / IEEE 802.15 Working Group for WPANsTitle / IEEE 802.15 TG3 Minutes Session Austin Texas,
Date Submitted / [12 November 2001]
Sources / Mike McInnis
Jim Allen / Voice:
Fax:
E-mail:
Re: / []
Abstract / [IEEE 802.15.3 Task Group 3 Minutes]
Purpose / [Official minutes of the Task Group 3 during Session 13 in Austin November 12-16, 2001]
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.
Table of Contents (Hot Linked)
Morning, Monday, 12 November 2001
Afternoon, Monday, November 12, 2001
Evening, Monday, November 12, 2001
Morning, Tuesday November 13, 2001
Afternoon, Tuesday, November 13, 2001
Evening, Tuesday, November 13, 2001
Morning, Wednesday, November 14, 2001
Afternoon, Wednesday, November 14, 2001
Morning, Thursday, November 15, 2001..
Afternoon, Thursday, November 15, 2001
Minutes of the IEEE 802.15.3 Task Group 3
IEEE 802.15 Plenary Meeting – Session #13
Hyatt Austin-Downtown
Austin, Texas
12-16 November 2001
Morning, Monday, 12 November 2001
8:15 am John Barr opened the ad-hoc meeting.
Document 483r10 are the running minutes for this Task Group.
Document 453 r3 is this week's agenda for TG3 in the Austin, Texas.
Ad hoc meeting agenda
Security Clause 432r0 Rasor (8:31)
Configuration Inquiry Process 499R0 (10:31)
QOS Discussion 469r2 (10:51)
The goal the meeting this week is to get the draft ready for approval by the 802.15 WG for LB.
During this week we will create an amendments document. John is asking the TG to create a document showing the old text and the new and/or revised text. Get a document number from Bob Heile.
James Gilb would like anyone that has an open issue with document 01/374r8 to get his or her input to him.
8:30am Greg Rasor began going through document 01/432r0 TG3-MAC Security Proposal..
Basically.
802.11 authenticates then associates.
802.15.3 associates then authenticates.
Security is based on 802.1x layer device (DEV) authentication and payload session key establishment.
An external entity is controlling the 802.15.3 network via 802.1x and security services.
Patent free and algorithm versatile pushed off to the device host
Each device will have a 48-bit IEEE address and a Public Key certificate generating authority.
An Access Control list will be implemented.
Two tiers, authentication and public key; authentication, public key and key encryption key.
802.15.3 explicitly does not specify the details for device security implementation. Instead, 802.15.3 specifies services. These services are associated with different components of the architecture. There are two categories of 802.15 services, the station service (SS) and the distribution system service (DSS). Both categories of service are used by the 802.15 MAC layer.
One section of the document utilizes an 802.11 document security structure, which needs to be revised for 802.1x-based security.
The document needs to change some references to 802.15 to a more specific reference to 802.15.3.
9:35am Greg Rasor ended a review of document 01/432r0.
9:36am Greg Rasor began a review of document 01/487r1..
9:56am Greg ended the review of document 01/487r1.
9:57am Greg Rasor began a review of an e-mail which included a straw poll titled “802.15 TG3 Security and Privacy-Default Security Conditions" sent on 11/8/01.
10:08am Greg Rasor ended the review of the e-mail/straw poll.
10:15am john Barr called a recess until 10:30am
10:40am began a review of document 01/499r0 Configuration Inquiry Process by Bob Huang.
This document requests the inclusion of a Configuration Inquiry command process.
James Gilb suggests that an ACK process would be sufficient.
Problem is that the downlink slot is a broadcast to everyone..
Use two super frames and an N+1 slot process rather than a N slot process.
10:59am Bob Huang ended the review of document 01/499r0.
11:03am Allen Heberling began a review of document 01/469r2 QOS Discussion.
James Gilb says that all definitions will / must not have any acronyms in them.
Allen Heberling and James Gilb brought up the issue of DME vs. SME terminology in 802.15 vs. 802.11 in this draft.
The convergence layer would accept a SDU into a SDU classifier, which would direct the packet to the proper Stream Index Mapping function (Stream Index 1…N) then to the 802.15.3 Mac-CPS SAP.
802.1p has a user priority for 8 different traffic types.
Priority (Highest) 7 is assigned to Network control
Priority 6 is assigned to Voice
Priority 5 is assigned to Video
Etc.
11:16am Mary Duval would like to see an audio traffic type added to the user priority list. “Voice (VO) is currently on the list as a priority 6 and comments for priority 6 are <10ms delay and jitter.
The Convergence layer is being discussed here is coupled with 802.1p priority (QoS).
John Barr suggests that one SDU classifier queue could point to one or more Stream Indexes, i.e. three video streams could be coming through one SDU classifier then pointing to three different Stream Indexes.
Could use TCP/IP protocol parts as part of the convergence layer to support priority classification within 802.15.
What interface should we concentrate on in the draft? (802.1d, RFC-1394, IP, USB, PCI?)
If someone is going to propose a specific convergence layer to concentrate on, he/she needs to get it written and submitted before the Draft goes to Letter Ballot. However the convergence layer is not defined in order to enable an interface standard.
Mary Duval is going to help get a 1394 rep to present at the Jan 802.15 Interim meeting on an approach to drafting the convergence layer, or to talk about RFC-1394 convergence with 802.11 and/or 802.15.
12:09am Allen Heberling ended the review of document 01/469r2 QOS Discussion.
12:10pm John Barr adjourned the 802.15.3 Monday morning ad hoc meeting.
Meeting will re-convene at 3:30pm today in conference room Texas 6.
Afternoon, Monday, November 12, 2001
3:38pm John Barr opened the “official” meeting of 802.15.3.
3:40pm John reviewed the agenda document 01/453r4 TG3_Hight Rate_Agenda_November01
3:46pm Jim Allen-one change to the agenda, Release time for reviewing Project Plan, James Gilb moved Michael Dydyk seconded motion passed by unanimous consent.
Jim Allen moved, Barry Harold seconded to approve the minutes for Portland in section 3.2, Motion passed by unanimous consent.
3:50pm James Gilb moves to approve all the minutes in section 3.3 (424r0, 381r0, 447r0, 483r10, and 486r6), Jim Allen second, passed by unanimous consent.
3:55pm James Gilb moved to approve ad hoc minutes for Schaumburg and Rolling Meadows documents 01/422r0, 01/474r0, 01/425r0 and 01/473r0. Chair did not recognize the motion so James Gilb retracted the motion.
3:58pm Motion to approve the modified agenda 01/453r4 to make approval of the agenda was moved by James Gilb, Mark Schrader second. Motion passed by unanimous consent.
3:59pm James Gilb reviewed the August 01 ad hoc meeting minutes from Schaumburg (Chicago) document 01/422r0.
4:04pm James Gilb reviewed the October ad hoc meeting minutes, and conference call minutes since the Rolling Meadows ad hoc meeting, document 01/474r3.
4:21pm motion made to approve meeting minutes documents 01/422r0 and 01/474r3, James Gilb, seconded by Jim Allen. Motion passed by unanimous consent.
4:24pm Motion made to approve draft D08 by John Barr, seconded by Mark Schrader. Motion passed by unanimous consent.
4:28pm document 01/492r1 UWB Study Group Proposal reviewed by Rick Roberts.
Tutorials for UWB are in contributions IEEE802.15-00/082r1 and IEEE802.15-00/083r0.
Regulatory status of UWB is that it appears that by the end of the year (2001) the FCC intends to issue a UWB favorable report and order with modifications to FCC part 15 rules to authorize intentional low PSD radiation in the intentional radiator section (section 209?). Source of this data is meeting between the FCC and Xtremespectrum.
It appears that internationally the U.S. is about 2 years ahead of the rest of the world with UWB technology and spectrum considerations.
The tie to 802.15.3 is the MAC currently being defined by IEEE802.15.3 would be the required MAC. In affect, they are proposing an alternative PHY for the IEEE802.15.3 MAC.
What is being asked of WG 802.15 and TG3? To pass a motion to start a UWB study group under the auspices of TG3, called IEEE80215.3a (or other extension as Allen thought that the original PHY might be renumbered "a" and this might start as a "b"). The immediate activity is drafting a PAR and 5 criteria and issuing a call for applications.
4:47pm Jim Carlo commented that TG3 should explain why the 802.15 MAC should be used for UWB rather than the 802.11 MAC.
Proposed UWB Project Schedule:
November 01– Approve 15.3? Study Group, Issue UWB PHY CFA (Applications)
January 02- Approve PAR and 5 Criteria by WG, Present Applications Summary, Present Requirements document and approve select criteria, issue CFP (Proposals)
March 02- Proposal Presentations, Proposal evaluation against selection criteria, Approval of PAR by ExCom
May 02- Proposal Selection Voting, Generation and Acceptance of baseline draft text.
July 02- Presentation and approval of UWB PHY draft text.
September 02- Resolution of letter ballot comments.
4:55 pm James Gilb asked why UWB should be considered by TG3 as a new PHY, Higher speed, Adequate bandwidth to do QoS, New band,.
4:59 pm James Gilb asked if there is enough time in the proposed UWB Project Schedule for UWB proposers to become voters so that they can vote on their own proposals? Fix may be to conduct Proposal Selection Voting and Generation and acceptance of baseline draft text in July instead of May (Australia) where there may not be a quorum. Allen was concerned that the activity may threaten the comment resolution work on TG3.
5:07 pm John Barr recessed the meeting until 7pm in conference room Hill Country D.
Evening, Monday, November 12, 2001
Reconvened at 7:20PM. The meeting started late because of room shuffling.
Allen Heberling reviewed 01/469r2 regarding QoS proposals.
There was a lot of discussion about the Message Sequence Chart (MSC) for modifying a stream in figure 6. We discussed some issues about the message sequence, and the data content in the messages.
Mark Schrader thought that the DEV is the entity that knows what it wants to do. It makes a request for the services it wants. Therefore it should simplify things if we look at it that way.
Barr discussed his thoughts on what is needed to set up a stream. Shvodian thought it was difficult to make timing as precise as Barr suggested. Over the long term, clocks and systems will drift, so we need to keep it simple.
Barr asked whether we really need a stream command. Who makes the decisions about the stream? Ans: The PNC.
Shvodian suggested that limits on the super frame duration limit the flexibility but it simplifies things.
If here is a GTS allocated because of the stream command, how does the DEV know which one? Ans: from the CTA.
Heberling now sees that chart 6 does not give any timing data in the command to say which GTS has been chosen. The CTR has a stream element in it. The CTGrant is an info element containing the CTA, which contains the stream element. Shvodian and Barr suggested that there be stream start and stream stop commands rather than to split up the messages to DEV 1 and DEV 2. This should be triggered with a beacon command.
Barr recommended that the final trigger to establish a stream is the first beacon with the data in it. The MSC needs to be added to and clarified. Bain then asked whether this means that the BW is not allocated until the indication is passed back. Heberling will make it clearer and the SDLs will also make that clearer.
Schrader asked why we seem to avoid handling BW request directly, using indirect processes. There was a discussion about why and how.
01/410 will be discussed tomorrow by Heberling, and has some of the same issues that streams have.
Figure 6 for modifying the stream is not as complex as the initial request.
Schrader, asked, we don’t need a stream to make a channel time request -right? Ans; Yes.
Heberling explained examples of the weakness.
Schrader thinks each CTR needs a stream index associated with it so that it is a handle for the CTR. It doesn’t matter if there is a really a stream associated with it. Schrader asked what if we toss out CTA and replace it with Streams. The implications were discussed.
Barr said, "… we need to pick a method and go with it." He suggested that the modify command be related to the stream create command. Shvodian said that the modify command doesn’t need the three devices involved, so they are not the same.
We need more messages than what we have and we need to wait for a beacon to start the stream command and we need an MLME command to the DME.
Gilb suggested that Dev 2 needs a stream confirm, simultaneously with DEV1. Barr suggested a beacon sequence has to follow.
The "stream command" has to be renamed "stream management command". Two beacon arrows (one beacon) will be added, Create Confirm commands will also be added in parallel. Barr will mark up a document and Heberling will make the changes.
In the channel time request, there is a channel time request block. The original had a stream index, and the text calls it a stream control. It should be one octet not two and make sure the text is updated on the name. If the stream index is a non zero value, it is for a stream that has been previously set up.
Heberling is concerned that we would violate our QoS policy if we don't make the correct changes to this section.
Schrader reiterated that everything should have a unique stream index so you could modify it separately. This simplifies the whole standard. Mark explained how the handle makes things easier.
8:42 PM. There is some confusion why we have all this complexity.
Heberling thinks there should be a reason code in the Grant command so it can include a reject mode so that you know why you didn’t hear a response.
In figure 7 the request was denied. Heberling showed it as another example to consider.
There was a long debate on channel time allocation procedures. Barr is trying to consolidate stream commands, but there is still an issue with non-stream to avoid the three device negotiations. Schrader thinks that can still be one command. Shvodian suggested that if we get this too flexible, "..we are kidding ourselves if we think we can tune this to an optimal point."
Do we add an error code on the Channel Time Grant? We could seem a CTG and a stream management command. Gilb pointed out that the Neighbor command needs Channel Time Request so we can’t get rid of it (in case anyone was considering doing so).
We discussed the implementation some new commands and/or changes of new ones.
Are we going to Channel Time Grant command to contain only one CTA element and remove the text "however the PNC …" and the following sentence to the end in D08, section 7.5.21.2, page 102, line 13.
Gilb made the changes in D09. Also we changed variable in figure 58, Variable has been changed to "6", and deleted the sentence in section 7.5.21.2, second sentence, "When present in a broadcast….".
The payload command was also changed. This command listed channel time allocations granted to the address DEV in response to a channel time request command. In response to a CTR, the response means something specific.
Deleted the line "The recipient DEVs are expected to…".
The reason codes are the same as the stream management codes.
Gilb will name the new fields Grant Status field.
Right now, you need two CTAs because there is no end time. It is the start time for the next start time minus the guard time. Shvodian discussed what Gubbi suggested, and describes how all this interacts including the impact on dynamic guard time.
Gilb descried three ways to solve the problem, and the pro's /cons. Start stop, start and uniform guard time are the two simplest solutions. Shvodian thinks there is only a percent difference, but Gilb said it could affect other issues.
Heberling moved us to the Terminate Stream section in Figure 8. This has to be fixed too.
Not all of the issues are resolved. Several general scenarios were discussed to see if we missed something.
We did not cover service flows yet and will do it later. Heberling indicated the there was a Flow term that was not defined and passed the request to fix it to Gilb.
Recessed 9:57 PM.
Morning, Tuesday November 13, 2001
8:05am John Barr reconvened the meeting.
8:07am Rick Roberts began a review of document 01/493r0 UWB PHY SG Request.
5 issues were listed.
Question on Regulatory status of UWB worldwide?
What proof is there that the FCC is about to release rulemaking on UWB?
The UWB proposal 01/492r1 has a very aggressive schedule, and some members may not obtain voter rights by the time that down selection voting takes place?
Is it proper to ask the Excom to approve a study group around a specific UWB PHY proposal?
Why does TG3 believe that a UWB PHY is better used with the TG3 MAC rather than the 802.11 MAC?