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!
Why is the actual mobile phone (UE) data rate far lower than what carriers advertise? (Continued)
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.

2026

01/29

5G (NR) Terminal Supported PDU Sessions (Cont. 2)
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.

2026

01/28

5G (NR) Terminal Supported PDU Sessions (Continuation 1)
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.  

2026

01/27