1. oneM2M-ARC BRequest_Resource Architecture Proposal to address Broadcasting/Multicasting Requirements
Group Name: WG2
Source: Takanori Iwai, NEC, Norio　Uchida, NEC, Ataru Kobayashi, NEC, JaeSeung Song, NEC Lab Europe,
Joerg Swetina, NEC Lab Europe,
Meeting Date:
Agenda Item: <agenda item topic name>

2. Table of Contents Backgrounds Architecture Proposal Next steps
oneM2M Use Case, Requirements and LS (oneM2M – 3GPP)
Architecture Proposal
Overview
X Reference Point (AE  CSE: Request )
Functions in Common Services Entity (CSE)
Z Reference Point (CSE  NSE: Request)
Sequence (or information flow)
Next steps
References
State of the art; broadcasting/multicasting capability in 3GPP (SA1/SA2)

3. Backgrounds
Looking back at oneM2M Use Case, Requirements and LS (oneM2M -- 3GPP)　

4. Concept & Benefits
This mechanism allows a M2M service provider to take advantage of broadcasting/multicasting capability of underlying communication networks. It can suppress burst traffic in the communication network and provides a simple and cost-efficient way for the service provider to implement this neighbourhood alerting mechanism.
This mechanism involves authentication, charging and specifying geographic areas (in appropriate underlying networks) to broadcast data. Interworking between a M2M service platform and underlying networks is required to address needs of a wide spectrum of applications.
Benefit; It could offer flexible and tailored services to each application.

5. Use Case
oneM2M-REQ R02 Leveraging Broadcasting/Multicasting Capability of Underlying Networks -- Case of Neighbourhood Alerting on Traffic Accident --
This contribution illustrates the case that an automotive telematics service provider alerts vehicles around where a traffic accident has just happened. The alerted vehicles could go slow or go another route to prevent the second accident and to avoid the expected traffic jam.

6. Requirements Approved
oneM2M-TS-Requirements-V oneM2M Requirements Technical Specification < >
Requirements to be addressed
Requirement ID
Description
Release
OSR-037 
The M2M System shall enable a M2M Application to request to send data, in a manner independent of the Underlying Network, to the M2M Applications of a group of M2M Devices and M2M Gateways in geographic areas that are specified by the M2M Application.
OSR-051 
Depending on availability of suitable interfaces provided by the Underlying Network the M2M System shall be able to request the Underlying Network to broadcast / multicast data to a group of M2M Devices in a specified area.
OSR-052 
The M2M System shall be able to select an appropriate Underlying Network to broadcast or multicast data depending on the network’s broadcast/multicast support and the connectivity supported by the targeted group of M2M Devices/Gateways.

7. Requirements Approved (Cont.)
The other relevant requirements
Requirement ID
Description
Release
OSR-006  
The M2M System shall be able to reuse the services offered by underlying networks to M2M Applications and/or M2M Service Layer, by means of open access models (e.g. OMA, GSMA OneAPI framework). An example of available services is:
IP Multimedia communications
Messaging
Location
Charging and billing services
Device information and profiles
Configuration and management of devices
Triggering, monitoring of devices
Small data transmission
Group management
The set of features or APIs to be supported depends on the M2M Service Capabilities and access to available APIs.
OSR-029 
The M2M system shall be able to support sending common command(s) to each actuator or sensor via a group.
OSR-030 
The M2M system shall be able to support the management (i.e. addition, removal, retrieval and update) of the membership of a group.

8. LS (OneM2M  3GPP)
oneM2M-REQ R06 DRAFT LS on interfaces of oneM2M with Underlying Networks (Outgoing LS to 3GPP, Aug 2013)
oneM2M considers it beneficial to establish an on-going collaborative exchange of information between oneM2M and 3GPP.
Some of the features that oneM2M is working on that could require interworking with 3GPP Rel-12 and Rel-13 are listed below:
An M2M Service provider may request broadcasting/multicasting to multiple devices in the Operator Network (e.g. addressing a group of devices within a specified area for broadcast/multicasting of identical M2M data).

9. Architecture Proposal
Overview　

10. Points to be standardized; M2M Broadcast (to send data to a group of devices in Underlying Networks）
Overview
The whole mechanism should be standardized which involves authentication, charging and specifying geographic areas (in appropriate underlying networks) to broadcast data. Interworking between a M2M service platform and underlying networks is required to address needs of a wide spectrum of applications.
 Benefit; It could offer flexible and tailored services to each application.
Mobile Network（3GPP）
M2M Service Platform (oneM2M)
CBC
New I/F Z
Reference Point X
Reference Point
Tsp I/F
Applications
MTC-IWF
CSE
Applications
BMSC
Applications
In 3GPP,
A mobile network will expose APIs for a M2M service platform to broadcast data.
Interfaces to be newly added or extended with additional parameters
CSE – MTC-IWF  Tsp or new one
MTC-IWF – CBC/MBMS  new interface
Any other relevant interfaces
Nodes to implement additional features
MTC-IWF, CBC, BMSC, any other relevant nodes
In oneM2M,
A M2M service platform will be a broker/agent between apps and underlying networks to broadcast data.
Interfaces to be newly added or extended with additional parameters
App – CSE  X reference point
CSE – MTC-IWF  Z reference point
Any other relevant interfaces
Nodes to implement additional features
NSE CSF and any other relevant CSFs or nodes

11. Points to be standardized in oneM2M
Interface for AE to request to send a data to a group of devices in specific geographic areas (AE  CSE)
Common request format (?)
Dedicated request format for this functionality
Application Entity
(AE)
OSR-037
X Reference Point
Functions to be implemented in CSE
Functions to receive a request from an AE.
Authenticate the originator (=AE)
Validate and authorize the request
(Optional) Charge the request
Functions to send a request to NSEs
Select appropriate NSEs (according to the request parameters and capability of NSEs)
Transfer the request in the suitable form to the selected NSEs.
(Optional) Accept the receipt from the NSE
(Optional?) Functions to query broadcasting/multicasting capability of a NSE
Common Services Entity(CSE)
Common Service
Functions（CSFs)
OSR-052
Z Reference Point
Underlying Network
Service Entity(NSE)
OSR-051
Interface for CSE to request to broadcast/multicast (CSE  NSE）
Reference message flow and parameters (=data elements) sent/received through Z, though request formats depend on NSEs.

12. Architecture Proposal
X Reference Point
（A request from AE to CSE

13. Common request format (expected)
Destination ID of CSE
ID defined by oneM2M (= CSE-ID? and/or M2M-Node-ID?)
Source ID of AE
ID defined by oneM2M (= App-Inst-ID? and/or M2M-Node-ID?)

14. Dedicated request format (for this functionality)
Mandatory items
Message body
in the (encoding) format of NSE
Geographic areas (multiple formats are supported)
Area ID (defined by oneM2M?)
Naïve method … specify a circle (center , radius), ellipse, rectangle, polygon, belt with latitudes and longitudes
Group ID supported by CSE
Duration
Number of times, interval, and misc. (e.g. acceptable delay, timer)
Optional items
Message Category (ID?)
e.g. 1: Disaster, 2: Security, 3: Medical affairs, 4: Transportation, 5: Energy, 6: Weather, 7: Advertising
Priority
e.g. High, normal, low, Emergency
Needs to confirm delivery to devices
Binary flag (TRUE or FALSE)
Delivery method
CBS, MBMS, or any others
Radio bearer
UMTS, LTE
NSE ID
Device Action
Beep, pop-up a message, etc.

15. Architecture Proposal
Functions in Common Services Entity (CSE)

16. List of functions Functions to receive a request from an AE
Authenticate the originator (=AE)
Validate and authorize the request (from technical and contractual aspects)
(Optional) Charge the request
Functions to send a request to NSEs
Select appropriate NSEs (according to the request parameters and capability of NSEs)
Transfer the request in the suitable form to the selected NSEs. It may involve format conversion.
(Optional) Accept the receipt from the NSE
(Optional?) Functions to query broadcasting/multicasting capability of a NSE

17. Architecture Proposal
Z Reference Point
（A request from CSE to NSE

18. Common request format (expected)
Destination ID of NSE
ID defined and shared by oneM2M and 3GPP (?)
Source ID of CSE
ID defined by oneM2M (= CSE-ID? and/or M2M-Node-ID?)

19. Dedicated request format (for this functionality)
Mandatory items
Message Category (ID?)
e.g. 1: Disaster, 2: Security, 3: Medical affairs, 4: Transportation, 5: Energy, 6: Weather, 7: Advertising
Message body
in the (encoding) format of NSE
Geographic areas (multiple formats are supported)
Area ID (defined by NSE)
Naïve method … specify a circle (center , radius), ellipse, rectangle, polygon, belt with latitudes and longitudes
NSE-specific method (e.g. Group ID)
Duration
Number of times, interval, and misc. (e.g. acceptable delay, timer)
Optional items
Priority
e.g. High, normal, low, Emergency
Needs to confirm delivery to devices
Binary flag (TRUE or FALSE)
Delivery method
CBS, MBMS, or any others
Radio bearer
UMTS, LTE
Device Action
Beep, pop-up a message, etc.

20. Architecture Proposal
Sequence (Message Flow)

21. Basic Sequence (request from AE to send data)
NSE
Request to send data to a group of devices in specific areas
Check the request
Select appropriate NSEs
Convert the format of the request
Request to broadcast the data
Response (ACK)
Response
Execute Broadcasting

22. Next steps

23. Change Request for TS-0001
oneM2M-ARC BRequest_Resource_Description
oneM2M-ARC New_resources_for_NSE_CSF
oneM2M-ARC Resource_description_related_to_NSE-CSF
oneM2M-ARC Section_for_Z_reference_point

24. References

25. State of the art; broadcasting/multicasting capability in 3GPP (SA1/SA2)

26. Service requirements for Machine-Type Communications (MTC); Stage 1
Service requirements for Machine-Type Communications (MTC); Stage 1 (3GPP TS )
3GPP SA1 has defined the requirements below in TS
Group based addressing
MTC Feature Group Based Addressing is intended for use with a MTC Group for which the network operator wants to optimize the message volume when many MTC Devices need to receive the same message.
For the Group Based Addressing MTC Feature:
- The network shall provide a mechanism to send a broadcast message within a particular geographic area, e.g. to wake up the MTC Devices that are members of that MTC Group; only MTC Devices of the target group configured to receive the broadcast message will recognize it.
Note 1: The geographic area for the broadcast may be a cell sector, a cell or a group of cells.
Note 2: Verification of receipt of a broadcast message is not necessary.

27. Architecture in 3GPP SA2 (TR 23.887)
The following solution has been proposed in 3GPP SA2, described in TR
8.1.3 Solutions
Solution : Group based messaging using cell broadcast
Sending a group message over the Tsp reference point
With this solution a group message is received by the MTC-IWF over the Tsp interface containing group identification, geographic information and group message information, optionally the applicable RATs, optionally the number of times and frequency/rate to broadcast the trigger/message.
Indiscriminate use of cell broadcast for group messaging could potentially cause a flood of signalling when high amounts of devices respond to the cell broadcast group message at (almost) the same time, which could cause problems for both the mobile network operator and the MTC application owner. To spread the responses of the triggered devices in time, a time window over which the responses should be randomized may be included in the group message.