doc.: IEEE Submission ETRI May 2015 Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Identifiers for Peer Aware Communication MAC Sublayer Date Submitted: 12 May, 2015 Source: Seong-Soon Joo 1, Hyo-Chan Bang 1, Billy Verso 2, Byung-Jae Kwak 1 Company: ETRI 1, DecaWave 2 Re: Abstract: As a contribution proposal for the IEEE TG8 standards, the PAC MAC identifiers structure is proposed. Purpose:Response to the IEEE TG8 call for contribution Notice:This document has been prepared to assist the IEEE P 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 P

doc.: IEEE Submission ETRI May 2015 Slide 2 Identifiers for Peer Aware Communication MAC Sublayer Seong-Soon Joo, Hyo-Chan Bang, Billy Verso, Byung-Jae Kwak

doc.: IEEE Submission ETRI May 2015 Address and Identifier at PAC MAC sublayer MAC address of a PAC Device –PD MAC address (device ID) –48 bit, OUI Identifier of a multicast Group –Multicast Group ID –16 bit, hashing of 48bit PD MAC address Class of a Peer Communication Group –QoS of peer communication group (PCG class) –4bit, 16 classes of medium access Identifier of a link established between two Peer Devices –Peer Ddevice Link ID (PD Link ID) –8 bit, identified with source PD MAC address or destination PD MAC address Slide 3 Peer Communication Group 1 PD5 PD4 PD1 Peer Communication Group 2 PD2 PD3 The text in blue is what TG8 agreed on. The text in red is what TG8 agreed to reject.

doc.: IEEE Submission ETRI May 2015 Appearance of Address and Identifier in MHR Slide 4 Bits: 4Bits:2 Octects: 0/2/6Octets: 0/[1,2]/6 Frame Type Source addressing mode Destination addressing mode 2: Multicast address 6: Destination address [1,2]: Link ID 6: Source address Frame Control (2 octets)Addressing Fields The above table is an agreed one. Link ID is always used with the destination address. The use of Link ID need more discussion. Capability information can be exchanged during peering procedure. The above table is only for the discussion of addressing mode, and thus can be changed when we deal with other things. If used, TG8 may decide to use whether one or two octets for Link ID.

doc.: IEEE Submission ETRI May 2015 Addressing Options & Directional Link ID Slide 5 Dest.Src Option 1Dev ID -Simple and straightforward -(48 * 2) bits for destination and source. -Shall be available for PAC Option 2Dev IDLink ID-Same Link ID for both direction -Link ID is shorter than Dev ID, and we save resources -To avoid Link ID collision, needs negotiation stage. -Each PD should maintain a table of Link IDs for neighboring PDs with links Option 3Dev IDLink ID-Different Link ID for each direction -Link ID is shorter than Dev ID, and we save resources -No worry about Link ID collision (see next slide) -Each PD should maintain a table of Link IDs for both directions for neighboring PDs with links, so the amount of information required to maintain is the twice of that of Option 2. -TG8’s favorite for optional Link ID. Option 4Dev IDShort Add.-TG8 has already decided not to use short Add. -In terms of saving, Option 4 is comparable to Option 3. -But, using short address has problems of its own. Option 5Short Add. -Possibility of collision due to mobility

doc.: IEEE Submission ETRI May 2015 Addressing Options & Directional Link ID Slide 6 AB Inbound table 6 = B Outbound table B=72 Inbound table 72 = A Outbound table A=6 (1) Dest: B | SRC: A | Link 6 (Not in the MHR) (2) Dest: A | SRC: 6 | Link 72 (Not in the MHR) (3) Dest: B | SRC: 72 Steps: (1)PD A sends a packet, with destination address set to the Dev ID of B, and source address to its own Dev ID. Also, PD A indicates it wants to use 6 as a link ID in [TBD]*. PD A should put “6 = B” in it’s inbound link table. Note that, if PD A cannot/does not want to use Link ID, PD A will not send the Link ID part, and other PDs cannot force it. (2)If PD B decides to honor PD A’s request to use Link ID, PD B sets A=6 in its outbound Link table. PD B responses with a packet, with the destination address set to Dev ID of A, and Link ID to 6. Also, PD B can indicate it wants to use 72 as a link ID (for the opposite direction), within the same packet, or in a separate packet. PD B should put 72 into its inbound Link ID table. (3)At the reception of packet, PD A adds B=72 into its outbound link table. Now PD A can send a packet, with destination address set to the Dev ID of B, and Link ID to 72. Discussion: This approach removes the problem of Link ID collision, and does not require any negotiation other than the exchange described above. (Collision avoiding feature not illustrated) *: IE or MAC command payload.

doc.: IEEE Submission ETRI May 2015 Appearance of Address and Identifier in MHR Frame typeMulticast AddressSource AddressDestination AddressLink ID Discovery Req-OO- Discovery Resp-OO- Peering Req./Resp. - OOO De-Peering Req.,Resp. - -OO Data with Peering - -OO Data without Peering - OO- Slide 7 according to the frame type -Discovery request is broadcasting (multicasting is not possible because there is no group formed, yet.) -Discovery response is a unicast. Therefore multicast address should be absent. -The discussion of the above table has not been completed.