1. Trang chủ
  2. » Công Nghệ Thông Tin

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

26 1 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 26
Dung lượng 346,7 KB

Nội dung

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 Outlines      IP Over Bluetooth Bluetooth Security WPAN Standards IEEE 802.15.3 Overview 802.15.3 ► ► Topology Coordination • • • • • ► ► ► ► Starting a Piconet Handing over control of piconet Creating child piconet Ending a Piconent Association/Disassociation Medium Access (Superframe) Channel Time Management Power management MAC Frame format Last Lecture          Bluetooth introduction Technical features Access technique Bluetooth topology/scenario Specifications Architecture Core Protocols Packet format Link connections IP Over Bluetooth  IP over Bluetooth v 1.0 IP Over Bluetooth  IP over Bluetooth v 1.1 Security User input (initialization) PIN (1 – 16 bytes) E2 Link key (128 bit) E2 Encryption key (128 bit) Pairing  Authentication key generation (Possibly permanent storage) Authentication Encryption key generation (Possibly permanent storage) Encryption  Key­stream generator Payload key  E2 Link key (128 bit) E2 Encryption key (128 bit) Key­stream generator Ciphering  Cipher data Data PIN (1 – 16 bytes) Payload key  Data WPAN Standards IEEE 802.15 standards IEEE standard Topic Data throughput 802.15.1 Bluetooth 1 Mbps 802.15.2 Coexistence of Bluetooth and 802.11b N/A 802.15.3 High­rate WPAN > 20 Mbps 802.15.4 Low­rate WPAN 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 13  Creating a child piconet ► A child piconet is one that is formed under an established piconet The established piconet then becomes the parent piconet ► The child piconet functionality is useful for either extending the area of coverage of the piconet or shifting some computational or memory requirements to another PNC 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 14  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, 15  Association and disassociation ► ► ► ► ► ► ► Associating with the piconet provides the DEV with a unique identifier, the DEVID, for that piconet The DEVID, one octet in length, is used instead of the DEV’s address, octets in length, to save overhead in the system The association process optionally provides information about the services available in the piconet as well as the services provided or PNC capabilities PNC broadcasts the information about all of the DEVs in the 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 reissued by the PNC However, the PNC is not allowed to reissue the DEVID until a waiting period hasexpired 16 Security  Security for the piconet is one of two modes ► Mode Open: • Security membership is not required and payload protection (either data integrity or data encryption) is not used by the MAC The PNC is allowed to use a list of DEV addresses to admit or deny entry to the piconet ► Mode 1—Secure membership and payload protection: 17 IEEE 802.15.3 - Superframe  The super-frame is composed of three parts: ► The beacon • Which is used to set the timing allocations and to communicate management information for the piconet ► 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) 18 Superframe # m ­ 1 Beacon #  m Contention  access  period Superframe # m Superframe # m + 1 Channel time allocation period MCTA  MCTA  Channel time is divided into superframe with Beacon Contains piconet synchronization parameter and IE (Information Element)s CAP (Contention Access Period) Optional For command frames and non-stream data Using CSMA/CA with backoff scheme CFP (Contention Free Period) CTA 1 CTA 2  .  CTA  n­1 CTA  n The MCTAs are shown first, but the PNC is allowed to place any number of them at any position in the superframe 19 IEEE 802.15.3 - CAP  CAP ► Allows contention via CSMA/CD  CTA ► 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 20 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 21  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 22 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) mode ► asynchronous power save (APS) mode  PSPS ► PSPS mode allows DEVs to sleep at intervals defined by the PNC ► The DEV sends a request to the PNC when it wants to enter the PSPS mode 23  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 24 MAC Frame format Octets: 0 or 4 L n FCS Frame payload bits: b23 b22­b16 b15­b9 b8­b0 Reserved Last fragment number Fragment  number MSDU number 1 2 Stream  index Fragmentation control SrcID DestID PNID Frame  control MAC header MAC frame body bits: b15­ b11 b10 b9 b8­b7 b6 b5­b3 b2­b0 Reserved More data Retr y ACK  policy SE C Frame type Protocol  version 25 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 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 ImmACK process while allowing the source DEV to verify the delivery of frames to the destination 26 ... and 802.11b N/A 802.15.3 High? ?rate WPAN > 20 Mbps 802.15.4 Low? ?rate WPAN

Ngày đăng: 05/07/2022, 13:26