1 / 7

Identifiers for Peer Aware Communication MAC Sublayer

This document proposes the PAC MAC identifiers structure as a contribution to the IEEE 802.15 TG8 standards for wireless personal area networks (WPANs). It discusses various identifiers for peer communication groups, multicast groups, and links between peer devices.

margaretyi
Télécharger la présentation

Identifiers for Peer Aware Communication MAC Sublayer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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.

  2. Identifiers for Peer Aware Communication MAC Sublayer Seong-Soon Joo, Hyo-Chan Bang, Billy Verso, Byung-Jae Kwak

  3. 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 The text in blue is what TG8 agreed on. Peer Communication Group 1 Peer Communication Group 2 PD5 PD2 The text in red is what TG8 agreed to reject. PD4 PD1 PD3

  4. Appearance of Address and Identifier in MHR 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.

  5. Addressing Options & Directional Link ID

  6. Addressing Options & Directional Link ID 6 = B 72 = A (1) Dest: B | SRC: A : IE: Link 6 A B (2) Dest: A | SRC: 6 | IE: Link 72 (3) Dest: B | SRC: 72 • Steps: • PD A sends a packet, with destination address set to the Dev ID of B, and source address to its own Dev ID. Also, (possibly in the IE) PD A indicates it wants to use 6 as a link ID. PD A should put “6 = B” in it’s 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. • PD B responses with a packet, with the destination address set to Dev ID of A, and source address 6 (to honor PD A’s request). Also, PD B can indicate it wants to use 72 as a link ID (for the opposite direction), within the same packet as an IE, or in a separate packet. PD B should put this into its Link ID table. • Now PD A can send a packet, with destination address set to the Dev ID of B, and source address to 72. • Discussion: This approach removes the problem of Link ID collision, and does not require any negotiation other than the exchange described above. (Not illustrated)

  7. Appearance of Address and Identifier in MHR • 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.

More Related