8.5 Information Delivery service in the devastated area

8.5.1 Description

Background

• When a disaster occurs in the metro area, many victims require various kinds of information such as traffic, safety and evacuation area. However, it may be difficult to collect such information immediately and properly.

Description

• This is the use case of a M2M Service that transmits required information to the User Devices (UDs) of disaster victims immediately and automatically. Some of the information shall be maintained before a disaster happens.
• UD connects to the Wireless Gateways (WGs). The WGs properly provide the UDs with the information stored on its local DB to avoid the network congestion.
• When Disaster Sensor detect a serious disaster, the Service Provider multicasts the latest information which the victims need such as traffic congestion, locations of closest hospitals and evacuation area. The UDs receive and update the information automatically.
• After the disaster happens, the Service Provider continues to update the information according to the situation of traffic, safety and evacuation area as well as the data from Disaster Sensors and Equipment for public information.

8.5.2 Source

oneM2M-REQ-2012-0074R09 Use Case: Information Delivery service in the devastated area

8.5.3 Actors

• Service Provider has the aim to assist disaster victims by providing information to victims who have User Devices (UDs).
• Disaster Sensor shall detect a disaster and send the disaster detection to the Service Provider.
• Equipment shall send information to the Service Provider.
• The UDs shall receive the information from the Service Provider to support the disaster victim in emergency.
• Wireless Gateway (WG) can send the information from the Service Provider to the UDs by wireless connection (e.g. Wi-Fi, 3GPP) in an emergency.

8.5.4 Pre-conditions

• In times when disasters are not present (peace time), the Equipment collects information to be used for disaster situations (emergencies). The information is maintained in the DBs on the Service Provider's Disaster Information Network.
• The Service Provider shall have reliable, secure communication with the Disaster Sensor by checking the certificate issued by the Disaster Sensor.
• When receiving information regarding a disaster from the Service Provider, the WGs shall have the method to check if the information is reliable prior to distributing the information to UDs.
• UDs shall be able to receive the message from the Disaster Sensor by the other communication paths.
• The WG may be used for the other services for specific UDs in peace time. In case of emergency, every subscribed UDs should be able to receive the message from the Service Provider through the WG.
• Communication connections among UDs, WGs and Service Provider are established.
• When the network connectivity is available, the information on DB in the Service Provider-Disaster Information Network and local DBs in the WGs should be capable of being regularly synchronized and updated.

8.5.5 Triggers

The detection of a disaster (emergency) by the disaster sensor

8.5.6 Normal Flow

Normal flow for collecting information during a disaster

Figure 8.5.6-1 In Peace Time

Figure 8.5.6-2 In emergency

1. WGs request the updated information from the Service Provider in peace time repeatedly and stores the information in their local DBs.
2. Disaster Sensors send messages to start the processing flow of the information delivery service to the Service Provider if they detect the disaster trigger.
3. The Service Provider should be able to allow every UD to access to the Databases in the WGs and Service Provider's Disaster Information Network.
4. The Service Provider sends the latest information to UDs automatically. WGs can send the stored information on the local DB to the UDs in order to suppress the network congestion.

8.5.7 Alternative Flow

UDs can request their dedicated information from WGs. When the network connectivity between the WG and Service Provider is established, WGs can request from the Service Provider the dedicated information for the UDs (e.g. family safety and their refuge area, personal medical information).

8.5.8 Post-conditions

None

8.5.9 High Level Illustration

Figure 8.5.9-1 High Level System View

P8.5.10 otential Requirements

Table 8-1 Potential Requirements

Requirement ID	Classification	Requirement Text
HLR-088-a	Data reporting	The M2M System shall provide capabilities to Applications to update/synchronize Application specific databases between the Network Application and Gateway Application. Fulfilled by HLR-041.
HLR-087	Data reporting	The M2M System shall support transmission of Application specific data (e.g. tsunami and earthquake detection sensor data) from Devices and oneM2M external sources (e.g. ETWS data) to Applications in the Network. Fulfilled by HLR-046.
HLR-088-b	Data storage	A (wireless) Gateway shall be able to autonomously provide Devices that are attached via the LAN of the Gateway with trusted data that is locally stored in the Gateway. Trusted data and retrieval fulfilled by HLR-041 ACLs.
HLR-088-c	Data reporting	When the WAN connection between the Gateway and Service provider is not possible, the Gateway shall continue to provide data that is locally stored on the Gateway to authorized Devices.
HLR-089	Data reporting	A (wireless) Gateway shall be able to transmit data (e.g. disaster warnings) to M2M Devices that are connected to the Gateway and are authorized to receive the data. Fulfilled by HLR-010.
HLR-092-a	Security	A M2M Device that receives broadcast data from a (wireless) Gateway shall be able to verify that the (wireless) Gateway is authorized to broadcast the data (e.g. disaster warnings) and that the data is authentic. Fulfilled by HLR-185 and HLR-213.
HLR-092-b	Security	The M2M System shall provide capabilities to the Service Provider to enable/disable open access of M2M Devices to the Gateway. If access of M2M Devices to the Gateway is open any M2M Device shall be allowed to receive data from the Gateway. If access of M2M Devices to the Gateway is not open only authorized M2M Devices shall be allowed to receive data from the Gateway. Fulfilled by HLR-180, HLR-201