1. 1 OFDM, Mobile Software Development Framework 9/27/2012 Y. Richard Yang

2. 2 Admin. r Homework 2 to be posted by Friday r Start to think about project

3. 3 Recap r Inter-Symbol Interference (ISI) m Handle band limit ISI m Handle multipath ISI Viterbi –problems: Its complexity grows exponentially with D (the number of multipaths taps relative to the symbol time) –Q: how to reduce D?

4. 4 OFDM: Basic Idea r Uses multiple carriers modulation (MCM) m each carrier (called a subcarrier) uses a low symbol rate for N parallel subcarriers, the symbol time can be N times longer m spread symbols across multiple subcarriers also gains frequency diversity

5. 5 Benefit of Symbol Rate on ISI 123412341212

6. Multiple Carrier Modulation 6

7. 7 Multiple Carrier Modulation (MCM): Problem r Despite wave shaping, there can be leak from one subcarrier to another subcarrier r Conventional design: guard bands to avoid interference among subcarriers r Guard band wastes spectrum i j

8. Objective: Avoid subcarrier interference r Interference of subcarrier i on subcarrier j r Assume no pulse wave shaping, matched filter 8 i j Condition for the interference to be always 0?

9. 9 Objective: Avoid subcarrier interference if integer number of cycles in [0, T] # cycles in T is T * f => T * f = integer

10. 10 OFDM Key Idea: Orthogonal Subcarriers r Each subcarrier frequency is chosen so that an integral number of cycles in a symbol period, i.e., m subcarrier freq = k 1/T They do not need to have the same phase, so long integral number of cycles in symbol time T !

11. OFDM Modulation 11

12. 12 Orthogonal Frequency Division Multiplexing http://www1.linksys.com/products/images/ofdm.gif r OFDM allows overlapping subcarriers frequencies 802.11a

13. 13 OFDM Implementation r Take N symbols and place one symbol on each subcarrier (freq.) r Q: complexity of the implementation strategy? Freq 0 Freq N-1

14. 14 OFDM: Implementation Issue r Hardware implementation can be expensive if we use one oscillator for each subcarrier r Software implementation requires N multiplications per time output => N 2 multi. per N outputs Freq 0 Freq N-1

15. 15 OFDM: Key Idea 2 r Consider data as coefficients in the frequency domain, use inverse Fourier transform to generate time-domain sequence r Assume N outputs per symbol time T, f sc =1/T

16. 16 OFDM Implementation: FFT channel

17. 17 OFDM Implementation r Parallel data streams are used as inputs to an IFFT r IFFT does multiplexing and modulation in one step !

18. 18 Guard Interval: Removing ISI r Orthogonal subcarriers remove inter- carrier interference r Slow symbol rate reduces inter-symbol interference, but may still have ISI r Basic idea of GI: skip the first part “damaged” signal 1212 More details: Chap. 13.1.4 Gast

19. 19 OFDM Guard Interval http://www.dsplog.com/2008/02/17/cylcic-prefix-in-orthogonal-frequency-division-multiplexing/

20. 20 OFDM Implementation http://proquest.safaribooksonline.com/0596100523?tocview=true

21. OFDM in 802.11a r Subcarrier frequency spacing 312.5KHz m 1/312.5KHz = 3.2us m 64 samples FFT m 16 samples Guard Interval 21 http://standards.ieee.org/getieee802 /download/802.11a-1999.pdf

22. 22 Other Multipath Techniques r There are other techniques to handle multipath such as Rake Receiver r See backup slides for some details

23. 23 Summary of PHY

24. 24 Wireless PHY http://setemagali.com/2009/10/12/climbing-the-mountain-everyday/ PHY

25. Big Picture 25 Foundational Services: Communications, Location, Service Discovery, UI/Media, Power Management, Security Wireless/Mobile Application Development Framework Applications

26. Overview r Mobile/Wireless software development framework for mobile wireless applications is a quite large topic r We have already seen Gnuradio as an example framework r We will cover more examples m TinyOS, J2ME, Android, IOS r Approach for designing/evaluating each software development framework: m Focus on the key concepts introduced by each framework 26

27. 27 Outline r Admin and recap r Mobile/wireless development framework m GNURadio

28. 28 GNURadio: Design Objective r A software development toolkit that provides signal processing blocks to implement software-defined radio systems.

29. 29 Outline r Admin and recap r Mobile/wireless development framework m GNURadio Hardware setting

30. GNURadio Hardware Arch Hardware Frontend Host Computer RF Frontend (Daugtherboard) ADC/DAC and Digital Frontend (USRP) http://mobiledevices.kom.aau.dk/fileadmin/mobiledevices/teaching/software_testing/Gnu_radio_lecture.pdf GNU Radio Software

31. 31 Outline r Admin and recap r Mobile/wireless development framework m GNURadio Hardware setting Software concepts

32. Basic Software Concepts  Block  Flow graph

33. Basic Software Concepts  http://gnuradio.org/doc/doxygen/classgr __block.html  gr_basic_block (name, in/out signature, msg queue)  gr_block (Leaf block; key functions forecast/general_work)  Example: http://www.gnu.org/software/gnuradio/doc/howto- write-a-block.html  gr_hier_block2 (container block; key functions: connect/disconnect/lock/unlock)  gr_top_block (flow graph; start/stop/wait)

34. Software/Execution Model Python Application development Flow graph construction C++ Signal processing blocks  Software model  Python  Application management (e.g., GUI)  Flow graph construction  Non-streaming code (e.g., MAC-layer)  C++  Signal processing blocks  Certain routines also coded in assembly  Execution model  Python thread for each top_block Discussion: benefits/issues of the hybrid software structure?

35. 35 Summary: GNURadio r Interesting/key software design techniques you learned from GNURadio?

36. 36 Outline r Admin and recap r Mobile/wireless development framework m GNURadio Hardware setting Software concepts m TinyOS

37. 37 Design Goal r A free and open source component based operating system and platform targeting wireless sensor networks (WSNs) r Example app m Environment monitoring, e.g., measure temperature, lighting values/events periodically transmit measurements/events to a base station forward data for other nodes that are out of range of the base station r … http://www.tinyos.net/tinyos-1.x/doc/tutorial/

38. 38 Hardware r Assembled from off-the-shelf components r 4Mhz, 8bit MCU (ATMEL) m 512 bytes RAM, 8KB ROM r Devices m serial Port m temperature sensor & light sensor m 900Mhz Radio (RF monolithics) 10-100 ft. range m LED outputs 1.5” x 1.5”

39. 39 Schematic Diagram of a Mote

40. 40 Outline r Admin and recap r Mobile/wireless development framework m GNURadio Hardware setting Software concepts m TinyOS Hardware setting Software concepts

41. 41 Requirements on Software Dev. Framework r Flexible configuration of attached devices r Small foot print m devices have limited memory and power resources

42. TinyOS: Software Concept r TinyOS: Generate customized OS + application for each given scenario m support one application at a time but flexible reprogramming 42

43. 43 Schematic Diagram

44. 44 TinyOS: Software Concepts r A TinyOS consists of one or more components linked together m software components motivated by hardware component r Each component specifies that m it provides some interfaces allows other components to control it m also uses some interfaces control other components

45. 45 Interface r An interface declares m a set of functions called commands that provider must implement m another set of functions called events that the interface user must implement A uses interfaces I1 and I2 B provides I1 C provides I2 commands events commands events I1 I2 C provides I3

46. 46 Interface: Examples StdControl.nc interface StdControl { command result_t init(); command result_t start(); command result_t stop(); } Timer.nc interface Timer { command result_t start( char type, uint32_t interval); command result_t stop(); event result_t fired(); } ADC.nc interface ADC { async command result_t getdata(); async command result_t getContinuousData(); event result_t dataReady(uint 16_t data); }

47. 47 TinyOS Component: Implementation r Component contains: m commands and event handlers can invoke lower level commands, but cannot block m frame (storage) statically allocated, fixed size to know memory requirement and avoid overhead of dynamic allocation Component Internal State Internal Tasks CommandsEvents

48. 48 Linking Components Two types of components: m modules: individual components m configurations : assemble components together, connecting interfaces (objects) used by components to interfaces (objects) provided by others

49. 49 Example Application r A simple TinyOS application which periodically reads in the light intensity value, computes a moving average, displays it on the LED See SenseTaskM.nc SenseTask.nc

50. 50 Running tinyOS Program r make mica r ncc -o main.exe -target=mica SenseTask.nc r avr-objcopy --output-target=srec main.exe main.srec r Use uisp to install

51. 51 TinyOS Execution Model r Concurrency model: only two threads m long running tasks that can be interrupted by hardware event handlers r Tasks perform the primary computation work m commands and event handlers post tasks m call lower level commands m signal higher level events m schedule other tasks within a component r Each task is atomic with respect to other tasks m run to completion, but can be preempted by events m the task scheduler is a simple FIFO scheduler

52. 52 A More Complete Sample Application r Sensor network monitoring m monitor temperature and light conditions m periodically transmit measurements to a base station m sensors can forward data for other sensors that are out of range of the base station m dynamically determine the correct routing topology for the network

53. 53 Internal Component Graph RFM Radio byte Radio Packet UART UART Packet I2C Temp Light Active Messages Clocks bit byte packet Ad hoc Routing Application application HW SW

54. 54 Message Send Transition r Total propagation delay up the 5 layer radio communication stack is about 80 instructions Timing diagram of event propagation

55. 55 Evaluation: Storage Component NameCode Size (bytes) Data Size (bytes) Routing AM_dispatch AM_temperature AM_light AM RADIO_packet RADIO_byte RFM Light Temp UART UART_packet I2C 88 40 78 146 356 334 810 310 84 64 196 314 198 0 32 8 40 8 1 40 8 Processor_init TinyOS scheduler C runtime 172 178 82 30 16 0 Total3450226  Scheduler only occupies 178 bytes  Complete application only requires 3 KB of instruction memory and 226 bytes of data (less than 50% of the 512 bytes available)  Only processor_init, TinyOS scheduler, and C runtime are required

56. 56 Evaluation: Timing OperationsCost (cycles) Time (µs) Normalized to byte copy Byte copy821 Post an Event Call a Command Post a task to scheduler Context switch overhead 10 46 51 2.5 11.5 12.75 1.25 6 Interrupt (hardware cost)92.251 Interrupt (software cost)7117.759

57. Summary: TinyOS r Components m provide commands and require callback hooks for event-driven programming r Configurations m Link components r TinyOS m an app (configuration) at a time, linking only necessary components r Two threads exec m one for event m one for task 57 ADC.nc interface ADC { async command result_t getdata(); async command result_t getContinuousData(); event result_t dataReady(uint 16_t data); } configuration SenseTask { // this module does not provide any interfaces } implementation { components Main, SenseTaskM, LedsC, TimerC, DemoSensorC as Sensor; Main.StdControl -> TimerC; Main.StdControl -> Sensor; Main.StdControl -> SenseTaskM; SenseTaskM.Timer -> TimerC.Timer[unique("Timer")]; SenseTaskM.ADC -> Sensor; SenseTaskM.Leds -> LedsC; }

58. Discussion: Compare TinyOS/GNURadio r What are some similar software concepts? r What are some differences? 58

59. Discussion r Can we use GNURadio/TinyOS for writing mobile applications for mobile phones, or in other words, what are missing? 59

60. 60 Java2 Micro Edition (J2ME)

61. 61 Outline r Admin and recap r Mobile/wireless development framework m GNURadio m TinyOS m J2ME

62. 62 Java Platforms r Java2 is divided into three platforms m J2EE (Java2 Enterprise Edition) business applications m J2SE (Java2 Standard Edition) general applications m J2ME (Java2 Micro Edition) small devices such as mobile phone, PDA, car navigation r Oracle’s claims on Java on mobile devices m http://www.java.com/en/about/

63. 63 J2ME Basic Concepts: Versioning r To accommodate heterogeneous mobile devices, define configurations and profiles http://developers.sun.com/techtopics/mobility/getstart/articles/survey/ -A configuration provides fundamental services for a broad category of devices (e.g., lang, io, util) - A profile supports higher-level services common to a more specific class of devices or market (e.g., life cycle, GUI) -An optional package adds specialized services that are useful on devices of many kinds, but not necessary on all of them

64. 64 J2ME 128-512K mem 16-32 bit proc Upto 2M mem 32 bit proc

65. 65 Example J2ME Configurations r Connected Limited Device Configuration (CLDC) m 160 KB to 512 KB of total memory available m 16-bit or 32-bit processor m low power consumption and often operating with battery power m connectivity with limited bandwidth m examples: cell phones, certain PDAs r Connected Device Configuration (CDC) m 2 MB or more memory for Java platform m 32-bit processor m high bandwidth network connection, most often using TCP/IP m examples: set-top boxes, certain PDAs

66. 66 CLDC Available Packages r java.lang r java.util r java.io r javax.microedition.io

67. 67 CLDC Classes r Boolean r Byte r Character r Class r Integer r Long r Math r Object r Runnable r Runtime r Short r String r StringBuffer r System r Thread r Throwable r Calendar r Date r Enumeration r Hashtable r Random r Stack r TimeZone r Vector r ByteArrayOutputStream r ByteArrayInputStream r DataOuput r DataInput r DataInputStream r DataOutputStream r InputStream r InputStreamReader r OutputStream r OutputStreamWriter r PrintStream r Reader r Writer java.lang java.util java.io

68. 68 Example J2ME Profiles r Mobile Information Device Profile (MIDP) m GUI, multimedia and game functionality, end-to-end security, and greater networked connectivity m mobile phones and entry level PDAs r Foundation Profile m set of Java APIs that support resource-constrained devices without a standards-based GUI system r Personal Profile m Full set of AWT APIs, including support for applets and Xlets m CDC + Foundation Profile + Personal Profile for high-end PDA r …

69. 69 Mobile Phone Framework

70. 70 MIDP Hardware r Memory (added to CLDC memory) m 128 KB non-volatile for MIDP components m 8 KB non-volatile for application persistent data m 32 KB volatile for KVM r Display m screen 96x54 m display depth 1-bit m pixel shape (aspect ratio) 1:1

71. 71 MIDP Hardware r Input (one or more) m one-handed keyboard (ITU-T phone keypad) m two-handed keyboard (QWERTY keyboard) m or touch screen r Networking m two-way m wireless m possibly intermittent m limited bandwidth

72. 72 MIDP Packages r java.io r java.lang r java.util r javax.microedition.io r javax.microedition.lcdui r javax.microedition.rms r javax.microedition.midlet r javax.microedition.lcdui.game r javax.microedition.media r javax.microedition.media.control r javax.microedition.pki addition in version 2.0 version 1.0

73. 73 MIDP Technology Stack Mobile Information Device Profile KVM CLDC = KVM + J2ME Core APIs in this example DSP chip (e.g., ARM) J2ME core APIs Your MIDlet Yellow Pages, train schedules and ticketing, games… UI, HTTP networking... Threads, no Floats… 32-bit RISC, 256K ROM, 256K Flash, 64K RAM

74. MIDlet m GUI based m Each MIDP has one instance of Display Display.getDisplay(this) to get the manager At any instance of time at most one Displayable object can be shown on the display device and interact with user –display.setCurrent( ) 74

75. 75 MIDlet r An MIDP application is called a MIDlet m similar to the J2SE applet r A MIDlet moves from state to state in the lifecycle, as indicated m start – acquire resources and start executing m pause – release resources and become quiescent (wait) m destroy – release all resources, destroy threads, and end all activity PauseActiveDestroyed startApp destroyApp pauseApp destroyApp

76. MIDP Visual Display r Each MIDP has one instance of Display  Display.getDisplay(this) to get the manager  At any instance of time at most one Displayable object can be shown on the display device and interact with user display.setCurrent( ) 76

77. MIDP Visual Display r Displayable m Canvas GameCanvas m Screen Alert, List, TextBox, Form r Form can contain multiple form items for organization m Labels, Image Items, String Items, Text Fields, Date Fields, Gauges, Choice Groups 77

78. MIDP: User Interaction  Displayable objects can declare commands and declare a command listener: m addCommand(Command cmd) m addCommandListener() r Command(,, ) m Type: BACK, CANCEL, EXIT, HELP, ITEM, OK, SCREEN, and STOP 78

79. 79 HelloWorldMIDlet.java import javax.microedition.midlet.*; import javax.microedition.lcdui.*; public class HelloWorldMIDlet extends MIDlet implements CommandListener { private Command exitCommand; private Display display; private TextBox t; public HelloWorldMIDlet() { display = Display.getDisplay(this); exitCommand = new Command("Exit", Command.EXIT, 2); t = new TextBox(“CS434", "Hello World!", 256, 0); t.addCommand(exitCommand); t.setCommandListener(this); } public void startApp() { display.setCurrent(t); } public void pauseApp() { } public void destroyApp(boolean unconditional) { } public void commandAction(Command c, Displayable s) { if (c == exitCommand) { destroyApp(false); notifyDestroyed(); }

80. MIDP: Persistent State r Record store defined in javax.microedition.rms r Record store identified by name: m static String[] listRecordStores(); m recordStore = RecordStore.openRecordStore("scores", true); m recordId = addRecord(byte[] data, int offset, int numBytes); m getRecord(int recordId); 80

81. 81 Summary : J2ME r Scale down a popular programming environment to ease learning r Use virtual machines to mask device heterogeneity r Use configuration/profiling to handle device heterogeneity and avoid using lowest common denominator r MIDLet to manage app life cycle r Displayable to visual display, commands and provides command listener r Introduce persistent record store

82. 82 Windows.NET Compact Framework r Similar to J2ME r Scales down a popular programming environment to ease learning m the.NET CF is a subset of the full.NET framework with some additions m designed for resource constrained devices m 1,400 classes for.NET CF vs. 8,000 for full m 27 UI controls for.NET CF vs. 52 for full m 1.5 MB for.NET CF vs. 30 MB for full r Uses versioning to avoid using lowest common denominator m pocket PC m pocket PC phone version m smart phone version r Uses virtual machines to mask device heterogeneity m programming languages compile to MSIL MSIL is JIT compiled on the device MSIL code is smaller than native executables MSIL allows your code to be processor independent

83. Andriod 83 http://developer.android.com/index.html

84. Android Features r Linux kernel as foundation r Java based framework (J2SE not J2ME) m Dalvik Virtual machine r Nice features m Touch screen, accelerometer, compass, microphone, camera, GPS, m GSM, EDGE, and 3G networks, WiFi, Bluetooth, Near field communications m Media, SQLite, WebKit, SSL m Location-based service, map (Google API) 84

85. Andriod 85

86. Activity r A single, focused thing that the user can do. r Interaction with users: creating a window to place UI views r full-screen windows, floating windows, embedded inside of another activity

87. r Android Activity Life cycle 87

88. View r A view component is a building block for user interface components. r Widget Toolbox m TextView, EditText, Button, Form, TimePicker… m ListView m Layout Positions of controls LinearLayout, Relativelayout http://developer.android.com/guide/tutorials/views/index.htm

89. Rake Receiver 89

90. 90 Multipath Diversity: Rake Receiver r Instead of considering delay spread as an issue, use multipath signals to recover the original signal r Used in IS-95 CDMA, 3G CDMA, and 802.11 r Invented by Price and Green in 1958 m R. Price and P. E. Green, "A communication technique for multipath channels," Proc. of the IRE, pp. 555--570, 1958

91. 91 Multipath Diversity: Rake Receiver r Use several "sub-receivers" each delayed slightly to tune in to the individual multipath components r Each component is decoded independently, but at a later stage combined m this could very well result in higher SNR in a multipath environment than in a "clean" environment LOS pulse multipath pulses

92. 92 Rake Receiver Blocks Correlator Finger 1 Finger 2 Finger 3 Combiner

93. 93 Rake Receiver: Matched Filter r Impulse response measurement r Tracks and monitors peaks with a measurement rate depending on speeds of mobile station and on propagation environment r Allocate fingers: largest peaks to RAKE fingers

94. 94 Rake Receiver: Combiner r The weighting coefficients are based on the power or the SNR from each correlator output r If the power or SNR is small out of a particular finger, it will be assigned a smaller weight:

95. 95 Discussion r What are major considerations in designing a software environment for mobile wireless applications for mobile devices?

96. 96 Mobile Programming Requirements m Handle heterogeneous devices/configurations m Be extremely efficiency on using resources (memory, battery, …) m Easy programming for event-driven programming m …

97. 97 Comparison [PAH95] MCM is OFDM