Deployment Overview of Tencent Cloud Jutong Linux SDK
Download
Focus Mode
Font Size
Last updated: 2026-09-21 16:45:11
AI-Translated
Applicable product: Multiple Network Acceleration (Tencent Cloud Jutong) Linux SDK.
Applicable scenarios: in-vehicle/robotics platforms that require multi-cellular link aggregation, such as L4 autonomous driving, robotaxis, and embodied intelligent robots.
Background
The Jutong Linux SDK runs as a managed process and provides an HTTP API at 127.0.0.1:9801 on the local machine after installation. The service side uses the API to deliver configurations and start or stop acceleration. For installation and invocation, see Quick Start. One of the core SDK configuration items is interfaces, which is the list of interfaces participating in multi-network aggregation. In automotive and embodied intelligence scenarios, the cellular link (SIM card) and the compute unit running the SDK are often not on the same board: the SIM card is in the T-Box, while the compute is in the domain controller.
Therefore, before integration begins, you must answer two questions:
1. Which OS is the SDK installed on? (The T-Box OS or the domain controller OS)
2. What interface names should be entered in interfaces? (Physical cellular network interfaces or VLAN subinterfaces)
The answers to these two questions are interrelated and directly determine the configuration workload for the underlying software vendor. This document provides the determination method and two standard forms.
How to Determine
The multi-link capability of the SDK is built on one premise: in the Linux OS where the SDK runs, each link to be aggregated appears as an independent network interface, and this interface has an independent IP address and an independent next-hop gateway.
This premise comes from the SDK's policy-based routing mechanism. The policy-based routing management module built into the SDK is based on the source IP address of the WAN interface, allowing packets with a specified source IP address to be sent out through the corresponding interface. Without such policy-based routing, all packets will follow the default route, and the SDK will be unable to send and receive messages through multiple network interfaces.
79: from all fwmark 0x1/0xf lookup 180 # Redirected business traffic
80: from 192.168.81.80 lookup 100 # Source IP of link 1
81: from 10.221.7.233 lookup 101 # Source IP of link 2
# ip route ls table 100
default via 192.168.81.1 dev ath0
# ip route ls table 101
default via 10.21.5.17 dev rmnet_mhi0.1
Note:
The interface name of the second link, rmnet_mhi0.1, is itself a subinterface. This indicates that the SDK's requirement for interfaces is at the logical level: as long as an interface has an independent IP address and an independent next-hop gateway, physical interfaces and VLAN subinterfaces are equivalent to the SDK.
This yields the criterion for form selection:
If all links to be aggregated are already independent network interfaces in the same OS, select Form 1: the SDK is installed on this OS.
If the links to be aggregated are distributed across multiple hardware units and no single unit can see all of them, select Form 2: move the aggregation point up to the domain controller and map the links into it.
Two Standard Forms
Form 1: Integration in T-Box (Link-Local Visibility)
1. Applicable Conditions
The T-Box itself serves as the dual-link carrier, and the two links are already independent network interfaces within the T-Box OS:
DSDA (Dual SIM Dual Active): two SIMs can be online simultaneously and each establish its own data connection.
Dual-module: The T-Box has two independent cellular modules built in.
Cellular + other links: for example, 5G + Wi-Fi, 5G + satellite.
It is also required that the T-Box be capable of hosting the SDK: its computing power, memory, kernel version, and system permissions must all meet the Linux SDK hardware adaptation requirements.
2. Configuration Method
The SDK is installed on the T-Box. In the interfaces field, directly enter the interface names of the two physical cellular network interfaces. For complete parameter descriptions, see API Overview > Configuring Acceleration Parameters.
curl -X POST 'http://127.0.0.1:9801/api/v2/client/mp-speeder' \\
-H 'Content-Type: application/json' \\
-d '{
"dataKey":"<Device key obtained from the Tencent Cloud console>",
"interfaces": ["rmnet_mhi0","rmnet_mhi1"],
"scheduleMode":"bonding"
}'
The interface name depends on the actual device configuration. Common forms include rmnet_, usb0/usb1, wwan0/wwan1, and eth. You can run the ip addr command to confirm the interface name.
3. Benefits and Costs
Advantages: The link path is the shortest and requires no network configuration across hardware units. The service side (domain controller/IVI system) requires no modification, and the SDK can take over traffic within the T-Box by using traffic steering rules.
Cost: The SDK is bound to the T-Box model. Each time the T-Box vendor or model is changed, integration, verification, and hardening must be redone. If a project involves multiple T-Box vendors or has a future model change plan, this cost will recur.
Form 2: Domain Controller Integration + Link Mapping (Link-Remote Visibility)
1. Applicable Conditions
The aggregation point must be moved up to the domain controller when any of the following conditions occurs:
When there are two or more T-Boxes, each with a single SIM, any T-Box can only see its own link and cannot perform aggregation within the T-Box.
The T-Box vendor/model is not fixed: consolidate the SDK on the domain controller so that the device-side integration solution does not need to be redone when vendors are switched.
Insufficient T-Box computing power or system permissions: the SDK's requirements for computing power, kernel, TUN, iptables, and persistence cannot be met.
A key value of Form 2 is that the same device-side integration solution can cover different link bearer topologies. There are two common variants:
1 × T-Box with dual modules/DSDA (Dual SIM Dual Active): both links originate from the same communication unit.
2 × T-Box, each with 1 SIM: the two links originate from two independent communication units.
It is completely equivalent from the SDK's perspective. As long as each link can be mapped to an independent interface within the domain controller OS (with an independent IP address and an independent next-hop gateway), no changes are required to the SDK-side integration method or the interfaces configuration. The SDK only recognizes interfaces and does not care how many physical communication units the links come from. For projects that need to maintain a consistent solution across multiple hardware configurations, this can significantly reduce adaptation and maintenance costs.
2. Link Mapping Method
The cellular links on the T-Box need to be mapped to independent interfaces within the domain controller OS. There are two approaches:
VLAN subinterfaces (recommended): suitable when the automotive Ethernet is a shared link or when traffic needs to be relayed through a zone controller/central gateway. In the interfaces field, enter the subinterface names, such as ["eth0.75", "eth0.76"].
Independent physical Ethernet ports: suitable when the domain controller has sufficient free Ethernet ports and can be directly connected to each T-Box point-to-point. In the interfaces field, enter the physical port names, such as ["eth1", "eth2"].
The VLAN approach solves the problem of carrying multiple logical links over a single physical Ethernet link. In automotive Ethernet, traffic is typically aggregated through a zone controller (ZCU)/central gateway, and there are no multiple independent dedicated physical lines between the domain controller and the T-Box. VLAN is a means, not an end. If physical Ethernet ports are sufficient, using physical ports directly is equally feasible and completely equivalent from the SDK's perspective.
3. Configuration Method
The SDK is installed on the domain controller, and business processes on the same domain controller call the SDK through 127.0.0.1:9801. In the interfaces field, enter the VLAN subinterface names:
curl -X POST 'http://127.0.0.1:9801/api/v2/client/mp-speeder' \\
-H 'Content-Type: application/json' \\
-d '{
"dataKey":"<Device key obtained from the Tencent Cloud console>",
"interfaces": ["eth0.75","eth0.76"],
"scheduleMode":"bonding"
}'
4. Prerequisites Checklist for Implementation
Form 2 involves network configuration across hardware units and is typically implemented by the domain controller base software vendor. Before starting, confirm the following items one by one:
1. The T-Box side maps each cellular link to a different VLAN ID (verification: confirmed by the T-Box side configuration).
2. VLAN Trunk passthrough is established across all automotive Ethernet hops (domain controller ↔ ZCU ↔ T-Box), verified by end-to-end connectivity testing.
3. Each VLAN subinterface has an independent IP address in the domain controller OS (verification: run "ip addr show eth0.75" and confirm that an address is present).
4. Each VLAN subinterface has an independent next-hop gateway and can be discovered (verification: run "ip route" and confirm that the corresponding default route is visible).
5. The domain controller OS supports multiple default routes and can select the preferred route based on metric or support ECMP (verification: routing table check).
6. The domain controller meets the SDK hardware and software requirements. For verification, see Hardware Adaptation Requirements.
Items 3 and 4 are the most critical. The SDK's policy-based routing is built on "interface source IP address + next-hop gateway". If either is missing, the link cannot participate in aggregation. Note: The prerequisite for the SDK to manage policy-based routing is that the corresponding gateways of multiple links can be discovered.
If the domain controller OS routes are managed centrally by the customer and the SDK should not be involved, you can disable the SDK's built-in policy-based routing module and have the base software implement the above policy-based routing. In this case, ensure that the policy-based routing for traffic steering has a higher priority than other system routes. For how to enable or disable this feature, see API Overview > SDK Built-in Policy-Based Routing Management.
5. Summary of Domain Controller Environment Requirements
Kernel: version 4.4 or later, and the TUN module must be enabled during firmware compilation.
iptables: must be supported. Otherwise, traffic steering cannot be performed.
Policy-based routing: The system must support it. The system must also support multiple default routes.
CPU: AES instruction acceleration must be supported. The system cannot run on MIPS architectures. Cortex-A72/A53/A7 performance is relatively weak.
Memory: It is recommended to reserve > 100 MB (minimum 50 MB).
Storage: It is recommended to reserve > 200 MB.
Persistence: /usr/local/etc/mp-speeder (configuration) and /var/log (logs) must be non-volatile, and their contents must remain unchanged after firmware upgrades or reboots.
Process management: Support one of systemd / procd / rc.local, or have the vendor write a custom startup script.
Comparison of the Two Forms
Dimension
Form 1: T-Box Integration
Form 2: Domain Controller Integration
SDK runtime location
T-Box OS
Domain controller Linux SOC
Fill in interfaces.
Physical cellular network interfaces, such as ["rmnet_mhi0","rmnet_mhi1"]
VLAN subinterfaces, such as ["eth0.75","eth0.76"]
Hardware prerequisites
The T-Box is DSDA/dual-module, and its computing permission meets the requirement.
The domain controller computing permission is satisfied; the automotive Ethernet supports VLAN Trunk.
Support for 2 x T-Box
Not supported.
Supported
Impact of T-Box model change
Reintegration and verification required.
The device-side solution remains unchanged.
Network configuration workload
Low (link-local visible)
Medium (requires cross-unit VLAN mapping and policy-based routing)
Service-side modification
None (the T-Box functions as a transparent gateway to take over)
Business processes need to call the local SDK API.
Primary responsible party
T-Box vendor
Domain controller base software vendor + service party
No difference on the cloud side: The two deployment forms are completely identical in the cloud. The SDK encapsulates service traffic into QUIC tunnels and sends them to the Tencent Cloud aggregation gateway, which terminates the tunnels and routes traffic back to the origin. The differences between deployment forms exist only on the vehicle side and do not affect cloud-side access methods, billing methods, or device management methods.
Quick Reference for the interfaces Field
interfaces is a required field of type [string] that defines the list of interfaces participating in multi-network aggregation. For the complete field definition, see API Overview > Configure Acceleration Parameters.
Form 1 (integrated in T-Box): Enter the physical cellular network interface name. Example:
"interfaces": ["rmnet_mhi0","rmnet_mhi1"]
Form 2 (integrated in domain controller): Enter the VLAN subinterface name. Example:
"interfaces": ["eth0.75","eth0.76"]
In both forms, the interface name depends on the actual device configuration and can be confirmed by running the ip addr command. There is only one requirement: each interface in the list must have an independent IP address and an independent next-hop gateway.
Common Misconceptions
Misconception 1: Treating Dual SIM Dual Standby (DSDS) as Dual SIM Dual Active (DSDA)
This is the most common pitfall in Form 1. With dual SIM dual standby, only one SIM is running data services at any given time, so only one usable data network interface exists in the OS, making aggregation impossible.
The criterion is not "the device has two SIM cards". Instead, run ip addr and check that both cellular network interfaces are UP and each has an independent IP address. Only when this condition is met can the links be aggregated.
Misconception 2: Entering the VLAN's Physical Parent Interface in interfaces
In Form 2, enter ["eth0"] instead of ["eth0.75","eth0.76"]. The SDK will recognize only one link, policy-based routing for multiple links cannot be established, and acceleration degrades to a single link. You must enter the subinterface name.
Misconception 3: VLAN Subinterfaces Have No Independent Gateway
If a subinterface has an IP address but no corresponding next-hop gateway, or if the gateway cannot be discovered by the SDK, the link cannot participate in aggregation. To check:
ip route # Each link should have a corresponding default route
ip rule # After SDK policy-based routing is enabled, rules in the format "from <interface IP> lookup <table ID>" should appear
Misconception 4: Using Full Traffic Mirroring on the Vehicle Side
Full traffic steering is configured on the LAN port, which requires the network interface name to contain "lan". Network interfaces on the vehicle side usually do not have the "lan" prefix, in which case full traffic steering falls back to the first bridge port, resulting in unpredictable behavior.
Recommended practice: Use specific traffic steering rules for precise control. Specify the IP address network segment of downstream devices through srcIP, which is equivalent to "steering all traffic from specific ports". For the definition of traffic steering rule fields, see API Overview > Traffic Steering.
curl -X POST 'http://127.0.0.1:9801/api/v2/route/businessRoute' \\
Whether traffic steering has taken effect can be verified through counters:
iptables -t mangle -nvL # Check whether the pkts/bytes of the corresponding rules keep increasing
Misconception 5: Ignoring MTU and MSS
A VLAN tag occupies an additional 4 bytes, and the acceleration tunnel itself also incurs encapsulation overhead. Note:
Keep the MTU consistent across all automotive Ethernet hops (domain controller ↔ ZCU ↔ T-Box) to avoid fragmentation at intermediate nodes.
For UDP traffic, the packet size must be controlled: it is recommended that IPv4 packets not exceed 1289 bytes and IPv6 packets not exceed 1277 bytes.
UDP packet fragmentation doubles the number of packets, significantly affecting forwarding performance on both the device side and the gateway side. Packet loss is more likely in weak network conditions, and in extreme cases, multi-network acceleration may result in negative optimization.
Misconception 6: Calling start Directly After Modifying the Configuration
After configuration changes (such as replacing the dataKey, adjusting interfaces, or modifying traffic steering rules), call the restart acceleration API to make the new configuration take effect.
curl -X POST 'http://127.0.0.1:9801/api/v2/client/mp-speeder/restart'
The configuration is persisted to /usr/local/etc/mp-speeder/ and is automatically loaded after the SDK restarts, so no repeated configuration is required.
Verifying the Availability of the Acceleration Channel
After the SDK starts, it creates a virtual network interface named mp_tun0. You can directly specify this interface to verify tunnel connectivity.
curl --interface mp_tun0 https://www.qq.com
A normal HTML response indicates that the acceleration tunnel is reachable. At the same time, poll the status API until ready == true:
