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.eu Joerg Swetina, NEC Lab Europe, Joerg.Swetina@neclab.eu Meeting Date: 2013-10-14 Agenda Item: <agenda item topic name>

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)

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

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.

Use Case 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.

Requirements Approved oneM2M-TS-Requirements-V-0.5.2 oneM2M Requirements Technical Specification <2013-08-23> 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.

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.

LS (OneM2M  3GPP) oneM2M-REQ-2013-0380R06 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).

Architecture Proposal Overview　

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

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.

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

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?)

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.

Architecture Proposal Functions in Common Services Entity (CSE)

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

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

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?)

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.

Architecture Proposal Sequence (Message Flow)

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

Next steps

Change Request for TS-0001 oneM2M-ARC-2013-0413-BRequest_Resource_Description oneM2M-ARC-2013-0415-New_resources_for_NSE_CSF oneM2M-ARC-2013-0416-Resource_description_related_to_NSE-CSF oneM2M-ARC-2013-0418-Section_for_Z_reference_point

References

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

Service requirements for Machine-Type Communications (MTC); Stage 1 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.3 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.

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