APT International Collaborative Research 2016

Reporton
International Collaborative Research of
Disaster Response Modelusing Vehicle Communication

March 9, 2018
Submitted to:
Project Leader:

The Asia-Pacific Telecommunity
Dr. Gregory Tangonan
Ateneo Innovation Center,
Ateneo de Manila University, Philippines

Preface

Eliseo Rio, Jr.

Undersecretary
Department of Information and Communications Technology
Philippines
Distinguished delegates, colleagues, ladies and gentlemen, good morning!
It is my distinct honor and pleasure to welcome you all to this Asia-Pacific Telecommunity
workshop on “International Collaborative Research on Disaster Response Model Using Vehicle
Communication.”
The English social thinker John Ruskin once said, “When brilliant minds, attitudes, and talents
come together to form one goal – expect a masterpiece.”
In the next few days, the masterpiece we’ll be working towards creating is a matter of massive
importance. The presence or absence of it could mean a life saved or a life lost.
Communication. The be-all and end-all during and after disaster. Its availability can be thedifference between life and death.
And the question we’ll find answer to, When the world goes silent, how do we communicate?
According to the 2015 Asia-Pacific Disaster Report, Asia-Pacific remains to be the world’s mostdisaster-prone region, which bore the brunt of 1600 natural disasters in just the past decade,40 percent of the global total.
And the Philippines, the fourth most disaster-prone country in the world, endured a total of
274 natural calamities, covering the period between 1995 and 2015, according to a study
conducted by UN Office for Disaster Risk Reduction.
When Typhoon Haiyan, the strongest storm on record that struck the Philippines in November

2013, major issues on communications capabilities arose. There were reports that
communications gap immobilized relief efforts. Connection was cut between first responders
on the ground and the headquarters in Manila. This is a situation that highlights the value of
emergency communications systems in disaster relief efforts. The faster the response is, themore lives are saved.
More than 7,000 were killed by the super-storm and estimated economic losses amounting to
US$10 billion, and we do not intend to lose more from worse disasters in the future. We canonly hope for the best and prepare for the worst by leveraging technology in disastermanagement.
The Philippines, through the Department of Information and Communications Technology(DICT), would like to express our gratitude to the Ministry of Internal Affairs andCommunications of the Government of Japan for our ongoing ICT cooperation. Last June 30,
we held our first conference meeting with them and we are looking forward to promoting ourcooperation for enhancing the capability of disaster management in the Philippines using ICT
systems.
And thank you to the Asia-Pacific Telecommunity for having us on board this International
Collaborative Research on telecommunications. Let’s take this three-day opportunity to learn
from each other’s expertise and unique experiences. Through this learning process, we hope
to convert our shared knowledge into actionable strategies and develop a harmonized set ofutilization standards for vehicle communications networks during disasters.
Our regional cooperation is our sure-fire way to make Asia-Pacific truly disaster-resilient!
As we say it here, MABUHAY, everyone!

(quoted from Welcome Address for the Workshop on International Collaborative Research of
Disaster Response Model Using Vehicle Communication at Mabini, Batangas, Philippines,on 12 July 2017)

Message from the Project Leader

Professor Gregory Tangonan
Ateneo Innovation Center
Ateneo de Manila University, Philippines
Welcome to the Asia-Pacific Telecommunity (APT)-sponsored workshop on the standard
specifications of information and communications systems using vehicles during a disaster on
the V-Hub. The APT, with the able assistance of the Telecommunications Technology
Committee of Japan (TTC), deserves our sincerest thanks for sponsoring the activities related
to “Bridging the Standardization Gap” with Asia Pacific countries. This effort is culminatingwith the convergence of Industry, Government and Academe contributors in the Philippines
to complete the V-Hub standards specification this year.
Over the last five years researchers from throughout ASEAN and Japan have developed vehiclecommunications and information systems for disaster risk reduction and early responders. All
the participants have experienced how society can be crippled by natural disasters andsubmitted use cases for the V-Hub technology platform. The Philippines is hit with over twenty
strong typhoons every year-to this end we have contributed development of V2X
communications for disaster operations, where X can be another vehicle, an UAV, the sensor
infrastructure, and individuals interacting with the environment. To this end much work has
been done to investigate the role of sub-GHz frequencies in this context, since the propagation
characteristics match well with models of search-and-rescue operations over multiple
platforms. From this work we see the emergence of mobile cloud technology and ad-hoc WiFi
for situations with limited instantaneous bandwidth that will have many applications in future,
well beyond disaster response. The V-Hub Standard being developed here is truly a powerful
new platform for vehicular communications and information systems.
On behalf of the local organizers, the Ateneo Innovation Center and the DICT, we welcome you
to the Philippines. We hope you get to play hard and work hard during your stay.
(quoted from A MESSAGE FROM THE PROJECT LEADER, The WORKSHOP GUIDE)Table of Contents

Executive Summary........................................................................................................... 1
Chapter 1

Introduction of the Project ............................................................................ 2

1.1 Purpose ............................................................................................................................ 2
1.2 Participants ...................................................................................................................... 3
1.3 Schedule .......................................................................................................................... 6
1.4 Expected Output.............................................................................................................. 7
Chapter 2

Activities ....................................................................................................... 8

2.1 Kick-off Meeting .............................................................................................................. 8
2.2 Workshop Preparation .................................................................................................... 9
Chapter 3

International Workshop in the Philippines ................................................... 10

3.1 Workshop Program ........................................................................................................ 10
Chapter 4

Overview of Standard Specification for VHUB System .................................. 21

4.1. Device ........................................................................................................................... 21
4.2. Network interface......................................................................................................... 224.3. Application interface .................................................................................................... 24
4.4. Application.................................................................................................................... 26
Chapter 5

ASTAP-29 DRMRS SESSION........................................................................... 27

Chapter 6

Conclusion and Next Steps........................................................................... 28

Annex 1

VHUB Standards Specification Document

Annex 2Workshop Brochure and Guide

Annex 3

Keynote Presentation

Annex 4

Researcher’s Reports

Annex 5

Guest’s Presentations and Demonstration

Executive Summary

The International Collaborative Research of Disaster Response Model Using Vehicle
Communication (VHUB) is a project submitted under the APT International Collaborative
Research 2016. This project is headed by Dr. Gregory Tangonan of the Ateneo Innovation
Center, Ateneo de Manila University. Main collaborators are the Department of Information
and Communications Technology of the Philippines, Telecommunications Technology
Committee of Japan, and Toyota InfoTechnology Center Co., Ltd.
The project’s aim is to develop a set of utilization standards for vehicles as a resilient
communication network and information hub during disasters. Experts on intelligent transportsystems and disaster response from different Asian countries are the main participants in thisresearch. This expected output is a Draft Specification document that is submitted to APT for
further consideration.
The academe, industry, and government from Japan, Philippines, Thailand, Malaysia, andPapua New Guinea participated in the International Workshop held in Batangas, Philippines,
last July 12-15, 2017. This is a major activity of the project where experts from different
countries come together to discuss and share knowledge regarding disaster response and risk
management. This is also the venue where the draft specification document was discussed
and a final draft was crafted for presentation in ASTAP-29.
To date, the APT through ASTAP is consolidating the vote forms from member countries andwill be subjected for assessment whether the standard will finally be adopted and later be
implemented. The Project Team will monitor the progress of the status of the adoption of thedraft recommendation and closely coordinate with APT for any feedback.

1

Chapter 1 Introduction of the Project

1.1 Purpose
Disaster response is an important topic that should be continuously discussed ininternational meetings, with stakeholders from different countries sharing knowledge andexperiences with each other. The recent years have seen countries in Asia go throughnumerous disasters like earthquakes, typhoons, flooding, landslides, and volcanic eruptions.
When these events happen in populated areas, it results to loss of lives and properties.
Disaster response is crucial to provide immediate aid and minimize losses in communities.
A common problem encountered during disaster response is the lack of means ofcommunication, with the usual approaches like internet connectivity and cellular networks not
functioning properly. This communication problem affects almost everyone involved in thedisaster, whether survivor-to-survivor, survivor-to-rescuer, or rescuer-to-rescuer. With thedevelopment of vehicle-to-vehicle communication for automated driving, it is relevant to
explore other uses of the technology for applications that would involve the use of vehicles.
As such, this project was proposed to accelerate the international collaborative research on
the ASTAP Standardization theme of “Information and Communication System using Vehicle
During Disaster”. The project’s aim is to develop a set of utilization standards for vehicles as aresilient communication network and information hub during disasters.
The project involves international consultations that culminated in an international
workshop where experts were able to share their experiences, harness/harmonize ideas, andformulate a draft specification standard as the best practice for vehicle communications usedin disaster response. This draft recommendation was presented in ASTAP-29, after which theexperts can make follow-up actions and build a roadmap from the proof-of-concept to thebusiness practices based on the responses.

2

1.2 Participants
The success of this international project is critically dependent on the cooperation ofmany partners from academe, government, and industry from both the Philippines and Japan,
with invited experts from Malaysia, Thailand, and Papua New Guinea. The project is headed
by Dr. Gregory Tangonan of the Ateneo Innovation Center, Ateneo de Manila University,
Philippines, with close collaboration and support from the Department of Information andCommunications Technology of the Philippines, headed by Ms. Arlene Romasanta. The
Japanese counterpart for the implementation of the project is handled by the
Telecommunication Technology Committee, with Mr. Masatoshi Mano as the Project Manager.
The main activity of the project, the International Workshop, was held in Mabini,
Batangas, Philippines on July 11-15, 2017. A total of 33 participants from five (5) countries
attended the presentations and demonstrations during the 3-day event.
The workshop participants came from the following affiliations:
Philippines● Ateneo Innovation Center (AIC) - Ateneo de Manila University● Department of Information and Communications Technology (DICT)○ National Telecommunications Commission (NTC)● Philippine Communications Satellite Corporation (Philcomsat)
Japan● Telecommunication Technology Committee (TTC)● Toyota InfoTechnology Center Co., Ltd. (Toyota-ITC)● Oki Electric Industry Co., Ltd.
● Honda Motor Co., Ltd.
● SKY Perfect JSAT Corporation
Malaysia● Universiti Putra Malaysia
Thailand● Internet Education and Research Laboratory (intERLab) - Asian Institute of Technology● CAT Telecom Public Company Limited
Papua New Guinea● National Information & Communication Technology Authority (NICTA)

3

Table 1. List of Participants and Their Affiliations for the International Workshop
No.
Name
1 Eliseo M. Rio, Jr.
Undersecretary for Special Concerns
eliseo.riojr@dict.gov.ph
2 Alan A. Silor
Assistant Secretaryalan.silor@dict.gov.ph
3 Arlene RomasantaChief, Strategic R&D Services Divisionarlene.romasanta@dict.gov.ph
4 Marcelo Aberion
Information Technology Officer I
marcelo.aberion@dict.gov.ph
5 Jacoben Enzon
Engineer IIjacoben.enzon@dict.gov.ph
6 Medardo ValenzuelaLab. Tech II
medardo.valenzuela@ntc.gov.ph
7 Dennis Anthony Marquez
Officer II
dennismarquez2001@yahoo.com
8 Nathaniel J.C. Libatique
Associate Professor
nlibatique@ateneoinnovation.org
9 Gemalyn D. Abrajano
Assistant Professor
gabrajano@ateneo.edu
10 Daniel Lagazo
Researcher, Ateneo Innovation Center
dlagazo@gmail.com
11 Dominic Solpico
Researcher, Ateneo Innovation Centerdb.solpico@gmail.com
12 Jane Arleth Dela Cruz
Ateneo Innovation Center
13 Joshua Benedict Yu
Ateneo Innovation Center
14 Carlex Randolph Jose II
Ateneo Innovation Center
15 Jherrielloyd Lourrenz Yao
Ateneo Innovation Center
16 Aduwati Sali
Associate Professor IR. DR.
aduwati@upm.edu.my

Firm
Department of Information andCommunications Technology

Country
PHL

Department of Information andCommunications Technology

PHL

Department of Information andCommunications Technology

PHL

Department of Information andCommunications Technology

PHL

Department of Information andCommunications Technology

PHL

National Telecommunications
Commission

PHL

National Telecommunications
Commission

PHL

Ateneo de Manila University

PHL

Ateneo de Manila University

PHL

Ateneo de Manila University

PHL

Ateneo de Manila University

PHL

Ateneo de Manila University

PHL

Ateneo de Manila University

PHL

Ateneo de Manila University

PHL

Ateneo de Manila University

PHL

Universiti Putra Malaysia (UPM)

MYS

4

17 Gibson Kemoi
Senior Engineer ICT Policy
gkemoi@nicta.gov.pg
18 Nisarat Tansakul
Managernisarat@ait.asia
19 Arunsak Nit-in
Engineerarunsak.n@cattelecom.com
20 Hiroshi Masuyama
Manager
hiroshi_masuyama@hm.honda.co.jp
21 Akira Iihoshi
Chief Engineer
akira_iihoshi@hm.honda.co.jp
22 Yasuo Oishi
Chief Engineer
yasuo_oishi@hm.honda.co.jp
23 Yasubumi Chimura
Chairman of EG DRMRS ASTAP
chimura730@oki.com
24 Tomoki Isaac Saso
Assistant Manager
saso-tomoki-isaac@sptvjsat.com
25 Sunao Toya
Assistant Manager
s-toya@sptvjsat.com
26 Christopher Francisco
chrisfrancisco@philcomsat.com.ph
27 Junny Mark Panuela
28 Nizer Comia Rosales
29 Kazuma Sato
General Manager
ksato@jp.toyota-itc.com
30 Yoshiharu Doi
Group Leader, ITS Wirelessyo-doi@jp.toyota-itc.com
31 Ryokichi OnishiGroup Leader
onishi@jp.toyota-itc.com
32 Yoichi Maeda
S.V.P. & CEO
Chairman of ASTAP
maeda@s.ttc.or.jp
33 Masatoshi Mano
Director, Project Management
mano@ttc.or.jp

National Information &Communication Technology
Authority
intERLab
Asian Institute of Technology

PNG

CAT Telecom

THA

HONDA Motor Co., Ltd.

JPNHONDA Motor Co., Ltd.

JPNHONDA Motor Co., Ltd.

JPNOki Electric Industry Co., Ltd.

JPNSkyperfect JSAT Corporation

JPN

Skyperfect JSAT Corporation

JPN

Philcomsat

PHL

Philcomsat
Philcomsat
Toyota InfoTechnology Center

PHL
PHL
JPN

Toyota InfoTechnology Center

JPN

Toyota InfoTechnology Center

JPN

The Telecommunication
Technology Committee (TTC)JPN

The Telecommunication
Technology Committee (TTC)

JPN

5

THA

1.3 Schedule
The project duration is 11 months, from January 25, 2017 to December 24, 2017. The
following gives the schedule of the project:
January 6, 2017

Notification of selection of the project for the International
Collaborative Research Program of the APT

January 25, 2017

Notification of Acceptance of the Philippines through DICT

March 8, 2017

Kick-off meeting of the Philippine-Japan team in Bangkok during
ASTAP-28

April 2017

Writing of the initial Draft Specification v.0.1

May 2017

Circulation and review of the Draft Specification v.0.1 to member
countries

June 2017

Update Draft Specification to v.0.8, using initial comments

July 11-15, 2017
August 2017

Conduct of the International Workshop in the Philippines; updatingof Draft Specification to v.0.9, plus workshop talks anddemonstrations
Update Draft Specification to v.1.0 for presentation in ASTAP-29

September 2017

Present to ASTAP-29 and agree to Draft Specification v.1.0

November 2017

Meeting of the Steering Committee in Tokyo, Japan

December 2017

Editing of Final Report and Financial Report6

1.4 Expected Output
The project is proposed to formulate a specification standard for using vehicularcommunication as a communication hub during disaster. There are various relevant andisolated projects among the Asia-Pacific nations that deal with the project theme, and theinternational collaboration will enable those players to understand others’ experiences andharness/harmonize relevant efforts into a solid and integrative specification standard.
The Asia-Pacific Telecommunity (APT) organized the 5th APT Workshop on Disaster
Management/Communications (WDMC-5) in 2014 in Tokyo, Japan. In the workshop, manyrequirements and use cases of resilient networks and reconfigurable information systems foruse during disasters were discussed. The workshop led to the idea of developing a set of
specification standards of vehicle communications networks as resilient information hubnetworks during disasters. Thus, it is high time to step into the standardization effort on
disaster resilient communications. The purpose of the collaboration is to bring local
perspectives of Asia-Pacific nations on use cases, technologies, and regulations into a standard.
To do this, use cases from member countries were solicited, a draft specification standard waswritten and circulated, and an international workshop was conducted to produce the expected
output of the project, which is the draft specification standard on the utilization of vehicles as
information and communication hubs during disasters.

7

Chapter 2 Activities

2.1 Kick-off Meeting
The kick-off meeting for the project was held on March 8, 2017 at the Hilton Hotel in
Bangkok, Thailand. The meeting was facilitated by Mr. Yasubumi Chimura of Oki ElectricIndustry Co., Ltd. Mr. Masatoshi Mano, the Project Manager, initiated to introduce theparticipants in the meeting: the Philippine Project team headed by Dr. Gregory Tangonan ofAteneo Innovation Center (AIC) as the Project Lead, OIC Director Arlene Romasanta of the
Department of Information and Communications Technology (DICT) as the Project Co-Lead,and Mr. Ryokichi Onishi of Toyota InfoTechnology Center, Japan.
Mr. Onishi did a presentation about the Vehicle Hub (V-HUB) as a communication
system and the importance of vehicle as the hub for communication during disasters.
Communication protocols such as TV whitespace, WiFi modules, and cellular communication
are used to send messages to and from the victims and survivors in a disaster. For a successful
implementation, the protocol should be standardized in the application interface (messaging,tracking, streaming and alerting) and network interface (WLAN, GNSS, DSRC (beacon), whitespace, satellite, cellular).
Also discussed in the kick-off meeting were the next steps for the project. The AIC
together with the DICT counterpart are tasked to oversee the implementation of the workshop
in the Philippines. Target participants are the APT member countries while target place is Cebu,
Philippines in July. The venue was later changed to Batangas, a province to the south of Manila.
The draft standard specification will be circulated to the identified experts in member
countries prior to the workshop to be conducted in the Philippines. The standards would serveas the working document for review and suggestions. The same document will then bepresented to the workshop for a more participative discussion and inputs from other invited
participants.

Figure 1. Kick-off meeting, March 8, 2017, Bangkok, Thailand.

82.2 Workshop Preparation
Circulation of Draft Specification and Invitation Letters to Stakeholders
The draft specification document, which is the expected output of the project, wascirculated to APT member countries starting May 2017, specifically to those countries who
responded to the “Questionnaire on the Use-Cases for the Disaster Information andCommunication System Using Vehicle as a Communication Hub” in ASTAP-26. This was done
to get initial comments to the draft and in preparation for the international workshop to beheld in Batangas, Philippines on July 2017. Invitation letters for participation to the said
workshop was sent to the same stakeholders and other interested parties. Researchers doing
similar projects in Asian countries, their government representatives, and industry partners in
car manufacturing and satellite communications were invited to join.
Pre-meeting
Several pre-meetings were done to prepare for the workshop. After the kick-off
meeting in Bangkok, the PHL-JPN Steering Committee including Mr. Mano of TTC, Mr. Chimuraof OKI, Mr. Onishi of Toyota ITC, and the AIC and DICT working group had four teleconferences
to talk about the preparations being done for the workshop. These teleconferences happened
on March 30, April 10, May 10, and May 31. Details on the logistics of the date and venue ofthe workshop, invitation letters, workshop program, list of participants, and other logisticalmatters were discussed in these meetings.
Logistics and Participants
The International workshop was held at the Eagle Point Beach Resort in Anilao,
Batangas, Philippines last July 11-15, 2017. A total of 33 participants from government,
industry, and academe joined the workshop. Notably, two officials from the DICT of thePhilippines participated in the workshop as speakers, Undersecretary Eliseo Rio and Assistant
Secretary Alan Silor. There were also participants from the National Telecommunications
Commission (NTC), the regulating body for telecommunications companies in the Philippines,
and CAT Telecom, the public telecommunications company of Thailand. Academic experts
from Papua New Guinea, Malaysia, and Philippines gave presentations. Most of theparticipants stayed in the resort for the duration of the workshop. The workshop logistics werehandled by the researchers of the Ateneo Innovation Center.

9Chapter 3 International Workshop in the Philippines

3.1 Workshop Program
The APT International Collaborative Research 2016 Workshop on International
Collaborative Research of Disaster Response Model using Vehicle Communication (VHUB)
featured a comprehensive presentation from the participants on efforts relating to the use ofvehicle for disaster response, as well as best practices in ICT strategies for disaster risk
reduction and management. There was a total of six sessions over the 3-day workshop. The
schedule of the workshop is given in Table 2.
DATE
DAY 1: July 12
10:00-12:00

14:00-17:00

18:00-20:00

Table 2 Workshop Program
AGENDA
Session-1: Opening Session
Moderator: Arlene Romasanta, DICT, Philippines
1. Welcome address:
Eliseo Rio, Undersecretary, DICT, Philippines
2. Message:
Nathaniel J.C. Libatique, Ateneo Innovation
Center, Ateneo de Manila University, Philippines
3. Message:
Yoichi Maeda, ASTAP Chair,
The Telecommunication Technology Committee,
Japan
Session-2: VHUB Seminar
Moderator: Yasubumi Chimura, TTC, Japan
1. V-HUB: Vehicles as Information Hubs
during Disaster
2. Restoration Support by Satellite
Communications-- Tohoku-Pacific Ocean Earthquake -3. Approach for disaster prevention andreduction using Honda telematics
4. Resilient Post-Disaster Information
Systems Using Delay Tolerant Networks
and UAVs as Data Ferries
Welcome Reception

10

Kevin Sato,
Toyota ITC, Japan
Tomoki Isaac Saso,
SKY Perfect JSAT, Japan
Yasuo Oishi,
HONDA, Japan
Nathaniel Joseph Libatique,
Ateneo Innovation Center,
Ateneo de Manila
University, Philippines

DAY 2: July 13
10:00-12:00

14:00-17:00

Session-3: Review of draft of VHUB Specification
Moderator: Ryokichi Onishi, Toyota ITC, Japan
1. Presentation of VHUB Specification Draft Ryokichi Onishi
Toyota ITC, Japan
2. Discussion
Session-4: Use-case Presentation and Demonstration
Moderator: Yasubumi Chimura, TTC, Japan
1. SKY Perfect JSAT (Demo)
2. Ateneo de Manila University (Demo)
3. WiFi on Vehicle cells: Inter-operation of
Mr. Arunsak Nit-in,
Satellite, Drone and Vehicle cells
CAT Telecom, Thailand
4. Research on Disaster Response

Dr. Aduwati Sali, Universiti
Putra Malaysia, Malaysia

5. The Design and Operational Guidelines for Ms. Nisarat Tansakul,
DUMBONET Emergency Networks
Asian Institute ofTechnology, Thailand
6. ICT Strategy for DRRM (The Philippine
Asec. Alan Silor,
Setting)
DICT, Philippines
7. V2X Applications by using VHUB

DAY 3: July 14
10:00-12:00

Dr. Yoshiharu Doi
Toyota ITC, Japan

Session-5: Closing Session
Moderator: Yasubumi Chimura, TTC, Japan
Agreement on VHUB Specification or its way forward which will becontribute to ASTAP-29

14:00-17:00

Session-6: (Reserved）

18:00-20:00

Farewell Dinner

11

(a)

(b)
Figure 2 Participants of the International Workshop held in Batangas, Philippines.

12Workshop Program in Pictures: Presentations and Demonstrations
Session-1: Opening Moderator: Arlene Romasanta, DICT, Philippines

Eliseo Rio, Undersecretary, DICT, Philippines

Nathaniel J.C. Libatique
Ateneo Innovation Center, Ateneo de Manila University, Philippines

Yoichi Maeda, ASTAP Chair,
The Telecommunication Technology Committee, Japan

13

Session-2: VHUB Seminar
Moderator: Yasubumi Chimura, Oki Electric Industry, Japan“V-HUB: Vehicles as Information Hubs during Disaster”
Kevin Sato, Toyota InfoTechnology Center, Japan“Restoration Support by Satellite Communications - Tohoku-Pacific Ocean Earthquake –”Tomoki Isaac Saso, SKY Perfect JSAT, Japan“Approach for disaster prevention and reduction using Honda telematics”
Yasuo Oishi, HONDA Motor, Japan14

“Resilient Post-Disaster Information Systems
Using Delay Tolerant Networks and UAVs as Data Ferries”
Nathaniel Libatique, Ateneo Innovation Center, Ateneo de Manila University, Philippines

7. V2X Applications by using VHUB
Dr. Yoshiharu Doi, Toyota InfoTechnology Center, Japan

15

Session-3: Review of draft of VHUB Specification
Moderator: Ryokichi Onishi, Toyota InfoTechnology Center, Japan

Presentation of VHUB Specification Draft
Ryokichi Onishi, Toyota InfoTechnology Center, Japan

Discussion

16Session-4: Use-case Presentation
Moderator: Yasubumi Chimura, TTC, Japan

WiFi on Vehicle cells: Inter-operation of Satellite, Drone and Vehicle cells
Mr. Arunsak Nit-in, CAT Telecom, Thailand

Research on Disaster Response
Dr. Aduwati Sali, Universiti Putra Malaysia, Malaysia

17

The Design and Operational Guidelines for DUMBONET Emergency Networks
Ms. Nisarat Tansakul, Asian Institute of Technology, Thailand

ICT Strategy for DRRM (The Philippine Setting)
Asec. Alan Silor, DICT, Philippines

18

Session-4: Demonstration
Ateneo de Manila University (Demo)

SKY Perfect JSAT (Demo)19

Session-5: Closing Session
Moderator: Yasubumi Chimura, Oki Electric Industry, Japan
Agreement on VHUB Specification
or its way forward which will be contributed to ASTAP-29

20

Chapter 4 Overview of Standard Specification for VHUB
System

V-HUB system is the entire information and communication system using vehicles*1during disaster. Note that it is not limited to vehicle unit. The V-HUB*2 system has two types ofinterface; network interface for devices and application interface for applications. The
specification covers scenarios using vehicles to replace destroyed/broken communication
infrastructure during disaster beyond V2V communications.
Note *1; The vehicle of V-HUB has engine or motor and battery, communication unit.
Note *2; The HUB of V-HUB means information and communications infrastructure.

Figure 3. The VHUB system
4.1. Device
Device is defined as a hardware that serves as a communication network node and may
include consumer device, vehicle unit, and information kiosk. The consumer device is off-theshelf such as smartphone, PC, tablet, and other mobile devices.
A) Smartphone, Tablet, PC

The computer device used for consumer.

B) Other mobile devices

The mobile computer device not included in A.

C) Vehicle unit

The vehicle unit can be factory-installed bymanufacturer and also carried-on by user.

D) Information Kiosk

The information kiosk may include a stationary server at21

the evacuation site with internet access. The
information kiosk is usually maintained by designatedoperators.
4.2. Network interface
Network interface is defined as a communication interface among devices and may
include WLAN, beacon (V2X), satellite, white space and cellular.
1) WLANWLAN has two major connection methods; infrastructure mode and ad-hoc mode. The
V-HUB system must support the infrastructure mode because most of consumer off-the-shelfdevices such as smartphones only support the infrastructure mode and the V-HUB system
must offer the service to such popular devices. Alternatively, the V-HUB system may
additionally support ad-hoc mode for communications between vehicle units. Since this is alsoachieved by infrastructure mode as mentioned below, the ad-hoc mode specification has been
postponed. It does not mean the ad-hoc mode remains declined. This option can also be
developed in the future.
The infrastructure mode has two functions; AP and STA. One WLAN AP serves multiple
connections to WLAN STAs. It is not supported to establish connection between APs or
between STAs. Since the consumer devices usually operate WLAN STA as a standard setup, thevehicle unit must operate WLAN AP to connect to user devices without any operation on theuser side. In addition, the inter-vehicle communication also requires the AP-STA linkage. Thismeans that the vehicle unit must operate WLAN STA for relaying. This also benefits the vehicle
unit to connect to the internet access point and information kiosk at the evacuation site. As aconsequence, the vehicle unit must operate both WLAN AP and STA. There are three potential
options for this as follows: (1) dual interfaces, (2) concurrent mode, and (3) Wi-Fi Direct. With
dual interfaces or concurrent mode, the vehicle unit may operate both AP and STA at the sametime. The concurrent mode is to switch AP and STA periodically on the single interface toemulate (pretend) the dual interfaces. This is a kind of proprietary technology provided bymany major WLAN chipset manufacturers. Though it looks the simplest setup, it is not true
actually. If there are several vehicles in the same communication vicinity, multiple APs areappeared. Since there is no linkage among APs, communication network is divided among APseven in the same communication vicinity. This also induces a complication for users to choose
one AP to connect. The third option Wi-Fi Direct enables the interface to be AP or STA and not
both at the same time. If there is no AP, the interface gets AP. If there is AP, the interface gets
STA and connects to the existing AP. If existing APs are met, one random AP gets STA andconnects to the other AP. This mechanism virtually ensures a single AP in the samecommunication vicinity and keeps the V-HUB system away from network complication due tomultiple APs that occurs in case of dual interface and concurrent mode.
In addition, it is quite opportunistic to practice inter-vehicle communication on thestreet. In order to increase that opportunity, it will be highly recommended that the V-HUB
system support IEEE802.11ai of Fast Initial Link Setup (FILS) capability.

22Note that this specification does not cover multi-hop ad-hoc routing, that is known as
VANET (Vehicular Ad-hoc Network), and DTN (Delay/Disruption Tolerant Network). Bothcapabilities can be developed in the future.
2) Beacon (V2X)
The consumer device (pedestrian device) broadcasts a rescue message using wirelessbeacon(s). The vehicle unit (including drone) relays the message to the information kiosk. After
receiving the message at the information kiosk, the massage will be used to make rescue map
in the information kiosk. The rescue map shows position and priority of people who needs
support. Typical wireless media for the beacon are 1) ARIB STD T109 (V2X) and 2) IoT using
sub-giga band (IoT), because communication distance and stability is better than higher band.
Field trial to confirm communication distance is carried out in the Philippines and it is reported
to ASTAP. The report shows that the vehicle unit can work to find victims and the information
kiosk can gather the victim information.
This system has three types of beacons. First beacon is an alert delivery beacon thatwill be sent by authorized organization. This beacon defines mode of this system and area. If
the alert delivery beacon shows disaster mode and certain area, consumer devices that are in
the certain area shift to disaster mode automatically. Before shifting disaster mode, theconsumer devices stay in normal mode, so the pedestrian units can use the beacon system fornormal V2X communication and so on.
Second beacon is a rescue request beacon, and this rescue request beacon can be sent
only after shifting disaster mode. We can assume that the beacon can be sent by four cases.
First case is that the consumer device sends the beacon automatically. Second case is victim
sends the beacon by him/herself. Third case is other person sends the beacon in order to callrescue team for rescuing victims. Fourth case is a rescue team uses this beacon to share theinformation within another rescue team. The rescue request beacon includes requirement
information, personal information that is needed, vital information, and METHANE
information. METHANE is defined in NATO. M means Major incident happens. E means Exact
location. T means Types of incident, H means kind of Hazard, A means Accessibility to thelocation. N means Number of casualties. E means Emergency services to rescue the casualties.
Third beacon is a rescue response beacon from rescue team to victim. This rescue
response beacon includes accepting time, estimated arrival time, and so on.
3) Satellite
Satellite Network Interface is used for providing robust communication line to othernetworks outside the V-HUB system.
In a typical regulatory environment, high power satellite communication requires a
trained and licensed person to operate the terminal. However, in a case of disaster obtaining
such personal at the right site will be extremely difficult. Therefore, the V-HUB system must
deploy a VSAT system, which is a system that uses low power satellite communicationequipment that does not require trained and licensed personal to operate the terminal.

23

The VSAT system is constructed by terminals with satellite antenna, satellites andsatellite gateways. The terminal will be deployed on to the vehicle unit and the information
kiosk. The satellite gateway is an entity that will control the remote terminal and become thegateway to connect to the internet. In order to secure robust communication a backup thesatellite gateway is needed.
4) White space
The VHUB system may use the government specified frequency such as VHF. The VHUB
system dynamically finds/utilizes the available white space typically for long-range (10-17 km)
communications for isolated disaster areas. The use case may follow technical requirement of
VSAT and the specification can be developed in the future.
5) Cellular
The VHUB system may use mobile BTS (base transceiver station) for isolated areas. The
specification can be developed in the future.
4.3. Application interface
Application interface is defined as a communication interface among applications andmay include messaging, tracking, streaming and alerting.
1) Messaging
The messaging application is a general service platform. It may be used by citizens,
responders and volunteers. Note that the application is neither intended to be time sensitive
nor mission critical. The messaging interface is for asynchronous transfer of data such as binary,text, voice, image and video. This interface is widely used for application such as SMS, SOS
signaling, white board, public announcement, phone (E-call), conferencing and search/rescue.
The V-HUB system delivers messages among users. There are following four options in whichusers put their messages into the vehicle unit:a) Web service
The web service is the simplest fashion that does not require users to install any
application -just available at the pre-installed web browser. In order to host the service, thevehicle unit must have a web server and a database. In addition, the vehicle unit must show
the default web page whichever URLs users indicate.
b) Dedicated applications
The dedicated application is mainly for professional use. Though it requires anadditional installation, it may offer optimized user interface for professional users and also forchallenged users. Since the dedicated application does not limit protocol options, the vehicle
unit may also use the web server for it.

24c) Commercial applications
The commercial application should be user friendly. Users may use any social media
applications. For that service, the vehicle unit must emulate these commercial services andthis requires individual collaborations.
d) Email service
The last option of email service seems easy and friendly to users, but the fact is the
opposite. It requires users to modify email client settings and that information is obtained fromthe web service.
The last two options are not suitable as standard specifications.
The vehicle units share messages among each other. Since there remains limited timeto inter-vehicle communication, it is important to share messages efficiently using dedicatedmessaging daemon. The information kiosk shall have the same requirements and therefore
have the same functions with the vehicle unit because the vehicle unit also acts as theinformation kiosk at the evacuation site in some situation.
In order to protect messages from fraud acts, the vehicle unit uses encryption or digital
signature in the messages. Note that important is not concealment of information but proofof identity of message originators. Messaging interface is mainly supported by WLAN interface.
2) Tracking
The V-HUB system tracks victims, responders and vehicle units to locate and coordinate
the rescue team. The specification can be developed in the future.
3) Streaming
The streaming interface is for distributing video contents to users as live streaming andalso sending of recorded videos. Considering it is difficult for consumer devices to deploy
satellite antennas, an IP streaming method is required.
A video playout system at the satellite gateway will uplink the video content to theinformation kiosks and the vehicle units with satellite interface. Information kiosks and vehicle
units will receive the RF signals and encode it through an IP encoder that will multicast it to
the vehicle units and the web client on consumer devices and vehicle units.
Note that it has not covered the use case of phone call and video chat yet. Here it
assumes the use case of the command center streams down to victims and responders. If aninteractive streaming capability gets available, the command center, responders and victims
can talk among each other interactively according to appropriate designated policy. Even
drones can do streaming. The requirement may involve ISDB-T and DTN. This can be developedin the future.

254) Alerting
The alerting interface is for delivering critical information that requires robust andimmediate delivery. Here the information assumes Earthquake Early Warning Alert. The
Earthquake Early Warning Alert is an alert to provide awareness to humans and machines inminutes or seconds prior to the earthquake wave hits the location. A typical massive
earthquake accompanies large aftershock for few days or more. Hence, it is necessary to
deploy a robust communication line that can deliver the Earthquake Early Warning Alert evenwhen the terrestrial line has been damaged after the first shock. The alert will be distributed
to alert software servers from an alert management server which is located in the satellite
gateway. The alert software server, which is a software deployed in certain vehicle units orinformation kiosks will be responsible to distribute the alert to other vehicle units or consumer
devices. Of course, the alerting application should cover not only earthquake but also othernatural disasters and even man-made ones. The application should also use another network
such as beacon (V2X). This can be developed in the future.
4.4. Application
Application is a software enabling use cases. APT Report on Requirements ofInformation and Communication System Using Vehicle during Disaster (APT/ASTAP/REPT-21)
has a list of suggested use cases of V-HUB. Use cases can be classified by nature into four
categories below:a) SMS/Whiteboard

Non-real-time text communication
ex. Short Message Service and Whiteboard for
information sharing during disaster. etc.

b) Public announcement

Non-real-time/Real-time text distribution
ex. Delivering information by Web news. etc.

c) Phone(E-call)/Conferencing

Interactive voice/video communicationex. Emergency Call etc.

d) Search/Rescue

Non-real-time beacon communication
ex. Person Search Service. etc.

26

Chapter 5 ASTAP-29 DRMRS SESSION

Event Title:

Asia-Pacific Telecommunity Standardization Program-29 (ASTAP29)– Expert Group on Disaster Risk Management Relief System (EG DRMRS)
Project Title: International Collaborative Research on Disaster Response Model Using
Vehicle Communications (APT-Funded Project)
Duration:
11 months (25 January to 24 December 2017)
Date:
22-25 August 2017
Venue:
Amari Waterpark, Bangkok, Thailand
Participants: • APT-Member countries EG DRMRS• Representatives from Project Team:
Arlene Romasanta DICT, Philippines – Co-Project Lead of AIC
Yasubumi Chimura Chair of TTC Working Group on Connected car
Oki Electric Industry Co., Ltd. – Industry Collaborator
Masatoshi Mano TTC, Japan – Account Coordinator
Highlights:
1. There was a discussion on V-HUB Draft Specification where Philippines was one of the major
players. The version presented was an output of the workshop conducted in Batangas,
Philippines through the APT-funded project “International Collaborative Research on Disaster
Response Model on Vehicle Communications during Disasters”; The Telecommunication
Technology Committee (TTC) Japan, Department of Information and Communications
Technology (DICT) Philippines and Ateneo Innovation Center (AIC) conducted the workshop
last July 12-14, 2017.
2. Mr. Mano (TTC) proposed the Draft Recommendation on “Standard Specification ofInformation and Communication System using Vehicle during Disaster” (INP-06 (Rev.1)) basedon discussion by corresponding group.
3. There were comments to change the format into the Recommendation Document Style.
Chairman Maeda (TTC) proposed the APT Recommendation Style Information (TMP-02) to be
used as reference. EG DRMRS editing group changed the style of documents, confirmed new
Draft (TMP-02 (Rev.3). EG DRMRS agreed, adopted and forwarded to the WG NS the Draft
Recommendation on Standard Specification of Information and Communication System using
Vehicle during Disaster (TMP-02 Rev.3).
4. APT will begin the recommendation process after approval at plenary of ASTAP-29. During
the plenary, the proposed Draft Recommendation on Standard Specification of Information
and Communication System using Vehicle during Disaster was APPROVED. It will then be
forwarded to APT-Member Countries for their “YES” votes on the standard.

27

Chapter 6 Conclusion and Next Steps

The project, through its eleven months of implementation, was able to bring together
experts and industry practitioners from different APT-member countries to discuss and shareexperiences regarding disaster response and communications using vehicles. The academe,
government, and industry from Japan, Philippines, Thailand, Malaysia, and Papua New Guinea
came together to produce a draft standard specification document on the use of vehicles as
an information and communication system (VHUB) during disaster.
During the ASTAP29 last 22-25 August held in Bangkok, Thailand, the Draft
Recommendation on Standard Specification of Information and Communication System using
Vehicle during Disaster was APPROVED in the plenary. It was then circulated by the APTmember countries for their “YES” votes to adopt the standard and be implemented in the Asia
Pacific region.
To date, the APT through ASTAP is consolidating the vote forms from member countries
and will be subjected for assessment whether the standard will finally be adopted and later be
implemented. The Project Team will monitor the progress of the status of the adoption of thedraft recommendation and closely coordinate with APT for any feedback. The Project Team islooking at the possibility of pushing for another collaborative project for APT funding based on
the Call for Proposal that will be released. The proposal should be responsive on the priorities
identified in the Call and on the current pressing national problems commonly experienced by
APT-member countries.

28

ANNEX-1

Standard Specification

Information and Communication Systemusing Vehicle during Disaster23 August 2017

Annex 1

1

CONTENTS
1. Scope ...................................................................................................................... 4
2. References ............................................................................................................... 4
3. Terms and definition ................................................................................................. 4
3.1.

V-HUB system .................................................................................................... 4

3.2.

Device ................................................................................................................. 4

3.3.

Network interface ................................................................................................ 5

3.4.

Application interface............................................................................................ 5

3.5.

Application .......................................................................................................... 5

4. Abbreviations ........................................................................................................... 5
5. Conventions ............................................................................................................. 5
6. Network interfaces ................................................................................................... 5
6.1.

WLAN ................................................................................................................. 6

6.1.1. Description ........................................................................................................ 6
6.1.2. Technical requirement ....................................................................................... 6
6.1.3. Functional architecture specification ................................................................. 8
6.2.

Beacon (V2X) ..................................................................................................... 8

6.2.1. Description ........................................................................................................ 8
6.2.2. Technical requirement ....................................................................................... 9
6.2.3. Functional architecture specification ................................................................. 9
6.3.

Satellite ............................................................................................................. 10

6.3.1. Description ...................................................................................................... 10
6.3.2. Technical requirement ..................................................................................... 10
6.3.3. Functional architecture specification ............................................................... 12
6.4.

White space ...................................................................................................... 12

6.4.1. Description ...................................................................................................... 12
6.4.2. Technical requirement ..................................................................................... 12
6.4.3. Functional architecture specification ............................................................... 12
6.5.

Cellular.............................................................................................................. 12

6.5.1. Description ...................................................................................................... 12
6.5.2. Technical requirement ..................................................................................... 126.5.3. Functional architecture specification ............................................................... 12
7. Application interfaces ............................................................................................. 12
7.1.

Messaging ........................................................................................................ 12

7.1.1. Description ...................................................................................................... 12

Annex 12

7.1.2. Technical requirement ..................................................................................... 13
7.1.3. Functional architecture specification ............................................................... 14
7.2.

Tracking ............................................................................................................ 15

7.2.1. Description ...................................................................................................... 15
7.2.2. Technical requirement ..................................................................................... 15
7.2.3. Functional architecture specification ............................................................... 15
7.3.

Streaming ......................................................................................................... 15

7.3.1. Description ...................................................................................................... 15
7.3.2. Technical requirement ..................................................................................... 15
7.3.3. Functional architecture specification ............................................................... 16
7.4.

Alerting.............................................................................................................. 16

7.4.1. Description ...................................................................................................... 16
7.4.2. Technical requirement ..................................................................................... 17
7.4.3. Functional architecture specification ............................................................... 17
BIBLIOGRAPHY （Informative） ................................................................................ 19
APPENDIX (Informative) ............................................................................................. 20
APPENDIX-A. Example of VSAT terminal on vehicle unit .......................................... 20
APPENDIX-B. Example of alerting application ........................................................... 21
APPENDIX-C. Proactive V-HUB system .................................................................... 22
APPENDIX-D. Example of the pre-defined SSID of WLAN AP for disaster in japan .. 23

Annex 13

1. ScopeThis document defines the specification of information and communication systemusing vehicle during disaster in order to support the system requirements. The
specification covers technical requirements and functional architectures. The
specification does not cover protocol details (message format, message sequence,and etc.), conformance/interoperability testing, and operational guideline. They can be
developed in the future.
2. References[APT/ASTAP/REPT-21] Report APT/REPT-21(2016), “Requirements ofInformation and Communication System using Vehicle during Disaster”
3. Terms and definition
This document defines the following terms.
3.1. V-HUB system
V-HUB system is the entire information and communication system using vehicles*1during disaster. Note that it is not limited to vehicle unit. The V-HUB*2 system has two
types of interface; network interface for devices and application interface forapplications. The specification covers scenarios using vehicles to replace destroyed /broken communication infrastructure during disaster beyond V2V communications.
Note *1; The vehicle of V-HUB has engine or motor and battery, communication
unit.
Note *2; The HUB of V-HUB means information and communications
infrastructure.
Application(Use Case)

SMS
Whiteboard

PublicAnnouncement

Phone(E-call)
Conferencing

SearchRescueScope of the standard specification
Applicationinterface

Messaging

Network
interface

WLAN

DeviceSmartphone,
Tablet, PC

Tracking

Beacon(V2X)

Streaming

White
space

Satellite

Other mobile
deviceVehicleunit

Consumer device

Fig. 1 The V-HUB system
3.2. Device
Annex 1

4

Alerting

Cellular

Information
Kiosk

Device is defined as a hardware that serves as a communication network node andmay include consumer device, vehicle unit, and information kiosk. The consumer
device is off-the-shelf such as smartphone, PC, tablet and other mobile device.
A) Smartphone, Tablet, PC The computer device used for consumer.
B) Other mobile device

The mobile computer device out of A).

C) Vehicle unit

The vehicle unit can be factory-installed bymanufacturer and also carried-on by user.

D) Information Kiosk

The information kiosk may include a stationary serverat the evacuation site with internet access. The
information kiosk is usually maintained by designatedoperators.

3.3. Network interface
Network interface is defined as a communication interface among devices and may
include WLAN, beacon (V2X), satellite, white space and cellular.
3.4. Application interface
Application interface is defined as a communication interface among applications andmay include messaging, tracking, streaming and alerting.
3.5. Application
Application is a software enabling use cases. APT Report on Requirements ofInformation and Communication System Using Vehicle during Disaster(APT/ASTAP/REPT-21) has a list of suggested use cases of V-HUB. Use cases can
be classified by nature into four categories below:A) SMS/Whiteboard
Non-real-time text communication
ex. Short Message Service and Whiteboard for information sharing during disaster.
etc.
B) Public announcement
Non-real-time/Real-time text distribution
ex. Delivering information by Web news. etc.
C) Phone(E-call)/Conferencing
ex. Emergency Call etc.

Interactive voice/video communication

D) Search/Rescue
ex. Person Search Service. etc.

Non-real-time beacon communication

4. Abbreviations
AP
CRUD
SSID
STA
WLAN
VSAT system

Access Point
Create, Read, Update and Delete
Service Set Identifier
Station terminal
Wireless LAN
Very Small Aperture Terminal system

5. Conventions
None
6. Network interfaces

Annex 15

6.1. WLAN
6.1.1.

Description

WLAN has two major connection methods; infrastructure mode and ad-hoc mode. The
V-HUB system must support the infrastructure mode, because most of consumer offthe-shelf devices such as smartphones only support the infrastructure mode and the
V-HUB system must offer the service to such popular devices. Alternatively the V-HUB
system may additionally support ad-hoc mode for communications between vehicle
units. Since this is also achieved by infrastructure mode as mentioned below, the adhoc mode specification has been postponed. It does not mean the ad-hoc moderemains declined. This option can also be developed in the future.
The infrastructure mode has two functions; AP and STA. One WLAN AP serves
multiple connections to WLAN STAs. It is not supported to establish connection
between APs or between STAs. Since the consumer devices usually operate WLAN
STA as a standard setup, the vehicle unit must operate WLAN AP to connect to user
devices without any operation on the user side. In addition, the inter-vehiclecommunication also requires the AP-STA linkage. This means that the vehicle unit
must operate WLAN STA for relaying. This also benefits the vehicle unit to connect tothe internet access point and information kiosk at the evacuation site. As aconsequence, the vehicle unit must operate both WLAN AP and STA. There are threepotential options for this as follows:
Dual interfaces
Concurrent mode
Wi-Fi Direct
With dual interfaces or concurrent mode, the vehicle unit may operate both AP and
STA at the same time. The concurrent mode is to switch AP and STA periodically on
the single interface to emulate (pretend) the dual interfaces. This is a kind of proprietary
technology provided by many major WLAN chipset manufacturers. Though it looks thesimplest setup, it is not true actually. If there are several vehicles in the samecommunication vicinity, multiple APs are appeared. Since there is no linkage amongAPs, communication network is divided among APs even in the same communication
vicinity. This also induces a complication for users to choose one AP to connect. The
third option Wi-Fi Direct enables the interface to be AP or STA and not both at thesame time. If there is no AP, the interface gets AP. If there is AP, the interface gets
STA and connects to the existing AP. If existing APs are met, one random AP gets
STA and connects to the other AP. This mechanism virtually ensures a single AP in
the same communication vicinity and keeps the V-HUB system away from network
complication due to multiple APs that occurs in case of dual interface and concurrentmode.
In addition, it is quite opportunistic to practice inter-vehicle communication on the street.
In order to increase that opportunity, it will be highly recommended that the V-HUB
system support IEEE802.11ai of Fast Initial Link Setup (FILS) capability.
Note that this specification does not cover multi-hop ad-hoc routing, that is known as
VANET (Vehicular Ad-hoc Network), and DTN (Delay/Disruption Tolerant Network).
Both capabilities can be developed in the future.
6.1.2.
ID

Annex 1

Technical requirement
Technical requirement

6

Use case

N001

The V-HUB system shall enable the vehicle unit to haveboth WLAN AP and WLAN STA.

A, B, D

N002

The V-HUB system shall enable the vehicle unit todeactivate WLAN AP after a random time wait, while thevehicle unit identifies the presence of WLAN AP of theother vehicle unit.
Note: Wi-Fi Direct can be a solution for this.

A, B, D

N003

The V-HUB system shall enable the vehicle unit to use apre-defined SSID at WLAN AP.

A, B, D

N004

The V-HUB system shall enable the vehicle unit to operate
WLAN STA to automatically connect to the pre-defined
SSID of WLAN AP of another vehicle unit.
Note: IEEE802.11ai may apply for fast link setup.

A, B, D

N005

The V-HUB system shall enable the vehicle unit to operate
WLAN STA not to connect to its own WLAN AP while thesame vehicle unit activate WLAN AP.

A, B, D

N006

The V-HUB system shall enable the consumer device have A, B, D
WLAN STA.

N007

The V-HUB system shall enable the consumer device toA, B, D
operate WLAN STA to manually connect to the pre-defined
SSID of WLAN AP of the vehicle unit.
Note: IEEE802.11ai may apply for fast link setup.

N008

The V-HUB system shall enable the information kiosk tohave WLAN AP.

A, B, D

N009

The V-HUB system shall enable the information kiosk to
use a pre-defined SSID at WLAN AP.

A, B, D

N010

The V-HUB system shall enable the vehicle unit that
A, B, D
operates WLAN AP to operate WLAN STA to automaticallyconnect to the pre-defined SSID of WLAN AP of theinformation kiosk.
Note: IEEE802.11ai may apply for fast link setup.

Annex 17

6.1.3.

Functional architecture specification
Information Kiosk
APPre -defined SSID

Vehicle Unit
WLAN
AP

STA
Pre -defined SSID

Vehicle Unit
Consumer device
STA

WLAN
AP -> deactivated

STA

Fig. 2 Functional architecture of wireless LAN interface
6.2. Beacon (V2X)
6.2.1.

Description

The consumer device (pedestrian device) broadcasts a rescue message using
wireless beacon(s). The vehicle unit (including drone) relays the message to theinformation kiosk. After receiving the message at the information kiosk, the massage
will be used to make rescue map in the information kiosk. The rescue map shows
position and priority of people who needs support. Typical wireless media for the
beacon are 1) ARIB STD T109 (V2X) and 2) IoT using sub-giga band (IoT), because
communication distance and stability is better than higher band. Field trial to confirm
communication distance is carried out in the Philippines and it is reported to ASTAP.
The report shows that the vehicle unit can work to find victims and the information kiosk
can gather the victim information.
This system has three types of beacons. First beacon is an alert delivery beacon thatwill be sent by authorized organization. This beacon defines mode of this system andarea. If the alert delivery beacon shows disaster mode and certain area, consumer
devices that are in the certain area shift to disaster mode automatically. Before shiftingdisaster mode, the consumer devices stay in normal mode, so the pedestrian units canuse the beacon system for normal V2X communication and so on.
Second beacon is a rescue request beacon, and this rescue request beacon can besent only after shifting disaster mode. We can assume that the beacon can be sent byfour cases. First case is that the consumer device sends the beacon automatically.
Second case is victim sends the beacon by him/herself. Third case is other person

Annex 18

sends the beacon in order to call rescue team for rescuing victims. Fourth case is a
rescue team uses this beacon to share the information within other rescue team. The
rescue request beacon includes requirement information, personal information that isneeded, vital information, and METHANE information. METHANE is defined in NATO.
M means Major incident happens. E means Exact location. T means Types of incident,
H means kind of Hazard, A means Accessibility to the location. N means Number ofcasualties. E means Emergency services to rescue the casualties.
Third beacon is a rescue response beacon from rescue team to victim. This rescue
response beacon includes accepting time, estimated arrival time, and so on.
6.2.2.

Technical requirement

ID
N011

Technical requirement
The V-HUB system shall enable the rescue message tohave three types of beacon; alert delivery beacon, rescue
request beacon, and rescue response beacon.

Use case
B, D

N012

The V-HUB system shall use ARIB STD T109 (V2X) and/or
sub-giga band wireless IoT system (IoT) that carries the
rescue messages.
Note: ARIB STD T109 can be referred at[URL]http://www.arib.or.jp/english/html/overview/doc/5-STDT109v1_2-E1.pdf
The V-HUB system shall enable the consumer device tobroadcast and to receive the rescue message.

B, D

N014

The V-HUB system shall enable the vehicle unit to relay(receive and re-broadcast) the rescue message.

B, D

N015

The V-HUB system shall enable the information kiosk to
broadcast and to receive the rescue message.

B, D

N013

6.2.3.

Annex 1

Functional architecture specification

9

B, D

Information Kiosk
Receive the rescue message
V2X

IoT

V2X

IoT

Vehicle Units

Relay the rescue message
V2X

IoT

Consumer Device
V2X

IoT

Broadcast the rescue message

Fig. 3 Functional architecture of beacon interface
6.3. Satellite
6.3.1.

Description

Satellite Network Interface is used for providing robust communication line to othernetworks outside the V-HUB system.
In a typical regulatory environment, high power satellite communication requires a
trained and licensed person to operate the terminal. However, in a case of disasterobtaining such personal at the right site will be extremely difficult. Therefore the V-HUB
system must deploy a VSAT system, which is a system that uses low power satellite
communication equipment that does not require trained and licensed personal tooperate the terminal.
The VSAT system is constructed by terminals with satellite antenna, satellites andsatellite gateways. The terminal will be deployed on to the vehicle unit and theinformation kiosk. The satellite gateway is an entity that will control the remote terminal
and become the gateway to connect to the internet. In order to secure robust
communication a backup the satellite gateway is needed.
6.3.2.

Technical requirement

ID
N016

Technical requirement
The V-HUB system shall have the V-SAT system thatconsists of the information kiosks/the vehicle units,satellites, satellite gateways and the internet.

Use case
A, B, C, D

N017
N018

The V-HUB system shall have the satellite in the sky.
The V-HUB system shall have the satellite gateway
outside the disaster area that connects to the internet.

A, B, C, D
A, B, C, D

Annex 110

N019

The V-HUB system shall enable the satellite gateway tohave back up equipment including site diversity to avoid
service down time.

A, B, C, D

N020

The V-HUB system shall enable the information kiosk,
the vehicle unit and the satellite gateway to have aterminal with satellite antenna in order to connect to thesatellite.

A, B, C, D

N021

The V-HUB system shall enable the terminal to use thepre-assigned IP address.

A, B, C, D

N022

The V-HUB system shall enable the VSAT system todeliver the data between the information kiosk/the vehicle
unit and the internet.

A, B, C, D

N023

The V-HUB system shall enable the VSAT system tomaintain designated capacity.

A, B, C, D

Annex 111

6.3.3.

Functional architecture specification

V-SAT system
Satellite Gateway(Site diversity)
Information Kiosk
Vehicle Unit

Satellite Gateway

Terminal

Terminal

Pre-assigned
IP Address

Satellite Antenna

Pre-assigned
IP Address

Satellite

The Internet

Satellite Antenna

In the sky

Outside disaster area

Fig. 4 Functional architecture of satellite interface
6.4. White space
6.4.1.

Description

The VHUB system may use the government specified frequency such as VHF. The
VHUB system dynamically finds/utilizes the available white space typically for longrange (10-17 km) communications for isolated disaster areas. The use case may follow
technical requirement of VSAT and the specification can be developed in the future.
6.4.2.

Technical requirement

To be developed.
6.4.3.

Functional architecture specification

To be developed.
6.5. Cellular
6.5.1.

Description

The VHUB system may use mobile BTS (base transceiver station) for isolated areas.
The specification can be developed in the future.
6.5.2.

Technical requirement

To be developed.
6.5.3.

Functional architecture specification

To be developed. It will include the utilization of DTH (Direct to Home) satellite band.
7. Application interfaces
7.1. Messaging
7.1.1.

Description

The messaging application is a general service platform. It may be used by citizens,
responders and volunteers. Note that the application is neither intended to be time

Annex 112

sensitive nor mission critical. The messaging interface is for asynchronous transfer ofdata such as binary, text, voice, image and video. This interface is widely used for
application such as SMS, SOS signaling, white board, public announcement, phone(E-call), conferencing and search/rescue. The V-HUB system delivers messages
among users. There are following four options in which users put their messages into
the vehicle unit:
Web service
The web service is the simplest fashion that does not require users to install any
application - just available at the pre-installed web browser. In order to host theservice, the vehicle unit must have a web server and a database. In addition, thevehicle unit must show the default web page whichever URLs users indicate.
Dedicated applications
The dedicated application is mainly for professional use. Though it requires anadditional installation, it may offer optimized user interface for professional users
and also for challenged users. Since the dedicated application does not limit
protocol options, the vehicle unit may also use the web server for it.
Commercial applications
The commercial application should be user friendly. Users may use any social
media applications. For that service, the vehicle unit must emulate thesecommercial services and this requires individual collaborations.
Email service
The last option of email service seems easy and friendly to users, but the fact isthe opposite. It requires users to modify email client settings and that information is
obtained from the web service.
The last two options are not suitable as standard specifications.
The vehicle units share messages among each other. Since there remains limited timeto inter-vehicle communication, it is important to share messages efficiently using
dedicated messaging daemon. The information kiosk shall have the samerequirements and therefore have the same functions with the vehicle unit because thevehicle unit also acts as the information kiosk at the evacuation site in some situation.
In order to protect messages from fraud acts, the vehicle unit uses encryption or digital
signature in the messages. Note that important is not concealment of information but
proof of identity of message originators. Messaging interface is mainly supported by
WLAN interface.
7.1.2.

Technical requirement

ID
A001

Technical Requirement
The V-HUB system shall enable the vehicle unit to haveboth web server and database.

Use case
A,B,D

A002

The V-HUB system shall enable the consumer device tohave web client accessible by users.

A,B,D

A003

The V-HUB system shall enable the vehicle unit to have
DNS server to let the web server respond to any hostname request from the web client of the consumer device.

A,B,D

Annex 1

13

A004

The V-HUB system shall enable the web server of thevehicle to have web page to receive message andmessage query from the web client and show message tothe web client.

A,B,D

A005

The V-HUB system shall enable the web page to use
encryption or digital signature in the message based on
information from the web client.

B

A006

The V-HUB system shall enable the web page of thevehicle unit to have CRUD (create, read, update anddelete) function of the message at the database.

A,B,D

A007

The V-HUB system shall enable the vehicle unit to have
A,B,D
messaging daemons CRUD function of the message at the
database.

A008

The V-HUB system shall enable the messaging daemon of
the vehicle unit to have CRUD function of the message atthe database.

A,B,D

A009

The V-HUB system shall enable the messaging daemon of
the vehicle unit to communicate with the messaging
daemon of the other vehicle unit connected at the network
interface.

A,B,D

A010

The V-HUB system shall enable the messaging daemon of
the vehicle unit to send summary of messages tomessaging daemons.

A,B,D

A012

The V-HUB system shall enable the information kiosk has
the same requirements as the vehicle unit.

A,B,D

7.1.3.

Functional architecture specification
Vehicle Unit / Information Kiosk
DNS server

Web server
Web page
CRUD

Database

Messaging daemon
CRUD

Consumer device
Web client

Vehicle Unit
Messaging daemon

user

Fig. 5 Functional architecture of messaging interface

Annex 114

7.2. Tracking
7.2.1.

Description

The V-HUB system tracks victims, responders and vehicle units to locate andcoordinate the rescue team. The specification can be developed in the future.
7.2.2.

Technical requirement

To be developed.
The VHUB system shall enable the vehicle unit to track responders, vehicle units,
existing sensors (fitness trackers) for rescuers, health information/ body status (activity
tracker, body sensor data). Smartphone acts as intermediary. The VHUB system shallinvolve GIS map format, GPS (responders should have GPS), and data analytics.
7.2.3.

Functional architecture specification

To be developed.
7.3. Streaming
7.3.1.

Description

The streaming interface is for distributing video contents to users as live streaming andalso sending of recorded videos. Considering it is difficult for consumer devices todeploy satellite antennas, an IP streaming method is required.
A video playout system at the satellite gateway will uplink the video content to theinformation kiosks and the vehicle units with satellite interface. Information kiosks andvehicle units will receive the RF signals and encode it through an IP encoder that will
multicast it to the vehicle units and the web client on consumer devices and vehicle
units.
Note that it has not covered the use case of phone call and video chat yet. Here it
assumes the use case of the command center streams down to victims and responders.
If an interactive streaming capability gets available, the command center, responders
and victims can talk among each other interactively according to appropriate
designated policy. Even drones can do streaming. The requirement may involve ISDBT and DTN. This can be developed in the future.
7.3.2.

Technical requirement

ID
A013

Technical requirement
The V-HUB system shall enable the satellite gateway tohave a video playout system.

A014

The V-HUB system shall enable the vehicle unit and theinformation kiosk to have a decoder, an IP encoder, a
database and a web server.

C

A015

The V-HUB system shall enable the video playout system
to encode video signals into RF signals and transmit themto the decoder.

C

A016

The V-HUB system shall enable the decoder to receive theRF signals, decode them into video signals hand them tothe IP encoder.

C

Annex 1

15

Use caseCA017

The V-HUB system shall enable the IP encoder to receive
the video signals, encode them to IP video stream andstore them into the database.

C

A018

The V-HUB system shall enable the consumer device andthe vehicle unit to have a web Client to connect to the web
server.

C

A019

The V-HUB system shall enable the web server to retrieve
the IP video stream from the database and send it to theconnected web client on demand.

C

7.3.3.

Functional architecture specification
Satellite Gateway
Video Playout System

Vehicle Unit
Information Kiosk
Decoder
IP Encoder
Database
Web Server

Consumer device
Vehicle Unit
Web Clientuser

Fig. 6 Functional architecture of streaming interface
7.4. Alerting
7.4.1.

Description

The alerting interface is for delivering critical information that requires robust andimmediate delivery. Here the information assumes Earthquake Early Warning Alert.

Annex 1

16

The Earthquake Early Warning Alert is an alert to provide awareness to humans andmachines in minutes or seconds prior to the earthquake wave hits the location.
A typical massive earthquake accompanies large aftershock for few days or more.
Hence, it is necessary to deploy a robust communication line that can deliver the
Earthquake Early Warning Alert even when the terrestrial line has been damaged after
the first shock.
The alert will be distributed to alert software servers from an alert management serverwhich is located in the satellite gateway.
The alert software server, which is a software deployed in certain vehicle units orinformation kiosks will be responsible to distribute the alert to other vehicle units or
consumer devices.
Of course, the alerting application should cover not only earthquake but also othernatural disasters and even man-made ones. The application should also use othernetwork such as Beacon (V2X). This can be developed in the future.
7.4.2.

Technical requirement

ID
A019

Technical requirement
The V-HUB system shall enable the satellite gateway tohave an alert management server.

A020

The V-HUB system shall enable the vehicle unit and theinformation kiosk to have an alert software server.

B

A021

The V-HUB system shall enable the consumer device
and the vehicle device to have an alert software client.

B

A022

The V-HUB system shall enable the alert management
server to distribute Earthquake Early Warning Alert to thealert software servers.

B

A023

The V-HUB system shall enable the alert software server
to distribute Earthquake Early Warning Alert to the alert
software client.

B

7.4.3.

Annex 1

Functional architecture specification17

Use case
BSatellite Gateway
Alert Management Server

Vehicle Unit
Information Kiosk
Alert Software Server

Consumer device
Vehicle Unit
Alert Software Clientuser

Fig. 7 Functional architecture of alerting interface

Annex 1

18

BIBLIOGRAPHY （Informative）[IEEE 802.11ai] Draft IEEE802.11ai (2016), “Fast Initial Link Setup (FILS)”[DOD GPS] DOD Standard Global Position System (2001), “Global Position
System Standard Positioning Service Performance Standard”[RTCM GNSS] RTCM Standard SC104-STD (1998), “RTCM Recommended
Standard for GNSS (Global Navigation Satellite System)”[NATO MIMMS] NATO Standard MIMMS (2010), “The Major Incident Medical
Management and Support System”[ARIB STD-T109] ARIB Standard STD-T109 Version1.0 (2012), “700 MHz BANDINTELLIGENT TRANSPORT SYSTEMS”[ARIB ISDB-T] ARIB Standard STD-B24 (2009), “Data Coding and Transmission
Specification for Digital Broadcasting”

Annex 119

APPENDIX (Informative)
APPENDIX-A. Example of VSAT terminal on vehicle unit
VSAT Terminals for information kiosk can be a typical off the shelf product. However,
it is advised that VSAT terminal for vehicle unit implements certain specification suchas・Small antenna space factor
・Quick satellite acquisition process including auto track satellite antenna
・Low Electric power consumption

Annex 120

APPENDIX-B. Example of alerting application
Figure below shows arrival time of destructive quakes in the case of Tohoku-Pacific
Ocean Earthquake.
P-Wave : 6~8km/sec
S-Wave : 3~5km/Sec[Seismic intensity]

Event

Miyagi prf,
+2 secTime

Earthquake occurrence

14:46.40

P-Wave detection@ seismometers

14:46.40

Data of Early Warning
Distributed by JMA

14:46.48

Uplink from Satellite
Received by users

seismic center

Annex 1

21

S-Wave detected@ Fukushima

14:47.04

S-Wave detected@ Ibaraki

14:47.20

S-Wave detected
＠ Tokyo

14:47.51(+16 Sec)(+32 Sec)（+63 Sec）

APPENDIX-C. Proactive V-HUB system
The V-HUB system can be more proactive for forecasting next action and moves,maybe using big data infrastructure. This can be developed in the future.

Annex 122

APPENDIX-D. Example of the pre-defined SSID of WLAN AP for disaster injapan
The pre-defined SSID of WLAN AP for disaster is assigned by government or disasterorganization. The Japanese government assigned “00000JAPAN” to the pre-defined
SSID of WLAN AP for disaster .
____________

Annex 123

Annex 1

24

ANNEX-2

Annex 2

1

Annex 22

Annex 2

3

Annex 2

4

Annex 2

5Annex 2

6Annex 2

7

Annex 2

8Annex 2

9Annex 2

10Annex 3

List of Invited Presenters of the Workshop

Session 2 – 1 “V-HUB: Vehicles as Information Hubs during Disaster”
Kevin Sato
Toyota InfoTechnology Center, Japan

Annex 31

Annex 3

Entry Number:Presenter Name:
Title:

2

Session 2 - 1
Kevin Sato, Toyota InfoTechnology Center, Japan
V-HUB: Vehicles as Information Hubs during DisasterAnnex 3

3

Annex 3

4

Annex 3

5

Annex 3

6

Annex 3

7

Annex 3

8Annex 3

9Annex 3

10Annex 3

11____________

Annex 3

12

Annex 4

List of Invited Presenters of the Workshop
Presentation by invited Researchers
Session 2 - 4

Session 4 - 2

Session 4 - 3

Session 4 - 4

Session 4 - 5

Session 4 - 6

Session 4 - 7

Annex 4

“Resilient Post-Disaster Information Systems Using Delay Tolerant
Networks and UAVs as Data Ferries”
Nathaniel Libatique
Ateneo Innovation Center, Ateneo de Manila University, Philippines“AIC Demo on Resilient Post-Disaster Communication Using UAV and
DTN”
Daniel Lagazo
Ateneo Innovation Center, Ateneo de Manila University, Philippines“WiFi on Vehicle Cells: Inter-operation of Satellite, Drone and Vehicles”
Arunsak Nit-in
CAT Telecom Public Co., Ltd, Thailand“UNIVERSITI PUTRA MALAYSIA (UPM) in Collaboration with
Malaysian Technical Standards Forum Bhd. (MTSFB) Project on Disaster
Response and Vehicle Communication”
Aduwati Sali
Universiti Putra Malaysia, Malaysia“The Design and Operational Guidelines for DUMBONET Emergency
Networks”
Nisarat Tansakul
Internet Education and Research Laboratory (intERLab), Asian Instituteof Technology, Thailand“ICT Strategy for DRRM (The Philippine Setting)”
Alan Silor
Department of Information and Communications Technology, Philippines“V2X Applications by using VHUB”
Yoshiharu Doi
Toyota InfoTechnology Center, Japan1

Annex 4

Entry Number:Presenter Name:
Title:

2

Session 2 - 4Nathaniel Libatique, Ateneo Innovation Center, Philippines
Resilient Post-Disaster Information Systems Using Delay Tolerant
Networks and UAVs as Data Ferries

Annex 4

3

Annex 44

Annex 4

5

Annex 4

6

Annex 4

7

Annex 4

8Annex 4

9Annex 4

10

Annex 4

Entry Number:Presenter Name:
Title:

11

Session 4 - 2
Daniel Lagazo, Ateneo Innovation Center, Philippines
AIC Demo on Resilient Post-Disaster Communication Using UAV and DTN

Annex 4

Entry Number:Presenter Name:
Title:

12

Session 4 - 3
Arunsak Nit-in, CAT Telecom Public Co., Ltd, Thailand
WiFi on Vehicle Cells: Inter-operation of Satellite, Drone and Vehicles

Annex 4

13

Annex 4

14

Annex 4

Entry Number:Presenter Name:
Title:

15

Session 4 - 4
Aduwati Sali, Universiti Putra Malaysia, Malaysia
UNIVERSITI PUTRA MALAYSIA (UPM) in Collaboration with MalaysianTechnical Standards Forum Bhd. (MTSFB)Project on Disaster Response andVehicle Communication

Annex 4

16

Annex 4

17

Annex 418

Annex 4

19

Annex 4

20

Annex 4

21

Annex 4

Title:

Entry Number:Presenter Name:

22

Session 4 - 5
Nisarat Tansakul, Internet Education and Research Laboratory(intERLab)Asian Institute of Technology, Thailand
The Design and Operational Guidelines for DUMBONET Emergency
Networks

Annex 4

23

Annex 4

24

Annex 4

25

Annex 4

26

Annex 4

27

Annex 4

Title:

Entry Number:Presenter Name:

28

Session 4 - 6
Alan Silor
Department of Information and Communications Technology, Philippines
ICT Strategy for DRRM

Annex 429

Annex 430

Annex 4

31

Annex 4

32

Annex 4

Entry Number:Presenter Name:
Title:

33

Session 4 - 7
Yoshiharu Doi. Toyota Infotechnology Center, JapanV2X Applications by using VHUB

Annex 4

34

Annex 4

35

Annex 4

36

Annex 4

37

Annex 4

38

Annex 4

39

Annex 4

40

Annex 441____________

Annex 4

42Annex 5

List of Invited Presenters of the Workshop
Presentation by Guests
Session 2 - 2

Session 2 - 3

Session 2 - 3 - 2

Session 4 - 1

Annex 5“Restoration Support by Satellite Communications”
Tomoki Isaac Saso
SKY Perfect JSAT, Japan“HONDA, Origin of HONDA TECHNOLOGY for I-Trip”
Yasuo Oishi
Honda Motor, Japan“Approach for disaster prevention and reduction using Honda
telematics”
Akira Iihoshi
Honda Motor, Japan“JSAT Demo”
Tomoki Isaac Saso
SKY Perfect JSAT, Japan1

Annex 5

Entry Number:Presenter Name:
Title:

2

Session 2 - 2
Tomoki Isaac Saso, SKY Perfect JSAT
Restoration Support by Satellite Communications

Annex 5

3

Annex 5

4

Annex 55Annex 56

Annex 57

Annex 58Annex 5

9Annex 5

10Annex 5

11Annex 5

12Annex 5

13

Annex 5

14

Annex 515

Annex 5

Entry Number:Presenter Name:
Title:

16

Session 2 - 3
Yasuo Oishi, Honda Motor, Japan
HONDA, Origin of HONDA TECHNOLOGY for I-Trip

Annex 517Annex 518

Annex 5

19

Annex 520

Annex 5

21

Annex 5

22Annex 523

Annex 524

Annex 525

Annex 526

Annex 527

Annex 528

Annex 529Annex 5

Entry Number:Presenter Name:
Title:

30

Session 2 - 3 - 2
Akira Iihoshi, Honda Motor Co., Ltd., Japan
Approach for disaster preventionand reduction using Honda telematics

Annex 531

Annex 5

32

Entry Number:Presenter Name:
Title:

Session 4 – 1
Tomoki Isaac Saso, SKYPerfect JSAT, Japan
JSAT Demo____________

Annex 533