Wireless Personal Area Networks s15

IEEE P802.15 Wireless Personal Area Networks

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

Title Multiple clock support documentation

Date [17 January, 2010] Submitted

[Sridhar Rajagopal, Sang-Kyu Lim, Taehan Voice:[] Source Bae, Dae Ho Kim, Jaeseung Son, Ill Soon Jang, Fax: [ ] Doyoung Kim, Dong Won Han, Ying Li, E-mail:[[email protected]] Atsuya Yokoi, J.S. Choi, D.K. Jung, H.S.Shin, S.B.Park, K.W.Lee, Shadi Abu Surra, Eran Pisek, Farooq Khan, Tae Gyu Kang, E.T. Won] [Samsung Electronics, ETRI]

Re: []

Abstract [Documentation for multiple clock support ]

Purpose [Description of what the authors wants P802.15 to do with the information in the document.]

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. January 2010 IEEE P802.15-< 15-10-07-0063-00-0007>

1. Clock rate selection:

The standard supports multiple optical clock rates in order to accommodate a wide variety of optical sources and receivers. The standard also supports the use of asymmetric clock rates between the transmitter and the receiver since the transmitter and receiver are independent chains and may support different clock rate ranges. The multiple clocks used for both PHY types are as shown in Tables xx and yy.

Support for minimum clock rate for a given PHY type shall be mandatory for TX and RX for all devices. All specified clock rates less than the maximum supported clock rate in a given device shall also be supported in that device. If a clock rate is supported, all data rates associated with that clock rate shall be supported. The preamble, header and payload in the PHY shall have the same clock rate The header shall be sent at lowest data rate for the chosen clock rate. The payload can choose any data rate belonging to the chosen clock rate.

1.1. Clock rate selection for P2P topology:

Let us assume that Device 1 supports the following clock rates at the transmitter (C1, C2, … C t1), where

Ct1 is the maximum clock rate supported at the transmitter at device 1. Also, C1 < C2 < .. < Ct1 The clock rates are also integral multiples of each other to make the clock generation and selection simple at the transmitter i.e. Ci+1/Ci = m Є Z. The receiver may support more or less clock rates than the transmitter since the receiver circuit is physically independent of the transmitter clock. The transmitter clock is restricted to the clock supported by the optical source while the receiver clock is restricted by the photodiode. Let the clocks supported by the receiver of device 1 be C1, C2, … C r1, where Cr1 is the maximum clock rate supported at the receiver of device 1. Similarly, let Ct2 and Cr2 be the maximum clock rates supported by the device 2. Support for the lowest clock rate C1 is mandatory at both the transmitter and receiver for all devices i.e. t1, t2, r1, r2 ≥ 1. For every clock rate, there is associated set of data rates at the physical layer. This data rate is dependent on the modulation, line coding and FEC used at the physical layer for a given clock rate. Let the data rate be represented by rate{Ci,p}, where Ci is the chosen clock rate and 1 ≤ p ≤ N(Ci), where N(Ci) is the number of physical layer rates associated with clock rate

In Figure 1, Device 1 sends the association request at the lowest clock C1 at a physical layer data rate rate{C1,k}. The data rate index ‘k’ is typically is chosen to be the lowest data rate to guarantee

2 January 2010 IEEE P802.15-< 15-10-07-0063-00-0007>

maximum range and reliability for the given clock rate. In this association request, the device 1 also informs the other device of the maximum clock rate supported by its transmitter and receiver (C t1, Cr1). Device 2 receives the association request and compares the received information about the supported clocks at device 1 and compares it with its supported clocks. In order for it to communicate, it must select a clock rate Csel2 that is equal to or lower than maxCsel2, which is the minimum of its maximum transmitter clock and the maximum receiver clock supported by device 1. The decision to use clock rates lower than maxCsel1 and maxCsel2 at device 1 and device 2 for transmission depends on the performance and throughput needs of the devices. The receiver also sends an association grant back to the transmitter at the same lowest clock rate C1 supported by all devices. The devices then exchange the selected clock frequencies for future communication before they switch to the selected clock frequencies. The devices may also decide to change the clock rate anytime in future communication for performance or throughput, as long as it is below maxCsel1 and maxCsel2 for transmission at devices 1 and 2 respectively.

Clock rate selection for P2P topology

Dev 1 Dev 2 (supports clocks (supports clocks TX: C1,C2,...Ct1 TX: C1,C2,...Ct2 RX: C1,C2,...Cr1) RX: C1,C2,...Cr2)

Association Request (clock C1, rate{C1,k})

Inform max clock of Dev 1 (Ct1,Cr1)

Association Grant (clock C1, rate{C1,j})

maxCsel2 = min (Cr1, Ct2) maxCsel1 ≤ min (Cr2, Ct1) Csel2 ≤ maxCsel2 Csel1 ≤ maxCsel1 Inform selected clock Cse1 (clock C1) Inform selected clock Csel2 (clock C1) Dev2 to Dev1 (clock Csel2) Dev1 to Dev2 (clock Csel1)

There is a data rate table rate{Ci,j} associated with each clock rate Ci where j is the data rate index associated with clock rate Ci

Figure 1 Clock rate selection for P2P topology (explicit notification)

It is also possible for Device 2 to send the association grant at the new clock rate Csel2 and not have to explicitly exchange notification information, if device 1 has the capability to detect all clock rates less

3 January 2010 IEEE P802.15-< 15-10-07-0063-00-0007>

than its maximum receive clock rate. In this case, communication can occur without overhead for explicit notification. Clock rate selection for P2P topology

Dev 1 Dev 2 (supports clocks (supports clocks TX: C1,C2,...Ct1 TX: C1,C2,...Ct2 RX: C1,C2,...Cr1) RX: C1,C2,...Cr2)

Association Request (clock C1, rate{C1,k})

maxCsel2 = min (Cr1, Ct2) Csel2 ≤ maxCsel2 Association Grant (clock Csel2, rate{Csel2,j})

maxCsel1 ≤ min (Cr2, Ct1) Csel1 ≤ maxCsel1 Dev2 to Dev1 (clock Csel2)

Dev1 to Dev2 (clock Csel1)

There is a data rate table rate{Ci,j} associated with each clock rate Ci where j is the data rate index associated with clock rate Ci Figure 2 Clock rate selection for P2P topology (without explicit notification)

1.2. Clock rate selection for Star topology: Figure 3 shows the clock rate selection for a star topology. In this case, let us assume Device 1 to be a co- ordinator. The co-ordinator will send a broadcast message via a beacon to all nodes such as Devices 2 and 3 and inform them of its supported clock rates. The CAP always uses the lowest clock rate C1 for uplink contention. The co-ordinator and the devices communicate the selected clock frequencies during the CFP using clock rate C1 before switching to the selected clock frequencies.

4 January 2010 IEEE P802.15-< 15-10-07-0063-00-0007>

Clock rate selection for Star topology

Dev 1 (AP) Dev 2 Dev 3 (supports clocks (supports clocks (supports clocks TX: C1,C2,...Ct1 TX: C1,C2,...Ct2 TX: C1,C2,...Ct3 RX: C1,C2,...Cr1) RX: C1,C2,...Cr2) RX: C1,C2,...Cr3)

Beacon (clock C1,rate{C1,k}) Inform max clock of Dev 1 (Ct1,Cr1)

Contention Access Period (clock C1,rate{Csel2,j})

Contention Access Period (clock C1,rate{Csel3,m})

Csel3 ≤ min (Cr1, Ct3) Csel2 ≤ min (Cr1, Ct2)

CFP: Inform clock Csel12 (clock C1) CFP: Inform clock Csel13 (clock C1) CFP: Inform clock Csel2 (clock C1) CFP: Inform clock Csel3 (clock C1)

CFP: Dev2 to Dev1 (clock Csel2) CFP: Dev1 to Dev2 (clock Csel12) CFP: Dev3 to Dev1 (clock Csel3) CFP: Dev1 to Dev3 (clock Csel13)

Figure 3 clock rate selection for star topology (explicit notification)

Similar to the P2P topology, the clock rate selection for the star topology can also occur without explicit notification as shown in Figure 4.

5 January 2010 IEEE P802.15-< 15-10-07-0063-00-0007>

Clock rate selection for Star topology

Contention Access Period (clock Csel2,rate{Csel2,j})

Contention Access Period (clock Csel3,rate{Csel3,m})

CFP: Dev2 to Dev1 (clock Csel2) CFP: Dev1 to Dev2 (clock Csel12)

CFP: Dev3 to Dev1 (clock Csel3)

CFP: Dev1 to Dev3 (clock Csel13)

Figure 4 clock rate selection for star topology (without explicit notification)

1.3. Clock rate selection for Broadcast/Multicast topology:

Figure 5 and Figure 6 show the clock rate selection for broadcast/multicast topologies assuming bi- directional communication. For unidirectional broadcast, the co-ordinator should use the lowest clock rate for broadcasting to ensure all devices can receive the information.

6 January 2010 IEEE P802.15-< 15-10-07-0063-00-0007>

Clock rate selection for Broadcast/multicast topology

CFP: Dev2 to Dev1 (clock Csel2) CFP: Dev1 to Dev2 (clock Csel12) CFP: Dev3 to Dev1 (clock Csel3) CFP: Dev1 to Dev3 (clock Csel13)

Csel1 ≤ min (Cr2, Cr3,Ct1)

CFP: Inform clock change to Csel1 (clock Csel12)

CFP: Inform clock change to Csel1 (clock Csel13)

Broadcast/Multicast message (clock Csel1)

Figure 5 Clock rate selection for broadcast/multicast (assuming bi-directional communication)

7 January 2010 IEEE P802.15-< 15-10-07-0063-00-0007>

Clock rate selection for Broadcast/multicast topology

Contention Access Period (clock C1,rate{Csel2,j})

Contention Access Period (clock C1,rate{Csel3,m})

Csel1 ≤ min (Cr2, Cr3,Ct1)

Broadcast/Multicast message (clock Csel1)

Figure 6 clock rate selection for broadcast/multicast (bi-directional communication and no explicit notification)

2. Changes to support multiple clock rate selection

Table 1 Capability field Bit Attribute Description 0 Traffic support 0 = unidirectional (broadcast only) 1 = bi-directional 1-2 Topology 00 = reserved 10 = P2P only 01 = P2MP support 11 = both

8 January 2010 IEEE P802.15-< 15-10-07-0063-00-0007>

3-4 Device type 00 = infrastructure 01 = mobile 10 = vehicle 11 = reserved 5 Beacon capability 1 = capable 6 Visibility support 1= support 7 Dimming support 1 = support 8 Co-ordinator support 1 = support, can act as co-ordinator for VLAN 9-11 Max supported TX clock 000 – lowest clock rate, 001 – next highest clock, …

12-14 Max supported RX clock 000 – lowest clock rate, 001 – next highest clock, …

15 Explicit clock notification request 1 = needs explicit clock notification at receiver

Table 2 Command frame notification

Command frame identifier Command name

0x01 Association request

0x02 Association response

0x03 Disassociation notification

0x04 Data request

0x05 PAN ID conflict notification

0x06 Orphan notification

0x07 Beacon request

0x08 Coordinator realignment

0x09 GTS request

0x0a Blinking notification

0x0b Dimming notification

0x0c Fast link recovery signaling

9 January 2010 IEEE P802.15-< 15-10-07-0063-00-0007>

0x0d Mobility notification

0x0e Information element exchange

0x0f Clock rate change notification

0x10–0xff Reserved

Table 3 Clock rate change notification format

octets: 1 1

MAC Header Command New clock rate for future fields Frame TX Identifier