1. 3GPP SCEF Interworking Call Flows
Group Name: ARC #20
Source: InterDigital
Contact: Paul Russell, Jr., Mike Starsinic,
Meeting Date:
Agenda Item: TBD

2. Background Information
In S / TP , SA2 informed oneM2M about the new R13 Service Exposure features and referred oneM2M to TS
TS provides call flows that demonstrate how an SCS (IN-CSE or MN-CSE) can use the SCEF to access the services of the Mobile Core Network. “Services” include:
Configuring Communication Patterns
Configuring Session QoS
Configuring Session Sponsorship (Starting and stopping sponsorship at session start up and during the session)
Background Data Transfer (Requesting a Time Window, Identifying the Selected Time Window)
Monitoring (Configuring a Monitoring Event, Deleting a Monitoring Event, Receiving a Monitoring Report)
Support for High Latency Communication
Mobile Core Network Issue Reports (Requesting Reports, Receiving Reports, Stopping Reports)
Triggering (Requesting, Recalling, and Replacing)
Group Messaging (via MBMS)

3. Purpose of this Contribution
In contribution (ARC ) we show the different ways that the oneM2M System accesses the Services of the Mobile Core Network.
By accessing an SCEF that is external to the oneM2M System (i.e. the SCEF is not part of an NSSE).
By accessing an SCEF that in internal to the oneM2M System (i.e. the SCEF is part of an NSSE).
In both deployment scenarios, the oneM2M System must provide the SCEF with information elements in order to access the 8 Mobile Core Network Services that are listed on the previous slide.
This contribution hopes to start the discussion of how the information elements should be populated by the oneM2M System.

4. Configuring Communication Patterns (1 of 3)
In R13 (TS , Section ), 3GPP added the following:
Predictable communication patterns (CP) of a UE may be provided by the Application Server to the SCEF in order to enable network resource optimizations for such UE(s). The SCEF filters the CP parameters and forwards them to the HSS, which provides them to the MME. The MME may use the CP parameters as input to derive the CN assisted eNB parameters as described in TS 23.401 [7]. This feature is applicable to UEs served over the E-UTRAN access.

5. Configuring Communication Patterns (2 of 3)
The SCS/AS sends an Update Request (External Identifier or MSISDN, SCS/AS Identifier, SCS/AS Reference ID, CP parameter set(s), validity time(s)) message to the SCEF.
The SCEF sends the Update Response (SCS/AS Reference ID, Cause) message to inform the SCS/AS whether the provision of the CP parameter set(s) was successful.
This call flow and the notes on steps 1 and 6 are copied from section of 3GPP TS
When providing the communication patterns to the SCEF, the oneM2M System needs to provide External Identifier or MSISDN of the UE, SCS/AS Identifier, SCS/AS Reference ID, CP parameter set(s), and validity time(s) to the SCEF and understand the Cause reply.

6. Configuring Communication Patterns (3 of 3)
Table of TS defines the set of possible communication pattern attributers.
CP parameter
Description
1) Periodic communication indicator
Identifies whether the UE communicates periodically or not, e.g. only on demand. [optional]
2) Communication duration time
Duration interval time of periodic communication [optional, may be used together with 1)]
Example: 5 minutes
3) Periodic time
Interval Time of periodic communication [optional , may be used together with 1)]
Example: every hour
4) Scheduled communication time
Time zone and Day of the week when the UE is available for communication [optional]
Example: Time: 13:00-20:00, Day: Monday
5) Stationary indication
Identifies whether the UE is stationary or mobile [optional]
The contents of the table above are copied from Table of TS

7. Configuring Session QoS (1 of 2)
In R13 (TS , Section ), 3GPP added the following:
The 3rd party SCS/AS may request that a data session to a UE that is served by the 3rd party service provider (AS session) is set up with a specific QoS (e.g. low latency or jitter) and priority handling. This functionality is exposed via the SCEF towards the SCS/AS.

8. Configuring Session QoS (2 of 2)
When setting up the connection between SCS/AS and the UE with required QoS for the service, the SCS/AS sends an On-demand QoS request message (UE IP address, SCS/AS Identifier, SCS/AS Reference ID, Description of the application flows reference to a pre-defined QoS) to the SCEF. Optionally, a period of time or a traffic volume for the requested QoS can be included in the SCS/AS request.
The SCEF sends an On-demand QoS response message (SCS/AS Identifier, SCS/AS Reference ID, Result) to the SCS/AS. Result indicates whether the QoS request is granted or not.
This call flow and the notes on steps 1 and 5 are copied from section 5.11 of 3GPP TS
The oneM2M System needs to provide UE IP address, SCS/AS Identifier, SCS/AS Reference ID, a sescription of the application flows, and a reference to a pre-defined QoS to the SCEF and understand the Result reply.

9. Changing the Chargeable Party (1 of 3)
In R13 (TS , Section ), 3GPP added the following:
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.

10. Changing the Chargeable Party (2 of 3)
When setting up the connection between the AS and UE, the SCS/AS may request to become the chargeable party for the session to be set up by sending a Set chargeable party request message (SCS/AS Identifier, SCS/AS Reference ID, Description of the application flows, sponsor information, Sponsoring Status) to the SCEF, including optionally a usage threshold. The Sponsoring Status indicates whether sponsoring is started or stopped, i.e. whether the 3rd party service provider is the chargeable party or not.
The SCEF sends a Set chargeable party response message (SCS/AS Identifier, SCS/AS Reference ID, Result) to the SCS/AS. Result indicates whether the request is granted or not.
This call flow and the notes on steps 1 and 4 are copied from section of 3GPP TS
When setting up sponsorship during session start up, the oneM2M System needs to provide SCS/AS Identifier, SCS/AS Reference ID, a description of the application flows, sponsor information, and Sponsoring Status to the SCEF and understand the Result reply.

11. Changing the Chargeable Party (3 of 3)
For the ongoing AS session, the SCS/AS may send a Change chargeable party request message (SCS/AS Identifier, SCS/AS Reference ID, Sponsoring Status) to the SCEF, including optionally a usage threshold. The Sponsoring Status indicates whether sponsoring is enabled or disabled, i.e. whether the 3rd party service provider is the chargeable party or not.
The SCEF sends a Change chargeable party response message (SCS/AS Identifier, SCS/AS Reference ID, Result) to the SCS/AS. Result indicates whether the request is granted or not.
This call flow and the notes on steps 1 and 4 are copied from section of 3GPP TS
When changing sponsorship during a session, the oneM2M System needs to provide SCS/AS Identifier, SCS/AS Reference ID, and Sponsoring Status to the SCEF and understand the Result reply.

12. Background Data Transfer (1 of 2)
In R13 (TS , Section 4.5.9), 3GPP added the following:
The 3rd party SCS/AS requests a time window and related conditions from the SCEF for background data transfer to a set of UEs …………………..The SCEF passes this information to a selected PCRF. The PCRF shall determine one or more transfer policies each including a recommended time window for the data transfer together with a maximum aggregated bitrate for the expected volume of data and a reference to the applicable charging rate during the time window and provide them to the SCEF together with a reference ID. The SCEF shall forward the reference ID and the transfer policies to the 3rd party SCS/AS. If more than one transfer policy was received, the 3rd party SCS/AS needs to select one of them and inform the SCEF about the selected transfer policy ………………..

13. Background Data Transfer (2 of 2)
A 3rd party SCS/AS sends a Background data transfer request (SCS/AS Identifier, SCS/AS Reference ID, Volume per UE, Number of UEs, Desired time window) message to the SCEF. The Volume per UE describes the volume of data the SCS/AS expects to be transferred per UE. Number of UEs describes the expected amount of UEs participating in the data transfer. Desired time window describes the time interval during which the SCS/AS wants to realize the data transfer. Optionally, the SCS/AS can provide a geographic area information.
The SCEF forwards the reference ID and the transfer policies to the 3rd party SCS/AS by sending a Background data transfer response (SCS/AS Identifier, reference ID, Possible transfer policies) message. The SCS/AS stores the reference ID for the future interaction with the PCRF.
If more than one transfer policy was received, the 3rd party SCS/AS shall select one of them and send another Background data transfer request (SCS/AS Identifier, SCS/AS Reference ID, Selected transfer policy) message to inform the SCEF and PCRF about the selected transfer policy.
This call flow and the notes on steps 1, 4, 5, and 6 are copied from section 5.9 of 3GPP TS
The SCEF confirms the transfer policy selection to the 3rd party SCS/AS by sending a Background data transfer response (SCS/AS Identifier) message.
When setting up a background data transfer, the oneM2M System needs to provide SCS/AS Identifier, SCS/AS Reference ID, Volume per UE, Number of UEs, and Desired time window to the SCEF and understand the Transfer Policies in the reply.

14. In R13 (TS 23.682, Section 4.5.6), 3GPP added the following:
Monitoring
In R13 (TS , Section 4.5.6), 3GPP added the following:
The Monitoring Events feature is intended for monitoring of specific events in 3GPP system and making such monitoring events information available via the SCEF. …………………… If such an event is detected, the network might be configured to perform special actions, e.g. limit the UE access. Configuration and reporting of the following monitoring events may be supported:
Monitoring the association of the UE and UICC and/or new IMSI-IMEI-SV association;
UE reachability;
Location of the UE, and change in location of the UE;
Loss of connectivity;
Communication failure;
Roaming status (i.e. Roaming or No Roaming) of the UE, and change in roaming status of the UE; and
Number of UEs present in a geographical area; and
Availability after DDN failure.

15. Monitoring Configuration (1 of 2)
The SCS/AS sends a 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) message to the SCEF.
The SCEF sends a Monitoring Response (SCS/AS Reference ID, Cause) message to the SCS/AS to acknowledge acceptance of the Monitoring Request and the deletion of the identified monitoring event configuration, if it was requested. If the SCEF received a Monitoring Event Report then it includes the Monitoring Event Report in the Monitoring Response message. If it is a One-time request and the Monitoring Response includes a Monitoring Event Report, the SCEF deletes the associated Monitoring Event configuration.
This call flow and the notes on steps 1 and 9 are copied from section of 3GPP TS
When configuring, deleting, or replacing a monitoring event configuration, the oneM2M System needs to provide 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 to the SCEF and understand the Cause and Report that may be in the reply.

16. Monitoring Configuration (2 of 2)
Note that monitoring events can be configured in a one-time manner (Maximum Number of Reports=1), limited to a specific number of reports manner (Maximum Number of Reports > 1), can be time based (Monitoring Duration) or can be based on time and a maximum number of reports.
The previous slide shows the generic procedure for configuring a monitoring event. Depending on the type of event that is being monitored, other parameters may need to be provided by the oneM2M System.
When configuring a Loss of Connectivity Monitoring Event, the oneM2M System may provide a maximum detection time.
When configuring a Reachability Report Event, the oneM2M System may indicate if is interested in reachability for SMS or Data, the maximum latency for DL data transfers, how long the UE should stay reachable, and the number of downlink packets that should be buffered by the Serving GW when the UE is not reachable.
When configuring a Location Report Monitoring Event, the oneM2M System provides the Location Type (Current Location or Last Known Location) and optionally Accuracy (Accuracy could be at cell level (CGI/ECGI), eNB, LA/TA/RA level, Presence Area reporting level, or other formats..).
When configuring a Change of IMSI-IMEI-SV association event, the oneM2M system needs to indicate if the event is for a change of IMEI or IMEISV to IMSI association.
When the oneM2M System configures a Roaming Status monitoring report, it may optionally include a "PLMN Information" parameter that indicates a request to include the UE's Serving PLMN ID in the Monitoring Event Report.
When the oneM2M System configures a “Number of UE’s in a Geographical Area” report, the oneM2M System adds Location Type and Geographic Area in the monitoring request.

17. Monitoring Reports
Using the SCEF Reference ID, the SCEF retrieves the associated SCS/AS Reference ID along with the Monitoring Destination Address or, if not available, the address of the SCS/AS as destination for the Monitoring Indication message. The SCEF sends a Monitoring Indication (SCS/AS Reference ID, External ID or MSISDN, Monitoring Information) message to the identified destination..
This call flow and the note on step 9 are copied from section of 3GPP TS
When receiving a monitoring report, the oneM2M System needs to understand the Monitoring Information that will be in the reply.
The Monitoring Information will depend on the type of monitoring report.
The Monitoring Destination node will often be the NSSE that configured the monitoring event, but it does not need to be. Event Monitoring can be configured by one NSSE and reports can be sent to another NSSE.

18. Support for High Latency Communication (1 of 3)
"High latency" refers to the initial response time before normal exchange of packets is established.
3GPP provides 3 High Latency configuration options that should be configured by the oneM2M System
Serving GW Buffering – The oneM2M System has the ability to configure the UE’s use of S-GW Buffering Feature by configuring 2 parameters. These parameters are configured when the one M2M Systems sets up a reachability notification request (as described in the monitoring events section)
The Suggested Number of downlink packets parameter indicates the number of packets that the Serving Gateway shall buffer in case the UE is not reachable.
UE’s Maximum Latency – This time is used by the network to determine how ling the UE is expected to be unreachable and how long the S-GW should buffer packets.
Power Savings Mode – The oneM2M System has the ability to configure the UE’s use of Power Savings Mode by configuring 2 parameters. These parameters are configured when the one M2M Systems sets up a reachability notification request (as described in the monitoring events section)
UE’s Maximum Latency – This time is used by the network to determine if Power Saving Mode (PSM) should be enabled for the UE and to determine how long the UE should stay in the power savings state (and be unreachable for mobile terminated communications).
UE’s Maximum Response Time – This timer is used by the network to determine how long a UE should stay reachable for Mobile terminated communications after it has been in PSM.
Reachability Notifications – Two flavours of reachability notifications are available to the oneM2M System.
The ability to Request a notification when the UE becomes available (as described in the monitoring events section)
The ability to request a notification when the UE becomes available after there has been a downlink data delivery failure.

19. Support for High Latency Communication (2 of 3)
The application requests that the SCEF register a trigger to be notified when the UE becomes available after downlink data delivery fails.
The SCEF responds to the SCS/AS regarding the trigger request.
This call flow and the notes on steps 1 and 4 are copied from section of 3GPP TS
When configuring a monitoring report for reachability, the oneM2M System may indicate that it only wants to receive the report if there has been a downlink data delivery failure.

20. Support for High Latency Communication (3 of 3)
The application sends downlink data.
The MME initiates paging for UE but receives no response or the UE is in Power Saving Mode
The SCEF notifies the application that the UE is available.
The application sends the queued data toward the UE.
This call flow and the notes on steps 1, 3, 9 and 11 are copied from section of 3GPP TS
The oneM2M System needs to be able to recognize that there has been a downlink data delivery failure, buffer the downlink data and wait for the notification from the SCEF before sending data again.

21. Network Issue Reports (1 of 4)
In R13 (TS , Section 4.5.8), 3GPP added the following:
The SCS/AS may request the SCEF for being notified about the network status in a geographical area. The SCS/AS can request for a one-time reporting of network status or a continuous reporting of network status changes.

22. Network Issue Reports (2 of 4)
When the SCS/AS needs to retrieve NSI, the SCS/AS sends a Network Status Request (Geographical area, SCS/AS Identifier, SCS/AS Reference ID, Duration, Threshold) message to the SCEF. Duration indicates the time for which a continuous reporting is requested. The absence of Duration indicates a one-time reporting. Threshold indicates a range at which the SCS/AS wishes to be informed of the network status. Multiple Threshold values may be included..
The SCEF send a Network Status Report (SCS/AS Reference ID, NSI) message to the SCS/AS.
This call flow and the notes on steps 1 and 6 are copied from section of 3GPP TS
When requesting a one-time or periodic network status report, the oneM2M System needs to provide Geographical area, SCS/AS Identifier, SCS/AS Reference ID, and Duration, Threshold to the SCEF and understand the NSI in the reply.

23. Network Issue Reports (3 of 4)
Triggered by a NSI change (derived in step 3) that is crossing a Threshold (if provided by the SCS/AS), the SCEF sends a Network Status Report (SCS/AS Reference ID, NSI) message to the SCS/AS.
The SCS/AS acknowledges the report to the SCEF.
This call flow and the notes on steps 4 and 5 are copied from section of 3GPP TS
When continuous reporting is configured, the oneM2M System needs to accept the NSI in the notification from the SCEF and acknowledge it.

24. Network Issue Reports (4 of 4)
When the SCS/AS needs to terminate an ongoing continuous reporting of network status, the SCS/AS sends a Cancel Network Status Request (SCS/AS Identifier, SCS/AS Reference ID) message to the SCEF.
If the SCS/AS requested to terminate an ongoing continuous reporting of network status in step 1b, the SCEF sends a Cancel Network Status Response (SCS/AS Reference ID) message to the SCS/AS.
This call flow and the notes on steps 1b and 3b are copied from section of 3GPP TS
When continuous reporting is configured, the oneM2M System will eventually need to turn off the reports by providing the SCEF with the SCS/AS Identifier and SCS/AS Reference ID that are associated with the reports.

25. Device Triggering
Other than the introduction of the SCEF, there were no major changed to Device Triggering in R12.
SMS Based Device Trigger requests can be routed through the SCEF and the SCEF will forward the request to the MTC-IWF. Thus, the SCEF API can hide the underlying Tsp interface and Diameter interaction from the oneM2M system.

26. In R13 (TS 23.682, Section 4.5.5), 3GPP added the following:
Group Messaging (1 of 2)
In R13 (TS , Section 4.5.5), 3GPP added the following:
Group message delivery is intended to efficiently distribute the same content to the members of a group that are located in a particular geographical area on request of the SCS/AS via SCEF.
The specific procedure handling for group message delivery using MBMS is described in clause  The group message delivery using MBMS has limited applicability and does not support all the scenarios, e.g. UEs not supporting MBMS, UEs located in areas where MBMS is not deployed.

27. Group Messaging ( 2 of 2)
If there is no assigned TMGI for an External Group Id, the SCS/AS sends the Allocate TMGI Request (External Group ID, SCS Identifier) message to the SCEF. The SCS/AS may determine the IP address(es)/port(s) of the SCEF by performing a DNS query using the External Group Identifier or using a locally configured SCEF identifier/address. The SCEF checks that the SCS/AS is authorized to request TMGI allocation.
The SCEF sends the received TMGI and expiration time information to the SCS/AS.
The SCS/AS sends the Group Message Request (External Group Identifier, SCS Identifier, delivery content, location/area information, RAT(s) information, TMGI) message to the SCEF. The location/area information indicated by the SCS/AS may be the geographic area information.
The SCEF sends a Group Message Confirm message to the SCS/AS to confirm that the Request has been accepted for delivery to the group.
Before sending a group message, the oneM2M System and Mobile Core Network need to be provisioned with which UE’s are part of the External Group ID.
The oneM2M System needs to obtain a TMGI for the group (Steps 1 and 4).
The oneM2M System needs to provide the TMGI to the UE’s that are part of the group and each UE needs to listen (Step 5).
Then the oneM2M System can deliver the group message to the SCEF and associated External Group Identifier, SCS Identifier, delivery content, location/area information, RAT(s) information, and TMGI