5.6 Other

36.3313GPPEvolved Universal Terrestrial Radio Access (E-UTRA)Protocol specificationRadio Resource Control (RRC)Release 17TS

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

5.6.0 General

For NB-IoT, only a subset of the procedures described in this clause apply.

Table 5.6.0-1 specifies the procedures that are applicable to NB-IoT. All other procedures are not applicable to NB-IoT; this is not further stated in the corresponding procedures.

Table 5.6.0-1: "Other″ Procedures applicable to a NB-IoT UE

Clause	Procedures
5.6.1	DL information transfer
5.6.2	UL information transfer
5.6.3	UE Capability transfer
5.6.5	UE information (see NOTE)
5.6.23	PUR Configuration Request
5.6.24	Neighbour Relation Reporting for SON ANR in NB-IoT

NOTE: Not applicable for a UE that only supports the Control Plane CIoT EPS optimisation (see TS 24.301 [35]).

5.6.1 DL information transfer

5.6.1.1 General

Figure 5.6.1.1-1: DL information transfer

The purpose of this procedure is to transfer NAS, (tunnelled) non-3GPP dedicated information or time reference information from E-UTRAN to a UE in RRC_CONNECTED, or to transfer F1-C related information from IAB-donor-CU to IAB-DU via IAB-MT in RRC_CONNECTED.

5.6.1.2 Initiation

E-UTRAN initiates the DL information transfer procedure whenever there is a need to transfer NAS, non-3GPP dedicated information, time reference information or F1-C related information. E-UTRAN initiates the DL information transfer procedure by sending the DLInformationTransfer message.

5.6.1.3 Reception of the DLInformationTransfer by the UE

Upon receiving DLInformationTransfer message, the UE shall:

1> if the UE is a NB-IoT UE; or

1> if the dedicatedInfoType is present and set to dedicatedInfoNAS:

2> forward the dedicatedInfoNAS to the NAS upper layers.

1> if the dedicatedInfoType is present and set to dedicatedInfoCDMA2000-1XRTT or to dedicatedInfoCDMA2000-HRPD:

2> forward the dedicatedInfoCDMA2000 to the CDMA2000 upper layers;

1> if timeReferenceInfo is included:

2> calculate the time reference based on the included time, timeInfoType and referenceSFN in timeReferenceInfo;

2> calculate the inaccuracy of the time reference based on the uncertainty and other implementation-related inaccuracies, if uncertainty is included in timeReferenceInfo;

2> inform upper layers of the time reference and, if uncertainty is included in timeReferenceInfo, of the inaccuracy of the time reference.

Upon receiving DLInformationTransfer message, the IAB-MT shall:

1> if dedicatedInfoF1c is included:

2> forward dedicatedInfoF1c to the IAB-DU.

5.6.2 UL information transfer

5.6.2.1 General

Figure 5.6.2.1-1: UL information transfer

The purpose of this procedure is to transfer NAS or (tunnelled) non-3GPP dedicated information from the UE to E-UTRAN, or to transfer F1-C related information from IAB-DU to IAB-donor-CU via IAB-MT in RRC_CONNECTED.

5.6.2.2 Initiation

A UE in RRC_CONNECTED initiates the UL information transfer procedure whenever there is a need to transfer NAS, non-3GPP dedicated information, except at RRC connection establishment or resume in which case the NAS information is piggybacked to the RRCConnectionSetupComplete or RRCConnectionResumeComplete message correspondingly. In addition, an IAB-MT in RRC_CONNECTED may initiate the UL information transfer procedure whenever there is a need to transfer F1-C related information. The UE initiates the UL information transfer procedure by sending the ULInformationTransfer message. When CDMA2000 information has to be transferred, the UE shall initiate the procedure only if SRB2 is established. When F1-C related information has to be transferred, the IAB-MT shall initiate the procedure only if SRB2 is established.

5.6.2.3 Actions related to transmission of ULInformationTransfer message

The UE shall set the contents of the ULInformationTransfer message as follows:

1> if there is a need to transfer NAS information:

2> if the UE is a NB-IoT UE:

3> set the dedicatedInfoNAS to include the information received from upper layers;

2> else:

3> set the dedicatedInfoType to include the dedicatedInfoNAS;

1> if there is a need to transfer CDMA2000 1XRTT information:

2> set the dedicatedInfoType to include the dedicatedInfoCDMA2000-1XRTT;

1> if there is a need to transfer CDMA2000 HRPD information:

2> set the dedicatedInfoType to include the dedicatedInfoCDMA2000-HRPD;

1> upon RRC connection establishment, if UE supports the Control Plane CIoT EPS/5GS optimisation and UE does not need UL gaps during continuous uplink transmission:

2> configure lower layers to stop using UL gaps during continuous uplink transmission in FDD for ULInformationTransfer message and subsequent uplink transmission in RRC_CONNECTED except for UL transmissions as specified in TS 36.211 [21];

1> if there is a need to transfer F1-C related information (applies only to IAB-MT):

2> include the dedicatedInfoF1c;

1> submit the ULInformationTransfer message to lower layers for transmission, upon which the procedure ends;

5.6.2.4 Failure to deliver ULInformationTransfer message

The UE shall:

1> if the UE is a NB-IoT UE, AS security is not started and radio link failure occurs before the successful delivery of ULInformationTransfer messages has been confirmed by lower layers; or

1> if mobility (i.e. handover, RRC connection re-establishment) occurs before the successful delivery of ULInformationTransfer messages has been confirmed by lower layers:

2> inform upper layers about the possible failure to deliver the information contained in the concerned ULInformationTransfer messages, unless the messages include dedicatedInfoF1c and no dedicatedInfoType is included;

5.6.2a UL information transfer for MR-DC

5.6.2a.1 General

Figure 5.6.2a.1-1: UL information transfer MR-DC

The purpose of this procedure is to transfer from the UE to E-UTRAN MR-DC dedicated information e.g. the NR RRC MeasurementReport, the NR RRC UEAssistanceInformation, the NR RRC IABOtherInformation, NR RRC FailureInformation or an NR RRCReconfigurationComplete (transmitted upon intra-SN CPC without MN involvement execution if NR RRCReconfiguration with conditionalReconfiguration for CPC was received via SRB1 and the UE is operating in EN-DC) messages.

5.6.2a.2 Initiation

A UE in RRC_CONNECTED initiates the UL information transfer procedure whenever there is a need to transfer MR DC dedicated information as specified in TS 38.331 [82]. I.e. the procedure is not used during an RRC connection reconfiguration involving NR connection reconfiguration, in which case the MR DC information is piggybacked to the RRCConnectionReconfigurationComplete message, except in the case the UE executes an intra-SN Conditional PSCell Change without MN involvement.

5.6.2a.3 Actions related to transmission of ULInformationTransferMRDC message

The UE shall set the contents of the ULInformationTransferMRDC message as follows:

1> if there is a need to transfer MR DC dedicated information:

2> set the ul-DCCH-MessageNR to include the MR DC dedicated information to be transferred;

1> submit the ULInformationTransferMRDC message to lower layers for transmission, upon which the procedure ends;

5.6.2a.4 Void

5.6.3 UE capability transfer

5.6.3.1 General

Figure 5.6.3.1-1: UE capability transfer

The purpose of this procedure is to transfer UE radio access capability information from the UE to E-UTRAN.

If the UE is NTN capable, the UE reports its E-UTRAN radio access capabilities for the network type (TN or NTN) to which it is connected.

If the UE has changed its E-UTRAN radio access capabilities, the UE shall request higher layers to initiate the necessary NAS procedures (see TS 23.401 [41]) that would result in the update of UE radio access capabilities using a new RRC connection.

NOTE: Change of the UE’s GERAN UE radio capabilities in RRC_IDLE is supported by use of Tracking Area Update.

5.6.3.2 Initiation

E-UTRAN initiates the procedure to a UE in RRC_CONNECTED when it needs (additional) UE radio access capability information. Except if the UE is using Control plane CIoT EPS optimisation, E-UTRAN should retrieve UE capabilities only after AS security activation and E-UTRAN does not forward capabilities that were retrieved before AS security activation to the CN.

5.6.3.3 Reception of the UECapabilityEnquiry by the UE

The UE shall:

1> for NB-IoT, set the contents of UECapabilityInformation message as follows:

2> include the UE Radio Access Capability Parameters within the ue-Capability;

2> include ue-RadioPagingInfo;

2> submit the UECapabilityInformation message to lower layers for transmission, upon which the procedure ends;

1> else, set the contents of UECapabilityInformation message as follows:

2> if the ue-CapabilityRequest includes eutra:

3> include the UE-EUTRA-Capability within a ue-CapabilityRAT-Container and with the rat-Type set to eutra;

3> if the UE supports FDD and TDD:

4> set all fields of UECapabilityInformation, except field fdd-Add-UE-EUTRA-Capabilities and tdd-Add-UE-EUTRA-Capabilities (including their sub-fields), to include the values applicable for both FDD and TDD (i.e. functionality supported by both modes);

4> if (some of) the UE capability fields have a different value for FDD and TDD:

5> if for FDD, the UE supports additional functionality compared to what is indicated by the previous fields of UECapabilityInformation:

6> include field fdd-Add-UE-EUTRA-Capabilities and set it to include fields reflecting the additional functionality applicable for FDD;

5> if for TDD, the UE supports additional functionality compared to what is indicated by the previous fields of UECapabilityInformation:

6> include field tdd-Add-UE-EUTRA-Capabilities and set it to include fields reflecting the additional functionality applicable for TDD;

NOTE 1: The UE includes fields of XDD-Add-UE-EUTRA-Capabilities in accordance with the following:

– The field is included only if one or more of its sub-fields (or bits in the feature group indicators string) has a value that is different compared to the value signalled elsewhere within UE-EUTRA-Capability;

(this value signalled elsewhere is also referred to as the Common value, that is supported for both XDD modes)

– For the fields that are included in XDD-Add-UE-EUTRA-Capabilities, the UE sets:

– the sub-fields (or bits in the feature group indicators string) that are not allowed to be different to the same value as the Common value;

– the sub-fields (or bits in the feature group indicators string) that are allowed to be different to a value indicating at least the same functionality as indicated by the Common value;

3> else (UE supports single xDD mode):

3> compile a list of band combinations, candidate for inclusion in the UECapabilityInformation message, comprising of band combinations supported by the UE according to the following priority order (i.e. listed in order of decreasing priority):

4> include all non-CA bands, regardless of whether UE supports carrier aggregation, only:

– if the UE includes ue-Category-v1020 (i.e. indicating category 6 to 8); or

– if for at least one of the non-CA bands, the UE supports more MIMO layers with TM9 and TM10 than implied by the UE category; or

– if the UE supports TM10 with one or more CSI processes; or

– if the UE supports 1024QAM in DL;

4> if the UECapabilityEnquiry message includes requestedFrequencyBands and UE supports requestedFrequencyBands:

5> include all 2DL+1UL CA band combinations, only consisting of bands included in requestedFrequencyBands;

5> include all other CA band combinations, only consisting of bands included in requestedFrequencyBands, and prioritized in the order of requestedFrequencyBands, (i.e. first include remaining band combinations containing the first-listed band, then include remaining band combinations containing the second-listed band, and so on);

4> else (no requested frequency bands):

5> include all 2DL+1UL CA band combinations;

5> include all other CA band combinations;

4> if UE supports maximumCCsRetrieval and if the UECapabilityEnquiry message includes the requestedMaxCCsDL and the requestedMaxCCsUL (i.e. both UL and DL maximums are given):

5> remove from the list of candidates the band combinations for which the number of CCs in DL exceeds the value indicated in the requestedMaxCCsDL or for which the number of CCs in UL exceeds the value indicated in the requestedMaxCCsUL;

5> indicate in requestedCCsUL the same value as received in requestedMaxCCsUL;

5> indicate in requestedCCsDL the same value as received in requestedMaxCCsDL;

4> else if UE supports maximumCCsRetrieval and if the UECapabilityEnquiry message includes the requestedMaxCCsDL (i.e. only DL maximum limit is given):

5> remove from the list of candidates the band combinations for which the number of CCs in DL exceeds the value indicated in the requestedMaxCCsDL;

5> indicate value in requestedCCsDL the same value as received in requestedMaxCCsDL;

4> else if UE supports maximumCCsRetrieval and if the UECapabilityEnquiry message includes the requestedMaxCCsUL (i.e. only UL maximum limit is given):

5> remove from the list of candidates the band combinations for which the number of CCs in UL exceeds the value indicated in the requestedMaxCCsUL;

5> indicate in requestedCCsUL the same value as received in requestedMaxCCsUL;

4> if the UE supports reducedIntNonContComb and the UECapabilityEnquiry message includes requestReducedIntNonContComb:

5> set reducedIntNonContCombRequested to true;

5> remove from the list of candidates the intra-band non-contiguous CA band combinations which support is implied by another intra-band non-contiguous CA band combination included in the list of candidates as specified in TS 36.306 [5], clause 4.3.5.21:

4> if the UE supports requestReducedFormat and UE supports skipFallbackCombinations and UECapabilityEnquiry message includes requestSkipFallbackComb:

5> set skipFallbackCombRequested to true;

5> for each band combination included in the list of candidates (including 2DL+1UL CA band combinations), starting with the ones with the lowest number of DL and UL carriers, that concerns a fallback band combination of another band combination included in the list of candidates as specified in TS 36.306 [5]:

6> remove the band combination from the list of candidates;

6> include differentFallbackSupported in the band combination included in the list of candidates whose fallback concerns the removed band combination, if its capabilities differ from the removed band combination;

4> if the UE supports requestReducedFormat and diffFallbackCombReport, and UECapabilityEnquiry message includes requestDiffFallbackCombList:

5> if the UE does not support skipFallbackCombinations or UECapabilityEnquiry message does not include requestSkipFallbackComb:

6> remove all band combination from the list of candidates;

5> for each CA band combination indicated in requestDiffFallbackCombList:

6> include the CA band combination, if not already in the list of candidates;

6> include the fallback combinations for which the supported UE capabilities are different from the capability of the CA band combination;

5> include CA band combinations indicated in requestDiffFallbackCombList into requestedDiffFallbackCombList;

3> if the UECapabilityEnquiry message includes requestReducedFormat and UE supports requestReducedFormat:

4> include in supportedBandCombinationReduced as many as possible of the band combinations included in the list of candidates, including the non-CA combinations, determined according to the rules and priority order defined above;

3> else:

4> if the UECapabilityEnquiry message includes requestedFrequencyBands and UE supports requestedFrequencyBands:

5> include in supportedBandCombination as many as possible of the band combinations included in the list of candidates, including the non-CA combinations and up to 5DL+5UL CA band combinations, determined according to the rules and priority order defined above;

5> include in supportedBandCombinationAdd as many as possible of the remaining band combinations included in the list of candidates, (i.e. the candidates not included in supportedBandCombination), up to 5DL+5UL CA band combinations, determined according to the rules and priority order defined above;

4> else:

5> if it is not possible to include in supportedBandCombination all the band combinations to be included according to the above, selection of the subset of band combinations to be included is left up to UE implementation;

3> indicate in requestedBands the same bands and in the same order as included in requestedFrequencyBands, if received;

3> if the UE is a category 0, M1 or M2 UE, or supports any UE capability information in ue-RadioPagingInfo, according to TS 36.306 [5]:

4> include ue-RadioPagingInfo and set the fields according to TS 36.306 [5];

3> if the UE supports (NG)EN-DC or NE-DC and if requestedFreqBandsNR-MRDC is included in the request:

4> include into featureSetsEUTRA the feature sets that are applicable for the received requestedFreqBandsNR-MRDC and requestedCapabilityCommon as specified in TS 38.331 [82], clause 5.6.1.4.

NOTE 2: The network must include the requestedFreqBandsNR-MRDC in order to obtain feature sets for E-UTRA and MR-DC.

NOTE 3: Even if the network requests (only) capabilities for eutra, it may include NR band numbers in the requestedFreqBandsNR-MRDC in order to ensure that the UE includes all necessary feature sets (i.e. E-UTRA and NR) needed for subsequently requested eutra-nr capabilities.

3> if the UECapabilityEnquiry message includes requestSTTI-SPT-Capability and if the UE supports short TTI and/or SPT (i.e., sTTI-SPT-Supported):

4> for each band combination the UE included in a field of the UECapabilityInformation message in accordance with the previous:

5> if the UE supports short TTI, include the short TTI capabilities for each of the band combinations using the stti-SPT-BandParameters;

5> if the UE supports SPT, include the SPT capabilities for each of the band combinations using the stti-SPT-BandParameters;

NOTE 4: The UE may have to add/repeat the band combinations to the list of band combinations included earlier, to include short TTI capabilities and/or SPT capabilities.

3> if the UECapabilityEnquiry message includes sidelinkRequest:

4> for a sidelink band combination the UE included in v2x-SupportedBandCombinationListEUTRA-NR:

5> if the UE supports partial sensing for a band of the sidelink band combination, include the partial sensing capabilities for the band using the v2x-BandParametersEUTRA-NR-v1710;

4> set sidelinkRequested to true;

2> if the ue-CapabilityRequest includes geran-cs and if the UE supports GERAN CS domain:

3> include the UE radio access capabilities for GERAN CS within a ue-CapabilityRAT-Container and with the rat-Type set to geran-cs;

2> if the ue-CapabilityRequest includes geran-ps and if the UE supports GERAN PS domain:

3> include the UE radio access capabilities for GERAN PS within a ue-CapabilityRAT-Container and with the rat-Type set to geran-ps;

2> if the ue-CapabilityRequest includes utra and if the UE supports UTRA:

3> include the UE radio access capabilities for UTRA within a ue-CapabilityRAT-Container and with the rat-Type set to utra;

2> if the ue-CapabilityRequest includes cdma2000-1XRTT and if the UE supports CDMA2000 1xRTT:

3> include the UE radio access capabilities for CDMA2000 within a ue-CapabilityRAT-Container and with the rat-Type set to cdma2000-1XRTT;

2> if the ue-CapabilityRequest includes nr and if the UE supports NR:

3> include the UE radio access capabilities for NR within a ue-CapabilityRAT-Container, with the rat-Type set to nr;

3> include band combinations and feature sets as specified in TS 38.331 [82], clause 5.6.1.4, considering the included requestedFreqBandsNR-MRDC, requestedCapabilityNR, the eutra-nr-only flag and requestedCapabilityCommon (if present);

2> if the ue-CapabilityRequest includes eutra-nr and if the UE supports (NG)EN-DC or NE-DC:

3> include the UE radio access capabilities for EUTRA-NR within a ue-CapabilityRAT-Container, with the rat-Type set to eutra-nr;

3> include band combinations as specified in TS 38.331 [82], clause 5.6.1.4, considering the included requestedFreqBandsNR-MRDC, requestedCapabilityNR (if present) and requestedCapabilityCommon (if included);

1> if the RRC message segmentation is enabled based on the field rrc-SegAllowed received, and the encoded RRC message is larger than the maximum supported size of a PDCP SDU specified in TS 36.323 [8]:

2> initiate the UL message segment transfer procedure as specified in clause 5.6.22;

1> else:

2> submit the UECapabilityInformation message to lower layers for transmission, upon which the procedure ends;

5.6.4 CSFB to 1x Parameter transfer

5.6.4.1 General

Figure 5.6.4.1-1: CSFB to 1x Parameter transfer

The purpose of this procedure is to transfer the CDMA2000 1xRTT parameters required to register the UE in the CDMA2000 1xRTT network for CSFB support.

5.6.4.2 Initiation

A UE in RRC_CONNECTED initiates the CSFB to 1x parameter transfer procedure upon request from the CDMA2000 upper layers. The UE initiates the CSFB to 1x parameter transfer procedure by sending the CSFBParametersRequestCDMA2000 message.

5.6.4.3 Actions related to transmission of CSFBParametersRequestCDMA2000 message

The UE shall:

1> submit the CSFBParametersRequestCDMA2000 message to lower layers for transmission using the current configuration;

5.6.4.4 Reception of the CSFBParametersResponseCDMA2000 message

Upon reception of the CSFBParametersResponseCDMA2000 message, the UE shall:

1> forward the rand and the mobilityParameters to the CDMA2000 1xRTT upper layers;

5.6.5 UE Information

5.6.5.1 General

Figure 5.6.5.1-1: UE information procedure

The UE information procedure is used by E-UTRAN to request the UE to report information.

5.6.5.2 Initiation

E-UTRAN initiates the procedure by sending the UEInformationRequest message. E-UTRAN should initiate this procedure only after successful security activation.

5.6.5.3 Reception of the UEInformationRequest message

Upon receiving the UEInformationRequest message, the UE shall, only after successful security activation:

1> if rach-ReportReq is set to true, set the contents of the rach-Report in the UEInformationResponse message as follows:

2> set the numberOfPreamblesSent to indicate the number of preambles sent by MAC for the last successfully completed random access procedure;

2> if contention resolution was not successful as specified in TS 36.321 [6] for at least one of the transmitted preambles for the last successfully completed random access procedure:

3> set the contentionDetected to true;

2> else:

3> set the contentionDetected to false;

2> if the UE is a BL UE or UE in CE:

3> set the initialCEL to indicate the initial CE level used for the last successfully completed random access procedure;

2> if the UE is a NB-IoT UE:

3> set the initialNRSRP-Level to indicate the NRSRP level of the NPRACH resource selected for the first preamble transmission for the last successfully completed random access procedure;

2> if the UE is a BL UE, UE in CE or NB-IoT UE:

3> if the last successfully completed random access procedure was initiated with EDT PRACH resource and succeeded after receiving EDT fallback indication from lower layers:

4> set the edt-Fallback to true;

3> else:

4> set the edt-Fallback to false;

1> if rlf-ReportReq is set to true and the UE has radio link failure information or handover failure information available in VarRLF-Report (VarRLF-Report-NB in NB-IoT) and if the RPLMN is included in plmn-IdentityList stored in VarRLF-Report:

2> for NB-IoT, if the global cell identity of the selected cell is the same as the reestablishmentCellId in the VarRLF-Report-NB:

3> remove the reestablishmentCellId from the VarRLF-Report-NB;

2> set timeSinceFailure in VarRLF-Report (VarRLF-Report-NB in NB-IoT) to the time that elapsed since the last radio link or handover failure in E-UTRA;

2> set the rlf-Report in the UEInformationResponse message to the value of rlf-Report in VarRLF-Report (VarRLF-Report-NB in NB-IoT);

2> discard the rlf-Report from VarRLF-Report (VarRLF-Report-NB in NB-IoT) upon successful delivery of the UEInformationResponse message confirmed by lower layers;

1> except for NB-IoT, if connEstFailReportReq is set to true and the UE has connection establishment failure information in VarConnEstFailReport and if the RPLMN is equal to plmn-Identity stored in VarConnEstFailReport:

2> set timeSinceFailure in VarConnEstFailReport to the time that elapsed since the last connection establishment failure in E-UTRA;

2> set the connEstFailReport in the UEInformationResponse message to the value of connEstFailReport in VarConnEstFailReport;

2> discard the connEstFailReport from VarConnEstFailReport upon successful delivery of the UEInformationResponse message confirmed by lower layers;

1> except for NB-IoT, if the logMeasReportReq is present and if the RPLMN is included in plmn-IdentityList stored in VarLogMeasReport:

2> if VarLogMeasReport includes one or more logged measurement entries, set the contents of the logMeasReport in the UEInformationResponse message as follows:

3> include the absoluteTimeStamp and set it to the value of absoluteTimeInfo in the VarLogMeasReport;

3> include the traceReference and set it to the value of traceReference in the VarLogMeasReport;

3> include the traceRecordingSessionRef and set it to the value of traceRecordingSessionRef in the VarLogMeasReport;

3> include the tce-Id and set it to the value of tce-Id in the VarLogMeasReport;

3> include the logMeasInfoList and set it to include one or more entries from the VarLogMeasReport starting from the entries logged first, and for each entry of the logMeasInfoList that is included, include all information stored in the corresponding logMeasInfoList entry in VarLogMeasReport;

3> if the VarLogMeasReport includes one or more additional logged measurement entries that are not included in the logMeasInfoList within the UEInformationResponse message:

4> include the logMeasAvailable;

4> if logMeasResultListBT is included in one or more of the additional logged measurement entries in VarLogMeasReport that are not included in the logMeasInfoList within the UEInformationResponse message:

5> include the logMeasAvailableBT;

4> if logMeasResultListWLAN is included in one or more of the additional logged measurement entries in VarLogMeasReport that are not included in the logMeasInfoList within the UEInformationResponse message:

5> include the logMeasAvailableWLAN;

1> except for NB-IoT, if mobilityHistoryReportReq is set to true:

2> include the mobilityHistoryReport and set it to include entries from VarMobilityHistoryReport;

2> include in the mobilityHistoryReport an entry for the current cell, possibly after removing the oldest entry if required, and set its fields as follows:

3> set visitedCellId to the global cell identity or the physical cell identity and carrier frequency of the current cell:

3> set field timeSpent to the time spent in the current cell;

1> except for NB-IoT, if the idleModeMeasurementReq is included in the UEInformationRequest and the UE has stored VarMeasIdleReport that contains measurement information concerning cells other than the PCell:

2> set the measResultListIdle-r15 in the UEInformationResponse message to the value of measReportIdle-r15 in the VarMeasIdleReport;

2> set the measResultListExtIdle in the UEInformationResponse message to the value of measReportIdle-r16 in the VarMeasIdleReport, if available;

2> set the measResultListIdleNR in the UEInformationResponse message to the value of measReportIdleNR in the VarMeasIdleReport, if available;

2> discard the VarMeasIdleReport upon successful delivery of the UEInformationResponse message confirmed by lower layers;

1> except for NB-IoT, if flightPathInfoReq field is present and the UE has flight path information available:

2> include the flightPathInfoReport and set it to include the list of waypoints along the flight path;

2> if the includeTimeStamp is set to TRUE:

3> set the field timeStamp to the time when UE intends to arrive to each waypoint if this information is available at the UE;

1> for NB-IoT, if anr-ReportReq is set to true and the UE has measResultList available in VarANR-MeasReport-NB:

2> set the anr-MeasReport in the UEInformationResponse message as follows:

3> if the global cell identity of the PCell is different from servCellIdentity in the VarANR-MeasReport-NB;

4> include the servCellIdentity and set it to the value of servCellIdentity in the VarANR-MeasReport-NB;

3> set measResultServCell to the value of measResultServCell in the VarANR-MeasReport-NB;

3> set relativeTimeStamp to the value of relativeTimeStamp in the VarANR-MeasReport-NB;

3> set measResultList to the value of measResultList in the VarANR-MeasReport-NB;

2> discard the VarANR-MeasReport-NB upon successful delivery of the UEInformationResponse message confirmed by lower layers;

1> except for NB-IoT, if the coarseLocationReq is set to true:

2> if available, include the coarseLocationInfo;

1> if the logMeasReport is included in the UEInformationResponse:

2> submit the UEInformationResponse message to lower layers for transmission via SRB2;

2> discard the logged measurement entries included in the logMeasInfoList from VarLogMeasReport upon successful delivery of the UEInformationResponse message confirmed by lower layers;

1> else:

2> submit the UEInformationResponse message to lower layers for transmission via SRB1;

5.6.6 Logged Measurement Configuration

5.6.6.1 General

Figure 5.6.6.1-1: Logged measurement configuration

The purpose of this procedure is to configure the UE to perform logging of measurement results while in RRC_IDLE and to perform logging of measurement results for MBSFN in both RRC_IDLE and RRC_CONNECTED. The procedure applies to logged measurements capable UEs that are in RRC_CONNECTED.

NOTE: E-UTRAN may retrieve stored logged measurement information by means of the UE information procedure.

5.6.6.2 Initiation

E-UTRAN initiates the logged measurement configuration procedure to UE in RRC_CONNECTED by sending the LoggedMeasurementConfiguration message.

5.6.6.3 Reception of the LoggedMeasurementConfiguration by the UE

Upon receiving the LoggedMeasurementConfiguration message the UE shall:

1> discard the logged measurement configuration as well as the logged measurement information as specified in 5.6.7;

1> store the received loggingDuration, loggingInterval and areaConfiguration, if included, in VarLogMeasConfig;

1> if the LoggedMeasurementConfiguration message includes plmn-IdentityList:

2> set plmn-IdentityList in VarLogMeasReport to include the RPLMN as well as the PLMNs included in plmn-IdentityList;

1> else:

2> set plmn-IdentityList in VarLogMeasReport to include the RPLMN;

1> store the received absoluteTimeInfo, traceReference, traceRecordingSessionRef and tce-Id in VarLogMeasReport;

1> store the received targetMBSFN-AreaList, if included, in VarLogMeasConfig;

1> store the received bt-NameList, if included, in VarLogMeasConfig;

1> store the received wlan-NameList, if included, in VarLogMeasConfig;

1> store the received loggedEventTriggerConfig, if included, in VarLogMeasConfig;

1> store the received measUncomBarPre, if included, in VarLogMeasConfig;

1> start timer T330 with the timer value set to the loggingDuration;

5.6.6.4 T330 expiry

Upon expiry of T330 the UE shall:

1> release VarLogMeasConfig;

The UE is allowed to discard stored logged measurements, i.e. to release VarLogMeasReport, 48 hours after T330 expiry.

5.6.7 Release of Logged Measurement Configuration

5.6.7.1 General

The purpose of this procedure is to release the logged measurement configuration as well as the logged measurement information.

5.6.7.2 Initiation

The UE shall initiate the procedure upon receiving a logged measurement configuration in another RAT. The UE shall also initiate the procedure upon power off or detach.

The UE shall:

1> stop timer T330, if running;

1> if stored, discard the logged measurement configuration as well as the logged measurement information, i.e. release the UE variables VarLogMeasConfig and VarLogMeasReport;

5.6.8 Measurements logging

5.6.8.1 General

This procedure specifies the logging of available measurements by a UE in RRC_IDLE that has a logged measurement configuration and the logging of available measurements by a UE in both RRC_IDLE and RRC_CONNECTED if targetMBSFN-AreaList is included in VarLogMeasConfig.

When UE is configured to perform logging of measurements, measurements are performed with CRS.

5.6.8.2 Initiation

While T330 is running, the UE shall:

1> if measurement logging is suspended:

2> if during the last logging interval the IDC problems detected by the UE is resolved, resume measurement logging;

1> if not suspended, perform the logging in accordance with the following:

2> if targetMBSFN-AreaList is included in VarLogMeasConfig:

3> if the UE is camping normally on an E-UTRA cell or is connected to E-UTRA; and

3> if the RPLMN is included in plmn-IdentityList stored in VarLogMeasReport; and

3> if the PCell (in RRC_CONNECTED) or cell where the UE is camping (in RRC_IDLE) is part of the area indicated by areaConfiguration if configured in VarLogMeasConfig:

4> for MBSFN areas, indicated in targetMBSFN-AreaList, from which the UE is receiving MBMS service:

5> perform MBSFN measurements in accordance with the performance requirements as specified in TS 36.133 [16];

NOTE 1: When configured to perform MBSFN measurement logging by targetMBSFN-AreaList, the UE is not required to receive additional MBSFN subframes, i.e. logging is based on the subframes corresponding to the MBMS services the UE is receiving.

5> perform logging at regular time intervals as defined by the loggingInterval in VarLogMeasConfig, but only for those intervals for which MBSFN measurement results are available as specified in TS 36.133 [16];

2> else:

3> if the loggedEventTriggerConfig is configured in VarLogMeasConfig, and eventType is set to outOfCoverage:

4> perform the logging at regular time intervals as defined by the loggingInterval in VarLogMeasConfig only when the UE is in any cell selection state;

4> upon transition from any cell selection state to camped normally state in E-UTRA:

5> if the RPLMN is included in plmn-IdentityList stored in VarLogMeasReport; and

5> if areaConfiguration is not included in VarLogMeasConfig or if the current camping cell is part of the area indicated by areaConfiguration in VarLogMeasConfig:

6> perform the logging;

3> else if the loggedEventTriggerConfig is configured in VarLogMeasConfig and eventType is set to eventL1:

4> if the UE is in camped normally state on an E-UTRA cell and if the RPLMN is included in plmn-IdentityList stored in VarLogMeasReport:

5> if areaConfiguration is not included in VarLogMeasConfig; or

5> if the serving cell is part of the area indicated by areaConfiguration in VarLogMeasConfig:

6> perform the logging at regular time intervals as defined by the loggingInterval in VarLogMeasConfig only when the conditions indicated by the eventL1 are met;

3> else if the UE is in any cell selection state (as specified in TS 36.304 [4]):

4> perform the logging at regular time intervals, as defined by the loggingInterval in VarLogMeasConfig;

3> else if the UE is camping normally on an E-UTRA cell and if the RPLMN is included in plmn-IdentityList stored in VarLogMeasReport and, if the cell is part of the area indicated by areaConfiguration if configured in VarLogMeasConfig:

4> perform the logging at regular time intervals, as defined by the loggingInterval in VarLogMeasConfig;

2> when adding a logged measurement entry in VarLogMeasReport, include the fields in accordance with the following:

3> if the UE detected IDC problems during the last logging interval:

4> if measResultServCell in VarLogMeasReport is not empty:

5> include inDeviceCoexDetected;

5> suspend measurement logging from the next logging interval;

4> else:

5> suspend measurement logging;

NOTE 1A: The UE may detect the start of IDC problems as early as Phase 1 as described in clause 23.4 of TS 36.300 [9].

3> set the relativeTimeStamp to indicate the elapsed time since the moment at which the logged measurement configuration was received;

3> if detailed location information became available during the last logging interval, set the content of the locationInfo as follows:

4> include the locationCoordinates;

3> if wlan-NameList is included in VarLogMeasConfig:

4> if detailed WLAN measurements are available:

5> include logMeasResultListWLAN, in order of decreasing RSSI for WLAN APs;

3> if bt-NameList is included in VarLogMeasConfig:

4> if detailed Bluetooth measurements are available:

5> include logMeasResultListBT, in order of decreasing RSSI for Bluetooth beacons;

3> if measUncomBarPre is included in VarLogMeasConfig:

4> if available, include the uncomBarPreMeasResult;

3> if targetMBSFN-AreaList is included in VarLogMeasConfig:

4> for each MBSFN area, for which the mandatory measurements result fields became available during the last logging interval:

5> set the rsrpResultMBSFN, rsrqResultMBSFN to include measurement results that became available during the last logging interval;

5> include the fields signallingBLER-Result or dataBLER-MCH-ResultList if the concerned BLER results are availble,

5> set the mbsfn-AreaId and carrierFreq to indicate the MBSFN area in which the UE is receiving MBSFN transmission;

4> if in RRC_CONNECTED:

5> set the servCellIdentity to indicate global cell identity of the PCell;

5> set the measResultServCell to include the layer 3 filtered measured results of the PCell;

5> if available, set the measResultNeighCells to include the layer 3 filtered measured results of SCell(s) and neighbouring cell(s) measurements that became available during the last logging interval, in order of decreasing RSRP, for at most the following number of cells: 6 intra-frequency and 3 inter-frequency cells per frequency and according to the following:

6> for each cell included, include the optional fields that are available;

5> if available, optionally set the measResultNeighCells to include the layer 3 filtered measured results of neighbouring cell(s) measurements that became available during the last logging interval, in order of decreasing RSCP(UTRA)/RSSI(GERAN)/PilotStrength(cdma2000), for at most the following number of cells: 3 inter-RAT cells per frequency/set of frequencies (GERAN), and according to the following:

6> for each cell included, include the optional fields that are available;

4> if in RRC_IDLE:

5> set the servCellIdentity to indicate global cell identity of the serving cell;

5> set the measResultServCell to include the quantities of the serving cell;

5> if available, set the measResultNeighCells, in order of decreasing ranking-criterion as used for cell re-selection, to include neighbouring cell measurements that became available during the last logging interval for at most the following number of neighbouring cells: 6 intra-frequency and 3 inter-frequency neighbours per frequency and according to the following:

6> for each neighbour cell included, include the optional fields that are available;

5> if available, optionally set the measResultNeighCells, in order of decreasing ranking-criterion as used for cell re-selection, to include neighbouring cell measurements that became available during the last logging interval, for at most the following number of cells: 3 inter-RAT cells per frequency/set of frequencies (GERAN), and according to the following:

6> for each cell included, include the optional fields that are available;

4> for the cells included according to the previous (i.e. covering previous and current serving cells as well as neighbouring EUTRA cells) include results according to the extended RSRQ if corresponding results are available according to the associated performance requirements defined in TS 36.133 [16];

4> for the cells included according to the previous (i.e. covering previous and current serving cells as well as neighbouring EUTRA cells) include RSRQ type if the result was based on measurements using a wider band or using all OFDM symbols;

NOTE 2: The UE includes the latest results in accordance with the performance requirements as specified in TS 36.133 [16]. E.g. RSRP and RSRQ results are available only if the UE has a sufficient number of results/ receives a sufficient number of subframes during the logging interval.

3> else:

4> if the UE is in any cell selection state (as specified in TS 36.304 [4]):

5> set anyCellSelectionDetected to indicate the detection of no suitable or no acceptable cell found;

5> if the loggedEventTriggerConfig is not configured in the VarLogMeasConfig;

6> set the servCellIdentity to indicate global cell identity of the last logged cell that the UE was camping on;

6> set the measResultServCell to include the quantities of the last logged cell the UE was camping on;

5> else if the RPLMN at the time of entering the any cell selection state is included in plmn-IdentityList stored in VarLogMeasReport; and

5> if areaConfiguration is not included in VarLogMeasConfig or if the last suitable cell that the UE was camping on is part of the area indicated by areaConfiguration in VarLogMeasConfig:

6> set the servCellIdentity to indicate global cell identity of the last suitable cell that the UE was camping on;

6> set the measResultServingCell to include the quantities of the last suitable cell the UE was camping on;

5> else:

6> set the fields within the servCellIdentity and measResultServingCell to all zeros to indicate unavailability of the servCellIdentity and measResultServCell.

4> else:

5> set the servCellIdentity to indicate global cell identity of the cell the UE is camping on;

5> set the measResultServCell to include the quantities of the cell the UE is camping on;

4> if available, set the measResultNeighCells, in order of decreasing ranking-criterion as used for cell re-selection, to include neighbouring cell measurements that became available during the last logging interval for at most the following number of neighbouring cells: 6 intra-frequency and 3 inter-frequency neighbours per frequency as well as 3 inter-RAT neighbours, per frequency/ set of frequencies (GERAN) per RAT and according to the following:

5> for each neighbour cell included, include the optional fields that are available;

NOTE 3: The UE includes the latest results of the available measurements as used for cell reselection evaluation in RRC_IDLE or as used for evaluation of reporting criteria or for measurement reporting according to 5.5.3 in RRC_CONNECTED, which are performed in accordance with the performance requirements as specified in TS 36.133 [16].

2> when the memory reserved for the logged measurement information becomes full, stop timer T330 and perform the same actions as performed upon expiry of T330, as specified in 5.6.6.4;

5.6.9 In-device coexistence indication

5.6.9.1 General

Figure 5.6.9.1-1: In-device coexistence indication

The purpose of this procedure is to inform E-UTRAN about (a change of) the In-Device Coexistence (IDC) problems experienced by the UE in RRC_CONNECTED, as described in TS 36.300 [9], and to provide the E-UTRAN with information in order to resolve them.

5.6.9.2 Initiation

A UE capable of providing IDC indications may initiate the procedure when it is configured to provide IDC indications and upon change of IDC problem information.

Upon initiating the procedure, the UE shall:

1> if configured to provide IDC indications:

2> if the UE did not transmit an InDeviceCoexIndication message since it was configured to provide IDC indications:

3> if on one or more frequencies for which a measObjectEUTRA is configured, the UE is experiencing IDC problems that it cannot solve by itself; or

3> if configured to provide IDC indications for UL CA; and if on one or more supported UL CA combination comprising of carrier frequencies for which a measurement object is configured, the UE is experiencing IDC problems that it cannot solve by itself; or

3> if configured to provide IDC indications for MR-DC, and if on one or more supported MR-DC combination comprising of at least one E-UTRA carrier frequency for which a measurement object is configured and at least one NR carrier frequency included in candidateServingFreqListNR, the UE is experiencing IDC problems that it cannot solve by itself:

4> initiate transmission of the InDeviceCoexIndication message in accordance with 5.6.9.3;

2> else:

3> if the set of frequencies, for which a measObjectEUTRA is configured and on which the UE is experiencing IDC problems that it cannot solve by itself, is different from the set indicated in the last transmitted InDeviceCoexIndication message; or

3> if for one or more of the frequencies in the previously reported set of frequencies, the interferenceDirection is different from the value indicated in the last transmitted InDeviceCoexIndication message; or

3> if the TDM assistance information is different from the assistance information included in the last transmitted InDeviceCoexIndication message; or

3> if configured to provide IDC indications for UL CA; and if the victimSystemType is different from the value indicated in the last transmitted InDeviceCoexIndication message; or

3> if configured to provide IDC indications for UL CA; and if the set of supported UL CA combinations on which the UE is experiencing IDC problems that it cannot solve by itself and that the UE includes in affectedCarrierFreqCombList according to 5.6.9.3, is different from the set indicated in the last transmitted InDeviceCoexIndication message; or

3> if configured to provide IDC indications for MR-DC, and if the victimSystemType is different from the value indicated in the last transmitted InDeviceCoexIndication message; or

3> if configured to provide IDC indications for MR-DC, for one or more of the frequencies in the previously reported set of frequencies, if interferenceDirectionMRDC is different from the value indicated in the last transmitted InDeviceCoexIndication message; or

3> if configured to provide IDC indications for MR-DC, and if the set of supported MR-DC combinations on which the UE is experiencing IDC problems that it cannot solve by itself and that the UE includes in affectedCarrierFreqCombInfoListMRDC according to 5.6.9.3, is different from the set indicated in the last transmitted InDeviceCoexIndication message:

4> initiate transmission of the InDeviceCoexIndication message in accordance with 5.6.9.3;

NOTE 1: The term "IDC problems" refers to interference issues applicable across several subframes/slots where not necessarily all the subframes/slots are affected.

NOTE 2: For the frequencies on which a serving cell or serving cells is configured that is activated, IDC problems consist of interference issues that the UE cannot solve by itself, during either active data exchange or upcoming data activity which is expected in up to a few hundred milliseconds.
For frequencies on which a SCell or SCells is configured that is deactivated, reporting IDC problems indicates an anticipation that the activation of the SCell or SCells would result in interference issues that the UE would not be able to solve by itself.
For a non-serving frequency, reporting IDC problems indicates an anticipation that if the non-serving frequency or frequencies became a serving frequency or serving frequencies then this would result in interference issues that the UE would not be able to solve by itself.

5.6.9.3 Actions related to transmission of InDeviceCoexIndication message

The UE shall set the contents of the InDeviceCoexIndication message as follows:

1> if there is at least one E-UTRA carrier frequency, for which a measurement object is configured, that is affected by IDC problems:

2> include the field affectedCarrierFreqList with an entry for each affected E-UTRA carrier frequency for which a measurement object is configured;

2> for each E-UTRA carrier frequency included in the field affectedCarrierFreqList, include interferenceDirection and set it accordingly;

2> include Time Domain Multiplexing (TDM) based assistance information, unless idc-HardwareSharingIndication is configured and the UE has no Time Doman Multiplexing based assistance information that could be used to resolve the IDC problems:

3> if the UE has DRX related assistance information that could be used to resolve the IDC problems:

4> include drx-CycleLength, drx-Offset and drx-ActiveTime;

3> else (the UE has desired subframe reservation patterns related assistance information that could be used to resolve the IDC problems):

4> include idc-SubframePatternList;

3> use the MCG as timing reference if TDM based assistance information regarding the SCG is included;

1> if the UE is configured to provide UL CA information and there is a supported UL CA combination comprising of carrier frequencies for which a measurement object is configured, that is affected by IDC problems:

2> include victimSystemType in ul-CA-AssistanceInfo;

2> if the UE sets victimSystemType to wlan or Bluetooth:

3> include affectedCarrierFreqCombList in ul-CA-AssistanceInfo with an entry for each supported UL CA combination comprising of carrier frequencies for which a measurement object is configured, that is affected by IDC problems;

2> else:

3> optionally include affectedCarrierFreqCombList in ul-CA-AssistanceInfo with an entry for each supported UL CA combination comprising of carrier frequencies for which a measurement object is configured, that is affected by IDC problems;

1> if idc-HardwareSharingIndication is configured, and there is at least one E-UTRA carrier frequency, for which a measurement object is configured, the UE is experiencing hardware sharing problems that it cannot solve by itself:

2> include the hardwareSharingProblem and set it accordingly;

1> if the UE is configured to provide IDC indications for MR-DC and there is a supported MR-DC band combination comprising of at least one E-UTRA carrier frequency for which a measurement object is configured and at least one NR carrier frequency included in candidateServingFreqListNR, that is affected by IDC problems; and

1> if the IDC problem does not only concern the E-UTRA band combination as the UE already included in affectedCarrierFreqCombList:

2> for each entry of affectedCarrierFreqCombInfoListMRDC in mrdc-AssistanceInfo;

3> include victimSystemType;

3> include interferenceDirectionMRDC;

3> if the UE sets victimSystemType to wlan or Bluetooth:

4> include a set of at least one NR carrier frequency included in candidateServingFreqListNR and optionally one or more E-UTRA carrier frequency for which a measurement object is configured, that is affected by IDC problems;

3> else:

4> optionally include a set of at least one NR carrier frequency included in candidateServingFreqListNR and optionally one or more E-UTRA carrier frequency for which a measurement object is configured, that is affected by IDC problems;

NOTE 1: When sending an InDeviceCoexIndication message to inform E-UTRAN the IDC problems, the UE includes all assistance information (rather than providing e.g. the changed part(s) of the assistance information).

NOTE 2: Upon not anymore experiencing a particular IDC problem that the UE previously reported, the UE provides an IDC indication with the modified contents of the InDeviceCoexIndication message (e.g. by an empty message).

The UE shall submit the InDeviceCoexIndication message to lower layers for transmission.

5.6.10 UE Assistance Information

5.6.10.1 General

Figure 5.6.10.1-1: UE Assistance Information

The purpose of this procedure is to inform E-UTRAN of the UE’s power saving preference and SPS assistance information, maximum PDSCH/PUSCH bandwidth configuration preference, overheating assistance information, or the UE’s delay budget report carrying desired increment/decrement in the Uu air interface delay or connected mode DRX cycle length and for BL UEs or UEs in CE of the RLM event ("early-out-of-sync" or "early-in-sync") and RLM information or the UE preference for the NR SCG deactivation or that the UE with a deactivated NR SCG has uplink data to send on a DRB for which there is no MCG RLC bearer. Upon configuring the UE to provide power preference indications E-UTRAN may consider that the UE does not prefer a configuration primarily optimised for power saving until the UE explictly indicates otherwise.

5.6.10.2 Initiation

A UE capable of providing power preference indications in RRC_CONNECTED may initiate the procedure in several cases including upon being configured to provide power preference indications and upon change of power preference.

A UE capable of providing SPS assistance information in RRC_CONNECTED may initiate the procedure in several cases including upon being configured to provide SPS assistance information and upon change of SPS assistance information.

A UE capable of providing delay budget report in RRC_CONNECTED may initiate the procedure in several cases, including upon being configured to provide delay budget report and upon change of delay budget preference.

A UE capable of CE mode and providing maximum PDSCH/PUSCH bandwidth preference in RRC_CONNECTED may initiate the procedure upon being configured to provide maximum PDSCH/PUSCH bandwidth preference and/or upon change of maximum PDSCH/PUSCH bandwidth preference.

A UE capable of providing overheating assistance information in RRC_CONNECTED may initiate the procedure if it was configured to do so, upon detecting internal overheating, or upon detecting that it is no longer experiencing an overheating condition.

A UE supporting NR SCG deactivation may intiate the procedure in several cases including upon being configured to provide its preference for NR SCG deactivation and upon change of its preference for NR SCG deactivation.

A UE in EN-DC that has uplink data to transmit for a DRB for which there is no MCG RLC bearer while the SCG is deactivated shall initiate the procedure.

Upon initiating the procedure, the UE shall:

1> if configured to provide power preference indications:

2> if the UE did not transmit a UEAssistanceInformation message with powerPrefIndication since it was configured to provide power preference indications; or

2> if the current power preference is different from the one indicated in the last transmission of the UEAssistanceInformation message and timer T340 is not running:

3> start or restart timer T340 with the timer value set to the powerPrefIndicationTimer, if the UE does not prefer a configuration primarily optimised for power saving;

3> initiate transmission of the UEAssistanceInformation message in accordance with 5.6.10.3;

1> if configured to provide maximum PDSCH/PUSCH bandwidth preference:

2> if the UE did not transmit a UEAssistanceInformation message with bw-Preference since it was configured to provide maximum PDSCH/PUSCH bandwidth preference; or

2> if the current maximum PDSCH/PUSCH bandwidth preference is different from the one indicated in the last transmission of the UEAssistanceInformation message and timer T341 is not running;

3> start timer T341 with the timer value set to the bw-PreferenceIndicationTimer;

3> initiate transmission of the UEAssistanceInformation message in accordance with 5.6.10.3;

1> if configured to provide SPS assistance information:

2> if the UE did not transmit a UEAssistanceInformation message with sps-AssistanceInformation since it was configured to provide SPS assistance information; or

2> if the current SPS assistance information is different from the one indicated in the last transmission of the UEAssistanceInformation message:

3> initiate transmission of the UEAssistanceInformation message in accordance with 5.6.10.3;

1> if configured to report RLM events:

2> if "early-out-of-sync" event has been detected (T314 has expired) and T343 is not running:

3> start timer T343 with the timer value set to the rlmReportTimer:

3> initiate transmission of the UEAssistanceInformation message in accordance with 5.6.10.3;

2> if "early-in-sync" event has been detected (T315 has expired) and T344 is not running:

3> start timer T344 with the timer value set to the rlmReportTimer:

3> initiate transmission of the UEAssistanceInformation message in accordance with 5.6.10.3;

1> if configured to provide delay budget report:

2> if the UE did not transmit a UEAssistanceInformation message with delayBudgetReport since it was configured to provide delay budget report; or

2> if the current delay budget is different from the one indicated in the last transmission of the UEAssistanceInformation message and timer T342 is not running:

3> start or restart timer T342 with the timer value set to the delayBudgetReportingProhibitTimer;

3> initiate transmission of the UEAssistanceInformation message in accordance with 5.6.10.3;

1> if configured to provide overheating assistance information:

2> if the overheating condition has been detected and T345 is not running; or

2> if the current overheating assistance information is different from the one indicated in the last transmission of the UEAssistanceInformation message and timer T345 is not running:

3> start timer T345 with the timer value set to the overheatingIndicationProhibitTimer;

3> initiate transmission of the UEAssistanceInformation message in accordance with 5.6.10.3;

NOTE: In case overheating assistance for NR SCG is released while the regular overheating assistance remains configured, a UE that included SCG overheating parameters in the last reported overheating assistance considers overheating assistance information to be different regardless whether or not its preferences for the regular overheating assistance changed.

1> if configured to provide its preference for NR SCG deactivation:

2> if the UE did not transmit a UEAssistanceInformation message with scg-DeactivationPreference since it was configured to provide its preference for NR SCG deactivation and the UE prefers the NR SCG to be deactivated; or

2> if the UE preference for NR SCG deactivation is different from the one indicated in the last transmission of the UEAssistanceInformation message and timer T346 is not running:

3> start or restart timer T346 with the timer value set to the scg-DeactivationPreferenceProhibitTimer;

3> initiate transmission of the UEAssistanceInformation message in accordance with 5.6.10.3;

1> if the UE is configured with a deactivated NR SCG and there are uplink data to send on a DRB for which rlc-Config is not configured in drb-ToAddModList; and

1> if the UE previously did not have any uplink data to send for any SCG RLC entity:

2> initiate transmission of the UEAssistanceInformation message in accordance with 5.6.10.3.

5.6.10.3 Actions related to transmission of UEAssistanceInformation message

The UE shall set the contents of the UEAssistanceInformation message for power preference indications:

1> if configured to provide power preference indication and if the UE prefers a configuration primarily optimised for power saving:

2> set powerPrefIndication to lowPowerConsumption;

1> else if configured to provide power preference indication:

2> set powerPrefIndication to normal;

The UE shall set the contents of the UEAssistanceInformation message for SPS assistance information:

1> if configured to provide SPS assistance information:

2> if there is any traffic for V2X sidelink communication which needs to report SPS assistance information:

3> include trafficPatternInfoListSL in the UEAssistanceInformation message;

2> if there is any traffic for uplink communication which needs to report SPS assistance information:

3> include trafficPatternInfoListUL in the UEAssistanceInformation message;

The UE shall set the contents of the UEAssistanceInformation message for bandwidth preference indications:

1> set bw-Preference to its preferred configuration;

The UE shall set the contents of the UEAssistanceInformation message for delay budget report:

1> if configured to provide delay budget report:

2> if the UE prefers an adjustment in the connected mode DRX cycle length:

3> set delayBudgetReport to type1 according to a desired value;

2> else if the UE prefers coverage enhancement configuration change:

3> set delayBudgetReport to type2 according to a desired value;

The UE shall set the contents of the UEAssistanceInformation message for the RLM report:

1> if configured to provide RLM report:

2> if T314 has expired:

3> set rlm-event to earlyOutOfSync;

2> if T315 has expired:

3> set rlm-event to earlyInSync;

3> if configured to report rlmReportRep-MPDCCH:

4> set excessRep-MPDCCH to the value indicated by lower layers;

The UE shall set the contents of the UEAssistanceInformation message for overheating assistance indication:

1> if configured to provide overheating assistance indication:

2> if the UE experiences internal overheating:

3> if the UE prefers to temporarily reduce its DL category and UL category:

4> include reducedUE-Category in the OverheatingAssistance IE;

4> set reducedUE-CategoryDL to the number to which the UE prefers to temporarily reduce its DL category;

4> set reducedUE-CategoryUL to the number to which the UE prefers to temporarily reduce its UL category;

3> if the UE prefers to temporarily reduce the number of maximum secondary component carriers:

4> include reducedMaxCCs in the OverheatingAssistance IE;

4> set reducedCCsDL to the number of maximum SCells the UE prefers to be temporarily configured in downlink;

4> set reducedCCsUL to the number of maximum SCells the UE prefers to be temporarily configured in uplink;

3> if configured to provide overheating assistance indication for NR SCG:

4> include overheatingAssistanceForSCG in the OverheatingAssistance IE;

4> if configured with serving cells operating on FR2-2 for NR SCG

5> include overheatingAssistanceForSCG-FR2-2 in the OverheatingAssistance IE;

4> set overheatingAssistanceForSCG and if applicable, overheatingAssistanceForSCG-FR2-2, in accordance with clause 5.7.4.3a as specified in TS 38.331 [82];

2> else (if the UE no longer experiences an overheating condition):

3> if the UE had a preference for the OverheatingAssistance:

4> do not include reducedUE-Category, reducedMaxCCs in OverheatingAssistance IE;

3> if the UE had a preference for the overheatingAssistanceForSCG:

4> do not include overheatingAssistance-v1610 in the UEAssistanceInformation-v1610 IE; or

4> do not include UEAssistanceInformation-v1610 IE in the UEAssistanceInformation-v1530 IE; or

4> do not include UEAssistanceInformation-v1530 IEs in UEAssistanceInformation-v1450 IEs;

4> if configured with serving cells operating on FR2-2 for NR SCG

5> do not include OverheatingAssistance-v1710 in the UEAssistanceInformation-v1710 IE;

NOTE 0: It is up to UE implementation to whether include an empty OverheatingAssistance IE or not, for the case where UE only had a preference for the overheatingAssistanceForSCG.

The UE shall set the contents of the UEAssistanceInformation message for NR SCG deactivation:

1> if configured to provide its preference for NR SCG deactivation;

2> if the UE prefers NR SCG to be deactivated

3> include the scg-DeactivationPreference and set it to scgDeactivationPreferred:

2> else:

3> include the scg-DeactivationPreference and set it to noPreference:

The UE shall:

1> if the UE is configured with a deactivated NR SCG and there are uplink data to send on a DRB for which rlc-Config is not configured in drb-ToAddModList: and

1> if the UE previously did not have any uplink data to send for any SCG RLC entity:

2> include uplinkData in the UEAssistanceInformation message;

1> if the procedure was triggered to provide SPS assistance information and the related configuration was provided by an RRCConnectionReconfiguration message that was received embedded within an NR RRCReconfiguration message:

2> submit the UEAssistanceInformation message via SRB1 embedded in NR RRC message ULInformationTransferIRAT as specified in TS 38.331 [82];

1> else:

2> submit the UEAssistanceInformation message to lower layers for transmission.

NOTE 1: It is up to UE implementation when and how to trigger SPS assistance information.

NOTE 2: It is up to UE implementation to set the content of trafficPatternInfoListSL and trafficPatternInfoListUL.

NOTE 3: Traffic patterns for different Destination Layer 2 IDs are provided in different entries in trafficPatternInfoListSL.

NOTE 4: Although not recommended, UE may start or restart the following timers whenever it sends the UEAssistanceInformation message (i.e. even if the message was not triggered for the concerned feature): T340, T341, T342, T343, T344 and T345.

5.6.11 Mobility history information

5.6.11.1 General

This procedure specifies how the mobility history information is stored by the UE, covering RRC_CONNECTED and RRC_IDLE.

5.6.11.2 Initiation

If the UE supports storage of mobility history information, the UE shall:

1> Upon change of cell, consisting of PCell in RRC_CONNECTED or serving cell in RRC_IDLE, to another E-UTRA or inter-RAT cell or when entering out of service:

2> include an entry in variable VarMobilityHistoryReport possibly after removing the oldest entry, if necessary, according to following:

3> if the global cell identity of the previous PCell/ serving cell is available:

4> include the global cell identity of that cell in the field visitedCellId of the entry;

3> else:

4> include the physical cell identity and carrier frequency of that cell in the field visitedCellId of the entry;

3> set the field timeSpent of the entry as the time spent in the previous PCell/ serving cell;

1> upon entering E-UTRA (in RRC_CONNECTED or RRC_IDLE) while previously out of service and/ or using another RAT:

2> include an entry in variable VarMobilityHistoryReport possibly after removing the oldest entry, if necessary, according to following:

3> set the field timeSpent of the entry as the time spent outside E-UTRA;

5.6.12 RAN-assisted WLAN interworking

5.6.12.1 General

The purpose of this procedure is to facilitate access network selection and traffic steering between E-UTRAN and WLAN.

If required by upper layers (see TS 24.312 [66], the UE shall provide an up-to-date set of the applicable parameters provided by wlan-OffloadConfigCommon or wlan-OffloadConfigDedicated to upper layers, and inform upper layers when no parameters are configured. The parameter set from either wlan-OffloadConfigCommon or wlan-OffloadConfigDedicated is selected as specified in clauses 5.2.2.24, 5.3.12, 5.6.12.2 and 5.6.12.4.

5.6.12.2 Dedicated WLAN offload configuration

The UE shall:

1> if the received wlan-OffloadInfo is set to release:

2> release wlan-OffloadConfigDedicated and t350;

2> if the wlan-OffloadConfigCommon corresponding to the RPLMN is broadcast by the cell:

3> apply the wlan-OffloadConfigCommon corresponding to the RPLMN included in SystemInformationBlockType17;

1> else:

2> apply the received wlan-OffloadConfigDedicated:

5.6.12.3 WLAN offload RAN evaluation

The UE shall:

1> if the UE is configured with either wlan-OffloadConfigCommon or wlan-OffloadConfigDedicated; and

1> if the UE is in RRC_IDLE or none of rclwi-Configuration, lwa-Configuration and lwip-Configuration is configured:

2> provide measurement results required for the evaluation of the network selection and traffic steering rules as defined in TS 24.312 [66] to upper layers;

2> evaluate the network selection and traffic steering rules as defined in TS 36.304 [4] using WLAN identifiers as indicated in other clauses (either provided in steerToWLAN included in rclwi-Configuration or in wlan-Id-List included in SystemInformationBlockType17);

5.6.12.4 T350 expiry or stop

The UE shall:

1> if T350 expires or is stopped:

2> release the wlan-OffloadConfigDedicated and t350;

2> release rclwi-Configuration if configured;

2> if the wlan-OffloadConfigCommon corresponding to the RPLMN is broadcast by the cell:

3> apply the wlan-OffloadConfigCommon and the wlan-Id-List corresponding to the RPLMN included in SystemInformationBlockType17;

5.6.12.5 Cell selection/ re-selection while T350 is running

The UE shall:

1> if, while T350 is running, the UE selects/ reselects a cell which is not the PCell when the wlan-OffloadDedicated was configured:

2> stop timer T350;

2> perform the actions as specified in 5.6.12.4;

5.6.13 SCG failure information

5.6.13.1 General

Figure 5.6.13.1-1: SCG failure information

The purpose of this procedure is to inform E-UTRAN about an SCG failure the UE has experienced i.e. SCG radio link failure, SCG change failure.

5.6.13.2 Initiation

A UE initiates the procedure to report SCG failures when neither MCG nor SCG transmission is suspended and when one of the following conditions is met:

1> upon detecting radio link failure for the SCG, in accordance with 5.3.11; or

1> upon SCG change failure, in accordance with 5.3.5.7a; or

1> upon stopping uplink transmission towards the PSCell due to exceeding the maximum uplink transmission timing difference when powerControlMode is configured to 1, in accordance with clause 7.17.2 of TS 36.133 [29].

In case of DC, upon initiating the procedure, the UE shall:

1> suspend all SCG DRBs and suspend SCG transmission for split DRBs;

1> reset SCG-MAC;

1> stop T307;

1> if the UE is configured with NE-DC:

2> initiate transmission of the SCGFailureInformationEUTRA message via the NR MCG as specified in TS 38.331 [82], clause 5.7.3a;

1> else:

2> initiate transmission of the SCGFailureInformation message in accordance with 5.6.13.3;

5.6.13.3 Actions related to transmission of SCGFailureInformation message

The UE shall set the contents of the SCGFailureInformation message as follows:

1> if the UE initiates transmission of the SCGFailureInformation message to provide SCG radio link failure information:

2> include failureType and set it to the trigger for detecting SCG radio link failure;

1> else if the UE initiates transmission of the SCGFailureInformation message to provide SCG change failure information:

2> include failureType and set it to scg-ChangeFailure;

1> else if the UE initiates transmission of the SCGFailureInformation message due to exceeding maximum uplink transmission timing difference:

2> include failureType and set it to maxUL-TimingDiff;

1> set the measResultServFreqList to include for each E-UTRA SCG cell that is configured, if any, within measResultSCell the quantities of the concerned SCell, if available according to performance requirements in TS 36.133 [16];

1> for each E-UTRA SCG serving frequency included in measResultServFreqList, include within measResultBestNeighCell the physCellId and the quantities of the best non-serving cell, based on RSRP, on the concerned serving frequency;

1> set the measResultNeighCells to include the best measured cells on non-serving E-UTRA frequencies, ordered such that the best cell is listed first, and based on measurements collected up to the moment the UE detected the failure, and set its fields as follows;

2> if the UE was configured to perform measurements for one or more non-serving EUTRA frequencies and measurement results are available, include the measResultListEUTRA;

2> for each neighbour cell included, include the optional fields that are available;

NOTE 1: The measured quantities are filtered by the L3 filter as configured in the mobility measurement configuration. The measurements are based on the time domain measurement resource restriction, if configured. Exclude-listed cells are not required to be reported.

The UE shall submit the SCGFailureInformation message to lower layers for transmission.

5.6.13.4 Failure type determination in NE-DC

The UE shall:

1> if SCG failure is due to T313 expiry:

2> consider the failureType to be t313-Expiry;

1> else if SCG failure is due to indication from SCG MAC that a random access problem was detected:

2> consider the failureType to be randomAccessProblem;

1> else if SCG failure is due to indication from SCG RLC that the maximum number of retransmissions was reached:

2> consider the failureType to be rlc-MaxNumRetx;

1> else if SCG failure is due to SCG change failure:

2> consider the failureType to be scg-ChangeFailure;

5.6.13.5 Setting the contents of MeasResultSCG-FailureMRDC

The UE shall:

1> set the contents of the MeasResultSCG-FailureMRDC as follows:

2> for each measObjectEUTRA for which a measId is configured and for which measurement results are available;

3> include an entry in measResultsFreqListEUTRA;

3> if a serving cell is associated with the MeasObjectEUTRA:

4> set measResultServingCell to include the available quantities of the concerned cell and in accordance with the performance requirements in TS 36.133 [16];

3> set the measResultNeighCellList to include the best measured cells, ordered such that the best cell is listed first, and based on measurements collected up to the moment the UE detected the failure, and set its fields as follows;

4> ordering the cells with sorting as follows:

5> using RSRP if RSRP measurement results are available, otherwise using RSRQ if RSRQ measurement results are available, otherwise using SINR;

4> for each neighbour cell included:

5> include the optional fields for which measurement results are available;

2> if detailed location information is available, set the content of the locationInfo as follows;

3> include the locationCoordinates;

3> include the horizontalVelocity, if available:

2> if available, set the logMeasResultListWLAN to include the WLAN measurement results, in order of decreasing RSSI for WLAN APs;

2> if available, set the logMeasResultListBT to include the Bluetooth measurement results, in order of decreasing RSSI for Bluetooth beacons;

NOTE: The measured quantities are filtered by the L3 filter as configured in the mobility measurement configuration. The measurements are based on the time domain measurement resource restriction, if configured. Exclude-listed cells are not required to be reported.

5.6.13a NR SCG failure information

5.6.13a.1 General

Figure 5.6.13a.1-1: NR SCG failure information

The purpose of this procedure is to inform E-UTRAN about an SCG failure the UE has experienced (e.g. SCG radio link failure, failure to successfully complete an SCG reconfiguration with sync), as specified in TS 38.331 [82], clause 5.7.3.2.

5.6.13a.2 Initiation

A UE initiates the procedure to report NR SCG failures when neither E-UTRA MCG nor NR SCG transmission is not suspended and in accordance with TS 38.331 [82], clause 5.7.3.2. Actions the UE shall perform upon initiating the procedure, other than related to the transmission of the SCGFailureInformationNR message are specified in TS 38.331 [82], clause 5.7.3.2.

5.6.13a.3 Actions related to transmission of SCGFailureInformationNR message

The UE shall set the contents of the SCGFailureInformationNR message as follows:

1> include failureType within failureReportSCG-NR and set it to indicate the SCG failure in accordance with TS 38.331 [82], clause 5.7.3.3;

NOTE 1: This may involve including both failureType-r15 and failureType-v1610, see TS 38.331 [82], clause 5.7.3.3.

1> include and set measResultSCG in accordance with TS 38.331 [82], clause 5.7.3.4:

1> for each NR frequency the UE is configured to measure by measConfig for which measurement results are available:

2> set the measResultFreqListNR to include the best measured cells, ordered such that the best cell is listed first using RSRP to order if RSRP measurement results are available for cells on this frequency, otherwise using RSRQ to order if RSRQ measurement results are available for cells on this frequency, otherwise using SINR to order, and based on measurements collected up to the moment the UE detected the failure, and for each cell that is included, include the optional fields that are available;

NOTE 2: Field measResultSCG is used to report available results for NR frequencies the UE is configured to measure by NR RRC signalling.

1> if detailed location information is available, set the content of the locationInfo as follows:

2> include the locationCoordinates;

2> include the horizontalVelocity, if available;

1> if available, set the logMeasResultListWLAN to include the WLAN measurement results, in order of decreasing RSSI for WLAN APs;

1> if available, set the logMeasResultListBT to include the Bluetooth measurement results, in order of decreasing RSSI for Bluetooth beacons;

The UE shall submit the SCGFailureInformationNR message to lower layers for transmission.

5.6.14 LTE-WLAN Aggregation

5.6.14.1 Introduction

E-UTRAN can configure the UE to connect to a WLAN and configure bearers for LWA (referred to as LWA DRBs). The UE uses the WLAN parameters received from E-UTRAN in performing WLAN measurements. The UE also performs WLAN connection management as described in 5.6.15 while LWA is configured.

5.6.14.2 Reception of LWA configuration

Upon reception of LWA configuration, the UE shall:

1> if the received lwa-Configuration is set to release:

2> release the LWA configuration as described in 5.6.14.3;

1> else:

2> if the received lwa-Config includes lwa-WT-Counter:

3> determine the S-K_WT key based on the K_eNB key and received lwa-WT-Counter value, as specified in TS 33.401 [32];

3> forward the S-K_WTkey to upper layers to be used as a PMK or PSK for WLAN authentication;

2> if the received lwa-Config includes lwa-MobilityConfig:

3> if the received lwa-MobilityConfig includes wlan-ToReleaseList:

4> for each WLAN-Identifiers included in wlan-ToReleaseList:

5> remove the WLAN-Identifiers if already part of the current wlan-MobilitySet in VarWLAN-MobilityConfig;

3> if the received lwa-MobilityConfig includes wlan-ToAddList:

4> for each WLAN-Identifiers included in wlan-ToAddList:

5> add the WLAN-Identifiers to the current wlan-MobilitySet in VarWLAN-MobilityConfig;

3> if the received lwa-MobilityConfig includes associationTimer:

4> start or restart timer T351 with the timer value set to the associationTimer;

3> if the received lwa-MobilityConfig includes successReportRequested:

4> set successReportRequested in VarWLAN-MobilityConfig to the value of successReportRequested;

3> if the received lwa-MobilityConfig includes wlan-SuspendConfig:

4> set the field(s) in wlan-SuspendConfig within VarWLAN-MobilityConfig to the value(s) of field(s) included in wlan-SuspendConfig;

2> start WLAN Status Monitoring as described in 5.6.15.4;

5.6.14.3 Release of LWA configuration

To release the LWA configuration, the UE shall:

1> for each LWA DRB that is part of the current UE configuration:

2> disable data handling for this DRB at the LWAAP entity;

2> perform PDCP data recovery as specified in TS 36.323 [8];

1> delete any existing values in VarWLAN-MobilityConfig and VarWLAN-Status;

1> stop timer T351, if running;

1> stop WLAN status monitoring and WLAN connection attempts for LWA;

1> indicate the release of LWA configuration, if configured, to upper layers;

5.6.15 WLAN connection management

5.6.15.1 Introduction

WLAN connection management procedures in this clause are triggered as specified in other clauses where the UE is using a WLAN connection for LWA, RCLWI or LWIP.

The UE stores the current WLAN mobility set, which is a set of one or more WLAN identifier(s) (e.g. BSSID, SSID, HESSID) in wlan-MobilitySet in VarWLAN-MobilityConfig. This WLAN mobility set can be configured and updated by the eNB. A WLAN is considered to be inside the WLAN mobility set if its identifiers match all WLAN identifiers of at least one entry in wlan-MobilitySet and outside the WLAN mobility set otherwise. When the UE receives a new or updated WLAN mobility set, it initiates connection to a WLAN inside the WLAN mobility set, if not already connected to such a WLAN, and starts WLAN status monitoring as described in 5.6.15.4. The UE can perform WLAN mobility within the WLAN mobility set (connect or reconnect to a WLAN inside the WLAN mobility set) without any signalling to E-UTRAN.

The UE reports the WLAN connection status information to E-UTRAN as described in 5.6.15.2. The information in this report is based on the monitoring of WLAN connection as described in 5.6.15.4.

5.6.15.2 WLAN connection status reporting

5.6.15.2.1 General

Figure 5.6.15.2.1-1: WLAN connection status reporting

The purpose of this procedure is to inform E-UTRAN about the status of WLAN connection for LWA, RCLWI, or LWIP.

5.6.15.2.2 Initiation

The UE in RRC_CONNECTED initiates the WLAN status reporting procedure when:

1> it connects successfully to a WLAN inside WLAN mobility set while T351 is running after a WLAN mobility set change; or

1> after a lwa-WT-Counter update or after a lwip-Counter update (if success report is requested by the eNB); or

1> its connection or connection attempts to all WLAN(s) inside WLAN mobility set fails in accordance with WLAN Status Monitoring described in 5.6.15.4; or

1> T351 expires; or

1> its WLAN connection to all WLAN(s) inside WLAN mobility set becomes temporarily unavailable; or

1> its WLAN connection to a WLAN inside the WLAN mobility set is successfully established after its previous WLAN Connection Status Report indicating WLAN temporary suspension;

Upon initiating the procedure, the UE shall:

1> initiate transmission of the WLANConnectionStatusReport message in accordance with 5.6.15.2.3;

5.6.15.2.3 Actions related to transmission of WLANConnectionStatusReport message

The UE shall set the contents of the WLANConnectionStatusReport message as follows:

1> set wlan-status to status in VarWLAN-Status;

1> submit the WLANConnectionStatusReport message to lower layers for transmission, upon which the procedure ends;

5.6.15.3 T351 Expiry (WLAN connection attempt timeout)

Upon T351 expiry, the UE shall:

1> set the status in VarWLAN-Status to failureTimeout;

1> perform WLAN connection status reporting procedure in 5.6.15.2;

1> stop WLAN status monitoring and WLAN connection attempts;

5.6.15.4 WLAN status monitoring

To perform WLAN status monitoring, the UE shall:

1> if UE is not configured with rclwi-Configuration and WLAN connection to a WLAN inside the WLAN mobility set is successfully established or maintained after a WLAN mobility set configuration update, after a lwa-WT-Counter update or after a lwip-Counter update:

2> set the status in VarWLAN-Status to successfulAssociation;

2> stop timer T351, if running;

2> if successReportRequested in VarWLAN-MobilityConfig is set to TRUE:

3> perform WLAN Connection Status Reporting procedure in 5.6.15.2;

1> if WLAN connection or connection attempts to all WLAN(s) inside WLAN mobility set fails:

2> if the failure is due to WLAN radio link issues:

3> set the status in VarWLAN-Status to failureWlanRadioLink;

2> else if the failure is due to UE internal problems related to WLAN:

3> set the status in VarWLAN-Status to failureWlanUnavailable;

NOTE 1: The UE internal problems related to WLAN include connection to another WLAN based on user preferences or turning off WLAN connection or connection rejection from WLAN or other WLAN problems.

3> remove all WLAN related measurement reporting entries within VarMeasReportList;

2> stop timer T351, if running;

2> perform WLAN Connection Status Reporting procedure in 5.6.15.2;

2> if the UE is configured with rclwi-Configuration:

3> release rclwi-Configuration and inform upper layers of a move-traffic-from-WLAN indication (see TS 24.302 [74]);

2> stop WLAN Status Monitoring and WLAN connection attempts;

1> if wlan-SuspendResumeAllowed in wlan-SuspendConfig within VarWLAN-MobilityConfig is set to TRUE:

2> if WLAN connection to all WLAN(s) inside WLAN mobility set becomes temporarily unavailable:

3> set the status in VarWLAN-Status to suspended;

3> if wlan-SuspendTriggersStatusReport in wlan-SuspendConfig within VarWLAN-MobilityConfig is set to TRUE:

4> trigger PDCP Status Report as specified in TS 36.323 [8];

3> perform WLAN Connection Status Reporting procedure in 5.6.15.2;

2> if the status in VarWLAN-Status in the last WLAN Connection Status Report by this UE was suspended and WLAN connection to a WLAN inside the WLAN mobility set is successfully established:

3> set the status in VarWLAN-Status to resumed;

3> perform WLAN Connection Status Reporting procedure in 5.6.15.2;

5.6.16 RAN controlled LTE-WLAN interworking

5.6.16.1 General

The purpose of this procedure is to perform RAN-controlled LTE-WLAN interworking (RCLWI) i.e. control access network selection and traffic steering between E-UTRAN and WLAN.

5.6.16.2 WLAN traffic steering command

The UE shall:

1> if the received rclwi-Configuration is set to setup:

2> if the command is set to steerToWLAN:

3> inform the upper layers of a move-traffic-to-WLAN indication along with the WLAN identifier lists in steerToWLAN (see TS 24.302 [74]);

3> store steerToWLAN in wlan-MobilitySet in VarWLAN-MobilityConfig;

3> perform the WLAN status monitoring procedure as specified in 5.6.15.4 using steerToWLAN as the WLAN mobility set;

2> else:

3> inform the upper layers of a move-traffic-from-WLAN indication (see TS 24.302 [74]);

3> clear wlan-MobilitySet in VarWLAN-MobilityConfig;

3> stop performing the WLAN status monitoring procedure as specified in 5.6.15.4;

3> delete any existing values in VarWLAN-Status;

1> else (the rclwi-Configuration is released):

2> clear wlan-MobilitySet in VarWLAN-MobilityConfig;

2> stop performing the WLAN status monitoring procedure as specified in 5.6.15.4;

2> delete any existing values in VarWLAN-Status;

2> inform the upper layers of release of the rclwi-Configuration.

5.6.17 LTE-WLAN aggregation with IPsec tunnel

5.6.17.1 General

The WLAN resources that are used over the LWIP tunnel as described in TS 36.300 [9] established as part of LWIP procedures are referred to as ‘LWIP resources’. The purpose of this clause is to specify procedures to indicate to higher layers to initiate the establishment/ release of the LWIP tunnel over WLAN and to indicate which DRB(s) shall use the LWIP resources.

5.6.17.2 LWIP reconfiguration

The UE shall:

1> if the received lwip-Configuration is set to release:

2> release the LWIP configuration, if configured, as described in 5.6.17.3;

1> else:

2> if lwip-MobilityConfig is included:

3> if the received lwip-MobilityConfig includes wlan-ToReleaseList:

4> for each WLAN-Identifiers included in wlan-ToReleaseList:

5> remove the WLAN-Identifiers if already part of the current wlan-MobilitySet in VarWLAN-MobilityConfig;

3> if the received lwip-MobilityConfig includes wlan-ToAddList:

4> for each WLAN-Identifiers included in wlan-ToAddList:

5> add the WLAN-Identifiers to the current wlan-MobilitySet in VarWLAN-MobilityConfig;

3> if the received lwip-MobilityConfig includes associationTimer:

4> start timer T351 with the timer value set according to the value of associationTimer;

3> if the received lwip-MobilityConfig includes successReportRequested:

4> set successReportRequested in VarWLAN-MobilityConfig to the value of successReportRequested;

2> if tunnelConfigLWIP is included:

3> indicate to higher layers to configure the LWIP tunnel according to the received tunnelConfigLWIP, as specified in TS 33.401 [32];

3> if lwip-Counter is included:

4> determine the LWIP-PSK based on the K_eNB key and received lwip-Counter value, as specified in TS 33.401 [32];

4> forward the LWIP-PSKto upper layers for LWIP tunnel establishment;

2> start WLAN Status Monitoring as described in 5.6.15.4;

5.6.17.3 LWIP release

The UE shall:

1> delete any existing values in VarWLAN-MobilityConfig and VarWLAN-Status;

1> stop timer T351, if running;

1> release the lwip-Configuration;

1> indicate to higher layers to stop all DRBs from using the LWIP resources;

1> indicate to higher layers to release the LWIP tunnel, as specified in TS 33.401 [32];

1> stop WLAN status monitoring and WLAN connection attempts for LWIP;

5.6.18 Void

5.6.19 Application layer measurement reporting

5.6.19.1 General

Figure 5.6.19.1-1: Application layer measurement reporting

The purpose of this procedure is to inform E-UTRAN about application layer measurement report.

5.6.19.2 Initiation

A UE capable of application layer measurement reporting in RRC_CONNECTED may initiate the procedure when configured with application layer measurement, i.e. when measConfigAppLayer has been configured by E-UTRAN.

Upon initiating the procedure, the UE shall:

1> if configured with application layer measurement, and SRB4 is configured, and the UE has received application layer measurement report information from upper layers:

2> set the measReportAppLayerContainer in the MeasReportAppLayer message to the value of the application layer measurement report information;

2> set the serviceType in the MeasReportAppLayer message to the type of the application layer measurement report information;

2> submit the MeasReportAppLayer message to lower layers for transmission via SRB4.

5.6.20 Idle/Inactive Measurements

5.6.20.1 General

This procedure specifies the measurements to be performed and stored by a UE in RRC_IDLE or RRC_INACTIVE when it has an idle/inactive measurement configuration.

5.6.20.1a Measurement configuration

The purpose of this procedure is to update the idle/inactive measurement configuration.

The UE initiates this procedure while T331 is running and one of the following conditions is met:

1> upon selecting a cell when entering RRC_IDLE or RRC-INACTIVE from RRC_CONNECTED; or

1> upon update of system information (SIB5, or SIB24), e.g. due to intra-RAT cell (re)selection;

While in RRC_IDLE or RRC_INACTIVE and T331 is running, the UE shall:

1> if VarMeasIdleConfig includes neither a measIdleCarrierListEUTRA nor a measIdleCarrierListNR received from the RRCConnectionRelease message:

2> if the UE is capable of idle/inactive measurements for E-UTRA:

3> if the SIB5 includes the measIdleConfigSIB:

4> store or replace the measIdleCarrierListEUTRA of measIdleConfigSIB of SIB5 within VarMeasIdleConfig;

3> else:

4> remove the measIdleCarrierListEUTRA in VarMeasIdleConfig, if stored;

2> if the UE is capable of idle/inactive measurements for NR:

3> if the SIB5 includes the measIdleConfigSIB-NR:

4> store or replace the measIdleCarrierListNR of measIdleConfigSIB-NR of SIB5 within VarMeasIdleConfig;

3> else:

4> remove the measIdleCarrierListNR in VarMeasIdleConfig, if stored;

1> for each entry in the measIdleCarrierListNR within VarMeasIdleConfig that does not contain an ssb-MeasConfig received from the RRCConnectionRelease message:

2> if there is an entry in measIdleCarrierListNR in measIdleConfigSIB-NR of SIB5 that has the same carrier frequency and subcarrier spacing as the entry in the measIdleCarrierListNR within VarMeasIdleConfig and that contains ssb-MeasConfig:

3> delete the ssb-MeasConfig of the corresponding entry in the measIdleCarrierListNR within VarMeasIdleConfig;

3> store the SSB measurement configuration from SIB5 into maxRS-IndexCellQual, threshRS-Index, measTimingConfig, ssb-ToMeasure, deriveSSB-IndexFromCell, and ss-RSSI-Measurement within ssb-MeasConfig of the corresponding entry in the measIdleCarrierListNR within VarMeasIdleConfig;

2> else if there is an entry in carrierFreqListNR of SIB24 with the same carrier frequency and subcarrier spacing as the entry in measIdleCarrierListNR within VarMeasIdleConfig:

3> delete the ssb-MeasConfig of the corresponding entry in the measIdleCarrierListNR within VarMeasIdleConfig;

3> store the SSB measurement configuration from SIB24 into maxRS-IndexCellQual, threshRS-Index, measTimingConfig, ssb-ToMeasure, deriveSSB-IndexFromCell, and ss-RSSI-Measurement within ssb-MeasConfig of the corresponding entry in measIdleCarrierListNR within VarMeasIdleConfig;

2> else:

3> remove the ssb-MeasConfig of the corresponding entry in the measIdleCarrierListNR within VarMeasIdleConfig, if stored;

5.6.20.2 Performing measurements

When performing measurements on NR carriers according to this clause, the UE shall derive the cell quality as specified in 5.5.3.3 and consider the beam quality to be the value of the measurement results of the concerned beam, where each result is averaged as described in TS 38.215 [89].

While in RRC_IDLE or RRC_INACTIVE, and T331 is running, the UE shall:

1> perform the measurements in accordance with the following:

2> if the SIB2 contains idleModeMeasurements, for each entry in measIdleCarrierListEUTRA within VarMeasIdleConfig:

3> if UE supports carrier aggregation between serving carrier and the carrier frequency and bandwidth indicated by carrierFreq and allowedMeasBandwidth within the corresponding entry;

4> perform measurements in the carrier frequency and bandwidth indicated by carrierFreq and allowedMeasBandwidth within the corresponding entry;

NOTE 1: How the UE performs the idle/inactive measurements is up to UE implementation as long as the requirements in TS 36.133 [16] are met for measurement reporting.

4> if the reportQuantities is set to rsrq:

5> consider RSRQ as the sorting quantity;

4> else:

5> consider RSRP as the sorting quantity;

4> if the measCellList is included:

5> consider cells identified by each entry within the measCellList to be applicable for idle /inactive measurement reporting;

4> else:

5> consider up to maxCellMeasIdle strongest identified cells, according to the sorting quantity, to be applicable for idle/inactive measurement reporting;

4> for all cells applicable for idle/inactive measurement reporting and for the serving cell, derive measurement results for the measurement quantities indicated by reportQuantities;

4> store the derived measurement result as indicated by reportQuantities for the serving cell within measResultServingCell in the measReportIdle in VarMeasIdleReport;

4> store the derived measurement results as indicated by reportQuantities for cells applicable for idle/inactive measurement reporting within measResultNeighCells in the measReportIdle in VarMeasIdleReport in decreasing order of the sorting quantity, i.e. the best cell is included first, as follows:

5> if qualityThreshold is configured:

6> include the measurement results from the cells applicable for idle/inactive measurement reporting whose RSRP/RSRQ measurement results are above the value(s) provided in qualityThreshold;

5> else:

6> include the measurement results from all cells applicable for idle/inactive measurement reporting;

2> if the SIB2 contains idleModeMeasurementsNR and VarMeasIdleConfig includes the measIdleCarrierListNR:

3> for each entry in measIdleCarrierListNR within VarMeasIdleConfig that contains ssb-MeasConfig:

4> if UE supports (NG)EN-DC between serving carrier and the carrier frequency and subcarrier spacing indicated by carrierFreqNR and subCarrierSpacingSSB within the corresponding entry:

5> perform measurements in the carrier frequency and subcarrier spacing indicated by carrierFreqNR and subCarrierSpacingSSB within the corresponding entry;

5> if the reportQuantitiesNR is set to rsrq:

6> consider RSRQ as the cell sorting quantity;

5> else:

6> consider RSRP as the cell sorting quantity;

5> if the measCellListNR is included:

6> consider cells identified by each entry within the measCellListNR to be applicable for idle/inactive measurement reporting;

5> else:

6> consider up to maxCellMeasIdle strongest identified cells, according to the sorting quantity, to be applicable for idle/inactive measurement reporting;

5> for all cells applicable for idle/inactive measurement reporting, derive the cell measurement results for the measurement quantities indicated by reportQuantitiesNR;

5> store the derived measurement results as indicated by reportQuantitiesNR within the measReportIdleNR in VarMeasIdleReport in decreasing order of the cell sorting quantity, i.e. the best cell is included first, as follows:

6> if qualityThresholdNR is configured:

7> include the measurement results from the cells applicable for idle/inactive measurement reporting whose RSRP/RSRQ measurement results are above the value(s) provided in qualityThresholdNR;

6> else:

7> include the measurement results from all cells applicable for idle/inactive measurement reporting;

5> if beamMeasConfigIdle is included in the associated entry in measIdleCarrierListNR and if UE supports nr-IdleInactiveBeamMeasFR1 or nr-IdleInactiveBeamMeasFR2 for the FR of the carrier frequency indicated by carrierFreqNR within the associated entry, for each cell in the measurement results:

6> derive beam measurements based on SS/PBCH block for each measurement quantity indicated in reportQuantityRS-IndexNR, as described in TS 38.215 [89];

6> if the reportQuantityRS–IndexNR is set to rsrq:

7> consider RSRQ as the beam sorting quantity;

6> else:

7> consider RSRP as the beam sorting quantity;

6> set resultRS-IndexList to include up to maxReportRS-Index SS/PBCH block indexes in order of decreasing sorting quantity as follows:

7> include the index associated to the best beam for the sorting quantity and if threshRS-Index is included, the remaining beams whose sorting quantity is above threshRS-Index;

6> if the reportRS-IndexResultsNR is set to true:

7> include the beam measurement results as indicated by reportQuantityRS–IndexNR;

3> if, as the result of the procedure in this clause, the UE performs measurements in one or more carrier frequency indicated by measIdleCarrierListNR:

4> store the cell measurement results for RSRP and RSRQ for the serving cell within measResultServingCell in the measReportIdle in VarMeasIdleReport;

NOTE 2: The UE is not required to perform idle/inactive measurements on a given carrier if the SSB configuration of that carrier provided via dedicated signaling is different from the SSB configuration broadcasted in the serving cell, if any.

NOTE 3: How the UE prioritizes which frequencies to measure or report (in case it is configured with more frequencies than it can measure or report) is left to UE implementation.

5.6.20.3 T331 expiry or stop

The UE shall:

1> if T331 expires or is stopped:

2> release the VarMeasIdleConfig;

NOTE: It is up to UE implementation whether to continue idle/inactive measurements according to SIB5 and SIB24 configuration or according to NR SIB11 and NR SIB4 configuration as specified in TS 38.331 [82] upon inter-RAT cell reselection to NR, after T331 has expired or stopped.

5.6.20.4 Cell re-selection or selection while T331 is running

The UE shall:

1> if intra-RAT cell selection or reselection occurs while T331 is runing:

2> if validityAreaList is configured in VarMeasIdleConfig:

3> if the serving cell frequency does not match with the carrierFreq of any entry in the validityAreaList; or

3> if the serving frequency matches with the carrierFreq of an entry in the validityAreaList, the validityCellList is included in that entry, and the physical cell identity of the serving cell does not match with any entry in validityCellList:

4> stop timer T331;

4> perform the actions as specified in 5.6.20.3, upon which the procedure ends;

2> else if validityArea is configured in VarMeasIdleConfig and UE reselects to a serving cell whose physical cell identity does not match any entry in validityArea for the corresponding carrier frequency:

3> stop timer T331;

3> perform the actions as specified in 5.6.20.3, upon which the procedure ends;

1> if inter-RAT cell selection or reselection occurs while timer T331 is running;

2> stop timer T331;

2> perform the actions as specified in 5.6.20.3;

5.6.21 Failure information

5.6.21.1 General

Figure 5.6.21.1-1: Failure information

The purpose of this procedure is to inform E-UTRAN about a failure that the UE has experienced.

5.6.21.2 Initiation

A UE initiates the procedure to report failures when one of the following conditions is met:

1> upon detecting RLC failure, in accordance with 5.3.11;

1> upon detecting a DAPS HO failure, in accordance with 5.3.5.6.

Upon initiating the procedure, the UE shall:

1> initiate transmission of the FailureInformation message in accordance with 5.6.21.3;

5.6.21.3 Actions related to transmission of FailureInformation message

When initiating the procedure according to 5.6.21.2, the UE shall:

1> set the contents of the FailureInformation message as follows:

2> if the procedure is initiated to report RLC failure:

3> set logicalChannelIdentity to the logical channel identity of the RLC entity;

3> set cellGroupIndication to the cell group where the RLC entity is located;

3> set failureType to the type of failure that has been detected;

2> if the procedure is initiated to report a DAPS HO failure:

3> set failureType to dapsHO-failure;

1> submit the FailureInformation message to lower layers for transmission.

5.6.22 UL message segment transfer

5.6.22.1 General

Figure 5.6.22.1-1: UL message segment transfer

The purpose of this procedure is to transfer segments of UL DCCH messages from UE to E-UTRAN in RRC_CONNECTED.

NOTE: The segmentation of UL DCCH message is only applicable to UECapabilityInformation in this release.

5.6.22.2 Initiation

A UE capable of UL RRC message segmentation in RRC_CONNECTED will initiate the procedure when the following conditions are met:

1> if the RRC message segmentation is enabled based on the field rrc-SegAllowed received, and

1> if the encoded RRC message is larger than the maximum supported size of a PDCP SDU specified in TS 36.323 [8];

Upon initiating the procedure, the UE shall:

1> initiate transmission of the ULDedicatedMessageSegment message as specified in 5.6.22.3;

5.6.22.3 Actions related to transmission of ULDedicatedMessageSegment message

The UE shall segment the encoded RRC PDU based on the maximum supported size of a PDCP SDU specified in TS 36.323 [8]. UE shall minimize the number of segments and set the contents of the ULDedicatedMessageSegment messages as follows:

1> For each new UL DCCH message, set the segmentNumber to 0 for the first message segment and increment the segmentNumber for each subsequent RRC message segment;

1> set rrc-MessageSegmentContainer to include the segment of the UL DCCH message corresponding to the segmentNumber;

1> if the segment included in the rrc-MessageSegmentContainer is the last segment of the UL DCCH message:

2> set the rrc-MessageSegmentType to lastSegment;

1> else:

2> set the rrc-MessageSegmentType to notLastSegment;

1> submit all the ULDedicatedMessageSegment messages generated for the segmented RRC message to lower layers for transmission in ascending order based on the segmentNumber, upon which the procedure ends.

5.6.23 PUR Configuration Request

5.6.23.1 General

Figure 5.6.23.1-1: PUR Configuration Request

The purpose of this procedure is to indicate to the E-UTRAN that the UE is interested to be configured with PUR and provide PUR related information to E-UTRAN, or that the UE is no longer interested to be configured with PUR.

The procedure is applicable only for BL UEs, UEs in CE or NB-IoT UEs.

5.6.23.2 Initiation

A UE in RRC_CONNECTED may initiate the procedure when all of the following conditions are fulfilled:

1> if the UE is connected to EPC:

2> for CP transmission using PUR, SystemInformationBlockType2 (SystemInformationBlockType2-NB in NB-IoT) includes cp-PUR-EPC; or

2> for UP transmission using PUR, SystemInformationBlockType2 (SystemInformationBlockType2-NB in NB-IoT) includes up-PUR-EPC;

1> else if the UE is connected to 5GC:

2> for CP transmission using PUR, SystemInformationBlockType2 (SystemInformationBlockType2-NB in NB-IoT) includes cp-PUR-5GC; or

2> for UP transmission using PUR, SystemInformationBlockType2 (SystemInformationBlockType2-NB in NB-IoT) includes up-PUR-5GC;

1> the size of the resulting MAC PDU including the total UL data size of the traffic is smaller than or equal to the maximum supported TBS based on the UE category.

NOTE 1: It is up to UE implementation how the UE determines whether the size of UL data is suitable for transmission using PUR.

Upon initiating the procedure, the UE shall:

1> initiate transmission of the PURConfigurationRequest message in accordance with 5.6.23.3;

5.6.23.3 Actions related to transmission of PURConfigurationRequest message

When initiating the procedure according to 5.6.23.2, the UE shall set the contents of the PURConfigurationRequest message as follows:

1> if the UE is interested to be configured with PUR, include pur-SetupRequest and set the contents of pur-SetupRequest as follows:

2> set requestedNumOccasions to the requested number of PUR occasions requested;

2> set requestedPeriodicityAndOffset according to the requested periodicity between consecutive PUR occasions and the requested time offset with respect to current time until the first PUR occasion;

2> set requestedTBS to the requested TBS for the PUR occasion(s);

2> if RRC response message is preferred by the UE for acknowledging the reception of a transmission using PUR, include rrc-ACK;

1> if the UE is no longer interested to be configured with PUR:

2> include pur-ReleaseRequest;

The UE shall submit the PURConfigurationRequest message to lower layers for transmission.

5.6.24 Neighbour Relation Reporting for SON ANR in NB-IoT

5.6.24.0 General

This procedure specifies the neighbour measurements and CGI reading performed when the UE is in RRC_IDLE when it has an ANR measurement configuration and the storage of the associated information by a UE in RRC_IDLE and RRC_CONNECTED.

NOTE: E-UTRAN may retrieve the stored ANR measurements information by means of the UE information procedure.

5.6.24.1 Initiation

While the UE is in RRC_IDLE, the UE shall:

1> store the measurement results for the serving cell in measResultServCell in VarANR-MeasReport-NB;

1> while the serving cell global cell identity is the same as stored in servCellIdentity in VarANR-MeasReport-NB:

2> perform the measurements once in accordance with the following:

3> for each carrier frequency indicated by an entry in anr-CarrierList, if present, within VarANR-MeasConfig-NB:

4> add a new entry in measResultList in VarANR-MeasReport-NB;

4> set the carrierFreq to the carrier frequency;

4> perform measurements on the corresponding carrier frequency and determines the strongest cell, if any, on the carrier frequency;

NOTE: How the UE performs ANR measurement in RRC_IDLE is up to UE implementation as long as the measurement requirements (see TS 36.133 [16], clause 4.6) are met. While performing an ANR measurement, the UE performs inter-frequency measurements on the configured frequency regardless of the measurement rules for cell re-selection and the relaxed monitoring measurement rules as specified in TS 36.304 [4].

4> if the strongest cell is not identified by an entry within the excludedCellList, if present, for the corresponding entry in anr-CarrierList:

5> set the physCellId to the physical cell identity of the cell;

5> set the measResultLastServCell to the last measurement results of the PCell;

5> set the measResult to the measurement results of the cell;

5> if the NRSRP measurement result is above the value provided in anr-qualityThreshold:

6> set the cgi-Info with the information obtained from the systemInformationBlockType1-NB of the cell;

2> set the relativeTimeStamp to the elapsed time since the measurements configuration was received;

1> release the VarANR-MeasConfig-NB.

The UE may discard the ANR measurements information, i.e. release the UE variables VarANR-MeasConfig-NB and VarANR-MeasReport-NB, 96 hours after the configuration was received, upon power off or upon detach and upon entering another RAT.

5.6.25 DL message segment transfer

5.6.25.1 General

Figure 5.6.25.1-1: DL message segment transfer

The purpose of this procedure is to transfer segments of DL DCCH messages from E-UTRAN to the UE.

NOTE: The segmentation of DL DCCH message is only applicable to RRCConnectionReconfiguration and RRCConnectionResume messages in this release.

5.6.25.2 Initiation

E-UTRAN initiates the DL Dedicated Message Segment transfer procedure whenever the encoded RRC message PDU exceeds the maximum PDCP SDU size. E-UTRAN initiates the DL Dedicated Message Segment transfer procedure by sending the DLDedicatedMessageSegment message.

5.6.25.3 Reception of DLDedicatedMessageSegment by the UE

Upon receiving DLDedicatedMessageSegment message, the UE shall:

1> store the segment;

1> if all segments of the message have been received:

2> assemble the message from the received segments and process the message according to 5.3.5 for the RRCConnectionReconfiguration message or 5.3.3.4a for the RRCConnectionResume message;

2> discard all segments.

5.6.26 MCG failure information

5.6.26.1 General

Figure 5.6.26.1-1: MCG failure information

The purpose of this procedure is to inform the network about an MCG failure the UE has experienced i.e. MCG radio link failure. A UE in RRC_CONNECTED, for which AS security has been activated with SRB2 and at least one DRB setup, may initiate the fast MCG link recovery procedure in order to continue the RRC connection without re-establishment.

5.6.26.2 Initiation

A UE configured with split SRB1 or SRB3 initiates the procedure to report MCG failures when neither MCG nor SCG transmission is suspended, the SCG is not deactivated, t316 is configured, and when the following condition is met:

1> upon detecting radio link failure of the MCG, in accordance with 5.3.11, while T316 is not running.

Upon initiating the procedure, the UE shall:

1> stop timer T310, if running;

1> stop timer T312, if running;

1> suspend MCG transmission for all SRBs and DRBs, except SRB0;

1> reset MCG MAC;

1> stop conditional reconfiguration evaluation for CHO, if configured;

1> stop conditional reconfiguration evaluation for CPC, if configured;

1> initiate transmission of the MCGFailureInformation message in accordance with 5.6.26.4.

NOTE: The handling of any outstanding UL RRC messages during the initiation of the fast MCG link recovery is left to UE implementation.

5.6.26.3 Failure type determination

The UE shall set the MCG failure type as follows:

1> if the UE initiates transmission of the MCGFailureInformation message due to T310 expiry:

2> set the failureType as t310-Expiry;

1> else if the UE initiates transmission of the MCGFailureInformation message due to T312 expiry:

2> set the failureType as t312-Expiry;

1> else if the UE initiates transmission of the MCGFailureInformation message to provide random access problem indication from MCG MAC:

2> set the failureType as randomAccessProblem;

1> else if the UE initiates transmission of the MCGFailureInformation message to provide indication from MCG RLC that the maximum number of retransmissions has been reached:

2> set the failureType as rlc-MaxNumRetx.

5.6.26.4 Actions related to transmission of MCGFailureInformation message

The UE shall set the contents of the MCGFailureInformation message as follows:

1> include and set failureType in accordance with 5.6.26.3;

1> for each measObjectEUTRA for which a measId is configured and for which measurement results are available:

2> include an entry in measResultsFreqListEUTRA;

2> if a serving cell is associated with the MeasObjectEUTRA:

3> set measResultServingCell to include the available quantities of the concerned cell and in accordance with the performance requirements in TS 36.133 [16];

2> set the measResultNeighCellList to include the best measured cells, ordered such that the best cell is listed first, and based on measurements collected up to the moment the UE detected the failure, and set its fields as follows:

3> ordering the cells with sorting as follows:

4> using RSRP if RSRP measurement results are available, otherwise using RSRQ if RSRQ measurement results are available, otherwise using SINR;

3> for each neighbour cell included:

4> include the optional fields for which measurement results are available;

1> for each NR frequency the UE is configured to measure by measConfig for which measurement results are available:

2> set the measResultFreqListNR to include the best measured cells, ordered such that the best cell is listed first using RSRP to order the cells if RSRP measurement results are available for cells on this frequency, otherwise using RSRQ to order the cells if RSRQ measurement results are available for cells on this frequency, otherwise using SINR to order the cells, based on measurements collected up to the moment the UE detected the failure, and for each cell that is included, include the optional fields that are available;

1> for each UTRA frequency the UE is configured to measure by measConfig for which measurement results are available:

2> set the measResultFreqListUTRA to include the best measured cells, ordered such that the best cell is listed first using RSCP to order the cells if RSCP measurement results are available for cells on this frequency, otherwise using EcN0 to order the cells, based on measurements collected up to the moment the UE detected the failure, and for each cell that is included, include the optional fields that are available;

1> for each GERAN frequency the UE is configured to measure by measConfig for which measurement results are available:

2> set the measResultFreqListGERAN to include the best measured cells based on measurements collected up to the moment the UE detected the failure, and for each cell that is included, include the optional fields that are available;

1> if the UE is in (NG)EN-DC:

2> include and set measResultSCG in accordance with TS 38.331 [82], clause 5.7.3.4:

NOTE 2: Field measResultSCG is used to report available results for NR frequencies the UE is configured to measure by NR RRC signalling.

1> if SRB1 is configured as split SRB and pdcp-Duplication is not configured in accordance with TS 38.331 [82, 6.3.2]:

2> if the primaryPath for the PDCP entity of SRB1 refers to to the MCG:

3> set the primaryPath to refer to the SCG.

The UE shall:

1> start timer T316;

1> if SRB1 is configured as split SRB:

2> submit the MCGFailureInformation message to lower layers for transmission via SRB1, upon which the procedure ends;

1> else (i.e. SRB3 is configured):

2> submit the MCGFailureInformation message to lower layers for transmission, embedded in NR RRC message ULInformationTransferMRDC via SRB3 as specified in TS 38.331 [82], clause 5.7.2a.3.

5.6.26.5 T316 expiry

The UE shall:

1> if T316 expires:

2> initiate the connection re-establishment procedure as specified in 5.3.7.

5.6.27 Void

5.6.28 UL transfer of IRAT information

5.6.28.1 General

Figure 5.6.28.1-1: UL transfer of IRAT information

The purpose of this procedure is to transfer from the UE to E-UTRAN dedicated information terminated by E-UTRAN but specified by another RAT e.g. the NR RRC MeasurementReport message, the NR RRC SidelinkUEInformationNR message or the NR RRC UEAssistanceInformation message. The specific information transferred in this message is set in accordance with:

– the procedure specified in 5.7.4 of TS 38.331 [82] for NR UEAssistanceInformation message;

– the procedure specified in 5.8.3 of TS 38.331 [82] for NR SidelinkUEInformationNR message;

– the procedure specified in 5.5.5 of TS 38.331 [82] for NR MeasurementReport Message.

5.6.28.2 Initiation

A UE in RRC_CONNECTED initiates the UL information transfer procedure whenever there is a need to transfer dedicated IRAT information as specified in TS 38.331 [82].

5.6.28.3 Actions related to transmission of ULInformationTransferIRAT message

The UE shall set the contents of the ULInformationTransferIRAT message as follows:

1> if there is a need to transfer dedicated NR information:

2> set the ul-DCCH-MessageNR to include the IRAT dedicated information to be transferred;

1> submit the ULInformationTransferIRAT message to lower layers for transmission, upon which the procedure ends.