3GPP TSG-RAN WG2 #99bis
`Prague, Czech Republic, 9 - 13 Oct 2017
`
` R2-1710279
` Revision of R2-1707896
`
`CATT
`Source:
`RRC connection re-establishment and resume procedures in NR
`Title:
`10.4.1.3.5
`Agenda Item:
`Document for: Discussion and Decision
`
`Introduction
`1.
`In RAN2#97bis meeting, some guidelines are agreed for the RRC messages and procedures [1].
`
`Agreement
`1
`Aim to limit the number of RRC messages i.e. avoid introducing several messages with similar content/
`similar procedural handling (details can be discusses when more progress has been made on the individual
`procedures)
`
`This contribution discusses the details of individual procedures for RRC connection re-establishment and resume.
`
`2. Discussion
`2.1.
`RRC connection re-establishment
`In LTE, The purpose of this procedure is to re-establish the RRC connection, which involves the resumption of
`SRB1 operation, the re-activation of security and the configuration of only the PCell.
`
`UE
`
`EUTRAN
`
`RRCConnectionReestablishmentRequest
`
`RRCConnectionReestablishment
`
`RRCConnectionReestablishmentComplete
`
`Figure 1 RRC connection re-establishment, successful
`
`UE
`
`EUTRAN
`
`RRCConnectionReestablishmentRequest
`
`RRCConnectionReestablishmentReject
`
`Figure 2 RRC connection re-establishment, failure
`The function of re-establishing the RRC connection should naturally be supported in NR for UE in connected
`mode, including the successful and failure procedures.
`Proposal 1: Support the successful and failure procedures for RRC connection re-establishment in NR.
`The content of the RRC messages for RRC connection re-establishment are listed in the table 1.
`Table 1 content of the RRC messages for RRC connection re-establishment
`Content in LTE
`Proposed Content in NR
` ue-Identity
` ue-Identity
`
`RRC message
`RRCConnectionReestablishment
`Request
`
`R2-1710279
`
`1
`
`APPLE 1007
`
`

`

`
`
`
`
`RRCConnectionReestablishment 
`
`
`reestablishmentCause
`rrc-TransactionIdentifier
`radioResourceConfigDedicated
`(for SRB1)
` NextHopChainingCount
`
`rrc-TransactionIdentifier
`
`rlf-InfoAvailable-r9
`
`logMeasAvailable-r10
`
`connEstFailInfoAvailable-r11
`
`logMeasAvailableMBSFN-r12
` No IE
`
`
`
`
`
`reestablishmentCause
`rrc-TransactionIdentifier
`radioResourceConfigDedicat
`ed (for SRB1)
` NextHopChainingCount
`
`rrc-TransactionIdentifier
`
` No IE
`
`RRCConnectionReestablishment
`Complete
`
`RRCConnectionReestablishment
`Reject
`
`and
`
`RRCConnectionReestablishment
`RRCConnectionReestablishmentRequest,
`For
`RRCConnectionReestablishmentReject messages, all parameters for LTE are also needed in NR.
`For RRCConnectionReestablishmentComplete message, the IEs rlf-InfoAvailable-r9, logMeasAvailable-r10,
`connEstFailInfoAvailable-r11 and logMeasAvailableMBSFN-r12 are related to MDT/SON which are not
`supported in NR phase I, so only IE rrc-TransactionIdentifier is needed in NR.
`The RRC connection re-establishment procedure is used for SRB1 resumption and re-activation of security and
`the configuration of only the PCell, so the following parameters are proposed to support.
`Proposal 2: Support the following parameters for the RRC messages in RRC connection re-establishment
`procedure, the details of each parameter can be discussed further:
` RRCConnectionReestablishmentRequest: UE ID, Re-establishment Cause
` RRCConnectionReestablishment: Transaction ID, dedicated radio resource configuration for SRB1,
`NCC
` RRCConnectionReestablishmentComplete: Transaction ID
`
`RRC connection resume
`2.2.
`In LTE, the purpose of this procedure is to resume an RRC connection, which involves the resumption of all
`SRBs and DRBs, and the re-activation of security.
`
`UE
`
`
`
`EUTRAN
`
` RRCConnectionResumeRequest
`
`RRCConnectionResume
`
`RRCConnectionResumeComplete
`
`
`
`Figure 3 RRC connection resume, successful
`
`R2-1710279
`
`2
`
`

`

`
`
`
`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
`In RAN2#99, it is agreed that for INACTIVE to CONNECTED RRC transition, RRC connection resume request
`kind of message is sent over SRB0 carried by RACH MSG3. When RAN successfully retrieves and verifies the
`UE context, RRC connection resume kind of message is sent over SRB1 carried by RACH MSG4, and MSG5 is
`RRC connection resume complete kind of message over SRB1 [2]. Accordingly, the successful resume is
`supported for the UE in inactive mode in NR. Moreover, RAN2 agreed that when RAN cannot successfully
`retrieve and verify the UE context, RRC Connection Setup kind of message is sent over SRB0 (which would
`enable a fallback to establish a new RRC connection similar to Rel-13 LTE), i.e., fallback to RRC connection
`establishment is supported for the UE resuming from inactive mode in NR. In addition, in RAN2#98 it is agreed
`that “If the UE received a message suspending the UE on MSG4 on SRB1 then the UE remains in RRC inactive”
`[3], it can be realized by network reject or release procedure, which is under discussion of email discussion#29.
`Consequently, we expect that network reject or release procedures should be supported for the UE resuming
`from inactive mode in NR.
`Proposal 3: Support the successful resume, fallback to RRC connection establishment and either network
`reject or release procedures for RRC connection resume in NR.
`In RAN2#99, RAN2 also achieved some agreements on the information included in the above messages directly
`and indirectly. Specifically, for INACTIVE to CONNECTED RRC transition, RRC Connection Resume Request
`kind of message includes UE identity (or UE context identity), establishment (or resume) cause information and
`UE's security information (e.g. authentication token). FFS if MSG3 could also include other information. RRC
`Connection Resume kind of message can optionally include the dedicated radio resource configuration. FFS
`Whether RRC Connection Resume Complete includes NAS PDU, 5CN node selection information (e.g. selected
`PLMN identity or NSSAI).
`The content of the RRC messages for RRC connection resume are listed in the table 1.
`Table 2 content of the RRC messages for RRC connection resume
`Content in LTE
`Proposed Content in NR
`
`
`resumeIdentity-r13
`resumeIdentity-r13
` UE's security
`
`information
`shortResumeMAC-I-r13
`(e.g. authentication token)
`
`resumeCause-r13
`resumeCause-r13
`rrc-TransactionIdentifier
`radioResourceConfigDedicat
`ed-r13(for all SRBs and
`DRBs)
`
`RRC message
`RRCConnectionResumeRequest
`
`RRCConnectionResume
`
`rrc-TransactionIdentifier
`radioResourceConfigDedicated-
`r13(for all SRBs and DRBs)
`nextHopChainingCount-r13
`
`
`
`
`
`
`
`
`
`
`R2-1710279
`
`3
`
`

`

`
`
`
` measConfig-r13
`
`antennaInfoDedicatedPCell-r13
`
`drb-ContinueROHC-r13
`
`RRCConnectionResumeComplete 
`rrc-TransactionIdentifier
`
`selectedPLMN-Identity-r13
`
`dedicatedInfoNAS-r13
`
`rlf-InfoAvailable-r13
`
`logMeasAvailable-r13
`
`connEstFailInfoAvailable-r13
` mobilityState-r13
` mobilityHistoryAvail-r13
`
`logMeasAvailableMBSFN-r13
`
`rrc-SuspendIndication-r13
`
`RRCConnectionReject
`
`
`nextHopChainingCount-r13
` measConfig-r13
`
`antennaInfoDedicatedPCell-
`r13
`drb-ContinueROHC-r13
`rrc-TransactionIdentifier
`selectedPLMN-Identity-r13
`dedicatedInfoNAS-r13
`
`
`
`
`
`
`
`
`rrc-SuspendIndication-r13
`
`For RRCConnectionResumeRequest, RRCConnectionResume and RRCConnectionReject messages, all
`parameters for LTE are also needed in NR, except that in RRCConnectionResumeRequest it is FFS whether the
`UE's security information is shortResumeMAC-I. As to RRCConnectionReject message, although in light
`connection a new rrc-LightConnectionIndication is introduced to indicate that the UE should remain lightly
`connected and not release its stored context if present [4], whether MSG 4 can be a reject to idle is for further
`study in case of inactive state. If it is agreed that MSG 4 can be a reject to idle afterwards, this kind of indication
`should be added in Table 2.
`logMeasAvailable-r13,
`rlf-InfoAvailable-r13,
`IEs
`the
`For RRCConnectionResumeComplete message,
`connEstFailInfoAvailable-r13 and logMeasAvailableMBSFN-r13 are related to MDT/SON which are not
`supported in NR phase I. The IEs mobilityState-r13 and mobilityHistoryAvail-r13 are related to UE mobility
`history which is not supported in NR phase I. So only IEs rrc-TransactionIdentifier, selectedPLMN-Identity-r13
`and dedicatedInfoNAS-r13 are needed in NR.The RRC connection resume procedure is used for all SRBs and
`DRBs resumption and re-activation of security and, so the following parameters are proposed to support.
`Proposal 4: Support the following parameters for the RRC messages in RRC connection resume
`procedure, the details of each parameter can be discussed further:
` RRCConnectionResumeRequest: Resume ID, Resume Cause, UE's security information
` RRCConnectionResume: Transaction ID, dedicated radio resource configuration for all SRBs and
`DRBs, NCC, measurement Configuration, antenna info, Continue ROHC for DRB
` RRCConnectionResumeComplete: Transaction ID, selected PLMN ID, dedicated NAS info.
` RRCConnectionReject: Suspend Indication
`
`Comparison of RRC connection re-establishment and resume
`2.3.
`Comparison can be made based on the analysis of section 2.1 and 2.2. The details are shown below:
` RRC re-establishment is used for connected mode UE, and RRC resume is used for inactive mode UE. In
`these two cases, the network both has UE’s AS context.
` They are both used to re-active the security.
` RRC re-establishment can resume SRB1, and RRC resume can resume all SRBs and DRBs.
` From the procedure point of view, the successful and reject procedures are similar. The RRC resume
`procedure has a fallback mechanism to RRC connection establishment, which is not supported by RRC re-
`establishment.
` From the content point of view:
`
`R2-1710279
`
`4
`
`

`

`
`
`
`
`
`both RRCConnectionReestablishmentRequest and RRCConnectionResumeRequest have UE ID and
`cause, although the details are not the same. And the latter has just one more parameter, i.e. UE's
`security information.
` Both RRCConnectionReestablishment and RRCConnectionResume have Transaction ID, dedicated
`radio resource configuration and NCC, and the latter has more parameters for other purpose.
` Both RRCConnectionReestablishmentComplete and RRCConnectionResumeComplete have
`Transaction ID, and the latter has more parameters for other purpose.
` For reject case, only reject message for resume procedure has a Suspend Indication.
`
`So there are many commonalities between RRC connection re-establishment procedure and RRC connection
`resume procedures. Thus it should be aim to combine the RRC messages used for RRC connection re-
`establishment procedure and RRC connection resume procedure.
`Proposal 5: Aim to combine the following RRC messages for NR:
` RRCConnectionReestablishmentRequest and RRCConnectionResumeRequest
` RRCConnectionReestablishment and RRCConnectionResume
` RRCConnectionReestablishmentComplete and RRCConnectionResumeComplete
` RRCConnectionReestablishmentReject and RRCConnectionReject
`
`3. Conclusion
`In this contribution, we discuss the individual procedures for RRC connection re-establishment and resume, and
`propose:
`Proposal 1: Support the successful and failure procedures for RRC connection re-establishment in NR.
`Proposal 2: Support the following parameters for the RRC messages in RRC connection re-establishment
`procedure, the details of each parameter can be discussed further:
` RRCConnectionReestablishmentRequest: UE ID, Re-establishment Cause
` RRCConnectionReestablishment: Transaction ID, dedicated radio resource configuration for SRB1,
`NCC
` RRCConnectionReestablishmentComplete: Transaction ID
`Proposal 3: Support the successful resume, fallback to RRC connection establishment and either network
`reject or release procedures for RRC connection resume in NR.
`Proposal 4: Support the following parameters for the RRC messages in RRC connection resume
`procedure, the details of each parameter can be discussed further:
` RRCConnectionResumeRequest: Resume ID, Resume Cause, UE's security information
` RRCConnectionResume: Transaction ID, dedicated radio resource configuration for all SRBs and
`DRBs, NCC, measurement Configuration, antenna info, Continue ROHC for DRB
` RRCConnectionResumeComplete: Transaction ID, selected PLMN ID, dedicated NAS info.
` RRCConnectionReject: Suspend Indication
`Proposal 5: Aim to combine the following RRC messages for NR:
` RRCConnectionReestablishmentRequest and RRCConnectionResumeRequest
` RRCConnectionReestablishment and RRCConnectionResume
` RRCConnectionReestablishmentComplete and RRCConnectionResumeComplete
` RRCConnectionReestablishmentReject and RRCConnectionReject
`
`4. Reference
`[1] RAN2#97bis, Chairman notes.
`[2] RAN2#99, Chairman notes.
`
`R2-1710279
`
`5
`
`

`

`
`
`
`[3] RAN2#98, Chairman notes.
`[4] R2-1701689, Light Connection Feature specification in 36.331 - TP agreements and outcome of email
`discussion [96#66], RAN2#97.
`
`R2-1710279
`
`6
`
`