3GPP SCEF Interworking Discussions Group Name: TP 19.3 Source: InterDigital: Paul Russell, Jr., Paul.Russell@Interdigital.com; Mike Starsinic, Mike.Starsinic@InterDigital.com NEC Corporation: Norio Uchida, n-uchida@cq.jp.nec.com Ataru Kobayashi, a-kobayashi@df.jp.nec.com NEC Europe LTd.: Joerg Swetina, Joerg.Swetina@neclab.eu Meeting Date: October 20th, 2015 Agenda Item: 3GPP R13 Interworking

Background Information At TP18 3GPP SCEF Interworking options were discussed for oneM2M Work Item # 0037: 3GPP_Rel13 Interworking ARC-2015-2038R03 ARC-2015-2157 ARC-2015-2089 Two Architecture options were discussed Option #1 – IN-CSE provides SCEF functionality and interfaces directly with the 3GPP network Option #2 – IN-CSE interfaces with the SCEF using OMA defined APIs The goal of this contribution is to continue discussions on how to support SCEF in oneM2M architecture and to clarify terminology a bit to help reduce confusion.

Background - Option 1 Ref. ARC-2015-2157 NSSE: Network Service Exposure, Service Execution and Triggering

Background - Option 2 Ref. ARC-2015-2157 NSSE: Network Service Exposure, Service Execution and Triggering

Existing oneM2M Terms TS-0001 defines 3 main terms for interworking with underlying networks The Network Service Exposure, Service Execution and Triggering (NSSE) CSF manages communications with the Underlying Networks for accessing network service functions over the Mcn reference point. The NSSE CSF uses the available/supported methods for service "requests" on behalf of AEs. The NSSE CSF shields other CSFs and AEs from the specific technologies and mechanisms supported by the Underlying Networks. The network service functions provided by the Underlying Network include service functions such as, but not limited to, device triggering, small data transmission, location notification, policy rules setting, location queries, IMS services, device management. Such services do not include the general transport services. Underlying Network Services Entity (NSE): A Network Services Entity provides services from the underlying network to the CSEs. Examples of such services include device management, location services and device triggering. No particular organization of the NSEs is assumed. Mcn Reference Point - Communication flows between a Common Services Entity (CSE) and the Network Services Entity (NSE) cross the Mcn reference point. These flows enable a CSE to use the supported services (other than transport and connectivity services) provided by the NSE.

Confusion Per TS 23.682 : The SCEF is always part of the Trust Domain. The AS/SCS (IN-CSE) may, or may not, be part of the trust domain. Depending on the Deployment Model, the oneM2M Interworking Terms do not consistently Map to the 3GPP Interworking Architecture The oneM2M Architecture is good, but the definition of some terms (NSSE, NSE and Mcn) should be modified or clarified based on SCEF deployment model to avoid confusion.

Clarifications to Option #1 In this case, a single company operates both the NSE and IN-CSE (3GPP SCS). The company is a trusted business partner (in 3GPP TS23.682) which provides SCEF functionality. Operator Trust Domain NSE MN-CSE 3GPP NW CSE Mcc Network Entities (HSS, MME, MTC-IWF, PCRF) IN-CSE (SCS) NSSE CSF SCEF API Mca IN-AE Some functions in the 3GPP NW are NSEs. SCEF is deployed as the oneM2M NSSE CSF within the IN-CSE SCEF northbound interface (API) is made available to the rest of the IN-CSE. The IN-CSE may make some or all API’s available to other CSE’s and AE’s. SCEF southbound interfaces is oneM2M Mcn reference point and is bound to 3GPP defined interfaces (e.g. Rx, Tsp, etc.)

Clarifications to Option #2 Operator Trust Domain NSSE CSF functionality defined by oneM2M SCEF southbound Interface made up of 3GPP defined interfaces (e.g. Rx, Tsp, etc.) are out of scope for oneM2M NSE CSE IN-CSE (SCS) IN-AE Mcn 3GPP NW API NSSE CSF Multiple IN-CSEs could interface to a single SCEF Network Entities (HSS, MME, MTC-IWF, PCRF) SCEF IN-CSE (SCS) CSE IN-AE NSEE CSF API Mcn The SCEF may be deployed in a standalone manner. In this type of deployment the SCEF may be operated by the Mobile Network Operator or a trusted party. The trusted party may be a third party other than the IN-CSE operator. From the CSE’s point of view, the SCEF and the network entities that it connects to can collectively be considered an NSE. SCEF northbound interface API (e.g. OMA APIs) is bound to oneM2M Mcn reference point.