China Shenzhen Olax Technology CO.,Ltd Company News

In a 5G system, when the NG interface or certain parts of the NG interface need to be reset, the NG-RAN node will be notified; when the AMF processes overload, an overload message will also be sent to the NG-RAN node to notify the gNB to start the load management process; the specific definitions of these messages are as follows;   1. NG reset messages are sent by NG-RAN nodes and AMF to request the reset of the NG interface or certain parts thereof.   Message direction: NG-RAN node → AMF and AMF → NG-RAN node   2. The NG RESET acknowledgment message is jointly sent by the NG-RAN node and the AMF as a response to the NG RESET message.   Message direction: NG-RAN node → AMF and AMF → NG-RAN node   3. NG RESET Confirmation Message: This message is jointly sent by the NG-RAN node and the AMF as a response to the NG RESET message.   Message direction: NG-RAN node → AMF and AMF → NG-RAN node   4. Error indication messages are sent by NG-RAN nodes and AMF to indicate that an error has been detected in the node.   Message direction: NG-RAN node → AMF and AMF → NG-RAN node 5. The overload start message is sent by the AMF to indicate to the NG-RAN node that the AMF is overloaded.   Message direction: AMF → NG-RAN node   6. The overload stop message is sent by the AMF to indicate that the AMF is no longer overloaded.   Message direction: AMF → NG-RAN node      

AMF (Access and Mobility Management Function) is a control plane (CU) functional unit in the 5G core network (CN). Radio network elements (gNodeBs) need to connect to AMF before they can access any 5G service. The connection between AMF and other units in the 5G system is shown in the figure below.     *Figure 1. Schematic diagram of AMF and 5G network element connection (solid lines in the figure represent physical connections, and dashed lines represent logical connections)   I. AMF Interface Functions N1[2]: The AMF obtains all connection and session-related information from the UE through the N1 interface. N2[3]: Communication between the AMF and the gNodeB related to the UE, as well as communication unrelated to the UE, is conducted through this interface. N8: All user and specific UE policy rules, session-related subscription data, user data, and any other information (such as data exposed to third-party applications) are stored in the UDM, and the AMF obtains this information through the N8 interface. N11[4]: The N11 interface represents the triggers for the AMF to add, modify, or delete PDU sessions on the user plane. N12: The AMF simulates an AUSF within the 5G core network and provides services to the AMF through the AUSF-based N12 interface. The 5G network represents a service-based interface, focusing on the AUSF and the AMF. N22: The AMF selects the best network function (NF) in the network using the NSSF. The NSSF provides network function location information to the AMF through the N22 interface. SBI[8]: The service-based interface is API-based communication between network functions.   II. AMF Application Protocols NAS[5]: In 5G, NAS (Non-Access Layer Protocol) is the control plane protocol on the radio interface (N1 interface) between the UE and AMF; it is responsible for managing mobility and session-related context within the 5GS (5G system). NGAP[6]: NGAP (Next Generation Application Protocol) is a control plane (CP) protocol used for signaling communication between the gNB and AMF. It is responsible for handling services related to the UE and services unrelated to the UE. SCTP[7]: Flow Control Transmission Protocol (SCTP) ensures the transmission of signaling messages between the AMF and the 5G-AN node (N2 interface). ITTI Messages[9]: Inter-task interface used to send messages between tasks.   III. Call Flow - UE Registration and Deregistration (Steps) The AMF first needs to register with the NRF to identify and communicate with the Network Function Location. When the UE powers on, it goes through a registration process. The AMF processes the registration and then receives the initial NAS UE message and registration request. This message is used to create an AMF identity for the UE. Then, the AMF checks the AMF the UE last registered with. If the old AMF address is successfully found, the new AMF will retrieve all UE contexts and initiate a deregistration procedure for the old AMF. The old AMF requests to release the SM context from the SMF and the UE context from the gNB.   IV. Terminal Authentication and Authorization If the new AMF does not detect any trace of the old AMF, it initiates the authorization and authentication process with the UE. It handles the identity verification process and requests an authentication vector from the AMF. It then sends an authentication request to the UE to set a security key and select a security algorithm for the channel, thereby ensuring secure data transmission. The AMF controls all NAS downlink/uplink transmission channels used for communication.

As mobile communication networks become increasingly complex, performance optimization and user experience improvement are crucial for operators. Previously, optimization engineers primarily relied on drive tests to perform (physical) measurements of the network to understand and control wireless coverage and performance. However, this testing method is costly, time-consuming, and not always comprehensive.   I. Minimum Drive Testing (MDT) is a wireless network measurement method designed by 3GPP for mobile communication networks. MDT allows the network to collect actual performance data directly from the User Equipment (UE) side, thereby reducing the need for manual drive testing. It is specifically divided into Logged MDT and Immediate MDT (iMDT).   II. Immediate MDT, as defined in 3GPP, refers to the real-time reporting of network performance data by the terminal equipment (UE) during a radio connection session. Unlike logged MDT, which stores data on the device for later upload, immediate MDT sends measurement results to the network, enabling operators to:   Identify network problems such as radio link failures (RLFs) in real time. Collect data at specific locations during the real-time session. Improve user performance in real time.   III. Key Points of Immediate MDT The Immediate MDT process during a connection session between the UE and the network mainly includes: MDT Configuration: The UE obtains the MDT configuration from the network. This configuration specifies which types of data need to be collected (e.g., RSRP, RSRQ, SINR, or call events). Measurement Timing: In a connected state, the UE periodically performs measurements based on specified conditions. Measurement parameters may include signal strength, quality metrics, and location data. Coverage Dead Zones and Radio Link Failures (RLF): If the UE finds itself in a coverage dead zone, an RLF may occur, prompting the MDT process to record signal strength and location for further analysis. Logger and RLF Indication: During an RLF event, the UE logs key information such as signal strength and location coordinates. After the RRC connection is re-established, an RLF log indication is created and sent. Re-establishment and Reporting: The UE needs to re-establish the RRC connection to reconnect. After the RRC reconnection, the UE sends the RLF log indication along with the recorded information. This helps the network identify the location and cause of the RLF, which is very useful for network optimization.

I. PDU Session Resource Notification (PDU SESSION RESOURCE NOTIFY) is a 5G system notification to the core network element AMF that a QoS flow or PDU session established for a specific terminal (UE) has been released, is no longer being executed, or is being re-executed by an NG-RAN node controlled by a request notification. This procedure is also used to notify the NG-RAN node of QoS parameters that were not successfully accepted during the path handover request procedure. The entire procedure uses UE-related signaling.   II. PDU Session Resource Success Notification: As shown in Figure 8.2.4.2-1, the PDU session resource success operation is initiated by the GN-RAN node.     III. Key information for PDU session resource notification includes:   The NG-RAN node initiates this process by sending a PDU session resource notification message. The PDU SESSION RESOURCE NOTIFY message should contain information about PDU session resources or QoS flows that have been released, are no longer being executed, or have been re-executed by the NG-RAN node. For each PDU session where some QoS flows have been released, are no longer being executed, or have been re-executed by the NG-RAN node, a PDU session resource notification transport IE should be included, containing: A list of QoS flows released by the NG-RAN node (if any) in the QoS flow release list IE. If no other QoS flows are associated with the existing bearer after release (e.g., splitting the PDU session), the NG-RAN node and 5GC should consider the associated NG-U transport bearer to have been removed, and the associated NG-U UP TNL information to be available again. A list of GBR QoS flows that the NG-RAN node no longer executes or has re-executed by the NG-RAN node (if any) in the QoS flow notification list IE, along with the notification reason IE. For QoS flows indicated as no longer satisfied, the NG-RAN node may also indicate the alternative QoS parameter sets that can currently be satisfied in the Current QoS Parameter Set Index IE. For QoS flows indicated as no longer satisfied, the NG-RAN node may also indicate RAN feedback in the TSC Traffic Characteristics Feedback IE. A list (if any) of QoS flows whose QoS parameters have been updated but cannot be successfully accepted by the NG-RAN node during a path handover request should be included in the QoS Flow Feedback List IE, which may be associated with values ​​that can be provided. For each PDU session resource released by the NG-RAN node, a PDU session resource notification transmission released should be included in the "PDU Session Resource Notification Released Transmission IE" and the release reason should be included in the "Reason IE". If the User Plane Error Indication IE is set to "Received GTP-U Error Indication", the SMF (if supported) should consider the PDU session released due to receiving a GTP-U error indication through the NG-U tunnel, as described in TS 23.527. The NG-RAN node (if supported) should report the UE location information in the User Location Information IE in the PDU SESSION RESOURCE NOTIFY message. Upon receiving a PDU SESSION RESOURCE NOTIFY message, the AMF should transparently transmit a PDU Session Resource Notify Transfer IE or a PDU Session Resource Notify Released Transfer IE to the SMF associated with the relevant PDU session for each PDU session indicated in the PDU Session ID IE. Upon receiving the PDU Session Resource Notify Transfer IE, the SMF typically initiates the corresponding release or modification procedure on the core network side for PDU sessions or QoS flows that are identified as no longer satisfying. For each PDU session, if its PDU Session Resource Notification Transfer IE or PDU Session Resource Notification Released Transfer IE contains a Secondary RAT Usage Information IE, the SMF should process this information in accordance with TS 23.502. If the PDU Session Resource Notification message contains a User Location Information IE, the AMF should process this information in accordance with TS 23.501.

  I. A CORESET is a Control Resource Set used in 5G (NR). It is a set of physical resources within a specific area of ​​the Downlink Resource Grid used to carry the PDCCH (DCI). In 5G (NR), the PDCCH is specifically designed to be transmitted within a configurable Control Resource Set (CORESET).   II. PDCCH Location The CORESET in 5G is similar to a Control Region in LTE because its Resource Set (RB) and OFDM symbol set are configurable, and it has a corresponding PDCCH search space. The flexibility of NR Control Region configuration, including time, frequency, parameter set, and operating point, allows it to meet a wide range of application scenarios. While PDCCHs in LTE Control Regions are allocated across the entire system bandwidth, NR PDCCHs are transmitted within a specially designed CORESET area, located in a specific region of the frequency domain, as shown in the diagram below.   III. 4G PDCCH and 5G PDCCH CORESET Frequency allocation in a CORESET configuration can be continuous or discontinuous. A CORESET configuration spans 1-3 consecutive OFDM symbols in time. REs in a CORESET are organized into REGs (RE groups). Each REG consists of 12 REs from one OFDM symbol in an RB. The PDCCH is confined to a CORESET and transmitted using its own demodulation reference signal (DMRS) to achieve control channel beamforming for the UE. To accommodate different DCI payload sizes or different coding rates, the PDCCH is carried by 1, 2, 4, 8, or 16 Control Channel Elements (CCEs). Each CCE contains 6 REGs. The CCE-to-REG mapping of a CORESET can be interleaved (for frequency diversity) or non-interleaved (for local beamforming). IV. CORESET Mapping Each 5G terminal (UE) is configured to blindly test multiple PDCCH candidate signals with different DCI formats and aggregation levels. Blind decoding increases the complexity of the UE, but is necessary for flexibly scheduling and processing different DCI formats with low overhead.   V. CORESET Characteristics The CORESET control resource set in 5G (NR) is similar to the LTE PDCCH control area; 5G (NR) CORESETs are divided into two types: general CORESETs and UE-specific CORESETs; Each active downlink BWP can configure up to 3 core sets, including general CORESETs and UE-specific CORESETs; A serving cell can have up to 4 BWPs, and each BWP can have up to 3 CORESETs, for a total of 12 CORESETs; Each CORESET can be identified by an index ranging from 0 to 11, named Control Resource Set Id; The Control Resource Set Id is unique within the same serving cell; When a specific CORESET is defined, its index is CORESET0; this CORESET is configured using a 4-bit information element in the MIB (Master Information Block), which is associated with the cell-defined synchronization signal and Physical Broadcast Channel (PBCH) block (SSB); CORESETs are only configured within their associated Bandwidth Weighted (BWP) Activation occurs only upon activation, except for CORESET0, which is associated with the initial bandwidth-weighted packet (the bandwidth-weighted packet with index 0); In the frequency domain, CORESETs are configured on 6 PRB frequency grids in units of 6 PRBs; In the time domain, CORESETs are configured as 1, 2, or 3 consecutive OFDM symbols.  

Compared to previous generations of technology, 5G (NR) has higher requirements for timing and synchronization accuracy. This is because the network needs synchronization to achieve functions such as carrier aggregation, Mass MIMO, and TDD (Time Division Duplex); key technologies such as enhanced boundary clocks, PTP (Precise Time Protocol), and TSN (Time Sensitive Networking) can meet its accuracy requirements; regarding timing and synchronization status reports, 3GPP defines them in TS38.413 as follows:     I. Timing Synchronization Status Report The purpose of the timing synchronization status report process in the 5G system is to enable NG-RAN nodes to provide RAN timing synchronization status information to the AMF in accordance with TS 23.501 and TS 23.502; the timing synchronization status report process uses signaling not associated with the UE. The successful report operation process is shown in Figure 8.19.2.2-1, where:   The NG-RAN node initiates the process by sending a TSCTSF timed synchronization status report message, indicated by the routing ID IE, to the AMF.   II. The purpose of the timed synchronization status report is to enable the AMF to request the NG-RAN node to start or stop reporting RAN timed synchronization status information as specified in TS 23.501 and TS 23.502. The successful synchronization status report operation process is shown in Figure 8.19.1.2-1 below. The reporting process uses non-UE associated signaling; where:     AMF initiates this process by sending a timing synchronization status request message to the NG-RAN node. If the RAN TSS request type IE contained in the timing synchronization status request message is set to "start", the NG-RAN node should start RAN TSS reporting for the TSCTSF indicated by the route ID IE. If the RAN TSS request type IE is set to "stop", the NG-RAN node should stop reporting the TSCTSF indicated by the route ID IE. III. The scheduled synchronization status report operation failed, as shown in Figure 8.19.1.3-1, where:     If an NG-RAN node is unable to report the timing synchronization status, the process should be considered a failure and a "Timing Synchronization Status Failed" message should be returned.  

I. Service Support Similar to 2G, 3G, and 4G mobile communication systems, 5G (NR) systems support services categorized into three main types: voice, data, and video. A cellular mobile system consists of two basic parts: the mobile terminal (UE) and the network (composed of base stations and backend data connection components such as the core network and fiber optics).   II. System Characteristics 5G is developed according to 3GPP standards Release 15 and higher, and is backward compatible with LTE and LTE-Advanced Pro. Currently, 5G systems are being developed in multiple frequency bands to support spectrum regulation worldwide. A 5G system can be composed of three parts: UE (i.e., the terminal - mobile phone) gNB (i.e., the base station) CN (i.e., the core network)   III. 5G Network Deployment 5G deployment is divided into Non-Standalone (NSA) and Standalone (SA) architectures. Specifically:   In NSA, the UE operates simultaneously on both the LTE eNB and the 5G gNB. In this mode, the UE uses the C-plane (control plane) of the LTE eNB for initial synchronization, and then camps on the U-plane (user plane) of the 5G gNB for traffic exchange. In SA, the UE operates only in the presence of a 5G base station (gNB). In this mode, the UE uses the control plane of the 5G base station for initial synchronization, and then also camps on the user plane of the 5G base station for traffic exchange.   IV. Service Call Flow 4.1 Voice Call Flow 5G voice calls establish a circuit between the caller and the called party to enable voice transmission and reception over the 5G network. Voice calls are of two types: Mobile-initiated call Mobile-terminated call Regular voice calls can be made using 4G/5G phones without any applications. 4.2 Data Call Flow 5G data calls establish a virtual circuit between the caller and the called party to enable data transmission and reception over the 5G network. Data calls are of two types: Mobile-initiated packet-switched call Mobile-terminated packet-switched call Specific services include normal internet browsing and uploading/downloading after establishing an internet connection with the 5G network and the 5G phone (i.e., the terminal).   4.3 Video Call Flow 5G video calls establish a connection between two phones (or terminals) and use a packet-switched connection for video transmission and reception; it uses applications such as WhatsApp, Facebook Messenger, and GTalk over the internet connection.

    Compared to 4G systems, 5G (NR) has achieved breakthrough improvements in key performance indicators of mobile communication; it also supports various emerging application scenarios. Based on the success of 5G (NR) systems, 6G is expected to emerge around the end of 2030. 3GPP SA1's multiple studies on Rel-19 not only demonstrate the additional capabilities that 5G systems will bring, but also provide guidance for the future capabilities required for 6G systems.   I. 3GPP Standards The entire development of mobile communication from GSM (2G), WCDMA (3G), LTE (4G) to NR (5G) has adopted 3GPP, the only and globally leading communication standard. During this period, almost all mobile phones and devices connected to cellular networks supported at least one of these standards. Besides contributing to the enormous success of 4G systems (commonly known as LTE), 3GPP has also significantly improved the performance of cellular communication systems in 5G.   II. 5G Standards and Functions Since the first commercial deployment of 5G systems in 2018, as shown in Figure 1, 3GPP has continuously added new functions in subsequent versions, including:     Rel-15, Rel-16, and Rel-17 are the first three versions supporting 5G systems, providing the basic functionalities that distinguish 5G from 4G systems. Rel-18, Rel-19, and Rel-20 add advanced features to 5G systems and are also known as 5G-Advanced. The second and third phase working groups in 3GPP developed the Rel-18 system architecture and protocols, while the first phase working group of 3GPP discussed 6G system architectures beyond the Rel-19 5G system.   III. Overall Progress of Rel-19 At the SA1#97 (February 2022) and SA1#98 (May 2022) meetings, the 3GPP SA1 working group reached an agreement on the Rel-19 Research Item Descriptions (SIDs), as shown in Table 1. Many projects are gradually moving towards application.     As the research title suggests, 3GPP standards are addressing the more specific needs of industries considering using 3GPP-based communication systems. Previous versions of 3GPP standards have added support for various industries, such as machine-to-machine communication. 3GPP has also introduced features such as support for low-power IoT communication, wide-coverage IoT communication, and vehicle-to-vehicle communication.   However, previous versions' support is insufficient for some other industries, and new research is striving to meet their needs. For example, the research on Metaverse services (FS_Metaverse) will address the requirements of 3GPP-based systems in carrying traffic for applications in metaverse scenarios.   On the other hand, as industries adopt 3GPP-based communication technologies, new scenarios are constantly emerging, requiring 3GPP to conduct further research. For instance, the research on satellite access (FS_5GSAT_ph3) is attempting to meet the additional needs of the satellite industry, building upon previous research.

In a 5G broadcast system, session modification will update the PDU (Packet Data Unit) session; the update can be triggered by events such as the terminal device (UE), the network, or a radio link failure. The MBS session update process is specifically handled by the SMF, involving the UPF updating the user plane connection; then the UPF notifies the access network and AMF to modify session rules, QoS (Quality of Service), or other parameters.   I. Session Modification Initiation in 5G Systems can be triggered by multiple network elements, namely: UE-Initiated:The UE requests changes to its PDU session, such as modifying packet filters or QoS for a specific service. Network-Initiated:The network (typically a Policy Control Function (PCF)) initiates modifications, such as applying new policy rules or QoS changes. Access Network-Initiated: Events such as radio link failures, user inactivity, or mobility restrictions may trigger modifications, causing the AN to release the session or modify its configuration. AMF-Initiated:The AMF may also trigger modifications, such as due to unspecified network failures.   II. The MBS successful modification broadcast session modification procedure aims to request the NG-RAN node to update MBS session resources or areas related to previously established broadcast MBS sessions; this procedure uses non-UE associated signaling. A successful modification is shown in Figure 8.17.2.2-1, where:   MF initiates this process by sending a "BROADCAST SESSION MODIFICATION REQUEST" message to the NG-RAN node, in which:   If the "Broadcast Session Modification Request" message contains an "MBS Service Area" IE, the NG-RAN node should update the MBS service area and send a "Broadcast Session Modification Response" message. If the "Broadcast Session Modification Request" message contains an "MBS Session Modification Request Transmission" IE, the NG-RAN node should replace the previously provided information with the newly received information and update the MBS session resources and area according to the request, and then send a "Broadcast Session Modification Response" message. If the "Broadcast Session Modification Request" message includes a "List of Supported User Equipment Types" IE (if supported), the NG-RAN node should consider this in the MBS session resource configuration. If the MBS NG-U fault indication IE is included in the broadcast session modification request message within the MBS session setup or modification request transmission IE and is set to "N3mb path failure," the NG-RAN node can provide new NG-U transport layer information to replace the failed transport layer information, or switch data transmission to another 5GC according to the N3mb path failure broadcast MBS session recovery procedure specified in TS 23.527.   III. MBS Modification Failure In the live network, NG-RAN nodes may experience broadcast session modification failures for various reasons; the modification failure is shown in Figure 8.17.2.3-1, where:   If an NG-RAN node fails to update any requested modifications, the NG-RAN node should send a "Broadcast Session Modification Failure" message.  

1. Broadcast Session Release: In mobile communications systems, this refers to the process by which a user equipment (UE) terminates reception of broadcast signals from a 5G network, similar to ending a streaming media session. This occurs when the user explicitly terminates the session, the broadcast ends, or the device moves out of broadcast coverage. The network element (Broadcast/Multicast Service Center) will tear down the session to ensure efficient data transmission to multiple users simultaneously. Releases include:     User-Initiated Release: The user manually stops the broadcast, similar to closing a streaming app. Network-Initiated Release: The broadcast session ends due to the completion of content playback or termination by the network operator. This may be due to the end of a live event or scheduled broadcast. Device-Initiated Release: The device moves out of broadcast coverage, resulting in signal loss and session termination. The Broadcast/Multicast Service Center (BM-SC) manages broadcast sessions and can initiate releases based on network policies or user actions.   2. Broadcast Session Release Process: The purpose is to release resources associated with a previously established MBS broadcast session. The release uses non-UE-associated signaling. A successful release operation is shown in Figure 8.17.3.2-1, where:       The AMF initiates this procedure by sending a Broadcast Session Release Request message to the NG-RAN node. Upon receipt of the Broadcast Session Release Request message, the NG-RAN node shall respond with a Broadcast Session Release Response message. The NG-RAN node shall cease broadcasting and release all MBS session resources associated with the broadcast session. Upon receipt of the Broadcast Session Release Response message, the AMF shall transparently transmit the Broadcast Session Release Response Transport IE (if any) to the MB-SMF.