Embed Size (px)
Citation preview
Discussion oneM2M WG2 contributions to address Network Optimization
Group Name: WG2Source: 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])
Meeting Date: 2013-10-14Agenda Item: <agenda item topic name>
oneM2M-ARC-2013-0414-Network_Optimization_Discussion_Doc
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)
• 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.2oneM2M Requirements Technical Specification <2013-08-23>– Requirements to be addressed
Requirement ID Description Release
OPR-005 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 intervalsNote: “Low mobility” and “Time controlled” are equivalent to the MTC Features specified in [i.x] (section 7.2 of 3GPP TS 22.368)
OPR-006 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.
Page 7
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 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.
Page 8
LS (OneM2M 3GPP)
• oneM2M-TP-2013-0307R01LS 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 ）
In 3GPP,A mobile network will change parameters and process for
specified device based on the information from service platform for transition of device’s behavior.
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
OverviewThe 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.
In oneM2M,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• App – CSE X reference point• CSE – MTC-IWF Z reference point• Any other relevant interfacesNodes to implement additional features• NSE CSF and any other relevant CSFs or nodes
MTC-IWF
Mobile NW （ 3GPP ）
Tsp I/FCSE
Service PF （ oneM2M ）
ApplicationsApplications
Applications
HSSX Reference Point
ZReference Point
MME T5b
S6m
Page 11
Points to be standardized in oneM2M
Application Entity(AE)
Application Entity(AE)
Common Services Entity(CSE)
▐ Interface for AE to request to notify the usage and traffic characteristics of M2M devices (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
▐ 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.
Underlying Network Service Entity(NSE)
Underlying Network Service Entity(NSE)
Z Reference Point
X Reference Point
Common Service Functions （ CSFs)Common Service Functions （ CSFs)
OPR-005OPR-005
OPR-006OPR-006
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 PointA 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 contributionsSequence (Message Flow)
Page 21
Basic Sequence (request from AE to send data)
CSE NSEAE
• Check the request• Select appropriate NSEs• Convert the format of the request
Request to notify M2M device information
Request to notify M2M device information
Execute optimized processing
Response
Response (ACK)
Page 22
References
Page 23
State of the art; network processing optimization in 3GPP (SA1/SA2)
Page 24
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– Infrequent Mobile Terminated– MTC Monitoring– Secure Connection– Group Based MTC Features– Group Based Policing– Group Based Addressing
Page 25
• 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.
Service requirements for Machine-Type Communications
(MTC); Stage 1 for Rel-12 (3GPP TS 22.368)
Page 26
• 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 27
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.
Service requirements for Machine-Type Communications
(MTC); Stage 1 for Rel-12 (3GPP TS 22.368)
Page 28
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:
• 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.
Page 29
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 30
Analysis and proposal to 3GPP MTC for Rel-13
Page 31
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 32
• 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.
Example of Static versus Dynamic of Mobility characteristic
Network
Parking or Moving Always stopping
Provide Low Mobility
StaticDynamic
Detect device behavior And
Provide Mobility characteristic
Page 33
