5G (NR) RAN Learning - Path Request During Handover(2)

In a 5G system, a handover path request is a request by a terminal (UE) to establish a UE-related signaling connection with the 5GC and, if applicable, request that the NG-U transport bearer downlink termination point be switched to a new termination point. As 5G supports an increasing number of service types, the content of path requests during handovers will become increasingly complex. 3GPP defines this in TS 38.413 as follows.

I. Packet Delay Budget

• If the CN Packet Delay Budget Downlink IE is included in the Path Switch Request Acknowledge Transport IE of the Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) message, the NG-RAN node SHOULD (if supported) replace the previously provided CN Packet Delay Budget Downlink (if any) and use it as specified in TS 23.502.

• If the CN Packet Delay Budget Uplink IE is included in the Path Switch Request Ack Transport IE of the Path Switch Request Ack No WLEDGE message, the NG-RAN node shall (if supported) replace the previously provided CN Packet Delay Budget Uplink (if any) and use it as specified in TS 23.502.

II. Burst Data Handling

If the Burst Arrival Time Downlink IE is included in the Path Switch Request Ack Transport IE of the Path Switch Request Ack message, the NG-RAN node shall (if supported) replace the previously provided value (if any) and use it as specified in TS 23.502.

III. RRC Inactive and Core Network Assistance Information Handling

• If the Core Network Assistance Information of the RRC INACTIVE IE is included in the Path Switch Request Confirmation message, the NG-RAN node (if supported) shall store this information in the UE context and use it for RRC_INACTIVE state decisions and the UE's RNA configuration and RAN paging (if any), as described in TS 38.300.

• If the Core Network Assistance Information of the RRC INACTIVE IE includes the MICO All PLMN IE, the NG-RAN node (if supported) shall treat the UE's registration area as the complete PLMN and ignore the TAI list of the RRC Inactive IE.

• If the Core Network Assistance Information of the RRC INACTIVE IE includes the Paging Cause Indication of the Voice Service IE, the NG-RAN node (if supported) shall store and use it as specified in TS 38.300.

• If the Core Network Assistance Information of the RRC INACTIVE IE includes the PEIPS Assistance Information IE, the NG-RAN node (if supported) shall store it and use it for paging subgroups of UEs in the RRC_INACTIVE state, as described in TS 38.300.

• If the CN MT Communication Handling IE is included in the Core Network Assistance Information (RRC INACTIVE IE), the NG-RAN node shall (if supported) store this IE and may subsequently request the CN to perform MT communication handling, as described in TS 23.502, depending on the implementation.

• If the CN Assisted RAN Parameter Adjustment IE is included in the Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) message, the NG-RAN node may use this IE as described in TS 23.501.

• If the RRC INACTIVE Transition Report Request IE is included in the Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) message, the NG-RAN node shall (if supported) store this information in the UE context.

V. EPS and SRVCC Processing

• If the PATH SWITCH REQUEST ACKNOWLEDGE message includes the Redirection for Voice EPS Fallback IE, the NG-RAN node shall (if supported) store this IE and use it in subsequent voice EPS fallback decisions as specified in TS 23.502.

• If the PATH SWITCH REQUEST ACKNOWLEDGE message contains the SRVCC Operation Possible IE information, the NG-RAN node shall (if supported) store the received SRVCC Operation Possible IE content in the UE context and use it as defined in TS 23.216.