Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.401  Word version:  18.4.0

Top   Top   Up   Prev   Next
1…   4…   4.2.2…   4.3…   4.3.6…   4.3.8…   4.3.12…   4.3.16…   4.3.20…   4.3.25…   4.4…   4.6…   4.7…   5…   5.1.2…   5.3…   5.3.2…   5.3.3…   5.3.3.2   5.3.3.3…   5.3.4…   5.3.4B…   5.3.5…   5.3.8…   5.3.9…   5.4…   5.4.4…   5.5…   5.5.1.2…   5.5.2…   5.5.2.2…   5.5.2.3…   5.5.2.4…   5.6…   5.7.3…   5.7A…   5.10   5.11…   5.19…   D…   D.3…   D.3.4   D.3.5   D.3.6   D.3.7…   D.3.8…   E   F…   J…   K…   L…   M…

 

5.7A  Chargingp. 338

5.7A.1  General |R15|p. 338

Accounting functionality is provided by the Serving-GW and the PDN-GW. When a Secondary RAT may be used, the Serving-GW and PDN-GW can be assisted by the E-UTRAN (see clause 5.7A.4).
The Serving-GW shall be able to collect and report for each UE accounting information, i.e. the amount of data transmitted in uplink and downlink direction categorized with the QCI and ARP pair per UE per PDN connection. For GTP-based S5/S8 the accounting information is collected and reported per bearer.
The Serving-GW shall not collect UE accounting information for packets that are being processed for the sole purpose of indirect forwarding.
The Serving-GW for inter-operator charging, and the PDN-GW shall be able to interface the OFCS according to charging principles and through reference points specified in TS 32.240.
The PDN-GW shall be able to provide charging functionality for each UE according to TS 23.203. The PDN-GW data collection for charging and usage monitoring purposes can be temporarily paused as described in clause 5.3.6A.
A PDN-GW without a Gx interface shall be able to support flow based online and offline charging based on local configuration and interaction with the Online and Offline Charging Systems.
The Online Charging System may provide a PRA identifier(s) to the PDN-GW to subscribe to notifications about changes of UE presence in Presence Reporting Area as defined in the TS 23.203. For UE-dedicated Presence Reporting Areas the Online Charging System also provides the list(s) of the elements comprising each subscribed UE-dedicated Presence Reporting Area.
The PDN-GW shall be able to collect and report, for each UE, accounting information, i.e. the amount of data received and transmitted in uplink and downlink direction categorized with the QCI and ARP pair per UE per PDN connection. For GTP-based S5/S8 the accounting information is collected and reported per bearer. The PDN-GW data collection can be temporarily paused as described in clause 5.3.6A based on operator configuration in the PDN-GW.
The Charging identifier(s) generated by the PDN-GW per bearer for GTP-based S5/S8 and per PDN connection for PMIP-based S5/S8 and the PDN-GW address for control signalling enables the correlation of the reporting from a Serving-GW and a PDN-GW. The Charging identifier is uniquely assigned within the PDN-GW.
The PDN-GW receives Charging Characteristics from the Serving-GW through GTP-S5/S8, or through PMIP for PMIP-based S5/S8. The handling of the Charging Characteristics in the P-GW is defined in TS 32.251.
To enable CSG charging function for a subscriber consuming network services via a CSG cell or a hybrid cell, User CSG Information is transferred to the PDN-GW as indicated by CSG Information Reporting Action. User CSG Information includes CSG ID, access mode and CSG membership indication. CSG membership indication of whether the UE is a member of the CSG is included if the access mode is hybrid.
The valid CSG information shall be available in the serving GW and PDN-GW in connected mode.
The PCRF shall, if deployed, provide User CSG Information reporting rules to the PDN-GW at Attach and PDN Connectivity Request. PDN-GW sets the CSG Information Reporting Action IE according to the User CSG Information reporting rules and sends it to Serving-GW and MME.
To enable the MME to signal the correct RAT Type (NB-IoT or WB-E-UTRAN) to the SGW and PDN-GW for accounting information generation purposes, the eNodeB informs the MME of the RAT Type and TAC associated with each cell in the S1 SETUP REQUEST and eNodeB CONFIGURATION UPDATE messages (TS 36.413). If the eNodeB signals WB-EUTRAN and the UE is of Category M from the UE's radio capability, the MME reports RAT Type LTE-M to the SGW. See clause 5.11.5 for more details.
Up

5.7A.2  Usage Data Reporting for Secondary RAT |R15|p. 339

When a Secondary RAT can be used in conjunction with E-UTRAN, the HPLMN or VPLMN operator may wish to record the data volume sent on the Secondary RAT.
In order to reduce the complexity of this procedure, and to align with existing per EPS bearer accounting procedures, the following principles are used in this release:
  1. The PLMN locally activates the Secondary RAT Usage Data Reporting by E-UTRAN O&M. The activation can happen separately for Data Volume Reporting of NR and Unlicensed Spectrum. If the PLMN uses this feature, it should ensure that this functionality is supported by all eNodeBs that support NR, Unlicensed Spectrum aggregation (if used to record data volume sent over unlicensed spectrum) as a Secondary RAT.
  2. The E-UTRAN reports uplink and downlink data volumes to the EPC for the Secondary RAT on a per EPS bearer basis and per time interval.
  3. At X2 handover and S1 handover, the source eNodeB reports the data volumes to the EPC. The reported data volume excludes data forwarded to the target RAN node.
  4. At S1 Release, Connection Suspend, and EPS Bearer Deactivation the eNodeB reports the data volumes to the EPC.
  5. To assist "partial CDR" generation at the Serving-GW and the PDN-GW, E-UTRAN O&M can instruct the E-UTRAN to also make periodic reports if no event has triggered a report before the period expires.
  6. As an option, the Serving Gateway sends the data volume reports on to PDN-GWs identified in bilateral roaming agreements.
Up

5.7A.3  Secondary RAT Usage Data Reporting Procedure |R15|p. 339

The procedure in Figure 5.7A.3-1 may be used to report Secondary RAT usage data from eNodeB to the MME. It is executed by the eNodeB to report the Secondary RAT usage data information which is then included in messages on S11 towards Serving-GW and S5/S8 interface to the PGW (e.g. during I-RAT handover procedures, S1 handover, X2 handover). This then further uses existing EPC signalling of the procedures involved.
The procedure in Figure 5.7A.3-2 may be used to report the Secondary RAT usage data from MME to the Serving-GW. Optionally, it is used to report the Secondary RAT usage data from Serving-GW to the PDN-GW when the reporting to PDN-GW is activated.
If the Secondary RAT usage data is provided by an S1AP message from eNodeB to MME other than the one indicated in Figure 5.7A.3-1, the procedures in Figure 5.7A.3-2 may be used to transfer the secondary RAT usage data to the Serving-GW and PDN-GW (e.g. during S1 Release procedure). The eNodeB may also provide the user location information, e.g. ECGI, PSCell ID.
During IRAT handovers, the procedures 5.7A.3-1 to 5.7A.3-2 in its entirety is executed to provide reporting of Secondary RAT usage data to the Serving-GW and to the PDN-GW if PGW secondary RAT usage data reporting is active.
Handover related signalling of IRAT procedures may be used to provide reporting of Secondary RAT usage data to the Serving-GW instead of the signalling of Figure 5.7A.3-2, when PGW secondary RAT usage data reporting is not active.
Reproduction of 3GPP TS 23.401, Fig. 5.7A.3-1: RAN Secondary RAT usage data Reporting procedure
Up
Step 1.
The eNodeB, if it supports Dual Connectivity with Secondary RAT (using NR radio (see clause 4.3.2a on Support for Dual Connectivity), using unlicensed spectrum in the form of LAA/LWA/LWIP/NR-U (see clause 4.3.30)) and it is configured to report Secondary RAT usage data for the UE, depending on certain conditions documented in this specification, it shall send a RAN usage data Report message to the MME including the Secondary RAT usage data for the UE. The eNodeB will send only one RAN usage report for a UE when the UE is subject to handover by RAN. The RAN usage data report includes a handover flag to indicate when the message is sent triggered by X2-handover.
If Dual Connectivity is active or had been activated by that eNodeB, the eNodeB shall add the PSCell ID (and the time elapsed since the Dual Connectivity was released if Dual Connectivity is no longer activated) to the RAT usage data Report message.
In the case of X2 handover, the MME is expected to handle a secondary RAT data reporting received from the source eNodeB within a short time after Path Switch Request by forwarding it to the SGW, e.g. using the GW Secondary RAT usage data Reporting procedure.
Reproduction of 3GPP TS 23.401, Fig. 5.7A.3-2: GW Secondary RAT usage data Reporting procedure
Up
The eNodeB, if it supports Dual Connectivity with Secondary RAT (using NR radio (see clause 4.3.2a on Support for Dual Connectivity), using unlicensed spectrum in the form of LAA/LWA/LWIP/NR-U (see clause 4.3.30)) and it is configured to report Secondary RAT usage data for the UE, it shall send include the Secondary RAT usage data for the UE to the MME in certain messages depending on certain conditions documented elsewhere in this TS.
Secondary RAT usage reporting from the eNodeB is provided using S1 signalling message which are either at the UE level (eg. Path Switch Request, etc), or at bearer level (eg. E-RAB modification indication, Deactivate bearer response, etc.) as captured in relevant clauses in this specification. If Secondary RAT usage report is provided in bearer level signalling message by the eNodeB, the Secondary RAT usage report is related only to the specific bearer.
Step 1.
The MME forwards the Secondary RAT usage data and User Location Information, PSCell ID to the SGW in a Change Notification Request (Secondary RAT usage data) message. If the SGW is requested to forward Secondary RAT usage data to the PGW, the MME includes a flag causing the SGW to forward this to the PGW. Also, the MME informs the Serving-GW if the secondary RAT usage data shall not be processed by the Serving-GW (e.g. during Serving-GW relocation when the usage data is to be forwarded via the target Serving-GW).
Step 2.
The Serving-GW may, based on flags received in the previous message and local configuration in the Serving-GW, send the Change Notification (Secondary RAT usage data) message to the PDN-GW.
Step 3.
The PDN-GW acknowledges receiving the Secondary RAT usage data for the UE by a Change Notification Ack() message to the Serving-GW.
Step 4.
The SGW acknowledges by sending a Change Notification ack() message back to the MME.
Up

5.7A.4  Secondary RAT Periodic Usage Data Reporting Procedure |R15|p. 341

Periodic reporting of the Secondary RAT usage data is an optional function. When eNodeB, as defined in bullet e) of clause 5.7A.2, is configured with a "time interval for Secondary RAT usage data reporting", the eNodeB shall send a RAN Usage Data Report message for periodic reporting purposes to the MME only when this timer expires for a UE for which Secondary RAT usage data reporting is ongoing. The timer runs from the last usage reporting for the UE. The MME also indicates to SGW if secondary RAT usage data reporting to the PGW is active.
The procedures 5.7A.3-1 to 5.7A.3-2 in its entirety is executed to provide periodic reporting of Secondary RAT usage data to the Serving-GW and to the PDN-GW when PGW secondary RAT usage data reporting is active. At use for periodic usage data reporting, the procedure 5.7A.3-1 uses signalling from eNodeB which does not include a handover flag.
Up

5.8  MBMSp. 341

MBMS is a point-to-multipoint service in which data is transmitted from a single source entity to multiple recipients. Transmitting the same data to multiple recipients allows network resources to be shared.
Support of MBMS for EPS is defined in TS 23.246.

5.9  Interactions with other servicesp. 341

5.9.1  Location Reporting Procedurep. 341

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.
Reproduction of 3GPP TS 23.401, Fig. 5.9.1-1: Location Reporting Procedure
Up
Step 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.
Step 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, but it is not guaranteed that the UE is always located in one of these TACs.
Step 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.
Up

5.9.2  Location Change Reporting Procedure |R9|p. 342

5.9.2.1  General |R12|p. 342

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.
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.
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. The SGW and PDN-GWPDN-GW indicate each use of this RRC establishment cause by the related counter on its CDR.
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.
Reproduction of 3GPP TS 23.401, Fig. 5.9.2.1-1: Notification of the ECGI, TAI and/or user CSG information changes
Up
Step 1a.
the MME has received an ECGI information Update from the eNodeB.
Step 1b.
The MME detects that the user CSG information has changed by comparing with the MME stored user CSG information, or
Step 1c.
The MME detects that the TAI of the UE has changed, or
Step 1d.
The MME detects that the UE has entered or left a Presence Reporting Area defined for this UE.
Step 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).
Step 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. 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.
Step 4.
The PDN-GW sends the Change Notification Ack to the SGW.
Step 5.
The SGW forwards the Change Notification Ack to the MME.
Up

5.9.2.2  Reporting at Presence Reporting Area entering and leaving |R12|p. 345

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

5.9.3  IMSI and APN information retrieval procedure |R13|p. 346

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.
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. The following steps are applied to all MMEs serving the congested eNodeB or E-UTRAN cell.
Reproduction of 3GPP TS 23.401, Fig. 5.9.3-1: IMSI and APN information retrieval procedure
Up
Step 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.
Step 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).
Up

Up   Top   ToC