1 / 19

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: ISO 21214, Link Budget Estimate, and Application Subclasses Date Submitted: May 2009 Source: Rick Roberts, Barry O’Mahony, Praveen Gopalakrishnan (Intel Corporation)

cade
Download Presentation

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: ISO 21214, Link Budget Estimate, and Application Subclasses Date Submitted: May 2009 Source: Rick Roberts, Barry O’Mahony, Praveen Gopalakrishnan (Intel Corporation) Address: Hillsboro, Oregon Voice: 503-929-5624, E-Mail: richard.d.roberts@intel.com Re: Abstract: This contribution provides an introductory summary of ISO 21214 and then uses the information provided in ISO 21214 to estimate range and data rate for a typical ITS application. The results show that ITS applications, servicing ~100 meter range, operate at a much lower data rate than short range mobile-to-mobile links. It is then suggested that we consider separating applications via a multi (2 or 3) part standard, where each part is a stand alone protocol catering to a specific application class. The objective is to achieve more optimal performance while maintaining co-existence and interoperability. Purpose: 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. Praveen Gopalakrishnan, Intel

  2. ISO 21214 – What is it? • Air Interface Standard for 820-1010 nm IR systems used in Intelligent Transport Systems (ITS) • Published 2006 • Prepared by ISO/TC 204 Working Group 16 committee for Continuous Air interface Long and Medium range communications ITS architecture (CALM) • For vehicle to vehicle, and vehicle to roadside communications • Data rates of 1 Mbit/s up to 128 Mbit/s; • Vehicle speeds up to a minimum of 200 km/h (closing speeds could be 2x); • Distances up to 100 m (optionally 300 m to 1 000 m); • Milliseconds-range latencies Praveen Gopalakrishnan, Intel

  3. CALM – What is it? • http://www.calm.hu • Definition of related set of protocols, procedures and management processes to support services for vehicle-to-vehicle and vehicle-to-infrastructure communications Praveen Gopalakrishnan, Intel

  4. ISO/TC 204 WG 16 Praveen Gopalakrishnan, Intel

  5. ISO 21214 PHY • Two passbands • Mandatory 820-910 nm main channel; optional 920-1010 nm alternate • 16 Transmitter Classes • 11 Receiver Classes • 10-6 reference BER • ≥ 1,120 W/m2 natural light (sunlight) immunity Praveen Gopalakrishnan, Intel

  6. PHY [2] • 7 Communications Profiles Praveen Gopalakrishnan, Intel

  7. PHY [5] – link Budget • Losses: free-space path loss + windshield loss (LW) + Weather attenuation (LWC) + Sunlight loss (LSUN) • IR Windshield loss < 7 dB (typically 1.4-5.5 dB) • IR Sunlight loss <2 dB (full sun) Praveen Gopalakrishnan, Intel

  8. PHY [6] – link budget • Ideal (free-space) achievable distances (base profile?) Praveen Gopalakrishnan, Intel

  9. So what TX and RX class should be used? • Assume RX class is R9 (best estimate at this time) • To determine TX class … • Assume LED is similar to LUMEX SLX-LX5093UWC/C • axial intensity: 3500 mcd (milli-candelas) • viewing Angle: 40 degrees (2x theta) • 88 LEDs per traffic light (8 inch) • total candela: 308 cd • One candela = (1/683) watt/sr @ 540 THz • assume our energy is ~540 THz (upper bound) • 451 mW/sr (between TX class 1 and TX class 2) • interpolate the range Ref: http://en.wikipedia.org/wiki/Candela Praveen Gopalakrishnan, Intel

  10. Range Estimate based upon slide 8 table • Range Estimate • TX-1 with RX-9 class: 20 meters • TX-2 with RX-9 class: 28 meters • Interpolated Range: 22 meters (assuming base profile of 1 Mbps) • Not considering any other losses (environment, other light sources) • Data rate reduction estimate • Desired Range: 100 meters • Link Budget Range Shortage: (100/22)=4.5 (~13 dB) • What to do? One suggestion is to reduce the data rate! • 13 dB reduction ratio is 10^(13/10)=20 • Reduced Data Rate Estimate: (1 Mbps/20)=50 kbps • An optimistic calculation gives rate of 400 kbps @ 100m • Details provided in backup slides • Actual rate is probably between 50 to 400 kbps … more testing needed Praveen Gopalakrishnan, Intel

  11. Observations • There are assumptions in this analysis … need to do more work • It appears that ITS applications could have data rates that fall well below 1 Mbps due to link budget limitations • Do we need to design a common set of data rates and protocols that service all VLC applications? …. let us consider application requirements. • Three possible classes of applications emerging … • Vehicular with data rates < 1Mbps over long range (100m) • Static usages: Mobile to Mobile and indoor Mobile to Infra at short ranges (~1-10 meters) with data rates >> 1 Mbps • Information Broadcast: Outdoor and between mobiles and Infra (range and data rate TBD) Praveen Gopalakrishnan, Intel

  12. Vehicular vs. Static usage requirements • System requirements • Vehicular: Provide highly robust communication to support Safety and other apps. Work well under diverse conditions (high speed, high density..). Ranges of up to 100m. • Static usages: Provide high data rate QoS support over short ranges, covering a number of different usages. • Discovery/link establishment • Vehicular: Difficult due to mobility, need to track multiple sources, and need for automatic beam steering. Need to support fast discovery and tracking. • Static usages: Easier due to no/low mobility, and possibly manual beam pointing • Link performance • Vehicular: Many usages are focused on safety and high robustness under different operating conditions is critical. Data rates from 10’s kbps to few Mbps • Static usages: Primary requirement is high data rate (10’s Mbps to Gbps) and QoS support. • Type of applications/traffic • Vehicular: Mostly short messages, sometimes pictures/map. Mostly broadcast. • Static usages: Mostly large data and A/V. Mostly unicast. • Design requirements/constraints are different • Many devices will serve one class (vehicular or static) exclusively Praveen Gopalakrishnan, Intel

  13. Protocol design considerations • Try to ensure that design considerations for one class not to restrict performance for other class (ex: high data rates for static usages not to restrict robustness for vehicular and vice-versa) • It may be that we want to write a multi (2 or 3) part standard where each part is a stand alone protocol, catering to a specific application class (ex: one for static usages, one for vehicular) • We must guarantee co-existence and facilitate interoperability among the stand alone protocols Praveen Gopalakrishnan, Intel

  14. Options for interop and coexistence • Mandate that all outdoor devices be able to communicate at common low rate mode • Can use high rate modes optionally if both end points support it (TDM) • Frequency banding application classes • FDM (at the photodector output) to put each of these applications in their own frequency band ITS Applications Info Applications High Speed Applications frequency Praveen Gopalakrishnan, Intel

  15. Backup Slides Praveen Gopalakrishnan, Intel

  16. PHY [3] • Profiles 0 & 1 • Each byte encoded with R=2/3 Hamming code Praveen Gopalakrishnan, Intel

  17. PHY [4] • Profile 2 to 6 • CALM-fast IR Packet Format • R=2/3 RLL code • Average duty cycle ~26% • ~8.3% to ~33% range • Prepend Preamble and Start; • Append CRC32, Flush & Stop bytes Praveen Gopalakrishnan, Intel

  18. Advantages of Frequency Banding • Allows a different protocol and MCS to be used for each application • i.e. highly mobile auto applications have a difficult device discovery problem that does not exist for static home networks • ITS applications may be a significantly lower data rate than high speed in home networks (and short range mobile-to-mobile) • Provides definitive knowledge of where to “tune” for each of these applications • allows a software configurable device to service all applications • Guarantees co-existence and facilitates device interoperability • i.e. a car parked in a garage can participate in the high speed home network by frequency tuning Praveen Gopalakrishnan, Intel

  19. Optimistic link budget • TX: TX2 class (500 mW/Sr) • RX: RX9 (best estimate)  0.12 (for default 2Mbps profile) • d = 64m (using equation sqrt(TX/RX)) • For 1 Mbps profile assume RX sens is 3dB lower. Then for 1Mbps d = 91m • This is with zero margin! Typical losses are at least a few dB. (other losses + margin ~ 5 dB) • distance = 64m. • Link Budget Range Shortage: (100/64)=1.5 (~4 dB) • What to do? One suggestion is to reduce the data rate! • 4 dB reduction ratio is 10^(4/10)=2.4 • Reduced Data Rate Estimate: (1 Mbps/2.4)= 400 kbps Praveen Gopalakrishnan, Intel

More Related