3GPP TSG-RAN WG2 Meeting #100
`Reno, US, 27th Nov – 1st Dec 2017
`
`R2-1714208
`
`Agenda Item:
`
`10.4.1.3.1
`
`Source:
`
`Ericsson
`
`Title:
`(Ericsson)
`
`OFFLINE#22 LTE re-establishment and resume while using NR PDCP
`
`Document for: Discussion, Decision
`
`1 Introduction
`The issue of LTE re-establishment in case NR PDCP was configured for some bearers (either in EN-DC or
`standalone LTE) was discussed, and the outcome was:
`
`-
`-
`-
`
`R2-1713388 LTE re-establishment when using NR PDCP (TP to 36.331 and
`38.331) Ericsson
`discussion Rel-15 NR_newRAT-Core
`-
`Lenovo think this reduces the chances to successfully re-establishment. Ericsson think in
`this case it would result in extra reconfiguration when the cell does support NR PDCP.
`IDC think the common case is reestablishment to a cell that does support NR PDCP.
`Intel wonder why reject is needed and full configuration is not used.
`HTC think that full configuration is not possible in the re-establishment , it can only be
`done in the first reconfiguration.
`OPPO think this proposal has some benefit when the cell supports EN-DC.
`-
`=> Offline discussion to progress the SRB1 issue to ensure that the mechasism works when
`the UE attempts to re-establish on an eNB that supports EN-DC, and when the UE
`attempts to re-establish on a a legacy eNB that has the context but can not understand the
`full context. (Offline discussion #22, Ericsson)
`
`
`
`Agreements
`1 For re-establishement in LTE, UE releases the lower layer SCG configuration (i.e. nr-
`secondaryCellGroupConfig) at RRC re-establishment while the DRB configuration (incl.
`the NR PDCP configuration received in radioBearerConfig) is kept.
`
`The issue of NR PDCP version preservation during LTE suspend/resume was also discussed:
`R2-1713399 Discussion and TP on preserving NR PDCP version
`Ericsson
`discussion Rel-15
`NR_newRAT-Core
`- OPPO think this should be discussed together with re-establishment. Samsung have the
`same view.
`Ericsson think this case is different as an additional reconfiguration is not always needed
`but if we change to LTE PDCP then an extra reconfiguration step will be needed
`Intel think this case has the same issue with legacy eNBs as the re-establishment.
`LG think this requires that all cells in the resume area will have to support NE-DC and NR
`PDCP.
`=> Can be discussed within the scope of offline discussion #22
`
`-
`-
`
`-
`
`The purpose of this offline is:
` discuss the different ways of performing re-establishment in cases where NR PDCP was used for
`SRB1, and to agree on a solution that works for both re-establishment in EN-DC capable as well
`legacy eNBs.
` discuss the different ways of performing the resume operation in cases where NR PDCP was used
`for SRB1 and/or any other radio bearers
`
`1/12
`
`APPLE 1004
`
`

`

` 2
`
` Problem description
`2.1 LTE re-establishment procedure
`The purpose of the LTE re-establishment procedure is to re-establish the RRC connection upon detecting
`radio link failure, handover failure, mobility from E-UTRA failure, integrity check failure on SRBs or RRC
`connection reconfiguration failure. Re-establishment involves the resumption of SRB1, the re-activation of
`security and the configuration of only the PCell (i.e. CA or DC operations are not re-established)
`When the target eNB get a re-establishment request, it identifies the source eNB/cell from the ReestabUE-
`Identity included in the request, and can send an RLF Indication X2 message to the source eNB. The source
`eNB may respond with a Handover Request message that includes the UE context (RRC context and S1
`context). If the target eNB is able to understand the UE context, re-establishment succeeds and the target
`sends an RRCConnectionReestablishment message to the UE. If the target does not receive the UE context
`or it doesn’t understand the context, it may reject the re-establishment and the UE has to go to RRC_IDLE to
`re-connect. If the target doesn’t understand the RRC context but can understand the S1 context, it doesn’t
`necessarily should reject the re-establishment and can use still respond with
`RRCConnectionReestablishment and later use full reconfiguration to reconfigure the bearers based on the
`S1 context.
`
`In case of re-establishment success, SRB1 operation resumes while the operation of other radio bearers
`(SRB2 and DRBs) remains suspended. If AS security has not been activated, the UE does not initiate the
`procedure but instead moves to RRC_IDLE directly.
`E-UTRAN applies the re-establishment procedure as follows:
`- When AS security has been activated:
`-
`to reconfigure SRB1 and to resume data transfer only for this RB;
`
`to re-activate AS security without changing algorithms.
`-
`After this, the UE sends the RRCConnectionReestablishmentComplete message, and the target eNB
`responds by sending an RRCConnectionReconfiguration message to reconfigure SRB2 and the DRBs.
`The RRC connection re-establishment procedure flow is shown in Figures 1 (success case) and Figure 2
`(failure case). SRB0 is used for sending the RRCConnectionReestablishmentRequest,
`RRCConnectionReestablishment and RRCConnectionReestablishementReject messages, while
`RRCConnectionReestablishmentComplete uses SRB1.
`
`
`UE
`
`
`
`EUTRAN
`
`RRCConnectionReestablishmentRequest
`
`RRCConnectionReestablishment
`
`RRCConnectionReestablishmentComplete
`
`Figure 1: RRC connection re-establishment, successful
`
`
`
`
`
`2/12
`
`
`
`

`

`UE
`
`
`
`EUTRAN
`
`RRCConnectionReestablishmentRequest
`
`RRCConnectionReestablishmentReject
`
`
`
`Figure 2: RRC connection re-establishment, failure
`2.2 LTE Suspend/Resume procedure
`The RRC suspend/resume functionality has been introduced in LTE rel-13. A suspended UE can be
`considered to be in an intermediate state between IDLE and CONNECTED, where the UE AS context is
`kept both at the UE and RAN, and the UE can be seen as if it is in connected mode but suspended from
`the CN point of view and in IDLE mode from the RAN point of view. The advantage of operating in this
`mode is reduced signaling and faster transition to CONNECTED mode as compared to legacy IDLE-
`CONNECTED mode transitions, while maintaining the UE power saving advantages of IDLE mode.
`
`When a decision is made by the network to move the UE to suspended state, the eNB sends the UE an
`RRCConnectionRelease message with the release cause value of rrc-suspend and it is also provided with
`a Resume ID. The UE stores the ID and UE AS context (including the current RRC configuration, the
`current security context, the PDCP state including ROHC state, C-RNTI used in the source PCell, the
`cellIdentity and the physical cell identity of the source PCell;); re-establishes all RLC entities (both for
`SRBs and DRBs); and suspends all DRBs and SRBs expect SRB0.
`
`When the UE later on wants to resume the connection (in response to an UL data to be sent or a paging
`request for DL data), it sends an RRCConnectionResumeRequest message with the saved Resume ID. If
`the resume operation is performed in an eNB other than the eNB that was serving the UE when the UE
`was suspended, the new eNB can perform a context fetch by using the Retrieve UE Context X2 procedure
`from the old eNB (as the Resume ID includes information about the old eNB/cell). Upon getting the context
`(if resuming on a new eNB) or if the resumption was in the same eNB, the target eNB responds with an
`RRCConnectionResume message, and both the UE and eNB restore the saved UE context, and data
`transmission/reception from/to the UE can be resumed.
`The RRC connection resume procedure flow is shown in Figures 3 (success case), Figure 4 (fallback to RRC
`connection establishment) and Figure 5 (network reject or release) show the resume procedure in LTE.
`SRB0 is used for sending the RRCConnectionResumeRequest, RRCConnectionSetup and
`RRCConnectionReestablishementReject, while RRCConnectionResume and RRCConnectionResume
`Complete messages use SRB1.
`
`UE
`
`
`
`EUTRAN
`
` RRCConnectionResumeRequest
`
`RRCConnectionResume
`
`RRCConnectionResumeComplete
`
`
`
`Figure 3: RRC connection resume, successful
`
`
`
`3/12
`
`
`
`

`

`UE
`
`
`
`EUTRAN
`
`RRCConnectionResumeRequest
`
`RRCConnectionSetup
`
`
`Figure 4: RRC connection resume fallback to RRC connection establishment, successful
`
`RRCConnectionSetupComplete
`
`UE
`
`
`
`
`
`EUTRAN
`
`RRCConnectionResumeRequest
`
`RRCConnectionReject
`
`
`
`Figure 5: RRC connection resume, network reject or release
`
`The main difference between resume and re-establishment are (from procedural perspective):
` SRB1 is used for the RRCConnectionResume message, while SRB0 is used for the
`RRCConnectionReestablishment message
` The RRCConnectionResume message, unlike the RRCConnectionReestablishement message, can
`contain the SRB2/DRB configuration, and thus RRCConnectionReconfiguration is not needed after
`resume (while it is necessary in the re-establishment case to reconfigure SRB2/DRBs)
`
`2.3 Re-establishment in case NR PDCP was used
`If the source eNB is EN-DC capable, it is possible that SRB1 (and other RBs) was configured with NR PDCP
`(even if the UE was not in EN-DC). This may cause problems if the target eNB is a legacy eNB. The table
`below illustrates the problem.
`
`Table 1: Different cases of PDCP version usage for SRB1 and support of NR PDCP at the source and
`target eNBs
`
`
`
`
`
`
`
`
`
`uses
`SRB1
`LTE PDCP
`SRB1
`uses
`
`
`
`Source eNB =
`legacy
`Target eNB =
`legacy
`A
`
`Source eNB =
`legacy
`Target eNB = NR
`capable
`B
`
`Source eNB
`= NR capable
`Target eNB =
`legacy
`C
`
`Source eNB
`= NR capable
`Target eNB =
`NR capable
`D
`
`Not applicable Not applicable
`
`E
`
`F
`
`4/12
`
`
`
`

`

`NR PDCP
`
`For cases A to D, there will be no issue because LTE PDCP is used for SRB1, and both source and target
`eNBs understand that. Case F is also OK because both source and target are EN-DC capable.
`In Case E, if the UE resumes with re-establishing SRB1 with NR PDCP, then RRC communication with the
`the target will not be possible (even the RRCConnectionReestablishmentComplete message can’t be
`received at the target eNB). The target eNB’s behaviour is also not clear upon getting a UE context that it
`(partially) doesn’t understand.
`
`2.4 Resume in case NR PDCP was used
`The different cases of table 1 are still relevant in the resume case. But there are two major differences to
`consider:
`- SRB1 is used for the Resume message, so if both the UE and the target eNB use the same PDCP
`version, even the Resume message may not be understood by the UE.
`- No RRCConnectionReconfiguration after resume is required (i.e. Resume message contains radio
`resource configuration)
`
` 3
`
` Possible solutions
`3.1 Re-establishment
`During the online discussion and offline discussion with some companies afterwards, several ways of solving
`the problem were identified:
`Solution 1: UE always falls back to using LTE PDCP on re-establishment
` If target eNB doesn’t support EN-DC, and it doesn’t understand the RRC Context, it will use the S1
`context to do full reconfiguration of the bearers
` If target eNB supports EN-DC, the target will first setup SRB1 with LTE PDCP, and can use the
`RRCConnectionReconfiguration message to revert the PDCP of SRB1 back to NR.
`Solution 2: target eNB supporting EN-DC includes a flag in RRCConnectionReestablishment that
`indicates that it can support EN-DC
` If UE gets such an indication, it uses the same PDCP version that it was using before failure
` If UE doesn’t get such an indication, UE falls back to using LTE PDCP
`Solution 3: UE re-establishes using the same PDCP version that it was using before failure
` If target eNB doesn’t support EN-DC, and it doesn’t understand the RRC context, it will reject the re-
`establishment; or
` If source eNB knows that the target eNB doesn’t support EN-DC, it will not forward the UE context to
`the target (i.e. it will not respond with Handover Request upon getting RLF indication), forcing the
`target eNB to reject the re-establishment.
`Solution 4: UE determines which PDCP is used for re-establishment procedure using “nr-Indication”
`in SIB.
`Solution4a: UE determines which PDCP is used for re-establishment procedure using one new
`indication (eNB support NR PDCP) in SIB2/3.
`
`Solution 5: The SRB1 is reverted to LTE PDCP upon initiation of re-establishment
`
`
`
`5/12
`
`
`
`

`

` If target eNB does not have the UE AS context or receive the UE AS context but does not support full
`configuration for handling different eNB release, it will always reject the RRC Connection Re-
`establishment request.
` If target eNB does not support EN-DC and receive the UE AS context but support full configuration for
`handling different eNB release, it will respond with RRC Connection Re-establishment (with SRB1
`revert to LTE PDCP) and then perform Full configuration in the first RRC Connection
`Reconfiguration message
` If target eNB supports EN-DC and receive the UE AS context, it will respond with RRC Connection
`Re-establishment including the RadioBearerConfiguration containing the SRB1 NR PDCP
`configuration. Upon receiving this, the UE change the PDCP version of SRB1 from LTE PDCP to NR
`PDCP.
`3.2 Resume
`
`
`3.2.1 SRB1 aspects
`
`
`Solution 1: UE always falls back to using LTE PDCP on SRB1 during resume
` If target eNB doesn’t support EN-DC, and it doesn’t understand the RRC Context, it needs to send an
`extra RRCConnectionReconfiguration after the resume to do full reconfiguration of the bearers
`based on the S1 context
` If target eNB supports EN-DC, the target will first setup SRB1 with LTE PDCP, and can use the
`Resume message to revert the PDCP of SRB1 back to NR.
`Solution 2: UE re-establishes using the same PDCP version that it was using before suspension
` If target eNB doesn’t support EN-DC, and it doesn’t understand the RRC context, it will respond with
`RRCConnectionSetup, and send an RRCConnectionReconfiguration after the connection setup to
`do full reconfiguration of the bearers based on the S1 context ; or
` If source eNB knows that the target eNB doesn’t support EN-DC, it will not forward the UE context to
`the target (i.e. it will respond with Retrieve UE Context Failure), forcing the target eNB to reject the
`resume or use RRCConnectionSetup (but this time, since no S1 UE context is available, we will
`need NAS recovery to re-setup the bearers)
`Solution 3: UE determines which PDCP is used for resume procedure using “nr-Indication” in SIB.
` Solution3a: UE determines which PDCP is used for resume procedure using one new
`indication (eNB support NR PDCP) in SIB2/3.
`
`Solution 4: The SRB1 is reverted to LTE PDCP upon initiation of resumption
` If target eNB cannot retrieve the UE context or does not comprehend it and does not perform full
`configuration, it will always reject the RRC Connection Resume request.
` If target eNB can retrieve the UE context but does not comprehend it (i.e. not supporting EN-DC) and
`support full configuration, it will perform RRC Resume with Full configuration over SRB1 with LTE
`PDCP. With the full configuration, the SRB1/2 and DRB can all be switched to LTE PDCP
` If target eNB supports EN-DC and successfully retrieve the UE context, it will respond with RRC
`Connection Resume including the RadioBearerConfiguration containing the SRB1 NR PDCP
`configuration. Upon receiving this, the UE should change the PDCP version of SRB1 from LTE
`PDCP to NR PDCP.
`
`
`
`3.2.2 SRB2/DRB aspects
`In the case of re-establishment, we have already agreed that:
`
`
`
`
`6/12
`
`
`
`

`

`Agreements
`1 For re-establishment in LTE, UE releases the lower layer SCG configuration (i.e. nr-
`secondaryCellGroupConfig) at RRC re-establishment while the DRB configuration (incl.
`the NR PDCP configuration received in radioBearerConfig) is kept.
`
`
`This aspect was not discussed online for the resume case. The keeping of the bearer configuration is even
`more relevant for the resume case because RRCConnectionReconfigruation is not needed after resume and
`as such keeping the bearer configuration facilitates the possibility of performing delta configuration via the
`resume message.
`Proposal 1: On LTE suspend, the DRB configuration (incl. the NR PDCP configuration received in
`radioBearerConfig) is kept.
`Regarding the resumption of SRB2/DRBs, since the resume message contains radio bearer configurations, it
`is natural to extend it to also include NR configurations.
`
`
`Proposal 2: The resume message to be aligned with RRCConnectionReconfiguration message to
`enable configuration of bearers with NR PDCP.
`
` Discussion
`Question 1: Which solution do you prefer regarding the PDCP version to be used for SRB1 during re-
`establishment? Why?
`
`Company
`
` 4
`
`Ericsson
`
`Lenovo
`
`LG
`
`
`
`Preferred
`solution
`Solution 3
`
`Solution 1
`or Solution
`4
`(proposed
`by Intel)
`
`Solution 4
`
`Comments
`
`- In both Solution1 and 2, mapping of the NR security algorithms to
`the LTE algorithms is required by both the UE and network (as
`SRB1 is used to send the
`RRCConnectionReestablishmentComplete message). In rel-15, we
`have a clear mapping/support for this, but this means in the future
`we might face a problem as new algorithms get introduced in NR
`(or else have to put a limitation that even in future releases of EN-
`DC, SRB1 can’t use non LTE compatible algorithms)
`- Keeping the NR PDCP is the most forward compatible solution,
`i.e. in the future, as more EN-DC capable eNBs are deployed, it will
`become very unlikely to pop up in an eNB that doesn’t support NR
`PDCP.
`-Solution 3 has the least standardization impact.
`
`Sufficient and sufficiently clear.
`Solution 3 may not be possible for legacy eNBs since they had no
`idea about such a case (NR PDCP) and were planning on full
`configuration after a successful admission control!! Though
`“preparation between source and target” could ensure that such
`confusing situation is taken care off but in that case the re-
`establishment possibility would reduce (only limited target cell
`prepared for re-establishment)
`If the UE was configured with EN-DC, the surrounding neighbor cell
`are most likely to support EN-DC also. We think that the case
`moving from source eNB supporting EN-DC to target eNB also
`supporting EN-DC is much more frequent than otherwise. In
`addition, moving to pure LTE in the future will be even rarer. Thus,
`
`7/12
`
`
`
`

`

`we do not prefer the fall-back procedure, solution 1.
`Solution 3 has the least impact on specification and legacy network,
`but it is true that the UE has to transit to RRC_IDLE. Compared to
`accepting re-establishment and performing full configuration, it will
`take more time to perform initial RRC connection.
`Regarding solution 2, though it was not discussed and agreed in
`RAN2, SA2 approved to introduce a SIB indicator for the support of
`NR as secondary RAT in E-UTRA cell (CR S2-176090). Thus, if we
`want an approach that changing PDCP according to the eNB
`capability, the UE can use that indication to decide which PDCP
`would be used instead of additional bit in
`RRCConnectionReestablishment message.
`Based on that, we suggest to slightly change the solution 2 (i.e.
`solution 4) as below:
`Solution 4: UE determines which PDCP is used for re-
`establishment procedure using “nr-Indication” in SIB. (In this
`solution, “nr-Indication” indicates whether the E-UTRA cell is
`capable of supporting dual connectivity with locally available NR
`secondary cell(s) via SIB1, and this already proposed by Qualcomm
`in R2-1713639 based on the SA2 agreement.)
`-
`If UE gets a “nr-Indication” as true via SIB1, it uses the same
`PDCP version that it was using before failure.
`-
`If UE doesn’t get a “nr-Indication”, UE falls back to using LTE
`PDCP.
`Solution 4 is preferred as long as RAN2 does not reject the SA2
`agreement. Otherwise Solution 2 would be better.
`It’s simple and can be used by legacy eNB. No impact on the
`legacy eNB and specificaiton.
`The benefit of Solution3 is unclear. It can’t reduce the signalling
`overhead, because RRCConnectionReconfiguration message is still
`needed. And even more EN-DC capable eNBs will be deployed in
`the future, the legacy eNBs are still there. The re-establishment to
`legacy eNB can not be avoided.
`Besides the specification impact, Solution 3 also increases the eNB
`complexity, because the source eNB should distinguish whether the
`target eNB support EN-DC or not before sending the UE context.
`Solution 4 We think the key point is whether UE can know if the cell to
`reestablish support EN-DC or not. Thus solution 4 seems to be
`straight forward. And one note is that we need to interpret the
`nr_indicator as EN-DC capable.
`Solution 5 We should first discuss what legacy eNB behaviour should be. To
`our understanding, the legacy eNB behaviour is:
` If eNB does not have the UE context, it will always reject the
`RRC Connection Re-establishment request.
` If eNB does not support EN-DC and receive the UE context, ,
`there are two possible legacy network behaviours possible:
`a)
`It will reject the re-establishment
`b)
`it will respond with RRC Connection Re-
`establishment and then perform Full configuration
`in the first RRC Connection Reconfiguration
`message
`Hence for backward compatibility, both network implementations
`
`Solution 1
`
`CATT
`
`OPPO
`
`Intel
`
`
`
`8/12
`
`
`
`

`

`Solution 1
`or Solution
`5.
`
`has to be supported. Solution3 mentioned above is not backward
`compatible and cannot be supported by at least some legacy eNBs
`using (b).
`To avoid the impact to legacy eNB, upon initiating the RRC
`Connection Reestablishment request, the SRB1 should use the
`default configuration where the PDCP version should be LTE
`PDCP. A full configuration reverts the PDCP to LTE PDCP for DRB.
`However, Full configuration does not change SRB1 configuration,
`UE has to revert to LTE PDCP for SRB1. 
`
`Then for eNB that supports EN-DC and receive the UE context, it
`will respond with RRC Connection Re-establishment including the
`RadioBearerConfiguration containing the SRB1 NR PDCP
`configuration. Upon receiving this, the UE should change the PDCP
`version of SRB1 from LTE PDCP to NR PDCP. The first
`reconfiguration message will decide on SRB2 and the DRB
`configuration (either keep them as the configuration prior to the re-
`establishment or perform delta configuration).
`
`We are sympathetic to solution 3 but it may require a new
`behaviour from legacy eNBs considering the proposal that “If target
`eNB doesn’t support EN-DC, and it doesn’t understand the RRC
`context, it will reject the re-establishment “.
`Solution4a Adding 1 bit indication (NR-PDCP supported) in SIB can help solve
`all PDCP selection problem in both cases, RRC Connection
`Reestablishment procedure and RRC Connection Resume
`procedure.
`We doubt reusing nr-Indication for NR PDCP supported indication is
`a good proposal because nr-Indication is designed for 5g marketing
`advertising and for per PLMN. The NR-PDCP support is for eNB
`self, which doesn’t need per PLMN. Furthermore, eNB who
`supports EN-DC doesn’t means it must support NR PDCP. We
`already had agreement in this meeting that one-step bearer type
`change + PDCP type change can be supported. So one explicit
`indication for NR PDCP support in SIB2/3 is more attractive to
`cover all cases.
`Solution 1 We don't see the need for any new indication. It is simple to always
`fall back to LTE PDCP upon re-establishment/resume. For re-
`establishment, the network can configure NR PDCP in the first
`reconfiguration if it wishes to. For resume, it should be possible in
`the resume message to reconfigure SRB1 to use NR PDCP.
`For eNB supporting EN DC, an indicator can be added into its SI.
`No impacts to the legacy eNBs.
`The UE can check the indicator and decide to use LTE PDCP or
`NR PDCP for connection reestablishment. This way can solve
`security algorithm problems too.
`
`Solution 4
`
`Convida Wireless
`
`Nokia
`
`Huawei
`
`Spreadtrum
`
`
`Question 2: Which solution do you prefer regarding the PDCP version to be used for SRB1 during
`resume? Why?
`Company
`
`Comments
`
`Preferred
`solution
`Solution 2 The reason is similar to the case for re-establishment.
`Solution 2 For backward compatibility with an eNB that implements Full
`
`Ericsson
`Intel
`
`
`
`9/12
`
`
`
`

`

`Solution
`3+3a
`
`configuration in msg 4 Resume message sent with LTE PDCP, UE
`should already revert to LTE PDCP before sending Resume
`request.
`For the case the eNB supports EN-DC and successfully retrieve the
`UE context, it will respond with RRC Connection Resume including
`the RadioBearerConfiguration containing the SRB1 NR PDCP
`configuration. Upon receiving this, the UE should change the PDCP
`version of SRB1 from LTE PDCP to NR PDCP.
`We also think that UE can determine which PDCP to use for
`resume procedure using one indication broadcasted in SIB. And we
`think that the reconfiguration procedure that always accompanies
`the resume procedure is not beneficial.
`Agree with LG and align with the reestablishment case.
`3+3a
`Solution 1 Same reasons as above for re-est case.
`Solution
`It has been discussed in our feedback to Q1.
`3+3a
`Solution 2
`
`LG
`
`OPPO
`Lenovo/ MotM
`Nokia
`
`CATT
`
`If target eNB cannot retrieve the UE context or does not
`comprehend it , it can reject the RRC Connection Resume request
`or send RRC Connection Setup to trigger UE to fallback. So there
`is no problem for legacy eNB.
`If target eNB support NR PDCP and successfully retrieve the UE
`context, it can resume UE with NR PDCP.
`Share LG’s view
`
`3+3a
`
`Spreadtrum
`
`Question 3: What is your view regarding proposal 2 on the SRB2/DRB aspects during resumption?
`Regarding the resumption of SRB2/DRBs, since the resume message contains radio bearer configurations, it
`is natural to extend it to also include NR configurations.
`
`
`Proposal 2: The resume message to be aligned with RRCConnectionReconfiguration message to
`enable configuration of bearers with NR PDCP.
`
`
`Company
`Intel
`
`Comments
`The PDCP version for SRB2/DRB will depend on whether (i) UE
`receives a full configuration flag with no radio bearer configuration,
`(ii) UE receives a full configuration flag with radio bearer
`configuration or UE receives only optionally radio bearer
`configuration.
`
`If (i), SRB2/DRB is reverted to LTE PDCP.
`If (ii), SRB2/DRB stays with NR PDCP
`
`We agree with Intel.
`Agree with Intel.
`More time needed to check it.
`We agree the proposal 2
`Agree with Intel
`
`10/12
`
`
`
`LG
`Lenovo/ MotM
`Nokia
`CATT
`Spreadtrum
`
`
`
`

`

`
`
`
` 5
`
` Summary
`Question 1: Which solution do you prefer regarding the PDCP version to be used for SRB1 during re-
`establishment?
`Solution 1: Lenovo, CATT, Convida, Huawei, Ericsson
`Solution 2:
`Solution 3:
`Solution 4: LG, OPPO,Nokia, Spreadtrum
`Solution 5: Intel, Convida
`There is a equal preference for solution 1 and 4. However, solution 5 is also a modified version of solution 1
`(i.e. revert to LTE PDCP, and later change to NR PDCP if target eNB supports EN-DC). Solution 4 also
`needs further discussion on the introduction of a new SIB bit or the feasibility of using the 5G indication bit
`that was already introduced in earlier. Considering this, it is proposed:
`Proposal 1: On re-establishment,
` UE reverts to using LTE PDCP for SRB1
` If target eNB supports EN-DC, it can use RRCConnectionReconfiguration to revert the PDCP
`version of SRB1 or any other bearers to NR
` If target eNB doesn’t support EN-DC, it can perform full configuration to revert the PDCP
`version of all bearers to LTE PDCP.
`
`
`Question 2: Which solution do you prefer regarding the PDCP version to be used for SRB1 during
`resume?
`Solution 1: Lenovo
`Solution 2 Ericsson, Intel, CATT
`Solution 3: LG, OPPO, Spreadtrum, Nokia
`There was not as many input on this as for the re-establishment.
`Solution 3 has got a slight preference, but as agreed in the re-establishment discussion, it requires further
`discussion about the SIB bit to be introduced/used. Solution 2, will not cause a problem in case the target is
`legacy as in the re-establishment case, because here the target behaviour is well defined. That is, it will
`respond with RRCConnectionSetup (while in the re-establishment case, it could still respond with re-
`establish command, as it can do full reconfiguration later).
`
`Proposal 2: On resume,
` UE uses the same PDCP version as before suspension for SRB1
` If target eNB doesn’t support EN-DC and it doesn’t understand UE context, it will respond to
`the resume request with RRCConnectionSetup.
`
`
`Regarding the third aspect,
`The resume message to be aligned with RRCConnectionReconfiguration message to enable
`configuration of bearers with NR PDCP.
`There seems to be a strong support (except one company, Nokia, who indicated they need to check further)
`
`
`
`
`11/12
`
`
`
`

`

`Proposal 3: The RRCResume message to be aligned with RRCConnectionReconfiguration message
`to enable configuration of bearers with NR PDCP.
`
`
`
`
`
`12/12
`
`
`
`