Content for TR 23.700-68 Word version: 18.1.0

6.2 Solution #2: Long eDRX with RAN buffering 6.2.1 Introduction 6.2.2 Functional Description 6.2.3 Procedures 6.2.3.1 MT Signalling for UE in RRC-Inactive state with long eDRX. 6.2.3.2 MT Data for UE in RRC-Inactive state with long eDRX. 6.2.3.3 Procedure how to handle UE mobility outside the RNA. 6.2.4 Impacts on services, entities and interfaces 6.2a Solution #2a: Additional HLcom support for Solution 2 6.2a.1 Introduction 6.2a.2 Functional Description 6.2a.3 Procedures 6.2a.4 Impacts on services, entities and interfaces
...

6.2 Solution #2: Long eDRX with RAN buffering p. 11

6.2.1 Introduction p. 11

This solution relates the KI#1 and proposes a solution where RAN initiates either extended buffering of MT data or notification to the AMF for UE unavailability due to use of long eDRX in RRC-Inactive.

6.2.2 Functional Description p. 11

This solution addresses KI#1 and the following principles are used:

Allow eDRX >10,24s for RRC-Inactive.
RAN anchor node configures the UE with eDRX value and PTW to be used during RRC-Inactive when releasing the UE to RRC-Inactive.
- The CM idle mode eDRX and PTW configuration are provided to NG-RAN in the RRC Inactive Assistance Information as described in TS 23.501 and TS 38.413.
RAN is responsible for paging and will apply RAN paging strategy considering the UE PTW configuration.
RAN either buffers MT data if it finds it feasible or triggers the UE context release (N2 msg).

NOTE 1:
The N2 message could be the UE Context Release Request message which RAN use to notify the AMF of RAN paging failure. The message may need to be extended to include that the failure was due to eDRX configuration. TSG RAN3 is responsible for N2 messages and their format.
If MT NAS message can't be delivered to the UE within the NAS retransmission timer range i.e. <10.24s), then RAN triggers the UE context release (N2 msg - UE context release request), with cause value indicating that the UE is not currently reachable for MT signalling.

NOTE 2:
The N2 message used to deliver the failure could be the UE Context Release Request message which RAN use to notify the AMF of RAN paging failure. The message may need to be extended to include that the failure was due to eDRX configuration. Sending an N2 notification instead of UE Context release request could be an alternative to prevent that the UE is moved to CM-Idle state in the AMF. TSG RAN3 is responsible for N2 messages and their format.
As long as the RAN has not initiated UE context release, the Core Network behaves as in CM-CONNECTED state as specified in TS 23.501.
This solution is based on extensive re-use of the existing procedures and therefore assumes HLcom procedures in CM-IDLE state. The support of HLcom in CM-CONNECTED state can be studied in separate solution and if found to be feasible, such solution is expected to be compatible with this solution.
After the UE context release, the Core network moves to CM-IDLE state, where it can initiate HLcom procedures, see clause 5.31.8 of TS 23.501.

NOTE 3:
The Support of HLcom feature in CM-IDLE depends on AMF and SMF supports the corresponding HLcom features as the support of HLcom feature is optional for the network. The AMF selection is done during the registration procedure and could be based on a combination of request for long eDRX and the 'NR RedCap indication' provided by RAN as specified in rel-17.

RAN is responsible for RAN based paging within a RAN Notification Area (RNA). Long eDRX may increase the possibility that the UE has moved outside the RNA and possibly further away from the RNA. It is proposed that UE mobility and buffered MT data in the old RAN anchor Node should be handled based on the following principles:

If the new gNB, inside or outside the RNA, has an Xn interface between the old RAN anchor node and the new gNB, then the new gNB can retrieve the UE context (as specified in TS 38.413) and also retrieve the MT data that has been buffered in the old gNB and delivers the data to the UE.
If the new gNB is outside the RNA and has NOT an Xn interface between the new gNB and old RAN anchor node, the new gNB is not able to retrieve the UE context and extended buffered Data from the old RAN anchor node. To avoid systematic failure to deliver the extended buffered data to the UE, it is proposed that the new gNB can request assistance from the Core Network in retrieving the UE context and extended buffered data.

NOTE 4:
UE context retrieval via CN needs to be coordinated with RAN WGs
In addition to the new gNB requesting assistance to retrieve the buffered data, the old gNB may request the AMF to escalate the paging in a wider area. The old RAN node may include, in the N2 message, how many POs that remains in the PTW.

NOTE 5:
To make efficient use of this alternative, the N2 message should be sent while there are POs remaining in the PTW.

6.2.3 Procedures p. 13

6.2.3.1 MT Signalling for UE in RRC-Inactive state with long eDRX. p. 13

Reproduction of 3GPP TS 23.700-68, Fig. 6.2.3.1-1: MT signalling for UE is in RRC-Inactive with long eDRX

Figure 6.2.3.1-1: MT signalling for UE is in RRC-Inactive with long eDRX

Step 0.

UE is in RRC-Inactive/CM-Connected state configured by the RAN node to apply long eDRX in RRC-Inactive Inactive and the AMF is in CM-CONNECTED state as specified in clause 5.3.3.2.5 of TS 23.501.

Step 1.

The AMF send NAS message towards the UE.

Step 2.

The RAN node determines when the UE will become reachable next time according to the eDRX scheme. If the UE will become reachable before NAS retransmission timer expires, then the RAN may buffer the NAS message and page the UE and deliver the NAS message to the UE according to step 6.

Step 3.

[Conditional] If the RAN node determines e.g. based on awareness that the UE will not become reachable before the NAS retransmission timer expires, it indicates failure to deliver the NAS message.

Step 4.

The AMF releases the UE context and moves to CM-IDLE state.

Step 5.

Optional: Following the CM-IDLE state procedures, the AMF may retransmit the NAS message in conjunction to the next PTW. This step includes CN paging prior to sending the NAS message to the RAN node.

Step 6.

RAN B pages the UE and delivers the MT NAS message.

6.2.3.2 MT Data for UE in RRC-Inactive state with long eDRX. p. 14

Reproduction of 3GPP TS 23.700-68, Fig. 6.2.3.2-1: MT data for UE is in RRC-Inactive with long eDRX

Figure 6.2.3.2-1: MT data for UE is in RRC-Inactive with long eDRX

Step 0.

UE is in RRC-Inactive/CM-Connected state configured by the RAN node to apply long eDRX in RRC-Inactive and the AMF is in CM-CONNECTED state as specified in clause 5.3.3.2.5 of TS 23.501.

Step 1.

MT Data for the UE is forwarded to the RAN node.

Step 2.

The RAN node determines when the UE will become reachable next time according to the eDRX scheme. The RAN may decide to buffer the DL data until next PTW, then the RAN will page the UE and deliver the DL data to the UE according to step 5.

Step 3.

[Conditional] If the RAN node determines that it is not able to buffer the MT data for the remaining eDRX cycle, it indicates failure to page the UE.

Step 4.

The AMF releases the UE context and moves the UE to CM-Idle state. RAN drops the MT data after receiving the UE Context Release message. Following the existing CM-IDLE state procedures, the AMF may escalate the paging to wider area. If the AMF is able to reach the UE by paging, then the AMF triggers data forwarding from the old RAN node to the new RAN node instead of sending the UE Context Release message to the old RAN node.

Step 5.

RAN pages the UE and delivers the DL data.

6.2.3.3 Procedure how to handle UE mobility outside the RNA. p. 15

Reproduction of 3GPP TS 23.700-68, Fig. 6.2.3.3-1: Procedure for handling UE mobility outside the RNA

Figure 6.2.3.3-1: Procedure for handling UE mobility outside the RNA

Step 0.

UE is in RRC-Inactive/CM-Connected state configured by the RAN node to apply long eDRX in RRC-Inactive and the AMF is in CM-CONNECTED state as specified in clause 5.3.3.2.5 of TS 23.501.

Step 1.

MT Data to the UE is forwarded to the old RAN node.

Step 2.

The UE detects that it is outside the configured RNA and send an RNA Update due to mobility to the new RAN node.

Step 3.

If the new RAN is not able to retrieve the UE context from the old RAN node e.g. due to lack of Xn interface, then the new RAN node will send a N2 message requesting assistance from the AMF to retrieve the UE context.

Step 4.

The AMF, based on the received UE temporary (i.e. I-RNTI which includes the ID of the old RAN node), tries to retrieve the UE context from the old RAN node. If the AMF is not able to retrieve the UE context, then the AMF responds to the new RAN node with a failure to do so. Based on this failure the new RAN node will reject the RNA Update due to mobility.

Step 5.

The AMF requests to retrieve the UE context from the old RAN node.

Step 6.

The Old RAN node forwards the UE context as a transparent container to the AMF and then the AMF forwards the UE context to the old RAN node

Step 7.

If the old RAN indicated to the AMF that the RAN has buffered data to the UE, then the AMF triggers data forwarding between the old RAN node and the new RAN node.

Step 8.

If the new RAN node received DL data, the new RAN node delivers the data to the UE before releasing the UE with new RNA configuration. The new RAN node also performs path switch procedure according to clause 4.9.1.2.2 of TS 23.502.

6.2.4 Impacts on services, entities and interfaces p. 16

UE:

Support eDRX and PTW in RRC-Inactive, i.e. new RRC-Release configuration for RRC-Inactive.

gNB:

Support sending failure indication to the AMF for UE unavailability due to long eDRX in RRC-Inactive.
Support extended buffering of MT data.
Support CN assisted AS UE context retrieval and data forwarding.
Optional: Provide the remaining number of POs in the PTW when failing to page the UE within the RNA.

AMF:

Support the indication of UE unavailability due to long eDRX in RRC-Inactive.
Support CN assisted AS UE context retrieval and data forwarding.

6.2a Solution #2a: Additional HLcom support for Solution 2 p. 16

6.2a.1 Introduction p. 16

This solution description is not a standalone solution, it is an extension to solution 2 to support the HLcom feature "UE Reachability" that would allow an AF to subscribe to a notification when the UE is reachable for DL data.

6.2a.2 Functional Description p. 16

As solution #2 with the following enhancements:

The HLcom feature "UE Reachability" can be supported in CM-CONNECTED state. To support "UE Reachability" feature the following enhancement is needed. When the AMF receives the event subscription as specified in clause 4.15.3.2.1 of TS 23.502 and the UE is in CM-CONNECTED state, the AMF checks the eDRX configuration for CM-IDLE in the UE context and provides an event notification to the AF via the NEF prior to the next reachability period based on the eDRX value stored in the UE context. It is assumed that RAN has configured the UE with eDRX value in RRC-Inactive which is a factor of the CM-IDLE value i.e. eDRX in RRC-Inactive = eDRX in CM-IDLE divided by N where N=1, 2, 3, ...

The other HLcom features "Availability after DDN failure" and "Downlink Data Delivery Status" as specified in clause 5.31.8 of TS 23.501 is not supported by this enhancement of solution 2.

6.2a.3 Procedures p. 16

As in Solution 2.

6.2a.4 Impacts on services, entities and interfaces p. 16

As in Solution 2 with the following additional impact.

AMF:

Support "UE Reachability" notification, when the AMF receives the event subscription as specified in clause 4.15.3.2 of TS 23.502 and the UE is in CM-CONNECTED state.