3GPP Interworking and use of <schedule> resource Group Name: ARC Source: Convida - Dale Seed, Bob Flynn, Catalina Mladin Meeting Date: 2018-09-17

Current use of <schedule> Cellular Enabled Device represented as a oneM2M node and hosting multiple AEs and/or an ASN/MN-CSE Network AEs monitoring/ Configuring UE’s schedule ADN-AE 1 T8 (3GPP) Mcn (oneM2M) 3GPP Network IN-AE 1 ADN-AE 2 oneM2M IN-CSE SCEF IN-AE 2 Mca ADN-AE n Uu <cseBase> 0. Devices are enrolled IN-AE n ASN/MN-CSE eNodeB 3GPP CN components 7. IN-CSE overwrites the schedule and initiates NPC procedure <m2mServiceSubscriptionProfile> |_ <serviceSubscribedNode> |_<serviceSubscribedAppRule> 5. IN-AE2 Subscribes to <schedule> 3. Device Transitions to Connected or Idle mode 2. IN-CSE Starts Monitoring UE reachability via SCEF and updates <schedule> based on notifications from 3GPP <node> 6. IN-AE 1 configures network parameters using <schedule> 8. Network parameters may get modified by the network or could be rejected. This would result in the <schedule> not in sync with the network <schedule> <schedule> <schedule> 9. IN-AE2 gets a notification of <schedule> change which could be incorrect <sub> 1. ADN-AEs (and/or ASN/MN-CSE) register and IN-CSE links them to <node> using <serviceSubscribedNode> information and creates <schedule> 4. Network sends Reachability notification to IN-CSE and schedule gets updated adn-ae1 adn-ae2

Current use of <schedule> (continued) <schedule> is being used for Monitoring Events: UE Reachability, UE Availability after DDN failure, UE Communication failure and UE loss of connectivity procedures are initiated over T8 using <schedule> resource as a trigger. On receiving the monitoring notifications from SCEF, <schedule> is updated based on the reachability status of UE indicated in the notification. Hence, <schedule> resource shall reflect the current availability of the UE at any given time. Network Parameter Configuration: Uses <schedule> resource to allow AEs to configure the network parameters (maximumResponseTime and maximumLatency). This involves an AE overwriting any existing <schedule> information that was received in the monitoring notifications from SCEF.

3GPP Interworking and <schedule> resource Problem Statement: Using <schedule> for both configuration and monitoring results in ambiguity in interpretation of the information stored in the <schedule> resource as it may reflect the current or a desired schedule of the UE. Also, network parameter procedure is a way of suggesting the network parameters which may not necessarily be accepted by the underlying network. In the cases when the suggested parameters were not accepted or modified by the network, <schedule> resource will be in an ambiguous state and will be out of sync with the network parameters.  The ambiguity arises from the fact that the <schedule> functionality is overloaded. Sometimes <schedule> resource will represent the actual current schedule and sometimes it will represent a desired schedule.

3GPP Interworking and <schedule> resource Proposed solution: Use <schedule> resource to reflect the current reachability schedule of a node(UE) based on notifications received from SCEF and observed node behavior. Use activityPatternElements attribute to request, or indicate, desired schedule of a given AE or CSE hosted on a node(UE). Updates to the activityPatternElements attribute may trigger the NPC procedure. This solution will help avoid complexities and confusion of overloading the functionality of <schedule> and using it to reflect current reachability schedule and desired schedule This solution helps raise level of abstraction w.r.t. to using 3GPP interworking features via oneM2M E.g. ADN-AEs and/or ASN/MN-CSE configure activityPatternElements and IN-CSE uses this information to manage Network Parameter Configuration and Communication/Traffic pattern configuration on behalf of all the IN-AEs, ADN-AEs and/or ASN/MN-CSE of a UE.

Appendix – More Details and an Example

Network Parameter Configuration Procedure Pre-requisite: ADN-AE or ASN/MN-CSE is hosted on UE. UE is attached to the network and is in connected state. ADN-AE or ASN/MN-CSE enrolled/registered to the IN-CSE with m2m-Ext-ID filled. This results in implicit creation of <node> and <schedule> with networkCoordinated set to true under the <node> resource. Optionally, IN-AE can subscribe to the <schedule> resource to keep track of the schedule of the ADN-AE or ASN/MN-CSE. IN-CSE implicitly initiates a UE reachability monitoring event subscription over T8 interface as a result of <schedule> creation. SCEF on receiving the monitoring event subscription, Performs configuration of monitoring event with 3GPP network elements. IN-CSE receives the Monitoring Event Subscription response from SCEF. When UE moves to the Idle state, SCEF receives the reachability report from the network and generates a Monitoring Notification for IN-CSE.

Network Parameter Configuration Procedure IN-CSE receives the Monitoring Notification from SCEF with the Idle state information of the UE. Information such as the IdleStatusTimeStamp, ActiveTime, periodicTAUTimer, edrxCycleLength is conveyed to IN-CSE. IN-CSE uses the information in the Monitoring Notification and updates the <schedule> resource to reflect the current availability status of the UE. If a subscription exists for <schedule>, a notification shall be triggered for the change in <schedule> and sent to the subscriber (e.g. IN-AE). Based on the current status of the <schedule>, an IN-AE may configure the activityPatternElements attribute of the corresponding <AE> or <remoteCSE> resource associated with the <node> resource. Also, a ADN-AE or ASN/MN-CSE may configure the activityPatternElements during registration in step 1 or during an update of <AE> or <remoteCSE>.

Network Parameter Configuration Procedure On receiving the activityPatternElements information, IN-CSE shall derive the network parameters from the activityPatternElements attribute. This is detailed in further slides. IN-CSE may initiate the Network Parameter Configuration procedure (if needed) over the T8 interface with the derived parameters from step 11. 3GPP core network validates these configured network parameters and based on the policies accept/modifies/rejects the configuration. In case of successful configuration, the core network waits for the next TAU/RAU request from UE to apply these parameters to the UE. IN-CSE receives the Network Parameter Configuration response from SCEF indicating the status of the configuration. On receiving the next UE reachability Monitoring Notification for Idle State transition of UE, IN-CSE can observe how the 3GPP network ultimately configured the UE for PSM or eDRX. IN-CSE can then update the <schedule> accordingly.

activityPatternElements attribute stationaryIndicator datasizeIndicator Since scheduleEntry is already a list, scheduleElement’s multiplicity should be 1. This needs correction in Spec scheduleElement ActivityPatternElement activityPattern scheduleElement scheduleEntry scheduleEntry stationaryIndicator activityPattern datasizeIndicator scheduleElement scheduleEntry scheduleElement scheduleEntry

Deriving NPC parameters Let’s consider a simple example of single activityPattern and single scheduleEntry in one scheduleElement stationaryIndicator activityPatternElements datasizeIndicator scheduleEntry scheduleElement activityPattern * 0-15 2,3 * * * * The possible values with this schedule entry is as shown in the below table index startTime EndTime MaxResponseTime MaxLatency 2:00 2:15 15 mins 45 mins 1 3:00 3:15 22 hr 45 mins

When to send NPC request? When a Network Parameter Configuration is performed over T8 interface, the configured network parameters (maximumResponseTime, maximumLatency and suggestedNumberOfDlPackets) will be applied only when the UE transitions to the connected state and initiates a TAU/RAU request. Hence, the configured network parameters from IN-CSE are most likely to be applied the next time UE transitions to the connected state. This can be achieved by monitoring the UE reachability notifications received from the underlying network. IN-CSE can use the information provided in the IdleStatusInfo of the monitoring notification to compute the next UE availability time and can initiate the network parameter configuration so that it gets applied when the UE transitions to the connected state and initiates a TAU/RAU request.

UE Reachability Monitoring Notifications for NPC 6. Reachability Notification is sent from MME to SCEF to In-CSE (externalID, reachabilityType and maxUEAvailability Time) 7. Idle Status Indication is sent from MME to SCEF to IN-CSE (activeTime, periodicTAUTimer, idleStatusTimestamp 4. Idle Status Indication is sent from MME to SCEF to IN-CSE (activeTime, periodicTAUTimer, idleStatusTimestamp 2. Reachability Notification is sent from MME to SCEF to In-CSE (externalID, reachabilityType and maxUEAvailability Time) periodicTAUTimer (secs) IN-CSE calculates the next UE availability time to send NPC request Paging Occassions 02:20 hrs 01:00 hrs 01:20 hrs 01:10 hrs 01:25 hrs 01:47 hrs 02:05 hrs 01:50 hrs Application, UE and eNB Implementation dependent time activeTime (secs) idleStatusTimestamp 1. UE Performs TAU. Network provides activeTime and periodicTAUTimer idleStatusTimestamp IN-CSE initiates Network Parameter procedure so that it gets applied in the next cycle. MaximumRspTime:15mins MaximuLatency:45mins 5. UE Performs TAU. Network provides activeTime and periodicTAUTimer 3. Updates to the ActivityPatternElements with scheduleElement: * 0-15 2,3 * * * * Configured Network parameters are reflected in the <schedule> resource