Wireless networks - Lecture 40: High rate wireless personal area networks (WPAN)

Wireless networks - Lecture 40: High rate wireless personal area networks (WPAN). The main topics covered in this chapter include: IP over bluetooth; bluetooth security; WPAN standards; IEEE 802.15.3 overview; 802.15.3; channel time management; power management; MAC Frame format;...

Wireless Networks

Lecture 40 High Rate Wireless Personal Area Networks

(WPAN)

Dr Ghalib A Shah

• Handing over control of piconet

• Creating child piconet

• Ending a Piconent

• Association/Disassociation

► Medium Access (Superframe)

► Channel Time Management

► Power management

► MAC Frame format

IP Over Bluetooth

 IP over Bluetooth v

1.0

IP Over Bluetooth

 IP over Bluetooth v

1.1

Encryption key generation (Possibly permanent storage)

Cipher data

WPAN Standards

IEEE standard Topic Data throughput Suitable applications QoS needs

802.15.1 Bluetooth 1 Mbps Cell phones, Computers, Personal Digital

Assistants (PDAs)/ Handheld Personal Computers (HPCs), Printers, Microphones, Speakers, Handsets, Bar Code Readers, Sensors, Displays, Pagers and Cellular & Personal

Communications Service (PCS) phones

QoS suitable for Voice

applications

802.15.2 Coexistence

of Bluetooth and 802.11b

IEEE 802.15 standards

IEEE 802.15.3 - Overview

 High data rate WPAN

 Potential future standard

 Motivation: Data, High quality TV, Home

cinema

 Dynamic topology

► Mobile devices often join and leave the

piconet

► Short connection times

 Multiple Power Management modes

 Secure Network

 2.4 GHz PHY

► 4 channels (high density) or 3 channels (with

802.11b) modes are available

► Supports 5 data rates

• 11Mbps(QPSK)

• 22Mbps(DQPSK without coding)

• 33Mbps(16QAM)

• 44Mbps(32QAM), 55Mbps(64QAM)

IEEE 802.15.3 - Overview

 Based on piconets in a person space analogous

to LAN in larger area

 Data Devices (DEV) establish peer-to-peer

communication

 Includes also a Piconet Coordinator (PNC)

► PNC manages the quality of service (QoS)

requirements, power save modes and access control to the piconet

 A new piconet created with same channel as of

the existing PNC is called child/neighbor piconet

► If channel access is also controlled by the parent PNC

then it is called dependent piconet

IEEE 802.15.3 - Topology

802.15.3

 IEEE 803.15.3 MAC is designed to support

the following goals:

► Fast connection time

Coordination in IEEE 802.15.3

 Starting a piconet

► DEV scans for the best channel and sends out beacons

-> the DEV becomes PNC

► If no channels available: Establishes a child or neighbor

piconet instead

► While the process of starting a piconet does not ensure

that the “most capable” PNC is initially selected

 Handing over control of the piconet

► When a DEV associates, PNC checks the capabilities of

the new DEV to see if it is more capable to be the PNC

of the piconet

► In handover process, it maintains all existing time

allocations so that there is no interruption in the delivery

 Creating a child piconet

► A child piconet is one that is formed under an

established piconet The established piconet then becomes the parent piconet

either extending the area of coverage of the piconet or shifting some computational or

capable DEV

► The child piconet uses a distinct piconet ID

(PNID) and acts as an autonomous piconet except that it is dependent on a private CTA from the parent piconet.

 Ending a piconet

► If the PNC is going to stop operation and there are no

other PNC capable DEVs in the piconet, the PNC places the PNC Shutdown information element (IE) into the beacon to notify the members of the piconet

► In the case that the PNC abruptly leaves the piconet

without handing over control to another PNC capable DEV in the piconet, the piconet stops operation

► After the association timeout period (ATP) expires, a

PNC capable DEV from the old piconet will be able to start a new piconet using the normal process,

► In the case of dependent piconets, the parent PNC is

able to end the dependent piconet via the Disassociation Request command,

 Association and disassociation

► Associating with the piconet provides the DEV with a unique

► The DEVID, one octet in length , is used instead of the DEV’s

address, 8 octets in length, to save overhead in the system

► The association process optionally provides information about

provided or PNC capabilities

piconet, and places information in the beacon about the new DEV.

► When a DEV wants to leave the piconet or if the PNC wants to

remove a DEV from the piconet, the disassociation process is used

► The DEVID of the disassociated DEV is no longer valid, until

► However, the PNC is not allowed to reissue the DEVID until a

► Mode 1—Secure membership and payload

protection:

► The contention access period (CAP)

• Which is used to communicate commands and/or asynchronous data if it is present in the superframe

► The channel time allocation period (CTAP)

• Which is composed of channel time allocations (CTAs), including management CTAs (MCTAs)

The MCTAs are shown first, but the PNC is allowed to place any number of them at any position in the

Element)s CAP (Contention Access Period)

Optional For command frames and non-stream data

Using CSMA/CA with backoff scheme

CFP (Contention Free Period)

For data stream PNC assigns

to DEV with each CTA

Superframe # m ­ 1 Superframe # m Superframe # m + 1

Beacon # 

m Contention access 

period

Channel time allocation period MCTA 

1 MCTA 2 CTA 1 CTA 2 . . . CTA 

n­1 CTA n

► The CTAP, uses a standard TDMA protocol where the

DEVs have specified time windows,

 Contention Free Access

► To enable power saving and QoS

► CTA

• Private CTA – for dependent piconet

• Dynamic CTA – scheduled on a superframe by superframe basis

• Pseudo-Static CTA – only for isochronous stream Allowed

to transmit during CTA as long as the number of consecutive lost beacon is less then mMaxLostBeacons

Channel time management

 There are three methods for

communicating data between DEVs in the piconet:

► Sending asynchronous data in the CAP, if

present.

► Allocating channel time for isochronous

streams in the CTAP.

► Allocating asynchronous channel time in the

CTAP.

 Dynamic channel selection

► Due to ISM bands, piconet is subject to interference

from unlicensed users or other 802.15.3 piconets

► PNC has the capability to dynamically change the

channel that the piconet is using without requiring either user intervention or the disruption of services in the piconet

► To evaluate the status of the current channel as well as

other channels, the PNC is able to use many methods including:

• Gathering information about the current channel from other DEVs in the piconet using the Channel Status Request command.

• Performing a passive scan of the channels.

• Requesting other DEVs to perform a channel scan using the Remote Scan Request command,

Power Management

 standard provides three techniques to

enable DEVs to turn off for one or more superframes:

► device synchronized power save (DSPS) mode

► piconet-synchronized power save (PSPS)

► The DEV sends a request to the PNC when it

wants to enter the PSPS mode

 DSPS

► Besides allowing the DEVs to wake up and

exchange traffic at the same time, the use of DSPS sets makes it easy for other DEVs in the piconet to determine exactly when a DSPS

DEV will be available to receive traffic.

 APS

► The only responsibility of a DEV in APS mode

is to communicate with the PNC before the end of its ATP in order to preserve its

membership in the piconet.

MAC Frame format

bits: b23 b22­b16 b15­b9 b8­b0 Reserved Last fragment number Fragment 

MAC header

bits: b15­

b11 b10 b9 b8­b7 b6 b5­b3 b2­b0Reserved More data Retr

y policyACK  SEC Frame type Protocol version

ACK Policy

 If the source DEV wishes to verify the delivery of

a frame, then one of the acknowledgement

(ACK) policies

► NO ACK

• The no-ACK policy, is appropriate for frames that do not require guaranteed delivery, where the retransmitted frame would arrive too late or where an upper layer protocol is handling the ACK and retransmission protocol

► The immediate-ACK (Imm-ACK) policy,

• it provides an ACK process in which each frame is individually ACKed following the reception of the frame

► The delayed-ACK (Dly-ACK) policy,

• it lets the source send multiple frames without the intervening ACKs Instead, the ACKs of the individual frames are grouped into a single response frame that is sent when requested by the source DEV

• The Dly-ACK process decreases the overhead in the ACK process while allowing the source DEV to verify the delivery of frames to the destination.