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!
Characteristics of the Three SSC Modes in 5G
3GPP defines three modes for UE Mobility and Service Continuity Management (SSC) in 5G (NR) systems, each with the following characteristics:   I. SSC Mode 1: For PDU sessions in this mode, the UPF used as the PDU session anchor at session establishment remains valid, regardless of the access technology (e.g., access type and cell) subsequently used by the UE to access the network. Specifically:   For PDU sessions of IPv4, IPv6, or IPv4v6 type, IP continuity is supported regardless of changes in UE mobility. In Release 18, when IPv6 multihoming or UL CL is applied to a PDU session in SSC Mode 1, and the network (based on local policies) allocates additional session anchors for that PDU session, these additional PDU session anchors may be released or allocated, and the UE does not expect to retain additional IPv6 prefixes for the lifetime of the PDU session. SSC Mode 1 can be applied to any PDU session type and any access type. UEs supporting PDU connectivity should support SSC Mode 1.   II. SSC Mode 2 If a PDU session in this mode has only one session anchor, the network can trigger the release of that PDU session and instruct the UE to immediately establish a new PDU session with the same data network. The triggering condition depends on operator policies, such as application function requests, load status, etc. When establishing a new PDU session, a new UPF can be selected as the PDU session anchor. Otherwise, if the SSC Mode 2 PDU session has multiple PDU session anchors (e.g., multi-homed PDU sessions or UL CL applied to SSC Mode 2 PDU sessions), additional PD session anchors can be released or allocated; furthermore:   SSC2 mode can be applied to any PDU session type and any access type. SSC Mode 2 is optional in the UE.   ---UEs relying on SSC Mode 2 functionality will not function if SSC Mode 2 is not supported.   ---In UL CL mode, the UE does not participate in the reallocation of PDU session anchors, therefore the UE is unaware of the existence of multiple PDU session anchors.   III. SSC Mode 3 For PDU sessions in this mode, the network allows the UE to establish a connection to the same data network through a new PDU session anchor point before the connection between the UE and the previous PDU session anchor point is released.   When the triggering conditions are met, the network decides whether to select a PDU session anchor point UPF suitable for the UE's new conditions (e.g., network access point). In Release 18, SSC Mode 3 applies only to IP PDU session types and any access type. For IPv4, IPv6, or IPv4v6 type PDU sessions, the following rules apply during PDU session anchor point changes:   a. For IPv6 type PDU sessions, a new IP prefix anchored to the new PDU session anchor point can be assigned within the same PDU session (subject to IPv6 multihoming as specified in TS23.501 5.6.4.3), or​ b. A new IP address and/or IP prefix can be assigned within the new PDU session established when the UE is triggered. After a new IP address/prefix is ​​assigned, the old IP address/prefix will be retained for a period of time, during which the UE will be informed via NAS signaling (as described in section 4.3.5.2 of TS 23.502[3]) or router announcement (as described in section 4.3.5.3 of TS 23.502[3]), after which it will be released.   If the SSC mode 3 PDU session has multiple PDU session anchors (e.g., multihomed PDU sessions or UL CL applied to SSC mode 3 PDU sessions), additional PDU session anchors can be released or assigned. Whether the UE supports SSC mode 3 is optional.   ----If the UE does not support SSC mode 3, functions that rely on SSC mode 3 will not work;

2026

01/22

5G System QoS Key Parameters
In the 5G (NR) system, QoS is the finest granularity unit for differentiating QoS (Quality of Service) in a terminal (UE)'s PDU session. Each QoS flow is identified by a unique identifier called QFI (QoS Flow ID), which is also unique within the PDU session. QoS typically includes the following parameters:   1. GFBR (Guaranteed Flow Bit Rate) Application: Applicable only to GBR and delay-critical GBR QoS flows. Function: Defines the minimum bit rate that the QoS flow can achieve when measured over an averaging window. Uplink and Downlink: Specifies the GFBR for the uplink and downlink separately.   2. MFBR (Maximum Flow Bit Rate) Application: Applicable only to GBR and delay-critical GBR QoS flows. Function: Defines the maximum bit rate that the QoS flow can achieve when measured over an averaging window. Uplink and Downlink: Specifies the MFBR for the uplink and downlink separately.   3. Session Maximum Allowed Bit Rate (Session-AMBR) Function: Defines the sum of the maximum allowed bit rates of all Non-GBR QoS flows in a specific PDU session. Execution: Managed by the User Plane Function (UPF) of the relevant PDU session.   4. Terminal (UE) Maximum Allowed Bit Rate (UE-AMBR) Function: Defines the sum of the maximum allowed bit rates of all non-GBR QoS flows of a specific UE. Execution: Managed by the serving base station.   5. Maximum Packet Loss Rate Application: Applicable only to GBR and delay-critical GBR QoS flows, and only for voice media in 3GPP specification Release 15. Function: Defines the maximum tolerable packet loss rate in the uplink and downlink.   6. Notification Control Function: Indicates whether the base station should notify the SMF if the QoS flow fails to meet its GFBR. Behavior: If the GFBR is not met, the base station will continue to try while notifying the SMF, which may reconfigure or release the QoS flow.   7. Reflective QoS Attribute (RQA) Function: Indicates whether packets in the QoS flow require the UE application to use reflective QoS, which involves learning uplink rules from the downlink pattern. Scope of application: Used for PDU sessions of IP or Ethernet data packets (not applicable to unstructured data packets).

2026

01/21

SSC – Ensuring PDU Session Continuity for 5G Terminals
  To ensure that the terminal's (UE) PDU session remains unchanged during mobility or network changes (handover), guaranteeing a seamless user experience, 3GPP has defined SSC (Session and Service Continuity) for 5G (NR)! Through SSC management, sessions can achieve smooth handover without service interruption, which is crucial for various applications such as VoIP, gaming, and the Internet of Things.   I. PDU SSC: The 5G (NR) system architecture defined by 3GPP supports PDU session and service continuity, meeting the various continuity requirements of different applications/services for the terminal (UE). The 5G system supports different SSC (Session and Service Continuity) modes. The SSC mode associated with a PDU session remains unchanged throughout its lifecycle.   II. SSC Modes: Currently (R18 version), there are three modes defined for SSC (Session and Service Continuity): In SSC Mode 1, the network maintains the connection service provided to the UE. For IPv4, IPv6, or IPv4v6 PDU sessions, the IP address will be retained. In SSC Mode 2, the network can release the connection service provided to the UE and release the corresponding PDU session. For IPv4, IPv6, or IPv4v6 types, the release of the PDU session will result in the release of the IP address assigned to the UE. In SSC Mode 3, changes in the user plane are visible to the UE, while the network ensures that the UE's connection is not interrupted. Before terminating the previous connection, a connection is established through a new PDU session anchor to ensure better service continuity. For IPv4, IPv6, or IPv4v6 types, in this mode, the IP address is not retained when the PDU session anchor changes. In the R18 specification version, the process of adding/removing additional PDU session anchors in PDU sessions used for local access DN is independent of the PDU session's SSC mode.   III. Mode Selection: In 5G, the SSC mode adopted by the terminal is determined by the SMF based on the SSC modes allowed in the user subscription (including the default SSC mode) and the PDU session type, and also considers the SSC mode requested by the UE if present. The operator can provide the UE with an SSC mode selection policy (SSCMSP) as part of the URSP rules (see Section 6.6.2 of TS 23.503 [45]). The UE should use the SSCMSP to determine the session type and service continuity mode associated with the UE's application or group of applications, as described in Section 6.6.2.3 of TS 23.503 [45].   If the UE does not have an SSCMSP, the SSC mode can be selected based on the UE's local configuration, as described in TS 23.503 [45] (if applicable). If the UE cannot select an SSC mode, the UE requests a PDU session without providing an SSC mode.

2026

01/20