Download oneM2M-ARC-2013-0412R01-BRequest_Resource

oneM2M-ARC-2013-0412-BRequest_Resource
Architecture Proposal to address Broadcasting/Multicasting
Requirements
Group Name: WG2
Source: Takanori Iwai, NEC, [email protected],
Norio Uchida, NEC, [email protected],
Ataru Kobayashi, NEC, [email protected],
JaeSeung Song, NEC Lab Europe, [email protected]
Joerg Swetina, NEC Lab Europe, [email protected]
Meeting Date: 2013-10-14
Agenda 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)
• Next steps
• References
– State of the art; broadcasting/multicasting capability in 3GPP
(SA1/SA2)
© 2013 oneM2M Partners
<oneM2M-ARC-2013-0412-BRequest_Resource>
2
Backgrounds
Looking back at oneM2M Use Case, Requirements
and LS (oneM2M -- 3GPP)
© 2013 oneM2M Partners
<oneM2M-ARC-2013-0412-BRequest_Resource>
3
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
• 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 Telematics Service Provider
vehicles around where a traffic accident has
just happened. The alerted vehicles could go
oneM2M Service Provider
slow or go another route to prevent the
second accident and to avoid the expected
traffic jam.
Communication Network
!
Service Providers (or operators)
Pre-conditions
(No Accident)
Post-conditions
(Accident Occurred)
Detect an accident
XYZ Ltd.
Request to alert vehicles
ABC
ABC Corp.
Corp.
Request to broadcast the alert message
in specific areas
BB Telecom
AA Wireless
Base Stations
Alert & Directions
CC Mobile
……
……
Crash Point
•Accident Location
•Request to Go Slow ……
Broadcast the alert message
Vehicles
Crash
Broadcast Area
© 2013 oneM2M Partners
<oneM2M-ARC-2013-0412-BRequest_Resource>
5
Requirements Approved
• oneM2M-TS-Requirements-V-0.5.2
oneM2M Requirements Technical Specification
<2013-08-23>
– Requirements to be addressed
Requirement ID
Description
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.
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.
OSR-052
Release
© 2013 oneM2M Partners
<oneM2M-ARC-2013-0412-BRequest_Resource>
6
Requirements Approved (Cont.)
– The other relevant requirements
Requirement ID
Description
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:









OSR-029
OSR-030
Release
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.
The M2M system shall be able to support sending common command(s) to each actuator or
sensor via a group.
The M2M system shall be able to support the management (i.e. addition, removal, retrieval
and update) of the membership of a group.
© 2013 oneM2M Partners
<oneM2M-ARC-2013-0412-BRequest_Resource>
7
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
Architecture Proposal
Overview
© 2013 oneM2M Partners
<oneM2M-ARC-2013-0412-BRequest_Resource>
9
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
BMSC
Tsp I/F
MTC-IWF
Z
Reference Point
CSE
X
Reference Point
Applications
Applications
Applications
In 3GPP,
In oneM2M,
A mobile network will expose APIs for a M2M service platform
to broadcast data.
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
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
• App – CSE  X reference point
• CSE – MTC-IWF  Z reference point
• Any other relevant interfaces
Nodes to implement additional features
Nodes to implement additional features
• MTC-IWF, CBC, BMSC, any other relevant nodes
• NSE CSF and any other relevant CSFs or nodes
© 2013 oneM2M Partners
<oneM2M-ARC-2013-0412-BRequest_Resource>
10
Points to be standardized in oneM2M
Application Entity
(AE)
▐
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
OSR-037
X Reference Point
▐
Functions to be implemented in CSE

Common Services
Entity(CSE)
Functions to receive a request from an AE.



Common Service
Functions（CSFs)

Functions to send a request to NSEs



Z Reference Point
Underlying Network
Service Entity(NSE)

▐
Authenticate the originator (=AE)
Validate and authorize the request
(Optional) Charge the request
Select appropriate NSEs (according to the request
OSR-052
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）

OSR-051
Reference message flow and parameters (=data elements) sent/received
through Z,
though request formats depend on NSEs.
© 2013 oneM2M Partners
<oneM2M-ARC-2013-0412-BRequest_Resource>
11
Architecture Proposal
X Reference Point
（A request from AE to CSE
© 2013 oneM2M Partners
<oneM2M-ARC-2013-0412-BRequest_Resource>
12
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 body
–
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
•
•
in the (encoding) format of NSE
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
–
Needs to confirm delivery to devices
–
Delivery method
–
Radio bearer
•
•
•
•
–
–
e.g. High, normal, low, Emergency
Binary flag (TRUE or FALSE)
CBS, MBMS, or any others
UMTS, LTE
NSE ID
Device Action
•
Beep, pop-up a message, etc.
© 2013 oneM2M Partners
<oneM2M-ARC-2013-0412-BRequest_Resource>
14
Architecture Proposal
Functions in Common Services Entity (CSE)
© 2013 oneM2M Partners
<oneM2M-ARC-2013-0412-BRequest_Resource>
15
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
Architecture Proposal
Z Reference Point
（A request from CSE to NSE
© 2013 oneM2M Partners
<oneM2M-ARC-2013-0412-BRequest_Resource>
17
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?)
•
–
Message body
•
–
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
•
•
in the (encoding) format of NSE
Geographic areas (multiple formats are supported)
•
•
•
–
e.g. 1: Disaster, 2: Security, 3: Medical affairs, 4: Transportation, 5: Energy, 6: Weather, 7: Advertising
Number of times, interval, and misc. (e.g. acceptable delay, timer)
Optional items
–
Priority
•
–
Needs to confirm delivery to devices
•
–
CBS, MBMS, or any others
Radio bearer
•
–
Binary flag (TRUE or FALSE)
Delivery method
•
–
e.g. High, normal, low, Emergency
UMTS, LTE
Device Action
•
Beep, pop-up a message, etc.
© 2013 oneM2M Partners
<Document number>
19
Architecture Proposal
Sequence (Message Flow)
© 2013 oneM2M Partners
<Document number>
20
Basic Sequence
(request from AE to send data)
AE
Request to send data
to a group of devices
in specific areas
NSE
CSE
• Check the request
• Select appropriate NSEs
• Convert the format of the request
Request to broadcast the data
Response (ACK)
Response
Execute Broadcasting
© 2013 oneM2M Partners
<Document number>
21
Next steps
© 2013 oneM2M Partners
<Document number>
22
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
© 2013 oneM2M Partners
<Document number>
23
References
© 2013 oneM2M Partners
<Document number>
24
State of the art; broadcasting/multicasting capability in 3GPP
(SA1/SA2)
© 2013 oneM2M Partners
<Document number>
25
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.
© 2013 oneM2M Partners
<Document number>
26
Architecture in 3GPP SA2 (TR 23.887)
•
The following solution has been proposed in 3GPP SA2, described in TR 23.887
– 8.1.3
– 8.1.3.1
Solutions
Solution : Group based messaging using cell broadcast
Um
UE
Node B
Uu
UE
CBCBSC
Gb
BSC
Tcb
Iub
Node B
RNC
UE
eNode B
App Server
Tsp
SCS
SBc
Iu-Bc
LTE-Uu
MTCIWF
CBC
S1-MME
MME
• 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.