Transcript oneM2M-ARC-2013-0414R01

oneM2M-ARC-2013-0414-Network_Optimization_Discussion_Doc
Discussion oneM2M WG2 contributions
to address Network Optimization
Group Name: WG2
Source: Takanori Iwai, NEC, ([email protected])
Tetsuo Inoue, NEC, ([email protected])
Ataru Kobayashi, NEC, ([email protected])
JaeSeung Song, NEC Lab Europe, ([email protected])
Joerg Swetina, NEC Lab Europe, ([email protected])
Masaharu Hattori, KDDI, ([email protected])
Meeting Date: 2013-10-14
Agenda Item: <agenda item topic name>
Agenda
•
Backgrounds
– oneM2M Use Case, Requirements and LS (oneM2M  3GPP)
•
Drafting Contributions
–
–
–
–
–
•
•
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; M2M network optimization capability in 3GPP (SA1/SA2)
Page 2
Backgrounds
Looking back at oneM2M Use Case, Requirements
and LS (oneM2M -- 3GPP)
Page 3
Concept & Benefits
• This mechanism allows a M2M service provider to take advantage of
network optimization capability of underlying communication networks. It
can optimize connection and mobility managements in the
communication network based on the characteristics of device for
communication and mobility.
• This mechanism involves authentication, charging, detecting
characteristics of device for communication and mobility by M2M service
provider and notifying the characteristics to appropriate underlying
network. Interworking between M2M service platform and underlying
network is required.
– Benefit; It could offer to reduce load and improve reliability of
underlying network.
Page 4
Use case (1)
• Optimized M2M interworking with mobile networks
(Optimizing connectivity management parameters)
This use case illustrates detection of a change of data transmission interval on service layer
and notification to the mobile network by interworking between the M2M service platform
and the mobile network.
1
1
Page 5
Use case (2)
• Optimized M2M interworking with mobile networks
(Optimizing mobility management parameters)
This use case illustrates detection of a change of mobility characteristics on service layer
(through the M2M Application) and notification (through the oneM2M Service Capabilities)
to the mobile network by interworking between the M2M service platform and the mobile network.
1
1
Page 6
Requirements Approved
•
oneM2M-TS-Requirements-V-0.5.2
oneM2M Requirements Technical Specification
– Requirements to be addressed
Requirement ID
OPR-005
OPR-006
Page 7
<2013-08-23>
Description
The M2M System shall be able to exchange information with M2M
Applications related to usage and traffic characteristics of M2M Devices
or M2M Gateways by the M2M Application. This information includes
the following features for a M2M Device:
- Time controlled
devices to send or receive data only during defined time intervals
Note: “Low mobility” and “Time controlled” are equivalent to the MTC
Features specified in [i.x] (section 7.2 of 3GPP TS 22.368)
Depending on availability of suitable interfaces provided by the
Underlying Network the M2M System shall be able to provide
information related to usage and traffic characteristics of M2M Devices
or M2M Gateways to the Underlying Network.
Release
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:
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.
Page 8
Release
LS (OneM2M  3GPP)
•
oneM2M-TP-2013-0307R01
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 and a Network Operator may exchange information
related to characteristics of M2M Devices or M2M Gateways, such as indications
for small data, transmission scheduling parameters, mobility characteristics, etc..
Page 9
Drafting contributions,
Overview
Page 10
Points to be standardized;
Network Optimize（exchange information related to characteristics of M2M Devices）
Overview
The whole mechanism should be standardized which involves authentication, charging, detecting characteristics of
device for communication and mobility by M2M service provider and notifying the characteristics to appropriate
underlying network. Interworking between M2M service platform and underlying network is required.  Benefit; It could
offer to reduce load and improve reliability of underlying network.
Mobile NW（3GPP）
HSS
Service PF（oneM2M）
S6m
Tsp I/F
MME
T5b
MTC-IWF
Z
Reference Point
CSE
X
Reference Point
Applications
Applications
Applications
In 3GPP,
In oneM2M,
A mobile network will change parameters and process for
specified device based on the information from service
platform for transition of device’s behavior.
A M2M service platform will detect or receive transition of
device’s behavior from apps and inform underlying network
the information such as mobility or connectivity
characteristics.
Interfaces to be newly added or extended with additional
parameters
•
CSE – MTC-IWF  Tsp or new one
•
MTC-IWF – MME/HSS  T5b, S6m
•
Any other relevant interfaces
Nodes to implement additional features
•
MTC-IWF, MME, HSS, any other relevant nodes
Page 11
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 notify the usage and traffic
characteristics of M2M devices (AE  CSE)
Application Entity
(AE)
X Reference Point
Common Services
Entity(CSE)
 Common request format (?)
 Dedicated request format for this functionality
OPR-005
▐ 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
Common Service
Functions（CSFs)



Z Reference Point
Underlying Network
Service Entity(NSE)
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
OPR-006
▐ Interface for CSE to request to notify the usage and traffic
characteristics of M2M devices (CSE  NSE）
 Reference message flow and parameters (=data elements)
sent/received through Z,
though request formats depend on NSEs.
Page 12
Drafting contributions,
X Reference Point
（A request from AE to CSE）
Page 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?)
Page 14
Dedicated request format for this functionality
•
•
Mandatory items
– Device ID
• Identifier of target device for transition of behavior (characteristics of device’s behavior).
ex) IMSI or External ID of 3GPP.
Optional items
– Mobility characteristics
• Stop, Low Mobility, High Mobility
• Mobility area, Destination
– Connectivity characteristics
• Average bandwidth of usage
• Average time of communication (or manipulation)
• Average interval between communications
• Schedule of communications
• Available delay time
– Device power consumption information
• Remained power (percentage)
• Power saving mode, Power charging
– Other options
• Booted application information
• Radio signal reception information
Page 15
Drafting contributions,
Functions in Common Services Entity (CSE)
Page 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) Charge the request and/or charge based on execution condition of NSE
Page 17
Drafting contributions,
Z Reference Point
A request from CSE to NSE
Page 18
Common request format
•
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?)
Page 19
Dedicated request format for this functionality
•
•
Mandatory items
– Device ID
• Identifier of target device for transition of behavior (characteristics of device’s behavior).
ex) IMSI or External ID of 3GPP.
Optional items
– Mobility characteristics
• Stop, Low Mobility, High Mobility
• Mobility area, Destination
– Connectivity characteristics
• Average bandwidth of usage
• Average time of communication (or manipulation)
• Average interval between communications
• Schedule of communications
• Available delay time
– Device power consumption information
• Remained power (percentage)
• Power saving mode, Power charging
– Other options
• Booted application information
• Radio signal reception information
Page 20
Drafting contributions
Sequence (Message Flow)
Page 21
Basic Sequence (request from AE to send data)
AE
Request to notify M2M
device information
NSE
CSE
• Check the request
• Select appropriate NSEs
• Convert the format of the request
Request to notify M2M
device information
Response (ACK)
Response
Execute optimized
processing
Page 22
Next steps
Page 23
Change Requests for TS-0001
•
•
•
•
oneM2M-ARC-2013-0415-New_resources_for_NSE_CSF
oneM2M-ARC-2013-0416-Resource_description_related_to_NSE-CSF
oneM2M-ARC-2013-0417-Msg_Flows_for_NSE-CSF_related_resources
oneM2M-ARC-2013-0418-Section_for_Z_reference_point
Page 24
References
Page 25
State of the art; network processing optimization in 3GPP
(SA1/SA2)
Page 26
Service requirements for
Machine-Type Communications
(MTC); Stage 1 for Rel-12 (3GPP TS 22.368)
•
3GPP SA1 has defined the requirements below in TS 22.368
– 6 Categories of features for Machine-Type Communications
• Machine Type Communication (MTC) applications do not all have the same characteristics.
• This implies that not every system optimisation is suitable for every MTC application.
• Therefore, MTC Features are defined to provide structure for the different system optimisation
possibilities that can be invoked.
• MTC Features provided to a particular subscriber are identified in the subscription.
• MTC Features can be individually activated.
• The following MTC Features have been defined:
– Low Mobility
– Time Controlled
– Small Data Transmissions
–
–
–
–
–
–
Page 27
Infrequent Mobile Terminated
MTC Monitoring
Secure Connection
Group Based MTC Features
Group Based Policing
Group Based Addressing
Service requirements for
Machine-Type Communications
(MTC); Stage 1 for Rel-12 (3GPP TS 22.368)
•
3GPP SA1 has defined the requirements below in TS 22.368
– 7.2.1
Low mobility
• The MTC Feature Low Mobility is intended for use with MTC Devices that do
not move, move infrequently, or move only within a certain region.
• For the Low Mobility MTC Feature:
– The network operator shall be able to change the frequency of
mobility management procedures or simplify mobility management
per MTC Device.
– The network operator shall be able to define the frequency of location updates
performed by the MTC Device.
Page 28
Service requirements for
Machine-Type Communications
(MTC); Stage 1 for Rel-12 (3GPP TS 22.368)
•
3GPP SA1 has defined the requirements below in TS 22.368
– 7.2.2
Time controlled
• The MTC Feature Time Controlled is intended for use with MTC Applications
that can tolerate to send or receive data only during defined time intervals
and avoid unnecessary signalling outside these defined time intervals. The
network operator may allow such MTC Applications to send/receive data
and signalling outside of these defined time intervals but charge differently
for such traffic.
Page 29
Service requirements for
Machine-Type Communications
(MTC); Stage 1 for Rel-12 (3GPP TS 22.368)
•
3GPP SA1 has defined the requirements below in TS 22.368
– 7.2.5
Small data transmissions
• The MTC Feature Small Data Transmissions is intended for use with MTC Devices that send
or receive small amounts of data.
• For the Small Data Transmissions MTC Feature:
– -The system shall support transmissions of small amounts of data with minimal
network impact (e.g. signalling overhead, network resources, delay for reallocation).
– -Before transmission of small amount of data, the MTC Device may be attached or
detached to/from the network.
• Note: “Transmission” implies either sending or receiving small amount of data.
– -The 3GPP system shall be able to count the number of small data transmissions per
subscription e.g. for charging or statistical purposes.
• Note 1: observed size of many of the instances of data exchanges is on the order of 1K
(1024) octets
• Note 2: Charging and accounting of small data transmissions between operators can be
done on a bulk basis.
Page 30
New Work Item for Rel-13 agreed on SA1:
WID for Service Exposure and Enablement Support (SEES)
•
3GPP SA1 has agreed new WID for Service Exposure and Enablement Support (SEES)
•
3
–
–
–
Justification *
This work item allows 3rd parties to interact with the 3GPP System to use 3GPP functions to provide 3 rd party services to their
customers. Since M2M services and other Application services often have the same or similar requirements on the 3GPP
System these are addressed jointly in this work item.
The following service scenarios are considered in this work item:
M2M services:
•
•
•
Page 31
Standardization work related to M2M service enablement is on-going in standardization organisations outside 3GPP (e.g. ETSI TC M2M and the oneM2M Global
Initiative). These SDOs work under the assumption that M2M service enablement can be offered by a network operator but can also be provided by third parties
that have business agreements with operators. In addition, these SDOs want to use 3GPP capabilities beyond pure IP based data transmission that can be offered
by 3GPP networks.
On the other hand, 3GPP architecture work on MTC has started in Rel-10 and in Rel-12 SA2 is working on Small Data Transmissions and Low Power Consumption
UEs. Some information (e.g. on transmission scheduling or indications for small data, device triggering...) may need to be provided by M2M service
enablement.
In Rel-11, 3GPP defined an interface (Tsp) between the 3GPP Core Network and M2M service enablement platforms. . Additionally, 3GPP has defined other
interfaces (Le, Rx, Mo, Mf, and Mh) between the 3GPP Core Network and application platforms; these interfaces may also be used by M2M service enablement
platforms.
This work item extends the scope for this interworking. Explain in sufficient detail why this work is needed.
New Work Item for Rel-13 agreed on SA1:
WID for Service Exposure and Enablement Support (SEES)
•
•
3GPP SA1 has agreed new WID for Service Exposure and Enablement Support (SEES)
4
Objective *
– Stage 1 objectives:
– Study and specify service requirements for the support of exposing selected 3GPP functions to
– M2M service enablement layers (e.g. ETSI TC M2M and oneM2M).
Use cases of oneM2M are contained in oneM2M TR 0001- oneM2M Use Case collection.
Functions that may require such interworking have been identified by oneM2M should e.g. allow for:
• An M2M Service provider may request QoS and Prioritization for M2M communications to/from individual devices or groups of
devices. A device may request QoS and Prioritization for M2M communications to/from the M2M Service Provider.
– Note: For M2M communications initiated by the device QoS may be covered by existing call setup procedures.
• An M2M Service provider and a Network Operator may exchange information related to individual M2M Devices or Gateways,
such as transmission scheduling or indications for small data, device triggering, etc.
• A Network Operator may request the M2M Service Provider to schedule traffic via the Operator Network (e.g. to delay specific
M2M traffic when the 3GPP Network experiences high traffic load).
• Provide mechanisms to correlate the oneM2M Service Enablement Framework identifier of M2M Devices with the External
Identifier used by the 3GPP network for the same MTC client.
• Upon request by the one M2M Service enablement Framework provide the oneM2M Service Enablement Framework with
information regarding whether a M2M Device is authorized to access the 3GPP Operator Network.
• An M2M Service provider and a Network Operator may need to exchange information on charging and subscriptions to support
interworking with M2M Service providers.
• Provide 3GPP security capabilities such as GBA for the benefit of oneM2M Services and Applications. Conversely provide
mechanisms to leverage oneM2M security capabilities for the benefit of the 3GPP Operator Network security.
• An M2M Service provider and a Network Operator may exchange information related to location information of M2M Devices or
M2M Gateways.
– In order to avoid overlapping specifications, close cooperation with ETSI TC M2M and oneM2M is envisaged.
Page 32
Analysis and proposal to 3GPP MTC for Rel-13
Page 33
Analysis and proposal to 3GPP MTC for Rel-13
•
Analysis on existing 3GPP MTC features
– Currently, device characteristics such as Low Mobility , Time Controlled , Small Data Transmissions would be
decided based on device subscription information which is statically provisioned on HSS or some other
entities related to device subscription database.
•
Future market expectation
– It is expected increasing devices which might change its characteristic automatically depends on situations.
– Examples of changing the characteristic are,
• stationary(low mobility) or mobile(High mobility)
• long interval or short interval
• permit delay or forbid delay
•
Existing Key Issue
– Dynamically change of device characteristics function is needed.
▐ Proposed features
– To provide MTC features based on device characteristics which are dynamically changing
• Mechanism of detection and notification for transition of device characteristics
• Mechanism of selection for MTC features to be used based on transition of device characteristics
Page 34
Example of Static versus Dynamic of
Mobility characteristic
•
Low Mobility
– The MTC Feature Low Mobility is intended for use with MTC Devices that do not move, move
infrequently, or move only within a certain region. (Reference TS 22.238 7.2.1)
– It can be used for “Smart meter”. But it can not be used for “Car / Cargo”.
– Because “Car / Cargo” usually move any region, and sometime “ Car” at home, “Cargo” in
freight distribution center.
Static
Dynamic
Detect device behavior
And
Provide Mobility characteristic
Parking or Moving
Page 35
Provide Low Mobility
Network
Always stopping