1. oneM2M-ARC-2013-0412-BRequest_Resource Architecture Proposal to address Broadcasting/Multicasting Requirements Group Name: WG2 Source: Takanori Iwai, NEC, t-iwai@hx.jp.nec.com, Norio Uchida, NEC, n-uchida@cq.jp.nec.com, Ataru Kobayashi, NEC, a-kobayashi@df.jp.nec.com, JaeSeung Song, NEC Lab Europe, JaeSeung.Song@neclab.eut-iwai@hx.jp.nec.comn-uchida@cq.jp.nec.coma-kobayashi@df.jp.nec.comJaeSeung.Song@neclab.eu Joerg Swetina, NEC Lab Europe, Joerg.Swetina@neclab.euJoerg.Swetina@neclab.eu Meeting Date: 2013-10-14 Agenda Item:

2. Table of Contents Backgrounds – 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) References – State of the art; broadcasting/multicasting capability in 3GPP (SA1/SA2) © 2013 oneM2M Partners 2

3. © 2013 oneM2M Partners 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. © 2013 oneM2M Partners 4

5. Use Case © 2013 oneM2M Partners 5 oneM2M-REQ-2013-0260R02 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-0.5.2 oneM2M Requirements Technical Specification – Requirements to be addressed © 2013 oneM2M Partners 6 Requirement IDDescriptionRelease 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 © 2013 oneM2M Partners 7 Requirement IDDescriptionRelease 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-2013-0380R06 DRAFT LS on interfaces of oneM2M with Underlying Networks (Outgoing LS to 3GPP, Aug 2013) oneM2M-REQ-2013-0380R06 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: 1.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). © 2013 oneM2M Partners 8

9. © 2013 oneM2M Partners 9 Architecture Proposal Overview

10. Points to be standardized; M2M Broadcast (to send data to a group of devices in Underlying Networks ） © 2013 oneM2M Partners 10 MTC-IWF Mobile Network （ 3GPP ） Tsp I/F CSE M2M Service Platform (oneM2M) Applications CBC 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 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. X Reference Point Z Reference Point BMSC New I/F 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 © 2013 oneM2M Partners 11 Application Entity (AE) Application Entity (AE) Common Services Entity(CSE) ▐ 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 ▐ 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 ▐ 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. Underlying Network Service Entity(NSE) Underlying Network Service Entity(NSE) Z Reference Point X Reference Point Common Service Functions （ CSFs) Common Service Functions （ CSFs) OSR-037 OSR-051 OSR-052

12. © 2013 oneM2M Partners 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?) © 2013 oneM2M Partners 13

14. 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 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) – Device Action Beep, pop-up a message, etc. 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 – NSE ID © 2013 oneM2M Partners 14

15. © 2013 oneM2M Partners 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 © 2013 oneM2M Partners 16

17. © 2013 oneM2M Partners 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?) © 2013 oneM2M Partners 18

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) – Device Action Beep, pop-up a message, etc. 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 © 2013 oneM2M Partners 19

20. © 2013 oneM2M Partners 20 Architecture Proposal Sequence (Message Flow)

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

22. © 2013 oneM2M Partners 22 References

23. © 2013 oneM2M Partners 23 State of the art; broadcasting/multicasting capability in 3GPP (SA1/SA2)

24. Service requirements for Machine-Type Communications (MTC); Stage 1 (3GPP TS 22.368) 3GPP SA1 has defined the requirements below in TS 22.368 – 7.2.14.3Group 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. © 2013 oneM2M Partners 24

25. Architecture in 3GPP SA2 (TR 23.887) The following solution has been proposed in 3GPP SA2, described in TR 23.887 – 8.1.3Solutions – 8.1.3.1Solution : 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.