MobileEmbedded Devices and Development Tools

1
Mobile/Embedded Devices and Development Tools

• Mobile/Embedded Devices
• Introduction to WAP Principles
• WAE, WTA and Push Services
• Mica Motes and Program Components in TinyOS
• Identify the characteristics and capabilities of
  the tools for development of pervasive computing
  systems

2
Mobile/Embedded Devices

• Examples (input/display devices, unique ID,
  environment monitoring and entertainment/living)
• PDA (Personal Digital Assistant)
• Pocket PC and tablet PC
• Laptops notebooks
• Smart phones
• Sensors, smart cards and smart IDs
• Electronic devices and appliances (i.e., camera,
  MP3, etc.)
• Mobile/Embedded devices
• Large in number small in size
• High variation in processing capability and
  interface, i.e., display screen sizes
• May be diskless and limited in memory sizes
• Wireless/fixed connection to networks, i.e. using
  infra red or radio signals

3
Mobile/Embedded Devices

• Need to know the limitations of the devices. Why?
• How do they affect the processing
  (cost/performance) of user requests (queries)?
• Consider two simple applications (1) someone has
  submitted a continuous queries to monitor the
  highest temperature of the class rooms. (2) a
  real-time news reporting system for car drivers
• What are the differences between the two
  applications?
• Updates/news reports are generated continuously
  from sensors/agents
• Update generation period? Processing cost, memory
  cost, energy cost and network transmission cost
• Any data aggregation? Where to put the database?
  Any caching/pre-caching? How to maintain the
  cached data?
• Where to complete the computation? Distributed
  Vs. centralized or hierarchical (remember
  minimizing network workload is always a big
  concern)
• Real-time responses Vs. doze mode of operation to
  conserve energy
• What is the biggest factor affecting the rate of
  energy consumption?
• Adaptation I.e. Any trans-coding of the content
  before transmission/displaying them in the client
  devices

4
Mobile/Embedded Devices

• Limited in energy supply (i.e. run on
  AA/Ni-Cd/Li-Ion batteries)
• Energy conservation is always a big concern in
  operation
• Transmit/receive, disk spinning, display, CPUs,
  connection
• Need energy efficient hardware (CPUs and memory)
  and system software
• Planned disconnection doze mode of operation
• Resource constraints
• Mobile computers are resource poor (computing
  power, memory and energy)
• Reduce program size interpret script languages
  (mobile Java?)
• Computation and communication load cannot be
  distributed equally
• It may be an advantage to download some
  computations from the mobile devices to a
  stationary server
• How to divide the tasks into sub-tasks for
  execution at the mobile devices and powerful
  servers? Where to perform validation
• When to load data and programs into a mobile
  device for execution?
• Small screen sizes and resolution (reformatting
  of data before display)

5
Mobile Terminals

• PocketPC? Palm? Smart Phones? What are the
  differences?
• General purposes Vs. specific purposes
• Symbian OS is a platform for wireless devices
  developed by Symbian consortium for 2G, 2.5G and
  3G data enabled mobile phones/PDA
• It is an operating systems
• Multi-tasking kernel
• Device drivers and libraries
• Supports low level communication and messaging
  protocols
• Supports applications developed in C, Java,
  J2ME
• Supports communication protocols the internet
  protocols TCP/IP protocols, UDP, HTTP, WAP stack
• Connection through Bluetooth and infrared
• Works on top of different types of 2G, 2.G and 3G
  networks
• It seems very powerful. Any problems, i.e.,
  stability and performance?

www.symbian.com
6
Symbian OS framework www.symbian.com
7
Wireless Application Protocol (WAP)

• Why WAP?
• Limitations and variability of mobile devices and
  networks
• Internet protocols are not designed to operate
  efficiently over mobile networks (why?)
• Mobile network (cellular network) initially was
  designed for voice communication
• Compare the traffic characteristics and
  requirements for voice and data communications
• Bursty and resilience to noises and errors
• Poor data communication bandwidth of 2G networks
• How to support data services in GSM/2G?
• Standard HTML web content cannot be displayed
  fully on the small-size screen of mobile devices
• Various proprietary standards and techniques for
  supporting mobile internet applications and
  communications
• Need an integration and interoperable solution

8
WAP - Wireless Application Protocol

• Goals
• Deliver Internet contents and enhanced data
  services to mobile devices (mobile phones, PDAs,
  etc.)
• Independence from wireless network standards
• Open for everyone to participate, protocol
  specifications will be proposed to
  standardization bodies
• Applications should scale well beyond current
  transport media and device types and should also
  be applicable to future developments
• Platforms
• e.g., GSM (900, 1800, 1900), CDMA IS-95, TDMA
  IS-136, 3rd generation systems (IMT-2000, UMTS,
  W-CDMA, cdma2000 1x, )
• Forum
• was WAP Forum, co-founded by Ericsson, Motorola,
  Nokia, Unwired Planet, further information
  www.wapforum.org
• now Open Mobile Alliance www.openmobilealliance.o
  rg (Open Mobile Architecture WAP Forum
  SyncML )
• How does WAP achieve its goals?

9
Fr. Schiller
10
WAP - Network Elements
wireless network
fixed network
Internet
WAP proxy
Binary WML
WML
filter
HTML
WML
HTML
HTML
filter/ WAP proxy
Binary WML
web server
HTML
WTA server
Binary WML
PSTN
Binary WML binary file format for clients
From Mobile Communications, Schiller
11
WAP Proxy/Gateway

• To enhance and optimize the connection between
  mobile devices and content provider, a WAP proxy
  is defined in the architecture
• WAP proxy provides
• Protocol gateway translates requests from a
  wireless (WAP) protocol stack to www protocols.
  WAP proxy intercepts and interprets mobile device
  requests (encoded) and then forwards the requests
  via HTTP to the appropriate network
• Content encoder and decoders translates WAP
  contents into a compact format for better
  transmission and display. When the proxy receives
  information from the network, the information is
  stored and converted (formatted) to a suitable
  form for processing and display by the mobile
  device
• User agent profile management User agent
  profiles describes client capabilities and
  personal preferences are composed and presented
  to applications
• Caching proxy improve performance and network
  utilization by maintaining a cache of frequently
  accessed resources

12
WAP - Scope of Standardization

• Browser
• micro browser, similar to existing, well-known
  browsers in the Internet, for resource limited
  devices
• Script language (WMLScript)
• similar to Java script, adapted to the mobile
  environment
• WTA/WTAI (Wireless Telephony Application
  Interface)
• Wireless Telephony Application (Interface)
  access to all telephone functions
• Integration of data and voice services
• Content formats
• e.g., business cards (vCard), calendar events
  (vCalender)
• Protocol layers
• Transport layer, security layer, session layer
  etc.
• Modifications of the protocols to meet the
  constraints of the networks and devices. What are
  they?

13
WAP 1.x - reference model and protocols
Internet
WAP
A-SAP
Application Layer (WAE)
HTML, Java
additional services and applications
S-SAP
Session Layer (WSP)
HTTP
TR-SAP
Transaction Layer (WTP)
SEC-SAP
Security Layer (WTLS)
SSL/TLS
T-SAP
Transport Layer (WDP)
TCP/IP, UDP/IP, media
WCMP
Bearers (GSM, CDPD, ...)
WAE comprises WML (Wireless Markup Language), WML
Script, WTAI etc.
From Mobile Communications, Schiller
14
Web vs. WAP
15
WAE - Wireless Application Environment

• Goals
• To create a general-purpose environment to
  integrate voice and data services over mobile
  networks
• Integrated Internet/WWW programming models with
  high interoperability
• Considerations of slow links, limited memory, low
  computing power, small display, simple user
  interface (compared to desktop computers
• Components
• WAE user-agent WAE is a micro-browser
  environment containing or allowing for markup,
  scripting, style-sheet languages, and telephony
  services and programming interfaces optimized for
  use in hand-held mobile terminals

16
WAE - Wireless Application Environment

• WTA user-agent telephone services, such as call
  control, text messages, phone book, ...
  (accessible from WML/WMLScript)
• Push The Push service provides a general
  mechanism for the network to initiate the
  transmission of data to applications resident on
  WAP devices
• Gateway, servers, filters
• WML XML-Syntax, based on card stacks, variables,
  ...
• WMLScript procedural, loops, conditions, ...
  (similar to JavaScript)
• Multimedia messaging MMS provides for transfer
  and processing of multimedia messages
• Content formats vCard, vCalendar, Wireless
  Bitmap, images, audio, video, animation, ...

17
WAE logical model
Origin Servers
Proxy/Gateway/filter
Client
WTA user agent
web server
encoded response with content
response with content
encoders decoders
WML user agent
other content server
push content
encoded push content
WAE user agents
encoded request
request
Fr. Schiller
18
Wireless Telephony Application (WTA)

• Browsing the web is only one of the applications.
  How about other services including voice
  communication. How to integrate them?
• Collection of telephony specific extensions for
  call and feature control mechanisms, merging data
  networks, and voice networks
• Extension of basic WAE application model
• Content push
• Server can push content to the client
• Client may now be able to handle unknown events
• Handling of network events
• Repository for storing channels (a reference to
  resource) and resources (WML decks)
• Within its lifetime, all resources the channel
  points to are locally available (how?)
• Access to telephony functions
• Any application on the client may access
  telephony functions through the functions
  provided in WTAI library
• Example
• calling a number (WML)wtai//wp/mc07216086415

19
WTA/WAE User-Agents and WTA Server

• WTA user-agent retrieves content from the
  repository (storage module) and WTAI to interact
  with mobile network functions (i.e., call setup
  and manipulate phonebook) and network events
• Note accessing to the repository is quick. Thus,
  it can eliminate the need for network access and
  provide timely responses
• WTA server is similar to a web server delivering
  requested by a mobile terminal by related to
  telephony applications to interact with mobile
  networks and other entities, i.e., voice mail
  systems
• Referring to WTA server can be done by URL

20
http//www.openmobilealliance.org/tech/affiliates/
wap/wapindex.html
21
Voice box example
WTA-User-Agent
WTA-Server
Mobile network
Voice box server
WTA-Gateway
Indicate new voice message
Someone leaves a message in the voice box server
Generate new deck
Push URL
Service Indication
The URL pointing to the details of the voice calls
Display deck user selects
WSP Get
HTTP Get
Respond with content
WML
Binary WML
Display deck user selects
WSP Get
HTTP Get
Respond with card for call
WML
Binary WML
Play requested voice message
Wait for call
Call setup
Setup call
Setup call
Accept call
Accept call
Accept call
Voice connection
From Mobile Communications, Schiller
22
(No Transcript)
23
(No Transcript)
24
WAP Push Architecture with Proxy Gateway

• PPG
• Check client address in the mobile network, may
  broadcast to a group
• Push Access Protocol
• Content transmission between server and PPG
• First version uses HTTP (POST), result
  notification to PI
• Push OTA (Over The Air) Protocol
• Mapped onto WSP
• Connection or connectionless

25
Push/Pull services

• Service Indication
• Service announcement using a pushed short message
• Service usage via a pull
• Service identification via a URL
• Service Loading
• Short message pushed to a client containing a URL
• User agent decides whether to use the URL via a
  pull
• Transparent for users, always looks like a push

26
WAP Future

• The current version of WAP 2.0
• How does WAP achieve its goals?
• Presentation and reformatting meets the
  limitations of the devices
• Redesign of communication protocols to adapt to
  the changing network environment and device
  limitations/capability
• Provide both datagram and connection services
• Negotiation in session establishment
• What will be the future of WAP?
• Mobile device
• More powerful processors
• The display screen is larger with higher
  resolution
• Better interface for user input and browsing
• The data transmission capability of mobile
  network is improving, i.e. in 3G and GPRS

27
Sensor Nodes and TinyOS Programming

• A sensor node consists of two main components
• Sensing unit
• Light, sound, velocity, temperature, etc
• Processing unit
• Usually has with limited processing power, energy
  supply, communication and memory capability
• Operating system (TinyOS) application programs
  (in nesC)
• Example sensor nodes Mica Motes developed in UC
  Berkeley and manufactured by www.xbow.com
• Characteristics and requirements
• Very small in size and cheap, and can be deployed
  in large number
• Energy saving and can operation for a long period
  of time non-stop (periodically switch to doze
  mode of operation to conserve energy)
• Continuous monitoring of the surrounding
  environment
• Continuous generation of sensor data (stream
  data)
• Automatically form a wireless sensor network
  (WSN) with other nodes (communication range from
  a few m to km with an antenna)
• Robust and reliable (can work in harsh
  environment)

28
MOTES

• Two Board Sandwich
• CPU/Radio board
• Sensor Board temperature, light
• Size
• Mote 1?1 in
• Pocket PC 5.2?3.1 in
• CPU
• Mote 4 MHz, 8 bit
• Pocket PC 133 MHz, 32 bit
• Memory
• Mote 512 B RAM 8K ROM
• Pocket PC 32 MB RAM 16 MB ROM
• Radio
• 900 Hz, 19.2 kbps
• Bluetooth 433.8 kbps (symmetric)

• Lifetime (Power)
• Mote 3-65 days
• Pocket PC 8 hrs
• Cost
• Mote 100 (expected to drop dramatically in the
  future)
• Pocket PC 400

• http//www.xbow.com/Products/Product_pdf_files/Wir
  eless_pdf/MICA.pdf

29
Mote Evaluation
Services
Networking
TinyOS
Commercial Off The Shelf Components (COTS)
30
Mote Operations

• Periodic
• Sleep majority of the time
• Wakeup quickly start processing
• Active minimize work return to sleep
• Triggered Events
• Detection/Notification
• Infrequently occurs
• But must be reported quickly and reliably
• Long Lifetime
• Months to years without changing batteries
• Power management is the key to WSN success
• Sleep isolating and shutting down individual
  circuits
• Using low power hardware

processing data acquisition communication
Power
wakeup
sleep
Time
31
Mote Applications

• Example application areas
• Object tracking and intrusion detection
• Environment and habitat monitoring
• Basic components
• A number of sensor nodes
• Base stations
• Gateway/Server
• Networks
• Fixed/wireless network connecting the base
  stations to the server/gateway
• Wireless sensor network connecting the sensor
  nodes to the base stations
• Base stations are mainly for pre-processing and
  data aggregation
• Server/gateway maintains a repository/DB for
  generating event alter/results to the users
• http//www.xbow.com/Products/Product_pdf_files/Wir
  eless_pdf/MSP410_Datasheet.pdf

32
Programming in Mica Motes

• TinyOS is the operating system designed
  specifically for sensor devices
• TinyOS (TOS) is a small, open-source operating
  system for wireless sensor developed by UC
  Berkeley
• TinyOS includes functions for radio messaging,
  message hopping from mote to mote, low power
  (energy saving) mode of operation and sensor
  measurements and signal processing
• http//webs.cs.berkeley.edu/tos/download.html1.1.
  0
• What are the performance requirements of a sensor
  control system?

33
Software challenges of Building Applications in
Sensor Nodes

• Power efficient
• Efficient modularity
• Small memory and Application specific
• Concurrency-intensive operations
• Multiple, high-rate data flows (radio, sensor,
  actuator)
• Concurrent events processing, receive input and
  communication
• TinyOS must process bit every 100 µs
• Real-time responses
• Real-time query and feedback control of physical
  world (monitoring and surveillance purposes)
• Little memory for buffering data must be
  processed on the fly
• TinyOS No buffering, missed deadline ? lost data
• But, TinyOS provides NO real-time guarantees
  (completion before a deadline). Why? How to
  provide real-time responses?

34
TinyOS Overview

• Application scheduler components
• Compiled into one executable
• Event-driven architecture
• Single shared stack
• No kernel/user space differentiation

Main (includes Scheduler)
Application (User Components)
Actuating
Sensing
Communication
Communication
Hardware Abstractions
35
nesC Programming in Mica Mote

• TinyOS system, libraries and applications are
  developed in nesC
• nesC is a C-like procedure language and can
  support concurrency models and component based
  applications
• Why concurrency model?
• Concurrency model tasks and hardware event
  handlers
• Components
• A nesC application consists of one or more
  components linked to form an executable
• A component provides and uses interfaces from
  other components
• A component can be accessed only through a
  bidirectional interface
• An interface declares a set of functions called
  commands implemented by the interface provider
  and a set of events implemented by the interface
  user

36
Components and Concurrency Model

• Two types of components modules and
  configurations
• A module provides application code, implementing
  one or more interfaces
• Configurations are used to assemble other
  components together, connecting interfaces used
  by components to interfaces provided by others
  (wiring)
• Every nesC application is described by a
  top-level configuration that wires together the
  components inside
• TinyOS executes one program consisting of
  selected system components and custom components
  needed for an application
• Two threads of execution tasks and hardware
  event handlers
• Tasks are functions whose execution can be
  deferred and once scheduled will run to
  completion. However, it may be preempted by
  events
• Hardware event handlers are executed in response
  to a hardware interrupts. It may preempt the
  execution of a task or other events

37
Life Cycle of a Sensor Program

• Main is a component that is executed first in a
  TinyOS application
• All the sensor programs need to connect with Main
  Program
• init() can be called multiple times, but will
  never be called after either start() or stop are
  called
• It is an event driven model. You need to specify
  what to do when an event arrives

Main.StdControl.init()
Main.StdControl.start()
Main.StdControl.stop()
38
Example Blink

• Blink causes the red LED on the mote to turn on
  and off at 1Hz
• Blink application is composed of two components
  a module, called BlinkM.nc and a configuration
  called Blink.nc
• Blink.nc configuration Blink implementation
    components Main, BlinkM, SingleTimer,
  LedsC  Main.StdControl -gt BlinkM.StdControl 
  Main.StdControl -gt SingleTimer.StdControl 
  BlinkM.Timer -gt SingleTimer.Timer  BlinkM.Leds
  -gt LedsC

User
Connect the Blink Program to Main program
Provider
39
(No Transcript)
40
Example Blink

• BlinkM.nc module BlinkM   provides    
  interface StdControl    uses     interface
  Timer    interface Leds  // Continued
  below...

Used by Main
Blink Program uses the component Timer and Leds
41

• implementation command result_t
  StdControl.init()     call Leds.init()   
  return SUCCESS    command result_t
  StdControl.start()     return call
  Timer.start(TIMER_REPEAT, 1000)     command
  result_t StdControl.stop()     return call
  Timer.stop()  event result_t
  Timer.fired()      call Leds.redToggle()   
  return SUCCESS 

Executed by Main program, as it is connected with
Main.stdControl.init() Main.stdControl.start() Mai
n.stdControl.stop()

Handle the event Timer.fried() i.e. to blink the
red led
42

• 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()

43
The Future of Sensors

• Further smaller in size
• Larger in number
• Cheaper in price
• Fixed and mobile
• Greater in capability
• Better connectivity
• More tools for development and debugging
• Better real-time supports and scheduling
• BUT, energy is still a concern

44
References

• WAP Mobile Communications, 10.3.1, 10.3.6,
  10.3.9, 10.3.10
• J2ME Learning Wireless Java, OReilly
• Sensors
• www.xbow.com
• www.tinyos.net
• http//www.tinyos.net/tinyos-1.x/doc/tutorial/less
  on1.html
• http//www.xbow.com/Products/Product_pdf_files/Wir
  eless_pdf/MICA.pdf