Revision as of 16:59, 25 March 2015

Discussion page. Let's keep (visible) record of the comment by inserting: NAME - ~~~~~ or simply ~~~~

COPELABS Comments

In order to avoid ending up with a large number of pictures, we should keep only the ones that: i) although being similar allow us to extract more requirements; ii) are sufficiently different to show the applicability range of UMobile technology. IMO, we should include a picture are the typical Digital Inclusion use-case (extend the Internet to remote areas), since most people will associate the “universal” property of UMobile to this use-case. However, due to the lack of scientific novelty in the development of yet another mute based system, I suggest to present such picture as the type “and yes, our technology can actually also be used to extend the Internet to remote areas.

For instance: IMO, picture 3 is similar to picture 1 and it related to micro-blogging (getting info about surrounding events). In picture 1 the events are sales, street happening, etc, and in picture 2 the events are about availability of ticket, size of ticket queue, traffic jam, road accidents, etc. My suggestion is to merge pictures 1 and 3.

Picture 6 seems a case of "Free Internet Access"

Looking at the current pictures, it seems that UMobile will be useful to improve civil protection (crowd control, management of disaster cases), to react to emergency situations (e.g. earthquakes, fires), as well as to improve our daily life experience (micro-blogging, daily routine improvement, free Internet access)

Fon Comments

Picture 1 In this scenario it is said "Information travels around the city through transportation or Internet". What does this mean? The user can access UMOBILE info through Internet or that the info goes to one hotspot to other through Internet?

Picture 2 We suppose that there is also TTL in this scenario? If not, a server is needed. If there is TTL, old opinions and info of the restaurants could not be stored, just the status like if there is many people there, or if there is an emergency. Bob would be able to send and receive info in this scenario?

Picture 3 The archaeological place status info functionality (if there are many people, discounts, etc) is very similar to the restaurant status of Picture 2. In this scenario, will the info go from device to device or will be always from CPE to device?

Picture 4 Do we have any partner with sensors? In case of disaster (no Internet) how will be the info be stored in the UAV? Manually?

Picture 5 Getting UMOBILE notifications without Internet access is covered in other scenarios. Offer free Internet (email) has sense in the scope of this project?

Picture 6 Very similar to Picture 3. Maybe Picture 3 could include that the info can go through vehicles, devices or Internet like this one and discard Picture 6.

Picture 7 How is the information sent from 1 city to the other one?. What would be UMOBILE contribution in this scenario?

AFA Systems comments

As already summerized by COPELAB, we should avoid to introduce a large number of pictures. Following the discussion in the KoM, and based on the designed picture, we should now focus on the main, arised, goals of UMOBILE:

1. to improve our daily life experience (micro-blogging, daily routine improvement);
2. to help civil protection department (crowd control, management of disaster cases);
3. to react to emergency situations (e.g. earthquakes, fires);
4. to provide universal internet connection (to remote areas).

Based on the previous goals, we could design 4 main big pictures:

• merging the already designed ones;
• motivating the need for a UMOBILE application, instead of updating through Facebook/twitter etc. (expecially in the first -social- picture);
• motivating the need for a UMOBILE opportunisti communcations, instead of the Interne connection (3G, hotspot, etc.)
• keeping the onesallow us to extract more requirements.