12.7 Leveraging Broadcasting/ Multicasting Capabilities of Underlying Networks

12.7.1 Description

This use case illustrates that an automotive telematics (Application) service provider XYZ Ltd. alerts vehicles around where a traffic accident has just happened. The alerted vehicles could go slow or go another route to prevent a second accident and to avoid the expected traffic jam.

In this case, the automotive telematics service provider XYZ Ltd. takes advantage of broadcasting/multicasting capability of underlying communication networks. Some kinds of communication networks (in particular, a mobile communication network) have the capability to broadcast/multicast a message in specific areas. Utilizing this capability, XYZ Ltd. can alert at once all the relevant vehicles within a specific region. This approach can avoid burst traffic in the communication network and provides a simple and cost-efficient way for XYZ Ltd. to implement this neighbourhood alerting mechanism.

Note

Ordinary unicast messaging mechanism is inadequate here. The alert messages shall be delivered in a timely manner to all the relevant vehicles within a specific region. XYZ Ltd. therefore needs to select the relevant vehicles that should receive the alert messages according to their current registered location (It needs continuous location management of vehicles). Moreover the underlying communication network has to route large number of unicast messages with very short delay.

However it is hard for XYZ Ltd. to utilize broadcasting/multicasting functionality of underlying networks directly which can vary with kinds of communication networks (e.g. 3GPP, 3GPP2, WiMAX or Wi-Fi).

A oneM2M service provider ABC Corp. facilitates this interworking between XYZ Ltd. and a variety of communication network service providers (or operators). ABC Corp. exposes unified/standardized interfaces to utilize broadcasting (or multicasting) capability of communication networks. ABC Corp. authenticates the requester (=XYZ Ltd.), validates and authorizes the request, then calls the corresponding function of the appropriate communication networks.

Note

There are many other scenarios in which broadcasting/multicasting capability of underlying communication networks provides significant benefit in a M2M system. For example,
- Warning about a crime incident - When a security firm detects a break-in at a house, it sets off all neighbourhood burglar alarms and alerts the M2M Application on the subscribed users' cellular phones around there. - Monitoring a water delivery system - When a water-supply corporation detects a burst of a water pipe, it remotely shuts off the water supply valves in that block, and alerts the M2M Application on the subscribed users' cellular phones around there.

The potential requirements in this contribution cover the above and all similar use cases, too.

12.7.2 Source

oneM2M-REQ-2013-0260R02 Leveraging Broadcasting - Multicasting Capability of Underlying Networks

12.7.3 Actors

• The automotive telematics service provider: XYZ Ltd.
  It provides automotive telematics service as a M2M application.
• The oneM2M service provider: ABC Corp.
  It provides a common platform to support diverse M2M applications and services.
• The communication network service providers (or operators): AA Wireless, BB Telecom and CC Mobile
  They operate communication networks.
  Some of them have the capability to broadcast/multicast a message in specific areas. The broadcasting/multicasting capability is available for external entities.
• The vehicles:
  They have communication capability as M2M devices, and have user interfaces (e.g. displays, audio speakers) or actuators to control driving.

Note

roles are distinct from actors. For example, the oneM2M service provider role may be performed by any organization that meets the necessary standardization requirements, including MNOs.

12.7.4 Pre-conditions

The vehicles are able to communicate in one or more communication networks.

12.7.5 Triggers

The automotive telematics service provider XYZ Ltd. detects a traffic accident.
How it detects the accident and captures details of the accident is out of scope of this use case.

12.7.6 Normal Flow

1. XYZ Ltd. estimates the location and impact of the accident to specify the area in which all the relevant vehicles should be alerted.
2. XYZ Ltd. requests oneM2M service provider ABC Corp. to alert subscribed vehicles in the specified area.
   • That request encapsulates the alert message (payload) and alert parameters (options).
     • The request contains the payload to be delivered to vehicles. It can contain for example the alert level (how serious and urgent), the location and time of the accident, and directions to the driver (e.g. go slow or change routes).
     • The request also defines targeted receivers of the message and specifies alert options. They can contain for example the area to be covered, the type of devices to be alerted, the option whether the alerting should be repeated, the repetition interval, and stopping conditions.
3. ABC Corp. receives the alert request from XYZ Ltd. It authenticates the requester (=XYZ Ltd.), validates and authorizes the request. When the request from XYZ Ltd. does not have alert parameters, ABC Corp. analyses the alert message to determine broadcast parameters. Then it chooses appropriate communication network service providers (or operators) to meet the alert request from XYZ Ltd.

4. ABC Corp. requests AA Wireless and CC Mobile to broadcast the alert message in the specified area.

   • That request encapsulates the alert message (payload) and broadcast parameters.
     • The alert message is the payload to be delivered to vehicles. The contents are the same as from ABC Corp. but the format and encoding of the message may be different from AA Wireless and CC Mobile.
     • The broadcast parameters define targeted receivers of the message and specify broadcast options. They can contain for example the area to be covered, the type of devices to be alerted, the option whether the broadcast should be repeated, the repetition interval, and stopping conditions. The format of the parameters can be different between AA Wireless and CC Mobile.

   ABC Corp. may need to cover a part of the broadcasting functions for some communication network service providers. For example, if CC Mobile does not have the functionality to repeat broadcasting periodically, ABC Corp. repeatedly requests CC Mobile to broadcast the message, in order to meet the request from XYZ Corp.

12.7.7 Alternative Flow

None

12.7.8 Post-conditions

The vehicles around where the traffic accident has just happened are properly alerted about the accident.

12.7.9 High Level Illustration

Figure 12.7.9-1 High level illustration 1

Figure 12.7.9-2 High Level Illustration 2

12.7.10 Potential Requirements

1. oneM2M System SHALL be able to leverage broadcasting and multicasting capability of Underlying Networks.
2. oneM2M System SHALL enable a M2M Application to request to broadcast/multicast a message in specific geographic areas.
   • That request SHALL encapsulate the message (payload) from the M2M Application, relevant parameters (options) and optionally credentials for authentication and authorization.
   • The M2M System SHALL support that request to be independent of the types of the Underlying Networks.
3. oneM2M System SHALL support mechanisms for Authentication, Authorization and Accounting of an M2M Application to request to broadcast/multicast a message.
   • oneM2M System SHALL authenticate the M2M Application.
   • oneM2M System SHALL validate and authorize the request.
   • oneM2M System SHALL support accounting on handling the request.
4. oneM2M System SHALL be able to select appropriate underlying networks to broadcast/multicast a message in specified geographic areas according to capability/functionality of those networks.
5. oneM2M System SHALL be able to receive information on broadcasting/multicasting capability/functionality of each underlying network.
6. oneM2M System SHALL be able to indicate towards the Underlying Network that a message needs to be broadcasted/multicasted and to determine its broadcast parameters (or multicast parameters), e.g. the area to be covered, the type of devices to be alerted, the option whether the broadcast should be repeated, the repetition interval, and stopping conditions.
7. oneM2M System SHALL be able to analyse a message from a M2M Application to determine broadcast parameters.
8. Interfaces to address the above requirements SHALL be standardized by oneM2M.

Note

roles are distinct from actors. An actor may play one or more roles and the economic boundary conditions of a particular market will decide which role(s) will be played by a particular actor.