Latest revision as of 12:47, 30 April 2015

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

We'd like to share some thoughts on the use cases, maybe introducing "WP2 - System requirements” themes.

AFA Comments Angela (talk) 13:47, 30 April 2015 (CEST)

Micro-blogging

The micro-blogging use case fits well in the Wireless City ("Citta' Wireless") architecture we operate in several Italian towns. In each of these Wireless Cities, an 802.11ac wide area network covers the entire town, reaching all public buildings and schools and many squares. In buildings, schools and squares everybody can interact with the network infrastructure via Wi-Fi.

The benefit is that we promptly have a layer that can be easily UMOBILE-enabled and that can reach a large number of users (students, tourists, residents, ...) transforming them in a trust circle (or more then one trust circle).

While this condition may appear as special case, it addresses some weaknesses we figure out in the UMOBILE architecture, such as who owns, manages - and sometime authorizes - the UMOBILE hotspots (or, better, systems as Liang's pointed out).

In other words, the Wireless City makes permanent the temporary "festival-related" UMOBILE depicted infrastructure.

Let's think if it could be useful and easily to produce touchable outputs deploying a trial in one of our active Wireless Cities.

Civil protection and Emergency Situations use cases

Generally speaking, and in particular in these use cases, the UMOBILE architecture should take into account these devices:

• not-wearable fixed device (cams and sensors which grab images and data, maybe later collected by a UAV)
• not-wearable vehicular device(on a UAV or a terrestrial vehicle)
• wearable - not-smartphone (e.g. Raspberry + GoPro as a rough suggestion) (as equipment of each member of the rescue/security team)
• wearable smartphone - not-personal (i.e. with a defined set of apps/configuration, not in the command of the user) (as equipment of each member of the rescue/security team)
• personal smartphone (the main one).

Whilst the personal smartphone is with no doubt the widely spread device, a "special" UMOBILE-by-construction device (i.e. the rescue team "kit") could allow us to gain outputs more easily. In this perspective, a specific trial would help the dissemination.

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 opportunistic communcations, instead of the Interne connection (3G, hotspot, etc.)
• keeping the onesallow us to extract more requirements.