MR-DC and NR-DC

Dual Connectivity means that one UE is connected to two base stations at the same time. One of them is the Master Node (MN) and the other is the Secondary Node (SN). The UE gets radio resources from both, so it can use more bandwidth than one node can give. In NR this idea is called MR-DC (Multi-Radio Dual Connectivity), because the two nodes can use different radio technologies. EN-DC, the LTE + NR combination of the first 5G networks, is one form of MR-DC. NR-DC, where both nodes are gNBs, is another.

The basic architecture was fixed in Release 15 and it has not changed since. But almost every release after that added something around it. There is a faster way to recover from MCG failure, and there are ways to save UE power while keeping the SCG. Early measurements let DC be set up quickly, and conditional procedures cover PSCell addition and change. These pieces are scattered over several pages of this site, such as Interworking with LTE, CHO, Power Saving and Split Bearer. This page puts them in one line, from day 1 (Release 15) to Release 18.

What is Dual Connectivity ?
Release Evolution
Day 1 Architecture - Release 15
Day 1 Procedures - Release 15
Fast MCG Recovery - Release 16
SCell Dormancy - Release 16
Early Measurement in IDLE and INACTIVE - Release 16
SCG Deactivation - Release 17
CPC, CPA and Subsequent CPAC - Release 16 to 18
Reference

What is Dual Connectivity ?

Why do we need Dual Connectivity when we already have Carrier Aggregation ? CA also gives the UE more than one carrier. The difference is where the carriers come from. In CA, all carriers are controlled by one MAC entity in one node, so the scheduler sees all of them at once. This needs a very fast connection between the carriers, practically the same baseband. DC came from LTE (see LTE Dual Connectivity). It was designed for the case where the two nodes are connected with non-ideal backhaul, like X2 or Xn, with milliseconds of delay. Each node has its own MAC and its own scheduler.

So in DC the UE has two cell groups. The MCG (Master Cell Group) is the group of the MN, with the PCell and optional SCells. The SCG (Secondary Cell Group) is the group of the SN, with the PSCell and optional SCells. Inside each group, normal CA works. Between the groups, the coordination is slow, over the network interface. In the first 5G deployments there was one more reason. NR was deployed on top of an existing LTE network, and DC let the UE keep LTE as the anchor while it used NR for data. That is EN-DC.

One thing to keep in mind is that DC also works inside one gNB. NR-DC can be used when a single gNB acts as both MN and SN, with an MCG and an SCG. This is common for FR1 + FR2, where the two frequency ranges are handled like two separate nodes even though they are in the same box. Basically, DC is about two MAC entities and two cell groups, not necessarily about two physical sites.

Option	MN	SN	Core	MN - SN interface	Common name
EN-DC	eNB	en-gNB	EPC	X2	NSA option 3 / 3a / 3x
NGEN-DC	ng-eNB	gNB	5GC	Xn	option 7
NE-DC	gNB	ng-eNB	5GC	Xn	option 4
NR-DC	gNB	gNB	5GC	Xn, or internal in one gNB	SA with two NR cell groups

MR-DC is the family name: EN-DC, NGEN-DC, NE-DC and NR-DC are all MR-DC. One node gives NR access, the other gives NR or E-UTRA access.
At least the MN is connected to the core: S1-MME or NG-C ends in the MN. The SN can have its own user plane connection to the core (S1-U or NG-U), but never its own control plane connection.
Two MAC entities: this is the real line between DC and CA. Each cell group has its own MAC, its own HARQ entities, its own PUCCH and its own RLF.

Release Evolution

Before going into details, let's look at the whole history. The question I had when reading the specifications was this: if Release 15 already defined MR-DC completely, what did the later releases actually add ? Figure 1 is my answer. Nothing replaced the Release 15 design. Every later feature solves a problem that appeared once DC was used in real networks: failures, battery, setup delay and mobility.

Figure 1. MR-DC features by release. The Release 15 architecture stays as it is, and each later release adds a mechanism around it for robustness, power, setup delay or mobility.

Release 15: everything you need to run DC. EN-DC came first in the early drop for NSA. NGEN-DC, NE-DC and NR-DC came in the late drop.
Release 16: making DC robust and fast to set up. The SCG can be used to recover the MCG. SCells can sleep without being deactivated. The UE can measure candidate carriers before it is even connected.
Release 17: making DC affordable for the battery. The whole SCG can be deactivated while the UE stays in DC. Conditional procedures cover PSCell addition and inter-SN change.
Release 18: making DC mobility cheap. A conditional PSCell configuration is no longer thrown away after each use.
Release 19: SCG LTM and more reporting appear in the latest ASN.1, but they are outside the scope of this page.

One thing the timeline does not show is that these features depend on each other. They were added in different releases, but in a real network they run at the same time on the same UE. So a later feature often has to say what happens to an earlier one. Following are the interactions that I think are the most useful to remember when reading a log or a specification.

Fast MCG recovery needs an active SCG: if the MCG fails while the SCG is deactivated (Release 17), the UE does not use fast MCG recovery (Release 16). It goes to RRC re-establishment.
Fast MCG recovery needs a path: T316 can be configured only when split SRB1 or SRB3 exists. Both of these are Release 15 features, so a network that never configured them cannot use fast MCG recovery.
Dormancy and SCG deactivation work at different levels: SCell dormancy (Release 16) puts individual SCells to sleep and needs an active SpCell to carry the DCI. SCG deactivation (Release 17) stops the whole SCG, including the PSCell, and all SCG SCells are deactivated with it.
Conditional configurations are released by other procedures: a normal PSCell change or PCell change command releases stored CPC and CPA configurations. Subsequent CPAC (Release 18) is the exception that survives.
Failure of a new procedure is reported in an old message: CPA, CPC and subsequent CPAC execution failures are reported with the Release 15 SCGFailureInformation, extended with new fields.

Day 1 Architecture - Release 15

Let's start from the control plane, because this is where DC is most different from a single connection. The UE has one RRC state, and it is decided by the MN. There is one control plane connection toward the core, also through the MN. But each node has its own RRC entity, and both can create RRC messages for the UE. Then how can two RRC entities talk to one UE without confusing it ?

The answer is in the SRBs. The MN uses the normal SRB1 and SRB2. The SN RRC messages can travel in two ways. They can be embedded in an MN RRC message and sent over SRB1, or they can be sent directly over a new SRB, SRB3, between the UE and the SN. Figure 2 shows these paths. Note that the first SN configuration always goes through the MN over SRB1, because SRB3 does not exist until that configuration sets it up.

Figure 2. MR-DC control plane. One RRC state from the MN, two RRC entities, and three ways to reach the UE: MCG SRBs, SRB3 for the SN alone, and the SCG leg of a split SRB for MN messages.

SRB3: the SN decides to set it up. It carries only SN RRC messages that do not need MN coordination, such as an SN reconfiguration, an SN measurement report and an SN failure report for an SCG RLC bearer. No MN RRC message ever goes on SRB3. It uses NR PDCP with keys derived from S-KgNB. SRB3 exists in EN-DC, NGEN-DC and NR-DC, but not in NE-DC.
Split SRB: SRB1 or SRB2 of the MN, with an additional leg over the SCG. The MN RRC message can go through the SN, or be duplicated on both legs. In UL, the MN tells the UE whether to use only the MCG path or to duplicate. Split SRB uses NR PDCP.
Embedded SN RRC: in NR RRC (NR-DC, NE-DC), the SN message is in mrdc-SecondaryCellGroupConfig of RRCReconfiguration. In EN-DC, the MN is an eNB, so the NR SCG configuration is carried inside the LTE RRCConnectionReconfiguration. That LTE side is described in LTE RRC Configuration on the Interworking page.
The MN does not change the SN configuration: when the MN forwards an SN RRC message, it puts it in a container as it is. This is why the SN part is an OCTET STRING.

Following is based on 38.331 v19.4.0 (Release 19)

RRCReconfiguration-v1560-IEs ::=         SEQUENCE {
    mrdc-SecondaryCellGroupConfig            SetupRelease { MRDC-SecondaryCellGroupConfig }                        OPTIONAL,   -- Need M
    radioBearerConfig2                       OCTET STRING (CONTAINING RadioBearerConfig)                           OPTIONAL,   -- Need M
    sk-Counter                               SK-Counter                                                            OPTIONAL,   -- Need N
    nonCriticalExtension                     RRCReconfiguration-v1610-IEs                                          OPTIONAL
}

MRDC-SecondaryCellGroupConfig ::=       SEQUENCE {
    mrdc-ReleaseAndAdd                      ENUMERATED {true}                                                     OPTIONAL,   -- Need N
    mrdc-SecondaryCellGroup                 CHOICE {
        nr-SCG                                  OCTET STRING  (CONTAINING RRCReconfiguration),
        eutra-SCG                               OCTET STRING
    }
}

nr-SCG / eutra-SCG: the SN RRC message as a container. In NR-DC it is a complete NR RRCReconfiguration of the SN. In NE-DC it is an E-UTRA message, because the SN is an ng-eNB.
radioBearerConfig2: a second RadioBearerConfig, used for the bearers terminated in the SN.
sk-Counter: the counter used to derive the SN key (S-KgNB) from the MN key. A new value means a new SN key.
mrdc-ReleaseAndAdd: release the current SCG and add a new one in the same step.

Bearer types

On the user plane, the question is where each bearer goes. Release 15 defines it in two independent dimensions, and this is the part that confuses people the most. From the UE point of view there are three bearer types. From the network point of view, each of them can be terminated in the MN or in the SN. So there are six combinations, not three.

MCG bearer, SCG bearer, split bearer: this is about radio resources. The RLC bearers are in the MCG, in the SCG, or in both.
MN terminated, SN terminated: this is about where the PDCP sits and where the user plane from the core ends. An SN terminated MCG bearer is possible: the PDCP is in the SN, but the data goes over the air through the MN.
PDCP: in MR-DC with 5GC, NR PDCP is always used. In EN-DC, an MN terminated MCG bearer can use E-UTRA PDCP or NR PDCP, and all other bearers use NR PDCP.
Split bearer details: how the data is divided between the legs and how the reordering works is described in the Split Bearer page.

Day 1 Procedures - Release 15

Most of what happens in DC is a small set of network procedures between the MN and the SN, defined in TS 37.340 clause 10. They are worth knowing by name, because the UE only sees an RRCReconfiguration in all of them. The X2 or Xn messages before it tell you which procedure it was.

SN Addition: the MN asks a candidate SN to allocate resources, typically after a measurement report (B1 in EN-DC, A4 in NR-DC). The SN answers with an SCG configuration. The MN sends it to the UE over SRB1, and the UE does random access on the PSCell.
SN Modification: initiated by the MN or by the SN. It changes the bearers or other parts of the UE context within the same SN. It is also used for a PSCell change within the same SN.
SN Change: the UE context moves from one SN to another. It can be triggered by the MN, or by the source SN.
SN Release: the SCG is released. Bearers may move back to the MN.
Inter-MN handover: the PCell changes to another MN, and the target MN decides whether to keep, change or release the SN.

One detail about PSCell change is useful when reading a log. A PSCell change does not always need a new security key. If the key changes, it is a synchronous SCG reconfiguration with random access, MAC reset, RLC re-establishment and PDCP re-establishment for SN terminated bearers. If the key does not change, the SCG MAC is reset and the RLC is re-established, but AM DRBs only do PDCP data recovery. This keyless case is possible in EN-DC, NGEN-DC and NR-DC, and it does not need the MN if no MN terminated SCG or split bearers exist.

SCG failure

What if the SCG radio link fails ? In DC, RLF is declared separately for the MCG and for the SCG. An SCG failure is not a reason to drop the whole connection, because the MCG is still fine. So the UE does not do re-establishment. It suspends SCG transmissions and reports the failure to the MN with SCGFailureInformation, and the MN decides whether to keep, change or release the SN. This is the Release 15 behavior, and the details on the EN-DC side are on the SCG Failure part of the Interworking page.

Following is based on 38.331 v19.4.0 (Release 19)

FailureReportSCG ::=                     SEQUENCE {
    failureType                              ENUMERATED {
                                                 t310-Expiry, randomAccessProblem,
                                                 rlc-MaxNumRetx,
                                                 synchReconfigFailureSCG, scg-ReconfigFailure,
                                                 srb3-IntegrityFailure, other-r16, spare1},
    measResultFreqList                       MeasResultFreqList                                    OPTIONAL,
    measResultSCG-Failure                    OCTET STRING (CONTAINING MeasResultSCG-Failure)       OPTIONAL,
    ...,
    [[
    locationInfo-r16                         LocationInfo-r16                                      OPTIONAL,
    failureType-v1610                        ENUMERATED {scg-lbtFailure-r16, beamFailureRecoveryFailure-r16,
                                                        t312-Expiry-r16, bh-RLF-r16, beamFailure-r17, spare3, spare2, spare1} OPTIONAL
    ]],
    [[
    previousPSCellId-r17                 SEQUENCE {
        physCellId-r17                       PhysCellId,
        carrierFreq-r17                      ARFCN-ValueNR
    }                                                             OPTIONAL,
    failedPSCellId-r17                   SEQUENCE {
        physCellId-r17                       PhysCellId,
        carrierFreq-r17                      ARFCN-ValueNR
     }                                                            OPTIONAL,
    timeSCGFailure-r17                   INTEGER (0..1023)        OPTIONAL,
    perRAInfoList-r17                    PerRAInfoList-r16          OPTIONAL
    ]],
    [[
    perRAInfoList-v17b0                  PerRAInfoList-v1660      OPTIONAL
    ]],
    [[
    perRAInfoList-v1840                  PerRAInfoList-v1800      OPTIONAL
    ]],
    [[
    cho-WithCandidateSCGInfoList-r19     CHO-WithCandidateSCGInfoList-r19        OPTIONAL
    ]]
}

failureType: the Release 15 causes. synchReconfigFailureSCG is the failure of an SN addition or PSCell change (T304 of the SCG). srb3-IntegrityFailure exists only because SCG messages can arrive directly on SRB3.
failureType-v1610: Release 16 adds NR-U LBT, beam failure recovery failure, T312 and IAB backhaul RLF. Release 17 adds beamFailure-r17, which is a beam failure detected while the SCG is deactivated (see SCG Deactivation).
previousPSCellId / failedPSCellId / timeSCGFailure -r17: information for MRO of PSCell change. It is the SCG version of the RLF report fields described in the SON page.

Fast MCG Recovery - Release 16

Now the opposite case. What if the MCG fails while the SCG is still fine ? In Release 15 the answer was harsh. MCG RLF means RRC re-establishment, and re-establishment releases the SCG. So a UE with a perfectly good link to the SN went through cell selection and lost all its DC configuration, just because the anchor link failed. In FR1 + FR2 NR-DC, or in EN-DC with a weak LTE anchor, this can happen often.

Release 16 adds fast MCG link recovery. The idea is to use the healthy SCG to tell the MN that the MCG failed, and let the MN fix it, usually with a handover. The constraint is that the MN must be reachable over the SCG. So the UE needs either a split SRB1, whose SCG leg goes through the SN, or SRB3, which can carry the report to the SN for forwarding. Figure 3 shows the flow.

Figure 3. Fast MCG link recovery. The SCG becomes the backup signalling path to the MN. T316 limits how long the UE waits before it gives up and does re-establishment.

Step 1: the UE detects MCG RLF. If fast MCG recovery is configured (T316) and the SCG is not deactivated, the UE starts fast recovery instead of re-establishment. It suspends MCG transmissions for all radio bearers except SRB0.
Step 2: the UE sends MCGFailureInformation with the available measurements from both the MN and the SN configurations. With split SRB1, the message goes on its SCG leg. Without split SRB1, it is put in ULInformationTransferMRDC on SRB3.
Steps 3 to 6: the SN passes it to the MN, and the MN answers through the same path. On SRB3 the answer comes back in DLInformationTransferMRDC.
Step 7: on RRCReconfiguration or a mobility command, the UE resumes the MCG transmissions. On RRCRelease, it releases everything.
Not during PSCell addition or change: if the MCG fails while a PSCell addition or change is ongoing, the UE does normal re-establishment.

Following is based on 38.331 v19.4.0 (Release 19)

MCGFailureInformation-r16-IEs ::= SEQUENCE {
    failureReportMCG-r16              FailureReportMCG-r16                             OPTIONAL,
    lateNonCriticalExtension          OCTET STRING                                     OPTIONAL,
    nonCriticalExtension              SEQUENCE {}                                      OPTIONAL
}

FailureReportMCG-r16 ::=          SEQUENCE {
    failureType-r16                   ENUMERATED {t310-Expiry, randomAccessProblem, rlc-MaxNumRetx,
                                                         t312-Expiry-r16, lbt-Failure-r16, beamFailureRecoveryFailure-r16,
                                         bh-RLF-r16, spare1}                                                                            OPTIONAL,
    measResultFreqList-r16            MeasResultList2NR                                                                     OPTIONAL,
    measResultFreqListEUTRA-r16       MeasResultList2EUTRA                                                                  OPTIONAL,
    measResultSCG-r16                 OCTET STRING (CONTAINING MeasResultSCG-Failure)                                       OPTIONAL,
    measResultSCG-EUTRA-r16           OCTET STRING                                                                          OPTIONAL,
    measResultFreqListUTRA-FDD-r16    MeasResultList2UTRA                                                                   OPTIONAL,
    ...
}

T316-r16 ::=         ENUMERATED {ms50, ms100, ms200, ms300, ms400, ms500, ms600, ms1000, ms1500, ms2000}

t316-r16: configured in RRCReconfiguration-v1610-IEs, from 50 ms to 2000 ms. It can be configured only if the UE has split SRB1 or SRB3. Configuring T316 is what enables fast MCG recovery.
failureType-r16: the MCG RLF cause, the same set of causes as the SCG failure report.
measResultFreqList / measResultSCG: measurements from the MN configuration and from the SN configuration. The MN uses them to choose a handover target, so they are the most important part of the message.

How long should T316 be ? It is a trade-off. A short T316 makes the UE fall back quickly when the MN cannot answer. A long T316 gives the MN time to prepare a handover through X2 or Xn. When fast recovery itself fails, Release 18 lets the UE report it in the RLF report with mcg-RecoveryFailureCause-r18 and elapsedTimeT316-r18, as described in the RLF Report part of the SON page.

SCell Dormancy - Release 16

The next problem is the battery. A DC UE often has many SCells, in the MCG and in the SCG. Each active SCell costs power for PDCCH monitoring, even when there is no data. The old way to save this power was to deactivate the SCell with a MAC CE. But a deactivated SCell takes a long time to come back, because the UE has to resynchronize, measure CSI and set up the beam again. So the network has to choose between power and delay.

Release 16 adds a state in between, the dormant BWP. The SCell stays activated, but its active BWP switches to a special BWP where the UE does not monitor PDCCH and does not transmit SRS, PUSCH or PUCCH. The UE still does CSI measurement, AGC and beam management on it. So when the network switches it back to a normal BWP, the SCell can be used almost at once. This is a CA feature, so it works for SCells of the MCG and of the SCG. The SpCells (PCell, PSCell) and a PUCCH SCell cannot have a dormant BWP.

Following is based on 38.331 v19.4.0 (Release 19)

DormantBWP-Config-r16::=               SEQUENCE {
    dormantBWP-Id-r16                      BWP-Id                                                           OPTIONAL,   -- Need M
    withinActiveTimeConfig-r16             SetupRelease { WithinActiveTimeConfig-r16 }                      OPTIONAL,   -- Need M
    outsideActiveTimeConfig-r16            SetupRelease { OutsideActiveTimeConfig-r16 }                     OPTIONAL    -- Need M
}

WithinActiveTimeConfig-r16 ::=         SEQUENCE {
   firstWithinActiveTimeBWP-Id-r16         BWP-Id                                                           OPTIONAL,   -- Need M
   dormancyGroupWithinActiveTime-r16       DormancyGroupID-r16                                              OPTIONAL    -- Need R
}

OutsideActiveTimeConfig-r16 ::=        SEQUENCE {
   firstOutsideActiveTimeBWP-Id-r16        BWP-Id                                                           OPTIONAL,   -- Need M
   dormancyGroupOutsideActiveTime-r16      DormancyGroupID-r16                                              OPTIONAL    -- Need R
}

DormancyGroupID-r16 ::=         INTEGER (0..4)

dormantBWP-Id-r16: which DL BWP of this SCell is the dormant one. It must be different from the default BWP.
firstWithinActiveTimeBWP-Id / firstOutsideActiveTimeBWP-Id: the BWP to go to when a DCI says "leave dormancy", one for each of the two DCI paths below.
DormancyGroupID-r16: 0 to 4. SCells are put into up to 5 groups, and the DCI has one bit per group, not one bit per SCell.

Then which DCI controls it ? There are two paths, and the names in the ASN.1 point to them. Within DRX active time, the UE is already monitoring PDCCH of the SpCell. So the SCell dormancy indication field of DCI format 0_1 or 1_1 carries a 1 to 5 bit bitmap, one bit per dormancy group. DCI 1_1 also has a special form with no PDSCH scheduled, where the fields are reused to indicate dormancy per SCell. Outside active time, the UE is sleeping, so the indication comes in DCI format 2_6, the power saving signal (DCP) that the UE checks before the DRX on duration. More about DCP is in the WUS / DCP and Power Saving pages.

Early Measurement in IDLE and INACTIVE - Release 16

DC and CA have a setup delay problem. After the UE connects, the network does not know which other carriers are good for this UE. So it configures measurements, waits for a report, and only then adds an SCell or an SN. This can take hundreds of milliseconds, and for short data bursts the burst may be over before DC is ready. Then you may ask, why not measure before connecting ? This is early measurement, also called idle/inactive measurement.

The UE measures the configured NR and E-UTRA carriers while it is in RRC_IDLE or RRC_INACTIVE, keeps the results, and reports them right after it connects. The network can then set up CA or DC in the first RRCReconfiguration. The measurement configuration comes from two places: dedicated in RRCRelease (measIdleConfig-r16) or broadcast in SIB11. The duration is limited by timer T331, which starts with measIdleDuration when the UE gets the configuration in RRCRelease.

Following is based on 38.331 v19.4.0 (Release 19)

MeasIdleConfigDedicated-r16 ::= SEQUENCE {
    measIdleCarrierListNR-r16       SEQUENCE (SIZE (1..maxFreqIdle-r16)) OF MeasIdleCarrierNR-r16          OPTIONAL,     -- Need N
    measIdleCarrierListEUTRA-r16    SEQUENCE (SIZE (1..maxFreqIdle-r16)) OF MeasIdleCarrierEUTRA-r16       OPTIONAL,     -- Need N
    measIdleDuration-r16            ENUMERATED{sec10, sec30, sec60, sec120, sec180, sec240, sec300, spare},
    validityAreaList-r16            ValidityAreaList-r16                                                   OPTIONAL,     -- Need N
    ...,
    [[
    measReselectionCarrierListNR-r18     SEQUENCE (SIZE (1..maxFreqIdle-r16)) OF MeasReselectionCarrierNR-r18    OPTIONAL,    -- Need S
    measIdleValidityDuration-r18         MeasurementValidityDuration-r18                                         OPTIONAL,    -- Need S
    measReselectionValidityDuration-r18  MeasurementValidityDuration-r18                                         OPTIONAL     -- Need S
    ]]
}

MeasIdleConfigSIB-r16 ::= SEQUENCE {
    measIdleCarrierListNR-r16       SEQUENCE (SIZE (1..maxFreqIdle-r16)) OF MeasIdleCarrierNR-r16          OPTIONAL,     -- Need S
    measIdleCarrierListEUTRA-r16    SEQUENCE (SIZE (1..maxFreqIdle-r16)) OF MeasIdleCarrierEUTRA-r16       OPTIONAL,     -- Need S
    ...,
    [[
    measIdleCarrierListNR-LessThan5MHz-r18   SEQUENCE (SIZE (1..maxFreqIdle-r16)) OF MeasIdleCarrierNR-r16       OPTIONAL,    -- Cond LessThan5MHz
    measReselectionCarrierListNR-r18     SEQUENCE (SIZE (1..maxFreqIdle-r16)) OF MeasReselectionCarrierNR-r18    OPTIONAL,    -- Need S
    measReselectionCarrierListNR-LessThan5MHz-r18   SEQUENCE (SIZE (1..maxFreqIdle-r16)) OF MeasReselectionCarrierNR-r18  OPTIONAL,    -- Cond LessThan5MHz
    measIdleValidityDuration-r18         MeasurementValidityDuration-r18                                         OPTIONAL,    -- Need S
    measReselectionValidityDuration-r18  MeasurementValidityDuration-r18                                         OPTIONAL     -- Need S
    ]]
}

measIdleCarrierListNR / measIdleCarrierListEUTRA: the carriers to measure. An E-UTRA carrier is measured only if the UE supports NE-DC between the serving carrier and that carrier, so the list is really about DC and CA candidates.
measIdleDuration: the T331 value, from 10 to 300 seconds. When T331 stops, the UE stops measuring but keeps the results it has.
validityAreaList: the cells or frequencies where the configuration is valid. If the UE reselects to a cell outside this area, T331 stops.
measIdleValidityDuration-r18: Release 18 adds a validity time for the results. An old result can be worse than no result, because the network may add a carrier that is no longer good. With validatedMeasurementsReq-r18, the network asks only for results that are still valid.
measReselectionCarrierListNR-r18: Release 18 reselection measurements, retrieved with reselectionMeasurementReq-r18 in UEInformationRequest.

How does the network get the results ? The UE sets idleMeasAvailable-r16 in RRCSetupComplete or RRCResumeComplete. For a resume, the gNB can ask for the results directly in RRCResume with idleModeMeasurementReq-r16, so no extra round trip is needed. Otherwise it uses idleModeMeasurementReq in UEInformationRequest, the same procedure that is described in the MDT page. Release 16 also allows a UE to resume with MR-DC: the SCG configuration stored in RRC_INACTIVE can be restored (restoreSCG-r16) instead of being built again. With early measurement and resume together, a UE can come back from RRC_INACTIVE almost directly into DC.

SCG Deactivation - Release 17

SCell dormancy saves power on SCells, but the PSCell still runs. A UE in DC that has no data for the SCG still monitors PDCCH on the PSCell, does RLM, sends CSI and so on. The only way to stop this in Release 16 was to release the SCG. Then the next data burst needs a full SN addition again, with all the X2 or Xn signalling and the random access. Release 17 adds SCG deactivation, which keeps the SCG configured but mostly silent.

While the SCG is deactivated, there is no transmission on SCG RLC bearers. The UE does not transmit PUSCH, SRS or CSI on the SCG, and it is not required to monitor PDCCH or receive DL-SCH there. All SCells of the SCG are deactivated too. But the UE still performs RRM measurements configured by the MN and the SN. Only the NR SCG can be deactivated, so it applies to EN-DC, NGEN-DC and NR-DC, not to NE-DC.

Following is based on 38.331 v19.4.0 (Release 19)

RRCReconfiguration-v1700-IEs ::=        SEQUENCE {
    otherConfig-v1700                       OtherConfig-v1700                                              OPTIONAL, -- Need M
    ...                                     -- fields not related to SCG deactivation are not shown
    scg-State-r17                           ENUMERATED { deactivated }                                     OPTIONAL, -- Need S
    appLayerMeasConfig-r17                  AppLayerMeasConfig-r17                                         OPTIONAL, -- Need M
    ue-TxTEG-RequestUL-TDOA-Config-r17      SetupRelease {UE-TxTEG-RequestUL-TDOA-Config-r17}              OPTIONAL, -- Need M
    nonCriticalExtension                    RRCReconfiguration-v1800-IEs                                   OPTIONAL
}

DeactivatedSCG-Config-r17 ::=       SEQUENCE {
    bfd-and-RLM-r17                     BOOLEAN,
    ...
}

scg-State-r17: present with deactivated means the SCG is deactivated. Absent means activated (Need S). This is an MN field. The MN can set it at PSCell addition, PSCell change, RRC resume or handover. When the SCG is added as deactivated, the UE does not do random access on the PSCell.
bfd-and-RLM-r17: whether the UE keeps doing RLM and BFD on the PSCell while deactivated. If true, a beam failure on the deactivated SCG is reported as beamFailure-r17 in SCGFailureInformation. If false, RLM stops, and T310 and T312 of the SCG are stopped.
scg-DeactivationPreference: in UEAssistanceInformation, the UE can say it prefers the SCG deactivated, if scg-DeactivationPreferenceConfig-r17 is set up in OtherConfig-v1700.

Who decides to activate the SCG again ? The MN and the SN can request deactivation. The MN, the SN and the UE can request activation. The UE case is UL data. If data arrives for an SCG bearer while the SCG is deactivated, the UE indicates it to the MN with uplinkData in UEAssistanceInformation. Then the network activates the SCG. On activation, the UE does random access on the PSCell only in two cases. One is when it was not doing RLM and BFD. The other is when the lower layers say random access is needed, for example because the timing was lost. Otherwise the UE can start on the PSCell directly, with TCI states that the network can give for that purpose.

One more interaction is important. Fast MCG recovery needs a working SCG. So if the MCG fails while the SCG is deactivated, the UE does not use fast MCG recovery. It goes to re-establishment. This is a good example of how features from different releases have to be checked against each other.

CPC, CPA and Subsequent CPAC - Release 16 to 18

The last area is PSCell mobility. A normal PSCell change has the same weakness as a normal handover: the command arrives when the radio is already bad, and it may not arrive at all. CHO solved this for the PCell by sending the command early, together with an execution condition. CPAC is the same idea for the PSCell. The CHO mechanism itself is explained in the CHO page, and this section only looks at the DC specific part.

CPAC came in three steps over three releases, and each step answered a limit of the previous one. The names are confusing, so here they are in order. Figure 4 compares the classic one-shot behavior with the Release 18 subsequent CPAC.

Release 16, intra-SN CPC: conditional PSCell change within the same SN, without MN involvement. It reuses the CHO structure, ConditionalReconfiguration-r16, sent by the SN.
Release 17, CPA and inter-SN CPC: conditional PSCell addition, and conditional change to another SN, initiated by the MN or the SN. For SN initiated inter-SN CPC, the condition refers to the SCG measurement configuration, so the field condExecutionCondSCG-r17 is added.
Release 18, subsequent CPAC: the configuration is kept after execution, so the UE can do the next PSCell change or addition without a new configuration.

Figure 4. One-shot CPC/CPA against subsequent CPAC. In the old behavior every execution throws away all candidates. In Release 18 the candidates stay, so a UE moving through the same group of PSCells needs no new configuration.

One-shot behavior: after a successful CPC or CPA, the UE releases all stored conditional reconfigurations. So a UE that moves along a street of small FR2 cells needs a new X2 or Xn preparation and a new RRC configuration for every PSCell.
Subsequent CPAC: the UE keeps the configuration and, after an execution, evaluates the conditions for the next execution. The candidate SN generates the conditions for "the next step" when it prepares its candidate SCG.
Reference configuration: each candidate PSCell configuration can be a delta on top of one reference configuration. This keeps the stored configuration small.
sk-Counter list: a change to another SN needs a new S-KgNB. The network gives a list of sk-Counter values per SN, and the UE uses the first unused one. This is how security is renewed without a new message from the network.

Following is based on 38.331 v19.4.0 (Release 19)

ConditionalReconfiguration-r16 ::=   SEQUENCE {
    attemptCondReconfig-r16              ENUMERATED {true}              OPTIONAL,   -- Cond CHO
    condReconfigToRemoveList-r16         CondReconfigToRemoveList-r16   OPTIONAL,   -- Need N
    condReconfigToAddModList-r16         CondReconfigToAddModList-r16   OPTIONAL,   -- Need N
    ...,
    [[
    scpac-ReferenceConfiguration-r18     SetupRelease {ReferenceConfiguration-r18}          OPTIONAL,   -- Need M
    servingSecurityCellSetId-r18         SecurityCellSetId-r18                              OPTIONAL,   -- Need M
    sk-CounterConfiguration-r18          SK-CounterConfiguration-r18                        OPTIONAL    -- Need M
    ]]
}

CondReconfigToAddMod-r16 ::=     SEQUENCE {
    condReconfigId-r16               CondReconfigId-r16,
    condExecutionCond-r16            SEQUENCE (SIZE (1..2)) OF MeasId                      OPTIONAL,    -- Need M
    condRRCReconfig-r16              OCTET STRING (CONTAINING RRCReconfiguration)          OPTIONAL,    -- Cond condReconfigAdd
    ...,
    [[
    condExecutionCondSCG-r17         OCTET STRING (CONTAINING CondReconfigExecCondSCG-r17) OPTIONAL     -- Need M
    ]],
    [[
    condExecutionCondPSCell-r18      SEQUENCE (SIZE (1..2)) OF MeasId                      OPTIONAL,    -- Cond condReconfigCHO-WithSCG
    subsequentCondReconfig-r18       SubsequentCondReconfig-r18                            OPTIONAL,    -- Need M
    securityCellSetId-r18            SecurityCellSetId-r18                                 OPTIONAL,    -- Need M
    scpac-ConfigComplete-r18         ENUMERATED {true}                                     OPTIONAL     -- Cond CPAC
    ]]
}

CondReconfigExecCondSCG-r17 ::=  SEQUENCE (SIZE (1..2)) OF MeasId

SubsequentCondReconfig-r18 ::=   SEQUENCE {
    condExecutionCondToReleaseList-r18   CondExecutionCondToReleaseList-r18                OPTIONAL,   -- Need N
    condExecutionCondToAddModList-r18    CondExecutionCondToAddModList-r18                 OPTIONAL,   -- Need N
    ...
}

condExecutionCond-r16: one or two measIds whose events are the execution condition. For CPC and CPA they refer to the conditional events of the configuration that sent the message. Only one RS type and at most two trigger quantities are allowed per candidate.
condRRCReconfig-r16: the stored RRCReconfiguration to apply on execution. For inter-SN CPC and CPA it may include the MCG part too.
condExecutionCondSCG-r17: the condition for SN initiated inter-SN CPC. The measIds belong to the SCG measurement configuration, because the source SN set them up. This is why it is a separate field from condExecutionCond.
subsequentCondReconfig-r18: the conditions for the following executions of subsequent CPAC. This is what turns a one-shot configuration into a reusable one.
scpac-ReferenceConfiguration-r18 / sk-CounterConfiguration-r18: the reference configuration for the delta candidates, and the sk-Counter values per SN.
condExecutionCondPSCell-r18: used when the stored RRCReconfiguration of a CHO candidate includes an nr-SCG. This is CHO with candidate SCG(s): the UE executes only when both the condition of the candidate PCell and the condition of the associated candidate PSCell are met.

Then what happens on failure ? A CPA, CPC or subsequent CPAC execution failure is one more SCG failure case. The UE sends SCGFailureInformation to the MN, and stops evaluating the CPA or CPC conditions. The MRO side of it, the SPR (Successful PSCell change or addition Report) of Release 18, is described in the SPR part of the SON page.

Reference

3GPP TS 37.340 V19.3.0 : NR; Multi-connectivity; Overall description; Stage-2. Clauses 4, 7.5, 7.6, 7.7, 7.13, 10.2.3, 10.6, 10.19.3, 10.20
3GPP TS 38.331 V19.4.0 : NR; Radio Resource Control (RRC) protocol specification. Clauses 5.3.5.13a, 5.3.5.13b, 5.7.8
3GPP TS 38.300 V19.4.0 : NR; NR and NG-RAN Overall description; Stage-2. Clause 10.6
3GPP TS 38.212 : NR; Multiplexing and channel coding. DCI formats 0_1, 1_1 and 2_6
Interworking with LTE, Split Bearer, CHO, Power Saving, WUS / DCP, SON for NR, LTE Dual Connectivity (ShareTechnote)