Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG3 Various D10 Issues] Date Submitted: [8 July 2002] Source: [James P. K. Gilb] Company: [Appairent Technologies] Address: [9921 Carmel Mountain Rd. #247, San Diego, 92129] Voice:[1-858-538-3903], FAX: [1-858-538-3903], E-Mail:[gilb@ieee.org] Re: [] Abstract: [This document discusses various issues with the D10 draft..] Purpose: [The purpose of this document is to generate discussion about issues in D10.] 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.

2. To OID or not to OID • OIDs are long, but only convey a small amount of information • Map them to a single octet instead • Pros: • Fixed length, short • Unlikely that arbitrary OID would work • Cons: • Only allows 256 security suites • More difficult to “upgrade”

3. Remove type and length from pictures • The pictures are big and hard to read. • Type and length appear in all figures and are somewhat redundant. • Suggestion: • Remove from all figures • The fields are shown in the introductory section for information elements and commands.

4. Suggested probe responses for IEs

5. Suggested probe responses for IEs (cont.)

6. Sending probe information

7. Sending probe information (cont.)

8. Probe with pseudo-static GTS • Since channel time grant was deleted, probe replaced it in D10 for moving pseudo-static GTSs. • Options: • Keep probe as command to send • Add complete CTA to channel time status command • Bring back channel time grant command, possibly with a different name

9. PHY header scrambling • Not clear if the scrambler is restarted before the second header for the 11 Mb/s mode • 2 options: • Restart it after 2nd PHY header • Continue scrambling after first header. • In second case, the frame is lost if one of the first two bits of the PHY header is lost. • Error will choose wrong scrambler and so second header is lost as well. • Second header BER << first header BER

10. PHY header scrambling (cont.) • Error probabilities • Whe QPSK TCM BER is 1e-5, DQPSK BER is 3e-2 • FER is 1-(1-BER)^nbits • TCM FER is 9.6e-4 [nbits = 12*8] • FER from 1st 2 QPSK bits is 6e-2 [nbits = 2] • So seed bits in first header would dominate FER • The FER is almost as bad as the FER for the frame body (~8e-2 for 1024 octets) • Best option is to re-start scrambler

11. Request for sample calculations • We should have an informative annex with sample calculations (e.g. CRC) and sample packet encodings • If a small number of people each took one frame to create the work would be small • Assign 2 others to verify the results for the frame • Each person looks at maximum of 3 frames • This activity will help to expose other unknown ambiguities in the standard.

12. Fragmenting the beacon • With 10 octets per CTA, the beacon can get very long, very quickly. • (2048-4-32-6-12)/7 = 284 CTAs • (MaxFrame-FCS-DEVGTSStatus-BSID-SyncParms) • Two-way communication requires 2 CTAs, ~140 unique connections. • But long beacons are hard to receive (FER rises with number of bits) • Suggest allowing 2 or 3 beacon fragments

13. Fragmenting beacon (cont.) • Structure • Re-use existing fragmentation protocol • Limit beacon to small number of fragments, say 3 • Require piconet syncrhonization parameters at the beginning of every beacon fragment • Each copy contains overall timing for the superframe • DEV may use any GTS allocated in an fragment that is received. • Example: BER = 1e-5 • 1024 octet beacon FER = 7.9e-2 • 3 fragments of 350 octets FER = 2.8e-2