5.9 Interactions with other services

23.4013GPPGeneral Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) accessRelease 18TS

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

5.9.1 Location Reporting Procedure

This procedure is used by an MME to request the eNodeB to report where the UE is currently located when the target UE is in ECM-CONNECTED state. The need for the eNodeB to continue reporting ceases when the UE transitions to ECM-IDLE. This procedure may be used for services that require accurate cell identification (e.g. for emergency services, lawful intercept, charging). When Dual Connectivity is activated, the PSCell information is only reported if requested by the MME. In the case of satellite access for Cellular IoT, this procedure may be used by the MME to determine the TAI where the UE is geographically located.

Figure 5.9.1-1: Location Reporting Procedure

1) The MME sends a Location Reporting Control message to the eNodeB. The Location Reporting Control message shall identify the UE for which reports are requested, the requested location information and may contain information such as reporting type. Requested location information is TAI+EGCI, and if requested by the MME, PSCell ID.

Reporting type indicates whether the message is intended to trigger:

– a single stand‑alone report about the current Cell ID serving the UE; or

– start the eNodeB to report whenever the UE changes cell.

In addition, the MME shall be able to control whether or not the RAN reports changes in the UE’s PSCell ID.

NOTE 1: Requesting reports whenever the UE changes cell can increase signalling load on multiple interfaces. Requesting reports for changes in PSCell ID can further increase signalling load. Hence it is recommended that any such reporting is only applied for a limited number of subscribers.

2) The eNodeB sends a Location Report message informing the MME about the location of the UE which shall include the requested location information.

If the MME requests UE location, in the case of satellite access for Cellular IoT, the eNodeB provides all broadcast TAIs to the MME as part of the ULI. The eNodeB also reports the TAI where the UE is geographically located if this TAI can be determined. The cell and TAI reporting by eNodeB refer to a fixed cell and fixed TA in which a UE is geographically located. As part of the User Location Information, eNodeB also reports one or more TACs for the Selected PLMN as described in TS 36.413 [36], but it is not guaranteed that the UE is always located in one of these TACs.

3) The MME can send a Cancel Location Reporting message to inform the eNodeB that it should terminate location reporting for a given UE. This message is needed only when the reporting was requested for a reporting period.

NOTE 2: Location reporting is transferred during X2 handover, although new control signalling is not transferred during an active handover.

5.9.2 Location Change Reporting Procedure

5.9.2.1 General

The PDN GW may request for each PDN connection independently whether the MME shall report changes of ECGI/eNodeB ID/TAI (by using the "MS Info Change Reporting Action" parameter) and/or the UE entering/leaving a Presence Reporting Area (by using the "Presence Reporting Area Action" parameter) and/or whether the MME shall report changes of user CSG information (by using "CSG Information Reporting Action" parameter) to the PDN GW.

This reporting (any combination of "MS Info Change Reporting Action" and/or "Presence Reporting Area Action" and/or "CSG Information Reporting Action") may be controlled by the PDN GW at the following procedures:

– Attach,

– Tracking Area Update (when inducing a Modify Bearer procedure to the PDN GW),

– Inter-RAT Mobility to E-UTRAN (when inducing a Modify Bearer procedure to the PDN GW),

– Dedicated bearer activation,

– PDN GW initiated bearer modification with bearer QoS update,

– PDN GW initiated bearer modification without bearer QoS update,

– UE requested PDN connectivity,

– UE requested bearer resource modification.

The "Presence Reporting Area Action" and "Presence Reporting Area Information" parameters apply to all procedures listed above but, within this specification, their usage has only been described in the message flows related with the Attach and the UE requested PDN connectivity procedures.

The reporting of UE entering/leaving a Presence Reporting Area is further described in clause 5.9.2.2.

The PDN GW may also request the MME to stop any of the above mentioned types of reporting. The MME shall obey the last explicit instruction received from the PDN GW or source MME.

During both mobility management and session management procedures, the MME shall indicate to the PDN GW the support of reporting location changes (using the MS Info Change Reporting support indication):

– If ECGI/eNodeB ID/TAI information is permitted to be sent to the PDN GW according to MME operator’s policy,

– If CSG information is permitted to be sent to the PDN GW according to MME operator’s policy.

The MME may be configured to report ECGI/eNodeB ID/TAI changes only when one or more E-RAB(s) are established. Otherwise the MME shall report ECGI/eNodeB ID/TAI changes as soon as detected.

If the level of support changes during a mobility management procedure then the MME shall indicate the current level of support to the S-GW and shall in addition provide ECGI/eNodeB ID/TAI even if the PDN GW has not requested this information. This could for example happen during MME change when the level of support indicated by the old MME is not the same as in the new MME.

NOTE 1: The inclusion of ECGI/eNodeB ID/TAI will trigger a Modify Bearer Request message from S-GW to the PDN GW and therefore this will make sure that the new level of support reaches the PDN GW.

At change of Serving Node (MME/S4-SGSN), the old Serving Node provides the new serving node with "MS Info Change Reporting Action" as previously requested by the PDN GW. The new Serving Node takes the "MS Info Change Reporting Action" immediately into account with the exception that, at mobility between a S4-SGSN and a MME, the new MME (respectively S4-SGSN) does not take into account the "MS Info Change Reporting Action" received from the S4-SGSN (respectively MME) but assumes that no location information change reporting is requested for the target RAT. At a change of RAT type between EUTRAN and UTRAN or between EUTRAN and GERAN, if location information change reporting is required in the target RAT, the PDN GW shall request "MS Info Change Reporting Action" from the new Serving Node (MME or S4-SGSN). Upon inter-RAT mobility, if the target MME/S4-SGSN supports location information change reporting, the target MME/S4-SGSN shall include the User Location Information in the Create Session Request / Modify Bearer Request, regardless of whether location Information change reporting had been requested in the previous RAT by the PDN GW.

The PDN GWPDN GW shall not request the MME to report location changes if it has not received the indication for corresponding support from the MME.

NOTE 2: For E-UTRAN access, homogeneous support of reporting changes of UE presence in a Presence Reporting Area in a network is assumed: When the PCRF configuration indicates that reporting changes of UE presence in a Presence Reporting Area is supported for E-UTRAN, this means it is supported by all the PDN GWPDN GW, all MME and all the SGW including the MME and SGW working in network sharing mode. If change of UE presence in Presence Reporting Area reporting is not supported, the PCRF may instead activate location information change reporting at cell, eNodeB or tracking area level.

The following procedure shall be used for location change reports to the PDN GWPDN GW where the report is not combined with other mobility management or session management signalling. The procedure shall only apply when the MME has been explicitly requested to report location changes.

The following procedure can be used for MO Exception Data Counter reporting where the report is not combined with other mobility management or session management signalling. The MME only includes the MO Exception data counter if the RRC establishment cause is set to "MO exception data" and the UE is accessing via the NB-IoT RAT. The MME maintains the MO Exception Data Counter for Serving PLMN Rate Control purposes (see clause 4.7.7.2). The MME may immediately send the MO Exception Data Counter to the Serving GW. Alternatively, in order to reduce signalling, the MME may send the MO Exception Data Counter to the Serving GW as described in TS 29.274 [43]. The SGW and PDN GWPDN GW indicate each use of this RRC establishment cause by the related counter on its CDR.

NOTE 3: Due to the increased signalling load, it is recommended that ECGI/eNodeB ID/TAI or CSG reporting is only applied for a limited number of subscribers.

Figure 5.9.2.1-1 represents the ECGI change triggering a report of change in ECGI, and/or the User CSG information change triggering a report of change in user CSG information. The figure also shows the reporting of a TAI change and/or when a UE enters or leaves a Presence Reporting Area.

Figure 5.9.2.1-1: Notification of the ECGI, TAI and/or user CSG information changes

1a. the MME has received an ECGI information Update from the eNodeB.

1b. The MME detects that the user CSG information has changed by comparing with the MME stored user CSG information, or

1c. The MME detects that the TAI of the UE has changed, or

1d. The MME detects that the UE has entered or left a Presence Reporting Area defined for this UE.

NOTE 4: It is possible that these changes are triggered at same time.

2. If the MME has been requested to report location changes to the PDN GWPDN GW for the UE (under the conditions specified in clause 5.9.2), the MME shall send the Change Notification message to the SGW indicating the new ECGI, TAI and/or user CSG information. The MME stores the notified user CSG information. If the MME has been requested to report a change of UE presence in Presence Reporting Area (under the conditions specified in clause 5.9.2), the MME shall send the Change Notification message including the Presence Reporting Area Information comprising the area identifier(s) and indication(s) on whether the UE is inside or outside the area(s). If MME decides to reactivate one or more of the inactive Presence Reporting Area(s), the Presence Reporting Area Information in this message also comprises the reactivated PRA identifier(s), and indication(s) on whether the UE is inside or outside the reactivated area(s).

3. The SGW forwards the Change Notification message to the PDN GWPDN GW. If dynamic PCC is deployed, and location changes need to be conveyed to the PCRF, then the PDN GWPDN GW shall send this information to the PCRF as defined in TS 23.203 [6]. If Presence Reporting Area Information has been received, the PDN GWPDN GW shall forward the Presence Reporting Area Information to the PCRF, to the OCS or to both as defined in TS 23.203 [6].

4. The PDN GW sends the Change Notification Ack to the SGW.

5. The SGW forwards the Change Notification Ack to the MME.

5.9.2.2 Reporting at Presence Reporting Area entering and leaving

In some use cases policy control/charging decisions, such as QoS modification or charging rate change depend on whether the UE is located inside or outside a specific area of interest (Presence Reporting Area), and especially on whether the UE enters or leaves that specific area of interest.

A Presence Reporting Area can be:

– Either a "UE-dedicated Presence Reporting Area", defined in the subscriber profile and composed of a short list of TAs/RAs, or eNodeBs and/or cells/SAs in a PLMN;

– Or a "Core Network predefined Presence Reporting Area", predefined in MME/SGSN and composed of a short list of TAs/RAs, or eNodeBs and/or cells/SAs in a PLMN.

NOTE 1: eNodeBs are identified via the Global eNodeB ID IE defined in TS 36.413 [36].

NOTE 2: Change of UE presence in Presence Reporting Area reporting does not apply to roaming.

The reporting of changes of UE presence in Presence Reporting Area is for a specific UE and is triggered as defined in TS 23.203 [6]. The PDN GW may request to Start/Stop reporting of changes of UE presence for one or more Presence Reporting Area(s) by using the Presence Reporting Area Action parameter. For UE-dedicated Presence Reporting Areas, the reporting request (Start) shall contain the PRA identifier(s) and the list(s) of TAs/RAs, or eNodeBs and/or cells/SAIs composing the Presence Reporting Area(s). For Core Network predefined Presence Reporting Areas, the reporting request (Start) shall contain the PRA identifier(s). The request to Stop a reporting contains the PRA identifier(s).

Each Core Network predefined Presence Reporting Area can be configured with a priority level in the MME/S4-SGSN. In order to prevent overload, the MME/S4-SGSN may set the reporting for one or more of the received Presence Reporting Area(s) to inactive under consideration of the priority configured for each of Core Network predefined Presence Reporting Area(s), while storing the reporting request for this Presence Reporting Area in the user context.

Upon reception of a request for change of UE presence in Presence Reporting Area reporting, the MME/S4-SGSN shall report to the PDN GW via the SGW the Presence Reporting Area Information comprising the PRA identifier(s) and indication(s) on whether the UE is inside or outside the Presence Reporting Area(s). If the UE is in ECM-IDLE state, the MME may either bring the UE into ECM-CONNECTED state, or, report based on the UE’s last known location and when the UE was there. One or more Presence Reporting Area may be set for a given PDN connection at a time. The serving node if needed only sets the reporting of UE presence in a Presence Reporting Area to inactive when receiving the reporting request for this Presence Reporting Area. If the MME/S4-SGSN decides to set the reporting of UE presence in one or more of the received Presence Reporting Area(s) to inactive, the MME/S4-SGSN shall also report the inactive Presence Reporting Area(s).

The MME/S4-SGSN shall notify the PDN GW when the UE enters or leaves a Presence Reporting Area, and no notifications are sent for UE movements inside or outside a Presence Reporting Area. The report of the change of UE presence in Presence Reporting Area shall contain the Presence Reporting Area Information comprising the PRA identifier(s) and indication(s) on whether the UE is inside or outside the area(s). A report shall be sent if the UE presence is different to the last one reported.

The MME/S4-SGSN may be configured with a PRA identifier which refers to a Set of Core Network predefined Presence Reporting Areas. The PDN GW may request Start reporting for this Set of Presence Reporting Areas by only indicating this PRA identifier in the Presence Reporting Area Action. When the Presence Reporting Area(s) to be reported belong to a set of Core Network predefined Presence Reporting Areas in which the MME/S4-SGSN is requested to report on change of UE presence, the MME/S4-SGSN shall additionally add to the report the PRA identifier of the Set of Core Network predefined Presence Reporting Areas.

Upon change of serving EPC node (MME, S4-SGSN), the PRA identifier(s) and if provided by the PDN GW the list(s) of Presence Reporting Area elements are transferred for all PDN connections as part of MM Context information to the target serving node during the mobility procedure. If one or more Presence Reporting Area(s) was set to inactive, the target serving node may decide to reactivate one or more of the inactive Presence Reporting Area(s). The target serving node indicates per PDN connection to the corresponding PDN GW the PRA identifier(s) and whether the UE is inside or outside the Presence Reporting Area(s) as well as the inactive Presence Reporting Area(s), if any.

NOTE 3: The target serving node cannot set the Presence Reporting Area(s) received from the source serving node to inactive.

5.9.3 IMSI and APN information retrieval procedure

This procedure is used by the RCAF to determine the UEs that are served by a congested eNodeB or E-UTRAN cell and the APNs of the active PDN connections of these UEs. This information is used to determine the PCRFs serving these UEs and subsequently report RAN user-plane congestion information (RUCI) to the PCRFs. The decision whether the RCAF requests MME to retrieve the list of UEs on eNodeB or E-UTRAN cell level is up to operator configuration.

NOTE 1: The details of congestion reporting to the PCRF are specified in TS 23.203 [6].

The RCAF determines the MMEs that are serving the congested eNodeB or E-UTRAN cell based on the Tracking Area Identities served by the congested eNodeB or E-UTRAN cell. For further details on the related DNS procedure see TS 29.303 [61]. The following steps are applied to all MMEs serving the congested eNodeB or E-UTRAN cell.

NOTE 2: In network sharing scenarios the RCAF belongs to the RAN operator. In this case it is up to inter-operator agreements and operator configuration which sharing partner’s MMEs the RCAF queries IMSI and APN information from.

Figure 5.9.3-1: IMSI and APN information retrieval procedure

1. The RCAF sends an IMSI/APN information request to the MME. The request shall identify whether the request refers to an eNodeB or an E-UTRAN cell and shall contain the related eNodeB ID or ECGI.

NOTE 3: The eNodeB ID is defined in TS 36.413 [36].

2. The MME sends the IMSI/APN information response to the RCAF. The response shall contain the list of UEs (identified by the IMSIs) served by the eNodeB or E-UTRAN cell and the list of APNs of the active PDN connections of each IMSI.

If the RCAF requested the IMSI/APN information on E-UTRAN cell level, then the MME first determines the list of UEs served by that E-UTRAN cell. The MME may achieve this by querying the eNodeB that the E-UTRAN cell belongs to for the exact ECGI for all UEs served by this eNodeB using the Location Reporting procedure (clause 5.9.1).

NOTE 4: Applying the Location Reporting feature due to an E-UTRAN cell level RCAF request can increase S1-MME interface signalling load.

NOTE 5: In order for RCAF to maintain the list of impacted UEs (identified by the IMSIs) (and related APN information) for a congested cell, the RCAF needs to regularly receive IMSI/APN information updates from the MME. The details of whether the RCAF needs to query the MME regularly or whether the MME updates the RCAF regularly without further explicit requests from the RCAF is specified in Stage 3.