doc.: ieee 802.15-05-0455-00-005 submission july 2005 ho-in jeon, kyung-won university slide 1...

July 2005

Ho-In Jeon, Kyung-Won UniversitySlide 1

doc.: IEEE 802.15-05-0455-00-005

Submission

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: [An Architecture for Mesh Networks and Some Related Issues]Date Submitted: [15 July, 2005]Source: [Ho-In Jeon (1), Sung-Hoon Jeong (2)] Company: [Dept. Electronic Engineering, Kyung-Won University(KWU) (1), LeiiTech Inc. (2)] Address: [San 65, Bok-Jung-Dong, Sung-Nam-Shi, Kyung-Gi-Do, Republic of Korea] Voice:[ +82-31-753-2533], FAX: [+82-31-753-2532], E-Mail:[[email protected]]

Re: [This work has been supported partly by HNRC of IITA and partly by TTA]

Abstract: [This document proposes an architecture for the IEEE 802.15.5 mesh networks and some issues that need to be resolved for various applications.]

Purpose: [Final Proposal for the IEEE802.15.4a standard]

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.

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

An Architecture for Mesh Networks

and Some Related Issues

Ho-In Jeon

Kyung-Won University, HNRC, TTA

Republic of Korea

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

Contents• Introduction• Definition of mesh networks• Issues of mesh networks

– Beacon Scheduling– Short Address Allocation– RTS/CTS for Collision Avoidance– Routing– Power-Saving Operation Mode

• Unsupervised Beacon Scheduling• Address Allocation• Conclusion

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

Definition of Mesh Network

• A mesh network is a PAN that employs one of two connection arrangements, full mesh topology or partial mesh topology.

• In the full mesh topology, each node is connected directly to each of the others.

• In the partial mesh topology, some nodes are connected to all the others, but some of the nodes are connected only to those other nodes with which they exchange the most data.

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

Mesh Networking Topologies

STAR Cluster Tree Mesh

PAN Coordinator Coordinator End Device

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

Overview of IEEE 802.15.5

• The IEEE 802.15 Task group 5 is chartered to determine the

necessary mechanisms that must be present in the PHY and MAC

layers of WPANs to enable mesh networking.

• A mesh network is a PAN that employs one of two connection

arrangements, full mesh topology or partial mesh topology.

• In the full mesh topology, each node is connected directly to each

of the others.

• In the partial mesh topology, some nodes are connected to all the

others, but some of the nodes are connected only to those other

nodes with which they exchange the most data.

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

Capabilities of Mesh Networks

• Extension of network coverage without increasing

transmit power or receive sensitivity

• Enhanced reliability via route redundancy

• Easier network configuration

• Better device battery life due to fewer retransmissions

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

Limitations of Mesh networks

• Hidden nodes

– Devices are unaware of current neighbors receiving data.

– Collisions of Beacon and Data.

– Mutual Interference Causing Beacon and Data Conflict.

• Exposed nodes

– Devices are unaware of their position relative to receiver.

– Concurrent transmission in same time period possible but

unused.

– Inefficient spatial frequency reuse.

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

Issues of Mesh Networks• Beacon Scheduling for Collision Avoidance

– Reduction of Power Consumption with Beacon Network– Non-beacon-Enabled Network cannot provide a power-efficient

operational mode• Short Address Allocation Algorithms

– Savings of Address Spaces• Adoption of RTS/CTS for Data Transmission

– Deterioration of Data Throughput– Overall Delay– Exposed Node Problem

• Routing: Proactive or Reactive• Power-Efficient Operation Mode• Support of Time-Critical or Delay-Sensitive Applications

sunghoon

알려진 노드 문제

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

Mesh Example 1: Home Network

DCam.

PVR

VPhone

DTV

DAMHS/

MMRG

InternetFTTH

DTV

PVR

VPhone

Refrig.

DCam.

PC

DTV

STB

PDA

Living Room

Room #1

Room #3

Room #2

Kitchen

DoorPhone

WaterMeter

GasMeter

ZigBee/15.4802.11a/g/n/e, IEEE802.15.3

Oven

Cable, Satellite, Terrestrial

PC

AP or PNC

: IEEE802.11x, 15.3, ZigBee/15.4, 15.5 Mesh

PDA DCam.

Printer

PC

PDARoom #4

DTV

PowerMeter

Meter Reader

Phone Jack

GasOven

MicrowaveOven

DSLAM

Phone Jack

Bath-room

UtilityRoom

Washer

MeshPNC

ONU

VDSLMODEM

MeshMesh

Mesh

: IEEE1394 or UWB Connectivity

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

Mesh Example 2: Environment Management

1 2 3 4 5 N-2 NN-1

10 Km

• A scenario in which the device 1 wishes to send its sensed data to device N which is located 10 Km apart.

• Assumptions– The RF range of each device is assumed to be 20m.– Multihop topology has been used for the propagation of data– Each device is assumed to use beacon to save power consumption. – Device 2 listens to the beacon transmitted by device 1 and decides to associate with it. Device 2

determines its beacon tramitting time slot. – Device 1 is 40m apart from device 2 which implies that device 3 cannot listen to device 1.

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

A Scenario for the Operation of Mesh Network

12

3

4

5

6

78

9

• Issues to be resolved– Association and Reassociation Procedure

– Beacon Scheduling

– Short Address Allocations

– Creation and Update of Neighborhood Table

46

9

PNC

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

PNC Formation of the Mesh

1

• Device 1 first scans passively and actively, and found that there is no device that he can associate.

• So, it becomes the PNC.• Once a device becomes a PNC, it starts to transmit its beacon at the beginning of the

superframe.

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

Joining of Device 2 to the Mesh

Beacon-Only Period

Active Period

1

Inactive Period

CAP

2

2

1

• Dev. 2 hears the beacon form PNC and gets associated with it.• When associated, it gets PANID, Short Address, and other informations and

determines when to send its beacon. • Dev. 1 and 2 listen to beacons of each other and store information about their

neighbir in the Neighborhood Table.

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

Neighborhood Table for Mesh Node 1Device ID 2 … … …

PANID 1 … … …

Mesh neighbor

address 0x0002 … … …

RSSI(dBm) -49 … … …

BeaconTx-OffsetTime

2X maxBeaonLength

Device Information 1 … … …

• Neighborhood Table is created based on the beacon that it listens– PANID, Short Address, RSSI, PNC, Depth Information, Device

Information, and so on.

– The Device information of PNC is 0, and the device located in the 1 hop apart from the PNC has the device information of 2.

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

1

2

3

Beacon-Only Period

Active Period

1

CAP

2

3

Joining of New Node 3

• Device 3 is associated with PNC after it listens to the beacons transmitted from both PNC and Dev. 2.

• The PNC assigns the PANID and Short address to Dev. 3. • Then Dev. 3 determines when to send its beacon.

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

Device ID 1 2 … …

PANID 1 1 … …

Mesh Neighbor

Address 0x0001 0x0002 … …

RSSI(dBm) -49 -40 … …

BeaconTx-OffsetTime

1X

maxBeaconLength

2 X

maxBeaconLength

Device Info 0 1 … …

Neighbor Table for Mesh Node 3

• Dev. 3 stores information about its neighborhoods in the Neighborhood Table.

• Dev. 1 also updates its Neighborhood Table based on the beacon information that it hears.

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

1

3

54

2

Joining of New Dev. 5 outside the Range

• Dev. 5 can listen to beacons of only Dev. 2, 3, and 4 since it is outside the RF range of Dev. 1.

• Dev. 5 decides to associate with Dev. 2 because the beacon of Dev. 2 is the first one that it hears.

• Beacon transmission time of Dev. 5 is determined by itself in the way to avoid the beacon conflict.

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

Beacon-Only Period

Active Period

1

Inactive Period

CAP

2 3 4

5

Beacon Scheduling for Node 5

• Dev. 2 allocates the BeaconTxOffsetTime to Dev. 5 and send the BOP update command because Dev. 1 does not know whether Dev. 2 has allocated a BeaconTxOffseTime to Dev. 5

• When Dev. 1 receives BOP update command, it increments his BeaconTxOffsetTime register by 1.

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

Octet:2 1 4/10 2 Var. Var. Var. 2

Frame

Control

Sequence

number

Addressing

Fields

Superframe

Specification

GTS

Field

Pending

Address

field

Beacon

PayloadFCS

MHR MAC payload MFR

< BeaconTxOffsetTime >

Beacon Payload for the Mesh Formation

• On receipt of BOP update command, every device increments his BeaconTxOffsetTime information in its register.

• BeaconTxOffsetTime information is always transmitted in the beacon payload to update the neighborhood table.

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

New Joining of Node 6

2

4

5

6

46

1

3

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

Beacon Scheduling of Node 6

Beacon-Only Period

Active Period

1

Inactive Period

CAP

2 3 4 5

6

2

4

5

6

46

1

3

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

1

29

5

4

7

68

3

New Joining of Node 9

• Dev. 9 can listen to the beacon of Dev. 1 and is associated with it.

• Even though Dev. 9 cannot listen to Dev. 8, Dev. 8 is included in the neighborhood table of Dev. 9, because it is in the range of Dev. 8.

9

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

Device ID 1 2 3 4 5 6 7 8

PANID 1 1 1 1 1 1 1 1

Neighbor

address 0x001 0x002 0x003 0x004 0x005 0x006 0x007 0x008

RSSI(dBm) -49 -32 -59 … -69 -28 -58 -49 -57

BeaconTx OffsetTime

1X

MaxBeaconLength

2X

MaxBeaconLength

3X

MaxBeaconLength

4X

MaxBeaconLength

5X

MaxBeaconLength

6X

MaxBeaconLength

7X

MaxBeaconLength

8X

MaxBeaconLength

Device information

0 1 …1 1 2 2 2 2…

Neighborhood Table of Node 9

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

R

A B

C E F

N

Tree Link Direct Reachable

?

Beacon-Only Period

R A B C

Beacon-Only Period

R A B E F

An Example of Beacon Conflicts for Tree Topology

Occurrences of Beacon Conflicts in Tree

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

R

A B

C E F

N

Tree Link Direct Reachable

?

Beacon-Only Period

R A B C

Beacon-Only Period

R A B C E

F

1. BOP update command

Updated BeaconTxOffsetTime

BeaconTxOffsetTime can be selected based upon the updated BeaconTxOffsetTime

Beacon Conflicts and Avoidance in Tree

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

1 3 2

Unsupervised Beacon Scheduling

• Two PANs cannot listen to the other, such that they can never be associated.

• Then the Dev. 3 will never be associated when there beacon conflicts keep happening.

PAN 1 PAN 2

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

The Solution for Unsupervised Beacon

octets: 7 1

MHR fieldsCommand

frame identifier

1 3 2

1. Discovery Request

1. Discovery Request

1. Discovery Response

1. Discovery Response

1. Discovery request 1. Discovery response

octets: 7 2 1

MHR fieldsShort

address

Command

Frame Identifier

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission


• When Dev. 3 cannot listen to any beacon for a given predetermined period of time, it sends, after CSMA/CA, Discovery Request command.

• Dev. 1 that received Discovery request command performs a random number generation for its new BeaconTxOffset Time where he knows empty.

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

octets: 7 1

MHR fieldsCommand

frame identifier

Command

IdentifierCommand name

0 x 01 Association request

0 x 02 Association response

0 x 03 Disassociation notification

0 x 04 Data request

0 x 05 PAN ID conflict notification

0 x 06 Orphan notification

0 x 07 Beacon request

0 x 08 Coordinator realignment

0 x 09 GTS request

0 x 10 BOP update command

0 x 11 Discovery request

0 x 12 Discovery response

0 x 13 Beacon realignment request

0 x 14 Beacon slot empty request

octets: 7 1

MHR fieldsCommand

frame identifier

< BOP update command >

< Command frame identifier >

octets: 7 1

MHR fieldsCommand

frame identifier

<Beacon realignment request command>

<Beacon slot empty request command>


July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

Address Allocations

• Block addressing wastes address space

• Centralized Address allocations– May take too much time for the address

allocation.

• Distributed Address allocations– Beacon Scheduling mechanism can be used for

the address allocation

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

Conclusions

• Mesh network causes a lot of problems– Beacon conflicts

– Data Conflicts

– Address allocations

– Hidden node problems

– Delay-Sensitive Applications

– Power-saving mechanism

• Proposed some architectural solutions– Beacon scheduling

– Address allocation, if not quite in detail: next time

July 2005


doc.: IEEE 802.15-05-0455-00-005

Submission

Acknowledgment

• This work has been supported partly by HNRC of IITA and partly by TTA.

doc.: ieee 802.15-05-0455-00-005 submission july 2005 ho-in jeon, kyung-won university slide 1...

Documents