Conclusion
The draft running CR has been updated according to the input in section 2. In addition, the following open issues are added; companies are encouraged to address these open issues in their tdoc submissions.
Issue 1: How to define single MAC CE format for both explicit and implicit OD-SSB deactivation
Issue 2: Whether there is a need to capture selection/availability of additional RACH resources for RACH adaptation.
Annex A: R2 agreements affecting TS 38.321
Change is introduced to support the following objectives:
- On-demand SSB for SCell operation
- On-demand SIB1 for idle/inactive UEs
- Adaptation of common channels/signals
The following color code is used to categorize agreements interms of if/how they have been captured. It will be removed when the CR is finalized.
Fully implemented
Already specified in MAC
Not/partially implemented but additional agreements/FFSs needed before conclusion
Doesn’t impact MAC spec
RAN2 Agreements
On-demand SSB for SCell operation
RAN2#127
RAN2 start the discussion from Scenario 2/2A and wait for RAN1 conclusion on Scenario 3A/3B
RRC based OD-SSB transmission indication is used to indicate at least the initial activation/deactivation state of OD-SSB configuration. FFS on reconfiguration.
New MAC-CE for OD-SSB transmission indication is introduced. We will not change legacy SCell activation/deactivation MAC CE. FFS if we need further optimization for scenario 2A.
Measurement based on OD-SSB in both case 1 and case 2 will be considered. (case 1 and case 2 defined in RAN1).
For Case #1, the UE does not expect to measure SSB when on-demand SSB transmission is deactivated. In other words, the UE expects to measure SSB when on-demand SSB transmission is activated.
RAN2 does not handle the issue raised in R2-2407414 in OD-SSB based measurements.
R2-2407414: Proposal 3: RAN2 WG to discuss the issue of false measurement report triggering due to no SSB transmission when on-demand SSB is deactivated.
RAN2 does not handle this issue in OD-SSB
RAN2 study how the UE to perform L3 measurement according to OD-SSB L3 RRM configuration.
RAN2#127bis
No need to restrict the OD-SSB activation/deactivation state indication in RRC to initial configuration. No special specification effort is required.
Don’t introduce further new MAC CE that combines SCell activation/deactivation and OD-SSB indication for scenario 2A.
NW should be able to send OD-SSB indication for multiple SCells simultaneously by a MAC CE.
RAN2#129
RAN2 leave it to RAN4 to conclude whether always-on SSB and/or OD-SSB are measured when both are transmitted in OD-SSB case 2.
RAN2#127
For explicit activation/deactivation, the OD-SSB MAC-CE includes fixed sized bitmap to indicate whether OD-SSB is activated in each SCell (i.e., similar to legacy SCell A/D MAC-CE).
A/D bit: “1” means activation, “0” means deactivation for explicit deactivation case.
For explicit activation/deactivation, the OD-SSB MAC-CE supports two formats: one format indicates up to 7 SCells and the other format indicates up to 31 SCells.
OD-SSB MAC-CE includes a configuration index for each SCell activating OD-SSB.
RAN2 aims to define single MAC CE format for both explicit and implicit OD-SSB deactivations. Details are FFS.
Working assumption: When A-SSB and OD-SSB have different center frequency, introduce a new servingCellMO in ServingCellConfig to indicate MO of OD-SSB. FFS if we allow multiple OD-SSBs with the different frequencies for a given SCell.
On-demand SIB1 for idle/inactive UEs
RAN2#125bis
At least RAN2 starts scenario 1a. Other scenarios are not excluded.
Scenario 1a: Cell A SIB assisted intra-cell WUS. And WUS and SIB1 is sent to/from NES cell. with below potential RAN2 impacts:
Add WUS configuration in SIB of cell A.
Cell reselection from cell A to NES cell, including trigger condition and cell barring changes.
Whether allow camping, paging and SIB update in NES cell.
Cell reselection from NES cell to cell A or normal cell.
Contents of UL WUS
RAN2 assumes that RACH procedure is reused for UE to request on-demand SIB1.
UL WUS configuration includes at least below information:
RACH configuration
A UE needs to know a UL WUS configuration to request SIB1 of which cell.
On-demand SIB1 acquisition procedure
- Existing Msg 1 based on-demand procedure is reused for on-demand SIB1 acquisition procedure. FFS on Msg 3. FFS if / when the UE monitors the OD-SIB1 upon reception of RAR. FFS:T whether introduce specified UE behavior if RACH failure of OD-SIB1 request.
The UE first should acquire valid SIB1 (e.g. via SIB1 request) for camping to NES cell (if the UE knows the cell doesn’t broadcast SIB1 and supports on-demand SIB1).
RAN2#126
Study on-demand SIB1 provisioning for NES Cell(s) in versions of Scenario 1a with multiple Cells A and/or NES Cells:
More than one Cell A may provide configuration for the same NES cell.
The same Cell A may assist more than one NES Cells.
RRC release message assisted intra-cell WUS can be discussed as option of signaling details in stage 3.
Can use the PCI and frequency of a NES Cell to associate the UL WUS configuration with a NES Cell.
For Message 1 based on-demand SIB1 request, the on-demand SI request configuration that currently included in SIB1 may be used as the design baseline.
Cell A’s SIB can be used to configure on-demand SIB1 related configuration for neighbour NES cells, e.g., via new SIB or the existing SIB.
If the UE chooses the NES cell using legacy intra-F/inter-F cell re-selection procedure (as baseline), the UE triggers WUS transmission.
After UE successfully receives OD-SIB1 for that NES Cell and if it is a suitable cell, UE camps in the NES Cell “similar” to a legacy Cell.
RAN2 not to support on-demand SIB1 request that is combined with an initial access to perform RRC connection establishment/resume on the NES cell.
NW need to bar the legacy UE from accessing the on-demand SIB1 cell (e.g. based on the existing barring mechanism).
How to avoid/deprioritize the legacy UE camping at the Cell A attempting to switch to the NES Cell (but allowing the R19 NES UE to do that).
If the NES UE is unable to acquire the SIB1 of NES Cell before UE initiates OD-SIB1 procedure, it will not consider it as barred at that moment. R19 NES UE bars the cell if the UE fails to acquire SIB1 via on-demand SIB1 for NES cell.
After Rel-19 NES UEs camp in NES cell, the UE behaviour is same as the one defined as legacy normal camped state, e.g. paging reception, SIB1 update, etc.
RAN2 assumes the UE is expected to receive the RAR responding to the preamble transmission for Msg1-based on-demand SIB1 procedure, as the baseline.
As baseline, upon random access procedure failure of OD-SIB1 request, UE regards OD-SIB1 can’t be acquired in the NES cell and considers it as barred. It doesn’t exclude the option to leave the determination to the UE implementation.
Once the NES UE camps on the NES cell, if the UE receives SIB change notification, the UE is expected to receive SIB1 from NES cell.
RAN2 to wait for RAN1’s progress whether to support scenario 3.
RAN2#127
No consensus for RAN1 case 3 in RAN2.
We can rely on legacy UE behaviour to ensure UE has valid SIB1 for the cell (i.e. UE reacquire SIB1 whenever (re)selecting cell).
Further UE keeps SIB1 updated while on cell via regular SI modification procedure (confirmation of earlier RAN2 agreement).
Once Rel-19 NES UE camps on the NES cell, the UE expects to receive UL WUS configuration updates from the NES Cell, e.g., via legacy SI modification procedures.
Msg 3 based OD-SI procedure is not supported for on-demand SIB1 request in case 2 (for requesting to the NES Cell).
Following example options to handle legacy UEs (i.e. UEs not supporting OD-SIB1) can be considered in normative work. Details and further analysis need to be further discussed in normative work. Other existing options are not excluded.
Option 1: Legacy UEs bar the OD-SIB1 cell based on cellBarred bit set to barred in MIB.
Option 2: Legacy UEs bar the OD-SIB1 cell based on no SIB1 indication via ssb-SubcarrierOffset in MIB.
Option 3: Network includes cells supporting OD-SIB1 to list of excluded cells.
RAN2 understands the NW can avoid impact on legacy RRC connected UE and R19 RRC connected UE due to on-demand SIB1 (e.g. NES cell with OD-SIB1 is measured by legacy RRC_CONNECTED UE and can be configured as its PSCell/SCells/target cell).
RAN2 conclude that on-demand SIB1 is feasible from RAN2 perspective and recommend normative work of case 2 for on-demand SIB1.
RAN2#127bis
We will inherit all agreements made during SI phase to WI phase.
A NES cell can include neighbouring NES cell’s WUS configuration.
NES cell’s WUS configuration, it is included in a new SIB (including its own WUS configuration).
In on-demand SIB1 procedure, the UE considers RACH failure when PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax + 1.
The MAC layer will indicate the RACH failure for SI request to upper layers. FFS: after that the UE upper layer will consider the cell as barred.
The legacy UE behaviour can be reused upon on-demand SIB1 acquisition failure, i.e., the NES UE should follow the intraFreqReselection in MIB of NES cell.
A cell for which SIB1 request configuration is available, can periodically broadcast SIB1.
If UE has SIB1 request configuration of a cell, UE needs to check if SIB1 is currently being broadcasted or provided on demand for that cell before requesting SIB1 of that cell.
Legacy UEs bar the OD-SIB1 cell based on no SIB1 indication in MIB e.g. via ssb-SubcarrierOffset. Detailed solution is up to RAN1. If this works, no separate barring bit for R19 NES UEs is introduced.
NES UEs should be allowed to reselect to cells that are prevented from legacy UEs (e.g. by excluded cell list, reselection priorities).
RAN2 will not start the discussion on the issue when the UL WUS configuration update in Cell A is not synchronised with the UL WUS configuration update in the NES cell, unless we’re asked to do that by other WG, e.g. RAN3.
RAN2#128
Let’s wait for more RAN1 progress on Kssb discussion.
NES UE with SIB1 request configuration of a NES cell assumes that a NES cell, with SSB containing K_SSB < 24 for FR1 and K_SSB < 12 for FR2, will acquire SIB1 as in legacy.
New NES-specific reselection priority parameters for NES UEs are defined for the purpose of prioritizing/deprioritizing a NES frequency.
Introduce new IntraFreqExcludedCellList-NES / InterFreqExcludedCellList-NES IEs enable proper reselection behaviour of legacy and NES UEs.
Reuse legacy cell reselection criterion as trigger condition of OD-SIB1 acquisition. No need to specify other conditions (e.g. a new RSRP threshold).
The existing 1-second rule in the cell reselection criteria is still applied to the triggering condition of UL WUS transmission.
The UE considers the cell as barred after MAC indicates max number of preamble transmission for the OD-SIB1 request.
If MSG2 (ACK) is received, but UE fails to receive SIB1 then the UE may consider this cell as barred, no spec impact.
A UE bars the NES/SIB1 less cell and/or excludes it as a candidate for reselection since the UE had no corresponding UL WUS configuration, the UE would treat this cell as if cell status is “not barred” and consider it as candidate for cell reselection once it has received a UL-WUS configuration to request SIB1 for this cell.
UE considers WUS configuration only valid in directly succeeding cell reselection from cell where UE acquired WUS configuration. FFS on SI validity area rather than cell level.
Wait one cycle of RAN discussion (i.e. to see whether WID is updated or not to handle RRC connected UEs)
Working assumption: UL-WUS configuration in RRC release is not supported.
RAN2#129
There is no need for additional barring mechanisms (in addition to the k_ssb signaling “no SIB1” indication in MIB) to handle legacy to be able to bar cell using OD-SIB1.
Specify the following UE behavior to allow the UEs in RRC_CONNECTED state to acquire OD-SIB1 when T311 is running:
When T311 is running, the UE can trigger the OD-SIB1 acquisition procedure with stored UL WUS configuration in SIB-X, if it is still valid.
The legacy cell selection criteria are reused as the trigger condition of OD-SIB1 acquisition.
The OD-SIB1 acquisition behavior is same as that of RRC_IDLE/IANCTIV UEs.
The UE follows the legacy validity principle of stored SIB.
For Rel-19 NES UE in RRC_CONNECTED, rely on the NW dedicated RRC for SIB1 delivery if searchSpaceSIB1 is not configured. It is legacy UE behavior and no spec change is expected.
SIB-x can be cell specific or area specific, as legacy.
Upon reception of RAR, the UE monitors OD-SIB1 in the window agreed by RAN1.
RAN2#129bis
Capture the following understanding in meeting notes: RA on an SpCell can include a cell on which the UE is requesting OD-SIB1. No specification changes needed.
Reuse legacy SSB selection procedure in MAC spec for RA initiated for SIB1 request, i.e. the UE selects any SSB if no SSB is above the configured RSRP threshold. This can be revisited if RAN1 agrees otherwise.
NW ensures that the RRC connected UE has the latest SIB1 (e.g. dedicated RRC message to deliver SIB1 or not configure searchSpaceSIB1), as baseline. UE understands that the stored SIB1 is the latest SIB1.
When the cell supporting on demand SIB1 is broadcasting SIB1 (e.g. upon SIB1 request), legacy UE can camp on the cell if the legacy UE is able to acquire the broadcasted SIB1. No specification impact is foreseen.
Confirm the working assumption that “UL-WUS configuration in RRC release is not supported”.
SIBX that was acquired during RRC connected state can be used for OD-SIB1 request in RLF.
Align with legacy RAR for OSI for OD-SIB1 operation. Legacy RAR MAC PDU subheader with RAPID only to be used as NW acknowledgement for OD-SIB1 request.
The UL WUS configuration includes the IE totalNumberOfRA-Preambles.
Backoff is not applied to OD-SIB1 request when backoff is included in RAR.
Leave this issue (how to handle paging interruption during OD-SIB1 acquisition) to RAN4.
If UE has not received the PDCCH scheduling SIB1 upon the expiry of the SIB1 monitoring window, UE may consider the cell as being barred.
WUS configuration can be associated with a list of cells if the whole WUS configuration is same.
Area id will be used as legacy.
We do not need a separate new triggering condition of OD-SIB1 acquisition.
When timer T311 is running, SIB1 acquisition triggering condition is same as legacy. No additional spec impact is foreseen.
Adaptation of common channels/signals
RAN2#125bis
From the UE point of view, UE will monitor one PEI/PO every paging DRX cycle, i.e. the UE doesn’t skip PO in paging DRX cycle.
For adaptation of paging occasions in time domain, RAN2 to study a) bundle paging frames and b) extend the values of N to have increased interval between PFs (e.g. T/64, T/128 ...) and compensating decrease in number of PFs by increasing POs per PF.
For Paging adaptation, R2 discusses the following options on compatibility of legacy RRC_IDLE/RRC_INACTIVE UE:
Option 1: Prevent the access of legacy UE via barring;
Option 2: Separate paging resources for legacy UEs and Rel-19 NES UEs (assuming there are legacy UEs)
RAN2#127
Option-a) is about the bundling of PF for R19 NES UEs.
R2 observe that the option-a) and option-b) can be designed to configure the PO:s at same time position.
RAN2#127bis
Select option-b as baseline for R19 NES paging enhancement.
R2 should aim at signaling overhead minimization (e.g., Ns=8 and FFS for other larger values)
Allowing legacy and R19 UEs to co-ex in the same PF/PO is possible, based on NW configuration.
Legacy UE is not barred.
Rel-19 UEs only monitor the PO(s) according to Rel-19 paging configuration.
RAN2#128
Introduce value for Ns=8. FFS on 16.
Introduce value for N= T/32. FFS on T/64, T/128, T/256.
RAN2#129
For N, values smaller than T/32 are not supported.
The maximum possible value for Ns is 8.
Introduce a separate PEI configuration.
Paging adaptations are configured semi-statically and updated via system information update notification.
A new UE capability is added for R19 NES paging enhancement, and the new capability is included in UE-RadioPagingInfo. FFS on whether we have a common capability for all NES features.
RAN2 confirms SSB adaptation in time domain is not supported for RRC idle/inactive UEs and Rel-19 NES-capable UE’s PCell.
RAN2 preference is to keep SMTC based L3 RRM framework and to introduce additional SMTC configuration according to SSB adaptation for L3 RRM measurement on SCell with SSB adaptation.
For L3 measurement, RAN2 assumes the adapted SSB on neighbor cell is measured based on legacy SMTC.
Legacy UEs and UEs non-capable of time domain PRACH adaptation are expected to use legacy PRACH resources per legacy configuration and procedures. No barring is needed.
RAN2 starts CBRA for RACH adaptation.
RAN2 starts 4-step RACH adaptation.
From R2 perspective, not apply time-domain RACH adaptation to RACH resources for MSG1-based SI request.
From R2 perspective, not apply time-domain RACH adaptation to IAB RACH resources.
From R2 perspective, RACH adaptation is not modelled as RA feature(s).
From R2 perspective, RACH partitioning with all the features, i.e. RedCap, SDT, and Slicing, and feature combinations, are supported for PRACH adaption in time domain.
Will follow legacy mechanism regarding how to select RACH resource.
RAN2#129bis
For the case when both pei-Config-r17 and pagingAdaptationPEI-Config-r19 are configured, R19 UE supporting paging adaption should monitor PEI according to pagingAdaptationPEI-Config-r19 while other UE should monitor PEI according to pei-Config-r17.
For the case when pei-Config-r17 is configured and pagingAdaptationPEI-Config-r19 is absent, both R19 UE supporting paging adaption and other UE should monitor PEI according to pei-Config-r17.
Paging clustering/bundling/adaptation is not supported/applied in RRC_CONNECTED.
Not support MAC CE based signalling to indicate SSB adaptation in addition to DCI agreed in RAN1.
For SSB adaptation, multiple additional SMTC configurations are configured to UE via RRC, together with the mapping between SSB burst periodicity and SMTC configuration.
Upon reception of DCI format 2_9 for SSB burst periodicity switching, UE selects one SMTC configuration accordingly.
Relevant R1 Agreements:
On-demand SSB for SCell operation
RAN1#119
For a cell supporting on-demand SSB SCell operation, support at least the following options to deactivate on-demand SSB transmission from a UE perspective.
Option 1: Explicit indication of deactivation for on-demand SSB via MAC-CE for on-demand SSB transmission indication
Deactivation by RRC is up to RAN2
FFS: Which scenario Option 1 is used
Option 2: Configuration/indication of the number N of on-demand SSB bursts to be transmitted after on-demand SSB is indicated
FFS: Whether Option 4, 4a is needed in addition to Option 2
FFS: Whether the value of N can be implicitly determined using a timer
RAN1#118
For a cell supporting on-demand SSB SCell operation,
Support RRC based signaling to indicate on-demand SSB transmission on the cell at least for the case where this RRC also configures the SCell, activates the SCell, and provides on-demand SSB configuration.
FFS: Whether to support RRC based signaling for other cases.
Support MAC CE based signaling to indicate on-demand SSB transmission on the cell for Scenarios #2 and #2A.
For a cell supporting on-demand SSB SCell operation, at least for the following parameter(s), multiple candidate values can be configured by RRC and the applicable value can be indicated by MAC CE for on-demand SSB transmission indication for the cell.
Periodicity of the on-demand SSB
FFS: Any other relevant parameters
RAN1#120bis
For a cell supporting on-demand SSB SCell operation, at least for the following parameter(s) (in addition to agreed ones), multiple candidate values can be configured (includes the case where no candidate values are configured) by RRC and the applicable value can be indicated by MAC CE for on-demand SSB transmission indication for the cell.
SSB positions within an on-demand SSB burst by using signaling similar to ssb-PositionsInBurst (i.e., od-ssb-PositionsInBurst) for the following cases
The case where center frequency of AO-SSB and OD-SSB are different
Case 1
Number N of on-demand SSB bursts to be transmitted after on-demand SSB is indicated (i.e., od-ssb- nrofBurst)
On-demand SIB1
RAN1#119
At least the contents of RAR in response to SI request are included in RAR in response to UL WUS
There is no RAN1 consensus to support UL WUS repetition in R19.
The mapping rule between ra-PreambleStartIndex for OD-SIB1 and SSB follows the mapping rule between ra-PreambleStartIndex for OSI request and SSB as in legacy specification.
RAN1#118bis
No further optimization in RAN1 on power control and power ramp-up procedure for UL WUS in R19.
For the purpose of “WUS transmission”, at least the following parameters are included in the UL-WUS configuration:
rsrp-ThresholdSSB
prach-RootSequenceIndex
msg1-SubcarrierSpacing
restrictedSetConfig
Note: In legacy spec, the parameters above are under the IE RACH-ConfigCommon
It is up to gNB to configure whether RACH occasions for UL WUS are shared or separated from the RACH occasions for other usages.
RAN1#117
For further study of on-demand SIB1 in idle/inactive mode, on the spatial relationships among PDCCH/PDSCH of on-demand SIB1, SSB, and UL WUS, as UL WUS is using dedicated PRACH resource, it is assumed that spatial relationships among PDCCH/PDSCH of on-demand SIB1, SSB and UL WUS can follow legacy mechanism.
Adaptation of common signals and channels
RAN1#120
For adaptation of PRACH in time-domain, for determining the additional PRACH resources in time-domain,
When an additional RO is overlapped with legacy valid RO in both time and frequency domain, the additional RO is invalid before the SSB-RO mapping
Note: the overlapped RO for legacy resource is not impacted
FFS: Clarification on configuration of legacy ROs
For adaption of PRACH in time-domain, for a connected mode UE, support a 1-bit field in DCI 1_0 with C-RNTI used to trigger PRACH (i.e. PDCCH order) to indicate whether the additional PRACH resource(s) is available for the triggered PRACH.
FFS: UE behaviour (e.g. applicable resources for PRACH mask index) when it is indicated of additional PRACH resource(s)
FFS: Details on how to reuse existing bit for the 1-bit indication
For DCI-based adaptation for additional PRACH resources, DCI 1_0 with P-RNTI indicates the availability information for additional PRACH resource from a reference point and for a validity time duration
FFS: Validity time duration for availability is configured by higher layer signaling or predefined
FFS: Location of the reference point defined in the specification
FFS: Value/granularity of the validity time duration.
FFS: Whether DCI can be used to explicitly deactivate the additional PRACH resources
RAN1#119
At least msg1-FrequencyStart can be configured separately for the additional PRACH resources at least for 4-step RACH.
For DCI-based adaptation for additional PRACH resources, select only from the following alternatives:
Alt 1: (PRACH resource configuration level) DCI-based adaptation to indicate whether the additional PRACH resources provided by semi-static signalling are available or not
FFS: details
Alt 2: (subset of PRACH resource level) DCI-based adaptation to indicate whether a subset of the additional PRACH resources provided by semi-static signalling are available or not
FFS: Maximum number of subsets of the additional PRACH resources= [2 or 3 or 4 or 16]
FFS: whether the subset of the additional PRACH resources is in
Alt 2-1: RO level per SSB
Alt 2-2: SSB-to-RO mapping cycle level
Alt 2-3: PRACH association period level
Alt 2-4: PRACH association pattern period level
Alt 2-5: SFN level
Alt 2-6: Network configured time period
RAN1#118bis
For adaptation of PRACH in time-domain, support both of the following
Alt 1: The PRACH configuration index for the additional PRACH resources is same as the PRACH configuration index for the legacy resources
Alt 2: The PRACH configuration index for the additional PRACH resources is different from the PRACH configuration index for the legacy resources
FFS: Additional details
RAN1#118
Extend the RAN1#117 agreement on SSB-RO mapping rule for additional PRACH resources to Case 1
Case 1: no time-domain overlap between the additional PRACH resources for NES-capable UEs and the PRACH resources for legacy UEs
RAN1#117 Agreement
At least for the case where legacy ROs and additional ROs overlap in neither time nor frequency domain, for adaptation of PRACH in time-domain, the SSB-RO mapping rule for additional PRACH resources follows the legacy SSB-RO mapping rule.
Mapping SS/PBCH block indexes to valid additional PRACH occasions provided by semi-static signalling follows the legacy mapping order for preamble/time resource/frequency/PRACH slot indexes.
Note: This mapping is not impacted by time domain PRACH adaptation
Validation rules for the additional PRACH resources follow the legacy validation rules for PRACH resources configured for legacy UEs.
For SSB-RO mapping rule for additional PRACH resources for Case 2.
Extend the RAN1#117 and RAN1#118 agreements on SSB-RO mapping
RAN1#116bis
For adaptation of PRACH in time-domain, support at least the following:
Adaptation based on additional PRACH resources for NES-capable UEs in addition to PRACH resources for legacy UEs (if any)
Note: NES-capable UEs can use both additional PRACH resources and PRACH resources for legacy UEs
Configuration of additional PRACH resources is provided by semi-static signalling
FFS: details including whether there is overlap of additional PRACH resources and PRACH resources for legacy UEs
FFS: adaptation mechanism for additional PRACH resources
Note: No change to the existing PRACH configuration tables in 38.211
Support adaptation mechanisms of PRACH in time-domain for following:
UE in idle/inactive mode
UE in connected mode
|