1. 3GPP Interworking Abstraction
Group Name: WG2-ARC
Source: Nicolas Damour, Sierra Wireless,
Meeting Date:
Agenda Item: WI GPP Interworking

2. 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]

3. 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

4. Abstraction Proposal 1/2
=> Section 8.2 Modelling of underlying network capabilities:
Clause “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 “Reused concepts”: What can be done with existing concepts (entities, resources, …) of TS-0001
Clause “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

5. 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)