02273r16P802-15 TG3-D10-running-comment-resolutions

Gilb

Informations

• Publié par: Zowyong
• Nombre de lectures: 21
• Langue: English

Extrait

July 2002 IEEE P802.15-02/273r16
1IEEE P802.15
2
Wireless Personal Area Networks 3
4
5
Project IEEE P802.15 Working Group for Wireless Personal Area Networks 6
7(WPANs)
8
9Title TG3 D10 running comment resolutions
10
11Date [8 July, 2002]
12
Submitted
13
14Source [James P. K. Gilb] Voice: [858-538-3903]
15
[Appairent Technologies] Fax: [858-538-3903] 16
[9921 Carmel Mountain Rd. #247, San E-mail: [[e-mail]] 17
18Diego, CA 92129]
19
20Re: []
21
22Abstract [This document is a record of comment resolutions for LB17.]
23
24Purpose [To provide a record of the comment resolution for LB17.]
25
Notice This document has been prepared to assist the IEEE P802.15. It is 26
27offered as a basis for discussion and is not binding on the contributing
28
individual(s) or organization(s). The material in this document is subject
29
to change in form and content after further study. The contributor(s) 30
31reserve(s) the right to add, amend or withdraw material contained herein.
32
Release The contributor acknowledges and accepts that this contribution 33
34becomes the property of IEEE and may be made publicly available by
35
P802.15.
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
Submission 1 James P. K. Gilb, Appairent TechnologiesJuly 2002 IEEE P802.15-02/273r16
1 1. PICS review call
2
3 Attendees: John Barr, Jay Bain, Knut Odman, Bob Huang, James Gilb, James Allen
4
5 Meeting called to order at 12:08 pm PDT.
6
7 Table F.1 - No problems.
8
9 Table F.2 - No problems.
10
11 Table F.3 -
12
13 Jump to table F.5
14
15 S1 is OK
16
17 Delete S2, mode 1 support and renumber.
18
19 S2 (new is old S3)
20
21 S2.1 - ECMQV is S2: O.2
22
23 S2.2 - Ntru is S2: O.2
24
25 S2.3 - RSA is S2: O.2
26
27 S3 - OK, but renumber
28
29 S3.1 - ECMQV X509 certs, S3: O.3
30
31 S3.2 - ECMQV Implicit certs, S3: O.3
32
33 S3.3 - RSA X509 certs, S3: O.3
34
35 S4 - Supports acting as security managers, {xref 9.7.1}, FD2 & S2: M, S2: O
36
37 Back to table F.3 (note, need to renumber security modes in this table).
38
39 MF2.4 - is just Imm-ACK
40
41 Delete second MF2.4.
42
43 Rest of MF2.x is OK
44
45 MF3 now,
46
47 MF3.3 is gone, now is part of the beacon.
48
49 MF3.6 should be M, O with xtra xref 8.13.2
50
51 MF3.7 deleted, now part of the beacon.
52
53 MF3.9 should be M and FD2: M
54
Submission 2 James P. K. Gilb, Appairent TechnologiesJuly 2002 IEEE P802.15-02/273r16
MF3.10 has been deleted. 1
2
MF3.11 may be moved and renamed but it is still optional. 3
4
MF3.12 now parent PNC BSID, should be FD2: O/M depending child neighbor O for receiver. 5
6
MF3.15 will be deleted. 7
8
MF3.19, MF3.20 and MF3.21 will deleted. 9
10
MF3.22 will be changed to M and FD2: M 11
12
That finishes MF3 13
14
MF4 now 15
16
MF4.1 and MF4.2, change FD1: M to just be M. 17
18
MF4.13 is gone 19
20
MF4.14 is OK 21
22
New MF4.xx PNC handover response command, FD2: M and FD2:M 23
24
MF4.19 - deleted. 25
26
MF4.20 and MF4.21, change FD1: M to just M. 27
28
MF4.22 is O and M 29
30
MF4.23 is M and O. 31
32
MF4.26 is O and M. 33
34
MF4.25 and MF4.25, change FD1: M to just M. 35
36
MF4.27 and MF 4.28. 37
38
MF4.29 is renamed and is OK as written. 39
40
MF4.34 new that is Vendor specific commands, O and O. 41
42
Back to 43
44
MF4.4 S2: M and S4: M 45
46
MF4.5 S4: M and S2: M 47
48
MF4.6 S4: M and S2: M 49
50
MF4.7 S2: M and S4: M 51
52
MF4.8 S2: M and S4: M 53
54
Submission 3 James P. K. Gilb, Appairent TechnologiesJuly 2002 IEEE P802.15-02/273r16
MF4.9 S4: M and S2: M 1
2
MF4.10 S4: M and S2: M 3
4
MF4.11 S2: M and S4: M 5
6
MF4.12 S2: M and S2: M 7
8
Now table F.4 9
10
MLF4.1 Parent PNC supports request mechanism for creating a child piconet. M 11
12
MLF4.2 PNC capable DEV support of becoming a child PNC. O 13
14
MLF5.1 Parent PNC supports request mechanism for creating a neighbor piconet. O 15
16
MLF5.2 PNC capable DEV support of becoming a neighbor PNC. O 17
18
MF3.12 is O and O due to the above decision. 19
20
MLF13 is deleted, was for old process. 21
22
MLF17 change to FD2: M 23
24
MLF18.2 Extended beacon support, FD2: O. 25
26
MLF20 BF’ed and no M. 27
28
MLF20.4 will be deleted. 29
30
MLF20.5 Optional (rename 21) 31
32
Rename MLF20.6 - rename. 33
34
MLF21 - re-do formatting. 35
36
Below MLF21.4 37
38
22.1 Moving beacon - FD1: M, FD2: O, MLF4.2: M MLF5.2 M 39
40
22.2 Changing superframe duration - FD1: M, FD2: O, MLF4.2: M MLF5.2 M 41
42
22.3 Setting the BSID and PNID (this is moved from above) - M 43
44
22.4 Maintaing sycnrhonization in child and neighbor piconets. - MLF4.2: M MLF5.2 M 45
46
MLF23 - change to O 47
48
MLF24 remove O and make a heading. 49
50
MLF24.1 - becomes PSPS, O 51
52
MLF24.2 and MLF24.3, xref should be to 8.12.2. 53
54
Submission 4 James P. K. Gilb, Appairent TechnologiesJuly 2002 IEEE P802.15-02/273r16
MLF25 remove M and make a heading. 1
2
MLF25.1 - FD1: M, FD2: O 3
4
MLF25.2 Request transmitter power adjustment: O 5
6
MLF25.3 Adjust transmitter power as requested: M 7
8
Finished review. 9
10
Meeting adjourned at 2:13 pm PDT. 11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
Submission 5 James P. K. Gilb, Appairent TechnologiesJuly 2002 IEEE P802.15-02/273r16
12. Comment resolution in Schaumburg
2
3
2.1 Thursday, 8 August, 2002 4
5
Attendees: John Barr, James Gilb, Jim Allen, Mark Schader, Dan Bailey, Gregg Rasor, Rene Struik, Knut 6
Odman, Allen Heberling, Bill Shvodian, Robert Huang, Jeyhan Karaoguz, Jay Bain, Mike Harvey. 7
8
Meeting called to order 8:33 am, CDT, Thursday 8 August, 2002. 9
10
2.1.1 Other issues 11
12
450 (Gilb, TR) - The beacon can be quite long, allow it to be split in two. Either add a last field (0 for more 13
fragments, 1 for final fragment) or allow the beacon to be fragmented with the fragmentation process, possi- 14
bly with an upper limit of 2 or 3 fragments. Allow DEVs to act on any fragment they hear. Put the piconet 15
syncrhonization IE in each fragment so DEVs know the timing for any fragment they hear. Suggest accept 16
in principle, “Allow the beacon to be fragmented into two sections, each one of which has the piconet 17
sychronization elements. Use the fragmentation field to indicate which is which. Add text that says “A DEV 18
that correctly receives the header of the first beacon fragment may use channel time allocations in the frame 19
body of a beacon fragment which has also been correctly received.” 20
21
Accept in principle, “Add to 8.6.2. Allow the PNC to send IEs in probe frame (DestID = BcstID) in 22
either a broadcast MTS following the beacon or in a probe frame (DestID = BcstID) in the CAP one 23
SIFS after the beacon (i.e. it cheats on the back off rules). If the beacon is too large, then the PNC 24
may put the other IEs in the following probe frame(s). Make sure SPS DEVs have some way to 25
know that more important information is to follow. How about using the more data bit to indicate 26
this? Or use MSTF IE. Also, make sure that if the beacon is protected with security then the probe 27
command that follows should also be protected with security. JPKG will have new text for tomorrow 28
in 02/273r13.” 29
30
‘If the PNC determines that the beacon is too large or if it wishes to split the information in the bea- 31
con, it may send one or more probe command with the SrcID set to the PNCID and the DestID set to 32
the BcstId following the beacon. If the PNC has allocated time for the CAP, then the first probe com- 33
mand shall be sent one SIFS following the beacon with any additional probe commands following 34
one SIFS after the the prior probe command. If the PNC is using MTSs instead of the CAP, then the 35
probe command shall be sent in the first MTS assigned in the superframe. This MTS shall have the 36
SrcID set to the PNCID and the DestID set to the BcstID. If the PNC sends some of the beacon 37
information in the broadcast probe frames, it shall set the more data bit to indicate ‘more data’ in the 38
frame control field of the beacon frame and in all but the last probe command frame used to commu- 39
nicate the information elements. The PNC shall send CTA IEs, Piconet BSID, SECID IE or the Par- 40
ent BSID IE only in the beacon frame and not in any of the broadcast probe frames. Since the probe 41
frames are sent to the BcstID, the ACK policy shall be set to no-ACK in the frames.’ 42
43
Accept suggested resolution. 44