Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.401  Word version:  16.7.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  Charging

5.7A.1  General |R15|

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 ENB 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|Word‑p. 324
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|

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 signaling 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 clause 5.7A.3 may be used to transfer the secondary RAT usage data to the Serving GW and PDN GW (e.g. during S1 Release procedure).
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 signaling of Figure 5.7A.3-2, when PGW secondary RAT usage data reporting is not active.
Reproduction of 3GPP TS 23.401, Figure 5.7A.3-1: RAN Secondary RAT usage data Reporting procedure
Up
Step 1.
The eNB, 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 eNB 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 eNB, the eNB 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 eNB 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, Figure 5.7A.3-2: GW Secondary RAT usage data Reporting procedure
Up
The eNB, 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 eNB is provided using S1 signaling 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 signaling 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 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|Word‑p. 326
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 eNB which does not include a handover flag.
Up

5.8  MBMS

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 services

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.
Reproduction of 3GPP TS 23.401, Figure 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.
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|Word‑p. 327

5.9.2.1  General |R12|

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, Figure 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|Word‑p. 330
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 eNBs 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 eNBs 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 eNBs 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|Word‑p. 331
This procedure is used by the RCAF to determine the UEs that are served by a congested eNB 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 eNB or E-UTRAN cell level is up to operator configuration.
The RCAF determines the MMEs that are serving the congested eNB or E-UTRAN cell based on the Tracking Area Identities served by the congested eNB 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 eNB or E-UTRAN cell.
Reproduction of 3GPP TS 23.401, Figure 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 eNB or an E-UTRAN cell and shall contain the related eNB 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 eNB 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 eNB that the E-UTRAN cell belongs to for the exact ECGI for all UEs served by this eNB using the Location Reporting procedure (clause 5.9.1).
Up


Up   Top   ToC