A new revolutionary software for EETAC’s students and teachers.

This App comes with localization, routing mechanisms, social network and much more!

EETAC App

Tab

le o

f C

on

ten

ts

1. Concept 2. How it works? Stories 3. Workflow

4. Entity-Relashionship 5. Technologies

6. Ericsson Maps 7. Security 8. Rest Client Pattern 9. Cache mechanism

10. Traffic Analisys

11. Summary & Conclusions

Introduction to the application and user experience

Diagrams with different aspects of the architecture of the application.

Most important technical aspects, explained in detail.

2

Explaining what offers our App

3

» Offers orientation service inside the campus, where the user can explore the buildings and find the best route to go to any room.

» Follows web 2.0 Users can enrich the App sending comments and P.O.I

» Userful tool designed for Eetac students and teachers but also for visitors which don’t know the campus.

» What is the difference with Foursquare and other similar apps? Indoor positioning and routing.

Concept 4

Giving an example of how the App works

5

» This Monday was about to start badly for Bob. Just landing from

London at 13:17 am, he could definitively not remember the

explications about how to reach the conference room. Luckily, he

downloaded EetacApp before leaving, following his colleague’s

advice. Within a few moments, the application gave him the

quickest way to the place.

» After the presentation of Urbanization in room V-212, the group

was very pleased to see their friends have already taken pictures

and upload them with the EETAC App, creating several threads

about the main debated issues. Now, other students can see the

gallery pictures and add some comments.

Story 6

Explaining the Flow Diagram of the layouts of our App

7

Flow Diagram for Authentication

Starting Point Login (general) Tw

itter lo

gin

Local re

gistration

8

Flow Diagram for general use

Starting Point

Map

Explore Sites Site Site P.O.interest

Pro

file (eve

rywh

ere

)

ActionBar

9

Understanding the Entity-Relationship diagram

10

Entity-Relationship Diagram

6 entities

» Location: Where is the user

(dynamic)?

Where is a Site (static)?

» User: User information.

» Site: Site information.

» Check-in: Relates a User with

a Site (dynamic).

» Picture: P.O.I related with a

Site and a User.

» Comment: Comment related

with a Site and a User.

-id

-username

-password

-surname

-description

-email

-set<Checkin>

-set<Comment>

-set<Picture>

User

-id

-author

-route_image

-user

-date

-set<Comment>

Picture

-id

-name

-description

-num_checkins

-num_comments

-floor

-building

-checkin_id

-route_image

-set<Picture>

-set<Checkin>

Site

-id

-date

-site

-user

Check-in

-id

-text

-author

-date

-user

-picture

Comment

Location

1 0..*

10..*

0..*

1 1

1

0..*

1

0..* 1

Table: user_checkin

(user_id | checkin_id)

Table: site_checkin

(site_id | checkin_id)

1

0..*

1

0..*

Table: site_picture

(site_id | picture_id)

Table: user_picture

(user_id | picture_id)

Table: picture_comment

(picture_id | comment_id)

Table: user_comment

(user_id | comment_id)

11

Citing all the Technologies used for the project

12

Technologies Diagram

Indoor possitioning Show maps Route calc.

Database

We

b S

erv

er

Mo

bile

Ap

p

HTTP/JSON

TCP/IP

HT

TP/J

SON

OA

UTH

REST

13

Explaining what the App do with Ericsson Maps API

14

» Create maps using bulging plan and XML tags.

Ericsson Maps API 15

» Indoor localization and navigation using predefined routes, Wi-Fi Aps localization and XML tags as elevators or stairs.

» Add information using over lays

» Room labels

» Finish flag

» Google Maps to Ericsson Indoor Maps by Zoom

Ericsson Maps API 16

Adding Security to the App

17

» Challenge Implemented (SHA)

» Unique token generation.

» Token expires in 30min.

» For registering purposes, HTTPS

should be used

Security for Authentication

GET /date

Eetac_challenge: 63fe6da0...

200 OK

date=”2020134…”

date=”yyyyMMddHHmmssSS”Eetac_challenge=63fe6da0...

Eetac_challenge=long ID

POST /user/login

Eetac_challenge: 63fe6da0…

user

token=password=hash(date +

hash(password))=42D11GP...

token=password=hash(date +

hash(password))200 OK or 403 FORBIDDEN

user_id=2

Eetac_token=token

GET /site

Eetac_token: 42D11GP...

If (server_token == client_token) return 200;

else return 403;

18

Communicating with the server through a REST Client Pattern

19

The operating system may shut down the process.

» The processor could be destroyed in the middle of an operation.

The UI is frozen by the Processor (not interactive).

No memory or Database storage == bandwidth waste.

Wrong REST Client Pattern 20

Good REST Client Pattern 21

Adding Cache mechanism to the App

22

» Only image caching mechanism implemented

1. Download the image (write the outputstream of HTTP GET).

2. Save in the SSDcard (cache).

3. Save in memory (SoftReference HashMap)

» Before retrieving all data, retrieve a hashCode of it (no changes = no hashcode changes = no retrieving all data)

» Save each request in the Content Provider

» Good performance under 1MB of data on the Cursor Persistence == Requests == Battery consumtion

Cache 23

Dimensioning our App, through a Traffic Analisys 10

24

Traffic Analisys 25

OFF state

Get ALL Sites

User’s activity

Get Site Z

User’s activity on site Z

𝜇0

𝜇1 𝜇2

𝜇3

𝜇4

𝛿4 𝛿2

𝛼1

𝛼2 𝛼3 𝛽1

𝛽3

Γ

γ

» Several equations can be gotten from this Markov chain.

» 𝑃𝑖 = 1 = 𝑃𝑂𝐹𝐹 + 𝑃𝑔𝑒𝑡𝐴𝐿𝐿 + 𝑃𝑈𝐴 + 𝑃𝑔𝑒𝑡𝑍 + 𝑃𝑈𝐴𝑍𝑖 𝜖 𝑆𝑡𝑎𝑡𝑒𝑠 𝑃𝑂𝐹𝐹 = 𝜇0 ∗ 𝑃𝑂𝐹𝐹 + 𝛿2 ∗ 𝑃𝑈𝐴 + 𝛿2 ∗ 𝑃𝑈𝐴𝑍

𝑃𝑔𝑒𝑡𝐴𝐿𝐿 = 𝛾 ∗ 𝑃𝑂𝐹𝐹 + 𝜇1 ∗ 𝑃𝑔𝑒𝑡𝐴𝐿𝐿 + 𝛽1 ∗ 𝑃𝑈𝐴 + Γ ∗ 𝑃𝑈𝐴𝑍 𝑃𝑈𝐴 = 𝛼1 ∗ 𝑃𝑔𝑒𝑡𝐴𝐿𝐿 + 𝜇2 ∗ 𝑃𝑈𝐴

𝑃𝑔𝑒𝑡𝑍 = 𝛼2 ∗ 𝑃𝑈𝐴 + 𝜇3 ∗ 𝑃𝑔𝑒𝑡𝑍 + 𝛽3 ∗ 𝑃𝑈𝐴𝑍 𝑃𝑈𝐴𝑍 = 𝛼3 ∗ 𝑃𝑔𝑒𝑡𝑍 + 𝜇4 ∗ 𝑃𝑈𝐴𝑍

6 equations, 19 unknown. Get experimental values to solve the problem. Discrete time analysis of a Markov Chain.

Traffic Analisys 26

𝑃𝑈𝐴𝑍 =

𝛼31 − 𝜇4

∗ 𝑃𝑔𝑒𝑡𝑍

𝑃𝑔𝑒𝑡𝑍 =

𝛼2

1 − 𝜇3 − 𝛽3 ∗𝛼3

1 − 𝜇4

∗ 𝑃𝑈𝐴 = 𝐴 ∗ 𝑃𝑈𝐴

𝑃𝑈𝐴 =𝛼1

1 − 𝜇2∗ 𝑃𝑔𝑒𝑡𝐴𝐿𝐿

𝑃𝑔𝑒𝑡𝐴𝐿𝐿 ∗ 1 − 𝜇1 −𝛼1

1 − 𝜇2∗ 𝛽1 − Γ ∗

𝛼31 − 𝜇4

∗ 𝐴 = 𝛾𝑃𝑂𝐹𝐹

𝑃𝑔𝑒𝑡𝐴𝐿𝐿 =𝛾

𝐵∗ 𝑃𝑂𝐹𝐹

Traffic Analisys 27

Traffic Analisys 28

What we know: • Get All Size is a packet of

length: 3988 + 86 = 4074 bytes.

• Minimum packet size for Get Site Z: 158 + 86 = 244 bytes.

• Estimated velocity at server output: 1Mbyte/s getALL Transmission time

≈ 4ms <35ms get Z Transmission time

≈0,25ms << 35ms • Ping between mobile device

at the Eetac and the server:

70ms Latency for downlink ≈35ms.

• Unitary discrete time = 10ms.

Traffic Analisys 29

Traffic Analisys 30

Traffic Analisys 31

0

1000

2000

3000

4000

5000

1

10

19

28

37

46

55

64

73

82

91

10

0

10

9

11

8

12

7

13

6

14

5

15

4

16

3

17

2

18

1

19

0

19

9

JSON Packet size

Series1

Traffic Analisys 32

State getALL User's activity getZ User's Activity

site Z

Time (ms) 39 18 116 35 23 291 + Time slot = 10ms

Probability to stay in one state and to leave it

Exhaustive Analysis of the logs: Get the probability to go toward each state.

𝑃𝑈𝐴→𝑔𝑒𝑡𝐴𝐿𝐿 =221

𝑃𝑈𝐴→𝑔𝑒𝑡𝑍 =14

21

𝑃𝑈𝐴→𝑂𝐹𝐹 = 521

𝑃𝑈𝐴𝑍→𝑔𝑒𝑡𝐴𝐿𝐿 =949

𝑃𝑈𝐴𝑍→𝑔𝑒𝑡𝑍 =33

49

𝑃𝑈𝐴𝑍→𝑂𝐹𝐹 = 749

Traffic Analisys 33

With this, we get all the transition probabilities, except γ and μ0.

From 19 to 7 unknowns: more hypothesis are needed Hypothesis: A session (ON) happens every 24 hours.

• 24 hours <-> 8,64.10^7 ms Average Session Time = AST

𝐴𝑆𝑇 = 187450 +5

12∗ 𝑈𝐴𝑇𝑖𝑚𝑒 +

7

12∗ 𝑈𝐴𝑜𝑠𝑍 = 208 585 𝑚𝑠

𝑃𝑂𝐹𝐹 = 0,997586

• Using 𝑇𝑂𝐹𝐹 , 𝛾 = 1,16 ∗ 10−8 and 𝜇0 ≈ 1

State getALL User's activity getZ User's Activity site Z OFF

Probability 8,790000E-08 4,000000E-05 5,130000E-08 1,050000E-04 9,975860E-01

Probability 0,00000879% 0,00400000% 0,00000513% 0,01050000% 99,75860000%

Traffic Analisys 34

0

0,5

1

1,5

2

2,5

3

3,5

40 80 120 160 200 240 280 320 360 400 440 480 520 560 600

PDF Session

PDF Session

𝑃𝑂𝐹𝐹= 0,997586

𝑃𝑂𝑁 =0,002414

𝑃 𝑛 𝑠𝑖𝑚𝑢𝑙𝑡𝑎𝑛𝑒𝑜𝑢𝑠 𝑢𝑠𝑒𝑟𝑠 = 𝑃𝑂𝑁𝑛 ∗ 𝑃𝑂𝐹𝐹

𝑁−𝑛

Traffic Analisys 35

𝔼 𝑝𝑟𝑜𝑏𝑎𝑏𝑖𝑙𝑖𝑡𝑦 = 0, 000 089 then Number of user: 𝔼[𝑛] = 1,14629 𝐵𝑊𝑛𝑒𝑒𝑑𝑒𝑑 = 1𝑀𝑏𝑦𝑡𝑒/𝑠 because 𝑃𝑂𝑁_𝑜𝑛 ≪ 𝑃𝑂𝑁: support peaks.

Explain the tasks done; the tasks to be performed and the conclusions

11 36

Tasks Performed

» Show EETAC Map (Ericsson)

» Indoor Positioning (Ericsson)

» Route to a Site (Ericsson)

» Twitter Integration (OAuth)

» Server persistence (Postgree + Hibernate)

» REST client and Server communication (Spring and Jersey)

» GET/PUT images from/to the server

» GET/PUT/DELETE comments from/to the server

» PUT/DELETE checkin from/to the server

Tasks performed summary 37

Tasks to be performed summary

Tasks to be Performed

» Interaction between users

» View users profile and comments

» Integration with Facebook

» Add dynamically a Site

» Improve the “Go to” guide

» Use more the Local Cache (Content Provider)

» Integration with Google Maps

38

Conclusions

Indoor positioning & routing

» Bad precission because of the Aps power. Some brands offer

better precission with their own hard&soft.

Android (Client)

» Since the life cycle of an Activity is managed by Android; the

programmer should be careful.

» Limitted memory space also should be taken into account.

» Battery consumption should be taken into account.

Rest Client Server

» Difficulty to integrate Hibernate (learning curve).

39

? Questions?

40