Dynamic Frequency Hopping Community

boorishadamantΤεχνίτη Νοημοσύνη και Ρομποτική

29 Οκτ 2013 (πριν από 3 χρόνια και 5 μήνες)

151 εμφανίσεις

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
1

Dynamic Frequency Hopping Community

IEEE P802.22 Wireless RANs Date:

2006
-
06
-
29

Authors:

Notice:

This document has been prepared to assist IEEE 802.22. It is offered as a basis for discussion and is not binding on the cont
rib
uting 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, a
men
d or withdraw material contained herein.


Release:

The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and an
y m
odifications thereof, in the creation of an IEEE
Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of
thi
s contribution; and at the IEEE’s sole discretion to permit
others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accep
ts
that this contribution may be made public by IEEE 802.22.


Patent Policy and Procedures:

The contributor is familiar with the IEEE 802 Patent Policy and Procedures
http://standards.ieee.org/guides/bylaws/sb
-
bylaws.pdf

including the
statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives a
ssu
rance from the patent holder or applicant with respect to
patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working
Gro
up of patent information that might be relevant to the standard
is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publi
cat
ion will be approved for publication. Please notify the Chair

Carl R. Stevenson

as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be

i
ncorporated into a draft standard being
developed within the IEEE 802.22 Working Group.
If you have questions, contact the IEEE Patent Committee Administrator at
patcom@iee.org
.

>


awo@ieee.org

+49
-
30
-
314
-
29707


Germany

Technische Universität Berlin

Adam Wolisz

willkomm@tkn.tu
-
berlin.de

+49 30 314 23830

Germany

Technische Universität Berlin

Daniel Willkomm

abusbeih@tkn.tu
-
berlin.de

+49 30 314 23830

Germany

Technische Universität Berlin

Murad Abusubaih

gross@ee.tu
-
berlin.de

+49
-
30
-
314
-
23830


Germany

Technische Universität Berlin

James Gross

george.vlantis@st.com

+1
-
408
-
451
-
8109

USA

STMicroelectronics

George Vlantis

Wendong.hu@st.com

+1
-
408
-
467
-
8410

USA

STMicroelectronics

Wendong Hu

Liwen.chu@st.com

+1
-
408
-
467
-
8436

USA

STMicroelectronics

Liwen Chu

email

Phone

Address

Company

Name

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
2

Abstract


The key idea of DFHC is that one
-
hop BS neighbours create a DFH
community. A priority value is used to elect a DFH community leader. The
elected leader decides when and which channel to hop among a available
channel set for each community member, and the community members hop
among the available channels according to the leader’s decision in a
synchronised fashion. All the community members shall use the same working
channels. The hopping information does not change if the DFHC community
is stable (no community member joins or leave the community, and active
channels used by the community are usable by the community). This method
can avoid hopping collision and does not need real
-
time inter
-
BS
communication.

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
3


DFHC Introduction


DFHC Simulations


Conclusions


Backup Slides


Messages And Algorithms


DFHC Implementation


Common Management Channel


Possible Future Extension

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
4

Basic Assumptions


The community members shall use the following
methods to synchronize with their leader:


GPS which is used by 802.16h,


synchronizing with leader timer.


The inter
-
BS communication can use the following
methods:


Connection
-
based method,



common management channel method,


communication through IP network which is used by 802.16h,


other possible methods.

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
5

DFHC Overview


One
-
hop neighbors may become a DFHC community if
the following conditions are satisfied:


the number of usable channels are larger than the number of DFHC
community members


No channel is shared among overlapped neighbor DFHC
communities


No channel is shared among a DFHC community and its
overlapped neighbor BSs working in non_hop mode


Quiet time must meet the minimum requirements


Each DFHC community has a community leader and 0
to more community members.


Each community leader selects working channels for
each community member joining it among usable
channels.

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
6

DFHC Overview


Members of each community must hop in the same
working channel set.


The channel hopping information (start time and dwell
time in each working channel) are determined semi
-
dynamically



during the DFHC community initialization


DFHC community state change


neighbor BS joining


community member leaving.

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
7

DFHC Overview


A 802.22 system working in DFHC mode cognitively
and continuously switches operation frequencies for
data transmissions


A 802.22 system performs both data transmissions on a
channel, say Channel A, and RF sensing on DFH
community channels which are part of channels [0, A
-
n]
and channel [A+n, N] in each operation period


Channel “0” and Channel “N”


Lower bound and upper bound of the sensing spectrum


“n” is the number of channels in the guard band

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
8

DFHC Community Examples

WRAN2

WRAN1

WRAN3

WRAN4

WRAN5

WRAN6

DFHC Community1: WRAN1, WRAN2,
WRAN3

Normal mode: WRAN4

DFHC Community5: WRAN5, WRAN6

Community Member

Community Leader

Working in Non_Hop Mode

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
9

Community Leader Election and Maintenance


Each community leader decides if the community
accepts a new neighbor as a member of the community


The algorithm is not part of the standard. A informative algorithm
is that if the channel set of the original DFHC community can
accommodate the added one
-
hop neighbor in DFHC mode, then the
neighbor is accepted.


Each community leader calculates the channel hopping
information for each community member and broadcasts
the information.


Each leader transmit LDRA(leader announcement)
messages periodically, each member responds with a
MBRA (member announcement) message after each
receipt of LDRA.


Each leader maintains a community member table


If the leader does not receive messages from a member for some
time, it removes this member from the member table.

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
10

Community Leader Election and Maintenance


A DFHC leader election and maintenance protocol
[similar to the 802.1d root election protocol] is defined


A priority value+Mac Address is used to decide which DFHC
community member is elected as DFHC community leader


If community members do not receive LDRA message for some
time, the members will return to non_hop mode


The new joining BS with high priority can not make leader re
-
election occur.

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
11

Leader Election


The standard defines a mandatory algorithm.


If the following events occur, a BS may run the leader
election algorithm to try to elect itself as a community
leader


It has sent 3 BSANN messages and it has not requested to join any
neighbor community


It can not elect itself as a leader after event 1, it does not join any
neighbor community and a high priority neighbor BS join a
community


Simplified leader election algorithm:


If a BS is the BS with highest priority among its neighbors working
in non_hop mode and there are more than two usable channels, it
will elect itself as a community leader.



After the successful election, the leader will transmit a
LDRA (leader announce message) right away.


doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
12

Leader Election Example1


WRAN0 has highest priority among these three WRAN
systems. There are 4 usable channels.

Community Member

Community Leader

Working in Non_Hop Mode

WRAN1

WRAN0

WRAN2

BSANN

BSANN

WRAN1

WRAN0

WRAN2

LDRA

LDRA

BSANN

BSs broadcast BSANN messages

WRAN with high priority elects itself as
community leader

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
13

Leader Election Example2


WRAN with smaller id value has higher priority. There are enough
usable channels for each BS.

WRAN3 can not elect itself as a leader since there is a non_hop high
priority neighbor

WRAN3 can not request to join any community since it is not neighbor
of WRAN5 and WRAN6

WRAN2 joins community 0

WRAN3 elects itself as a community leader

WRAN0

WRAN3

WRAN2

WRAN4

WRAN1

Community Member

Community Leader

Working in Non_Hop Mode

WRAN0

WRAN3

WRAN2

WRAN4

WRAN1

WRAN5

WRAN6

WRAN5

WRAN6

WRAN0

WRAN3

WRAN2

WRAN4

WRAN1

WRAN5

WRAN6

WRAN0

WRAN3

WRAN2

WRAN4

WRAN1

WRAN5

WRAN6

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
14

Joining Leader Selection Algorithm


A BS working in non_hop mode uses the received new
LDRA message, its neighbor information and usable
channels to decide if it should join a community.


If the following events occur, a BS may run the member
joining algorithm to try to join a community


a new LDRA is received from its neighbor


It has more usable channels after sensing


802.22 implementation can select any algorithm to select
a leader to join.


Informative algorithm


If there is a neighbor leader which satisfies the minimum
community joining requirement ( all the members are neighbors,
the number of usable channels are more than the number of the
members), a BS working in non_hop mode will select a neighbor
community to join and send out MBRA message to the selected
leader to ask for the joining.


doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
15

Joining Leader Selection Example


Each WRAN system can select channels from channel0 to channel5
if its neighbors do not use them.

WRAN0

WRAN3

WRAN2

WRAN4

WRAN1

WRAN0 uses channel0, 5

WRAN1 uses channel1, 5

WRANi uses channeli (i>1)

WRAN0

WRAN3

WRAN2

WRAN4

WRAN1

LDRA0

LDRA0

LDRA1

LDRA1

MBRA2

MBRA4

Community Member

Community Leader

Working in Non_Hop Mode

WRAN2 can request to join Community0 since it is the neighbor of
WRAN0 and WRAN0, 2 have usable channel 0, 1, 2, 5.

WRAN4 can request to join Community1 since it is the neighbor of
WRAN1 and WRAN1, 4 have usable channel 0, 1, 4, 5.

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
16

Hopping Information Calculation Algorithm


A community leader uses hopping information calculation
algorithm to decide the channel hopping information (start time,
dwell time in each channel) for each community member.


Any algorithm being selected shall satisfy the following
requirements:


the number of the working channels is at least the same as the number of
the community members plus 1.


the dwelling time in each channel is smaller than 2000 milliseconds.


The quiet time between one dwelling’s leaving time and the following
dwelling’s entering time in each working channel is larger than the time
length of incumbent user’s requirement.



When the following events occur, a leader shall recalculate the
hopping information:


a new joining request is accepted by this leader.


A community member leaves the community.

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
17

Hopping Information Calculation Algorithm

chan_id<working_chan_num?

yes

no

Set member_id’s chan_id hopping information:

1), start_time=time_shift*member_id+


chan_id*channel_dwell_time

2),BS dwell channel_dwell_time in the channel

corresponding to chan_id

Set chan_id+=1

Set member_id=0

Set chan_id=0

Member_id<member_number?

start

Enough usable channels?

stop

Select working channel set

yes

yes

no

stop


The following is a simplified informative algorithm

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
18

Hopping Information Calculation Example1

WRAN1

WRAN2

Community Member

Community Leader

Working in Non_Hop Mode

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
19

Hopping Information Calculation Example2

WRAN2

WRAN1

WRAN3

Community Member

Community Leader

Working in Non_Hop Mode

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
20

Inter
-
Community Communication


Each community member broadcasts CMUA
(community announcement message) periodically to its
neighbor communities/BSs working in non_hop mode.


The BSs working in non_hop mode use neighbor
community information as one kind of input to
calculate their usable channels.


If two neighbor communities select overlapped working
channels at almost the same time, the community with
low priority will give up.

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
21

Inter
-
Community Communication Example

WRAN0

WRAN3

WRAN2

WRAN4

WRAN1

WRAN0

WRAN3

WRAN2

WRAN4

WRAN1

WRAN0

WRAN3

WRAN2

WRAN4

WRAN1

WRAN0

WRAN3

WRAN2

WRAN4

WRAN1

Community0 uses channel0, 5. Community1 uses
channel1, 5.

Request to join the community

Community0 uses channel0, 2, 5. Community1
uses channel1, 4, 5.


Accept to joining request

Using MBRA to ack the LDRA

send MBRA and find overlapping working channel 5

Low priority community gives up

MBRA

MBRA

LDRA

LDRA

MBRA

MBRA

CMUA

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
22

DFHC Operation Circle


During a DFHC operation cycle


BS schedules the system to switch (hop) to channel (set) A
according to the pre
-
defined channel hopping sequence


BS and CPEs perform data transmissions on channel (set) A


BS performs, and schedules CPEs to perform spectrum sensing on
channel [0, A
-
n] and [A+n, N]


CPEs report sensing measurement results


BS performs report processing


BS selects the pre
-
defined channel as the hopping channel if the pre
-
defined channel is available


BS switch to the normal mode if the pre
-
defined channel is not
available

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
23


DFHC Introduction


DFHC Simulations


Conclusions


Backup Slides


Messages And Algorithms


DFHC Implementation


Common Management Channel


Possible Future Extension

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
24

Simulation Scenario1


Three WRAN systems (WRAN0
--
WRAN2) with 6
usable channels (Chan0
--
Chan5).


All three WRAN systems have the same priority values.


Channel dwelling time: 2000milliseconds.


BS/Leader Announce Interval: 1000milliseeconds.


BS2BS delay: 100milliseconds.


Retransmission timeout: 300milliseconds.


WRAN1

WRAN0

WRAN2

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
25

Simulation Scenario1
--
Setup Time & Load

WRAN1

WRAN0

WRAN2

Community Member

Community Leader

Working in Non_Hop Mode

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
26

Simulation Scenario1
-
Hopping Information


Hopping scheduled by leader0 is shown in the
following table


doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
27

Simulation Scenario2


Five WRAN systems (WRAN0
--
WRAN4) with 6 usable channels
(Chan0
--
Chan5).


All WRAN systems have the same priority values.


Channel dwelling time: 2000milliseconds.


BS/Leader Announce Interval: 1000milliseeconds.


BS2BS delay: 100milliseconds.


Retransmission timeout: 300milliseconds.

WRAN0

WRAN3

WRAN2

WRAN4

WRAN1

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
28

Simulation Scenario2
-
Setup Time & Load

WRAN0

WRAN3

WRAN2

WRAN4

WRAN1

Community Member

Community Leader

Working in Non_Hop Mode

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
29

Simulation Scenario2
-
Hopping Information


Hopping scheduled by leader0 is shown in the following table


Hopping scheduled by leader1 is shown in the following table



Hopping scheduled by leader1 is shown in the following table


doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
30


DFHC Introduction


DFHC Simulations


Conclusions


Backup Slides


Messages And Algorithms


DFHC Implementation


Common Management Channel


Possible Future Extension

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
31

Conclusions


DFH Community is introduced to simplify DFH real
-
time operation


No per
-
operational period channel selection is required


No dynamic frequency hopping sequence and no
frequency hopping collision occur


Feasible


Clear sensing can be guaranteed with non
-
interrupted data
transmissions


Promising channel utilization


The simulations show that the DFHC protocol works.


The management message load is pretty low.


The community configuration time is pretty short.


Some intelligent algorithms are under consideration to
get optimized performance.


doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
32


DFHC Introduction


DFHC Simulations


Conclusions


Backup Slides


Messages And Algorithms


DFHC Implementation


Common Management Channel


Possible Future Extension

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
33

DFHC Messages


Four messages are defined in DFHC protocol


BS Announce Message (BSANN)


Member Announce Message (MBRA)



Leader Announce Message (LDRA)


Community Announce Message (CMUA)


The messages are the data part of its transport
protocol. If the CBP is used as its transport protocol,
DFHC messages are the data part of the CBP message.

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
34

BSANN Message


The BSANN message includes the following TLVs:


BS Information Set for neighbors


Channel Information Set for usable channels

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
35

LDRA Message


The LDRA message includes the following TLVs:


Hopping Information Set


Channel Information Set for usable channels


BS Information Set for community members


Channel Information Set for working channels

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
36

MBRA Message


The MBRA message includes the following TLVs:


BS Information Set for neighbors


Channel Information Set for usable channels

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
37

CMUA Message


The CMUA message includes the following TLVs:


Channel Information Set for working channels

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
38

TLVS


Channel IE


BS IE

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
39

Leader Election Algorithm


This algorithm is a mandatory algorithm which means
that all the BSs supporting DFHC shall implement it.


When the following events occur, a BS should run the
leader election algorithm to try to elect itself as a
community leader


It has sent 3 BSANN messages after there are enough idle channels and
it did not request to join any neighbor community


It can not elect itself as a leader after event 1, it does not join any
neighbor community and a high priority neighbor BS join a community

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
40

Leader Election Algorithm

get the next neighbor information

from the neighbor information set

start

Is there any

unchecked neighbor in the

neighbor information set?

Is this neighbor a

community leader?

yes

Is this neighbor a

community member?

yes

no

no

Does it have high

priority than this neighbor?

yes

no

stop

yes

no

Are there more than 2

usable channels?

no

stop

Elect itself as a community leader.

Select 2 working channels,

calculate channel hopping information

(start time, dwell time in each channel)

Create and broadcast a LDRA message

stop

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
41

Joining Leader Selection Algorithm


A BS working in non_hop mode uses received new LDRA
message, its neighbor information and usable channels to
decide if it should join a community.


When the following events occur, a BS should run the
member joining algorithm to try to join a community


a new LDRA is received from its neighbor


It has more usable channels after sensing


doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
42

Joining Leader Selection Algorithm

start

Is it a one
-
hop neighbor

of the all members of the LDRA?

yes

Usable channel number>

community member+1?

no

Get the usable channel set of this

BS and the community.

Select the leader to join it.

stop

no

stop

yes

Is there any

unchecked LDRA in the

neighbor LDRA set?

no

Get the next LDRA information.

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
43

Hopping Information Calculation Algorithm


A community leader uses hopping information calculation
algorithm to decide the channel hopping information (start
time, dwell time in each channel) for each community
member


The 802.22 implementation can select any algorithm to get
the hopping scheduling information. The following gives
an informative algorithm which has the following
characteristics:


the selected number of the working channels always equals to the
number of the community members plus 1


the dwelling time in each channel is 2000 milliseconds as required by
incumbent industry


the quiet time between one dwelling’s leaving time and the following
dwelling’s entering time in each working channel is
channel_dwell_time/community_numbe

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
44

Hopping Information Calculation Algorithm


Any algorithm being selected shall satisfy the following
requirements:


the dwelling time in each channel is smaller than 2000 milliseconds.


The quiet time between one dwelling’s leaving time and the following
dwelling’s entering time in each working channel is larger than the time
length of incumbent user’s requirement.



Other algorithms can also be considered:


select more working channels for backup in case incumbent user
interfering with the community


When the following events occur, a leader shall recalculate the
hopping information:


a new joining request is accepted by this leader.


A community leader leaves the community.

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
45

Hopping Information Calculation Algorithm

Calculate usable channels. These channels are

not used by incumbent users and its neighbors

which are not this community’s members


start


working_channel_number

>member_number?

yes

Is there a new usable channel

to be a working channel?

no

yes

no

chan_id<working_chan_num?

yes

no

stop

yes

no

A member leaves the community?

Remove a working channel from

the working channel set.

Add the selected channel to the working


channel channel set

Set time_shift to

channel_dwell_time/member_number

no

stop

Set member_id=0

Member_id<member_number?

Update sched_sequence

Set sched_effective_time to use

hopping information to hop among

working channels.

Set member_id’s chan_id hopping information:

1), start_time=time_shift*member_id+


chan_id*channel_dwell_time

2),BS dwell channel_dwell_time in the channel

corresponding to chan_id

Set chan_id=0

Set member_id +=1

Set chan_id+=1

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
46


DFHC Introduction


DFHC Simulations


Conclusions


Backup Slides


Messages And Algorithms


DFHC Implementation


Common Management Channel


Possible Future Extension

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
47

DFHC class

bsState_ : BsState

selfAddr_ : MacAddr

communitySeq_ : uint

totalChan_ : DbList<Chan>

usedChan_ : DbList<Chan>

incumbentChan_:DbList<Chan>

nonHopWorkingChan_:

DbLidt<Chan>

usableChan_ : DbList<Chan>

cmuUsableChan_ : DbList<Chan>

MbrLdrInfo
1

1

1

LdrLdrInfo

1

0..*

MbrLdrInfo
2

1

1

1

0..*

BsInfo
3

1

0..*

1

0..1

LdrAnnounce22

Timer

CommunityAnnounce22

Timer

1

0..1

Mac802_22_Dfhc

0..*

LdrInfo

BsInfo
4

NbrCommunityInfo

1

BsAnnounce22

Timer

1

1

1

0..1

HopingStart

Timer

+Mac802_22_Dfhc(Mac)

+~Mac802_22_Dfhc()

+handle()

+command()

+recv()

#recv(Ldra()

#recvMbra()

#recvBsa()

#recvCommunity()

#sendLdra

#sendMbra()

#sendBsa()

#sendCommunity()

-
hopAlgorithm()

-
ldrSelect()

-
transmit()

1, this BS selects a neighbor community to join from neighbor leader information set.

2, this leader information indicates a community that this BS joins.

3, this BS’s information.

4, the neighbor BSs’ information set.

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
48

DFHC Timers

BsAnnounce22

Timer

BsActive22

Timer

LdrAnnounce22

Timer

LdrActive22

Timer

Mac22Timer

MbrActive22

Timer

CommunityAnnounce22

Timer

CommunityActive22

Timer

ReTxTimer

HoppingStart

Timer

LdrSelect22

Timer

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
49

DFHC Timers


Mac22Timer: Abstract timer class which is super class of all the 22
timers.


BsAnnounce22Timer: it is a periodical timer. A BS announcement
message is sent out periodically according to this timer.


BsActive22Timer: Each time a BS receives a BSANN message from its
one
-
hop neighbor, this timer is reset. If this timer times out, the BS
information is removed and the neighbor relationship is lost.


LdrSelect22Timer: a BS elects a community leader among its one
-
hop
neighbors if this timer times out. This timer is stopped if a LDRA
message is received from its one
-
hop neighbor and it decides to try to
join the community.


LdrAnnounce22Timer: it is a periodical timer. A leader announcement
message is sent out periodically according to this timer by a
community leader.


LdrActive22Timer: each time a community member receives a LDRA
from its neighbor community or the community it joins, this timer is
reset. If this timer times out, the leader information is removed.



doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
50

DFHC Timers


MbrActive22Timer: Each time a leader receives a MBRA message
from its community member, this timer is reset. If this timer times out,
the member information is removed and the community member
relationship is lost.


CommunityAnnounce22Timer: it is a periodical timer. A community
announcement message is sent out periodically according to this timer
by a community member.


CommunityActive22Timer: each time a BS receives a CMUA from its
neighbor community, this timer is reset. If this timer times out, the
neighbor community information is removed.


ReTxTimer: the LDRA message with new channel hopping
information is sent out again after this timer times out. If all the joined
members response with MBRA messages, this timer is stopped.


HoppingStartTimer: the new channel hopping information is used
after this timer times out. Each time a LDAR with new channel
hopping information is received, this timer is set according to the
LDRA message.

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
51


DFHC Introduction


DFHC Simulations


Conclusions


Backup Slides


Messages And Algorithms


DFHC Implementation


Common Management Channel


Possible Future Extension

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
52

Common Management Channel


Each community leader selects its working channel with
minimal frequency value as the common management
channel.


The community members/leader use common management
channel to transmit DFHC CBP packets.


The CBP packets carry DFHC management information
elements.


A CPE shall only be locked to the community member
whenever it is scheduled to receive/send data from/to the
member (indicated through the US
-
MAP and DS
-
MAP
messages). At all other times during the frame, the CPE
shall tune to the common management channel and listen
to the medium and searching for a DFHC CBP packet.

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
53

Common Management Channel

Community 1:2 cells,

3 working channels: ch1
-
3,

ch1 has minimal frequency
value.

CBP period

ch1

ch2

ch3

CPE tunes to common
management channel

CPE tunes to working
channel of the BS it
associates with

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
54

Common Management Channel


When a BS is trying to join a community, it shall use the
sensing information to select potential common
management channel.


The occupied channel with minimal frequency value is the potential
common management channel


The BS indicate its CPEs to lock to the BS whenever it is
scheduled to receive/send data from/to the BS (indicated
through the US
-
MAP and DS
-
MAP messages). At all other
times during the frame, the CPE shall tune to the potential
common management channel and listen to the medium
and searching for a DFHC CBP packet.

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
55

Common Management Channel


If a normal CBP packet is received, the channel with next
minimal frequency value will be selected as the potential
common management channel.


If a DFHC CBP packet is received, the channel is a
common management channel used by a community.


The joining BS uses the common management channel to
switch DFHC management information with the
community leader.

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
56

Common Management Channel

Community 1:2 cells(BS1, BS2),

3 working channels: ch2
-
4.

BS4 in non
-
DFH mode, working
channel:ch1.

ch1 has minimal frequency value.

CBP period

ch2

ch3

ch4

BS2

BS1

BS4

BS3

BS1

BS2

BS3 tries to join community 1.

BS4

ch1

ch5

CPE tunes to (potential)
common management
channel

CPE tunes to working
channel of the BS it
associates with

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
57


DFHC Introduction


DFHC Simulations


Conclusions


Backup Slides


Messages And Algorithms


DFHC Implementation


Common Management Channel


Possible Future Extension


doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
58

Community Splitting and Merging

N+2 working channels

Y additional

(backoff) channels

Community 1: X cells,

X+1 channels

Community 2: N
-
X cells,

N
-
X+1 channels

Backoff bands are sensed by both clusters,


can be used in case of a primary appearance

Splitting

Merging

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
59

Community Splitting


split community give its neighbors more channels to use.


to create split communities, more available channels are
required.

Community 1:4 cells,

5 working channels: ch1
-
5

ch6 is a usable channel

Non DFH cell,

ch1
-
5 can not be used by it

Community 1:2 cells,

3 working channels: ch4
-
6

Non DFH cell,

ch1
-
3 can not be used by it

Splitting

Community 2:2 cells,

3 working channels: ch1
-
3

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
60

Community Merging


Merged community have more working channels to accept
new one hop neighbors as the new community members.

Community 1:4 cells,

6 working channels: ch1
-
6

Community 1:2 cells,

3 working channels: ch1
-
3

If green cell starts to work,
no channel is available

Community 2:2 cells,

3 working channels: ch4
-
6

If green cell starts to work, it can
join the community.

Merging

doc.: IEEE 802.22
-
06/0113r0

Submission

June 2006

Liwen Chu, STMicroelectronics

Slide
61

References