mobiquitous keynote

Category: Education

Presentation Description

No description available.


By: rs_rajesh1 (138 month(s) ago)

This presentation is excellent. I want a copy of it. Pl send a copy to me

Presentation Transcript

The Vision and Reality of Ubiquitous Computing: 

The Vision and Reality of Ubiquitous Computing Prof. Henning Schulzrinne Dept. of Computer Science Columbia University (with Arezu Moghadam, Ron Shacham, Suman Srinivasan, Xiaotao Wu and other IRT members; parts in cooperation with DoCoMo Eurolabs)


Overview The original vision of ubiquitous computing User challenges Beyond terminal mobility Location as new core service Universality: 7DS

Ubiquitous computing  ubiquitous communications: 

Ubiquitous computing  ubiquitous communications “It is invisible, everywhere computing that does not live on a personal device of any sort, but is in the woodwork everywhere.” Weiser’s original vision (“Nomadic Issues in Ubiquitous Computing”, 1996) “one person, many computers” many computers embedded in environment dynamic ownership PC phonebooth “IR use will grow rapidly” Updated version, 2007 not physically invisible, but transparent emphasis on communications, not computing most devices are mobile (or nomadic) cheap electronics personal devices radio (channelized and UWB)


Overview The original vision of ubiquitous computing User challenges Beyond terminal mobility Location as new core service Universality: 7DS

User challenges vs. research challenges: 

User challenges vs. research challenges Are we addressing real user needs? Engineering vs. sports My guesses reliability ease of use cost no manual integration limited risk phishing data loss no re-entry no duplication

Example: Email configuration: 

Example: Email configuration Application configuration for (mobile) devices painful SMTP port 25 vs. 587 IMAP vs. POP TLS vs. SSL vs. “secure authentication” Worse for SIP...

Example: SIP configuration: 

Example: SIP configuration highly technical parameters, with differing names inconsistent conventions for user and realm made worse by limited end systems (configure by multi-tap) usually fails with some cryptic error message and no indication which parameter out-of-box experience not good partially explains

Mobile why’s : 

Mobile why’s Not research, but examples of real annoyances Why does each mobile device need its own power supply? Why do I have to adjust the clock on my camera each time I travel? Why do I have to know what my IMAP server is and whether it uses TLS or SSL? Why do I have to type in my address book? Why do I have to “synchronize” my PDA? Why do I have to manually update software? Why is connecting a laptop to a projector a gamble? Why do we use USB memory sticks when all laptops have 802.11b?

Consumer wireless & mobile devices: 

Consumer wireless & mobile devices MSN Direct weather Prius key Garage door opener TAN display Water leak alarm wireless door bell

Mobile systems - reality: 

Mobile systems - reality idea: special purpose (phone) --> universal communicator idea is easy... mobile equipment: laptop + phone sufficiently different UI and capabilities we all know the ideal (converged) cell phone difficulty is not technology, but integration and programmability (almost) each phone has a different flavor of OS doesn’t implement all functionality in Java APIs no dominant vendor (see UNIX/Linux vs. Microsoft) external interfaces crippled or unavailable e.g., phone book access GPS location data

Example: displays and speakers: 

Example: displays and speakers

Philosophy transition: 

Philosophy transition One computer/phone, many users One computer/phone, one user Many computers/phones, one user anywhere, any time any media right place (device), right time, right media ~ ubiquitous computing mainframe era home phone party line PC era cell phone era

The mobile ubiquitous challenge: 

The mobile ubiquitous challenge Mobile phone Mobile Internet access Interconnected devices “Internet of things”

What do we need?: 

What do we need? Standards, not new technology Radio connectivity 802.11a/b/g/n, 802.15.4  better discovery of networks Location information everywhere Discovery: devices & services network-local discovery via Bonjour (mDNS)  missing: location-based discovery Advanced mobility: session, personal, service Event notification Data formats location, sensor events, ...

Examples of “invisible” behavior: 

Examples of “invisible” behavior MP3 player in car automatically picks up new files in home server A new email with vcard attachment automatically updates my cell phone address book The display of my laptop appears on the local projector without cable or configuration I can call people I just met at Mobiquitous without exchanging business cards My car key opens my front door My cell phone serves as a TAN (one-time password) generator My cell phone automatically turns itself off during a lecture My camera knows where the picture was taken

An interconnected system: 

An interconnected system any weather service school closings opens doors incoming call generates TAN acoustic alerts updates location time, location alert, events address book

Thinking beyond 802.11 and UMTS: 

Thinking beyond 802.11 and UMTS Many interesting networks beyond those covered in conferences ease of access by researchers vs. importance 90% of papers on 802.11b and maybe GPRS, BlueTooth New wireless networks broadcast instead of unicast -- useful for many ubiquitous applications S5 for low-rate sensors (city scale) Zigbee (802.15.4) for local sensors (20 - 250 kb/s) FM subcarrier (not really new) -- MSN Direct FM Radio Data System -- TMC Sirius / XM HD radio paging


Overview The original vision of ubiquitous computing User challenges Beyond terminal mobility Location as new core service Universality: 7DS

Application-layer mobility: 

Application-layer mobility terminal mobility one terminal, multiple network addresses Personal mobility one person, multiple terminals e.g., Grandcentral session mobility one user, multiple terminals in sequence or in parallel service mobility services move with user

Session mobility: 

Session mobility Walk into office, switch from cell phone to desk phone call transfer problem  SIP REFER related problem: split session across end devices e.g., wall display + desk phone + PC for collaborative application assume devices (or stand-ins) are SIP-enabled third-party call control R. Shacham, H. Schulzrinne, S. Thakolsri, W. Kellerer, “Ubiquitous device personalization and use: The next generation of IP multimedia communications”, ACM TOMCCAP, May 2007

How to find services?: 

How to find services? Two complementary developments: smaller devices carried on user instead of stationary devices devices that can be time-shared large plasma displays projector hi-res cameras echo-canceling speaker systems wide-area network access Need to discover services in local environment SLP (Service Location Protocol) allows querying for services “find all color displays with at least XGA resolution” slp:// SLP in multicast mode SLP in DA mode Apple Bonjour Need to discover services before getting to environment “is there a camera in the meeting room?” SLP extension: find remote DA via DNS SRV LoST to find services by geographic location

Session mobility: 

Internet Correspondent Node (CN) SIP UA SLP UA SIP SM Local Devices SLP SA SLP UA SIP SM SIP UA SLP DA Mobile Node (MN) SLP SIP RTP SIP UA Transcoder Session mobility


Overview The original vision of ubiquitous computing User challenges Beyond terminal mobility Location as new core service Universality: 7DS

Context-aware communication: 

Context-aware communication context = “the interrelated conditions in which something exists or occurs” anything known about the participants in the (potential) communication relationship both at caller and callee

GEOPRIV and SIMPLE architectures: 

GEOPRIV and SIMPLE architectures target location server location recipient rule maker presentity caller presence agent watcher callee GEOPRIV SIP presence SIP call PUBLISH NOTIFY SUBSCRIBE INVITE publication interface notification interface XCAP (rules) INVITE DHCP

Presence data architecture: 

Presence data architecture raw presence document create view (compose) privacy filtering draft-ietf-simple-presence-data-model composition policy privacy policy presence sources XCAP XCAP (not defined yet) depends on watcher select best source resolve contradictions PUBLISH

Presence data architecture: 

Presence data architecture candidate presence document watcher filter raw presence document post-processing composition (merging) final presence document difference to previous notification SUBSCRIBE NOTIFY remove data not of interest watcher

Presence data model: 

Presence data model “calendar” “cell” “manual” audio, video, text video person (presentity) (views) services devices

RPID = rich presence: 

RPID = rich presence Provide watchers with better information about the what, where, how of presentities facilitate appropriate communications: “wait until end of meeting” “use text messaging instead of phone call” “make quick call before flight takes off” designed to be derivable from calendar information or provided by sensors in the environment allow filtering by “sphere” – the parts of our life don’t show recreation details to colleagues

Rich presence: 

Rich presence More information: for (authorized) people and applications automatically derived from sensors: physical presence, movement electronic activity: calendars Rich information: multiple contacts per presentity device (cell, PDA, phone, …) service (“audio”) activities, current and planned sphere (home vs. work) current user mood surroundings (noise, privacy, vehicle, …) contact information composing (typing, recording audio/video IM, …)

Presence and privacy: 

Presence and privacy All presence data, particularly location, is highly sensitive Basic location object (PIDF-LO) describes distribution (binary) retention duration Policy rules for more detailed access control who can subscribe to my presence who can see what when <tuple id="sg89ae"> <status> <gp:geopriv> <gp:location-info> <gml:location> <gml:Point gml:id="point1“ srsName="epsg:4326"> <gml:coordinates>37:46:30N 122:25:10W </gml:coordinates> </gml:Point> </gml:location> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>no </gp:retransmission-allowed> <gp:retention-expiry>2003-06-23T04:57:29Z </gp:retention-expiry> </gp:usage-rules> </gp:geopriv> </status> <timestamp>2003-06-22T20:57:29Z</timestamp> </tuple>

Events as missing Internet capability: 

Events as missing Internet capability aka PUB/SUB Used across applications, e.g., email and voicemail notification presence replace RSS (= poll!) web service completion emergency alerts (“reverse 9-1-1”) network management home control data synchronization Rich research history but too complex, optimize the wrong thing XMPP and SIP as likely transport candidates


Local Switch Automatic Number Identification Automatic Location Identification Collaboration between local phone providers and local public safety agencies

911 technology failures: 

911 technology failures NY Times (“An S O S for 911 Systems in Age of High-Tech”), 4/6/07: “40% of … counties, most of them rural or small-town …, cannot yet pinpoint the location of the cellphone callers, though the technology to do so has been available for at least five years.” “In … Okmulgee, Okla., last November, 4-year-old Graciella Mathews-Tiger died in a house fire after a 911 operator who lacked the technology to pinpoint the call misheard the address.” Phase II wireless; billions of dollars spent In Mississippi, only 1 of out 5 counties “As it ages, it is cracking, with problems like system overload, understaffing, misrouted calls and bug-ridden databases leading to unanswered calls and dangerous errors.” operator (CAMA) trunks, with 8-digit number delivery MSAG and ALI databases

Location delivery: 

Location delivery DHCP HTTP GPS HELD LLDP-MED wire map

Location, location, location, ...: 

Location, location, location, ... Voice Service Provider (VSP) sees emergency call but does not know caller location ISP/IAP knows user location but does not handle call

Options for location delivery: 

Options for location delivery Wireless GPS S5 wireless (active sensors + triangulation) Skyhook (802.11 in urban areas) HDTV L2: LLDP-MED (standardized version of CDP + location data) periodic per-port broadcast of configuration information L3: DHCP for geospatial (RFC 3825) civic (RFC 4676) L7: proposals for retrievals: HELD, SIP, … for own IP address or by third party (e.g., ISP to infrastructure provider) by IP address by MAC address by identifier (conveyed by DHCP or PPP) HTTP-based

Locating Caller using LLDP-MED: 

Locating Caller using LLDP-MED LLDP-MED stands for: * Link Layer Discovery Protocol “a vendor-neutral Layer 2 protocol that allows a network device to advertise its identity and capabilities on the local network.” Media Endpoint Discovery “an enhancement to the LLDP that allows discovery of other things including location “ “I am LLDP-MED Capable. I can process location information.” “Your location is: 500 W 120TH st. New York NY 10027” * From Wikipedia

Location determination options: 

Location determination options

SIP message for Location Info.: 

INVITE urn:service:sos SIP/2.0 To: urn:service:sos Call-ID: 763782461@ Via: SIP/2.0/TCP;rport Content-Type: multipart/mixed; boundary From: Contact: <sip:eddie@> CSeq: 1 INVITE Content-Length: 1379 ------ =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY= MIME-Version: 1.0 content-Type: application/sdp Content-Transfer-Encoding: 8bit v=0 o=eddie 1127764654 1127764654 IN IP4 s=SIPC Call c=IN IP4 t=0 0 m=audio 10000 RTP/AVP 0 3 m=video 20000 RTP 31 SDP header fields request line ------- =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY= MIME-Version: 1.0 Content-Type: application/pidf+xml Content-Transfer-Encoding: 8bit <?xml version="1.0" encoding="ISO-8859-1"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0" entity=""> <tuple id="28185"> <status> <gp:geopriv> <gp:location-info> <cl:civilAddress> <cl:country>us</cl:country> <cl:A1>ny</cl:A1> <cl:A2>new york</cl:A2> <cl:A3>new york</cl:A3> <cl:A6>amsterdam</cl:A6> <cl:HNO>1214</cl:HNO> </cl:civilAddress> </gp:location-info> <gp:method>Manual</gp:method> </gp:geopriv> </status> <contact priority="0.8">sip:eddie@</contact> <timestamp>2005-09-26T15:57:34-04:00</timestamp> </tuple> </presence> ------- =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY=-- PIDF-LO SIP message for Location Info.



Data formats: location: 

Data formats: location Civic (street) jurisdictional & postal Geo (longitude & latitude) point, polygon, circle, … see GeoRSS for simple example

ECRIT: LoST Functionality: 

ECRIT: LoST Functionality Civic as well as geospatial queries civic address validation Recursive and iterative resolution Fully distributed and hierarchical deployment can be split by any geographic or civic boundary same civic region can span multiple LoST servers <findService xmlns="urn:…:lost1"> <location profile="basic-civic"> <civicAddress> <country>Germany</country> <A1>Bavaria</A1> <A3>Munich</A3> <A6>Neu Perlach</A6> <HNO>96</HNO> </civicAddress> </location> <service>urn:service:sos.police</service> </findService> Indicates errors in civic location data  debugging but provides best-effort resolution Can be used for non-emergency services: directory and information services pizza delivery services, towing companies, …

LoST: Location-to-URL Mapping: 

LoST: Location-to-URL Mapping cluster serves VSP2 NY US NJ US Bergen County NJ US 123 Broad Ave Leonia Bergen County NJ US cluster serving VSP1 replicate root information search referral root nodes Leonia NJ US VSP1 LoST

LoST Architecture: 

LoST Architecture T1 (.us) T2 (.de) T3 (.dk) G G G G G broadcast (gossip) T1: .us T2: .de resolver seeker 313 Westview Leonia, NJ US Leonia, NJ  tree guide

Left to do: event notification: 

Left to do: event notification notify (small) group of users when something of interest happens presence = change of communications state email, voicemail alerts environmental conditions vehicle status emergency alerts kludges HTTP with pending response inverse HTTP --> doesn’t work with NATs Lots of research (e.g., SIENA) IETF efforts starting SIP-based XMPP


Overview The original vision of ubiquitous computing User challenges Beyond terminal mobility Location as new core service Universality: 7DS

Problems with Wide Area Wireless: 

Problems with Wide Area Wireless 802.11 currently hard to deploy across city or large area Problem: How can mobile devices / gadgets get information while on the move? Use local peer-to-peer wireless networks to exchange information Peers can get information they do not have from another peer Solution: 7DS! S. Srinivasan, A. Moghadam, S.G. Hong, H. Schulzrinne, “7DS - Node Cooperation and Information Exchange in Mostly Disconnected Networks”, ICC '07. June 2007.

How 7DS Works: 

How 7DS Works When devices are in the same BSS (Basic service set) of 802.11 ad-hoc network, they discover each other using service discovery of Zeroconf zeroconf

How 7DS Works: 

How 7DS Works Internet If there is no Internet connection, the devices can communicate with each other to exchange information

Web Delivery Model: 

Web Delivery Model 7DS core functionality: Emulation of web content access and e-mail delivery


Design Peer-to-peer network set up using zeroconf Protocol enables devices to communicate with each other without a DHCP server, a DNS server and a Directory server Proxy server serves content Search engine searches for local data MTA store and forward In progress: File synchronization, BBS

Store and Forward: 

Store and Forward Forwarding e-mail in the ad-hoc network Acts as an MTA

Search Engine: 

Search Engine Provides ability to query self for results Searches the cache index using Swish-e library Presents results in any of three formats: HTML, XML and plain text Similar in concept to Google Desktop

Query Multicast Engine: 

Query Multicast Engine Used to actually exchange information among peers Requesting peer broadcasts a query to the network Responding peers reply if they have information Send encoded string with list of matching items Requesting peer retrieves suitable information

File Synchronization: 

File Synchronization SRV : 7ds-fs1.filesync._7ds._udp.local. 7ds-device1.local:2525 TXT : file1.xml TXT : file2.xml SRV : 7ds-fs2.filesync._7ds._udp.local. 7ds-device2.local:2525 TXT : word.doc TXT : presentation.ppt File1.xml File2.xml Word.doc Presentation.ppt “I want Word.doc and presentation.ppt” “I want File1.xml and file2.xml” Word.doc Presentation.ppt File1.xml File2.xml SERVICE ANNOUNCEMENT SERVICE RESOLUTION FILE SYNCHRONIZATION USING RSYNC PROTOCOL


Conclusion Motivate mobile ubiquitous research by user problems From stovepipe mobile & wireless systems to personal and shareable wireless networks Thinking beyond single applications presence event notification 9-1-1 location  time & location as infrastructure Need new models of creating services domain-specific languages, not Java APIs

authorStream Live Help