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

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

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

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

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

6. Appendix – More Details and an Example

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

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

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

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

11. Deriving NPC parameters
Let’s consider a simple example of single activityPattern and single scheduleEntry in one scheduleElement
stationaryIndicator
activityPatternElements
datasizeIndicator
scheduleEntry
scheduleElement
activityPattern
* ,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

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

13. 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:
* ,3 * * * *
Configured Network parameters are reflected in the <schedule> resource