Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.682  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   4.2   4.3…   4.4…   4.5…   4.5.7…   4.5.14…   4.6…   5…   5.3…   5.5…   5.6…   5.6.2…   5.6.6…   5.7…   5.8…   5.9…   5.13…   5.14…   5.15   5.16   5.17…   5.18   5.19…   A…   C…

 

5.6.2  Monitoring Events configuration and deletion directly at the MME/SGSNWord‑p. 69

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.
(not reproduced yet)
Figure 5.6.2.1-1: Monitoring event configuration and deletion directly at MME/SGSN procedure
Up
Step 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.
Step 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.
Step 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.
Step 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.
Step 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).
Step 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.
Step 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.
Step 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.
Up

5.6.2.2Void

5.6.2.3  Specific Steps for Monitoring Event: Number of UEs present in a geographic areaWord‑p. 70

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

5.6.3  Reporting of Monitoring Events from the HSS or the MME/SGSNWord‑p. 71

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.
(not reproduced yet)
Figure 5.6.3.1-1: Monitoring event reporting procedure
Up
Step 1a.
A Monitoring Event is detected by the MME/SGSN at which the Monitoring Event is configured.
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
Up

5.6.3.2  Reporting Event: Loss of connectivityWord‑p. 73

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), when ISR is disabled and a UE, MME, SGSN, or HSS initiated detach occurs (see TS 23.401, TS 23.060), 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).
2a)
Step 2a of clause 5.6.3.1 is executed.
3)
Step 3 of clause 5.6.3.1 is executed.
Up

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

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

5.6.3.5  Reporting Event: Change of IMSI-IMEISV associationWord‑p. 74

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

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

5.6.3.7  Reporting Event: Communication failure

Step 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.
Step 2a.
Step 2a of clause 5.6.3.1 is executed.
Step 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.
Up

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

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

5.6.4  Monitoring events configuration and reporting via PCRFWord‑p. 75

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. The procedure is common for any monitoring event defined in clause 4.5.6.3 "Monitoring Events via PCRF".
(not reproduced yet)
Figure 5.6.4-1: Requesting monitoring via PCRF
Up
Step 1.
The SCS/AS sends a Monitoring Request to the SCEF, including the information listed in step 1 of clause 5.6.1.1.
Step 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.
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.
Step 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.
Up

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

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.
For monitoring for a group of UEs, the SPR is configured with the External Group Identifier the UE belongs to.
(not reproduced yet)
Figure 5.6.4.1a-1: Requesting monitoring via PCRF for a group of UEs
Up
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 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. 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.
Step 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.
Step 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.
Step 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.
Up

5.6.4.2  Common Parameters of the request reporting procedureWord‑p. 77

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

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

5.6.4.4  Specific Parameters for Monitoring Event: Communication FailureWord‑p. 78

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

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.
(not reproduced yet)
Figure 5.6.5-1: Reporting event procedure
Up
Step 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, then the PCRF to the SCEF over Rx if the event was requested over Rx. Both events terminate the AF session to the SCEF.
Step 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.
Step 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.
Up

Up   Top   ToC