Re: Contribution for "Proposed initial draft of "Architecture and Requirements for Web-based Signage Player - Emergency Information Profile"

Everyone,

 > I think your use case assume that digital signage terminal runs a web
 > server, and device access the web server using its web browser. right?

Right. Please see the attached file.

I answer for your all questions as belows;

Regards,
Masayuki

----
 >Could you share more detailed materials about your research?

Attached the file to show how our technology works.

 >Is the emergency information uploaded to digital signage terminal 
directly? If so, I think some kind of agent should be running within a 
digital signage terminal for fetching emergency information from 
administrator's mobile devices. Am I right?

 >It will be appreciated if you can provide more details regarding how 
these devices interact with each other?

The administrator's mobile devices can change the mode of digital 
signage from a regular mode to an emergency one and can upload updated 
emergency information to the digital signage terminal directly via Wi-Fi 
connection. The mobile devices and the digital signage terminal have a 
javascript program downloaded from a web server inside LAN of Wi-Fi 
access point. The javascript program plays a role of the agent that you 
mention.

 >You mean that digital signage terminal provides detailed emergency 
information to generic user's mobile device. right?

Yes.

 >In my opinion, the administrator already knows the address of digital 
signage terminal. If not, it is also possible to make use of network 
service discovery(NDS) that periodically broadcasts to the local 
network. Anyway, it will be better if Mr.IHARA provides more details.

You are right. The administrator knows the address of digital signage 
terminal. Also, in emergency situation, when a user (including the 
administrator) connects to the Wi-Fi s/he will be redirected to the 
portal site of the emergency mode of the signage. The mechanism of the 
redirection is same as that in free Wi-Fi spot.

 >>What is the emergency information in this situation? In this 
situation, even a system administrator would not have any useful 
information at all, isn't he? Without Internet connection, how and what 
kind of information can he get?
 >
 >I understand your concern. I think that the administrator can have 
emergency information through various ways such as mobile networks, or 
local administrator's decisions.

Please imagine a train terminal just after disaster occurred. The train 
company staff has much useful information such as the nearest evacuation 
center or which line is suspended or delayed. The useful information can 
be obtained from the real situation. Of course, if the staff can know 
other information from another channel such as TV or phone calls from 
other train stations s/he can also upload it.

 >>> - the emergency information delivery by a distinction between 
categorized abstract contents for a signage display such as "public 
transportation" or "evacuation center" and detailed contents of each 
category for users' mobile devices
 >>
 >>I couldn't understand this statement. What is a distinction in this 
context? What are categorized abstract contents? Could you elaborate it 
a little more?
 >
 >This sentence is needs to be clarified. It is ambiguous whether this 
is related to delivery or information. As far as I understand, this 
requirement is about providing more detail information to user's mobile 
devices from digital signage terminal. For example, a screen in front of 
evacuation center just display "evacuation center" with additional 
information how to get more detail information from user's device. Of 
course, it is assumed that full information is already conveyed from 
administrator's devices. In other words, signage terminal displays 
simple message, and is capable of providing detail information to user's 
devices.

In my opinion, a signage display should show only the category and brief 
statement and detailed information should be displayed on users’ mobile 
devices. For example, only “Nearest evacuation center” and “The Central 
Park” are displayed on a signage display and detailed information about 
how to get to The Central Park is displayed on users’ mobile devices 
with landmarks or pictures.

 >The proposed requirements needs to be aligned with "Conformance" 
section, if those proposed sentences are for providing requirements. 
Hence, I want to propose to modify those requirements as follows;
 >
 >- The digital signage system is RECOMMENDED to be capable of 
collaborating with mobile devices through local area network for 
exchanging emergency information, if the local network is still alive.
 >- The digital signage system is RECOMMENDED to be capable of uploading 
of emergency information from administrative mobile devices, if the 
connection with content management system is lost.
 >- The digital signage system is RECOMMENDED to be capable of providing 
detailed emergency information to user's devices, and RECOMMENDED to 
display a method how to get the information.
 >For example, a signage terminal in front of evacuation center just 
shows "Evacuation Center" and additional information how to get detail 
information, and a user can get detailed emergency information from the 
signage terminal.

I agree. RECOMMENDED is better.

 >>How would the devices connect to the sign's local network? Normally 
that is locked out from public access on every commercial deployment I 
have seen so far.
 >
 >You are right. Wook and I have the same question too. I hope Masayuki 
will share the technical information of the NTT's field test. We have to 
discuss the way to achieve this requirement technically more.

See the attached file. Each device can join the local network by 
connecting to the Wi-Fi, accessing to the portal site by redirection, 
downloading a javascript program from a web server, running the 
javascript program and establishing a WebSocket connection. In the 
network, the signage can be accessed by users only for viewing contents 
and by an administrator for updating contents.

 >And I don't seen the need to restrict it to mobile devices.

 >>- The digital signage system is RECOMMENDED to be capable of 
uploading of emergency information from administrative mobile devices, 
if the connection with content management system is lost.
 >
 >Ditto for the mobile comment. It's also very likely that the 
administration console is very likely to be a PC of some sort - just to 
be factually correct, I don't think the word "mobile" is needed here.

Regarding the restriction to mobile devices, in emergency situation an 
administrator should catch up with the change of situation around the 
signage terminal and should immediately update signage contents 
according to the current situation. For example, if it is heavily 
crowded in front of the signage terminal the administrator should upload 
the new content which recommends people to move away to the nearest 
evacuation center to avoid unexpected accidents. Uploading signage 
contents from a mobile device is effective in such real situation in 
terms of “immediate updating”. I suggest the following revision of the 
sentence.

- The digital signage system is RECOMMENDED to be capable of uploading 
of emergency information from not only administrative PC but also 
administrative mobile devices, if the connection with content management 
system is lost.


 >>"Providing" is pretty vague. Are you implying that the terminal 
should provide a method to digitally copy the information over to a 
client? That's at least one would guess since there is a "user device" 
in the context - in which case the wording of the actions should be made 
more specific.
 >>
 >>If so, I think there should be at least one recommended transport 
method here. (I don't have any good ideas, NFC is probably one option 
but the amount of data you can transmit over is quite limited, and 
realistically I don't see people lining up to touch their phones on a 
sign during a emergency situation - but that could be just me assuming 
people don't follow the rules when there is a disaster.)
 >
 >Portability of information (digital copy) is useful in disaster 
situations, I think. In the situation, most of evacuation centers would 
be isolated. Besides they would lose the Internet connections. But some 
people would move to other centers. If they could have digital copies, 
the information would be spreaded to many centers.
 >
 >Though we have to clarify the way to achieve technically, I agree that 
this requirement is put into the conformance section in the doc.

One way of the digital copy is that when a user’s mobile device is 
redirected to the portal site the contents copied from the signage are 
displayed on the mobile device. The copied contents are categorized into 
a menu of disaster information. If the user chooses one category from 
the menu, detailed information of the category will be displayed on the 
mobile device.
----



> Thank you Mr.IHARA.
>
> I think your use case assume that digital signage terminal runs a web
> server, and device access the web server using its web browser. right?
> It will be better if you can give us a generalized figure for describing
> your use case.
>
> I hope you enjoy the flight. See you.
>
> Regards,..
>
>
> 2014-06-02 10:40 GMT+09:00 Masayuki IHARA <ihara.masayuki@lab.ntt.co.jp
> <mailto:ihara.masayuki@lab.ntt.co.jp>>:
>
>     Thank you for the discussion. I am sorry for this late reply.
>
>     Our technology is based on WebSocket-based communication
>     among users' devices and digital signage terminals, and each device
>     works by a javascript program downloaded from a web server
>     in LAN side of Wi-Fi access point. It is supposed that the digital
>     signage devices would be mananged inside the LAN in emergency situation.
>
>     I will send a figure to show how to work and answers for your questions
>     probably tomorrow. (I have to fly to Geneva from now.)
>
>     Regards,
>     Masayuki
>
>
>                 While we aren't making a normative document here
>                 (although I seriously wish
>                 we could) making the transport method completely open
>                 ended just makes life
>                 complicated for implementors.
>
>
>
>
>             What do you mean "a normative document"?
>             Legally, BGs can make only group notes. Do you mean this?
>             If we find lack of APIs, we can make API drafts unofficially.
>             Then we can propose them to WGs.
>
>
>         I was noting that since we are only working on a group note,
>         being very open ended
>         and ambiguous is probably acceptable but not ideal. Having
>         everything too open ended
>         will end up in a group note that neither a implementor or a
>         content developer can actually
>         refer to, as it's just a collection of ideas and use cases with
>         no specifics.
>
>         I honestly don't think that there is much of a point in
>         publishing a document that can't
>         be used as a reference from either side - which is what I was
>         trying to point out.
>
>         Sangwhan
>
>
>
>
>
>
>
>
> --
> 현욱 드림.



-- 
井原 雅行（Masayuki IHARA）
NTTサービスエボリューション研究所
サービスハーモナイズプロジェクト
〒239-0847 横須賀市光の丘1-1-309A
phone: 046-859-5018, fax: 046-859-5560
email: ihara.masayuki@lab.ntt.co.jp or ihara@acm.org