China Shenzhen Olax Technology CO.,Ltd Company News

I.Carrier Aggregation: Similar to LTE, 5G (NR) carrier aggregation also increases the wireless spectrum bandwidth used by UEs by combining multiple carriers. Each aggregated carrier is called a component carrier (CC). In 5G (NR), UEs can support up to 16 contiguous and non-contiguous component carriers (CCs) with different numerologies in both FR1 and FR2 bands. Carrier aggregation configurations include: carrier aggregation type (intra-band, contiguous/non-contiguous, or inter-band), number of frequency bands, and bandwidth class.   II. Bandwidth Class: The carrier aggregation bandwidth class of a terminal (UE) is defined using an alphabetical list of minimum and maximum bandwidths and the number of component carriers it can use. Key parameters include: 5G ​​(NR) terminals support up to 16 contiguous and non-contiguous component carriers (CCs) with different parameter sets when CA is enabled. The bandwidth class of a terminal (UE) is an alphabetical list of minimum and maximum bandwidths and the number of component carriers (CCs). According to Release 17, carrier aggregation classes in FR1 range from A to O, allowing a maximum aggregated bandwidth of 400 MHz. According to Release 17, carrier aggregation classes in FR2 range from A to Q, allowing a maximum aggregated bandwidth of 800 MHz.   III. Carrier Aggregation FR1 Bandwidth Class Category A: 5G UEs are configured without carrier aggregation. The maximum carrier frequency band (BWChannel, max) is determined by the frequency band number and parameter set, which defines the subcarrier frequency spacing (SCS). Class A belongs to all fallback groups and allows UEs to revert to this configuration even when carrier aggregation is not in place. Category B: Aggregating two radio channels, the total available bandwidth for UEs is between 20 and 100 MHz. Category C: Aggregating two radio channels, the total available bandwidth for UEs is between 100 and 200 MHz. Category D: Aggregating three radio channels, the total available bandwidth for UEs is between 200 and 300 MHz. Category E: Aggregating four radio channels, the total available bandwidth for UEs is between 300 and 400 MHz. Classes C, D, and E belong to the same fallback group (Fallback Group 1). Category G: Aggregating three radio channels, the total available bandwidth for UEs is between 100 and 150 MHz. Category H:aggregates four radio channels, providing a total bandwidth of 150-200 MHz available to the user equipment (UE). Category I:aggregates five radio channels, providing a total bandwidth of 200-250 MHz available to the user equipment (UE). Class J aggregates six radio channels, providing a total bandwidth of 250-300 MHz available to the user equipment (UE). Class K:aggregates seven radio channels, providing a total bandwidth of 300-350 MHz available to the user equipment (UE). Class L:aggregates eight radio channels, providing a total bandwidth of 350-400 MHz available to the user equipment (UE).  Classes G-L belong to the same fallback group (Fallback Group 2).   IV. Carrier Aggregation FR2 Bandwidth Class Category A is a 5G configuration for UEs without carrier aggregation. The maximum carrier frequency band (BWChannel, max) depends on the band number and numerology. Class A belongs to all fallback groups and allows UEs to fall back to this configuration even without carrier aggregation. Category B corresponds to the total bandwidth after aggregation of two radio channels, ranging from 400MHz to 800MHz. Category C corresponds to the total bandwidth after aggregation of two radio channels, ranging from 800MHz to 1200MHz. Class B is a fallback configuration for Class C; both belong to the same Fallback Group 1 fallback list. Category D corresponds to the total bandwidth after aggregation of two radio channels, ranging from 200MHz to 400MHz. Category E corresponds to the total bandwidth after aggregation of three radio channels, ranging from 400MHz to 600MHz. Category F corresponds to the total bandwidth after aggregation of four radio channels, ranging from 600MHz to 800MHz. Classes D, E, and F belong to the same Fallback Group 2 fallback list. Class G corresponds to two radio channel aggregations with a total bandwidth between 100 MHz and 200 MHz. Class H corresponds to three radio channel aggregations with a total bandwidth between 200 MHz and 300 MHz. Class I corresponds to four radio channel aggregations with a total bandwidth between 300 MHz and 400 MHz. Class J corresponds to five radio channel aggregations with a total bandwidth between 400 MHz and 500 MHz. Class K corresponds to six radio channel aggregations with a total bandwidth between 500 MHz and 600 MHz. Class L corresponds to seven radio channel aggregations with a total bandwidth between 600 MHz and 700 MHz. Class M corresponds to eight radio channel aggregations with a total bandwidth between 700 MHz and 800 MHz. Classes G, H, I, J, K, L, and M belong to the same Fallback Group 3 fallback list.

    I. Downlink NAS Transport Scenario In the 5G system, the downlink NAS transport process is used when the AMF needs to transparently send NAS messages to the UE via the NG-RAN node and there is a logical NG connection associated with the UE, or the AMF has received the RAN UE NGAP ID IE in the INITIAL UE MESSAGE message, or the NG-RAN node has sent the INITIAL UE MESSAGE message through another NG interface instance to start a logical NG connection associated with the UE.   II. NAS Transport Content Processing In addition to the content in 5G System Learning - Downlink NAS Transport, other downlink NAS content is processed as follows;   If the DOWNLINK NAS TRANSPORT message contains 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. If the DOWNLINK NAS TRANSPORT message contains the Target NSSAI Information IE, the NG-RAN node may use this information as specified in TS 23.501. If the DOWNLINK NAS TRANSPORT message contains a Partially Allowed NSSAI IE, the NG-RAN node (if supported) shall infer the UE's partially allowed network slice from it, store and replace any previously received Partially Allowed NSSAI, and use it as specified in TS 23.50. If the DOWNLINK NAS TRANSPORT message contains a Masked IMEISV IE, the NG-RAN node (if supported) shall use it to determine the UE's characteristics for subsequent processing. If the Downlink NAS Transport message contains a Mobile IAB Authorization IE, the NG-RAN node (if supported) shall store the received Mobile IAB Authorization status in the UE context. If the Mobile IAB Authorization IE is set to "Unauthorized" for Mobile IAB-MT, the NG-RAN node (if supported) shall ensure that no UE is served by this Mobile IAB node. 3. During the Initial UE Message Interaction Procedure, even if the RAN UE NGAP ID IE has been assigned in the "Initial UE Message" message sent via another NG interface instance, the NG-RAN node SHOULD use the "AMF UE NGAP ID IE" and "RAN UE NGAP ID IE" received in the "Downlink NAS Transport" message as the logical connection identifier.   4. During the UE Radio Capability Information Indication Procedure, if the Downlink NAS Transport message contains a UE Capability Information Request IE set to "requested" and UE capability-related information has been successfully retrieved from the UE, the NG-RAN node SHOULD trigger the UE Radio Capability Information Indication Procedure.   5. Downlink NAS Transport Abnormal Scenarios: If a Partially Allowed NSSAI IE is received in a DOWNLINK NAS TRANSPORT message, and the total number of S-NSSAIs contained in the Allowed NSSAI and Partially Allowed NSSAI exceeds 8, the NG-RAN node SHOULD 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 failed.

  1. Downlink NAS: The Downlink NAS Transfer procedure is used when the AMF only needs to transparently send NAS messages to the UE via the NG-RAN node and a logical NG connection associated with the UE exists, or the AMF has received the RAN UE NGAP ID IE in the INITIAL UE MESSAGE message, or the NG-RAN node has initiated a logical NG connection associated with the UE by sending an INITIAL UE MESSAGE message via another NG interface instance.   2. Downlink NAS Transfer is shown in Figure 8.6.2.2-1 below, where:   The AMF initiates this procedure by sending a DOWNLINK NAS TRANSPORT message to the NG-RAN node. If a logical NG connection associated with the UE is not established, the AMF shall assign a unique AMF UE NGAP ID to the UE and include it in the DOWNLINK NAS TRANSPORT message. Upon receiving the AMF-UE NGAP ID IE in the DOWNLINK NAS TRANSPORT message, the NG-RAN node establishes a logical NG connection associated with the UE.   If the DOWNLINK NAS TRANSPORT message includes the RAN Paging Priority IE, the NG-RAN node may use it to determine the priority for paging the UE in the RRC_INACTIVE state. The NAS-PDU IE contains an AMF-UE message, which is forwarded uninterpreted within the NG-RAN node. ​ If the Mobility Restriction List IE is included in the Downlink NAS Transport message, the NG-RAN node shall overwrite any previously stored mobility restriction information in the UE context.If the downlink NAS transport message contains information in the Mobility Restriction List IE, the NG-RAN node shall use this information to: determine the target of subsequent mobility operations, and the NG-RAN node shall provide information about the target of the mobility operation to the UE; 3. Select the appropriate SCG during dual connectivity operation; assign the appropriate RNA to the UE when moving it to the RRC_INACTIVE state; and, in addition:   If the downlink NAS transport message does not contain the Mobility Restriction List IE and no mobility restriction information has been previously stored, the NG-RAN node shall assume that the UE is not subject to roaming and access restrictions, except for PNI-NPN mobility as described in TS 23.501. ​ The NG-RAN node shall assume that roaming or access to a CAG cell is permitted only if the downlink NAS transport message contains the Allowed PNI-NPN List IE, as described in TS 23.501. ​ If the downlink NAS transport message contains the RAT/Frequency Selection Priority Index IE, the NG-RAN node shall (if supported) use it as defined in TS 23.501. ​ If the AMF has not previously sent the UE Aggregate Maximum Bit Rate IE, it shall be sent to the NG-RAN node. If included in a downlink NAS transport message, the NG-RAN node shall store the UE aggregate maximum bit rate in the UE context and use the received UE aggregate maximum bit rate for all non-GBR QoS flows of the associated UE as defined in TS 23.501. ​ If the Legacy AMF IE is included in a downlink NAS transport message, the NG-RAN node shall consider the logical NG connection associated with this UE to have been redirected from another AMF identified by the Legacy AMF IE to this AMF. If the Extended Legacy AMF IE is included in a downlink NAS transport message, the NG-RAN node shall (if supported) consider the logical NG connection associated with this UE to have been redirected from another AMF identified by the Extended Legacy AMF IE to this AMF. ​ If the SRVCC Operation Possible IE is included in the DOWNLINK NAS TRANSPORT message, the NG-RAN node shall (if supported) store the contents of the received SRVCC Operation Possible IE in the UE context and use it as defined in TS 23.216. If the Extended Connected Time IE is included in the DOWNLINK NAS TRANSPORT message, the NG-RAN node shall (if supported) use it as defined in TS 23.501. ​ If the Enhanced Coverage Restriction IE is included in the DOWNLINK NAS TRANSPORT message, 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 UE Differentiation Information IE is included in the DOWNLINK NAS TRANSPORT message, the NG-RAN node shall (if supported) store this information in the UE context for further use in accordance with TS 23.50. ​ If the CE-mode-B Restriction IE is included in the downlink NAS transport message, and 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 UE Radio Capabilities IE is included in the downlink NAS transport message, the NG-RAN node shall store this information in the UE context and use it as defined in TS 38.300. ​ If the End Indication IE is included in the downlink NAS transport message and is set to "No Additional Data", the NG-RAN node shall consider the UE Radio Capabilities IE to be in addition to the included NAS PDU.  

1. Protocol Framework As shown in the following figure (1), NETCONF adopts a layered structure, where each layer encapsulates specific functions and provides services to the upper layer. This structure allows each layer to focus on a single aspect of NETCONF and reduces the dependencies between layers. Changes within a layer have minimal impact on other layers.       NETCONF can be divided into four layers: the transport security layer, the message layer, the operation layer, and the content layer. These layers are:   The transport security layer: This layer is responsible for communication between the client and server. NETCONF can be layered on top of any transport protocol that meets basic requirements, such as SSH, TLS, and HTTPS. SSH is the preferred transport protocol for transmitting XML messages in NETCONF. The message layer: This layer provides transport-independent RPC and notification encoding mechanisms. The client encapsulates an RPC request in an element and sends it to the server. The server encapsulates the result of processing this request in an element and sends it to the client. The operation layer: This layer defines a set of basic protocol operations, which are called as RPC methods with XML-encoded parameters. The content layer: This layer is defined by the data model for management data. Currently, mainstream data models include Schema and YANG.         Schema is a set of rules for describing XML files. Devices use schema files (similar to MIB files in SNMP) to provide device configuration and management interfaces to network management systems (NMSs). YANG is a data modeling language designed for NETCONF. The client can compile RPC operations into XML messages to achieve client-server communication that conforms to the constraints of the YANG model.   2. Message Format The following figure (2) is a complete NETCONF YANG request message structure;       3. Communication Framework In NETCONF, the RPC request initiated by the client and the reply from the server are both encoded in XML and contained in the and elements respectively. This request-reply framework is independent of the transport layer protocol; some basic RPC elements are listed below: The element is used to encapsulate the request sent by the NETCONF client to the NETCONF server. The NETCONF server sends an element in response to each request. If any error or alarm occurs during the processing of the request, the NETCONF server will return an message containing only the element to the NETCONF client. If no errors or alarms occur during the processing of the request, the NETCONF server returns an message containing only the element to the NETCONF client.   IV. Database Configuration NETCONF defines a complete set of device configuration parameters. NETCONF defines the existence of one or more configuration databases and allows configuration operations on them. In the basic NETCONF model, only the configuration database is available. Other configuration databases can be defined based on capabilities and are only available on devices that support those capabilities. These include:   : The running configuration database. This database stores all currently active configurations on a network device. There is only one configuration database on a device, and it always exists.   : The candidate configuration database. This database stores configuration data to be committed to the configuration database on the device. Operations on the configuration database can be performed without affecting the device's current configuration. The operation is used to commit a candidate configuration. To support the configuration database, a device must support the candidate configuration capability, a standard NETCONF capability.   : The startup configuration database (similar to a saved configuration file). It stores the configuration data that needs to be loaded when the device starts. To support the configuration database, the device must support independent startup capability, which is a standard NETCONF capability.

Due to the complex configuration of traditional CLI and SNM and the lack of support for transaction mechanism, the NETCONF network management protocol is enabled in the 5G system, allowing NMS (network management system) to issue, modify and delete the configuration of network devices connected to routers, eNodeB, gNodeB, DU, CU or RU. The working principle, structure and service session are as follows;   I. Working principle The NETCONF system contains at least one NMS that manages all network devices, as shown in the figure below. The NETCONF architecture contains two roles: client and server     II. System structure characteristics NETCONF contains at least one NMS that manages all network devices, including:   2.1 The client provides the following functions   Use NETCONF to manage network devices. Send RPC requests to the NETCONF server to query or modify one or more parameter values. According to the alarms and events sent by the NETCONF server of the managed device, understand the status of the managed device. 2.2 When the server receives a request from the client, it will parse the request and send a reply to the client. When a managed device experiences a fault or other type of event, the NETCONF server reports the alarm or event to the client through a notification mechanism, allowing the client to understand the status of the managed device.   III. NETCONF Session: As shown in the figure below, the client and server communicate using the RPC mechanism. Communication is allowed only after a secure connection-oriented session is established between them. The client sends an RPC request to the server, which processes the request and returns a response to the client. The NETCONF client and server communicate using the RPC mechanism. Communication is allowed only after a secure connection-oriented session is established. The session establishment and termination process is as follows:       The client establishes an SSH connection with the server and, after completing authentication and authorization, establishes a NETCONF session with the server. The client and server exchange Hello messages to negotiate capabilities. The client sends one or more RPC requests to the server. Some example requests are listed below:  Modify and commit the configuration;  Query configuration data or status;  Perform maintenance operations on the device;  The client terminates the NETCONF session;  The SSH connection terminates.

  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).     I. 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.   II. 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 methods 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. Frequent changes in CLI structure and syntax make 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.

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.