doc.: IEEE 802.15-15-0396-03-0008

Submission

ETRI

May 2015

Slide 1

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)Project: IEEE P802.15 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 Joo1, Hyo-Chan Bang1, Billy Verso2, Byung-Jae Kwak1

Company: ETRI1, DecaWave2

Re:

Abstract: As a contribution proposal for the IEEE 802.15 TG8 standards, the PAC MAC identifiers structure is proposed.

Purpose: Response to the IEEE802.15 TG8 call for contribution

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.

doc.: IEEE 802.15-15-0396-03-0008

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 802.15-15-0396-03-0008

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 802.15-15-0396-03-0008

Submission

ETRI

May 2015

Appearance of Address and Identifier in MHR

Slide 4

Bits: 4 Bits:2 Bits:2 Octects: 0/2/6 Octets: 0/[1,2]/6

Frame TypeSource

addressing mode

Destination addressing

mode

2: Multicast address6: Destination address

[1,2]: Link ID6: 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 802.15-15-0396-03-0008

Submission

ETRI

May 2015

Addressing Options & Directional Link ID

Slide 5

Dest. Src

Option 1 Dev ID Dev ID - Simple and straightforward- (48 * 2) bits for destination and source.- Shall be available for PAC

Option 2 Dev ID Link 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 3 Dev ID Link 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 4 Dev ID Short 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 5 Short Add. Short Add. - Possibility of collision due to mobility

doc.: IEEE 802.15-15-0396-03-0008

Submission

ETRI

May 2015

Addressing Options & Directional Link ID

Slide 6

A B

Inbound table6 = B

Outbound tableB=72

Inbound table72 = A

Outbound tableA=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 802.15-15-0396-03-0008

Submission

ETRI

May 2015

Appearance of Address and Identifier in MHR

Frame type Multicast Address Source Address Destination Address Link ID

Discovery Req - O O -

Discovery Resp - O O -

Peering Req./Resp. - O O O

De-Peering Req.,Resp. - - O O

Data with Peering - - O O

Data without Peering - O O -

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.