3GPP Interworking Abstraction

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

Access Control Mechanism for User Group Name: SEC WG Source: Seongyoon Kim, LG Electronics, Meeting Date: Agenda Item:

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,

Device Management using mgmtCmd resource

OneM2M-ARC BRequest_Resource Architecture Proposal to address Broadcasting/Multicasting Requirements Group Name: WG2 Source: Takanori Iwai, NEC,

Multi-Link Devices Group Name: WG1 Source: Kaonmedia, KETI Contact: Hwang Kwang Tae Yong-Suk Park

Discussions for oneM2M Semantics Standardization Group Name: WG5 Source: InterDigital Communications Meeting Date: Agenda Item: WI-0005 ASN/MN-CSE.

Introduction of PRO WG activities Group Name: TP Source: Shingo Fujimoto, FUJITSU, Meeting Date: Agenda Item:

CP-a Emergency call stage 2 requirements - A presentation of the requirements from 3GPP TS Keith Drage.

3GPP Rel-13 Interworking discussions

Management of CMDH Policies Group Name: WG5-MAS Source: Wolfgang Granzow, Qualcomm, Meeting Date: Agenda Item: Management.

Usage Scenarios for CSE Group Name: WG2(ARC-WG) Source: Shingo Meeting Date: Agenda Item: Message.

App-ID Discussion Group Name: ARC WG Source: Seongyoon Kim, LG Electronics, Meeting Date: 31 July 2014 Agenda Item: TBD.

Response Status Codes Concepts for oneM2M Group Name: WG3 Source: Philip Jacobs, Cisco, Meeting Date: Agenda Item: TS-0004.

Proposal for WG3 & WG5 work area split

AllJoyn-Interworking Discussion Group Name: TP WG2 ARC Source: Josef Blanz, Phil Hawkes, Qualcomm Inc., Meeting Date:

Customized Resource Types MAS Group Name: MAS + ARC + PRO WGs Source: Wolfgang Granzow, Qualcomm Inc., Meeting Date:

Step by step approach Group Name: WG2 Source: Michael hs. Yang, LG uplus, Jaeseung Song, NEC Europe, Meeting.

Node-Specific Resource Group Name: ARC&MAS Source: LGE, Meeting Date: Agenda Item: Contribution.

An introduction to oneM2M

3GPP Rel-13 Interworking discussions

3GPP SCEF Interworking Call Flows

WG-2 - ARC TP #18 Status Report Group Name: oneM2M TP #18 Source: WG2 Chair (Nicolas Damour – Meeting Date: Agenda.

M2M Service Subscription Profile Discussion Group Name: oneM2M TP #19.2 Source: LG Electronics Meeting Date: Agenda Item:

Introducing Event handler Group Name: SEC & ARC Source: FUJITSU Meeting Date: Agenda Item: Device Configuration.

Discussion about RESTful Admin API Group Name: SEC & ARC Source: FUJITSU Meeting Date: Agenda Item: Device Configuration.

Security API discussion Group Name: SEC Source: Shingo Fujimoto, FUJITSU Meeting Date: Agenda Item: Security API.

SEC #11 WG4 Status & Release 1 Outlook Group Name: Source:,, Meeting Date: Agenda Item:

3GPP SCEF Interworking Discussions

Introduction to oneM2M OMA - oneM2M Meeting, San Diego, Jan. 19th 2016

WG2 - ARC TP #20 Status Report Group Name: oneM2M TP #20 Source: WG2 Chair (Nicolas Damour – Meeting Date: Agenda.

Authorization Architecture Discussion Group Name: SEC WG Source: Seongyoon Kim, LG Electronics, Meeting Date: 28 MAY, 2014 Agenda.

Consideration Security Issues on Registration Group Name: WG4 (SEC) Source: Shingo Fujimoto, FUJITSU, Meeting Date:

Reasons for CSF Clean-up (Issues & Next Steps) Group Name: WG2 Source: Syed Husain – NTT DOCOMO Meeting Date: (ARC_9.3) Agenda Item: 6 DOC#:

Management CSF(s) Architectural choices Group Name: WG2 (ARC), WG5(MAS) Source: Catalina Mladin, InterDigital Comm., Meeting.

Possible options of using DDS in oneM2M Group Name: ARC Source: KETI, Huawei, Hitachi, China Unicom Meeting Date: Agenda Item: DDS binding.

IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Proposed Presentation for 3GPP Date Submitted: August,

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:

Background Data Transfer

3GPP R13 Small Data Delivery

oneM2M Requirements for SCEF northbound API

ONEM2M RELEASE 2: SETTING THE STANDARD FOR IOT INTEROPERABILITY

Provisional Architecture for oneM2M

Service Framework Proposal

SCEF northbound API Analysis

Group multicast fanOut Procedure

3GPP interworking in R3 Group Name: ARC

Possible options of using DDS in oneM2M

Proposed design principles for modelling interworked devices

Teleconference Agenda

MAF&MEF Interface Specification discussion of the next steps

3GPP Rel-13 Interworking discussions

WPM ad-hoc group report TP#25

OneM2M-ARC BRequest_Resource Architecture Proposal to address Broadcasting/Multicasting Requirements Group Name: WG2 Source: Takanori Iwai,

Considering issues regarding handling token

LWM2M Interworking with <mgmtObj> Resources

CMDH Refinement Contribution: oneM2M-ARC-0397R01

MinitorEvent(UE_Reachability)

CMDH Policies Contribution: ARC-2014-xxxx

An introduction to oneM2M

3GPP V2X Interworking Potential Impact

3GPP Interworking and use of <schedule> resource

IEEE MEDIA INDEPENDENT HANDOVER DCN:

IEEE MEDIA INDEPENDENT HANDOVER DCN:

IEEE MEDIA INDEPENDENT HANDOVER DCN:

Presentation transcript:

3GPP Interworking Abstraction Group Name: WG2-ARC Source: Nicolas Damour, Sierra Wireless, ndamour@sierrawireless.com Meeting Date: 2016-01-19 Agenda Item: WI-0037 3GPP Interworking

3GPP Existing functions Triggering Communication Patterns CP parameter set Description Periodic communication indicator Identifies whether the Node communicates periodically or not, e.g. only on demand. [optional] Communication duration time Duration interval time of periodic communication [optional, may be used together with 1)] Example: 5 minutes Time period Interval Time of periodic communication [optional , may be used together with 1)] Example: every hour Scheduled communication time Time zone and Day of the week when the Node is available for communication [optional] Example: Time: 13:00-20:00, Day: Monday Stationary indication Identifies whether the UE is stationary or mobile [optional] Validity time The time after which a CP parameter becomes invalid once it had been set [optional]

Abstraction? Entities Mapping? UE = Node, AE, … ? Communication patterns (periodic, duration, intervals, scheduled…) of an Application (identified by its App-ID) or of specific AEs (identified by their AE-IDs) Mobility patterns (stationary/mobile) of Nodes (the equivalent of a 3GPP UE), identified by its Node-ID

Abstraction Proposal 1/2 => Section 8.2 Modelling of underlying network capabilities: Clause 8.2.1 “Introduction”: Generic way to model the underlying network capabilities that works for any kind of network (cable, cellular, satellite…), either reusing what’s already defined in TS-0001 (like CMDH, device management, existing resources…) or defining new concepts. Of course, in the scope of this TR, you will make sure that this works for 3GPP Release 13 networks Clause 8.2.2 “Reused concepts”: What can be done with existing concepts (entities, resources, …) of TS-0001 Clause 8.2.3 “New concepts”: Whichever new concepts are need, including the NSE resource (only if it is meant to be exposed!) and explain why we need these resources, and for what purpose we want to expose them over one of the reference points

Abstraction Proposal 2/2 => Section 8.3 called “Proposed communication flows”: The “northbound” provisioning flows: How does one tell the oneM2M system that certain AEs, Applications or Nodes will have certain characteristics This probably includes manipulation of some resources over the Mca reference point The “southbound” provisioning flows: How does the CSE (or the NSSE) actually work with the SCEF/OMA APIs, how it registers to it, authenticated, gets authorization, etc. The operating flows: What happens when an AE (server side or device side) tries to initiate a communication (northbound, southbound and in the network)