5.6 Other

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

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

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 or time reference 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.

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.

5.6.2.2 Initiation

A UE in RRC_CONNECTED initiates the UL information transfer procedure whenever there is a need to transfer NAS or 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. 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.

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, 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 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> 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;

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 Measurement Report message.

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.

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 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):

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 the xDD mode supported by the UE;

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> 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 defined above;

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.

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> 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;

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

2> set timeSinceFailure in VarRLF-Report 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;

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

1> 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> 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> 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 of the current cell:

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

1> if the idleModeMeasurementReq is included in the UEInformationRequest and UE has stored VarMeasIdleReport:

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

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

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

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 if:

3> 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 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 carrierFrequency 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 (UTRA, cdma2000)/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 (UTRA, cdma2000)/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> set the servCellIdentity to indicate global cell identity of the last logged cell that the UE was camping on;

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

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;

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

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;

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;

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

3> do not include reducedUE-Category and reducedMaxCCs in OverheatingAssistance IE;

The UE shall 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 SCG transmission is not 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. Blacklisted 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;

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. Blacklisted 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: NRSCG 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 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;

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: Field measResultSCG is used to report available results for NR frequencies the UE is configured to measure by NR RRC signalling.

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-KWT key based on the KeNB key and received lwa-WT-Counter value, as specified in TS 33.401 [32];

3> forward the S-KWT key 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 KeNB key and received lwip-Counter value, as specified in TS 33.401 [32];

4> forward the LWIP-PSK to 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 Mode Measurements

5.6.20.1 General

This procedure specifies the measurements done by a UE in RRC_IDLE or RRC_INACTIVE when it has an IDLE mode measurement configuration and the storage of the available measurements by a UE in RRC_IDLE, RRC_INACTIVE and RRC_CONNECTED.

5.6.20.2 Initiation

While T331 is running, the UE shall:

1> perform the measurements in accordance with the following:

2> 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: The fields s-NonIntraSearch in SystemInformationBlockType3 do not affect the UE measurement procedures in IDLE mode. How the UE performs measurements in IDLE mode is up to UE implementation as long as the requirements in TS 36.133 [16] are met for measurement reporting. UE is not required to perform idle measurements if the SIB2 does not contain idleModeMeasurements.

4> if the measCellList is included:

5> consider the serving cell and cells identified by each entry within the measCellList to be applicable for idle mode measurement reporting;

4> else:

5> consider the serving cell and up to maxCellMeasIdle strongest identified cells whose RSRP/RSRQ measurement results are above the value(s) provided in qualityThreshold (if any) to be applicable for idle mode measurement reporting;

4> store measurement results for cells applicable for idle mode measurement reporting within the VarMeasIdleReport;

NOTE 2: 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.

3> else:

4> do not consider the carrier frequency to be applicable for idle mode measurement reporting;

1> 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:

2> stop T331;

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 mode measurements according to SIB5 configuration after T331 has expired or stopped.

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.

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 set the contents of the FailureInformation message as follows:

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

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

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

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

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