Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 37.340  Word version:  18.1.0

Top   Top   Up   Prev   Next
1…   4…   4.2…   4.3…   5…   7…   8…   9   10…   10.2…   10.2.2…   10.3…   10.3.2   10.4…   10.5…   10.5.2   10.6   10.7…   10.8…   10.9…   10.10…   10.11…   10.12…   10.12.2   10.13…   10.14…   10.15   10.16…   10.17…   10.18…   10.19…   10.20   11…   A   B…

 

10.18  Self-optimisation for PSCell addition/change |R17|p. 107

10.18.1  Generalp. 107

For analysis of PSCell addition/change failure, the UE makes the SCG Failure Information available to the MN. If it is SN-initiated PSCell change/CPC, the SN may make the SN mobility information available to the MN which can later send it back to the SN when the failure occurs.

10.18.2  PSCell change failurep. 107

One of the functions of self-optimization for PSCell change is to detect PSCell change failures that occur due to Too late PSCell change or Too early PSCell change, or Triggering PSCell change to wrong PSCell. These problems are defined as follows:
  • Too late PSCell change: an SCG failure occurs after the UE has stayed for a long period of time in the PSCell; a suitable different PSCell is found based on the measurements reported from the UE.
  • Too early PSCell change: an SCG failure occurs shortly after a successful PSCell change from a source PSCell to a target PSCell or a PSCell change failure occurs during the PSCell change procedure; source PSCell is still the suitable PSCell based on the measurements reported from the UE.
  • Triggering PSCell change to wrong PSCell: an SCG failure occurs shortly after a successful PSCell change from a source PSCell to a target PSCell or a PSCell change failure occurs during the PSCell change procedure; a suitable PSCell different with source PSCell or target PSCell is found based on the measurements reported from the UE.
In the definition above, the "successful PSCell change" refers to the UE state, namely the successful completion of the RA procedure.
MN performs initial analysis to identify the node that caused the failure. The MN may use the SCG Failure Information Report procedure to verify whether intra-SN PSCell change has been triggered in the last serving SN and stores the SCG Failure Information for the time needed to receive possible response from the last serving SN. If the failure is caused by a source SN, the MN forwards then the SCG Failure Information to the source SN. The node responsible for the last PSCell change (the source SN, the last serving SN or the MN) performs the final root cause analysis.
Up

10.18.3  Conditional PSCell addition or change failure |R18|p. 108

One of the functions of self-optimization for CPAC is to detect CPAC failures that occur due to Too late CPC execution or Too early CPC/CPA execution, or CPC/CPA execution to wrong PSCell. These problems are defined as follows:
  • Too Late CPC Execution: UE receives CPC configuration, while a SCG failure occurs before CPC execution condition is satisfied; a suitable PSCell different from source PSCell is found based on the measurements reported from the UE.
  • Too Early CPC/CPA Execution: CPC/CPA execution is not successful or an SCG failure occurs shortly after a successful CPC/CPA execution; in case of CPC, the source PSCell is still the suitable PSCell based on the measurements reported from the UE; in case of CPA, no suitable PSCell is found based on the measurements reported from the UE.
  • CPC/CPA Execution to wrong PSCell: CPC/CPA execution is not successful or an SCG failure occurs shortly after a successful CPC/CPA execution; a suitable PSCell different from the source PSCell or the target PSCell is found based on the measurements reported from the UE. There are two sub-cases for wrong candidate PSCell list selection:
  • if the suitable PSCell is one of the candidate target PSCells provided by the node initiating the CPC or by the MN initiating the CPA, but not one of the candidate PSCells selected by the candidate or target SN, it is wrong target PSCell selection at the candidate or target SN;
  • else, it is wrong candidate PSCell list selection at the node initiating the CPC or at the MN initiating the CPA.
In the definition above, the "successful CPC/CPA execution" refers to the UE state, namely the successful completion of the RA procedure.
The MN performs the initial analysis when SCGFailureInformation is received from the UE. In the first step, MN verifies whether intra-SN PSCell change has been triggered in the last serving SN. In case the intra-SN PSCell change has been triggered in the last serving SN, the MN forwards the SCG Failure Information Report message to this last serving SN, which performs the final root cause analysis. In case of no intra-SN PSCell change, the MN determines the type of PSCell addition/change, e.g., whether it is CPA or CPC in case of conditional mobility, if CPC whether it is MN initiated or SN initiated.
For CPA or MN initiated CPC, if the suitable PSCell is one of the candidate PSCells provided by the MN at CPAC preparation, but not one of the candidate PSCells selected by the candidate or target SN, MN sends the SCG Failure Information Report messageto the candidate or target SN, which perform the final MRO related optimisation. Otherwise, the MN performs the final MRO related optimisation.
For SN initiated CPC, the MN sends the SCG Failure Information Report messageto source SN, and source SN performs root cause analysis. If the suitable PSCell is one of the candidate PSCells provided by the source SN, but not one of the candidate PSCells selected by the candidate or target SN, the source SN indicates to MN that the root cause of the SCG failure may have occurred in the other nodes. MN then sends the SCG Failure Information Report messageto the candidate or target SN. Otherwise, the source SN performs the final MRO related optimisation.
Up

10.18.4  Successful PSCell Addition/Change Report |R18|p. 108

The objective of Successful PSCell addition/change Report (SPR) is to detect sub-optimal successful PSCell change/CPC or successful PSCell addition/CPA.
For analysis of such sub-optimal successful PSCell change/CPC and successful PSCell addition/CPA, the UE may collect SPR based on the triggers configured by the network and makes the SPR available to the network as specified in TS 38.331. If the SPR available indication via SN RRCReconfigurationComplete is received by SN, SN should inform MN that an SPR is available at the UE via S-NODE MODIFICATION REQUIRED message.
For PSCell addition/CPA and PSCell change/CPC (MN or SN initiated), the target SN always decides the T304 trigger for SPR and performs root cause analysis.
For SN-initiated PSCell change/CPC, the source SN decides the T310/T312 triggers for SPR and is responsible for SPR related optimizations e.g., to optimize PSCell change/CPC configuration or associated mobility thresholds or adjust T310/T312 timer values.
For MN-initiated PSCell change/CPC, the MN decides the T310/T312 triggers for SPR. MN may optimize PSCell change/CPC configuration or associated mobility thresholds or both. Source SN may optimize lower layer issues e.g., adjust T310/T312 timer values.
The SPR can be fetched from the UE by the MN only while the UE is still connected to the MN, or by a node different from the MN that sent the SPR configuration to the UE if the UE is not connected to the MN anymore. In case the SPR is retrieved in a node different from the MN that sent the SPR configuration to the UE, the SPR is first forwarded to that MN, which then forwards it to the respective SN(s) which should perform the SPR optimization.
Up

10.18.5  RA Report retrieval |R18|p. 109

In MR-DC, when a UE performs successful random access attempts which are only known by the SN (e.g., beam failure recovery, UL synchronization issue, scheduling request failure, no PUCCH resource available), the SN may inform the MN about the occurrences of successful random access procedures in the SN via a RACH indication. The MN may then retrieve the RA Report from the UE(s) based on the RACH indication received from the SN.
A UE while being in EN-DC and NGEN-DC can collect E-UTRA RA Reports and NR RA Reports upon performing RACH in MN and SN respectively. When a E-UTRAN node retrieves the E-UTRA RA Report, it can also request UE to include the NR RA Report(s). If available, the UE then includes the NR RA Report(s) in a container along with a list of PSCells associated to the NR RA Report(s) within the E-UTRA RA Report. The retrieving E-UTRAN node may then forward the NR RA Report(s) to the corresponding SNs serving the indicated PSCells.
In case of NGEN-DC, in case there is no Xn connectivity between the ng-eNB retrieving the NR RA Report from the UE and the gNB serving the PSCells indicated by UE in the NR RA Report, the ng-eNB may forward the NR RA Report via Xn to an ng-eNB connected to a gNB serving the PSCells indicated in the RA Report.
In case of EN-DC, in case there is no X2 connectivity between the eNB retrieving the NR RA Report from the UE and the en-gNB serving the PSCells indicated by UE in the NR RA Report, the eNB may forward the NR RA Report via X2 to an eNB connected to an en-gNB serving the PSCells indicated in the RA Report.
Up

Up   Top   ToC