oneM2M Requirements for SCEF northbound API

Slides:



Advertisements
Similar presentations
Is a Node or not Node? ARC Node_resolution Group Name: ARC Source: Barbara Pareglio, NEC, Meeting Date: ARC#9.1 Agenda.
Advertisements

Omniran GPP Trusted WLAN Access to EPC Use Case Analysis Date: Authors: NameAffiliationPhone Max RiegelNSN
Problem of Current Notification Group Name: ARC WG Source: Heedong Choi, LG Electronics, Meeting Date: ARC 9.0 Agenda Item: TBD.
REQ WG Reuse of underlying networks, 3GPP
REQ WG Reuse of underlying networks, 3GPP
REQ WG Reuse of underlying networks, 3GPP From: Omar Elloumi (ALU) Source: Alcatel-Lucent (ATIS) Meeting Date: Agenda Item:
Discussion oneM2M WG2 contributions to address Network Optimization Group Name: WG2 Source: Takanori Iwai, NEC,
Mechanism to support establishment of charging policies Group Name: WG2-ARC Source: InterDigital Meeting Date: TP8 Agenda Item:
Optimized M2M interworking with mobile networks Group Name: oneM2M REQ Source: Takanori Iwai, NEC, Meeting Date: Agenda.
An Operators Input for oneM2M Baseline  Group name: TP#2/WG1  Source: DTAG, Vodafone Group  Meeting Date:  Agenda Item: WG1 agenda item.
Support for CSFB Tony Lee David Wang David Wang June/15/2009 VIA Telecom grants.
CP-a Emergency call stage 2 requirements - A presentation of the requirements from 3GPP TS Keith Drage.
3GPP Rel-13 Interworking discussions
Answer the Questions Regarding Pending Issues on Access Control Group Name: WG4 SEC Source: LG Electronics Meeting Date: Agenda Item: SEC#11.4.
Usage Scenarios for CSE Group Name: WG2(ARC-WG) Source: Shingo Meeting Date: Agenda Item: Message.
INTRODUCTION. 1.1 Why the Internet Protocol Multimedia Subsystem 1.2 Where did it come from?
Node-Specific Resource Group Name: ARC&MAS Source: LGE, Meeting Date: Agenda Item: Contribution.
3GPP Rel-13 Interworking discussions
September 28, 2006 Page 1 3GPP2 MMD Status for IMS Workshop Jack Nasielski
3GPP SCEF Interworking Call Flows
Optimized M2M interworking with mobile networks Group Name: oneM2M REQ Source: Takanori Iwai, NEC, Meeting Date: Agenda.
Page 1TTT - May 12, GPP IMS Standardization Update Bell Labs Innovations Lucent Technologies Room 9C Lucent Ln. Naperville, IL E Mail.
NETLMM Applicability Draft (Summary) 28 Sep
EHRPD-LTE Inter Technology Spectrum Optimization Source: Qualcomm Incorporated Contact: Jun Wang/George Cherian September 9, 2013 Notice ©2013. All rights.
3GPP SCEF Interworking Discussions
M2M Service Session Management (SSM) CSF Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP8 Agenda Item:
Adding Non-blocking Requests Contribution: oneM2M-ARC-0441R01R01 Source: Josef Blanz, Qualcomm UK, Meeting Date: ARC 7.0,
CMDH and Policies Contribution: oneM2M-ARC-0603
Subscription and Notification Issue Group Name: WG2 Source: Qi Yu, Mitch Tseng- Huawei Technologies, Co. LTD. Meeting Date: ~23 Agenda Item:
By Suman(1RV12LDC29).  Long Term Evolution (LTE) promises higher data rates, 100Mbps in the downlink and 50Mbps in the uplink in LTE’s first phase, and.
Possible options of using DDS in oneM2M Group Name: ARC Source: KETI, Huawei, Hitachi, China Unicom Meeting Date: Agenda Item: DDS binding.
Specifying the Address of Management Client of Managed Entity Group Name: ARC Source: Hongbeom Ahn, SK Telecom, Meeting Date: TP#21 Agenda.
3GPP Rel-13 Interworking discussions Group Name: TP #18 Source: Rejesh Bhalla, ZTE Corporation, Meeting Date: Agenda Item:
Month Year doc.: IEEE yy/xxxxr0 July 2017
Background Data Transfer
3GPP R13 Small Data Delivery
Managing Retransmission Timers in Sleep Mode
Review of new Question descriptions under ITU-T SG11
Exposing Link-Change Events to Applications
Update on 3GPP RAN3 Multi-RAT joint coordination
3GPP MBMS protocol stack
CSE Retargeting to AE, IPE, and NoDN Hosted Resources
CSE Retargeting to AE, IPE, and NoDN Hosted Resources
Service Enabled AE (SAE)
SCEF northbound API Analysis
Group multicast fanOut Procedure
GPRS.
3GPP interworking in R3 Group Name: ARC
Managing Retransmission Timers in Sleep Mode
Possible options of using DDS in oneM2M
NIDD Discussion Points
3GPP Rel-13 Interworking discussions
OneM2M-ARC BRequest_Resource Architecture Proposal to address Broadcasting/Multicasting Requirements Group Name: WG2 Source: Takanori Iwai,
Discussion to clarify online/offline behavior
3GPP Interworking Abstraction
教育部補助「行動寬頻尖端技術跨校教學聯盟第二期計畫 -- 行動寬頻網路與應用 -- 小細胞基站聯盟中心」 EPC核心網路系統設計 課程單元 05:Data Services in EPS 計畫主持人:許蒼嶺 (國立中山大學 電機工程學系) 授課教師:萬欽德 (國立高雄第一科技大學 電腦與通訊工程系)
Group multicast Group Name: ARC
CMDH Refinement Contribution: oneM2M-ARC-0397R01
MinitorEvent(UE_Reachability)
CMDH Policies Contribution: ARC-2014-xxxx
NETLMM Applicability Draft (Summary)
Distributed Mobility Management (DMM) WG DMM Work Item: Forwarding Path & Signaling Management (FPSM) draft-ietf-dmm-fpc-cpdp-01.txt IETF93, Prague.
3GPP V2X Interworking Potential Impact
3GPP Interworking and use of <schedule> resource
3GPP Charging 2019/2/16.
IEEE MEDIA INDEPENDENT HANDOVER DCN:
IEEE MEDIA INDEPENDENT HANDOVER DCN:
3GPP Update/Status (Release 15 – June 2018)
IEEE MEDIA INDEPENDENT HANDOVER DCN:
教育部補助「行動寬頻尖端技術跨校教學聯盟第二期計畫 -- 行動寬頻網路與應用 -- 小細胞基站聯盟中心」 模組名稱: 「LTE-Small Cell 核心網路架構及服務」 單元-A4:核心網路 (EPC) 與 Internet Cloud 的介接與存取 計畫主持人:許蒼嶺 (國立中山大學 電機工程學系)
Presentation transcript:

oneM2M Requirements for SCEF northbound API Group Name: ARC Source: Bei Xu, Huawei Technologies Co., Ltd. Echo.xubei@huawei.com Meeting Date: 2016-11-27 Agenda Item: TBD

Purpose The 3GPP R13&R14 exposes network capabilities to external entities via SCEF. In oneM2M 3GPP interworking architecture, the IN-CSE may leverage the network capabilities via SCEF APIs to provide E2E CIoT services. In order to support and expedite the standardization of SCEF APIs by other SDOs (e.g. 3GPP), this contribution analyzes the requirements for those APIs from oneM2M perspective (mapped to Mcn). The outcome is expected to be a consolidated requirement list from oneM2M, which will be included in a LS to be sent to the responsible SDO. Note: To facilitate the discussion, service flows defined in 3GPP TS23.682 are used in the following slides as informative information only. Our focus is on the northbound APIs of SCEF. There is no intention to change or suggest anything at the southbound of SCEF, but only to understand the network behavior when the SCEF APIs are invoked by oneM2M. The 3GPP defined term ‘SCS’ in the flows corresponds to oneM2M IN-CSE.

Content The current focus on Non-IP data transfer between oneM2M entity and oneM2M platform CMDH Down Link Data Delivery when UE is unreachable UE PSM timer or eDRX Configuration Network Monitor:Network Status, Communication Failure Group Management Location Network-based location Others

Non-IP data transfer between oneM2M entity and oneM2M platform This part will be discussed in another contribution based on TR-0026 NIDD section.

Content The current focus on Non-IP data transfer between oneM2M entity and oneM2M platform CMDH Down Link Data Delivery when UE is unreachable UE PSM timer or eDRX Configuration Network Monitor:Network Status, Communication Failure Group Management Location Network-based location Others

Downlink Data Delivery when UE is unreachable 3GPP introduction UE Power Saving Mode( PSM ) That mode is similar to power-off, but the UE remains registered with the network and there is no need to re-attach or re-establish PDN connections. A UE in PSM is not immediately reachable for mobile terminating services. A UE using PSM is available for mobile terminating services during the time it is in connected mode and for the period of an Active Time that is after the connected mode. Extended Idle mode Discontinuous Reception (eDRX) The UE and the network may negotiate over non-access stratum signaling the use of extended idle mode DRX for reducing its power consumption Applications that want to use extended idle mode DRX need to consider specific handling of mobile terminating services or data transfers, and in particular they need to consider the delay tolerance of mobile terminated data. oneM2M introduction Schedule A child <schedule> resource of the <AE> resource shall indicate the time periods when the application of a node can be accessed.

Monitor Event Configuration SCEF API Requirement Step1:Monitoring Request(SCS->SCEF) Monitoring Configuration Request of UE reachablity (External Identifier(s) or MSISDN(s), SCS/AS Identifier, SCS/AS Reference ID, Monitoring Type, Maximum Number of Reports, Monitoring Duration, Monitoring Destination Address, SCS/AS Reference ID for Deletion) Monitoring Type = UE reachablity (Reachability Type , Maximum Latency ,Maximum Response Time ) Monitoring Type = Availability after DDN Failure,without Max Number of Reports(one time subscription) Step9:Monitoring Response(SCEF->SCS) Monitoring Response (SCS/AS Reference ID, Cause) 3GPP Stage 2 completeness Y Figure 5.6.1.1-1: Monitoring event configuration and deletion via HSS procedure

UE PSM timer/eDRX Configuration SCEF API Requirement Step1:PSM Timer Set Request(SCS->SCEF) Monitoring Request of UE reachablity (External Identifier(s) or MSISDN(s), SCS/AS Identifier, SCS/AS Reference ID, Monitoring Type, Maximum Number of Reports, Monitoring Duration, Monitoring Destination Address, SCS/AS Reference ID for Deletion) Monitoring Type = UE reachablity (Reachability Type , Maximum Latency ,Maximum Response Time ) Step9:PSM Timer Set Response(SCEF->SCS) Monitoring Response (SCS/AS Reference ID, Cause) 3GPP Stage 2 completeness Y

Monitoring Event Report(UE Reachability ) SCEF API Requirement Step2:Monitor Report(SCEF->SCS) MonitorReport(SCS/AS Reference ID, External ID or MSISDN, Monitoring Information) 3GPP Stage 2 completeness Partially, Monitoring Information is not clear. Figure 5.3.2-1 UE Reachability reporting

Monitoring Event(Availability Notification after DDN Failure) Figure 5.4.4-1: Notification - Availability Notification after DDN Failure SCEF API Requirement Step9:Monitor Report(SCEF->SCS) MonitorReport(SCS/AS Reference ID, External ID or MSISDN, Monitoring Information) 3GPP Stage 2 completeness Partially, Monitoring Information is not clear.

Network Monitoring Monitoring Event: Communication failure This monitoring event allows the SCS/AS to be notified of communication failure events, identified by RAN/NAS Release Cause codes. Informing about Potential Network Issues The SCS/AS requests to be informed, one-time/continuously, about the network status by providing a geographical area.

Monitoring Event: Communication failure SCEF API Requirement Step1:Monitoring Request(SCS->SCEF) Monitoring Configuration Request of UE reachablity (External Identifier(s) or MSISDN(s), SCS/AS Identifier, SCS/AS Reference ID, Monitoring Type, Maximum Number of Reports, Monitoring Duration, Monitoring Destination Address, SCS/AS Reference ID for Deletion) Monitoring Type Communication Failure Step9:Monitoring Response(SCEF->SCS) Monitoring Response (SCS/AS Reference ID, Cause) Step12:Monitoring Report(SCEF->SCS) Monitoring Response(SCS/AS Reference ID, External ID or MSISDN, Monitoring Information) Stage 2 completeness Partially, Monitoring Information is not clear. Figure 5.8.2-1: Request procedure for one-time or continuous reporting of network status

Request procedure for one-time or continuous reporting of network status SCEF API Requirement Step1:Network Status Req(SCS->SCEF) Network Status Request (Geographical area, SCS/AS Identifier, SCS/AS Reference ID, Duration, Threshold) Cancel Network Status Request (SCS/AS Identifier, SCS/AS Reference ID) Step6:Network Status Rsp(SCEF->SCS) Network Status Report (SCS/AS Reference ID, Congestion level, ECGI/eNodeB-ID/SAI ) Cancel Network Status Response (SCS/AS Reference ID) 3GPP Stage 2 completeness Y Figure 5.8.2-1: Request procedure for one-time or continuous reporting of network status

Content The current focus on Non-IP data transfer between oneM2M entity and oneM2M platform CMDH Down Link Data Delivery when UE is unreachable UE PSM timer or eDRX Configuration Network Monitor:Network Status, Communication Failure Group Management Location Network-based location Others

Group message delivery procedures SCEF API Requirement Step1:Allocate TMGI Request(SCS->SCEF) Allocate TMGI Request (External Group ID, SCS Identifier, location/area information) Step4:Allocate TMGI Rsp (SCEF->SCS) Allocate TMGI Rsp(SCS/AS Reference ID, TMGI and expiration time information) Step6:Group Message Request(SCS->SCEF) Group Message Request (External Group Identifier, SCS Identifier, location/area information, RAT(s) information, TMGI, start time) Step11:Group Message Confirm(SCEF->SCS) Group Message Confirm (TMGI (optional), SCEF IP addresses/port) 3GPP Stage 2 completeness Partial, the interface and parameter is not clear

Content The current focus on Non-IP data transfer between oneM2M entity and oneM2M platform CMDH Down Link Data Delivery when UE is unreachable UE PSM timer or eDRX Configuration Network Monitor:Network Status, Communication Failure Group Management Location Network-based location Others

LocationPolicy oneM2M introduction The <locationPolicy> resource represents the method for obtaining and managing geographical location information of an M2M Node.Based on the locationSource attribute, the method for obtaining location information of an M2M Node can be differentiated. The methods for obtaining location information shall be as follows: Network-based method: where the CSE on behalf of the AE obtains the target M2M Node's location information from an Underlying Network. Device-based method: where the ASN is equipped with any location capable modules or technologies (e.g. GPS) and is able to position itself. Sharing-based method: where the ADN has no GPS nor an Underlying Network connectivity. Its location information can be retrieved from either the associated ASN or a MN.

Monitoring Event: Location Reporting SCEF API Requirement Monitor Event ConfigReq(SCS->SCEF) Monitoring Request (External Identifier(s) or MSISDN(s), SCS/AS Identifier, SCS/AS Reference ID, Monitoring Type, Maximum Number of Reports, Monitoring Duration, Monitoring Destination Address, SCS/AS Reference ID for Deletion) Monitoring Type = Location Reporting( Location Type, Accuracy prior ) Monitoring Type = Roaming Status (PLMN Information) Monitor Event ConfigRsp(SCEF>SCS) Monitoring Response (SCS/AS Reference ID, Cause) Monitor Report(SCEF>SCS) LocationMonitorReport(SCS/AS Reference ID, External ID or MSISDN, geo-location) RoamingStatusMonitorReport(SCS/AS Reference ID, External ID or MSISDN, HPLMN PLMN-Id/ Visited PLMN-Id) 3GPP Stage 2 completeness Y Figure 5.6.1.1-1: Monitoring event configuration and Report

Summary(1) oneM2M comman service function 3GPP SCEF API Requirement Prameter of API 3GPP defined or not OMA support or not Remark Non-IP device Accessing oneM2M platform(MO/MT) NIDD Configuration Request External Identifier or MSISDN, SCS/AS Identifier, SCS/AS Reference ID, NIDD Duration, NIDD Destination Address, SCS/AS Reference ID for Deletion Y N NIDD Configuration Response SCS/AS Reference ID, Cause NIDD MOReq NIDD MORsp NIDD MTReq External Identifier or MSISDN, SCS/AS Reference ID, non-IP data OMA-TS-REST_NetAPI_Messaging(NIDD Subscription NIDD Status NIDD MTRsp Communication failure Monitor Event ConfigReq External Identifier(s) or MSISDN(s), SCS/AS Identifier, SCS/AS Reference ID, Monitoring Type, Maximum Number of Reports, Monitoring Duration, Monitoring Destination Address, SCS/AS Reference ID for Deletion Communication failure Monitor Event ConfigRsp Communication failure Monitor Report failure cause code / an abstracted value CMDH-Down Link Data Delivery when UE is unreachable Monitor Event ConfigReq-UE reachablity External Identifier(s) or MSISDN(s), SCS/AS Identifier, SCS/AS Reference ID, Monitoring Type, Maximum Number of Reports, Monitoring Duration, Monitoring Destination Address, SCS/AS Reference ID for Deletion,Reachability Type , Maximum Latency , Maximum Response Time , Suggested number of downlink packets Y? OMA-TS-REST_NetAPI_TerminalStatus-V1_0 Monitor Event ConfigReq-Availability after DDN Failure External Identifier(s) or MSISDN(s), SCS/AS Identifier, SCS/AS Reference ID, Monitoring Type, Monitoring Duration, Monitoring Destination Address, SCS/AS Reference ID for Deletion OMA-TS-REST_NetAPI_Messaging-V1_0 Monitor Event ConfigRsp OMA-TS-REST_NetAPI_Messaging-V1_1 MonitorReport SCS/AS Reference ID, External ID or MSISDN, Monitoring Information OMA-TS-REST_NetAPI_Messaging-V1_2 OMA-TS-REST_NetAPI_TerminalStatus-V1_0 UE PSM timer/eDRX Configuration PSM timer Set Req(Monitor Event ConfigReq-UE reachablity已经支持) PSM timer Set Rsp(Monitor Event ConfigRsp已经支持) Group Management Allocate TMGI Request External Group ID, SCS Identifier, location/area information Allocate TMGI Rsp SCS/AS Reference ID, TMGI and expiration time information Group Message Request External Group Identifier, SCS Identifier, location/area information, RAT(s) information, TMGI, start time Group Message Confirm TMGI (optional), SCEF IP addresses/port Network Status Req Geographical area, SCS/AS Identifier, SCS/AS Reference ID, Duration, Threshold Network Status Report SCS/AS Reference ID, Congestion level, ECGI/eNodeB-ID/SAI Cancel Network Status Request SCS/AS Identifier, SCS/AS Reference ID Cancel Network Status Response SCS/AS Reference ID Location Network-based location Monitor Event ConfigReq-= Location Reporting External Identifier(s) or MSISDN(s), SCS/AS Identifier, SCS/AS Reference ID, Monitoring Type, Maximum Number of Reports, Monitoring Duration, Monitoring Destination Address, SCS/AS Reference ID for Deletion,Location Type, Accuracy prior OMA-TS-REST_NetAPI_TerminalLocation-V1_0_1-20151029-A  Monitor Event ConfigReq-= Roaming Status External Identifier(s) or MSISDN(s), SCS/AS Identifier, SCS/AS Reference ID, Monitoring Type, Maximum Number of Reports, Monitoring Duration, Monitoring Destination Address, SCS/AS Reference ID for Deletion,PLMN Information Monitoring Event Config Response OMA-TS-REST_NetAPI_TerminalLocation-V1_0_1-20151031-A  LocationMonitorReport SCS/AS Reference ID, External ID or MSISDN, geo-location OMA-TS-REST_NetAPI_TerminalLocation-V1_0_1-20151032-A  RoamingStatusMonitorReport SCS/AS Reference ID, External ID or MSISDN, HPLMN PLMN-Id/ Visited PLMN-Id

Content The current focus on Non-IP data transfer between oneM2M entity and oneM2M platform CMDH Down Link Data Delivery when UE is unreachable UE PSM timer or eDRX Configuration Network Monitor:Network Status, Communication Failure Group Management Location Network-based location Others

Monitoring Event: Loss of connectivity SCEF API Requirement Monitor Event ConfigReq(SCS->SCEF) Monitoring Request (External Identifier(s) or MSISDN(s), SCS/AS Identifier, SCS/AS Reference ID, Monitoring Type, Maximum Number of Reports, Monitoring Duration, Monitoring Destination Address, SCS/AS Reference ID for Deletion) Monitoring Type = Loss of connectivity ( Maximum Detection Time ) Monitor Event ConfigRsp(SCEF>SCS) Monitoring Response (SCS/AS Reference ID, Cause) Monitor Report(SCEF>SCS) LossOfConnectivityMonitorReport(SCS/AS Reference ID, External ID or MSISDN, Monitoring Information) 3GPP Stage 2 completeness Partially, Monitoring Information is not clear. Figure 5.6.1.1-1: Monitoring event configuration and Report

Monitoring Event: Change of IMSI-IMEI(SV) association SCEF API Requirement Monitor Event ConfigReq(SCS->SCEF) Monitoring Request (External Identifier(s) or MSISDN(s), SCS/AS Identifier, SCS/AS Reference ID, Monitoring Type, Maximum Number of Reports, Monitoring Duration, Monitoring Destination Address, SCS/AS Reference ID for Deletion) Monitoring Type = Change of IMSI-IMEI(SV) association ( Association Type ) Monitor Event ConfigRsp(SCEF>SCS) Monitoring Response (SCS/AS Reference ID, Cause) Monitor Report(SCEF>SCS) ChangeofAssociationMonitorReport(SCS/AS Reference ID, External ID or MSISDN, Monitoring Information) 3GPP Stage 2 completeness Partially, Monitoring Information is not clear. Figure 5.6.1.1-1: Monitoring event configuration and Report

Procedure for resource management of background data transfer SCEF API Requirement Step1: Background data transfer request (SCS->SCEF) Background data transfer request (SCS/AS Identifier, SCS/AS Reference ID, Volume per UE, Number of UEs, Desired time window) Step4: Background data transfer response (SCEF->SCS) Background data transfer response (SCS/AS Identifier, reference ID, Possible transfer policies) Step5:New Background data transfer request ( SCS->SCEF ) Background data transfer request (SCS/AS Identifier, SCS/AS Reference ID, Selected transfer policy) Step6: NewBackground data transfer response( SCEF->SCS) Background data transfer response (SCS/AS Identifier) 3GPP Stage 2 completeness Y Figure 5.9-1: Resource management for background data transfer

Communication Pattern parameters provisioning procedure SCEF API Requirement Step1: Background data transfer request (SCS->SCEF) Update Request (External Identifier or MSISDN, SCS/AS Identifier, SCS/AS Reference ID(s), CP parameter set(s), validity time(s), SCS/AS Reference ID(s) for Deletion) Step6: Update Response (SCEF->SCS) Update Response (SCS/AS Reference ID, Cause) 3GPP Stage 2 completeness Y Figure 5.10.2-1: Signalling sequence for provisioning of CP Parameters

Setting up an AS session with required QoS procedure Figure 5.11-1: Setting up an AS session with required QoS SCEF API Requirement Step1: On-demand QoS request (SCS->SCEF) On-demand QoS request (UE IP address, SCS/AS Identifier, SCS/AS Reference ID, Description of the application flows reference to a pre-defined QoS) Step5: On-demand QoS response (SCEF->SCS) On-demand QoS response (SCS/AS Identifier, SCS/AS Reference ID, Result) 3GPP Stage 2 completeness Y

Others DeviceTrigger PS-only Service Provision Device Triggering is the means by which a SCS sends information to the UE via the 3GPP network to trigger the UE to perform application specific actions that include initiating communication with the SCS for the indirect model or an AS in the network for the hybrid model. Device Triggering is required when an IP address for the UE is not available or reachable by the SCS/AS. PS-only Service Provision PS-only service provision is providing a UE with all subscribed services via PS domain. PS-only service provision implies a subscription that allows only for services exclusively provided by the PS domain, i.e. packet bearer services and SMS services. The support of SMS services via PS domain NAS is a network deployment option and may depend also on roaming agreements. Therefore, a subscription intended for PS-only service provision may allow also for SMS services via CS domain to provide a UE with SMS services in situations when serving node or network don't support SMS via PS domain NAS. Core Network assisted RAN parameters tuning Core Network assisted RAN parameters tuning aids the RAN in optimizing the setting of RAN parameters. Change the chargeable party at session set-up or during the session The SCS/AS may request the SCEF to start or stop sponsoring a data session for a UE that is served by the 3rd party service provider (AS session), i.e. to realize that either the 3rd party service provider is charged for the traffic (start) or not (stop). The SCS/AS may request to be set as the chargeable party, i.e. sponsoring the traffic, either at AS session set-up or to change it during an ongoing AS session.

Summary(2) Others 3GPP defined parameter complete or not DeviceTrigger PS-only Service Provision N(parameter not defined) Core Network assisted RAN parameters tuning Resource management of background data transfer E-UTRAN network resource optimizations based on communication patterns provided to the MME Support of setting up an AS session with required QoS Change the chargeable party at session set-up or during the session Monitoring Event: Loss of connectivity Monitoring Event: Change of IMSI-IMEI(SV) Association

oneM2M Requirements for SCEF API Summary The existing interfaces enhancement for stage2(TS23.682) NIDD MOReq/Rsp need define the parameters NIDD MTRsp need define the parameters Monitor Event Report: monitor information need to be specified according to the event type Group Management: need more explanation about the parameters of northbound interface and how mapping the parameters between the southbound interface and northbound interface PS-only Service Provision need define the service flow, interface and parameter Core Network assisted RAN parameters tuning need define the service flow, interface and parameter All APIs defining in stage 3 Support to finish defining the SCEF APIs in Q4 2017 Potential New Requirements? Add new parameter in the existing interface or add new service flow after more detail and deeper analysis on the oneM2M other functions interworking with 3GPP

oneM2M Requirements for SCEF API Summary oneM2M common service function SCEF API Reqirements Gaps in Stage2 of 3GPP Non-IP device Accessing oneM2M platform (MO/MT) NIDD MO Request(SCEF->SCS) NIDD MO Request (SCS->SCEF) Need to define the parameters. NIDD MT Request(SCS->SCEF) NIDD MT Response(SCEF->SCS) Group Management Allocate TMGI Request(SCS->SCEF) The parameter explain and format definition of location/area information How to map the parameters with parameters of MB2 interface defined in TS23468 Group Message Request(SCS->SCEF) The parameter explain and format definition of location/area information, RAT(s) information Group Message Confirm(SCEF->SCS) The parameter explain that how to indicate the group message delivery status. Communication Management and Delivery Handling Monitor Report(SCEF->SCS) MonitorType= UE Reachability Monitoring Information need to be defined more clearly. MonitorType = Availability Notification after DDN Failure MonitorType = Communication Failure Monitoring Information need to be defined more clearly MonitorType = LossOfConnectivityMonitorReport Others MonitorType = Change of IMSI-IMEI(SV) association PS-only Service Provision Need to define the service flow, interface and parameter Core Network assisted RAN parameters tuning

Next step oneM2M should create a document summering 3GPP stage2 gaps oneM2M should decide how forward the information to 3GPP for support?

Questions and comments