OneM2M-ARC-2013-0412-BRequest_Resource Architecture Proposal to address Broadcasting/Multicasting...

oneM2M-ARC-2013-0412-BRequest_ResourceArchitecture Proposal to address Broadcasting/Multicasting

Requirements

Group Name: WG2Source: Takanori Iwai, NEC, [email protected],

Norio 　 Uchida, NEC, [email protected], Ataru Kobayashi, NEC, [email protected], JaeSeung Song, NEC Lab Europe, [email protected] Swetina, NEC Lab Europe, [email protected]

Meeting Date: 2013-10-14Agenda Item: <agenda item topic name>

mailto:[email protected]





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<oneM2M-ARC-2013-0412-BRequest_Resource>

2


3

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

<oneM2M-ARC-2013-0412-BRequest_Resource>4

Use Case


5

• oneM2M-REQ-2013-0260R02Leveraging 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.

CC MobileAA WirelessBB Telecom

ABC Corp.ABC Corp.

XYZ Ltd.

Vehicles

Telematics Service Provider

oneM2M Service Provider

Communication NetworkService Providers (or operators)

Base Stations

Crash Point

! Detect an accident

Request to alert vehicles

Request to broadcast the alert message in specific areas

Broadcast the alert message

…… ……Post-conditions(Accident Occurred)

Pre-conditions(No Accident)

Crash

Alert & Directions

•Accident Location •Request to Go Slow ……

Broadcast Area

Requirements Approved• oneM2M-TS-Requirements-V-0.5.2

oneM2M Requirements Technical Specification <2013-08-23>

– Requirements to be addressed


6

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


7

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 communicationsMessagingLocationCharging and billing servicesDevice information and profilesConfiguration and management of devicesTriggering, monitoring of devicesSmall data transmissionGroup 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:

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


8

http://member.onem2m.org/Application/documentApp/documentinfo/?documentId=2913&fromList=Y


9

Architecture Proposal

Overview 　

Points to be standardized; M2M Broadcast (to send data to a group of devices in Underlying Networks ）


10

MTC-IWF

Mobile Network （ 3GPP ）

Tsp I/FCSE

M2M Service Platform (oneM2M)

ApplicationsApplications

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

OverviewThe 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

ZReference 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

Points to be standardized in oneM2M


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-037OSR-037

OSR-051OSR-051

OSR-052OSR-052


12


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


13

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


14


15


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


16


17


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


18

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<Document　number>

19


20


Sequence (Message Flow)

Basic Sequence (request from AE to send data)


21

CSE NSEAE

• 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

References


23

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

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 addressingMTC 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.


24

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.

App Server

Node B BSCUE

Um Gb

Node B RNCUE

Uu Iub

eNode B MMEUE

LTE-Uu S1-MME

CBCSCS

CBC-BSC

Iu-Bc

TcbMTC-IWF Tsp

SBc

Date post:	27-Dec-2015
Category:	Documents
Upload:	noah-jacobs
View:	220 times
Download:	3 times

OneM2M-ARC-2013-0412-BRequest_Resource Architecture Proposal to address Broadcasting/Multicasting...

Documents