logo
Send Message
Shenzhen Olax Technology CO.,Ltd
About Us
Your Professional & Reliable Partner.
Shenzhen OLAX Technology Co.,Ltd , which Located in Shenzhen, China. OLAX Technology established in 2010, It is a leading domestic supplier of wireless communication terminal technology solutions and equipment.Our main products are 4g C P E WIFI routers, USB WIFI dongles, modems. Pocket WIFI hotspot.G S M and C D M A fixed wireless telephones, terminals, Moreover, we support card lock, network lockand SIM card security.We have a core team with more than ten years of experience in R & D, sales ...
Learn More

0

Year Established

0

Million+
Employees

0

Million+
Customers Served

0

Million+
Annual Sales
China Shenzhen Olax Technology CO.,Ltd HIGH QUALITY
Trust Seal, Credit Check, RoSH and Supplier Capability Assessment. company has strictly quality control system and professional test lab.
China Shenzhen Olax Technology CO.,Ltd DEVELOPMENT
Internal professional design team and advanced machinery workshop. We can cooperate to develop the products you need.
China Shenzhen Olax Technology CO.,Ltd MANUFACTURING
Advanced automatic machines, strictly process control system. We can manufacture all the Electrical terminals beyond your demand.
China Shenzhen Olax Technology CO.,Ltd 100% SERVICE
Bulk and customized small packaging, FOB, CIF, DDU and DDP. Let us help you find the best solution for all your concerns.

Quality Portable Wifi Routers & Wireless Wifi Routers Manufacturer

Find Products That Better Meet Your Requirements.
Cases & News
The Latest Hot Spots
USIM in 5G (NR) system (1)
1.UE and UICC In the mobile communication system defined by 3GPP (3rd Generation Partnership Project), the user's terminal (UE) device is composed of: ME (mobile equipment) + UICC (Universal Integrated Circuit Card); where UICC is a Physical cards that are tamper-proof and resistant to software and hardware attacks. 2. UICC and USIM UICC can contain multiple applications, one of which is USIM; USIM securely stores and processes all sensitive data related to the user and home network. USIM is under the control of the home network operator; the operator selects the data to be configured in the USIM before issuance and remotely manages the USIM in the user's device through the OTA (over-the-air) mechanism. 3.USIM in 5G 3GPP defines USIM for the 5G system in Rel-15 for access and use in 3GPP and non-3GPP networks, allowing UE (user equipment) external data networks. USIM is defined in Rel-16 as network slice specific authentication. 4.First-time authentication is a mandatory procedure to allow UE (user equipment) to access 3GPP or non-3GPP networks. EAP-AKA' or 5G-AKA are the only authentication methods that allow primary authentication and the subscription credentials are always stored in the USIM when the terminal supports 3GPP access functionality. For primary authentication based on AKA, the mutual authentication performed in the USIM and the generation of the key material (integrity key IK and confidentiality key CK) sent by the USIM to the ME remain unchanged compared to 3G, 4G and Meets 3GPP TS 33.102 specification [3]. Changes in 5G Primary Authentication USIM include storing new security context and additional keying material in USIM (depending on the USIM's configuration). 4.1 5G support If the USIM supports storing 5G parameters, the ME will store the new 5G security context and the new keys defined for the 5G key hierarchy (i.e. KAUSF, KSEAF and KAMF) in the USIM. USIM can store a 5G security context for 3GPP access networks and a 5G security context for non-3GPP access networks. Storing the security context and key material in the USIM ensures faster reconnection when roaming (UICC moves from one ME to another). 4.2 NPN support Authentication in private networks (called independent non-public networks) can rely on the EAP framework supported by the 5G system; user equipment and service networks can support 5G AKA, EAP-AKA' or any other key generation EAP authentication method, where: ·When using AKA-based authentication methods, clause 6.1 of 3PPTS 33501[1] applies. ·When selecting an EAP authentication method other than EAP-AKA', the selected method determines the credentials required in the UE and network. How these credentials for EAP methods other than EAPAKA' are stored and processed within the UE is beyond the scope. But to ensure a high level of security for access to private networks, private network operators may decide to require the presence and use of a UICC containing USIM applications in order to securely store and process subscription credentials for EAP methods such as EAP-AKA' or EAP-TLS . 5. Secondary authentication This is an optional authentication based on EAP, conducted between UE (user equipment) and DN (external data network). Although the choice of EAP authentication method and credentials is beyond the scope of 3GPP, external data networks may decide to protect access to their DN by performing strong authentication thanks to the EAP-AKA' or EAP-TLS authentication method, UICC in the user device The presence of USIM on the DN securely stores and processes the credentials used to access the DN. Network Slice Specific Authentication Using network slice specific authentication between the user device and the AAA (Authentication, Authorization and Accounting) server to access the network slice is optional. Network slice specific authentication is based on the EAP framework and its user ID and credentials are different from the 3GPP subscription credentials. It follows the mandatory primary certification. Stakeholders deploying slices may decide to install USIM on the UICC of user devices to ensure a high level of security to access their slices and prevent the emergence of unauthorized users.
SIM Technology Innovation: An In-Depth Look at eSIM and vSIM
01.eSIM   eSIM, known as Embedded-SIM, or Embedded SIM, is a programmable, electronic SIM card technology whose main feature is that it does not require a physical slot, but rather an embedded chip that is integrated directly into the device's circuit board or inside other devices. Hardware part_     Integrated Circuit (IC) Chip: At the heart of the eSIM is a small IC chip that is built into the device's motherboard, similar to a physical SIM card. It contains the necessary hardware (CPU, ROM, RAM, EEPROM and serial communication unit) for storing and processing SIM data.   Software part_     Operating System (OS): The eSIM chip runs a dedicated operating system, often referred to as eUICC (Embedded Universal Integrated Circuit Card), which manages the SIM's functions, including data storage, secure processing and communication.     eSIM Production Process   ① Chip Manufacturing ② Chip testing ③ Integration into devices ④ Embedded software loading ⑤ Functional testing and verification   Virtual SIM (vSIM) is a SIM card technology without a physical form factor that allows devices to realize communication functions through software, including SoftSIM, CloudSIM, and others.   02.Virtual SIM (vSIM)   Virtual SIM (vSIM) is a SIM card technology without a physical form factor that allows devices to realize communication functions through software, including SoftSIM, CloudSIM, and others.   SoftSIM controls the information written to SoftSIM through the terminal provider, and the user purchases and uses communication services directly through the software without the intervention of the operator, which cuts off the direct connection between the user and the operator.   CloudSIM is a kind of SIM card function realized based on cloud computing technology, where users use network services on their devices through cloud services.   03.SIM service activation process   CloudSIM integrates the traffic resources of each operator into the cloud, selects operators according to the signal and network quality of different regions, and pushes them to the terminals to provide users with the best network services. The inclusion of multiple operators facilitates users to flexibly choose more favorable packages.       Do you want to learn more about SIM cards and other communication topics? We will continue to share more about this! See you in the next issue!
Framed Routing: 5G Application Definition
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.

2026

02/03

5G SMF Support for Network Slice Instances
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).

2026

02/02

What should the MTU size be set to in 5G to avoid packet fragmentation?
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.

2026

01/30