Handling Busy Indication and Leaving Procedure in 5G Networks
The pre-SA2#145E conference call discussed topics such as handling Busy indication from RRC Inactive, 5GS Leaving procedure for 5GC/NR, MUSIM capability exchange, and more. Agreements on RRC leaving procedures and the need for NAS Leaving in addition to RRC Leaving in 5GC/NR were addressed. The meeting also confirmed the work plan for SA2#145E.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Pre-SA2#145E CC 30 Apr 2021 Pre-SA2#145E conference call Sa o Stojanovski, Intel (Rapporteur)
Agenda 1. How to handle the Busy indication from RRC_Inactive in the light of the RAN2 LS (R2-2104354). Sony Busy indication from RRC_Inactive based on LS from RAN2 Intel 5GS Leaving procedure for 5GC/NR and Busy indication from RRC_Inactive - 15min 2. How to handle the 5GS Leaving procedure for 5GC/NR in the light of the RAN2#113bis-e. Charter Communications, Comcast 5GS Leaving procedure for 5GC/NR Intel 5GS Leaving procedure for 5GC/NR and Busy indication from RRC_Inactive Ericsson KI#3, updates to conclusions for KI#3 (for information) LG Electronics Discussion on leaving and charging issue - 15min 3. Resolve open discussion on MUSIM capability exchange. MediaTek Inc., Intel, LG Electronics, Qualcomm Incorporated, Samsung Handling of MUSIM capabilities Qualcomm et al. Introduction of MUSIM capability exchange (three CRs, not planned to be handled on the CC) - 15min 4. AOB - 10min Intel (Rapporteur) confirm the work plan for SA2#145E Samsung Voice service indication in NOTIFICATION message 2 Next Generation and Standards (NGS) Intel Confidential Client and Internet of Things (IoT) Businesses and Systems Architecture Group
5GS Leaving for 5GC/NR (1/3) RAN2#113bis-e have reached the following agreements on RRC leaving: 1 RRC signalling is used for switching procedure without leaving RRC_CONNECTED state in network A for UE temporarily switching to network B as a baseline. FFS on additional need of MAC signalling. 2 During switching procedure for leaving RRC_CONNECTED state, UE is allowed to enter RRC_IDLE state if it does not receive response message from network within a certain configured time period. FFS for RRC_INACTIVE state. Regarding Agreement 1: This leaving procedure (with UE remaining in RRC_Connected state) is completely transparent to the CN. It can be used for short activity in the other network (e.g. performing mobility or periodic update, or Busy indication). During UE s absence, the NG-RAN can e.g. silently drop packets, without declaring RL failure. Agreement 1 has no impact on the work in SA2 other than referencing it as a possibility (e.g. in the functional description or in a NOTE in the Leaving procedure). Regarding Agreement 2: Currently it covers only the RRC_Idle state and addresses the error case where the RAN s ack is somehow lost. 3 Next Generation and Standards (NGS) Intel Confidential Client and Internet of Things (IoT) Businesses and Systems Architecture Group
5GS Leaving for 5GC/NR (2/3) When the end state of the 5GS Leaving procedure is RRC_Idle: Is NAS Leaving procedure still needed for 5GC/NR in addition to the RRC Leaving procedure? We think NAS Leaving is needed in order to cope with the case of non-supporting RAN node NAS Leaving is also needed when UE wants to use Paging Restrictions (we assume that PRs are not supported with RRC Leaving) When RAN node supports RRC Leaving and UE does not need to use PRs, the choice of procedure can be left to UE implementation (the expectation being that RRC Leaving should be slightly faster) Proposal 1: The standard shall support NAS Leaving for 5GC/NR in addition to RRC Leaving. 4 Next Generation and Standards (NGS) Intel Confidential Client and Internet of Things (IoT) Businesses and Systems Architecture Group
5GS Leaving for 5GC/NR (3/3) When the end state of the 5GS Leaving procedure is RRC_Inactive: Should this case be supported? SA2#144E agreed that for NAS Leaving with 5GC/E-UTRA case the end state can only be RRC_Idle (refer to the technically endorsed S2- 2103027 with the clarification that RRC-CONNECTED is changed to CM-CONNECTED in two places). Introducing support for RRC_Inactive in the 5GC/NR case would be a further discrepancy compared to the 5GC/E-UTRA case If RAN2 decide to support RRC Leaving with end state RRC_Inactive, we assume that the use of Paging Restrictions is not possible. With NAS Leaving it is possible to support RRC_Inactive including the provision of Paging Restrictions to NG-RAN (e.g. as described in TR 23.761 Figure 6.5.3.1.1-1 step 2). It is noted that support for (NAS or RRC) Leaving with end state RRC_Inactive will require some work in RAN3 and may have impact to charging due to silently discarded data in NG-RAN. For short absence (e.g. performing mobility/periodic udate or Busy indication in the other network) the UE can use the RRC switching procedure without leaving RRC_Connected state For absence of undetermined duration the UE might as well be put in RRC_Idle state. Indeed, if silent discarding of DL data by NG-RAN is considered an issue for charging, then UE should better be released to RRC_idle Proposal 2: NAS Leaving with end state RRC_Inactive is not supported. Inform RAN2 of the decision so that they can discontinue their work on RRC Leaving with end state RRC_Inactive. 5 Next Generation and Standards (NGS) Intel Confidential Client and Internet of Things (IoT) Businesses and Systems Architecture Group
Busy indication from RRC_Inactive RAN2#113bis-e have reached the following agreement on Busy indication from RRC_Inactive (R2-2104354): 1 Only support NAS-based busy indication (for IDLE and INACTIVE) Consequences of this agreement: SA2 agreed to support the inclusion of PRs in the Reject Paging request. If PRs are included in the Reject Paging request, and if the UE is to remain in RRC_Inactive state, the Reject Paging procedure needs to be enhanced to support: 1) AMF sending an indication to NG-RAN that UE should be released to RRC_Inactive, 2) AMF sending PRs to NG-RAN, and 3) acknowledge that CT1 will need to define a Service Accept message that acks the PRs. Note that the potential issue with charging (described in slide 5) also applies in this case Alternatively, acknowledge that when NAS Reject Paging is used from RRC_Inactive, the end state is always RRC_Idle (Intel s preference) In other words, NAS Busy indication from RRC_Inactive can only be used once, the UE necessarily transitioning to RRC_Idle Proposal 3: When NAS Reject Paging is used from RRC_Inactive, the end state is always RRC_Idle. 6 Next Generation and Standards (NGS) Intel Confidential Client and Internet of Things (IoT) Businesses and Systems Architecture Group
Summary of proposals Proposal 1: NAS Leaving for 5GC/NR shall be supported in addition to RRC Leaving. Proposal 2: NAS Leaving with end state RRC_Inactive is not supported. Inform RAN2 of the decision so that they can discontinue their work on RRC Leaving with end state RRC_Inactive. Proposal 3: When NAS Reject Paging is used from RRC_Inactive, the end state is always RRC_Idle. 7 Next Generation and Standards (NGS) Intel Confidential Client and Internet of Things (IoT) Businesses and Systems Architecture Group
