China Shenzhen Olax Technology CO.,Ltd Company News

    In the 5G system, the NSSF (Network Slice Selection Function) is a key component in the 5GC architecture, responsible for enabling and managing network slices. It provides two services: Nnssf_NSSelection (slice selection) and Nnssf_NSSAIAvailability (slice availability), which are defined as follows:   I. Network slicing allows operators to create multiple virtual networks on top of a shared physical infrastructure. Each slice can be customized according to specific service requirements, such as enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC), or massive machine-type communication (mMTC). The NSSF plays a core role in selecting the appropriate network slice for a given User Equipment (UE) and ensuring the correct resources are allocated.   II. The responsibilities of the NSSF, as defined in 3GPP TS 29.531, are: Selecting a set of network slice instances: Based on the UE's subscription, requested Network Slice Selection Assistance Information (NSSAI), and operator policies, the NSSF determines which slice instances should serve the UE. Determining allowed NSSAI and configured NSSAI mapping: Based on the UE's subscription (subscribed S-NSSAI from UDM), requested NSSAI, current service area (TA/PLMN), operator policies, and network constraints, the NSSF determines which S-NSSAI are available to the UE.   The specific tasks of the NSSF include: Calculating allowed NSSAI – selecting the set of S-NSSAI authorized for the UE in the current serving PLMN and registration area from the requested or subscribed list. Providing configured NSSAI mapping information – the NSSF returns the configured NSSAI mapping for the serving PLMN, which the AMF then passes to the UE via a registration accept message or UE configuration update message.   III.Roaming Scenarios: In this scenario, the NSSF provides S-NSSAI mapping between the VPLMN and HPLMN to ensure network slice compatibility and determine the AMF set – in some cases, the NSSF can also help determine the appropriate set of AMFs (Access and Mobility Management Functions) to serve the UE, especially when AMF reallocation is required.   IV. NSSF Services In 5GC, the NSSF provides services to AMF, SMF, NWDAF, and other NSSF instances in different PLMNs through a service-based interface (SBI) based on the Nnssf service. The main function of the NSSF is to provide network slice information to the AMF; the NSSF exposes two main services via SBI: Nnssf_NSSelection: Used by the AMF to retrieve network slice selection information. Nnssf_NSSAIAvailability: Used by the AMF to update the NSSF with information on the S-NSSAI supported within each tracking area (TA) and to subscribe to availability change notifications.

  I. QoS Model In 5G, the QoS Flow model supports two types of QoS flows: GBR QoS flows – QoS flows requiring guaranteed flow bit rate, and Non-GBR QoS flows – QoS flows that do not require guaranteed flow bit rate. The QoS model in 5G also supports Reflective QoS (see Reflective QoS - TS 23.501 Clause 5.7.5).   II.QoS and PDU In a 5G system, the QoS flow is the finest granularity for distinguishing QoS within a PDU session. The QoS Flow ID (QFI) is used to identify QoS flows in the 5G system. Within a PDU session: user plane traffic with the same QFI will receive the same traffic forwarding processing (e.g., scheduling, admission thresholds). The QFI resides in the N3 (and N9) encapsulation header, meaning no changes are required to the end-to-end packet header. All PDU call types should use the QFI. The QFI should be unique within a PDU session. QFI can be dynamically allocated or equal to 5QI (see Section 5.7.2.1).   III. QoS Control In 5GS, QoS flows are controlled by the SMF and can be pre-configured or established through the PDU session establishment process (see Section 4.3.2 of TS 23.502[3]) or the PDU session modification process (Section 4.3.3 of TS 23.502[3]).   IV.QoS Flow Characteristics 5G systems have the following characteristics: - A QoS profile provided by the SMF to the AN via the AMF through the N2 reference point, or pre-configured in the AN; - One or more QoS rules, and optional QoS flow-level QoS parameters (as described in TS 24.501[47]), which can be provided by the SMF to the UE via the AMF through the N1 reference point, and/or derived by the UE through application reflective QoS control; and - One or more UL and DL PDRs (SMF to UPF) provided by the SMF.   V. Default QoS Flow In 5GS, a PDU session needs to establish a QoS flow associated with a default QoS rule, and this QoS flow remains established throughout the entire lifecycle of the PDU session. This QoS flow should be a non-GBR QoS flow, and the QoS flow associated with the default QoS rule provides connectivity to the UE throughout the entire lifecycle of the PDU session.Furthermore, the QoS flow is associated with the QoS requirements specified by QoS parameters and QoS characteristics. Interoperability with EPS necessitates the recommendation that this QoS flow be of the non-GBR type.

I. Network Analytics is a 5G system utilizing artificial intelligence/machine learning-driven real-time data analysis; it monitors and optimizes network performance, user experience, and resource allocation based on the 3GPP standardized NWDAF (Network Data Analytics Function). Network analytics achieves proactive closed-loop automation by collecting fine-grained data from the Radio Access Network (RAN), core network, and User Equipment (UE), thereby improving service quality, managing network slices, and predicting network behavior.   II. Network Analytics Features: Enabling network analytics provides mobile network operators with the following advantages: Increased Efficiency: Optimizing network resources and reducing total cost of ownership (TCO); User Experience Optimization: Monitoring and improving end-user quality of experience (QoE); Operations Optimization: Replacing passive manual troubleshooting with automated, proactive, and predictive operations; Vendor Interoperability: Using standardized interfaces to avoid vendor lock-in.   III. Key Network Analytics Nodes: NWDAF (Network Data Analytics Function): This is a core 5G function that collects data from multiple network nodes, generates and analyzes data, and provides insights to support automated operations. Fine-grained Real-time Data: Supports monitoring traffic at the user, session, and application levels to ensure high-quality service, especially for critical 5G services. Predictive and AI-driven: Utilizes machine learning to analyze historical and current data for proactive network management, such as predicting congestion or mobility issues. Automated Closed-loop: Enables the network to automatically adjust itself based on analytical insights without manual intervention. Network Slice Optimization: Provides specialized insights for managing the performance of different network slices, ensuring dedicated resources for specific services (e.g., high-bandwidth or ultra-low latency applications).   IV. Network Analytics Triggers: In the 5G system, the SMF requests or subscribes to analytical information from the NWDAF. The trigger conditions include the following conditions in the internal logic: - UE PDU session-related events subscribed to by other NFs (e.g., AMF, NEF); - UE access and mobility event reports from the AMF; - Locally detected events; - Received analytical information.   The trigger conditions may depend on the operator and SMF implementation strategy; when a trigger condition occurs, the SMF can decide whether any analytical information is needed; if needed, it requests or subscribes to analytical information from the NWDAF. When certain local events are detected, such as the number of PDU session establishments or releases within a specific area reaching a threshold, the SMF can request or subscribe to network analytics information related to "abnormal behavior" (as described in TS 23.288[86]) to detect any abnormal UE behavior within that area.

I. Framed Routing is one of the basic functions supported by the 5G system; however, it is only applicable to PDU sessions of IP type (IPv4, IPv6, IPv4v6); it allows the IP network behind the terminal (UE) to access a series of IPv4 addresses or IPv6 prefixes through a single PDU session (e.g., for enterprise connections) – framed routing is the IP routing behind the UE.   II. Framed Routing and PDU: In the 5G system, a PDU session can be associated with multiple framed routes; each framed route points to an IPv4 address range (i.e., IPv4 address and IPv4 address mask) or an IPv6 prefix range (i.e., IPv6 prefix and IPv6 prefix length). The set of one or more framed routes associated with a PDU session is included in the framed routing information. The network does not send framed routing information to the terminal (UE); devices in the network behind the terminal (UE) obtain their IP addresses through mechanisms outside the scope of 3GPP specifications. – See RFC 2865 [73] and RFC 3162 [74] for details.   III. In 5G, framed routing information is provided by the SMF to the UPF (PSA function) as part of the packet detection rule (PDR) (see TS 23.501 section 5.8.2.11.3), and the rule is related to the UPF network side (N6); the SMF needs to consider the UPF's capabilities when selecting a UPF as a PSA to ensure that the SMF selects a PSA (UPF) that supports framed routing for the PDU session to the DNN and/or slice that is considered to support framed routing, for example, a DNN and/or slice intended to support RG, or if the framed routing information has been received as part of the session management subscription data.   IV. Framed routing information can be provided to the SMF in the following ways: Provided by the DN-AAA server as part of PDU session establishment authentication/authorization (as defined in clause 5.6.6), or provided by: The UDM sending session management subscription data associated with the DNN and S-NSSAI (as defined in clause 5.2.3.3.1 of TS 23.502 [3]). If the SMF receives frame routing information from both DN-AAA and UDM simultaneously, the information received from DN-AAA takes precedence and overrides the information received from UDM.   V. The IPv4 address/IPv6 prefix assigned to the UE as part of PDU session establishment (e.g., passed in the NAS PDU session establishment acceptance) may belong to one of the frame routes associated with that PDU session, or it may be dynamically assigned outside of these frame routes.   VI. If PCC is applied to the PDU session, the SMF reports the frame routing information corresponding to that PDU session to the PCF during PDU session establishment (as described in Section 6.1.3.5 of TS 23.503 [45]). In this case, to support session binding, the PCF may also report the frame routing information corresponding to that PDU session to the BSF (as described in Section 6.1.2.2 of TS 23.503 [45]). ----If the UDM or DN-AAA updates the frame routing information during the lifetime of the PDU session, the SMF will release the PDU session and may include an instruction in the release request indicating that the UE should re-establish the PDU session.

In 5G, a Network Slice Instance (NSI) is an end-to-end logical or virtual network created on top of shared physical infrastructure to provide specific customized services. These instances consist of Virtual Network Functions (VNFs) that ensure dedicated performance, security, and resource isolation (e.g., for IoT, high-speed, or low-latency applications). The support of SMF for NSIs is defined by 3GPP in TS23.501 as follows:   I. The SMF (Session Management Function) unit is a key control plane network function in the 5GC (5G Core Network), responsible for managing the entire lifecycle of Protocol Data Unit (PDU) sessions for end-users (UEs), including establishment, modification, and release. It acts as a central coordinator for session connectivity, IP address allocation, and selection/control of User Plane Functions (UPFs) to ensure Quality of Service (QoS) implementation.   II. SMF Application Instances: In the 5G system, the SMF can establish or modify sessions via the N4 interface, providing network instances to the UPF in the FAR and/or PDR. Specifically:   Network instances can be defined as: for example, used to separate IP domains, where multiple data networks allocate overlapping UE IP addresses when the UPF is connected to the 5G-AN, and for transport network isolation within the same PLMN. Since the SMF can provide the network instance it selects for N3 CN tunnel information via N2, the 5G AN does not need to provide network instances to the 5GC.   III. SMF support for NSI specifically includes the following: The SMF determines the network instance based on local configuration. The SMF can consider factors such as UE location, the UE's registered PLMN ID, and the S-NSSAI of the PDU session to determine the network instance for the N3 and N9 interfaces. The SMF can determine the network instance for the N6 interface based on information such as (DNN, S-NSSAI) in the PDU session. The SMF can determine the network instance for the N19 interface based on information such as (DNN, S-NSSAI), which is used to identify the 5G VN group.   IV. UPF Support for NSI: The UPF can use the network instance included in the FAR, as well as other information such as external header creation (IP address portion) and target interface in the FAR, to determine the interface used for forwarding traffic within the UPF (e.g., VPN or Layer 2 technology).

In 5G (NR) systems, data is sent and received between the terminal and the network in Transfer Units (TU); the size of the MTU (Maximum Transmission Unit) is defined by 3GPP in TS23.501 as follows:   I. MTU Setting: To avoid packet fragmentation between the UE and the UPF acting as a PSA, the link MTU size in the UE should be set appropriately (based on the value provided by the network IP configuration). This is because: The IPv4 link MTU size is sent to the UE in the PCO (see TS24.501 [47]). The IPv6 link MTU size is sent to the UE in the IPv6 router advertisement message (see RFC 4861 [54]).   II. Network Configuration: Ideally, the network configuration should ensure that for IPv4/v6 PDU sessions, the link MTU values ​​sent to the UE via PCO and IPv6 router advertisement messages are the same. If this condition cannot be met, the MTU size selected by the UE is unspecified.   III. Unstructured PDU Sessions: When using unstructured PDU session types, the UE should use the maximum uplink packet size and, when using Ethernet, the payload of the Ethernet frame, which can be provided by the network as part of the session management configuration and encoded in the PCO (see TS 24.501 [47]). When using unstructured PDU session types, to provide a consistent environment for application developers, the network should use a minimum maximum packet size of 128 bytes (for both uplink and downlink).   IV. MT and TE: When the MT and TE are separated, the TE can be pre-configured to use a specific default MTU size, or the TE can use the MTU size provided by the network via the MT. Therefore, the MTU value is not always set by the information provided by the network.   V. Transport Network Settings: In network deployments where the transport network MTU size is 1500 bytes, providing a link MTU value of 1358 bytes to the UE (as shown in Figure J-1) as part of the network IP configuration information can prevent IP layer fragmentation in the transport network between the UE and the UPF. For deployments of transport networks that support MTU sizes greater than 1500 bytes (such as Ethernet jumbo frames with MTU sizes up to 9216 bytes), providing the UE with a link MTU value of MTU minus 142 bytes as part of the network IP configuration information can prevent IP layer fragmentation in the transport network between the UE and the UPF.   VI. Link Issues: Since the link MTU value is provided as part of the session management configuration information, it can be provided during each PDU session establishment. The dynamic adjustment of the link MTU in cases of inconsistent transport MTU is not discussed in Release 18.

Mobile communication carriers advertise very high data rates for 4G (LTE) and 5G (LTE) networks (4G can reach 300 Mbps, and 5G can reach 20 Gbps); however, the actual speeds experienced on mobile phones and in real-world tests differ significantly. Besides transmission loss and time delay, network congestion and transmission protocols are also major reasons.   I. Network Congestion: This is caused by excessive network traffic, outdated or slow hardware, inefficient network design, and bottlenecks caused by errors or congestion leading to retransmissions. Raw speed isn't everything; in some data center applications, higher overhead protocols are often chosen to gain advantages such as higher reliability, better error detection and correction, and congestion control, rather than prioritizing raw data transmission speed.   II. Protocol Overhead: Mobile data uses high-overhead protocols such as TCP (Transmission Control Protocol) to provide a high level of data integrity and reliability. Its main features are as follows: TCP ensures that data is transmitted correctly and in the right order by breaking data into packets, assigning sequence numbers, detecting errors, and retransmitting lost or corrupted packets. TCP uses checksums to detect whether data has been corrupted during transmission. If an error is detected, the receiver requests a retransmission. In TCP, the receiver sends acknowledgment messages to confirm successful receipt of data packets. If the sender does not receive an acknowledgment, it retransmits the packet. TCP manages data flow, preventing the sender from sending too much data and overwhelming the receiver, thus avoiding network congestion. Some routing algorithms in data centers can quickly route retransmitted packets around network failures, minimizing downtime and latency.   Standard protocols, although potentially high-overhead, ensure that various devices from different manufacturers can seamlessly interface and exchange data. This significantly simplifies network management in complex networks. High-overhead protocols may also require additional data and processing power to ensure security; protocols like SSL and TLS use encryption and authentication mechanisms to prevent unauthorized data access and ensure secure transmission. Data center operators, especially those handling critical data (such as financial transactions), often need to make trade-offs between raw speed and other critical requirements such as stability, security, and data accuracy and delivery guarantees.   III. Bandwidth and Data Rate: Wireless cell bandwidth represents the theoretical maximum transmission speed, while the data rate is the actual limit based on network "imperfections." These imperfections stem from inherent physical and software performance limitations, as well as the need for additional features such as higher security and better data reliability. Therefore, regardless of the reason, the data rate is always lower than the theoretical maximum bandwidth.

In 5G, the PDU session between the UE (terminal) and the DN (Data Network - Internet or enterprise network) involves not only the radio network element gNB, but also functional units such as SMF, UPF, and AMF in the 5GC. The relevant QoS services are defined by 3GPP in TS23.501 as follows:   I. Internet and QoS: Different frames exchanged in Ethernet-type PDU sessions may use different QoS services on the 5GS network. Therefore, the SMF can provide the UPF with a set of Ethernet packet filters and forwarding rules based on the Ethernet frame structure and the UE MAC address. The UPF then detects and forwards Ethernet frames based on the Ethernet packet filter set and forwarding rules received from the SMF. This is defined in more detail in sections 5.7 and 5.8.2 of TS23.501.   II. Data Authorization and Filtering: When the DN authorizes an Ethernet PDU type PDU session as described in section 5.6.6, the DN-AAA server can provide the SMF with a list of allowed MAC addresses for this PDU session as part of the authorization data. This list can contain up to 16 MAC addresses. When the list is provided for the PDU session, the SMF sets up corresponding filtering rules in the UPF acting as the anchor point for that PDU session. If an allowed MAC address list is provided, the UPF will discard any UL traffic whose source address does not contain one of these MAC addresses.   In the R18 specification version, PDU sessions of the Ethernet PDU session type are limited to SSC mode 1 and SSC mode 2. For PDU sessions established using the Ethernet PDU session type, the SMF may need to ensure that all Ethernet MAC addresses used as UE addresses in the PDU session are reported to the PCF, as requested by the PCF. In this case, as defined in section 5.8.2.12, the SMF controls the UPF to report the different MAC addresses used as source addresses of the frames sent by the UE in the PDU session.   III. PCF and MAC Address：In Release 18, is it permitted to perform AF control for each MAC address in a PDU session? 3GPP defines this in TS 23.503[45] clause 6.1.1.2, where: The PCF can use the "UE MAC address change" policy control request trigger defined in TS 23.503[45] Table 6.1.3.5-1 to activate or deactivate the reporting of the UE MAC address. The SMF can relocate the UPF serving as the PDU session anchor for an Ethernet PDU session according to TS 23.502[3] clause 4.3.5.8. Relocation can be triggered by mobility events (e.g., handover) or independently of UE mobility, for example, for load balancing reasons. Activating the reporting of the UE MAC address is required for relocating the PSA UPF.

In 5G, a PDU Session is a logical connection between the UE and the DN (Internet or enterprise network), specifically for data (traffic) transmission and supporting services such as browsing or voice (VoNR).   I. Ethernet Preamble and Frame Start Delimiter will not be sent through the 5GS, where: For uplink traffic, the UE will strip the preamble and Frame Check Sequence (FCS) from the Ethernet frame. For downlink traffic, the PDU session anchor will strip the preamble and Frame Check Sequence (FCS) from the Ethernet frame.   II. MAC and IP Addresses: The 5GC will not assign MAC or IP addresses to the UE in the PDU session. The PSA should store the MAC address received from the UE and associate it with the corresponding PDU session.   III. SMF and VLAN: The SMF in the 5GC can receive a list of allowed VLAN tags (up to 16 VLAN tags) from the DN-AAA, or it can configure the allowed VLAN tag values ​​locally. The SMF can also configure VLAN processing instructions (e.g., LAN tags to be inserted or deleted, S-TAGs to be inserted or deleted). Considering this, the SMF determines the VLAN processing method for the PDU session and instructs the UPF to accept or discard UE traffic based on the allowed VLAN tags, and process VLAN tags through PDR (outer header removal) and FAR (outer header creation for UPF application forwarding policy), for example: The UPF can insert (for uplink traffic) and remove (for downlink traffic) S-TAGs on the N6 or N19 or internal interface "5G VN Internal" for processing traffic to and from the UE. When there is no VLAN in the traffic to the UE, the UPF can insert (for uplink traffic) and remove (for downlink traffic) VLAN tags on the N6 interface. When the UPF processes uplink or downlink traffic from the UE, the UPF can discard any UE traffic that does not contain any allowed VLAN tags.   IV. Traffic Steering (Forwarding): In 5G, this can be used to steer traffic to N6-LAN, and also for N6-based traffic forwarding related to 5GVN services as described in Section 5.29.4. Except for specific conditions related to PDU session support over W-5GAN as defined in TS 23.316 [84], the UPF shall not remove VLAN tags sent by the UE, nor shall it insert VLAN tags for traffic sent to the UE; where: PDU containing VLAN tags can only be exchanged within the same VLAN through the PDU session anchor. The UE can obtain the MTU of the Ethernet frame payload it should consider from the SMF during PDU session establishment (see Section 5.6.10.4).   V. Connection Mode: The UE can connect to its connected LAN in bridge mode; therefore, the uplink (UL) source and destination MAC addresses of different frames may be different within the same PDU session. The downlink (DL) destination MAC addresses of different frames may also be different within the same PDU session.   VI. IP Allocation and MAC Addresses: Entities on the LAN connected to the 5GS may have IP addresses allocated by the DN, but the IP layer is considered an application layer and is not part of the Ethernet PDU session. The 5GS does not support the use of MAC addresses or (if VLANs are applied) combinations thereof across multiple PDU sessions for the same DNN S-NSSAI.   VII. UE Authentication: In the R18 specification version, only the UE connected to the 5GS is authenticated, not the devices behind it; furthermore: The R18 specification version does not guarantee a loop-free Ethernet network. Deployment scenarios need to be verified individually to ensure that Ethernet loops are avoided. The R18 specification version does not guarantee that Ethernet will respond correctly and quickly to topology changes. Deployment scenarios need to be verified individually to understand how they respond to topology changes.  

  URLLC (ultra-reliable low latency communications) is defined by 3GPP for 5G (NR) and aims to meet the extremely demanding requirements for latency and availability of services. 5G (NR) mobile networks supporting URLLC must provide low latency and minimize packet loss and out-of-order delivery.   I. URLLC Definition: ITU-R specifies a one-way user plane latency of 1 millisecond in 5G (NR) systems. This can be further defined by breaking down the URLLC acronym and analyzing its requirements:   • Ultra-high reliability requirements: Ranging from 99.99% for process monitoring to 99.999999% for industrial robots. This covers transmission packet loss and packet reordering – both of which need to be as low as possible. • End-to-end low latency communication requirements: Application layer latency below 0.5-50 milliseconds, and 5G wireless interface latency below 1 millisecond.   II. URLLC Applications: Various application scenarios can fully utilize its ultra-reliable low latency, including:   Augmented reality/virtual reality and haptic interaction technologies allow users to experience artificially created realities or obtain additional information by overlaying real-world information. This technology has been applied in the entertainment industry, industrial applications such as warehouse management and field maintenance, and is expected to be applied in critical areas such as enhanced surgery.   As autonomous vehicles gradually replace human drivers, transportation will also benefit from URLLC. Vehicles and infrastructure utilize advanced sensors, artificial intelligence, and near-instantaneous communication technologies to significantly improve efficiency and safety. The main advantages of low latency are reflected in remote driving and sensor sharing.   Smart grids are improving power distribution, utilizing communication capabilities to achieve better power balance and detect and mitigate faults.   Motion control covers machine tools, printing, and packaging machinery. URLLC is expected to control the movement and rotating parts of machinery in a synchronized manner, thereby achieving high efficiency.   III. URLLC Standards   3GPP took the first step towards URLLC in its first 5G release, R15; its air interface was defined with a latency of 1 millisecond and a reliability of 99.999%. In NSA (Non-Standalone) network architecture, the core network and wireless signaling must rely on LTE, which cannot meet the end-to-end latency requirements of URLLC. 3GPP R16 defines the SA (Standalone) 5G architecture, which has an independent 5G core network and can operate without LTE, providing two important functions—network slicing and mobile edge computing (MEC).   IV. URLLC Driving Factors: End-to-end latency typically depends on network performance and the distance between the server and user equipment, both of which are optimized to accommodate URLLC applications, including:   4.1 Air Interface: Low latency optimization in 5G is achieved through flexible subcarrier spacing, scheduling optimized for low latency, and uplink grant-free transmission. Differential multiplexing, robust control channels, and HARQ enhancements are crucial for improving reliability.   With new subcarrier spacing, the subcarrier spacing can be adjusted from 15kHz to 240kHz. Larger spacing means shorter symbol duration, thus shortening the scheduling interval. The scheduling algorithm can schedule micro-timeslots, further reducing transmission latency. To avoid delays caused by requesting transmission resources, uplink grant-free transmission can be used.   Differential multiplexing uses multiple antennas at the receiver and transmitter to create independent spatial signal propagation paths, thus preventing single-link failures. To ensure reliability, NR aims to build robust control channels with low bit error rates; introducing new coding and using low modulation coding schemes (MCS) for transmission. The HARQ retransmission mechanism is enhanced by pre-allocating retransmission resources, thereby reducing latency and improving reliability.   4.2 Network Slicing: This is a key feature of 5G, allowing resources to be allocated on demand according to the service needs of different users. Resources are flexibly partitioned and isolated from the influence of other users, creating end-to-end logical channels. The required QoS for user slices can be configured on demand from the wireless interface to the core network. For example, for the same user, 5G can create a high-capacity video streaming slice for enhanced mobile broadband (eMBB) services without strict latency constraints; at the same time, it can also create a low-latency slice for ultra-reliable low-latency communication (URLLC) for robot control. Business Functionality - This feature is only applicable to the Standalone (SA) architecture of the 5G core network.   4.3 Mobile Edge Computing significantly reduces latency and improves reliability by hosting user applications on the "edge side" of the Cloud Radio Access Network (C-RAN). Therefore, transmission latency primarily depends on wireless access. Hosting at the edge avoids traversing the core network and reduces the number of nodes in the data path, thereby improving reliability.