الصين Shenzhen Olax Technology CO.,Ltd أخبار الشركة

NETCONF is the full name of Network Configuration Protocol, which is a network management protocol that allows NMS (Network Management System) to issue, modify and delete the configuration of connected network devices (routers, eNodeB, gNodeB, DU, CU or RU). NETCONF is developed and standardized by IETF; while for O-RAN, it is under the responsibility of WG (Working Group 4).   1. The NETCONF protocol uses XML (Extensible Markup Language) data encoding to process configuration data and protocol messages; it is based on the concept of server and client and uses RPC (Remote Procedure Call) mechanism to achieve communication between server and client. The client process runs on the NMS, which can be a script or application, and the server is a typical network device.   2. The characteristics of NETCONF are as follows: It adopts a layered protocol framework, making it more suitable for on-demand, automated and cloud-based networks. It is used to issue, modify and delete configurations to network devices. XML (Extensible Markup Language) is used for data encoding of configuration data and protocol messages. Based on the server and client concept, the NMS acts as a client and the network device acts as a server. Communication between servers and clients is achieved using the RPC (Remote Procedure Call) mechanism. Operations are executed based on the YANG model, reducing network failures caused by manual configuration errors. NETCONF meets the needs of network automation. It provides security mechanisms such as authentication and authorization to ensure secure message transmission. It also provides transaction mechanisms, supporting data classification, storage and migration, phased commit, and configuration isolation. It supports comprehensive configuration delivery, verification, and rollback, minimizing the impact on network services. It allows vendors to define their own protocol operations to implement unique management capabilities.     3.Why is NETCONF needed? A key requirement of cloud networks is network automation for rapid, on-demand service provisioning and automated operations management. Traditional approaches such as CLI and SNM cannot meet this requirement. They have the following limitations, which NETCONF addresses.     31. Disadvantages of CLI: First, configuration is complex. Second, the following: CLIs vary by vendor, requiring users to learn and adapt CLI scripts for each vendor. CLI structure and syntax frequently change, making CLI scripts difficult to maintain. Command output is unstructured, unpredictable, and easily changeable, making automatic parsing of CLI scripts difficult.     3.2 Disadvantages of SNMP: SNMP does not support transactions, resulting in inefficient configuration. SNMP uses the User Datagram Protocol (UDP), which does not provide reliable, sequenced data transmission and lacks effective security mechanisms. SNMP lacks a mechanism for submitting configuration transactions. SNMP manages device configuration on a device-by-device basis and does not support network-level configuration or multi-device configuration collaboration.

  In the 5G system, a Path Switch Request (PATH SWITCH REQUEST) is a request for the terminal (UE) to establish a signaling connection with the 5GC and, if applicable, request the downlink of the NG-U transport bearer to be switched to a new service node. This request can fail for various reasons; 3GPP defines it in TS 38.413 as follows.   I. Path Request Operation Failure   As shown in Figure 8.4.4.3-1 below, a request failure is typically responded to by the AMF after the NG-RAN node issues a "PATH SWITCH REQUEST."       II. Request operation failure scenarios are typically as follows:   If the 5GC fails to switch the downlink termination point of the NG-U transport bearer to the new (service) termination point for all PDU session resources, the AMF shall send a PATH SWITCH REQUEST FAILURE message to the NG-RAN node.   The NG-RAN node shall release the corresponding QoS flows and consider the PDU Sessions indicated in the PDU Session Resource Release List IE contained in the PATH SWITCH REQUEST FAILURE message as released.   The corresponding cause value for each released PDU Session is contained in the Path Switch Request Unsuccessful Transfer IE in the PATH SWITCH REQUEST FAILURE message.   III. Requesting Abnormal Operations   If the AMF receives a message containing multiple PDU Session ID IEs set to the same value (in the PDU Session Resource to be Switched IE in the downlink list), the AMF shall send a PATH SWITCH REQUEST FAILURE message to the NG-RAN node. In addition,   As an exception, the AMF may generate a Path Switch Request Unsuccessful Transfer IE.   If a Partially Allowed NSSAI IE is received in a PATH SWITCH REQUEST ACKNOWLEDGE message, and the total number of S-NSSAIs contained in the Allowed NSSAI and Partially Allowed NSSAI exceeds 8, the NG-RAN node shall consider the procedure to have failed.   If any S-NSSAI present in the Partially Allowed NSSAI IE is also present in the Allowed NSSAI IE, the NG-RAN node shall consider the procedure to have failed.

RAN Status Transfer is the process of transferring a terminal (UE)'s uplink and downlink status information from a source radio access network (RAN) node to a target RAN node in a 5G network. This typically occurs during handover or dual connectivity scenarios. During this process, the AMF transmits information about downlink data (e.g., the number of forwarded packets), along with SN status and the PDCP (Packet Data Convergence Protocol) sequence number and hyperframe number (HFN) status for both uplink and downlink data, to the target RAN.   I. Uplink RAN ​​Status Transfer aims to enable lossless handovers over NG-RAN. The transfer process uses UE-related signaling. The specific process is shown in Figure 8.4.6.2-1 below, where:   The source NG-RAN node initiates this process by stopping allocating PDCP SNs for downlink SDUs and sending an UPLINK RAN STATUS TRANSFER message to the AMF when it deems the transmitter/receiver status frozen. For each DRB for which PDCP-SN and HFN status preservation is applicable, the source NG-RAN node shall include the DRB ID IE, UL COUNT IE, and DL COUNT IE in the DRB Subject Status Transfer List IE within the RAN Status Transfer Transparent Container IE of the UPLINK RAN STATUS TRANSFER message. For each DRB for which the source NG-RAN node has accepted an uplink forwarding request from the target NG-RAN node, the source NG-RAN node may also include the missing and received uplink SDUs in the UL PDCP SDUs IE of the UPLINK RAN STATUS TRANSFER message.   II. Downlink RAN ​​Status Transfer aims to implement NG-RAN-based lossless handover transfer procedures using UE-related signaling. The specific process is shown in Figure 8.4.7.2-1 below, where:     The AMF initiates this procedure by sending a DOWNLINK RAN STATUS TRANSFER message to the target NG-RAN node. The target NG-RAN node performing this handover according to TS 38.300 and using a full configuration shall ignore the information received in this message. For each DRB in the RAN Status Transfer Transparent Container IE that is subject to the State Transfer List IE, the target NG-RAN node shall not transmit any uplink data packet with a PDCP-SN lower than the value of the UL Count Value IE. For each DRB in the RAN Status Transfer Transparent Container IE that is subject to the State Transfer List IE, the target NG-RAN node shall use the value of the DL COUNT Value IE of the first downlink data packet that has not yet been assigned a PDCP-SN. If at least one DRB in the RAN Status Transfer Transparent Container IE of the DOWNLINK RAN STATUS TRANSFER message contains the receive status of the UL PDCP SDUs IE, the target NG-RAN node may use it in status report messages sent to the UE over the radio interface.

  The purpose of the PATH SWITCH REQUEST process is to establish a UE-related signaling connection with the 5GC and, if applicable, request that the downlink termination point of the NG-U transport bearer be switched to a new termination point. 3GPP defines the relevant processes of 5G in TS38.413 after enabling IAB, slicing, positioning and ranging technologies as follows;   I. IAB Authorization Processing   If the PATH SWITCH REQUEST ACKNOWLEDGE message contains the IAB Authorization IE, the NG-RAN node (if supported) shall store the received IAB authorization information in the UE context and use it as specified in TS 38.401.   If the PATH SWITCH REQUEST ACKNOWLEDGE message contains the Mobile IAB Authorization IE, the NG-RAN node (if supported) shall store the received Mobile IAB authorization status in the UE context of the Mobile IAB-MT. If the Mobile IAB Authorization IE of the Mobile IAB-MT is set to "Unauthorized," the NG-RAN node (if supported) shall ensure that the Mobile IAB node does not serve any UE.   II. NSSAI and Ranging and Positioning   If the "Partially Allowed NSSAI" IE is included in the Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) message, the NG-RAN node (if supported) shall infer the partially allowed network slice for the UE from it, store and replace any previously received "Partially Allowed NSSAI," and use it as specified in TS 23.501.   If the "Ranging and Sidetrack Location Service Information" IE is included in the Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) message, the NG-RAN node (if supported) shall update the UE's ranging and sidetrack location service information accordingly. If the "Ranging and Sidetrack Positioning Authorization" IE in the Ranging and Sidetrack Positioning Service Information IE is set to "Unauthorized," the NG-RAN node (if supported) should take steps to ensure that the UE no longer has access to ranging and sidetrack positioning services.   III. RRC Inactive Transition Report Procedure   If the RRC Inactive Transition Report Request IE is included in the Path Switch Request Acknowledgement message and is set to "Single RRC Connection Status Report," and the UE is in the RRC_CONNECTED state, the NG-RAN node (if supported) should send an RRC Inactive Transition Report message to the AMF to report the UE's RRC status.   If the RRC Inactive Transition Report Request IE is included in the PATH SWITCH REQUEST ACKNOWLEDGE message and is set to "Single RRC Connection Status Report", and the UE is in RRC_INACTIVE state, the NG-RAN node shall (if supported) send an RRC Inactive Transition Report message to the AMF, and a subsequent RRC Inactive Transition Report message upon RRC state transition to RRC_CONNECTED.   If the RRC Inactive Transition Report Request IE is included in the PATH SWITCH REQUEST ACKNOWLEDGE message and is set to "Subsequent State Transition Report", the NG-RAN node shall (if supported) send an RRC INACTIVE TRANSITION REPORT message to the AMF to report the UE's RRC status, and a subsequent RRC INACTIVE TRANSITION REPORT message to report the UE's RRC status upon the UE entering or leaving RRC_INACTIVE state.   IV. PDU Session Resource Notification Procedure   If the Path Switch Request Acknowledge Transfer IE of the PATH SWITCH REQUEST ACKNOWLEDGE message contains QoS-related parameters (e.g., CN Packet Delay Budget Downlink IE or CN Packet Delay Budget Uplink IE), but the NG-RAN node is unable to successfully accept the parameters, the NG-RAN node shall continue to use the old values ​​(if any) received from the source NG-RAN node. If supported, the NG-RAN node shall notify the AMF by sending a PDU SESSION RESOURCE NOTIFY message.    

  The purpose of the handover path request process is to establish the relevant signaling connection between the terminal (UE) and the 5GC and, if applicable, request the downlink termination point of the NG-U transport bearer to be switched to a new termination point. For the handover of UE-related services in the PC5 interface in Sildlink, 3GPP defines it in TS38.413 as follows;   I. PC5 QoS Processing The path request in handover of the PC5 interface in Sildlink is defined as follows;   If the Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) message contains the PC5 QoS parameter IE, the NG-RAN node shall (if supported) use it as defined in TS 23.287. If the Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) message contains the A2X PC5 QoS parameter IE, the NG-RAN node shall (if supported) use it as defined in TS 23.256. If the Path Switch Request Acknowledge message includes the Alternate QoS Parameter Set List IE, the NG-RAN node shall (if supported) use it as specified in TS 23.502. II. Path Request in CE-mode-B and User Plane CIoT Handover is defined as follows:   If the Path Switch Request Acknowledge message includes the CE-mode-B Restriction IE, the Enhanced Coverage Restriction IE is not set to "restricted", and the Enhanced Coverage Restriction information stored in the UE context is not set to "restricted", the NG-RAN node shall (if supported) store this information in the UE context and use it as defined in TS 23.501. If the Path Switch Request Acknowledge message includes the UE User Plane CIoT Support Indicator IE, the NG-RAN node shall (if supported) store this information in the UE context and assume that the UE supports User Plane CIoT 5GS Optimization as specified in TS 23.501. If the Path Switch Request Acknowledge message includes the UE Radio Capability ID IE, the NG-RAN node shall (if supported) use it as specified in TS 23.501 and TS 23.502. III. PDU Session Expected UE Activity and Path Request in MDT Handover are defined as follows: For each PDU Session, if the PATH SWITCH REQUEST ACKNOWLEDGE message includes the "PDU Session Expected UE Activity Behavior" IE, the NG-RAN node shall (if supported) process this information as specified in TS 23.501. If the PATH SWITCH REQUEST ACKNOWLEDGE message includes the "Management-Based MDT PLMN List" IE, the NG-RAN node shall store it in the UE context and, if supported, use this list to allow subsequent selection of the UE for management-based MDT as defined in TS 32.422. If the PATH SWITCH REQUEST ACKNOWLEDGE message includes the "Management-based MDT PLMN Modification List" IE, the NG-RAN node (if supported) shall use this list to overwrite any previously stored management-based MDT PLMN list information in the UE context and use the received information to allow subsequent selection of the UE for management-based MDT as defined in TS 32.422. If the PATH SWITCH REQUEST ACKNOWLEDGE message includes the Time Synchronisation Assistance Information IE, the NG-RAN node (if supported) shall store this information in the UE context and use it as defined in TS 23.501. IV. Path Request in 5G ProSe Handover is defined as follows: If the PATH SWITCH REQUEST ACKNOWLEDGE message includes the 5G ProSe Authorized IE, the NG-RAN node (if supported) shall update its ProSe authorization information for the UE accordingly. If the 5G ProSe Authorization Information (5G ProSe Authorized IE) contains one or more IEs set to "Unauthorized," the NG-RAN node (if supported) should take steps to ensure that the UE no longer has access to the associated 5G ProSe services. If the 5G ProSe PC5 QoS Parameters IE is included in the PATH SWITCH REQUEST ACKNOWLEDGE message, the NG-RAN node (if supported) should use it as defined in TS 23.304. If the Aerial UE Subscription Information IE is included in the PATH SWITCH REQUEST ACKNOWLEDGE message, the NG-RAN node (if supported) should store this information or overwrite any previously stored information in the UE context and use it as defined in TS 38.300. If the 5G ProSe UE PC5 Aggregate Maximum Bit Rate IE is included in the PATH SWITCH REQUEST ACKNOWLEDGE message, the NG-RAN node shall (if supported) perform the following actions: Replace the previously provided 5G ProSe UE PC5 Aggregate Maximum Bit Rate (if available in the UE context) with the received value; Use the received value for sidelink communications for the associated UE in the network scheduling mode for the 5G ProSe service.

  1. Network slicing divides a network into independent use cases, each tailored to provide specialized services. In the traditional 4G (LTE) era, APN (Access Point Names) were the first form of network slicing in mobile networks, allowing operators to partition their networks based on service requirements.   2. 5G network slices, defined by 3GPP, feature independent network instances with independent control and user plane processing. These slices require support from the 5G Core Network (5GC), which is only used in 5G with Standalone Architecture (SA).   3. Network Elements and Identifiers: Slicing deployments in 5G include network functions such as the user equipment (UE), next-generation radio access network (NG-RAN), control plane functions (e.g., AMF, PCF, SMF), and user plane functions (e.g., UPF). Each network slice is identified by an S-NSSAI (Slice Service Type), which includes a Slice Service Type (SST) to indicate the service to which the network slice applies. Network operators can use standardized SST values ​​such as: 1 for enhanced mobile broadband, 2 for ultra-reliable low-latency communications, 3 for massive IoT, 4 for vehicle-to-everything (V2X), 5 for high-performance machine-type communications. They can also use locally defined, non-standardized SST values.   4. Terminal Network Slicing Support: For SA (standalone) 5G terminals (UEs) configured with the USRP (UE Routing Policy), they can select S-NSSAI for network slicing (services) based on the desired application (depending on the application's quality of service requirements). For example, Samsung's first Galaxy S24 Ultra equipped with the URSP enables slice selection and service execution within the 5G system.   5. System Network Slicing Support: ADC (Detection and Control) is enabled (a function within the 5G core network elements PCF (Policy Control Function) and SMF (Session Management Function)). ADC is used to identify applications or traffic on the network side, apply policies such as quality of service, billing, or redirection, and implement real-time traffic classification and prioritization.   6. Network Slicing Commercial Deployment Examples: Singapore Telecommunications (Singtel) has launched Singtel 5G+, an advanced "network slicing" innovation that delivers a new standard of connectivity and a prioritized experience through three key features: Singtel 5G+: The only network using the 700MHz spectrum band, delivering optimal nationwide coverage, even indoors. Singtel 5G+ Ehanced: Wider coverage and faster speeds, with consistently up to 2x speeds. Singtel 5G+ Priority: Prioritized network channels with 4x faster speeds, always prioritizing services and detecting emerging

3GPP defines the following in TS 38.413 regarding enhanced coverage restriction, extended connection time, V2X service authorization, and handover path request processing for sidelink aggregation terminals in the 5G system:   I. Enhanced Coverage Restriction and Extended Connection Time   If the Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) message includes the Enhanced Coverage Restriction IE, the NG-RAN node SHOULD (if supported) store this information in the UE context and use it as defined in TS 23.501.   If the Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) message includes the Extended Connected Time IE, the NG-RAN node SHOULD (if supported) use it as defined in TS 23.501.   If the Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) message includes a UE Differentiation Information IE, the NG-RAN node (if supported) should store this information in the UE context for further use in accordance with TS 23.501.   II. NR V2X Service Authorization   If the PATH SWITCH REQUEST ACKNOWLEDGE message includes an NR V2X Service Authorization IE, the NG-RAN node (if supported) should update its NR V2X service authorization information for the UE accordingly.   If the NR V2X Service Authorization IE includes one or more IEs set to "Unauthorized," the NG-RAN node (if supported) should take steps to ensure that the UE no longer has access to the associated services.   If the PATH SWITCH REQUEST ACKNOWLEDGE message includes an LTE V2X Service Authorization IE, the NG-RAN node (if supported) should update its LTE V2X service authorization information for the UE accordingly.If the LTE V2X Service Authorization IE contains one or more IEs set to "Unauthorized," the NG-RAN node (if supported) should take measures to ensure that the UE no longer has access to the associated services.   If the NR A2X Service Authorization IE contains one or more IEs set to "Unauthorized," the NG-RAN node (if supported) should take measures to ensure that the UE no longer has access to the associated services.   If the Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) message contains an LTE A2X Service Authorization IE, the NG-RAN node (if supported) should update its LTE A2X Service Authorization information for the UE accordingly.   If the LTE A2X Service Authorization IE contains one or more IEs set to "Unauthorized," the NG-RAN node (if supported) should take measures to ensure that the UE no longer has access to the associated services.   III. Sidelink and Aggregation Processing   If the PATH SWITCH REQUEST ACKNOWLEDGE message contains the NR UE Sidelink Aggregate Maximum Bit Rate IE, the NG-RAN node (if supported) shall perform the following operations: Replace the previously provided UE Sidelink Aggregate Maximum Bit Rate (if available in the UE context) with the received value; Use the received value for sidelink communications with the associated UE in NR V2X serving network scheduling mode.   If the PATH SWITCH REQUEST ACKNOWLEDGE message contains the LTE UE Sidelink Aggregate Maximum Bit Rate IE, the NG-RAN node (if supported) shall perform the following operations: Replace the previously provided UE Sidelink Aggregate Maximum Bit Rate (if available in the UE context) with the received value; Use the received value for sidelink communications with the associated UE in LTE V2X serving network scheduling mode. If the PATH SWITCH REQUEST ACKNOWLEDGE message includes the NR A2X UE PC5 aggregate maximum bit rate IE, the NG-RAN node (if supported) shall perform the following operations: Replace the previously provided NR A2X UE PC5 aggregate maximum bit rate (if available in the UE context) with the received value; In network-scheduled mode, use the received value for NR A2X service sidelink communications for the associated UE. If the PATH SWITCH REQUEST ACKNOWLEDGE message includes the LTE A2X UE PC5 aggregate maximum bit rate IE, the NG-RAN node (if supported) shall perform the following operations: Replace the previously provided LTE A2X UE PC5 aggregate maximum bit rate (if available in the UE context) with the received value; In network-scheduled mode, use the received value for LTE A2X service sidelink communications for the associated UE.

  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.

In 5G, a path request is a signaling message sent by the target base station to the core network during handover to redirect the path of the terminal (data) session. TS 38.413 defines the following:   I. PDU Session Setup Failures   If any PDU session setup fails, the list of failed sessions shall be included within the “Path Switch Request Setup Failure Transport IE” in the PATH SWITCH REQUEST message. The AMF shall process this information as specified in TS 23.502.   2. User Security and Path Information   For each PDU session, if its "additional redundant DL QoS flow information IE for each TNL" is included in the PATH SWITCH REQUEST Transfer IE of the Path Switch Request message, Then the SMF can use each included UP transport layer information as the downlink termination point for the associated QoS flows contained in this PDU session, and these QoS flows are split into different tunnels for redundant transmission. For each PDU session, if the Path Switch Request Transfer IE of its "Path Switch Request" message contains "Redundant DL NG-U TNL information Reuse IE", then the SMF should (if supported) treat the included DL transport layer address as the DL transport layer address for redundant transfer. As described in TS 23.501. For each PDU session, if the Path Switch Request Transfer IE of its "Path Switch Request" message contains the "Global RAN Node ID of the auxiliary NG-RAN node" IE, the SMF should (if supported) handle this information as stipulated in TS 23.501. For each PDU session contained in the PATH SWITCH REQUEST message, if the "Path Switch Request Transmission IE" contains the "Current QoS Parameter Set Index IE", the SMF should treat it as the currently implemented QoS parameter set among the alternative QoS parameters of the involved QoS flow. The NG-RAN node should (if supported) report the processing indicator IE based on the PDU set in the "PATH SWITCH REQUEST Transmission IE" in the Path Switch Request message. If the "PATH SWITCH REQUEST Transfer IE" in the Path Switch Request message contains a processing indicator IE based on the PDU set, the SMF should (if supported) handle this information as stipulated in TS 23.501. If the "PATH SWITCH REQUEST Transport IE" in the Path Switch Request message contains the MBS support indicator IE, then the SMF should (if supported) handle this information as stipulated in TS 23.247. If supported, the NG-RAN node should report the PATH SWITCH REQUEST transmission of the ECN tag in IE or congestion information report status IE in the Path Switch Request message. If the ECN tag or congestion information reporting status IE is included in the PATH SWITCH REQUEST Transport IE of the Path switch Request message, the SMF should (if supported) use it to infer whether the ECN tag at NG-RAN, the ECN tag at UPF, or congestion information reporting is active. As described in TS 23.501.   3. Upstream Data Processing   If the PATH SWITCH REQUEST ACKNOWLEDGE Transfer IE of the Path Switch Request Acknowledge message contains UL NG-U UP TNL Information IE Then the NG-RAN node should store this information and use it as the uplink termination point for the user plane data of this PDU session. If the PATH SWITCH REQUEST ACKNOWLEDGE Transfer IE of the Path Switch Request Acknowledge message contains additional NG-U UP TNL Information IE, Then the NG-RAN node should store this Information and use the UL NG-U UP TNL Information IE contained therein as the uplink termination point for the user plane data of this PDU session (split into different tunnels). If the PATH SWITCH REQUEST ACKNOWLEDGE transmission IE of the path switch request acknowledge message contains redundant UL NG-U UP TNL information IE, the NG-RAN node should (if supported) store this information. And use it as the uplink termination point of the user plane data for the redundant transmission of this PDU session, as described in TS 23.501. If the PATH SWITCH REQUEST ACKNOWLEDGE transmission IE of the path switch Request acknowledge message contains additional redundant NG-U UP TNL information IE, the NG-RAN node should (if supported) store this information. And use the included UL NG-U UP TNL information IE as the uplink termination point for the user plane data split in different tunnels of this PDU session

Similar to the previous generation 4G (LTE) systems, the Path Switch Request is a signaling message sent by the target base station to the core network during handover to redirect the (user) data path of the terminal's (packet data) session. This message initiates a process where the session management unit instructs the user plane to change the downlink data endpoint from the old site (source) to the new site, ensuring uninterrupted data flow to the user's new location.   I. Path Switch Request In 5G, the path request process establishes a terminal (UE)-related signaling connection with the 5GC and, where applicable, requests switching the downlink terminal point of the NG-U transport bearer to a new terminal point. This process utilizes UE-related signaling.   II. Path Request Process As illustrated in Figure 8.4.4.2-1 below, the “PATH SWITCH REQUEST” is initiated by the target NG-RAN node to the AMF. Its specific definition is as follows: The NG-RAN node initiates the process by sending a Path Switch Request (PATH SWITCH REQUEST) message to the AMF. Upon receiving the PATH SWITCH REQUEST message, the AMF shall transparently transfer the Path Switch Request Transfer IE to the SMF associated with each PDU session indicated in the PDU Session ID IE. Upon receiving the PATH SWITCH REQUEST message, the AMF shall deactivate the activated MT communication processing as described in TS 23.502.   III. Path Request Message Processing If the PATH SWITCH REQUEST message contains an RRC Resume Cause IE, the AMF shall (if supported) use it in accordance with the user plane CIoT 5GS optimization provisions for NG-RAN nodes acting as ng-eNBs specified in TS 23.502. If the PATH SWITCH REQUEST message contains a RedCap Indicator IE or eRedCap Indicator IE, the AMF shall (if supported) treat the UE as a RedCap UE or eRedCap UE previously served by an E-UTRA cell, respectively, and use this IE according to TS 23.501. After all necessary updates (including uplink path switching) are successfully completed in the 5GC, the AMF shall send a Path Switch Request Acknowledge message to the NG-RAN node for at least one PDU session resource included in the Path Switch Request. The process then terminates.   IV. PDU Session Handling For an IAB-MT or mobile IAB-MT where the PDU session ID IE in the PATH SWITCH REQUEST message indicates an unassigned PDU session identifier (as defined in TS 24.007), the AMF shall (if supported) consider the IAB-MT or mobile IAB-MT to lack a PDU session and proceed as specified in TS 23.501. Subsequently, the NG-RAN node shall (if supported) ignore the PDU Session Resource Switched List IE in the Path Switch Request Acknowledge message. For each PDU session where the Path Switch Request Transfer IE within the Path Switch Request message contains an Additional DL QoS Flow per TNL Information IE, The SMF can use each included uplink transport layer information as the downlink termination point for the associated QoS flows split across different tunnels for this PDU session.