5.6 Monitoring Procedures

23.6823GPPArchitecture enhancements to facilitate communications with packet data networks and applicationsRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.6.0 Common Parameters

This clause describes the common parameters required for Monitoring Event procedures.

SCEF Reference ID is a parameter created by the SCEF to associate a Monitoring Event report or a deletion of a Monitoring Event to a specific Monitoring Request and the associated context information within the SCEF. SCEF Reference ID is stored by HSS, MME, SGSN, and IWK-SCEF.

NOTE 1: For the case of an individual UE, an SCEF may aggregate Monitoring Event configuration requests for the same External identifier/MSISDN from different SCS/AS instances.

NOTE 2: For the case of groups, an SCEF may aggregate Monitoring Event configuration requests for the same External Group Identifier from different SCS/AS instances.

SCEF ID indicates the SCEF to which the Monitoring Indication message has to be sent to by the HSS, MME, SGSN, or IWK-SCEF. SCEF ID is stored by the HSS, MME, SGSN, and IWK-SCEF.

SCEF Reference ID for Deletion identifies the monitoring event configuration that shall be deleted before applying the requested monitoring event configuration.

Monitoring Type identifies the specific Monitoring Event being requested.

If the Monitoring Event Configuration requested from the SCEF is for a group of UEs, the HSS includes User Identity in the monitoring event configuration.

Maximum Number of Reports is an optional parameter that indicates the maximum number of event reports to be generated by the HSS, MME, or SGSN until the associated monitoring event is considered to expire. This parameter can be used when configuring a monitoring event for an individual UE or a group. When the parameter is configured for a group, the configured value is applied to each individual UE’s monitoring event configuration. A value of one implies a single event report is to be generated which makes it equivalent to a One-time Monitoring Request.

Monitoring Duration is an optional parameter that indicates the absolute time at which the related monitoring event request is considered to expire. For Monitoring Requests for a group, this parameter applies to every group member UE.

Inclusion of either Maximum Number of Reports (with a value higher than one) or Monitoring Duration makes the Monitoring Request a Continuous Monitoring Request. For a Continuous Monitoring Request, a single Monitoring Request may generate more than one Monitoring Indication message. Support of continuous monitoring is optional.

Absence of both Maximum Number of Reports and Monitoring Duration makes the Monitoring Request a One-time Monitoring Request. For One-time Monitoring Requests, a single Monitoring Request generates only one Monitoring Report for an individual UE and for an individual group member UE.

If for a given Monitoring Event both Maximum Number of Reports and Monitoring Duration are included then the monitoring request is considered to expire as soon as one of the conditions is met.

Chargeable Party Identifier is an optional parameter included by the SCEF. It identifies the entity towards which accounting/charging functionality is performed by the involved 3GPP network elements.

MTC Provider Information is an optional parameter included by the SCEF. It identifies the MTC Service Provider and/or MTC Application. Optionally the MTC Provider Information may also be provided by the SCS/AS.

Group Reporting Guard Time is an optional parameter for group-based monitoring configuration to indicate the time for which the Monitoring Event Reporting(s) detected by the UEs in a group can be aggregated before sending them to the SCEF/SCS/AS. The value of the Group Reporting Guard time should be set less than the Monitoring Duration. For the continuous monitoring reporting, unless the Monitoring Duration has been reached, the Group Reporting Guard timer is restarted when it expires. If the time left until Monitoring Duration is less than the Group Reporting Guard Time, then the Group Reporting Guard timer shall be set to expire when the Monitoring Duration expires. If the Monitoring Duration is expired, the Group Reporting Guard Time, if running, shall be considered to expire and aggregated Monitoring Event Reporting(s) is sent to destination immediately.

Number of UEs is a parameter that is provided to the SCEF during group-based monitoring configuration to indicate the number of UEs within the group identified by the External Group Identifier. The SCEF uses this value to determine whether the monitoring event has been reported for all group member UEs.

5.6.1 Monitoring Event configuration and deletion via HSS

5.6.1.1 Configuration Procedure

Figure 5.6.1.1-1 illustrates the procedure of configuring monitoring at the HSS or the MME/SGSN. The procedure is common for various Monitoring Event types. Common parameters for this procedure are detailed in clause 5.6.0. The steps and parameters specific to different Monitoring Event types are detailed in clauses 5.6.1.3 to 5.6.1.9.

The procedure is also used for deleting a previously configured Monitoring Event either as a standalone procedure or together with configuring a new Monitoring Event between the same SCEF and the same SCS/AS, or replacing a previously configured Monitoring Event with a new Monitoring Event of the same type between the same SCEF and the same SCS/AS, or for one-time reporting if the Configured Monitoring Event is available at the configured node or cancelling the event monitoring for certain UEs (i.e. one individual UE or a sub-set of UEs) in a group of UEs for which there is a configured Monitoring Event or adding the event monitoring for certain new UEs (i.e. one individual UE or a sub-set of UEs) in a group of UEs for which there is a configured Monitoring Event.

Figure 5.6.1.1-1: Monitoring event configuration and deletion via HSS procedure

1. The SCS/AS sends a Monitoring Request (External Identifier or MSISDN or External Group ID, SCS/AS Identifier, Monitoring Type, Maximum Number of Reports, Monitoring Duration, T8 Destination Address, TLTRI for Deletion, TLTRI for Update, the External Identifier(s) or MSISDN(s) of the individual member UE(s) to be cancelled or added for an existing group event, operation indication (cancellation or addition), Group Reporting Guard Time, MTC Provider Information) message to the SCEF. The SCEF assigns a TLTRI that identifies the Monitoring Request, if a new monitoring event is being configured. The SCS/AS may perform deletion of a previously configured Monitoring Event together with configuring a new Monitoring Event. If the SCS/AS wants to perform deletion of a previously configured Monitoring Event, then it shall include TLTRI for Deletion.

If the SCS/AS wants to configure Monitoring Event for the group of UEs, the SCS/AS can send Monitoring Request message including External Group Identifier and Group Reporting Guard Time. If the SCS/AS includes External Group Identifier in the Monitoring Request message, External Identifier or MSISDN shall be ignored. A Group Reporting Guard Time is an optional parameter to indicate that aggregated Monitoring Event Reporting(s) which have been detected for the UEs in a group needs to be sent to the SCS/AS once the Group Reporting Guard Time is expired.

If the SCS/AS decides to cancel or add the monitoring event for certain UEs (i.e. one individual UE or a sub-set of UEs) in a group of UEs for which there is a configured Monitoring Event, the SCS/AS can send Monitoring Request message including the TLTRI for Update corresponding to the existing monitoring event configuration and the External Identifier(s) or MSISDN(s) of the individual member UE(s) to be cancelled or added with the operation indication which is either cancellation or addition.

NOTE 1: A relative priority scheme for the treatment of multiple SCS/AS Monitoring Requests, e.g. for deciding which requests to serve under overload condition, can be applied. This priority scheme is used locally by the SCEF, i.e. it is not used nor translated in procedures towards other functions.

2. The SCEF stores SCS/AS Identifier, T8 Destination Address, Monitoring Duration, Maximum Number of Reports and Group Reporting Guard Time, if provided. If the SCEF assigned a TLTRI, the SCEF stores the TLTRI, and also assigns it to an SCEF Reference ID. Based on operator policies, if either the SCS/AS is not authorized to perform this request (e.g. if the SLA does not allow for it) or the Monitoring Request is malformed or the SCS/AS has exceeded its quota or rate of submitting monitoring requests, the SCEF performs step 9 and provides a Cause value appropriately indicating the error. If the SCEF received a TLTRI for Update, the SCEF looks up the SCEF context pointed to by the TLTRI for Update to derive the related SCEF Reference ID. If the SCEF received a TLTRI for Deletion, the SCEF looks up the SCEF context pointed to by the TLTRI for Deletion to derive the related SCEF Reference ID for Deletion.

If the SCEF received a request to cancel the monitoring event for indicated UEs (i.e. one individual UE or a sub-set of UEs) in a group of UEs for which there is a configured Monitoring Event and if the Maximum Number of Reports applies to the monitoring event configuration, the SCEF sets the stored number of reports of the indicated UE(s) to Maximum Number of Reports.

The SCEF uses the Group Reporting Guard Time for a Monitoring Event Reporting for the group of UEs when the Monitoring Indication message is sent from the MME/SGSN to the SCEF. The SCEF sets the Group Reporting Guard Time for HSS less than the value for the SCEF received from SCS/AS in order to ensure to receive accumulated Monitoring Indication from HSS before the Group Reporting Guard Timer for SCEF is expired.

3. The SCEF sends a Monitoring Request (External Identifier or MSISDN or External Group Identifier, SCEF ID, SCEF Reference ID, Monitoring Type, Maximum Number of Reports, Monitoring Duration, SCEF Reference ID for Deletion, the External Identifier(s) or MSISDN(s) of the individual member UE(s) to be cancelled or added, operation indication (cancellation or addition), Chargeable Party Identifier, Group Reporting Guard Time, MTC Provider Information) message to the HSS to configure the given Monitoring Event on the HSS and on the MME/SGSN, if required. If the External Group Identifier is included, External Identifier or MSISDN shall be ignored. For one-time Monitoring Request of Roaming Status, the SCEF does not indicate the Group Reporting Guard Time.

NOTE 2: The MTC Provider Information in step 1 is an optional parameter. The SCEF should validate the provided MTC Provider Information and may override it to an SCEF selected MTC Provider Information based on configuration. How the SCEF determines the MTC Provider Information if not present in step 1 is left to implementation (e.g. based on the requesting SCS/AS).

4. The HSS examines the Monitoring Request message, e.g. with regard to the existence of External Identifier or MSISDN or External Group Identifier, whether any included parameters are in the range acceptable for the operator, whether the monitoring event(s) is supported by the serving MME/SGSN, whether the group-basis monitoring event feature is supported by the serving MME/SGSN, or whether the monitoring event that shall be deleted or updated is valid. The HSS optionally authorizes the chargeable party identified by Chargeable Party Identifier. If this check fails the HSS follows step 8 and provides a Cause value indicating the reason for the failure condition to the SCEF.

NOTE 3: The details of the chargeable party authorization are outside the scope of this specification.

The HSS stores the SCEF Reference ID, the SCEF ID, Maximum Number of Reports, Monitoring Duration and the SCEF Reference ID for Deletion as provided by the SCEF. For a Monitoring Request for a group, such parameters are stored for every group member UE. For a Monitoring Request with the External Identifier(s) or MSISDN(s) of the individual member UE(s) to be cancelled or added as in step 3, such parameters together with the operation indication as provided by the SCEF are stored for every indicated UE.

The HSS uses the Group Reporting Guard Time for a Monitoring Event Reporting for the group of UEs when the Monitoring Indication message is sent from the HSS to the SCEF.

4a. For group based processing, if the HSS receives the Monitoring Request with an External Group Identifier, the HSS sends a Monitoring Response (SCEF Reference ID, Number of UEs, Cause) message to the SCEF to acknowledge acceptance of the Monitoring Request immediately before beginning the processing of individual UEs indicating that Group processing is in progress. The HSS deletes the monitoring event configuration identified by the SCEF Reference ID, if it was requested.

If the HSS receives the Monitoring Request with the External Identifier(s) or MSISDN(s) of the individual member UE(s) to be cancelled or added as in step 3 and the event was monitored by the HSS, the HSS cancels or adds the event monitoring for the indicated UE(s).

4b. The SCEF sends a Monitoring Response (TLTRI, Cause) message to the SCS/AS. The Cause value indicates progress of Group processing request.

5. If required by the specific Monitoring Type and when Monitoring Event(s) is supported by the serving MME/SGSN, the HSS sends an Insert Subscriber Data Request (Monitoring Type, SCEF ID, SCEF Reference ID, Maximum Number of Reports, Monitoring Duration, SCEF Reference ID for Deletion, Chargeable Party Identifier) message to the MME/SGSN for each individual UE and for each individual group member UE. If the Monitoring Request message is for a group of UEs, for each UE group member, the HSS includes the selected External ID or the MSISDN in the monitoring event configuration and sends an Insert Subscriber Data Request message per UE to all the MME/SGSN(s) serving the members of the group. If the HSS has received in step 3 Monitoring Request with the External Identifier(s) or MSISDN(s) of the individual member UE(s) to be added, for each indicated UE group member, the HSS includes the corresponding External ID or the MSISDN in the monitoring event configuration and sends an Insert Subscriber Data Request message to the MME/SGSN(s) serving such indicated UE group member. If the HSS has received in step 3 Monitoring Request with the External Identifier(s) or MSISDN(s) of the individual member UE(s) to be cancelled and the event is monitored by MME/SGSN, the HSS includes the received value of the SCEF Reference ID within the SCEF Reference ID for Deletion towards to the MME/SGSN. Optionally, the HSS allocates a Provider-Group-ID based on the MTC Provider Information (different from the IMSI-Group-Id) and sends it to the MME/SGSN to assist the serving node(s) when selecting and differentiating configurations for a given MTC Service Provider (e.g. to delete the configurations for a specific MTC Service Provider at the MME/SGSN).

NOTE 4: How the HSS selects an External ID when multiple External IDs are associated with the same IMSI is left to implementation, e.g. based on the MTC Provider Information (if received) or the default External ID (if not received)

NOTE 5: The Provider-Group-ID is used for group operations e.g. as specified in clause 4.3.7.4.2 of TS 23.401 [7] NAS level congestion control.

6. If the MME/SGSN is configured to use an IWK-SCEF for the PLMN of the SCEF then clause 5.6.6 applies. Otherwise, the MME/SGSN verifies the request, e.g. if the Monitoring Type is covered by a roaming agreement when the request is from another PLMN or whether it serves the SCEF Reference ID for Deletion and can delete it. If this check fails, the MME/SGSN follows step 7 and provides a Cause value indicating the reason for the failure condition to the HSS. Based on operator policies, the MME/SGSN may also reject the request due to other reasons (e.g. overload or HSS has exceeded its quota or rate of submitting monitoring requests defined by an SLA).

The MME/SGSN stores the received parameters and starts to watch for the indicated Monitoring Event unless it is a One-time request and the Monitoring Event is available to the MME/SGSN at the time of sending Insert Subscriber Data Answer. The MME/SGSN deletes the monitoring configuration identified by the SCEF Reference ID for Deletion, if provided.

NOTE 6: The MME/SGSN will transfer the parameters stored for every monitoring task as part of its context information during an MME/SGSN change.

7. If the monitoring configuration is successful, the MME/SGSN sends an Insert Subscriber Data Answer (Cause) message to the HSS. If the requested Monitoring Event is available to the MME/SGSN at the time of sending Insert Subscriber Data Answer, then the MME/SGSN includes the Monitoring Event Report in the Insert Subscriber Data Answer message.

8. For single UE processing, the HSS sends a Monitoring Response (SCEF Reference ID, Cause, Monitoring Event Report) message to the SCEF to acknowledge acceptance of the Monitoring Request and the deletion of the identified monitoring event configuration, if it was requested. The HSS deletes the monitoring event configuration identified by the SCEF Reference ID, if it was requested. If the requested Monitoring Event is available to the HSS at the time of sending Monitoring Response message or was received from the MME/SGSN in step 7, then the HSS includes a Monitoring Event Report in the Monitoring Response message.

If it is a One-time request and the Insert Subscriber Data Answer includes a Monitoring Event Report, the HSS deletes the associated Monitoring Event configuration for the individual UE or for the individual group member UE.

For group-based processing, if the HSS sent the Monitoring Response in step 4a, i.e. due to having received a Monitoring Request with an External Group Identifier and if the Group Reporting Guard Time was provided in the Monitoring Request, the HSS accumulates multiple responses for the UEs of the group within the Group Reporting Guard Time. After the Group Reporting Guard Time expiration, the HSS sends a Monitoring Indication with the accumulated responses. The HSS includes UE identity(ies) and a Cause value indicating the reason for the failure in the message if the monitoring configuration of the group member failed.

NOTE 7: For the group-basis Monitoring Event configuration, the HSS may divide the accumulated Monitoring Indications into multiple messages due to e.g. limitation of the message size.

In the case of UE mobility, the HSS determines whether the new MME/SGSN supports requested Monitoring Event(s).

9a. For single UE processing, the SCEF sends a Monitoring Response (Cause, Monitoring Event Report) 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 for an individual UE and the Monitoring Response includes a Monitoring Event Report for the UE, the SCEF deletes the associated Monitoring Event configuration.

9b. For group-based processing, if no Group Reporting Guard Time was set, then the SCEF sends the Monitor Indication (TLTRI, Cause, Monitoring Event Report) message to the SCS/AS as it receives them from the HSS. Otherwise, it accumulates Monitoring Event for the UEs of the group until the expiration of Group Reporting Guard Time. Upon expiration, the SCEF sends a Monitoring Indication (TLTRI, Cause, list of (External Identifier or MSISDN, Monitoring Event Report)) message to the SCS/AS. A list of accumulated Monitoring Event Report for each UE identified by either External Identifier or MSISDN is also included.

If the Monitoring Request is a one-time request for a group of UEs or if Maximum Number of Reports is included for continuous monitoring of group of UEs, the SCEF uses the list of UE Identities that were received in step 8 and the Number of UEs parameter that was received in step 4a to check if the reports for all the individual group member UEs have been received. If the SCEF determines that all reports for all individual group member UEs have been received, the SCEF sends a request to the HSS to delete the associated Monitoring Event configuration for the group.

9c. For each Monitoring Indication message received in step 9b, the SCS/AS sends a Monitoring Indication Response (Cause) message to the SCEF. Cause value reflects successful or unsuccessful acknowledgement of Monitoring Indication message.

If the HSS detects that the current serving MME/SGSN cannot support a requested Monitoring Event or the group-basis monitoring event feature (e.g. after a UE mobility event), the HSS performs the procedures given below.

– Notify the SCEF that the configured Monitoring Event for the UE is considered to be suspended. The SCEF interprets this to mean that the network will temporarily be unable to serve the configured Monitoring Event. In this case:

– When the MME/SGSN for the UE changes (e.g. due to UE mobility), and the new MME/SGSN supports the suspended Monitoring Event, the HSS shall configure the new MME/SGSN with the Monitoring Event and notify the SCEF of resumption of the suspended Monitoring Event;

– If the criteria for Continuous Reporting expire while the Monitoring Event is suspended, the HSS and the SCEF shall independently delete the Monitoring Event.

5.6.1.2 Void

5.6.1.3 Specific Parameters for Monitoring Event: Loss of connectivity

Loss of connectivity indicates when the 3GPP network detects that the UE is no longer reachable for either signalling or user plane communication. Such condition is identified when the mobile reachability timer expires in the MME or SGSN (see TS 23.401 [7], TS 23.060 [6], when the UE detaches and when an active UE is purged (see TS 29.272 [31])). The SCS/AS may provide a Maximum Detection Time, which indicates the maximum period of time without any communication with the UE after which the SCS/AS is to be informed that the UE is considered to be unreachable.

NOTE 1: As the Maximum Detection Time of loss of connectivity determines the order of magnitude of the Periodic Update timer, the network should ensure that this Maximum Detection Time and thereby the periodic TAU/RAU timers for the UE remain above lower bound values both for preserving the battery of the UE and for managing the signalling load of the network. So for UEs with battery constraints, it should not be a small time (e.g. on the order of only a few minutes). Even for UEs without battery constraints, trying to fulfil a Maximum Detection Time of loss of connectivity on the order of a few minutes can only apply to a limited number of UEs due to the cost of signalling induced by this feature.

NOTE 2: The Maximum Detection Time of loss of connectivity is on the order of 1 minute to multiple hours.

1. The SCS/AS sets Monitoring Type to "Loss of Connectivity", and optionally adds Maximum Detection Time prior to sending Monitoring Request to the SCEF as in step 1 of clause 5.6.1.1.

2. The SCEF executes step 2 of clause 5.6.1.1.

3. The SCEF executes step 3 of clause 5.6.1.1.

4. The HSS executes step 4 of clause 5.6.1.1. In addition, it checks whether the Maximum Detection Time is within the range defined by operator policies, and, if acceptable then the HSS sets the subscribed periodic RAU/TAU timer using the value of Maximum Detection Time, if it is provided. If the Maximum Detection Time is not acceptable, the HSS rejects the request by executing step 8, and provides a Cause value indicating the reason for the failure condition to the SCEF.

If the Enhanced Multiple Event Monitoring feature is not supported and if the subscribed periodic RAU/TAU Timer was previously set by a different Monitoring Request identified by a different SCEF Reference ID for the same UE then, depending on operator configuration, the HSS either performs step 8 to reject the Monitoring Request with an appropriate Cause or accepts the request. If the HSS accepts this request, then it cancels the previously accepted Monitoring Request by including the SCEF Reference ID of that Monitoring Request in step 8.

For group based processing, if the previously accepted Monitoring Request is associated with a group of UEs and the HSS is not cancelling the previously accepted Monitoring Request for all UEs in the group, then the HSS provides the list of affected UEs (identified by External Identifier or MSISDN) as well as operation indication (cancellation or addition) to the SCEF in step 8.

If the Enhanced Multiple Event Monitoring feature is supported, and if the subscribed periodic RAU/TAU Timer was previously set by a different Monitoring Request or Network Parameter Configuration identified by a different SCEF Reference ID for the same UE, as long as the Maximum Detection Time is within the range defined by operator policies, the HSS shall accept the request. If the newly received Maximum Detection Time is lower than the provided subscribed periodic RAU/TAU timer, the HSS shall set the subscribed periodic RAU/TAU timer using the newly received Maximum Detection Time as described in clause 4.5.6.2. The HSS may notify the SCEF (which then notifies the SCS/AS) of the actual value that is being applied in the 3GPP network.

NOTE 3: Since the value of the mobile reachable timer is larger than the value of the periodic RAU/TAU timer (by four minutes as a default), the HSS may set the subscribed periodic RAU/TAU timer to a smaller value than the value of Maximum Detection Time.

5. The HSS executes step 5 of clause 5.6.1.1. In addition:

– if the Enhanced Multiple Event Monitoring feature is not supported and the HSS accepts new monitoring event configuration and cancel the existing monitoring event configuration, the HSS includes the new monitoring event configuration information, the SCEF Reference ID for Deletion of the cancelled monitoring event configuration with an appropriate Cause, and the subscribed periodic RAU/TAU Timer (if modified).

When HSS accepts new configured Monitoring Event for UEs in step 4 above, the HSS includes the new monitoring event configuration information and the subscribed periodic RAU/TAU Timer (if modified).

When HSS removes a previously configured Monitoring Event for UEs in step 4 above, the HSS also deletes the previously configured Monitoring Event in the MME/SGSN, if applicable.

– If the Enhanced Multiple Event Monitoring feature is supported, the HSS includes the new monitoring event configuration information and the subscribed periodic RAU/TAU Timer (if modified).

When HSS modifies a previously configured Monitoring Event for UE(s) in step 4 above, the HSS also updates the previously configured Monitoring Event in the MME/SGSN, if applicable.

6. The MME/SGSN executes step 6 of clause 5.6.1.1. If the MME/SGSN receives a subscribed periodic RAU/TAU timer value from the HSS, it allocates the subscribed value to the UE as the periodic TAU/RAU timer. The MME/SGSN starts watching for the expiration of the mobile reachable timer.

7. Step 7 of clause 5.6.1.1 is executed.

8. Step 8 of clause 5.6.1.1 is executed. The HSS may include the SCEF Reference ID of previously accepted Monitoring Request which needs to be cancelled and the cancellation cause. If the HSS, in step 4 above, decides to cancel Monitoring Event for indicated UEs (i.e. one individual UE or a sub-set of UEs) in the group of UEs for which there was a previously configured Monitoring Event, the HSS also includes the External Identifier or MSISDN of these indicated UEs towards the SCEF.

If the HSS, in step 4 above, decides to add Monitoring Event for indicated UEs (i.e. one individual UE or a sub-set of UEs) in the group of UEs for which there was a previously configured Monitoring Event, the HSS includes the External Identifier or MSISDN of these indicated UEs towards the SCEF.

9. Step 9 of clause 5.6.1.1 is executed. If SCEF Reference ID of previously configured Monitoring Event for cancellation is included in step 8, then the SCEF executes steps 2-5 of clause 5.6.9 using the associated TLTRI towards the associated SCS/AS.

5.6.1.4 Specific Parameters for Monitoring Event: UE reachability

For UE that is not reachable at the time of monitoring event configuration, UE reachability indicates when the UE becomes reachable for sending either SMS or downlink data to the UE, which is detected when the UE transitions to ECM-CONNECTED mode (for a UE using Power Saving Mode or extended idle mode DRX) or when the UE will become reachable for paging (for a UE using extended idle mode DRX). If the UE is reachable at monitoring event configuration, the MME shall immediately send UE reachability event report. This monitoring event supports Reachabilty for SMS and Reachability for Data. Only a One-time Monitoring Request for Reachability for SMS is supported. The SCS/AS may include the following parameters in the Monitoring Event configuration request to the SCEF:

– Reachability Type indicating whether the request is for "Reachability for SMS", or "Reachability for Data", or both.

– Optionally, Maximum Latency indicating maximum delay acceptable for downlink data transfers. Maximum Latency is used for setting the periodic TAU/RAU timer for the UE as it sets the maximum period after which a UE has to connect to the network again and thereby becomes reachable. Determined by the operator, low values for Maximum Latency may deactivate PSM.

– Optionally, Maximum Response Time indicating the time for which the UE stays reachable to allow the SCS/AS to reliably deliver the required downlink data. Maximum Response Time is used for setting the Active Time for the UE. When the UE uses extended idle mode DRX, the Maximum Response Time is used to determine how early this monitoring event should be reported to the SCS/AS before the next Paging Occasion occurs.

– Optionally, Suggested number of downlink packets indicating the number of packets that the Serving Gateway shall buffer if the UE is not reachable.

NOTE 1: As the Maximum Latency determines the order of magnitude of the Periodic Update timer, the network should ensure that this Maximum Latency and thereby the periodic TAU/RAU timers for the UE remain above lower bound values both for preserving the battery of the UE and for managing the signalling load of the network. So for UEs with battery constraints, it should not be a small time (e.g. on the order of only a few minutes). Even for UEs without battery constraints, trying to fulfil a Maximum Latency on the order of a few minutes can only apply to a limited number of UEs due to the cost of signalling induced by this feature.

NOTE 2: The Maximum Latency is on the order of 1 minute to multiple hours.

NOTE 3: The Network Parameter Configuration via SCEF feature (see clause 4.5.21) feature supersedes the option of setting Reachability Type to "configuration" during configuration of the UE Reachability Monitoring Event which is no longer recommended.

1. The SCS/AS sets Monitoring Type to "UE Reachability", and includes Reachability Type, and any combination of the following optional parameters: Maximum Latency, Maximum Response Time, Suggested number of downlink packets, and Idle Status Indication prior to sending the Monitoring Request to the SCEF as in step 1 of clause 5.6.1.1.

2. The SCEF executes step 2 of clause 5.6.1.1. In addition, it checks whether the Maximum Latency (if included), the Maximum Response Time (if included), and the Suggested number of downlink packets (if included) are within the range defined by operator policies. If not, or if the network does not support Idle Status Indication, then depending on operator policies, the SCEF rejects the request by performing step 9 of 5.6.1.1 with an appropriate cause value.

3. When "Reachability for SMS" is requested, the SCEF subscribes with the HSS by executing step 3 of 5.6.1.1 to get notified when the HSS is notified that the UE is reachable. The HSS performs the UE Reachability Notification Request procedure for getting a UE Activity Notification as described in TS 23.401 [7] and/or uses the UE Reachability function as described in TS 23.060 [6]. The Mobile-Station-Not-Reachable-Flag (MNRF) handling is described in TS 23.040 [12].

When "Reachability for Data" is requested, the SCEF executes step 3 of 5.6.1.1. In addition, if provided, it includes Maximum Latency, Maximum Response Time, and Idle Status Indication.

4. The HSS executes step 4 of clause 5.6.1.1. In addition, it checks whether the Maximum Latency, if provided, is within the range defined by operator policies, and if acceptable, the HSS sets the subscribed periodic RAU/TAU timer using the value of Maximum Latency, if it is provided. If the requested timer value is not acceptable, the HSS rejects the request by executing step 8, and provides a Cause value indicating the reason for the failure condition to the SCEF. In addition, the HSS checks whether the Suggested number of downlink packets is within the range defined by operator policies. If it is not, then the HSS rejects the request by executing step 8, and provides a Cause value indicating the reason for failure condition to the SCEF.

If the Enhanced Multiple Event Monitoring feature is not supported and if the subscribed periodic RAU/TAU timer was previously set by a different Monitoring Request identified by a different SCEF Reference ID for the same UE then, depending on operator configuration, the HSS either performs step 8 to reject the Monitoring Request with an appropriate Cause or accepts the request. In the case that the HSS accepts this request, then it cancels the previously accepted Monitoring Request by including the SCEF Reference ID of that Monitoring Request in step 8. If the HSS supports Idle Status Indication, then it includes it in step 5.

For group based processing, if the previously accepted Monitoring Request is associated with a group of UEs and the HSS is not cancelling the previously accepted Monitoring Request for all UEs in the group, then the HSS provides the indicated UEs (External Identifier or MSISDN) as well as operation indication (cancellation or addition) to the SCEF in step 8.

If the Enhanced Multiple Event Monitoring feature is supported, and if the subscribed periodic RAU/TAU Timer, or Active Time, or Suggested number of downlink packets, or any combination were previously set by a different Monitoring Request or Network Parameter Configuration identified by a different SCEF Reference ID for the same UE, as long as the Maximum Latency (if received), and Maximum Response Time (if received) and Suggested number of downlink packets (if received) are within the range defined by operator policies, the HSS shall accept the request as follows:

– If the newly received Maximum Latency is lower than the provided subscribed periodic RAU/TAU timer, the HSS shall set the subscribed periodic RAU/TAU timer using the newly received Maximum Latency.

– If the newly received Maximum Response Time is higher than the provided subscribed Active Time (i.e. previously provided Maximum Response Time), the HSS shall set the subscribed Active Time using the newly received Maximum Response Time.

– If Suggested number of downlink packets is newly received, the HSS shall add the newly received value to the currently used value of Suggested number of downlink packets if the aggregated value is within the operator defined range. If the aggregated value is not within the operator defined range, the HSS shall set the subscribed Suggested number of downlink packets according to operator defined range.

The HSS may notify the SCEF (which then notifies the SCS/AS) of the actual value of Maximum Latency and Maximum Response Time that are being applied in the 3GPP network.

5. The HSS executes step 5 of clause 5.6.1.1. In addition:

– if the Enhanced Multiple Event Monitoring feature is not supported and the HSS accepts new monitoring event configuration and cancel the existing monitoring event configuration, the HSS includes the subscribed periodic RAU/TAU timer (if modified), new received Maximum Response Time (if provided), new received Suggested number of downlink packets (if configured or provided), Idle Status Indication (if provided) and the SCEF Reference ID for Deletion of the cancelled monitoring event configuration and appropriate Cause.

When HSS accepts new configured Monitoring Event for UEs in step 4 above, the HSS includes the subscribed periodic RAU/TAU timer (if modified), Maximum Response Time (if provided), Suggested number of downlink packets (if configured or provided) and Idle Status Indication (if provided).

When HSS removes a previously configured Monitoring Event for UEs in step 4 above, the HSS also deletes the previously configured Monitoring Event in the MME/SGSN, if applicable.

– If the Enhanced Multiple Event Monitoring feature is supported, the HSS includes the subscribed periodic RAU/TAU timer (if modified), Maximum Response Time (if modified), Suggested number of downlink packets (if modified) and Idle Status Indication.

When HSS modify a previously configured Monitoring Event for UEs in step 4 above, the HSS also updates the previously configured Monitoring Event in the MME/SGSN, if applicable.

6. The MME/SGSN executes step 6 of clause 5.6.1.1 and starts watching for the UE entering connected mode. At every subsequent TAU/RAU procedure, the MME/SGSN applies the subscribed periodic RAU/TAU timer.

7. Step 7 of clause 5.6.1.1 is executed.

5.6.1.5 Specific Parameters for Monitoring Event: Location Reporting

This monitoring event allows the SCS/AS to request either the Current Location or the Last Known Location of a UE. The supported Accuracy in the network may be at different levels, which are described in clause 4.9.2. Only One-time Reporting is supported for the Last Known Location. One-time and Continuous Location Reporting are supported for the Current Location. For Continuous Location Reporting, unless a Minimum Reporting Interval was provided, the serving node(s) sends a notification every time it becomes aware of a location change. The granularity depends on the accepted Accuracy.

Minimum Reporting Interval is an optional parameter that indicates a minimum time interval between Location Reporting notifications. If this parameter was provided to the MME/SGSN, when sending each Location Reporting notification, the MME/SGSN starts a timer which runs for the duration of Minimum Reporting Interval. While the timer is running the MME/SGSN suppresses sending Location Reporting notification(s). If at least one Location Reporting notification was suppressed while the timer was running, on expiry of the timer the MME/SGSN sends location information that was contained in the latest suppressed Location Reporting notification and restarts the timer. If the MME/SGSN is relocated, the source MME/SGSN shall transfer the current value of the timer to the target MME/SGSN. The target MME/SGSN shall start the timer with the transferred value, i.e. with the time remaining from the Minimum Reporting Interval.

NOTE 1: Due to the potential increase in signalling load, it is recommended that a continuous monitoring of current location on cell level is only applied for a limited number of subscribers and/or that the Minimum Reporting Interval option is used.

1. The SCS/AS sets Monitoring Type to "Location Reporting", and adds Location Type, optionally Accuracy and optionally Minimum Reporting Interval prior to sending Monitoring Request to the SCEF as in step 1 of clause 5.6.1.1.

Location Type indicates whether the request is for Current Location or Last Known Location.

2. The SCEF executes step 2 of clause 5.6.1.1.

3. If Accuracy is included in step 1 then based on operator configuration the SCEF maps it to permissible granularity. If Accuracy is not included in step 1, the SCEF sets the granularity based on operator configuration. The SCEF adds Location Type, Accuracy and Minimum Reporting Interval (if included in step 1) prior to sending the Monitoring Request to the HSS as in step 3 of clause 5.6.1.1.

4. The HSS executes step 4 of clause 5.6.1.1.

5. Depending on the Location Type the HSS sets the "Current Location Request" (see TS 29.272 [31]), adds Accuracy and Minimum Reporting Interval (if included in step 3) prior to sending the Insert Subscriber Data Request to the MME/SGSN as in step 5 of clause 5.6.1.1.

6. The MME/SGSN executes step 6 of clause 5.6.1.1 and depending on the requested Accuracy invokes the appropriate procedures as defined in TS 23.401 [7] or TS 23.060 [6] for determining the location as requested. Unless it is a One-time request, the MME/SGSN starts watching for cell/RA/TA/eNodeB changes, depending on requested Accuracy.

If Minimum Reporting Interval is included in step 5, the MME/SGSN sends Location Reporting notifications with Minimum Reporting Interval option.

7-9. Steps 7-9 of clause 5.6.1.1 are executed and include the report of the current or last known location, depending on what was requested. Depending on operator configuration, the SCEF either maps the reported 3GPP system specific location information to the accepted Accuracy format or sends it as-is to the SCS/AS.

5.6.1.6 Specific Parameters for Monitoring Event: Change of IMSI-IMEI(SV) Association

Change of IMSI-IMEI(SV) indicates a change of the ME (IMEI(SV)) that uses a specific subscription (IMSI). It is based on the HSS being informed by the MME about the UE’s IMEI(SV) according to the procedures defined in TS 23.401 [7]. The support of this Monitoring Event by the SGSN requires the support of the Automatic Device Detection (ADD) function/feature defined in TS 23.060 [6].

1. The SCS/AS sets Monitoring Type to "Change of IMSI-IMEI(SV) Association", and adds Association Type prior to sending Monitoring Request to the SCEF as in step 1 of clause 5.6.1.1.

Association Type indicates whether change of IMEI or IMEISV to IMSI association shall be detected.

2. The SCEF executes step 2 of clause 5.6.1.1.

3. The SCEF adds Association Type prior to sending the Monitoring Request to the HSS as in step 3 of clause 5.6.1.1.

4. The HSS executes step 4 of clause 5.6.1.1.

5-7. Steps 5-7 of clause 5.6.1.1 shall not be executed for this Monitoring Event.

8-9. Steps 8-9 of clause 5.6.1.1 are executed.

5.6.1.7 Specific Parameters for Monitoring Event: Roaming Status

This monitoring event allows the SCS/AS to query the UE’s current roaming status (the serving PLMN and/or whether the UE is in its HPLMN) and to get notified when that status changes. It is based on the HSS being informed of the UE’s serving PLMN by the MME according to TS 23.401 [7] and by the SGSN according to TS 23.060 [6].

1. The SCS/AS sets Monitoring Type to "Roaming Status" prior to sending the Monitoring Request to the SCEF as in step 1 of clause 5.6.1.1. Optionally, it includes the "PLMN Information" parameter to request inclusion of the UE’s Serving PLMN ID in the Monitoring Event Report.

2. The SCEF executes step 2 of clause 5.6.1.1.

3. The SCEF includes "PLMN Information", if sent in step 1, prior to sending Monitoring Request to the HSS as in step 3 of clause 5.6.1.1.

4. The HSS executes step 4 of clause 5.6.1.1.

5-7. Steps 5-7 of clause 5.6.1.1 shall not be executed for this Monitoring Event.

8-9. Steps 8-9 of clause 5.6.1.1 are executed. The Monitoring Event Report for this event is sent in the Monitoring Response message. The Monitoring Event Report indicates whether the UE is presently roaming or not as specified in clause 5.6.3.6. If PLMN Information was requested in step 1, and the operator policies allow, then the HSS includes for each Roaming Status in the Monitoring Event Report:

– the HPLMN PLMN-Id if the UE is in the HPLMN; or

– the Visited PLMN-Id (see TS 29.272 [31]) if the UE is in the VPLMN.

5.6.1.8 Specific Parameters for Monitoring Event: Communication failure

This monitoring event allows the SCS/AS to be notified of communication failure events, identified by RAN/NAS Release Cause codes per TS 23.401 [7].

1. The SCS/AS sets Monitoring Type to "Communication Failure" prior to sending Monitoring Request to the SCEF as in step 1 of clause 5.6.1.1.

2. The SCEF executes step 2 of clause 5.6.1.1.

3. The SCEF executes step 3 of clause 5.6.1.1.

4. The HSS executes step 4 of clause 5.6.1.1.

5. The HSS executes step 5 of clause 5.6.1.1.

6. The MME/SGSN executes step 6 of clause 5.6.1.1 and starts watching for communication failure events.

7-9. Steps 7-9 of clause 5.6.1.1 are executed.

5.6.1.9 Specific Parameters for Monitoring Event: Availability after DDN Failure

This monitoring event allows the SCS/AS to be notified of availability of the UE after a DDN failure has occurred (see clause 5.7.1 Availability Notification after DDN Failure).

1. The SCS/AS sets Monitoring Type to "Availability after DDN Failure", and optionally Idle Status Indication prior to sending the Monitoring Request to the SCEF as in step 1 of clause 5.6.1.1.

2. The SCEF executes step 2 of clause 5.6.1.1.

3. The SCEF executes step 3 of clause 5.6.1.1 without adding Max Number of Reports, since the "Availability after DDN Failure" is an ongoing event that needs explicit deletion (see clause 5.6.1 for a description of Monitoring Event Deletion procedures) to cancel further reports.

4-5. Steps 4-5 of clause 5.6.1.1 are executed.

6. The MME/SGSN executes step 6 of clause 5.6.1.1 and starts watching for UE availability after DDN failure events.

7-9. Steps 7-9 of clause 5.6.1.1 are executed.

5.6.1.10 Specific Parameters for Monitoring Event: PDN Connectivity Status

This monitoring event allows the SCS/AS to be notified of the PDN Connectivity status when PDN Connections are created or deleted for the UE, and the existing PDN Connectivity status at the monitoring event configuration. The PDN Connectivity Status monitoring events report includes for each PDN Connection (that matches the requested APN if an APN has been specified) the IP address(es) allocated for the UE PDN connection(s), the PDN Types and optionally the APNs. This may be used by the SCS/AS to initiate communication with the UE, or to know when communication is no longer possible. Reporting is also done for PDN Connections using T6a/T6b connection towards the SCEF.

NOTE 1: For UE using a power saving method (e.g. eDRX or PSM), the SCS/AS can also invoke the UE Reachability monitoring event when the SCS/AS has DL data to send.

1. The SCS/AS sets Monitoring Type to "PDN Connectivity Status" and sends the Monitoring Request to the SCEF as in step 1 of clause 5.6.1.1.

2. The SCEF executes step 2 of clause 5.6.1.1.

3. The SCEF executes step 3 of clause 5.6.1.1. SCEF includes the APN for which the PDN Connectivity Status is to be monitored in the Monitoring Request to HSS. SCEF may also request PDN Connectivity Status for all PDN Connections regardless of APN (e.g. if APN is unknown in SCEF).

NOTE 2: The SCEF uses the SCS/AS Identifier and External Group Identifier, External Identifier or MSISDN that was obtained in step 1 to determine what APN will be used to enable PDN Connectivity between the UE and the SCS/AS. This determination is based on local policies.

4-5. Steps 4-5 of clause 5.6.1.1 are executed. The HSS shall check if the SCS/AS is authorized to use the PDN Connectivity Status Monitoring Event and/or if operator policies allow the PDN Connectivity Status Monitoring Event usage for this subscriber (e.g. the subscription/UE is for CIoT). If an External Identifier was included in the authorization request, the HSS maps the external identifier to IMSI and/or MSISDN and updates the SCEF ID field of the PDN subscription context for the provided APN with the requesting SCEF’s ID. Otherwise, if an External Group Identifier was included in the authorization request, the HSS authorizes the monitoring event configuration request for the received External Group Identifier, maps the External Group Identifier to a list of External Identifiers and maps the external identifiers to IMSIs and/or MSISDNs and updates the SCEF ID fields of the PDN subscription contexts for the provided APN with the requesting SCEF’s ID. If the authorization check fails, then the HSS rejects the request by executing step 8, and provides a Cause value indicating the reason for failure condition to the SCEF.

6. The MME/SGSN executes step 6 of clause 5.6.1.1 and if PDN Connection(s) already exists (that matches the requested APN if an APN has been specified), the MME shall immediately send a PDN Connectivity Status event report for the existing PDN Connections. The MME/SGSN then starts watching for any further PDN Connectivity Status events.

7-9. Steps 7-9 of clause 5.6.1.1 are executed.

5.6.2 Monitoring Events configuration and deletion directly at the MME/SGSN

5.6.2.1 Configuration Procedure

Figure 5.6.2.1-1 illustrates the procedure of configuring monitoring at the MME/SGSN. The procedure is common for various monitoring event types. Common parameters for this procedure are detailed in clause 5.6.2.2. The steps specific to different Monitoring Event types are detailed in clause 5.6.2.3. This procedure is not applicable for group configuration.

Figure 5.6.2.1-1: Monitoring event configuration and deletion directly at MME/SGSN procedure

1. The SCS/AS sends a Monitoring Request (SCS/AS Identifier, Monitoring Type, Monitoring Duration, Maximum Number of Reports, T8 Destination Address, TLTRI for Deletion) message to the SCEF. The SCEF assigns a TLTRI that identifies the Monitoring Request.

NOTE: A relative priority scheme for the treatment of multiple SCS/AS Monitoring Requests, e.g. for deciding which requests to serve under overload condition, can be applied. This priority scheme is used locally by the SCEF, i.e. it is not used nor translated in procedures towards other functions.

2. The SCEF stores the TLTRI, and also assigns it to an SCEF Reference ID. Based on operator policies, if either the SCS/AS is not authorized to perform this request (e.g. if the SLA does not allow for it) or the Monitoring Request is malformed or the SCS/AS has exceeded its quota or rate of submitting monitoring requests, the SCEF performs step 6 and provides a Cause value appropriately indicating the error. The SCEF stores the Monitoring Duration, the Maximum Number of Reports, the T8 Destination Address, the SCS/AS Identifier. If the SCEF received a TLTRI for Deletion, the SCEF looks up the SCEF context pointed to by the TLTRI to derive the related SCEF Reference ID for Deletion. If an External Group Identifier(s) was included in the request of step 1, then then flow proceeds to step 2a, otherwise steps 2a and 2b are skipped.

2a. When the SCS/AS includes External Group Identifier(s) in the monitoring request, the SCEF sends an External Group ID Resolution Request (External Group Identifier(s)) message to the HSS.

2b. The HSS resolves the External Group Identifier(s) to IMSI-Group Identifier(s) and sends an External Group ID Resolution Response (IMSI-Group Identifier(s)) message to the SCEF.

3. The SCEF sends a Monitoring Request (SCEF ID, SCEF Reference ID, Monitoring Type, Monitoring Duration, Maximum Number of Reports, SCEF Reference ID for Deletion) message to the MME(s)/SGSN(s).

4. The MME/SGSN examines whether it can accept the request from that SCEF based on operator configuration or whether it serves the SCEF Reference ID for Deletion and can delete it. If acceptable, the MME/SGSN stores SCEF ID, SCEF Reference ID, Monitoring Duration, Maximum Number of Reports and other relevant parameters unless it is a One-time request and the Monitoring Event is available to the MME/SGSN at this time. The MME/SGSN deletes the monitoring configuration identified by the SCEF Reference ID for Deletion, if provided.

5. The MME/SGSN sends a Monitoring Response (SCEF Reference ID, Cause, Monitoring Event Report) message to the SCEF to acknowledge acceptance of the Monitoring Request and to provide the requested monitoring information or to acknowledge the deletion of the identified monitoring event configuration, if it was requested.

6. The SCEF sends a Monitoring Response (TLTRI, Cause, Monitoring Event Report) message to the SCS/AS to acknowledge acceptance of the Monitoring Request and to provide the requested monitoring information in Monitoring Event Report parameter or to acknowledge the deletion of the identified monitoring event configuration, if it was requested.

5.6.2.2 Void

5.6.2.3 Specific Steps for Monitoring Event: Number of UEs present in a geographic area

This monitoring event allows the SCS/AS to ask for the number of UEs that are in the geographic area described by the SCS/AS. The SCS/AS may ask for the UEs that the system knows by its normal operation to be within the area (Last Known Location) or the SCS/AS may request the system to also actively look for the UEs within the area (Current Location). Whether the request is for Current Location or Last Known Location is indicated by the parameter Location Type. For this monitoring event only One-time reporting is supported and the Monitoring Duration as well as the Maximum Number of Reports parameters shall be ignored by the SCEF if present in the request.

In this release only Last Known Location is supported for this monitoring event.

When the SCS/AS includes External Group Identifier(s) in the monitoring request, the MME/SGSN counts the number of UEs at the requested location that have each IMSI Group Identifier(s) in its subscription information corresponding to the External Group Identifier(s) received from SCS/AS. The report that is provided by the network to the SCS/AS shall include the number of UEs in the geographic area per External Group Identifier.

NOTE 1: The system load resulting from this request may be highly dependent on Location Type.

1. The SCS/AS sets Monitoring Type to "Number of UEs present in a geographic area" and adds Location Type and Geographic Area before sending Monitoring Request to the SCEF as in step 1 of clause 5.6.2.1. The request may optionally include External Group Identifier(s).

2. The SCEF executes step 2 of clause 5.6.2.1. In addition, the SCEF maps the Geographic Area to a list of cells, eNodeBs and/or RAI(s)/TAI(s) and identifies the MMEs/SGSNs serving them by resolving the RA(s)/TA(s) to node addresses.

NOTE 2: The mapping of Geographic Areas to serving operator (MNO) network list of cells, eNodeBs and/or RAs/TAs, and the identity of the associated serving nodes (e.g. MMEs/SGSNs) is configured at the SCEF.

3. The SCEF adds Monitoring Type, Location Type, list of cells, eNodeBs and/or RAI(s)/TAI(s) before sending the Monitoring Request to those MMEs/SGSNs identified in step 3 of clause 5.6.2.1. If External Group Identifier(s) were included in step 1, then the IMSI-Group Identifier(s) that were obtained in step 2 are included in the request to the MME/SGSN.

4. The MME/SGSN executes step 4 of clause 5.6.2.1. In addition, if the request is for Last Known Location with cell or eNodeB granularity or for a location with RA/TA granularity, the MMEs/SGSNs collect all UEs for which the MME/SGSN stores a last known cell, eNodeB or RA/TA registration information that corresponds to the requested location.

NOTE 3: For Location Type Last Known Location, how the MME/SGSN determines the candidate set of UEs to be included is left to implementation.

5. The MME/SGSN executes step 5 of clause 5.6.2.1. The response from the MME/SGSN includes the count of the number of UEs at the requested location. If the request of step 3 included an IMSI-Group Identifier(s), the report from the MME/SGSN shall include the number of UEs in the geographic area per IMSI-Group Identifier(s). When IMSI-Group Identifier(s) were included in the request of step 3, the MME/SGSN may optionally, depending on operator configuration, include either the External Identifiers or the MSISDNs of the UEs that are associated with each IMSI-Group Identifier(s).

6. The SCEF combines the results from all involved MMEs/SGSNs to the total sum, i.e. the Number of UEs, and executes step 6 of clause 5.6.2.1. When External Identifiers or MSISDNs were included in the results that were received from the MME(s)/SGSN(s) in step 5, they are included in the response to the SCS/AS.

5.6.3 Reporting of Monitoring Events from the HSS or the MME/SGSN

5.6.3.1 Reporting Procedure

The following figure illustrates the common procedure flow of reporting Monitoring Events that are detected by the MME/SGSN or HSS. The steps specific to different Monitoring Event types are detailed in clauses 5.6.3.2 to 5.6.3.8.

Figure 5.6.3.1-1: Monitoring event reporting procedure

1a. A Monitoring Event is detected by the MME/SGSN at which the Monitoring Event is configured.

1b. Either a Monitoring Event is detected by the HSS, or the HSS needs to inform the SCEF about the change of status (suspend/resume/cancel) of an ongoing monitoring if an event related with the change of monitoring support at the serving node, (e.g. lack of monitoring support in MME/SGSN or revocation of monitoring authorization) is detected in the HSS. The HSS also stores the time when the Event is detected or the status is changed.

2a. The MME/SGSN sends a Monitoring Indication (SCEF Reference ID(s), Monitoring Event Report, User Identity) message to the SCEF. The SCEF store the time when it receives the Monitoring Indication.

If the Monitoring Event configuration was triggered by a One-time Monitoring Request, then the Monitoring Event configuration is deleted by the MME/SGSN upon completion of this step. If the MME/SGSN has a Maximum Number of Reports stored for this monitoring task, the MME/SGSN shall decrease its value by one. If the value of remaining number of reports is zero, the MME/SGSN shall locally remove the Monitoring Event Configuration. If the Monitoring Event configuration includes User Identity, the MME/SGSN sends the Monitoring Indication message including the User Identity. So that the SCEF can determine what groups the report pertains to, multiple SCEF Reference IDs can be included if the UE is part of multiple groups that require the same monitoring indication.

2b. When reporting for an individual UE or individual Group Member UE, the HSS sends a Monitoring Indication (SCEF Reference ID(s), External ID or MSISDN, Monitoring Event Report) message to the SCEF. External ID or MSISDN are only included if the indication is associated with an individual Group Member UE. If the Monitoring Event configuration was triggered by a One-time Monitoring Request, then the Monitoring Event configuration for the individual UE and for the individual group member UE is deleted by the HSS upon completion of this step. If the HSS has a Maximum Number of Reports stored for this monitoring task, the HSS shall decrease its value by one. Based on SCEF Reference ID, the SCEF can determine what groups the report pertains to. Multiple SCEF Reference IDs can be included if the UE is part of multiple groups that require the same monitoring indication.

If Group Reporting Guard Time was provided during the Monitoring Event configuration procedure, the HSS accumulates a Monitoring Event for the UEs of the group within the Group Reporting Guard Time. After the Group Reporting Guard Time expiration, the HSS send a Monitoring Indication (SCEF Reference ID, (Monitoring Event Report(s), External ID or MSISDN) Set, External Group ID) message to the SCEF. For each group member UE all the Monitoring Event Report and the corresponding stored time(s) are sent to the SCEF.

The External Group ID may be included in the message to indicate that the event has been detected for all group members. When the External Group ID is included in the indication, External ID(s) and MSISDN(s) are optional.

NOTE: For the group-basis Monitoring Event configuration, the HSS may divide the accumulated Monitoring Event Reports into multiple Monitoring indication messages due to the limitation of the message size.

3a. Using the SCEF Reference ID, the SCEF retrieves the associated TLTRI along with the T8 Destination Address.

If the TLTRI refers to a Monitoring Event Configuration for a single UE, the SCEF sends a Monitoring Indication (TLTRI, Cause, Monitoring Event Report) message to the identified destination. If the TLTRI refers to a group-based Monitoring Event configuration, and if no Group Reporting Guard Time was set, then the SCEF sends a Monitoring Indication (TLTRI(s), Cause, Monitoring Event Report) message to the identified destination. So that the SCEF can determine what groups the report pertains to, multiple TLTRIs can be included if the UE is part of multiple groups that require the same monitoring indication.

If the TLTRI refers to a group-based Monitoring Event Configuration, and if Group Reporting Guard Time was provided during the Monitoring Event configuration procedure, then the SCEF accumulates Monitoring Event for the UEs of the group until the Group Reporting Guard Time expiry. Upon expiration of which, the SCEF sends a Monitoring Indication (TLTRI, Cause, list of (External Identifier or MSISDN, Monitoring Event Report(s))) message to the identified destination. A list of accumulated Monitoring Event Report for each group member UE identified by either External Identifier or MSISDN is also included. For each group member UE all the received Monitoring Event Report, and the corresponding time received at SCEF or the time value sent by HSS, are sent to the SCS/AS.

For individual UE, if a report is received (step 2a or step 2b) for One-time Monitoring Request or the maximum number of reports is reached for a Continuous Monitoring Request, the SCEF requests the HSS (for monitoring events configured via HSS) to delete the related monitoring event configuration for the individual UE and deletes also its associated Monitoring Event configuration according to the procedure of clause 5.6.1.1 step 3-8.

For an individual group member UE, if a report is received (step 2a or step 2b) for One-time Monitoring Request or the maximum number of reports is reached for a Continuous Monitoring Request, based on the Number of UEs received in step 4a in clause 5.6.1.1 and local policy, the SCEF shall either:

– request the HSS (for monitoring events configured via HSS) to delete the related monitoring event configuration for the individual group member UE; or

– wait until reports for all group member UEs are complete and then request the HSS (for monitoring events configured via HSS) to delete the related monitoring event configuration.

The SCEF uses the identity of individual group member UE(s) (i.e. External Identifier or MSISDN) received in the step 2a or step 2b and the Number of UEs received in step 4a in clause 5.6.1.1 to determine if reporting for the group is complete. If it is complete, the SCEF deletes the associated Monitoring Event configuration for the group.

3b. For each Monitoring Indication message received in step 3a, the SCS/AS sends a Monitoring Indication Response (Cause) message to the SCEF. Cause value reflects successful or unsuccessful acknowledgement of Monitoring Indication message.

When the Monitoring Duration expires for a continuous Monitoring Request in the HSS, the MME/SGSN or the SCEF, then each of these nodes shall locally delete the related Monitoring Event configuration associated with the individual UE or group member UE.

5.6.3.2 Reporting Event: Loss of connectivity

1a. This monitoring event is detected as of step 1a of clause 5.6.3.1, which is when the mobile reachability timer expires, when an active UE is purged (see TS 29.272 [31]), when ISR is disabled and a UE, MME, SGSN, or HSS initiated detach occurs (see TS 23.401 [7], TS 23.060 [6]), or when ISR is enabled and a UE, MME, SGSN, or HSS initiated detach occurs and the MME or SGSN sends a Detach Notification message to the SGSN or MME with a Cause value that indicates complete, see (TS 23.401 [7]).

2a. Step 2a of clause 5.6.3.1 is executed.

3. Step 3 of clause 5.6.3.1 is executed.

5.6.3.3 Reporting Event: UE reachability

1a. This monitoring event is detected as of step 1a of clause 5.6.3.1, which is when the UE changes to connected mode or when the UE will become reachable for paging (for a UE using extended idle mode DRX).

If Maximum Response Time was included in step 5 of clause 5.6.1.4, then the MME/SGSN keeps the corresponding S1-U/Iu-PS connections of the UE for a duration of at least the Maximum Response Time less the UE’s PSM Active Timer value. If the UE uses extended idle mode DRX, the MME/SGSN takes the Maximum Response Time into account to determine when to report this monitoring event before the next Paging Occasion occurs.

1b. This monitoring event is detected as of step 1b of clause 5.6.3.1, which is when the HSS detects that the UE is reachable for SMS.

2a. Step 2a of clause 5.6.3.1 is executed. The Monitoring Event Report indicates if the event was caused by the UE changing to connected mode or by the UE becoming reachable for paging.

2b. Step 2b of clause 5.6.3.1 is executed.

3. Steps 3a-3b of clause 5.6.3.1 are executed. The Monitoring Event Report indicates if the event was caused by the UE changing to connected mode or by the UE becoming reachable for paging. If Idle Status Indication was not requested during Monitoring Event configuration, then the flow stops here.

4. UE transitions to idle mode as specified in TS 23.401 [7].

5. If Idle Status Indication was requested during Monitoring Event configuration, and the MME/SGSN supports Idle Status Indication, then MME executes step 1a, and includes the time at which the UE transitioned into idle mode, its granted active time (if PSM is enabled), the eDRX cycle length (if extended idle mode DRX is enabled), the periodic TAU/RAU timer granted to the UE by the MME and the Suggested number of downlink packets if a value was provided to the S-GW in the message.

6. The SCEF executes steps 3a-3b of clause 5.6.3.1, and includes additional parameters specified in step 5 above.

5.6.3.4 Reporting Event: Location Reporting

1a. This monitoring event is detected as of step 1a of clause 5.6.3.1, which is when the MME/SGSN detects that the UE changes location with the granularity as requested by the monitoring event configuration.

2a. Step 2a of clause 5.6.3.1 is executed.

3. Step 3 of clause 5.6.3.1 is executed. Depending on operator configuration, the SCEF either maps the reported 3GPP system specific location information to the accepted Accuracy format, sent in step 9 of clause 5.6.1.5, or sends it as-is to the SCS/AS.

5.6.3.5 Reporting Event: Change of IMSI-IMEISV association

1b. This monitoring event is detected as of step 1b of clause 5.6.3.1, which is when the HSS receives from a serving node an IMEISV that is different from the IMEISV stored by the HSS for the IMSI.

2b. Step 2b of clause 5.6.3.1 is executed.

3. Step 3 of clause 5.6.3.1 is executed. The Monitoring Indication message includes the new IMEISV.

5.6.3.6 Reporting Event: Roaming Status

1b. This monitoring event is detected as of step 1b of clause 5.6.3.1, which is when the HSS receives from a serving node a serving PLMN ID that is different from the one stored by the HSS.

2b. Step 2b of clause 5.6.3.1 is executed. If the UE is registered to different PLMNs via 3GPP and N3GPP Access Type, then the HSS includes two instances of Roaming Status in the Monitoring Indication message.

3. Step 3 of clause 5.6.3.1 is executed. The monitoring information indicates the ID of the serving PLMN and whether it is the home or a roaming PLMN. Operator policies in the SCEF may restrict the report, e.g. to indicate only whether the UE is in the home or in a roaming PLMN. The SCEF includes all Roaming Status instances that it received from the HSS.

5.6.3.7 Reporting Event: Communication failure

1a. This monitoring event is detected as of step 1a of clause 5.6.3.1, which is when the MME/SGSN becomes aware of a RAN or NAS failure event.

2a. Step 2a of clause 5.6.3.1 is executed.

3. Step 3 of clause 5.6.3.1 is executed. Based on operator configuration, the SCEF reports either the received failure cause code(s) as-is or an abstracted value.

5.6.3.8 Reporting Event: Availability after DDN failure

1a. This monitoring event is detected as of step 1a of clause 5.6.3.1, which is when the MME/SGSN becomes aware of UE availability after DDN failure.

2a. Step 2a of clause 5.6.3.1 is executed.

3. Step 3 of clause 5.6.3.1 is executed.

5.6.3.9 Reporting Event: PDN Connectivity Status

1a. This monitoring event is detected as of step 1a of clause 5.6.3.1, which is when a new PDN connection is created for the UE, or when a PDN connection is deleted for the UE, or for PDN connections that exist when the PDN Connectivity Status monitoring event is configured in the MME/SGSN. Reporting is also done for PDN Connections using T6a/T6b connection towards the SCEF.

2a. Step 2a of clause 5.6.3.1 is executed. The Monitoring Event Report indicates if the event was caused by a creation or deletion of a PDN Connection. The Monitoring Event Report indicates IP address, PDN Type, APN, 3GPP Interface Indication, and the new PDN Connectivity Status i.e. "created" or "deleted". For PDN Type Non-IP, the reported IP address may be the address allocated for SGi PtP tunnelling based on UDP/IP (see clause 4.3.17.8.3.3.2 of TS 23.401 [7]). MME leaves the IP address field empty in the Monitoring Event Report if it is not available. When reporting IPv6 address, the MME reports the IPv6 prefix when the full IPv6 address is not available. The 3GPP Interface Indication is set to "API-connectivity" for PDN Connections using T6a/T6b connection towards the SCEF, or set to "IP-connectivity" for SGi connectivity using IP based PDN Types, or set to "Other" for SGi connectivity using PDN Type Non-IP.

NOTE: If NAT is used, the reported IP Address is the UE’s private IP Address which is then different than the UE’s public IP Address. If no IP Address is assigned to the UE during PDN connection establishment (e.g. when DHCP is used after PDN connection establishment) no IP Address is included in the report.

3. Steps 3a-3b of clause 5.6.3.1 are executed. The SCEF sends the Monitoring Event Report to SCS/AS based on APN determined at Monitoring Event configuration (see clause 5.6.1.10).

5.6.4 Monitoring events configuration and reporting via PCRF

5.6.4.1 Request of monitoring event reporting

Figure 5.6.4-1 illustrates the procedure to request monitoring events reporting via PCRF with a reference to TS 23.203 [27]. The procedure is common for any monitoring event defined in clause 4.5.6.3 "Monitoring Events via PCRF".

Figure 5.6.4-1: Requesting monitoring via PCRF

1. The SCS/AS sends a Monitoring Request to the SCEF, including the information listed in step 1 of clause 5.6.1.1.

2. The SCEF checks that the SCS/AS is authorised to send monitoring request as defined in step 2 of clause 5.6.1.1. If an error is detected, then the message of step 4 is sent to SCS/AS with Cause value appropriately indicating the error and the flow stops at this step.

3. If operator policies indicate that monitoring is performed via PCRF, for the events listed in clause 4.5.6, the SCEF, acting as an Application Function, triggers the PCRF initiated-IP-CAN session modification procedure defined in TS 23.203 [27].

4. The SCEF sends a Monitoring Response (Cause, Monitoring Event Report) message to the SCS/AS. If the SCEF received a Monitoring Event Report then it includes it in the Monitoring Response message.

5.6.4.1a Request of monitoring event reporting for a group of UEs

Figure 5.6.4.1a-1 illustrates the procedure to request monitoring events reporting via PCRF for a group of UEs with a reference to TS 23.203 [27].

For monitoring for a group of UEs, the SPR is configured with the External Group Identifier the UE belongs to.

Figure 5.6.4.1a-1: Requesting monitoring via PCRF for a group of UEs

1. The SCS/AS sends a Monitoring Request to the SCEF, including the information listed in step 1 of clause 5.6.1.1 in figure 5.6.1.1-1. Maximum Number of Reports and Monitoring Duration shall not be included in the request.

2. The SCEF checks that the SCS/AS is authorised to send monitoring request as defined in step 2 of clause 5.6.1.1 in figure 5.6.1.1-1. If an error is detected, steps 3-4 are skipped, the message of step 5 is sent to SCS/AS with Cause value appropriately indicating the error, and the flow stops.

3. If operator policies indicate that monitoring is performed via PCRF, for the events listed in clause 4.5.6 applicable for a group of UEs, the SCEF triggers a Monitoring Request (SCEF Reference ID, External Group Identifier, event to monitor) over Nt interface to each PCRF in the operator´s network.

4. Each PCRF that serves a UE that is associated with the External Group Identifier stores the External Group Identifier, the event to monitor, the SCEF Reference ID, and the SCEF that sent the request and then sends a Monitoring Response message to the SCEF. If a PCRF serves no UEs that are associated with the External Group Identifier, the Monitoring Response Indicates that the PCRF is not currently serving any of the group members, and steps 6 and 7 are skipped for that PCRF.

5. The SCEF stores an indication that monitoring has been requested for the group of UEs for each PCRF that did not respond in step 4 with an indication that it is serving no group members. and then Once all PCRFs have responded in step 4, the SCEF and then sends a Monitoring Response (Cause) message to the SCS/AS.

6. Each PCRF that found a UE that has the External Group Identifier associated with it performs the following steps:

– For each UE that has an IP-CAN session established, the PCRF initiated-IP-CAN session modification procedure is triggered as defined in TS 23.203 [27]. Note that if the UE has multiple IP-CAN session established, only one PCRF initiated IP-CAN session modification is needed. The PCRF stored the SCEF address to report monitoring events for this group.

7. The PCRF sends a Monitoring Indication ((MSISDN or External ID, SCEF Reference ID, Cause) message to the SCEF. The Monitoring Indication may include reports for multiple UEs. If the Monitoring Indication does not include information for all UEs in the group, then the PCRF may send multiple Monitoring Indications to the SCEF. The PCRF indicates to the SCEF when the result for the last UE in the group is sent. The same PCRF will not send duplicate reports for the same UE to the SCEF.

NOTE: A UE may have established multiple IP-CAN sessions, each IP-CAN session under control of a different PCRFs.

8a. The SCEF sends a Monitoring Indication (TLTRI, MSISDN or External ID, Cause) message to the SCS/AS. The Monitoring Indication may include reports for multiple UEs. If the Monitoring Indication does not include information for all UEs in the group, then the SCEF may send multiple Monitoring Indications to the SCS/AS. The SCEF indicates to the SCS/AS when the result for the last UE is sent. The SCEF may wait for Monitoring Indication messages from multiple PCRFs so that it can send an aggregated response to the SCS/AS.

8b. For each Monitoring Indication message received in step 8a, the SCS/AS sends a Monitoring Indication Response (Cause) message to the SCEF. Cause value reflects successful or unsuccessful acknowledgement of Monitoring Indication message.

5.6.4.2 Common Parameters of the request reporting procedure

The following parameters are applicable when the procedure for monitoring via PCRF is used: TLTRI, Monitoring Type, Priority and T8 Destination Address.

The Monitoring types are defined in clause 4.5.6. The Priority is relevant to the SCEF, not transferred over Rx or Nt.

For single UE monitoring, the following parameters are not applicable when the procedure for monitoring via PCRF is used: SCEF Address, SCEF Reference ID, and Maximum Number of Reports. The SCEF address is not needed as Rx procedures do not require the AF address to be sent. The Maximum Number of Reports is not needed as only one time report is supported.

The following parameters are needed for the procedure for monitoring via PCRF for a request for an individual UE: UE IP address and service information (e.g. application identifier or media description or both).

The following parameters are needed for the procedure for monitoring via PCRF for a request for group of UEs: External Group identifier.

NOTE: The UE IP address provided by the SCS/AS is assumed to not be NAT’ed from the PDN-GW or GGSN to the SCS/AS at user plane. The UE IP address does not overlap with other UE IP addresses within the operator domain.

For monitoring for a group of UEs, the SPR is configured with the External Group Identifier the UE belongs to and External Identifier and the SCEF is configured with the list of PCRFs in the operator´s domain. The formats of the External Group Identifier and External Identifier are defined in clause 4.6.

5.6.4.3 Specific Parameters for Monitoring Event: Location Reporting

This monitoring event allows the SCS/AS to request the Current Location. The supported Accuracy may be at different levels which are described in clause 4.9.2. The Monitoring Event Report delivers the subscriber location and may include a time stamp to indicate when the UE was last-known to be in that location, i.e. if the current location or last-know location is provided.

NOTE: SCEF can map IP-CAN provided location to the location granularity required by SCS/AS only if it is configured to do so.

The description below is applicable if SCS/AS request Monitoring Type to "Location Reporting" for a single UE and Location Type is either "current location" or "last known location".

1. The SCS/AS sets Monitoring Type to "Location Reporting", and adds Location Type in a Monitoring Request to the SCEF as in step 1 of 5.6.4.1.

2. The SCEF executes step 2 of 5.6.4.1.

3. The SCEF triggers PCRF initiated IP-CAN session modification procedure, including the UE IP address and the Access Network information report request. The PCRF provides the Access Network Information report to the SCEF.

4. Based on operator policies, the SCEF either maps the location information to a geo-location or sends the location information to the SCS/AS. If the time stamp is included indicating that this is the last known location the SCEF indicates in the location type that this is last known location.

The description below is applicable if SCS/AS request Monitoring Type to "Location Reporting" for a group of UEs and Location Type is either "current location" or "last known location".

1. The SCS/AS sets Monitoring Type to "Location Reporting", and adds Location Type in a Monitoring Request to the SCEF as in step 1 of 5.6.4.1a.

2. The SCEF executes step 2 of 5.6.4.1a.

3. The SCEF triggers a Monitoring Request (External Group Identifier, Access Network information report request) to the PCRF over Nt interface to each PCRF in the operator´s network.

4. Each PCRF executes step 4 of 5.6.4.1a. If a PCRF serves no UEs that are associated with the External Group Identifier, steps 6 and 7 are skipped for that PCRF.

5. The SCEF executes step 5 of 5.6.4.1a.

6. The PCRF executes step 6 of 5.6.4.1a. For those UEs that have an IP-CAN session established, the PCRF initiated IP-CAN session modification procedure, including the Access Network information report request is performed. The PCRF stores the received Access Network Information for each IP-CAN session

7. The PCRF executes step 7 of 5.6.4.1a. The Monitoring Indication includes Access Network Information for each UE.

8a. The SCEF executes step 8a of 5.6.4.1a. The response includes location information for each group member UE. Based on operator policies, the SCEF either maps the Access Network Information to a geo-location or sends the Access Network Information to the SCS/AS. If the time stamp is included indicating that this is the last known location the SCEF indicates in the location type that this is last known location.

8b. The SCS/AS executes step 8b of 5.6.4.1a.

5.6.4.4 Specific Parameters for Monitoring Event: Communication Failure

This monitoring event allows the SCS/AS to be notified of communication failure events, identified by RAN/NAS or TWAN/UWAN Release Cause codes, per TS 23.203 [27].

1. The SCS/AS sets Monitoring Type to "Communication Failure" in the Monitoring Request to the SCEF sent as in step 1 of 5.6.4.1.

2. The SCEF executes step 2 of 5.6.4.1.

3. The SCEF triggers PCRF initiated IP-CAN session modification procedure, including the UE IP address and the dynamic session information. The PCRF provisions PCC Rules according to the provided session information. If the PCEF provides either RAN/NAS release code in GPRS/UTRAN/E-UTRAN, TWAN release code in TWAN or Untrusted WLAN release code the PCRF sends it to the SCEF.

4. Based on operation policies the SCEF may normalize the Release code to acceptable values per SLA that the SCS/AS accepts.

5.6.5 Reporting of Monitoring Events from the PCRF

The following figure illustrates the procedure to report Monitoring Events via PCRF. This procedure is applicable for reporting both user location information and communication failure for a single UE. This procedure does not apply to group monitoring. It is assumes that PCRF subscribes to Access Network Information report.

Figure 5.6.5-1: Reporting event procedure

1. The PCEF reports a monitoring event, either the location reporting stored in MME at Detach or dedicated bearer deactivation or a communication failure at dedicated bearer deactivation to the PCRF using PCEF initiated IP-CAN session modification or termination procedure defined in TS 23.203 [27], then the PCRF to the SCEF over Rx if the event was requested over Rx. Both events terminate the AF session to the SCEF.

2a. The SCEF retrieves the TLTRI along with the address of SCS/AS intended for Monitoring Indication message for the associated Rx session. The SCEF sends a Monitoring Indication (TLTRI, UE IP Address, Monitoring Event Report) message to the SCS/AS identified by T8 Destination Address stored in the SCEF.

2b. The SCS/AS sends a Monitoring Indication Response (Cause) message to the SCEF. Cause value reflects successful or unsuccessful acknowledgement of Monitoring Indication message.

5.6.6 Monitoring Event configuration and deletion via HSS for roaming scenarios using an IWK-SCEF

5.6.6.1 Configuration Procedure

Figure 5.6.6.1-1 illustrates the procedure of configuring monitoring events at the HSS or the MME/SGSN. The procedure is common for various Monitoring Event types. The steps and parameters specific to different Monitoring Event types are detailed in clauses 5.6.6.3 to 5.6.6.9.

The procedure is also used for deleting a previously configured Monitoring Event while configuring a new Monitoring Event between the same SCEF and the same SCS/AS.

Figure 5.6.6.1-1: Monitoring event configuration and deletion via HSS procedure

1-5. Steps of clause 5.6.1.1 are executed.

6. If the MME/SGSN is configured to use an IWK-SCEF for the PLMN of the SCEF and it is a One-time request and the Monitoring Event is available to the MME/SGSN, then the MME/SGSN collects the Monitoring Event data and includes it as Monitoring Event Report in step 10 so that the IWK-SCEF may perform normalization of Monitoring Event Report(s) according to operator policies, if required.

7-9. Steps 7-9 of clause 5.6.1.1.are executed.

10. MME/SGSN may send an Inform IWK-SCEF (Monitoring Type, SCEF ID, SCEF Reference ID, Maximum Number of Reports, Monitoring Duration, SCEF Reference ID for Deletion, Chargeable Party Identifier, Monitoring Event Report) message to the IWK-SCEF.

11. The IWK-SCEF may authorize the request, e.g. if the Monitoring Type is covered by a roaming agreement and notes the SCEF Reference ID for Deletion if available. If this authorization fails the IWK-SCEF follows step 12 and provides a Cause value indicating the reason for the failure condition to the MME/SGSN. Based on operator policies, the IWK-SCEF may also reject the request due to other reasons (e.g. overload or MME/SGSN has exceeded its quota or rate of submitting monitoring requests defined by an SLA).

If the request indicates deletion of a Monitoring Event Request, the IWK-SCEF shall perform any final operations necessary, e.g. generation of final charging information, delete any stored parameters, and send an acknowledgement to the MME/SGSN in step 12.

If the request indicates continuous reporting (new or a modification), the IWK-SCEF may authorize the request and, if authorization is successful, stores the received parameters, sends an acknowledgement to the MME/SGSN in step 12, and starts to watch for the indicated Monitoring Event(s).

If the request indicates One-time reporting, then the IWK-SCEF may authorize the request and, if authorization is successful, may perform normalization of the data according to operator policies, and sends an acknowledgement to the MME/SGSN in step 12 that contains any such normalized data.

If the request included Monitoring Event Data then the IWK-SCEF may perform normalization of the data according to operator policies.

12. If the authorization is successful, the IWK-SCEF sends an Authorization from IWK-SCEF (Cause, Monitoring Event Report) message to MME/SGSN.

The Monitoring Event Report is included if it was a One-time request, the MME/SGSN provided the Monitoring Event Report in the Inform IWK-SCEF message and the IWK-SCEF is not reporting directly to the SCEF as described clause 5.6.8.1 step 2c.

13. The MME/SGSN may verify the request, e.g. if the Monitoring Type is covered by a roaming agreement when the request is from another PLMN or whether it serves the SCEF Reference ID for Deletion and can delete it. If this check fails the MME/SGSN follows step 14 and provides a Cause value indicating the reason for the failure condition to the SCEF. Based on operator policies, the MME/SGSN may also reject the request due to other reasons (e.g. overload or HSS has exceeded its quota or rate of submitting monitoring requests defined by an SLA).

The MME/SGSN starts to watch for the indicated Monitoring Event unless it is a One-time request and the Monitoring Event is available to the MME/SGSN at the time of sending Insert Subscriber Data Answer. The MME/SGSN deletes the monitoring configuration identified by the SCEF Reference ID for Deletion, if provided.

NOTE 2: The MME/SGSN will transfer the parameters stored for every monitoring task as part of its context information during an MME/SGSN change.

14. If the monitoring event configuration status received from IWK-SCEF is different than the result reported to the HSS in Step 7, the MME/SGSN shall send the Notify Request to the HSS to inform the monitoring event configuration status received from IWK-SCEF.

15. The HSS send the Notify Answer to the MME/SGSN.

16. If the HSS receives in step 14 the monitoring event configuration status from the MME/SGSN, the HSS shall notify the SCEF that the configured Monitoring Event is cancelled for the individual UE for those monitoring event configurations for which the status received from the MME/SGSN is marked as not accepted. The HSS shall subsequently locally delete the Monitoring Event for the individual UE and for the individual group member UE if the Monitoring Event is configured in the HSS, and steps 1-5 of clause 5.6.9 are executed.

5.6.6.2 Void

5.6.6.3 Specific Parameters for Monitoring Event: Loss of connectivity

The description in clause 5.6.1.3 applies with the following clarifications.

1-5. Steps 1-5 of clause 5.6.1.3 are executed.

6. The MME/SGSN executes step 6 of clause 5.6.1.3, but if the values proposed by HSS is not acceptable to the MME/SGSN the MME/SGSN rejects the request and includes acceptable values in the reject message.

7-9. Steps 7-9 of clause 5.6.1.3 are executed.

5.6.6.4 Specific Parameters for Monitoring Event: UE reachability

The description in clause 5.6.1.4 applies with the following clarifications.

1-5. Steps 1-5 of clause 5.6.1.4 are executed.

6. The MME/SGSN executes step 6 of clause 5.6.1.4, but if the values proposed by HSS is not acceptable to the MME/SGSN the MME/SGSN rejects the request and includes acceptable values in the reject message.

7-9. Steps 7-9 of clause 5.6.1.4 are executed.

5.6.6.5 Specific Parameters for Monitoring Event: Location Reporting

The description in clause 5.6.1.5 applies with the following clarifications.

1-2. Steps 1-2 of clause 5.6.1.5 are executed.

3. If Accuracy is included in step 1 then based on operator configuration the SCEF may map it to permissible granularity at different levels, which are described in clause 4.9.2. If Accuracy is not included in step 1, the SCEF sets the granularity based on operator configuration. The SCEF adds Location Type and Accuracy prior to sending the Monitoring Request to the HSS as in step 3 of clause 5.6.1.5.

4-5. Steps 4-5 clause 5.6.1.5 are executed.

6. If the MME/SGSN is configured to use an IWK-SCEF for the PLMN of the SCEF and it is a One-time request, the MME/SGSN starts watching for cell/RA/TA/eNodeB changes, depending on requested Accuracy, and includes the location information as part of the Monitoring Event Data to the IWK-SCEF in step 7.

7. If the MME/SGSN is configured to use an IWK-SCEF for the PLMN of the SCEF, then the MME/SGSN shall execute the step 7 in clause 5.6.6.1.

8. The IWK-SCEF executes step 8 in clause 5.6.6.1, and if the request included Monitoring Event Data then the IWK-SCEF may perform normalization of the data according to operator policies.

9. The IWK-SCEF executes step 9 in clause 5.6.6.1.

10. If the MME/SGSN is configured to use an IWK-SCEF for the PLMN of the SCEF, then the MME/SGSN either starts to watch for the indicated Monitoring Event, or if the IWK-SCEF rejected the request the MME/SGSN rejects the request with the cause provided by the IWK-SCEF.

If the MME/SGSN is not configured to use an IWK-SCEF for the PLMN of the SCEF, then the MME/SGSN executes step 6 of clause 5.6.1.1 and in addition perform any actions required e.g. generating charging/accounting information.

11-13. Steps 7-9 of clause 5.6.1.1 are executed and include the report of the current or last known location, depending on what was requested. The SCEF, if not already done by the IWK-SCEF, maps eNodeB-ID/cell-ID/RAI/TAI to geo-location before reporting to the SCS/AS.

5.6.6.6 Specific Parameters for Monitoring Event: Change of IMSI-IMEI(SV) Association

The description in clause 5.6.1.6 applies as there are no VPLMN changes.

5.6.6.7 Specific Parameters for Monitoring Event: Roaming Status

The description in clause 5.6.1.6 applies as there are no VPLMN changes.

5.6.6.8 Specific Parameters for Monitoring Event: Communication failure

The description in clause 5.6.1.8 applies with the following clarifications.

1. The SCS/AS sets Monitoring Type to "Communication Failure" prior to sending Monitoring Request to the SCEF as in step 1 of clause 5.6.1.8.

2. The SCEF executes step 2 of clause 5.6.1.8.

3. The SCEF executes step 3 of clause 5.6.1.8.

4. The HSS executes step 4 of clause 5.6.1.8.

5. The HSS executes step 5 of clause 5.6.1.8.

6. Not applicable.

7. If the MME/SGSN is configured to use an IWK-SCEF for the PLMN of the SCEF, the MME/SGSN executes step 7 of 5.6.6.1.

8. The IWK-SCEF executes step 8 of clause 5.6.6.1.

9. The IWK-SCEF executes step 9 of clause 5.6.6.1.

10. The MME/SGSN executes step 6 of clause 5.6.1.8 and starts watching for communication failure events.

11-13. Steps 7-9 of clause 5.6.1.8 are executed.

5.6.6.9 Specific Parameters for Monitoring Event: Availability after DDN Failure

The description in clause 5.6.1.5 applies with the following clarifications.

1-5. Steps 1-5 are executed according to clause 5.6.6.9.

6. Not applicable.

7. If the MME/SGSN is configured to use an IWK-SCEF for the PLMN of the SCEF, the MME/SGSN executes step 7 of 5.6.6.1.

8. The IWK-SCEF executes step 8 of clause 5.6.6.1.

9. The IWK-SCEF executes step 9 of clause 5.6.6.1.

10. The MME/SGSN executes step 6 of clause 5.6.1.9.

11-13. Steps 7-9 of clause 5.6.1.9 are executed.

5.6.7 Monitoring Events configuration and deletion directly at the MME/SGSN for roaming scenarios

In this Release there is no support for Monitoring Events configuration and deletion directly at the MME/SGSN for roaming scenarios.

5.6.8 Reporting of Monitoring Events from the HSS or the MME/SGSN for roaming scenarios

5.6.8.1 Reporting Procedure

The following figure illustrates the common procedure flow of reporting Monitoring Events that are detected by the MME/SGSN or HSS for roaming scenarios. The steps specific to different Monitoring Event types are detailed in clauses 5.6.8.2 to 5.6.8.8.

Figure 5.6.8.1-1: Monitoring event reporting procedure for roaming scenarios

1a. A Monitoring Event is detected by the MME/SGSN at which the Monitoring Event is configured.

2a. If the MME/SGSN is not configured to use an IWK-SCEF for the PLMN of the SCEF then the MME/SGSN executes step 2a in clause 5.6.3.1. The MME/SGSN in addition generates any required charging/accounting information.

2b. The HSS executes step 2b in clause 5.6.3.1.

2c. If the MME/SGSN is configured to use an IWK-SCEF for the PLMN of the SCEF, then the MME/SGSN sends a Monitoring Indication (SCEF Reference ID(s), Monitoring Event Report, User Identity) message to the IWK-SCEF. If the Monitoring Event configuration was triggered by a One-time Monitoring Request, then the Monitoring Event configuration is deleted by the MME/SGSN upon completion of this step. If the MME/SGSN has a Maximum Number of Reports stored for this monitoring task, the MME/SGSN shall decrease its value by one. When the Monitoring Duration expires for a continuous Monitoring Request in the HSS, the MME/SGSN or the SCEF, then each of these nodes shall locally delete the related Monitoring Event configuration associated with the individual UE or group member UE. So that the SCEF can determine what groups the report pertains to, multiple SCEF Reference IDs can be included if the UE is part of multiple groups that require the same monitoring indication.

The IWK-SCEF sends a Monitoring Indication (SCEF Reference ID(s), Monitoring Event Report, User Identity) message to the SCEF. If the IWK-SCEF has a Maximum Number of Reports stored for this monitoring task, the IWK-SCEF shall decrease its value by one. When the maximum number of reports is reached for a Continuous Monitoring Request or in the case of a One-time Monitoring Request, the IWK-SCEF ends the reporting on the SCEF Reference ID. So that the SCEF can determine what groups the report pertains to, multiple SCEF Reference IDs can be included if the UE is part of multiple groups that require the same monitoring indication.

3. The SCEF executes step 3 in clause 5.6.3.1.

When the Monitoring Duration expires for a continuous Monitoring Request in the HSS, the MME/SGSN, the IWK-SCEF (if it is used in the visited PLMN) or the SCEF, then each of these nodes shall locally delete the related Monitoring Event configuration associated with the individual UE or group member UE.

5.6.8.2 Reporting Event: Loss of connectivity

1a. This monitoring event is detected as of step 1a of clause 5.6.8.1, which is when the mobile reachability timer expires, when an active UE is purged (see TS 29.272 [31]), when ISR is disabled and a UE, MME, SGSN, or HSS initiated detach occurs (see TS 23.401 [7], TS 23.060 [6]), or when ISR is enabled and a UE, MME, SGSN, or HSS initiated detach occurs and the MME or SGSN sends a Detach Notification message to the SGSN or MME with a Cause value that indicates complete, see (TS 23.401 [7]).

2. Dependent on MME/SGSN configuration step 2a or 2c of clause 5.6.8.1 is executed.

3. Step 3 of clause 5.6.8.1 is executed.

5.6.8.3 Reporting Event: UE reachability

1a. This monitoring event is detected as of step 1a of clause 5.6.8.1, which is when the UE changes to connected mode or when the UE will become reachable for paging (for a UE using extended idle mode DRX).

If Maximum Response Time was included in step 5 of clause 5.6.6.4, then the MME/SGSN keeps the corresponding S1-U/Iu-PS connections of the UE for a duration of at least the Maximum Response Time less the UE’s PSM Active Timer value. If the UE uses extended idle mode DRX, the MME/SGSN takes the Maximum Response Time into account to determine when to report this monitoring event before the next Paging Occasion occurs.

2. Dependent on MME/SGSN configuration step 2a or 2c of clause 5.6.8.1 is executed. The Monitoring Event Report indicates if the event was caused by the UE changing to connected mode or by the UE becoming reachable for paging.

3. Step 3 of clause 5.6.8.1 is executed.

5.6.8.4 Reporting Event: Location Reporting

1a. This monitoring event is detected as of step 1a of clause 5.6.8.1, which is when the MME/SGSN detects that the UE changes location with the granularity as requested by the monitoring event configuration.

2. Dependent on MME/SGSN configuration step 2a or 2c of clause 5.6.8.1 is executed. If step 2c is executed, then the IWK-SCEF maps the reported 3GPP system specific location information to a geo-location and forwards it to the SCEF.

3. Step 3 of clause 5.6.8.1 is executed. The SCEF may map the reported 3GPP system specific location information to a geo-location and reports it.

5.6.8.5 Reporting Event: Change of IMSI-IMEI(SV) association

This monitoring event is executes as in clause 5.6.3.5.

5.6.8.6 Reporting Event: Roaming Status

This monitoring event is executes as in clause 5.6.3.6.

5.6.8.7 Reporting Event: Communication failure

1a. This monitoring event is detected as of step 1a of clause 5.6.8.1, which is when the MME/SGSN becomes aware of a RAN or NAS failure event.

2. Dependent on MME/SGSN configuration step 2a or 2c of clause 5.6.8.1 is executed. If step 2c is executed, then the IWK-SCEF either forwards the received failure cause code(s) as-is or an abstracted value to the SCEF.

3. Step 3 of clause 5.6.8.1 is executed. Based on operator configuration, the SCEF reports either the received failure cause code(s) as-is or an abstracted value.

5.6.8.8 Reporting Event: Availability after DDN failure

1a. This monitoring event is detected as of step 1a of clause 5.6.8.1, which is when the MME/SGSN becomes aware of UE availability after DDN failure.

2. Dependent on MME/SGSN configuration step 2a or 2c of clause 5.6.8.1 is executed.

3. Step 3 of clause 5.6.8.1 is executed.

5.6.8.9 Reporting Event: PDN Connectivity Status

This monitoring event executes as in clause 5.6.3.9.

5.6.9 Network-initiated Explicit Monitoring Event Deletion Procedure

The procedure is used by the SCEF towards the SCS/AS to delete a previously configured Monitoring Event.

Figure 6.5.9-1: Network-initiated Explicit Monitoring Event Deletion Procedure

0. A Monitoring Event configuration procedure according to clause 5.6.1 or clause 5.6.6 has already executed successfully.

1. The HSS returns a Monitoring Response message or triggers a Monitoring Indication message towards the SCEF and includes SCEF Reference ID of a previously accepted Monitoring Event which needs cancellation due to certain conditions such as:

– For a single UE or a sub-set of UEs in a group for which there is an active monitoring event configuration, the monitoring event configuration is no longer valid (e.g. the previously subscribed periodic RAU/TAU Timer from one SCS/AS is being overwritten by another SCS/AS and the Enhanced Multiple Event Monitoring is not supported); or

– For group based processing, if a given External Group ID for which a previous group request was accepted is now no longer valid; or

– For group based processing, for UEs belonging to a group for which there is an active group based event configuration, the UE’s subscription is deleted from the HSS or the UE’s event monitoring is cancelled.

1b. The HSS also deletes the previously configured Monitoring Event in the MME/SGSN, if applicable, e.g. at deletion of an External Group ID in the HSS.

2. Based on the SCEF Reference ID for cancellation included in step 1a or local context lookup in step 1b, the SCEF determines TLTRI of the configured Monitoring Event which needs cancellation.

3. The SCEF sends a Cancel Monitoring Event Request (TLTRI, Cause) message to the T8 Destination Address. Cause value indicates the reason for cancellation of the previously configured Monitoring Event. If SCEF receives MSISDN(s) or External Identifier(s) in step 1 for group based processing and the Maximum Number of Reports applies to the monitoring event configuration, the SCEF sets the stored number of reports of the indicated UE(s) to Maximum Number of Reports and includes such UE identifier(s) in the Cancel Monitoring Event Request to the SCS/AS. If SCEF determines that the reporting for the group is complete based on the update above, the SCEF deletes the associated Monitoring Event configuration and request the HSS to delete the related monitoring event configuration for the group.

4. The SCS/AS sends a Cancel Monitoring Event Response (Cause) message to the SCEF. Cause indicates the result of the procedure. For single UE configuration, the SCS/AS deletes T8 context associated with the TLTRI received in step 3; for group based configuration, the SCS/AS deletes T8 context associated with the TLTRI received in step 3 when the event monitoring of the last UE in the group is cancelled.

5. The SCEF deletes T8 context and the SCEF EPS Bearer context associated with the TLTRI sent in step 3.