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>
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
© 2013 oneM2M Partners<oneM2M-ARC-2013-0412-BRequest_Resource>
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
© 2013 oneM2M Partners<oneM2M-ARC-2013-0412-BRequest_Resource>
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
© 2013 oneM2M Partners<oneM2M-ARC-2013-0412-BRequest_Resource>
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
© 2013 oneM2M Partners<oneM2M-ARC-2013-0412-BRequest_Resource>
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).
© 2013 oneM2M Partners<oneM2M-ARC-2013-0412-BRequest_Resource>
8
© 2013 oneM2M Partners<oneM2M-ARC-2013-0412-BRequest_Resource>
9
Architecture Proposal
Overview
Points to be standardized; M2M Broadcast (to send data to a group of devices in Underlying Networks )
© 2013 oneM2M Partners<oneM2M-ARC-2013-0412-BRequest_Resource>
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
© 2013 oneM2M Partners<oneM2M-ARC-2013-0412-BRequest_Resource>
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
© 2013 oneM2M Partners<oneM2M-ARC-2013-0412-BRequest_Resource>
12
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?)
© 2013 oneM2M Partners<oneM2M-ARC-2013-0412-BRequest_Resource>
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
© 2013 oneM2M Partners<oneM2M-ARC-2013-0412-BRequest_Resource>
14
© 2013 oneM2M Partners<oneM2M-ARC-2013-0412-BRequest_Resource>
15
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
© 2013 oneM2M Partners<oneM2M-ARC-2013-0412-BRequest_Resource>
16
© 2013 oneM2M Partners<oneM2M-ARC-2013-0412-BRequest_Resource>
17
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?)
© 2013 oneM2M Partners<oneM2M-ARC-2013-0412-BRequest_Resource>
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
© 2013 oneM2M Partners<Document number>
20
Architecture Proposal
Sequence (Message Flow)
Basic Sequence (request from AE to send data)
© 2013 oneM2M Partners<Document number>
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)
© 2013 oneM2M Partners<Document number>
22
References
© 2013 oneM2M Partners<Document number>
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.
© 2013 oneM2M Partners<Document number>
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
Top Related