Content for TR 23.700-68 Word version: 18.1.0

7.1 General 7.2 Key Aspects 7.2.1 Overview 7.2.2 Buffering of Downlink data 7.2.2.1 Core Network DL data buffering 7.2.2.2 RAN DL data buffering 7.2.3 Mobile Terminated signalling 7.2.3.1 AMF aware of RRC-Inactive with long eDRX 7.2.3.2 AMF unaware of RRC-Inactive with long eDRX 7.2.4 UE mobility outside RNA without Xn reference point. 7.2.5 High Latency Communication with RRC-Inactive

7 Evaluation p. 31

7.1 General p. 31

There are six solutions proposed to address the objective to enable long eDRX when the UE is in RRC-Inactive. The table below is to provide an overview of these solution. The solutions being:

Solution 1:

Power saving enhancement with long eDRX cycle support for UE in CM-CONNECTED with RRC_INACTIVE state.

Solution 2:

Long eDRX with RAN buffering.

Solution 3:

Solution #3: MT signalling and data handling for UE with long eDRX cycle in RRC_Inactive state and UPF buffering.

Solution 4:

RRC Inactive with CM-IDLE for eDRX > 10.24s.

Solution 5:

Enabling UPF buffering per NG-RAN request for UE in RRC_Inactive state with long eDRX cycle.

Solution 6:

Converged solution for handling RRC inactive with eDRX > 10.24s.

Table 7.1-1

	Solution #1	Solution #2	Solution #3	Solution #4	Solution #5	Solution #6
State Combination(s)	RRC Inactive/CM-Connected	RRC Inactive/CM-Connected	RRC Inactive/CM-Connected	RRC Inactive/CM-Idle	RRC Inactive/CM-Connected	RRC Inactive /CM-Connected and long eDRX (New AMF sub-state)
Node that configure the UE eDRX in RRC-Inactive	RAN (at RRC Release)	RAN (at RRC Release)	RAN (at RRC Release)	RAN (at RRC Release)	RAN (at RRC Release)	RAN (at RRC Release)
AMF awareness of RRC-Inactive state needed in CM-CONNECTED	Yes	No	Yes	Yes	Yes	Not explicitly (AMF aware of long eDRX.)
User data Buffering	UPF/SMF	RAN or UPF/SMF If RAN fails to buffer according to configured eDRX, RAN will initiate AN release procedure towards the CN. UE is moved to CM-Idle in the CN and the state in the UE remains as CM-Connected.	UPF	UPF/SMF	RAN and UPF RAN sends a N2 Suspend request indicate start of CN/UPF buffering after receiving DL data(remaining eDRX Timer).	UPF/SMF
MT Signalling	AMF is aware of eDRX information	AMF → RAN forward NAS msg. If the UE is not reachable then: RAN → AMF releases UE context with Notification that UE is in eDRX cycle. UE is moved to CM-Idle. AMF may try again later based on eDRX information	AMF is aware of buffer timer (initial and re-buffer timers)	AMF is aware of eDRX information	AMF → RAN forward NAS msg. If the UE is not reachable then: RAN → AMF Notification that UE is in eDRX cycle (remaining eDRX Timer). UE remains in RRC-Inactive and CM-Connected. AMF suspend MT signalling based on Timer.	AMF is aware of eDRX information
UE RRC Release timing.	UE may be released before AMF is notified	N/A	UE may be released before AMF is notified	UE is released after AMF responds to the N2 suspend as specified in clause 4.8.1 of TS 23.502	N/A	UE is released after AMF responds to the N2 request
Signalling when UE moves from RRC Connected to RRC Inactive	RAN→ AMF Notification (eDRX config) AMF→ SMF → UPF PDU session modification	None	RAN→ AMF Notification (buffer timer) AMF→ SMF → UPF PDU session modification (buffer timer)	RAN→ AMF Suspend message (eDRX config) AMF→ SMF → UPF PDU session modification	None, when the transition occurs. During the RRC_Inactive period RAN→ AMF Suspend message (eDRX config) AMF→ SMF → UPF PDU session modification may occur.	RAN→ AMF Suspend message (eDRX config) AMF→ SMF → UPF PDU session modification
Signalling when UE moves from RRC Inactive to RRC Connected	RAN→ AMF Notification AMF→ SMF → UPF PDU session modification	None	RAN→ AMF Notification and then AMF→ SMF → UPF PDU session modification for MO triggered connection resume.	RAN→ AMF Resume message AMF→ SMF → UPF PDU session modification	Only if RAN sent a N2 Suspend request to start of DL data buffering, then RAN will send a N2 Resume request once the UE is in RRC-Connected state.	RAN→ AMF Resume message AMF→ SMF → UPF PDU session modification
Information exchanged among NFs	AMF communicates with other NFs on the UE reachability the same way as in CM-IDLE modes deducing UE reachability information based on gNB provided eDRX value.	None EN: It is FFS whether and how the AMF may support UE reachability notification based on IDLE mode eDRX information also in CM-Connected.	AMF communicates with other NFs on the UE reachability based on the buffering information provided by gNB.	AMF communicates with other NFs on the UE reachability the same way as in CM-IDLE modes deducing UE reachability information based on gNB provided eDRX value.	AMF communicates with other NFs on the UE reachability based N1 message transfer failure provided by gNB and may reject requests from other NFs based on it.	AMF communicates with other NFs on the UE reachability the same way as in CM-IDLE modes deducing UE reachability information based on gNB provided eDRX value.
Paging	SMF/ UPF forwards buffered data based on Estimated Maximum Wait time to trigger RAN paging If UE does not respond data will be dropped	RAN trigger paging based on UE eDRX configuration If UE does not respond data will be dropped. Optional: RAN may escalate to AMF for paging within RA.	UPF forwards buffered data based on "buffer timer" to trigger RAN paging. If UE does not respond data will be dropped.	AMF send a paging request with new indication to trigger RAN paging. If UE does not respond AMF can escalate CN paging within RA.	Based on MT data/N1 message buffered in RAN, RAN trigger paging based on UE eDRX configuration. The UPF forwards buffered data based on "buffer timer". If UE does not respond MT data/N1 will be dropped if the buffer in RAN is overflown.	AMF send a paging request with new indication to trigger RAN paging. If UE does not respond AMF can escalate CN paging within RA.
Mobility within RNA	UE trigger RNAU New RAN node fetch UE context from anchor RAN node and perform path switch	UE trigger RNAU New RAN node fetch UE context from anchor RAN node and perform path switch	UE trigger RNAU New RAN node fetch UE context from anchor RAN node and perform path switch	UE trigger RNAU New RAN node fetch UE context from anchor RAN node and perform path switch	UE trigger RNAU New RAN node fetch UE context from anchor RAN node and perform path switch	UE trigger RNAU New RAN node fetch UE context from anchor RAN node and perform path switch
Mobility outside RNA	UE trigger RNAU RAN fetch UE context if Xn. If RAN is unable to fetch the UE context, RAN release UE to RRC Idle. No UE state change notification to CN If UE has MO data, the UE will perform SR from Idle	UE trigger RNAU RAN fetch UE context if Xn. RAN fetch UE context via AMF (buffered data will be forwarded) If RAN is unable to fetch the UE context, RAN release UE to RRC Idle. No UE state change notification to CN If UE has MO data the UE will perform SR from Idle	UE trigger RNAU RAN fetch UE context if Xn. RAN fetch UE context via AMF (buffered data will be forwarded) If RAN is unable to fetch the UE context, RAN release UE to RRC Idle. No UE state change notification to CN If UE has MO data the UE will perform SR from Idle	UE trigger RNAU RAN fetch UE context if Xn. If RAN is unable to fetch the UE context, RAN release UE to RRC Idle. No UE state change notification to CN If UE has MO data the UE will perform SR from Idle	UE trigger RNAU RAN fetch UE context if Xn. If RAN is unable to fetch the UE context, RAN release UE to RRC Idle. No UE state change notification to CN If UE has MO data the UE will perform SR from Idle	UE trigger RNAU RAN fetch UE context if Xn. If RAN is unable to fetch the UE context, RAN release UE to RRC Idle. No UE state change notification to CN If UE has MO data the UE will perform SR from Idle
UE signalling in RRC-Inactive	UE performs only periodic update signalling at AS.	UE performs only periodic update signalling at AS.	UE performs only periodic update signalling at AS.	UE performs periodic update signalling at both AS and NAS.	UE performs only periodic update signalling at AS.	UE performs only periodic update signalling at AS.

7.2 Key Aspects p. 36

7.2.1 Overview p. 36

RRC-Inactive/CM-Connected was specified in Rel-15 as a new efficient state for 5G UEs. The key benefits for RRC-Inactive/CM-Connected compared to RRC-Idle/CM-Idle are the following:

UE can resume the AS connection without performing e.g. AS security setup, and save several RRC message interactions between the UE and RAN.
There is no RAN and CN interaction when the UE change state RRC-Inactive to/from RRC-Connected, if not required.
User plane reconfiguration is not needed.

The area in which the UE move around in without the UE needs to perform Update due to mobility maybe much smaller than compared to RRC-Idle. In RRC-Inactive the area is defined by the Radio Notification Area (RNA) consisting of a set of RAN nodes. In RRC-Idle then the area is the whole Registered Area (RA) consisting of a set of Tracking Areas. This may result in more frequent Updates due to mobility.

7.2.2 Buffering of Downlink data p. 36

Two methods of buffering are proposed in the solutions with the main difference being DL data buffering in RAN or in the CN. Solution 2 and solution 5 allow buffering of the DL data in RAN. Solutions 1, 3, 4, 5 and 6 allows DL data in the Core Network either in the SMF or UPF in RRC_INACATIVE state.

7.2.2.1 Core Network DL data buffering p. 36

To enable DL data buffering in the Core Network, the RAN needs to signal to the AMF that the UE has changed its RRC state to RRC-Inactive with long eDRX. This initial N2 message will trigger the communication among CN NFs i.e. the AMF uses the Nsmf_PDUSession_UpdateSMContext Request to trigger the SMF to start the modification procedure towards UPF. Solution 4 and 6 ends these steps after the N2 response from the AMF to the RAN which allows the RAN to release the UE to RRC-Inactive. Solution 1 and 3 performs the these steps either after the UE is released or in parallel to that the UE is released. For solution 1 and 3 there is a risk that DL data can be forwarded to RAN after the UE is released which means that this DL data needs to be buffered in RAN or discarded by RAN.

The UE CM state in the AMF after this indication from RAN differs. Solutions 1, 3 and 5 leave the AMF in CM-CONNECTED state, the AMF knows that the UE is not reachable due to long eDRX and can apply the same procedures specified for UE that is unreachable in CM-IDLE state. Solution 4 moves the AMF to CM-IDLE with RRC-Inactive where selected CM-IDLE state procedures are applicable. Solution 6 moves the AMF to new substate of CM-CONNECTED state where the AMF can apply the same procedures specified for UE that is unreachable in CM-IDLE state. Solution 2 can move the UE to CM-IDLE based on a RANs decision and allow the CN to buffer using the existing procedures, however the UE is no longer in RRC_Inactive.

The advantage of DL data buffering in UPF/SMF is that it has already been specified for 5G-CIoT devices. It is expected that the existing HLcom mechanism can be re-used for extended CN buffering.

The negative side is that enabling CN buffering would require RAN/CN interaction, exchanging 5- 6 messages every time the UE change RRC state from RRC-Connected to RRC-Inactive and 6 more messages every time the UE resumes to RRC-Connected. This RAN/CN signalling is independent of whether or not any DL data was sent to the UE.

7.2.2.2 RAN DL data buffering p. 36

RAN is specified from Rel-15 to buffer DL data when the UE is released to RRC-Inactive.

The advantage of having the DL data buffering in RAN is that this is legacy behaviour for a UE in RRC-Inactive. There is no RAN/CN interaction when the UE change RRC state between RRC-Connected - RRC-Inactive - RRC-Connected. Thus, extending this capability means extending the buffering capacity of RAN . Furthermore, Solution 2 allows a deployment where RAN decides whether to support extended buffering or not. If the RAN chooses to not support extended buffering, then CN buffering (HLcom) is used instead by releasing the UE to CM-IDLE state. In that case, the RAN informs the AMF. Solution 5 reuses existing RAN buffer capability(e.g. around 1.28 or 2.56s). When the RAN determines that it cannot buffer any more downlink data, it informs the AMF to start CN buffering. The CN is not impacted if the RAN receives very few downlink packets during the UE unreachable time.

The negative side with RAN buffering for a UE in RRC-Inactive is that legacy buffering is only for typically around 1.28 or 2.56s, which now will be extended to a much longer time. This may affect the accumulated amount of data to be buffered.

7.2.3 Mobile Terminated signalling p. 37

7.2.3.1 AMF aware of RRC-Inactive with long eDRX p. 37

Solution 1, 3 and 6 makes the AMF aware of the non-reachability in CM-Connected by the N2 message sent from RAN when the UE is released to RRC-Inactive with long eDRX. This allows the AMF to schedule DL NAS message considering the UE power save state in RAN. Solutions 1 and 3 expect the AMF to run a subset of idle mode procedures in CM-CONNECTED state. Solution 6 uses new CM-state in the AMF to run a subset of CM-IDLE state procedures in that new state.

Solution 4 allows the same behaviour but avoids violating CM-CONNECTED state design principles in the AMF by introducing a new state combination RRC-Inactive/CM-IDLE with behaviour that is a subset of the AMF CM-IDLE behaviour.

Solution 5 allows the same indication to be issued by the RAN only on event driven basis if there is DL NAS message towards the UE in long eDRX. The advantage of this approach is that if eDRX is configured for a UE and the RAN does not receive DL NAS message for the UE, then the AMF will never be aware that the UE is using long eDRX power saving. When the UE becomes reachable the RAN can trigger RAN paging without CN involvement. This may reduce the signalling latency.

7.2.3.2 AMF unaware of RRC-Inactive with long eDRX p. 37

In Solution 2 and 5 the AMF is unaware of that the UE is in RRC-Inactive state and may not be reachable for a DL NAS message. That may result in that the DL NAS message is sent towards the UE at a timing when the UE will not monitor POs until the NAS retransmission timer expires.

To handle this, solution 5 proposes that RAN sends a notification as a response to the DL NAS message informing the AMF about the UE power save. This is the event discussed in 7.2.2.1. The AMF may try again once the UE is reachable again. The UE remains in RRC-Inactive/CM-Connected state in the network.

To handle the above situation, solution 2 reuses the legacy RAN paging failure and RAN initiate the AN release procedure. The negative effect with using the RAN paging failure is that the UE is moved to CM-Idle in the CN and RRC-Idle in RAN, but the UE is still locally in RRC-Inactive/CM-Connected. When the UE tries to resume the RRC connection it will be rejected, and the UE will need to perform RRC establishment procedure followed by NAS Service Request if the UE has UL data to transmit.

7.2.4 UE mobility outside RNA without Xn reference point. p. 37

The UE will wake-up after the long eDRX and search for a suitable cell and resynchronize to the network. This will be done prior to the PTW. When the UE detects that it is outside the RNA it will perform RNA update due to mobility and the new RAN node will try to fetch the UE context based on the I-RNTI. If there is no Xn and the RAN node is unable to fetch the UE context the RAN node will reject the RRC Resume (RNAU) and the UE is moved to RRC-Idle. RAN does not inform the AMF about this. The UE will need to perform RRC establishment procedure followed by NAS Service Request if the UE has UL data to transmit. This is legacy behaviour and applies to all solutions.

For solutions 4 and 6 the above does not affect the handling of the buffered DL data as the DL data is buffered in the CN and the CN can use legacy CN paging after the initial RAN based paging in the old RAN node failed. Typically, the same applies to solution 1 and 3. This may cause additional signalling latency.

Solutions 1, 2, 3 and 5 may have buffered DL data in the old RAN node and this data will be lost if nothing is done to forward the data to the new RAN node. Solution 1 proposes that the handling of the buffered DL data is done based on implementation. Solution 2 and 3 propose to specify CN assisted UE context/DL data forwarding from the old RAN node to the new RAN node.

7.2.5 High Latency Communication with RRC-Inactive p. 38

In solution 1, 3, 4 and 6, RAN informs the AMF and triggers CN buffering every time the UE is released to RRC-Inactive with long eDRX, These solutions can support the specified HLcom features in clause 5.31.8 of TS 23.501 depending on if the extended buffering is done in the SMF or UPF. To support Downlink Data Delivery Status then the buffering needs to be done in the SMF. To support of UE Reachability and Availability after DDN failure notification buffering in the UPF is enough.

Solution 2 does not inform the AMF when the UE is released to RRC-Inactive when RAN handles the MT data/signalling, do not support the HLcom features as defined in clause 5.31.8 of TS 23.501 when the UE is in CM-Connected. In solution 5 the RAN may also decide to inform the AMF to start the CN MT data/signalling handling and after that the HLcom feature in the CN can be applied.

UE reachability notification can be supported even if the AMF is not informed about UE RRC state change. A solution that is based on that the AMF is aware of the negotiated long eDRX for CM-IDLE is described in Solution #2a in clause 6.2a.