1 / 20

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: IEEE802.15.3: A proposal to add geographical coverage based criteria to PNC selection. Date Submitted: September 10, 2001 Source: Shig Sugaya, Kaz Takamura, Masa Akahane

wallis
Télécharger la présentation

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

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: IEEE802.15.3: A proposal to add geographical coverage based criteria to PNC selection. Date Submitted: September 10, 2001 Source: Shig Sugaya, Kaz Takamura, Masa Akahane Company: Sony Corporation Address: 2-17-1 Higashi-Gotanda Oval Court 13F Shinagawa-ku, Tokyo Japan 141-0022 Voice: +81.3.6409.3238, FAX: +81.3.6409.3203 E-Mail: sugaya@wcs.sony.co.jp, takamura@wcs.sony.co.jp, akahane@wcs.sony.co.jp Re: [ P802.15.3/D0.7] Abstract:This proposal presents defined Geographical Inquiry Process, Command sets and modified comparison order of fields that provide an accessible Device count for geographical coverage based PNC selection. Purpose: To provide an improvement to the current version of the 802.15.3 MAC 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 these viewgraphs becomes the property of IEEE and may be made publicly available by P802.15. S.Sugaya, K.Takamura, M.Akahane, Sony Corporation

  2. Assumptions on PNC Selection • Exist two kind of PNC-Capable DEVs • A DEV which wants to be a PNC • A DEV which does NOT want to be a PNC • PNC is selected among DEVs which want to be a PNC • DEVs which do NOT want to be, or CANNOT bea PNC shall associate a Piconet by acquiring the Beacon • “PNC-Capable” DEVs should NOT participate in PNC selection process if they are set “Abstain to be a PNC” S.Sugaya, K.Takamura, M.Akahane, Sony Corporation

  3. Case: Only 1 DEV wants to be PNC • There is only be 1 DEV to be set as PNC • Most cases all the DEVs to establish a Piconet are controlled by a single user • Turn on a DEV which should be the PNC and wait for 1 second then turn on the other DEVs S.Sugaya, K.Takamura, M.Akahane, Sony Corporation

  4. Case: More than 2 DEVs want to be a PNC • There may exist multiple DEVs want to be a PNC • In such a case multiple users want to establish an ad-hoc Piconet • PNC selection process is started if all the applicable DEVs which want to be a PNC turn their power on within 1 second (It might be a rare case such as a recovery from power failure) • If DEVs which want to be a PNC missed the associationtime window (“the” 1 second), they should associate the established Piconet as a “Loser” S.Sugaya, K.Takamura, M.Akahane, Sony Corporation

  5. Geographical Coverage BasedPNC Selection Procedure Current PNC Selection PNC PNC Good PNC Selection Bad PNC Selection Alternate PNC DEV Non-Alternate PNC DEV S.Sugaya, K.Takamura, M.Akahane, Sony Corporation

  6. Geographical PNC Selection • DEV that lost in Comparison does not participate in PNC Selection • GI Process allows Alternate PNC in the center of Piconet to be selected as PNC Alternate PNC A Alternate PNC B Alternate PNC C Alternate PNC Announcement Alternate PNC A Alternate PNC B Alternate PNC C Geographical Inquiry Process Alternate PNC Announcement Alternate PNC Announcement PNC Announcement PNC Announcement Alternate PNC Announcement Beacon Transmit Beacon Transmit PNC Announcement PNC PNC Beacon Transmit Piconet #1 Piconet #2 ??? PNC Good Selection Piconet S.Sugaya, K.Takamura, M.Akahane, Sony Corporation

  7. Hidden (Alternate PNC)Node Handling • GIP is the method to efficiently form the minimum Piconet required • If Hidden (Alternate PNC) Node exists, the creation of some Piconets is allowed Alternate PNC 1 Alternate PNC 2 Alternate PNC 3 Alternate PNC 4 Alternate PNC 5 Non-Alternate PNC 6 Non-Alternate PNC 7 Non-Alternate PNC 8 DEV 1 PNC 2 DEV 3 PNC 4 DEV 5 DEV 6 DEV 7 DEV 8 S.Sugaya, K.Takamura, M.Akahane, Sony Corporation

  8. Basic Discovery Mechanism • Adopt Inquiry transaction • All DEVs (PNC Capable or Incapable) respond to the Geographical Inquiry Request (GI-Req) • Alternate PNCs will count the number of nearby DEVs and compile their IDs, then broadcast the ID list of detected DEVs • ID : 48bit IEEE802 address of a DEV • DEVs that received this list broadcast a Geographical Inquiry Response (GI-Res) only when their own ID is not on the list S.Sugaya, K.Takamura, M.Akahane, Sony Corporation

  9. GeographicalInquiry Process (GIP) • All Alternate PNCs broadcastGI-Req • After the expiration of GI-Receive Timeout, update the DEV List and re-broadcast • GIP is terminated if no response is received within the 2nd or later GI-Receive Timeout • Non Alternate PNCs returnonly GI-Res • Non Alternate PNCs check whether its own ID is on the DEV ID List when they receive GI-Req • Broadcast GI-Res if its own DEV ID is NOT on the list • No response is returned if its own DEV ID is on the list S.Sugaya, K.Takamura, M.Akahane, Sony Corporation

  10. Broadcast of DEV ID List Alternate PNC DEV Non Alternate PNC DEV GI-Req (1st) GI-Receive Timeout GI-Res GI-Req (2nd) GI-Receive Timeout with Received DEV ID List • GIP is terminated when there is no response received within GI-Receive Timeout • At least two times of GI-Req shall be transmitted • Alternate PNC determines Accessible DEVs by exchanging more than one GI-Res • Other DEVs return at least one GI-Res • Advantage: Broadcasting DEV ID List reduces the number of response traffics S.Sugaya, K.Takamura, M.Akahane, Sony Corporation

  11. GI-Req Command Figure tbd：GI-Request Command • Set different GI-Receive Timeout for each DEV to avoid potential collisions • Add received DEV ID List in GI-Req every time • Cf) Maximum length (N=255) will be 1,544[Octets] • GI-Receive Timeout should be indicated in K [micro sec] as well as CS Timeout S.Sugaya, K.Takamura, M.Akahane, Sony Corporation

  12. GI-Res Command Figure tbd：GI-Res Command • GI-Res frame simply consists of Command Type, Length and DEV ID • The probability of collisions decreases with random access method if the length of the frame is short S.Sugaya, K.Takamura, M.Akahane, Sony Corporation

  13. Potential Collisions in GIP • Avoid Collisions of GI-Req • Set different Backoff for each DEV • Retransmission can decrease the probability of collisions • GIP is terminated if no response is received • Recover from Collisions of GI-Res • Detect collisions by checking whether its own DEV ID is on retransmitted device list (in GI-Req ) • Broadcast GI-Res if its own DEV ID is NOT on the list • GIP is terminated if its own DEV ID is on the list • No response is returned if its own DEV ID is on the list • GIP is terminated if no response is received S.Sugaya, K.Takamura, M.Akahane, Sony Corporation

  14. GI Process (Example 1) Time #2 #1 #3 #4 #5 • In case there are DEVs that one of the Alternate PNCs is out of reach GI-Res DEV #1 GI-Res DEV #2 GI-Req.-1 GI-Req.-2 #2,#4,#5 #1,#2,#4,#5 DEV #3 GI-Req.-2 GI-Req.-1 Alternate PNC #3 #3,#2,#5 DEV #4 Alternate PNC GI-Res DEV #5 Previous Step GI-Receive Timeout-3 Random Back-off GI-Receive Timeout-3 GI-Receive Timeout-4 GI-Receive Timeout-4 Next Action GI Process “Won by #3” S.Sugaya, K.Takamura, M.Akahane, Sony Corporation

  15. GI Process (Example 2) Time GI-Req.-2 GI-Req-1 #4,#5 #1 #2 #3 #4 #5 • 3 Alternate PNCs with one hidden PNC GI-Res DEV #1 Hidden #4 DEV #2 Alt PNC GI-Req.-1 GI-Req.-2 Hidden #4,#5,#1 #4,#5 DEV #3 GI-Req.-2 GI-Req.-1 Alt PNC #3 #3,#2,#5,#1 DEV #4 Alt PNC GI-Res DEV #5 Previous Step GI-Receive Timeout-3 GI-Receive Timeout-3 GI-Receive Timeout-2 Random Back-off GI-Receive Timeout-2 GI-Receive Timeout-4 GI-Receive Timeout-4 Next Action GI Process “Won by #4” (#2 & #3 can not see one another) S.Sugaya, K.Takamura, M.Akahane, Sony Corporation

  16. How to set GI-Receive Timeout Guard Time Preamble PLPC Header MAC Header GI_Response Payload With Back-off Time GI Response Data Frame Length Assumed to be 200 [micro sec] GI Response #1 GI Response #2 GI Response #3 GI Response #254 Max.254 Devices GI Response Transfer 50.8 [msec] GI Request-2 GI Request-1 Alternate PNC Announcement (or GI Request-3) Randomize Receive GI-Timeout 50 [msec] <50 [msec] 50 [msec] • Each device randomly sets up GI-Receive Timeout between 50 and 100[msec] • Assume that GI_Response is 200[micro sec] • For the maximum device number, i.e. 254 devices, 50.8[msec] is needed • Randomize GI-Receive Timeout within twice the time allows collision avoidance • The random factor is added only to the first internal • Next GI-Receive Timeout interval is fixed at 50 [msec] S.Sugaya, K.Takamura, M.Akahane, Sony Corporation

  17. Time Required for Geographical Selection GI Req-1 GI Req-2 APA Alternate PNC 1 GI-Receive Timeout GI-Receive Timeout 50-100 [msec] 50 [msec] GI Req-1 GI Req-2 APA Alternate PNC 2 GI-Receive Timeout GI-Receive Timeout 50-100 [msec] 50 [msec] (GI-Receive Timeout) x 2 or 3 100-250 [msec] Piconet Established Time About 1[sec] PNC Selection Association Authentication GI Process 500 [msec] 500 [msec] • Geographical Inquiry Process will be within twice or triple the GI-Receive Timeout • Actual Geographical Inquiry Process will be finished within 100 to 250[msec] • It can be included in PNC Selection, which is estimated to be over in 500[msec] S.Sugaya, K.Takamura, M.Akahane, Sony Corporation

  18. Add on Current PNC Selection First Alternate PNC Broadcasts Alternate PNC Announcement Other Alternate PNC Broadcast Alternate PNC Announcement Comparison Order 1: Designated mode in capability field Comparison Order 2 : SEC bit in capability field Comparison Order 3 : Battery / AC power Comparison Order 4 : PS bit Geographical Inquiry Process Comparison Order 5 : MAX GTS slots Comparison Order 6 : Repeater memory Comparison Order 7 : Transmit Power Level Comparison Order 8 : MAX PHY rate Comparison Order 9 : DEV ID A Winner of among Alternate PNCs Broadcasts PNC Announcement First Beacon Transmission • Add GIP on the current PNC Selection • No need if a PNC has uniquely been determined in higher comparison • If PNC has not uniquely been determined, enter GIP S.Sugaya, K.Takamura, M.Akahane, Sony Corporation

  19. Geographical Selection Comparison Order • Geographical Selection is made in coordination with other devices • Order 1-4 are the conditions for selecting PNC through coordinated operation with other devices • Order 5-10 are those for selecting PNC within the device’s own ability S.Sugaya, K.Takamura, M.Akahane, Sony Corporation

  20. Conclusion • Provision • There may exist DEVs which do NOT participate in the PNC selection process • Geographical Inquiry Process (GIP) is specified • All the DEVs send responses to the inquiry in order to report their existence (Alternate PNCs respond with GI-Req) • Broadcast of Accessible DEV List efficiently reduces data exchange • Reception of GI-Res is confirmed through the Accessible DEV List • Best Alternate-PNCs in terms of geographical coverage are selected • Estimate GI-Receive Timeout and Time Required for Geographical Selection S.Sugaya, K.Takamura, M.Akahane, Sony Corporation

More Related