China Shenzhen Olax Technology CO.,Ltd Company News

  In mobile communication networks, "system overload" occurs when excessive service traffic or too many devices simultaneously attempt to connect overwhelm network resources, leading to congestion, slow speeds, or connection failures. System protection mechanisms are activated to address these overloads. Specific strategies include network operators releasing more licensed spectrum, allocating resources through network slicing, implementing throttling within core network functional units, and enabling mechanisms such as backoff timers and overload messages to effectively control and manage the volume of users.   1. Overload Activation: In a 5G (NR) network, the Access and Mobility Management Function (AMF) sends an "Overload Activation" message to other relevant network elements (such as gNBs) based on its processing capacity (configuration) thresholds, indicating an overload condition. This triggers congestion control measures (such as rejecting connection requests from some user equipment (UEs)) to protect the network from failure. Overload Activation involves the AMF sending an NGAP Overload Activation message to the NG-RAN (Radio Access Network) node, requesting it to limit certain types of traffic and redirect or reject requests to maintain network stability during periods of high demand.   1.1 Overload Control Involves   Congestion Detection: The AMF or other network elements, such as the User Plane Function (UPF), monitor network load and identify when predefined congestion thresholds are exceeded. Overload Control Message: Upon detecting an overload, the AMF sends an NGAP Overload Control message to the connected NG-RAN node. Congestion Control Actions: Upon receiving the message, the NG-RAN node initiates control actions to manage the overload. These actions include: Rejecting Certain Connections: The NG-RAN may reject connection requests from user equipment (UE) for non-emergency or high-priority services. Limiting Uplink Signaling: The NG-RAN can limit the transmission of uplink NAS (Non-Access Stratum) signaling to the AMF, further reducing the load on the network core. Traffic Limiting: The network may limit or reduce the amount of traffic it handles to prevent system failure.   1.2 Overload Control has three objectives: Maintaining Network Stability: The primary goal is to prevent complete network failure during periods of extreme traffic or unexpected load spikes. Ensuring Service Continuity: By managing load, the network can continue to provide essential services even if less critical services are temporarily limited. Protecting Resources: Overload control protects resources such as UDM bandwidth and other critical network functions from being overwhelmed by excessive control plane signaling.   2.the Overload Stop procedure signals the NG-RAN node to which the AMF is connected that the overload situation has ended and that normal operations should resume. The Overload Stop procedure uses non-UE-associated signaling. A successful Overload Stop operation is shown in Figure 8.7.8.2-1 below, where:   An NG-RAN node that receives the "OVERLOAD STOP" message should assume that the overload situation for the receiving AMF has ended and should resume normal operations for traffic applicable to the AMF.

  1. System Overload: In 5G networks, "overload" refers to excessive traffic or too many devices attempting to connect simultaneously, overwhelming network resources and leading to congestion, slow speeds, or connection failures. Strategies for addressing this overload include releasing more licensed spectrum, allocating resources through network slicing and core network functions, and implementing mechanisms such as throttling, exit timers, and overload messages to effectively control and manage traffic.   2. The overload initiation process notifies the NG-RAN node to reduce the signaling load directed to the associated AMF. This initiation process uses non-UE-associated signaling. As shown in Figure 8.7.7.2-1 below, the initiation process includes:     An NG-RAN node receiving an overload initiation message should assume that the receiving AMF is in an overloaded state. If the Overload Start message contains the Overload Action IE and the AMF Overload Response IE, the NG-RAN node shall use it to identify the relevant signaling traffic. This information is used when the Overload Action IE is set to: “Reject RRC connection establishment for non-emergency mobile originated data transfers” (i.e., reject traffic corresponding to the RRC causes “mo-data”, “mo-SMS”, “mo-VideoCall”, and “mo-VoiceCall” in TS 38.331 or “mo-data” and “mo-VoiceCall” in TS 36.331), or “Reject RRC connection establishment for signaling” (i.e., reject traffic corresponding to the RRC causes “mo-data”, “mo-SMS”, “mo-signalling”, “mo-VideoCall”, and “mo-VoiceCall” in TS 38.331 or “mo-data”, “mo-signalling”, and “mo-VoiceCall” in TS 36.331), or “Allow RRC connection establishment only for emergency sessions and mobile terminated services” (i.e., allow only traffic corresponding to TS 38.331 or the RRC causes "emergency" and "mt-Access" in TS 36.331), or "RRC connection establishment is only allowed for high-priority sessions and mobile terminated services" (i.e., only traffic corresponding to the RRC causes "highPriorityAccess," "mps-Priority Access," "mcs-PriorityAccess," and "mt-Access" in TS 38.331 or "highPriorityAccess," "mo-ExceptionData," and "mt-Access" in TS 36.331 is allowed). 3. Overload Handling: The NG-RAN handles the situation as follows: If the OVERLOAD START message contains the AMF Traffic Load Reduction Indication IE, the signaling traffic is reduced by the indicated percentage; otherwise, only signaling traffic not indicated as rejected is sent to the AMF. If the Overload Start NSSAI List IE is included in the OVERLOAD START message, the NG-RAN node shall: If the Slice Traffic Load Reduction Indication IE is present, reduce the UE's signaling traffic by the indicated percentage, provided that the IE is present and the requested NSSAI contains only the S-NSSAI contained in the Overload Start NSSAI List IE and the signaling traffic reduction indicated by the Overload Action IE in the Slice Overload Response IE; otherwise, ensure that only signaling traffic from the UE (if the requested NSSAI matches, only signaling traffic from the UE's requested NSSAI containing S-NSSAIs other than the S-NSSAI contained in the Overload Start NSSAI List IE) or signaling traffic not reduced as indicated by the Overload Action IE in the Slice Overload Response IE) is sent to the AMF. If overload control is in progress and the NG-RAN node receives another OVERLOAD START message, the NG-RAN node shall replace the previously received message content with the new content.

  1. AMF (The Access and Mobility Management Function ) is a critical control plane element in 5G, responsible for managing user equipment (UE) access, mobility, and security within the 5G system. It handles initial UE registration and authentication, and manages handovers between network cells and access networks. The AMF collaborates with other network functions (such as the SMF) to establish and maintain data sessions for users.   2. The AMF's responsibilities are divided into the following areas: UE Registration and Authentication: The AMF authenticates the UE, verifies its identity and subscription credentials, and grants it access to 5G services. Mobility Management: Responsible for handling the complex process of moving a UE from one cell to another or between different radio access networks (NG-RANs). Context Management: Maintains the UE context, which includes information about the UE's current location, session state, and security. Interaction with Other Network Elements SMF (Session Management Function): The AMF collaborates with the SMF to establish, modify, and manage user data sessions. UDM (Unified Data Management): It communicates with the UDM to retrieve and manage user subscription information.      AUSF (Authentication Server Function): The AMF selects the appropriate AUSF to authenticate the UE's identity during registration. NSSF (Network Slice Selection Function): The AMF uses the NSSF to discover and select the appropriate network slice and functions based on the UE's location and requirements. Network Function Management: The AMF uses a service-based interface and the Network Repository Function (NRF) to discover and select other network functions. 3. The AMF Status Indication procedure is designed to support AMF management functions. This procedure uses non-UE-associated signaling and successful operation is shown in Figure 8.7.6.2-1 below, where:   The AMF initiates this procedure by sending an "AMF Status Indication" message to the NG-RAN node. Upon receipt of the AMF Status Indication message, the NG-RAN node shall assume that the indicated GUAMI is unavailable and perform AMF reselection as defined in TS 23.501. If supported, the NG-RAN node shall take appropriate action as specified in TS 23.501 based on the existence of the timer method for the GUAMI removal IE. If the Backup AMF Name IE is included in the AMF Status Indication message, the NG-RAN node shall (if supported) perform AMF reselection according to the AMF indicated by the Backup AMF Name IE as specified in TS 23.501. If the Extended Backup AMF Name IE is included in the AMF Status Indication message, the NG-RAN node shall (if supported) perform AMF reselection according to the AMF indicated by the Extended Backup AMF Name IE as specified in TS 23.501.

  1. System Abnormalities: Deviations from the design may occur during the normal operation of the 5G network. These include performance issues such as network security threats, signal interference, insufficient coverage, and potential failures in network software and hardware. These abnormalities can manifest as service interruptions, system crashes, slow network speeds, or dropped calls. They are typically identified by analyzing network data anomaly detection systems and can be categorized into the core network and radio network.     2. 5GC Abnormalities: If the NG RESET message includes the UE-associated Logical NG Connection List IE, but neither the AMF UE NGAP ID IE nor the RAN UE NGAP ID IE is present in the UE-associated Logical NG Connection Item IE, the AMF shall ignore the UE-associated Logical NG Connection Item IE. The AMF may return an empty UE-associated Logical NG Connection Item IE in the UE-associated Logical NG Connection List IE in the NG RESET ACKNOWLEDGE message.     3. NG-RAN Anomalies: If the NG RESET message contains the UE-Associated Logical NG Connection List IE, but neither the AMF UE NGAP ID IE nor the RAN UE NGAP ID IE is present in the UE-Associated Logical NG Connection Item IE, the NG-RAN node shall ignore the UE-Associated Logical NG Connection Item IE. The NG-RAN node may return an empty UE-Associated Logical NG Connection Item IE in the UE-Associated Logical NG Connection List IE in the NG RESET ACKNOWLEDGE message.     4. NG RESET message crossover typically occurs in the following two scenarios:   If an NG reset procedure is in progress in an NG-RAN node and the NG-RAN node receives an NG RESET message from a peer entity on the same NG interface that is associated with one or more UE associations that were previously requested to be reset (as explicitly or implicitly indicated in the received NG RESET message), the NG-RAN node shall respond with an NG RESET ACKNOWLEDGE message as specified in clause 8.7.4.2.1.   If an NG reset procedure is in progress in the AMF and the AMF receives an NG RESET message from a peer entity on the same NG interface that is related to one or more UE associations that were previously requested to be reset (indicated explicitly or implicitly in the received NG RESET message), the AMF shall respond with an NG RESET ACKNOWLEDGE message as specified in clause 8.7.4.2.

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.