Department of Computer Science Institute for System Architecture, Chair for Computer Networks

Transcription

1 Department of Computer Science Institute for System Architecture, Chair for Computer Networks Outlook Mobile Communication and Mobile Computing Prof. Dr. Alexander Schill

2 Challenges for Mobile and Ubiquitous Computing Highly heterogeneous and dynamic computing infrastructure Wireless communication technologies Computing devices: smartphones, tablets, wearable devices, sensors, embedded systems, robots Cloud platforms All Integrated into the Internet Challenges Create Internet scale systems Develop highly adaptive systems Capture and use context of computing Efficient development support 2

3 Research topics of CN department Service and Cloud Computing Internet of Services Platforms for Service Marketplaces Software as a Service (SaaS) Platform as a Service (PaaS) Cloud Computing Scalable Internet Services Internet of Things Smart Energy Grid Emulation Pervasive Computing and Collaboration Mobile and Ubiquitous Computing Context-Awareness and Adaptation Location-based Services Software Engineering for Mobile Applications Smart Cities/Smart Mobility Mobile Real-time Collaboration Energy Lab Energy efficient networks Energy efficient protocols Dynamic power management algorithms Computer Aided Network design Diffusion models for wireless networks 3

4 Research topics of CN department Service and Cloud Computing Internet of Services Platforms for Service Marketplaces Software as a Service (SaaS) Platform as a Service (PaaS) Cloud Computing Scalable Internet Services Internet of Things Smart Energy Grid Emulation Pervasive Computing and Collaboration Mobile and Ubiquitous Computing Context-Awareness and Adaptation Location-based Services Software Engineering for Mobile Applications Smart Cities/Smart Mobility Mobile Real-time Collaboration Energy Lab Energy efficient networks Energy efficient protocols Dynamic power management algorithms Computer Aided Network design Diffusion models for wireless networks 4

5 Agenda Auditorium Mobile Classroom Service Smart Mobility Projects Crowdsensing-Infrastructure IoT Platform for 3rd Party Services Role-based Software Infrastructures for Continuous- Context-Sensitive Systems (RoSI) 5

6 Classic University Settings Lecture readings Usually 90-minute classes Large auditorium (up to 1000) Mostly one-way presentation by docent Students as passive receptors of information Impart theoretical knowledge Lack of interactivity Loss of concentrated attention after less than 30 min Fail in building adequate mental models of domain knowledge 6

7 Classic University Settings Exercise tutorials Usually 90-minute classes Small groups (up to 30) Working together at exercise tasks Knowledge consolidation Repetition and practical application of theoretical knowledge Different level of knowledge Not enough time for further discussions and individual support 7

8 Support for self-regulated learning in classical lecture readings Asking for personal interests and goals Learning questions Cognitive prompts Metacognitive prompts Linking additional materials Scripted discussions Instant feedback Auditorium Mobile Classroom Service (AMCS) Lecturers App Folie 16 Students Apps 8

9 AMCS as evaluation tool for lectures Facilitating an immediate and substantial evaluation of the lecture Instant feedback about speed and volume Aggregation of livefeedback Results of learning questions and evalution questions (scale) 9

10 Live Feedback during lecture ProfWatch Getting live feedback via Smartwatch 10

11 Analysis of learning questions and surveys 11

12 Smart Mobility MapBiquitous Location-based services are mature for outdoor GPS positioning Map provider Services available But do not work indoors Ø Separation of outdoor and indoor systems Indoor systems with local scale GPS does not work, specific infrastructure used for location detection Maps for outdoors but no building plans for indoors How to find a route from room INF 3105 in computer science faculty buildingto lecture hall 12

13 Smart Mobility MapBiquitous The App An integrated system for indoor and outdoor location-based services 13

14 Smart Mobility MapBiquitous- Approach Decentralized Client/Server Architecture Based on standard technologies (WFS, GML, WGS84) Ø Everyone could participate 14

15 Smart Mobility MapBiquitous - Ongoing work Positioning combined approach using Smartphone sensors and ibeacons detection of further landmarks Integration of 3rd party content real-time bus and tram information for stops room booking system for meeting rooms sensor information for rooms advertisements based on ibeacons Multi-modal routing decentralized routing for indoor and outdoor 15

16 Smart Mobility BikeNow Supports cyclists to get next crossing s green light Consists of smartphone app and service Service is connected to VAMOS Prediction of next green light periods Calculation of speed suggestion based on current speed and position of biker Traffic lights in Dresden north-south axis 16

17 Smart Mobility BikeNow Ongoing Work Accurate green light prediction Calculation of speed suggestion Inaccurate position and speed information (Map Matching) Delay due to communication, processing and visualisation User interface Safety of bikers Easy to get information o current and suggested speed o Different user groups and preferences Ø Crowdsourcing of traffic information in background 17

18 SmartMobility Cyface Crowdsensing-based surface detection for bicycle lanes 18

19 SmartMobility Cyface Ongoing Work Map matching inaccuracy of GPS: How to map measurement points exacly to the lane? o parallel car and bicycle lanes o crossroads Quality of surface estimation International Roughness Index (IRI) depends on multiple factors: o type of bicycle, type of smartphone, etc. Using crowdsensed data for bicycle lane planning in cities App for assisting bicyclers to get green phase classification results type bumpy rough average smooth bumpy rough average smooth correct 164 false 34 accuracy 82,83% errors 17,17% 19

20 Crowdsensing Infrastructure Why an Crowdsensing Infrastructure? Cyface - detect surface quality of bicycle lanes What is the barrier? implementation effort (mobile app, user management) infrastructure setup (scalability, availability, cost) recruiting participants (app distribution, privacy and security) 20

21 Crowdsensing Infrastructure Requirements Contributors want to: contribute using different (mobile) devices independent of their location track, correct and withdraw submissions be motivated protect privacy Requester want to: address a broad base of contributors use specific mechanisms to process submissions provide rewards ban malicious users System should be easily adoptable be highly scalable and fault tolerant operate in a global setup 21

22 Crowdsensing Infrastructure Platform Architecture Achieving reusability with a set of generic functionality implemented as service a pair of libraries for accessing generic functionality Server Access Network Entity (SANE) management of user accounts, devices, submissions anonymity, security, fault tolerance and performance 22

23 Crowdsensing Infrastructure Ongoing Work Use cases Cyface MapBiquitous Landscape architecture o collect information about vegetation Traffic information o Can physical detectors be replaced/extended by crowdsensing solutions? Smart City support: Campaigns Long term motivation of submitters 23

24 IoT Platform for 3rd Party Services Overview Vision: user-centric services for the Internet of Things users consume real-world data and interact with the physical environment in real-time Connected Car domain Cars produce manifold floating car data (location, speed, fuel level, engine state, etc.) Car manufacturers protect car data in backend 3rd party services consume floating car data of multiple manufacturers (e.g. car sharing, fleet management) Approach: IoT service platform integrating real-world objects, backend systems and mobile devices Easy and cost-efficient service development Integration of mobile and wearable devices Scalable, reliable and secure data exchange 24

25 IoT Platform for 3rd Party Services Architecture Environmental Sensing Point Environmental Sensing Service XMPP Client Power Assistant Service XMPP Client Robot Comm. Service XMPP Client 3rd Party Backend Car System XMPP Client Car Manufacturer A Backend XMPP Client Data Hub XMPP Client Service Runtime App Registration and Device Management XMPP-based Service Platform Mobile Device App Runtime XMPP Client Car System Bluetooth-2-XMPP Converter Bluetooth-2- XMPP Converter XMPP Client Sensors/Actuators Consumers/Controllers Advantages Avoid redundant traffic Providecommon platform for simplifiedservice creation and provisioning Variable level of service for data transmission according to changing App requirements and varying resource availability 25

26 IoT Platform for 3rd Party Services Scenario Power Assistant Limited range of ecars Long period for recharging Low density of charging stations Relevant Floating Car Data battery charging state current speed average speed current location driving direction route additional energy consumers in car Adapting data quality according to current situation 26

27 IoT Platform for 3rd Party Services Adaptive Service Level for IoT Data Transmission Car Manufacturer Fahrzeug- Hintergrundsystem Backend Third Drittanbieterplattform Party Service Platform Mobile Device Platform Plattform mobiles Endgerät 1 hoch high 2 mittel medium 3 niedrig low low car is not moving/parking medium car is moving with low power consumption (economically driving, few additional power consumers like air conditioning or entertainment system high car is moving with high power consumption (fast driving, many additional power consumers) 27

28 Role-based Software Infrastructures for Continuous-Context-Sensitive Systems (RoSI) Challenge: long-living software requires constant changes ubiquitous computing requires dynamic changing systems Object-oriented models and programming languages not flexible enough static typing, independent from context no explicit specification of context and context dependent behavior often produces if-bloating code 28

29 RoSI Role Modelling Key idea: using Roles since they are contextually dependent and dynamic Separate the functional core of an object from its context-based and fluid features Restrictions so far: concept of roles is known but only used in singular fields of computer science (security, collaboration, etc.) no formalization no cross-layer correspondance 29

30 RoSI Involvement of CN group Self-adaptive software systems running in heterogeneous multdevice execution environments Dynamic change of software based on dynamic role binding and unbinding Coordination of adaptation processes spawning multiple nodes 30