Click the blue text aboveTalks Lab
Get more information on automotive network security
Most intelligent vehicles are equipped with vehicle networking functions, which mainly consist of three parts: mobile APPs, cloud backend servers (TSP), and in-vehicle central entertainment systems/T-BOX/gateway devices.
Vehicle Networking System Diagram
Various data in the vehicle is uniformly collected by in-vehicle devices (such as T-BOX) and transmitted to the cloud TSP platform via 4G/5G mobile communication signals. After data processing, the TSP platform transmits the signals to the mobile APP, which can display relevant vehicle information such as location, battery level, temperature, etc.
Similarly, control commands from the mobile APP, such as starting the vehicle, opening the doors, and turning on the air conditioning, are also transmitted back to the vehicle in this manner.
In this process, the TSP platform connects to the in-vehicle terminal devices, the mobile APP, and may also need to connect to third-party monitoring platforms and content service providers, thus placing TSP in a core position within the vehicle networking ecosystem.
01
Introduction to TSP
TSP stands for Telematics Service Provider, indicating a remote service provider.
TSP connects hardware, software, and vehicle manufacturers, primarily responsible for data collection and supply between vehicles and service providers, offering a variety of services to vehicle owners, including location services, navigation services, communication services, social services, entertainment services, remote maintenance services, and safety services, thereby realizing vehicle networking.
TSP Platform System Diagram
The various service functions provided by the TSP platform are based on data, requiring extensive data exchange between vehicles and the TSP platform, mobile APPs and the TSP platform, and TSP and other platforms, necessitating the use of certain communication protocol standards.
02
HTTP vs. MQTT
There are various types of communication protocols between in-vehicle controllers, such as CAN, LIN, FlexRay, MOST, Ethernet, etc. These are all wired communications based on hard connections, and different controllers choose different communication methods based on data volume, real-time requirements, and cost considerations.
Vehicle networking mainly involves communication between the vehicle and the TSP backend, as well as communication between the TSP backend and mobile APPs, which is external communication based on wireless networks and can use either private or public protocols.
In the early days, vehicle networking services were simple, and using private protocols was more efficient. However, as the demand for vehicle networking service scenarios increased and the number of vehicles continued to grow, private protocols began to encounter many issues.
Firstly, all functions of private protocols (such as keep-alive, reconnection, offline messages, etc.) need to be custom-developed, making function definitions and version updates difficult to maintain. Additionally, private protocols require custom-developed terminal hardware for adaptation, leading to high costs, long cycles, and slow update iterations. Therefore, manufacturers gradually adopted public protocols, with HTTP and MQTT being commonly used public protocols.
2.1 Introduction to HTTP Protocol
HTTP stands for Hypertext Transfer Protocol, which was designed early on to enable universal, stateless data transmission between web services and browsers, suitable for traditional web applications and multimedia transmission.
HTTP is based on a request-response model and can provide encryption through HTTPS, ensuring high security. It can support rich content and multimedia, making it suitable for scenarios requiring frequent interactions and large data transmissions, widely used in websites and web applications, and can also be used for communication between vehicle networking TSP systems.
Due to the maturity of HTTP applications and the relatively simple nature of early vehicle networking services, HTTP could fully meet functional requirements.
However, as business expansion occurred, some drawbacks of HTTP became apparent. The request-response model used by HTTP is a synchronous message-passing model, where the requester sends a request message and the responder returns a response message. A direct connection must be established between the requester and responder, and the requester must wait for the responder’s response to continue execution. If the requester does not receive a response, it will affect its operation.
Moreover, the header information of HTTP is relatively large, leading to more data transmission. As the number of functions and terminals increases, the overall platform traffic grows exponentially, and request connections are prone to interruptions. This traditional request-response communication model has performance bottlenecks, making it difficult to efficiently meet new business data transmission requirements.
2.2 Introduction to MQTT Protocol
MQTT stands for Message Queuing Telemetry Transport, designed for lightweight publish-subscribe communication in low-bandwidth and unstable network environments. It is suitable for IoT and mobile applications, supporting real-time communication between devices.
MQTT uses a publish-subscribe model, which is an asynchronous message-passing model where the publisher publishes messages to a topic, and subscribers subscribe to topics of interest to receive messages. There is no direct connection between publishers and subscribers, allowing for one-to-many message delivery.
Compared to the request-response model of HTTP, after a publisher publishes a message, it does not need to wait for a response and can continue executing other tasks. Subscribers can process received messages at their convenience.
Additionally, subscribers can dynamically subscribe or unsubscribe from a topic at runtime, allowing the system to adapt to changing demands. It supports long connections, enabling devices to establish persistent connections with servers to receive or send messages in real-time.
MQTT supports encryption via TLS, with specific security depending on implementation and configuration. Although it may not be as secure as HTTP, MQTT’s lightweight design results in very small packet headers, effectively reducing data transmission overhead.
MQTT is commonly used in IoT devices, smart homes, and remote sensors, where network connections may be unstable and bandwidth limited. Vehicle networking is a typical application of IoT in the transportation system, sharing similar network characteristics, making MQTT very suitable for data communication between vehicles and the cloud in vehicle networking.
03
Features and Specifications of MQTT Protocol
MQTT can operate over TCP/IP or other network protocols that provide ordered, lossless, bidirectional connections, featuring the following characteristics:
1) Uses a publish/subscribe message model, providing one-to-many message distribution and decoupling for applications.
2) It is a message transmission method that is independent of the payload content, meaning it does not concern itself with the specific functions and meanings of messages.
3) Message delivery has three Quality of Service (QoS) levels:
The first QoS level is “at most once,” which makes the best effort to deliver messages based on the operating environment. Message loss may occur. This level can be used for environmental sensor data, where losing a single reading is not critical since the next data will be published soon.
The second level is “at least once,” ensuring message delivery but may result in duplicates.
The third level is “exactly once,” ensuring that information is delivered accurately once. This level can be used for billing systems, where duplicate or lost messages may lead to incorrect charges.
4) Low transmission overhead, minimizing protocol exchanges to reduce network traffic.
5) A mechanism to notify relevant parties when an abnormal disconnection occurs.
When application messages are transmitted via MQTT, they will have the associated QoS and Topic Name.
MQTT System Diagram
In MQTT, a client refers to the program or device that publishes or subscribes to messages;
The server refers to the program or device that acts as an intermediary between the publishing client and the subscribing client. The server is responsible for handling subscription and unsubscription requests from clients and forwarding messages that match client subscriptions.
3.1 Data Representation
Integer data in MQTT is represented in 16-bit big-endian order, meaning the high-order byte is transmitted before the low-order byte, with the high significant byte sent first during network transmission.
Text fields in MQTT control packets are represented using UTF-8 encoded strings.
Structure of UTF-8 Encoded Strings
Each string is prefixed with a 2-byte length field (String length), which indicates the number of bytes in the string, with a maximum value of 65535.
If the server or client receives a control packet containing incorrectly formatted UTF-8, it must close the network connection.
3.2 Control Packet Format
The MQTT protocol operates through a series of MQTT control packets, which are information packets sent over the network connection. MQTT defines 14 different types of control packets, one of which (the publish packet) is used to transmit application messages.
MQTT control packets consist of up to three parts: a fixed header, a variable header, and a payload, always arranged in the order shown in the table below:
MQTT Control Packet Structure
3.2.1 Fixed Header
Each MQTT packet contains a fixed header, which consists of the control packet type, flags, and remaining length, formatted as shown in the table below:
Fixed Header Format
The control packet type (Control Packet type) is located in Byte 1, bits 4-7, with 4 bits allowing for a maximum of 16 types.
Control Packet Types
The flags are located in Byte 1, bits 0-3, also 4 bits, containing specific flags for each type of control packet. If invalid flags are received, the receiver must close the network connection.
Flags
The remaining length starts from the second byte, indicating the number of remaining bytes in the current packet, including data in the variable header and payload. The remaining length does not include the bytes used for its own encoding.
The remaining length uses a variable-length encoding scheme, where a single byte can represent up to 127 bytes. Larger values are handled as follows:
The lowest 7 bits (bit 0-6) of each byte encode the data, while the highest bit (bit 7) indicates whether there are more subsequent bytes. Thus, each byte can encode 128 values and one “continuation bit.” The maximum number of bytes for the remaining length field is 4, meaning this field can have a variable length of 1-4.
Size of Remaining Length Field
The table above shows the range of remaining lengths. Single-byte representation is straightforward and easy to understand, while multi-byte representation is relatively complex. Here are two examples:
Example 1: The number 64 corresponds to the hexadecimal number 0x40, which uses only 1 byte. Since the highest bit (bit 7) of the remaining length single-byte representation must be 0, and 0x40’s highest bit is already 0, the final remaining length value remains 0x40, confirming that numbers less than 127 can be represented with a single byte.
Example 2: The number 321 can be converted to 65 + 2 * 128. It needs to be encoded as two bytes. The first byte is the low significant byte 65, corresponding to the hexadecimal number 0x41. Since the highest bit (bit 7) is 1, the first byte is actually 65 + 128 = 193, which is 0xC1. The highest bit is 1, indicating that there is at least one subsequent byte, so the second byte is 2, with the high byte indicating 2 * 128, which is 256. Therefore, the final remaining length value is 0xC1 0x02.
3.2.2 Variable Header
Some types of MQTT control packets contain variable header components, located between the fixed header and the payload. The content of the variable header varies by packet type. The Packet Identifier field in the variable header is shared among several packet types.
Many control packet types’ variable header components include a 2-byte Packet Identifier field. These control packet types are PUBLISH (where QoS > 0), PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK.
Packet Identifier Bytes
SUBSCRIBE, UNSUBSCRIBE, and PUBLISH (when QoS > 0) control packets must include a packet identifier. Each time a client sends a new packet of these types, it must assign an unused packet identifier.
If a client resends a specific control packet, it must use the same packet identifier when resending that packet.
PUBACK, PUBREC, or PUBREL packets must include the same packet identifier as the originally sent PUBLISH packet. Similarly, SUBACK and UNSUBACK must include the packet identifiers used in the corresponding SUBSCRIBE and UNSUBSCRIBE packets.
Whether Control Packets Contain Packet Identifier List
3.2.3 Payload
Some MQTT control packets contain payloads, which are the last part of the packet. For example, some PUBLISH packets may include a payload, which refers to the application message.
Control Packets Containing Payload List
From the MQTT protocol control packet format, it can be seen that the MQTT header is relatively simple due to the limited information involved; for example, the fixed header contains only three fields: control packet type, flags, and remaining length, totaling a maximum of 5 bytes.
In contrast, HTTP messages contain a lot of information, such as request methods, resource paths, protocol versions, status codes, reasons, etc., occupying more bytes. Additionally, HTTP headers include security settings, performance optimizations, language settings, etc. While this information can enhance network stability, security, and user experience, it negatively impacts the efficiency and performance of network communication.
Header size occupies bandwidth resources, leading to low transmission efficiency
As vehicle sales continue to increase, the scale of vehicle terminals connected to the TSP platform is expanding. During peak periods, the platform needs to maintain concurrent connections in the hundreds of thousands.
To achieve rich business scenarios, each connected vehicle device will simultaneously have multiple upstream and downstream data transmissions. Therefore, when the number of vehicles reaches hundreds of thousands, the platform needs to support millions of message throughput, which places high demands on data transmission efficiency and real-time performance.
Moreover, vehicles often encounter complex network environments such as obstructions, tunnels, and base station switches during operation, causing disconnections between vehicle terminals and the cloud. HTTP may require frequent retries in unstable network environments, affecting efficiency and user experience. In contrast, the MQTT protocol can maintain long connections, keeping low power consumption during idle times, thus saving device energy. Therefore, MQTT is increasingly being applied in vehicle networking.
04
Conclusion
MQTT is a client-server publish/subscribe message transmission protocol. Subscribers can dynamically subscribe to topics at runtime, adapting to changing demands. It supports long connections, is lightweight, open, simple, easy to implement, and occupies a small code space and network bandwidth.
MQTT also supports multiple Quality of Service (QoS) levels, ensuring reliable message transmission in different network environments. Even in unstable network conditions, MQTT can ensure reliable message transmission through an automatic reconnection mechanism, making it more suitable for vehicle networking!
end
Recommended Premium Events
AutoSec China Tour Series Salon
Professional Community
Some experts in the group come from:
New Force Car Companies:
Tesla, Hozon New Energy – Nezha, Li Auto, Zeekr, Xiaomi, Binnli Automotive, Jiyue, Leap Motor, Avita, Zhiji Automotive, Xpeng, Lantu Automotive, NIO, Geely Automotive, Seres……
Foreign Traditional Mainstream Car Companies:
Volkswagen China, Volkswagen Cool Wing, Audi, BMW, Ford, Daimler-Benz, General Motors, Porsche, Volvo, Hyundai, Nissan, Jaguar Land Rover, Scania……
Domestic Traditional Mainstream Car Companies:
Geely Automotive, SAIC Passenger Cars, Great Wall Motors, SAIC Volkswagen, Changan Automobile, Beijing Automotive, Dongfeng Motor, GAC, BYD, FAW Group, FAW Liberation, Dongfeng Commercial, SAIC Commercial……
Global Leading Tier 1 Suppliers:
Bosch, Continental Group, United Automotive Electronics, Aptiv, ZF, Calsonic Kansei, Schaeffler, Honeywell, DJI, Hitachi, Harman, Huawei, Baidu, Lenovo, MediaTek, Preh, Desay SV, Hella, Wuhan Guangting, Xingji Meizu, CRRC Group, Wintech, Weichai Group, Horizon, Unisoc, ByteDance,……
Tier 2 Suppliers (500+):
Upstream, ETAS, Synopsys, NXP, TUV, Shanghai Software Center, Deloitte, Zhongke Shucai, Qihoo 360, China Automotive Research, Shanghai Automotive Inspection, Ruijun Technology, Zhejiang University……
Personnel Proportion
Company Type Proportion
More Articles
Don’t miss out, this could be the largest exclusive community in the automotive network security industry!
About the lawyer’s statement regarding the suspected imitation of the AutoSec conference brand
One article to help you understand the in-vehicle network communication security architecture of intelligent vehicles
Cybersecurity: TARA methods, tools, and cases
Key analysis of automotive data security compliance
Analysis of automotive chip information security and secure boot
Exploration of vehicle onboard communication security solutions in domain centralized architecture
System security architecture of vehicle network security
Privacy protection issues in vehicle networking
Research on network security technology for intelligent connected vehicles
AUTOSAR information security framework and key technology analysis
What information security mechanisms does AUTOSAR have?
Underlying mechanisms of information security
Automotive network security
Use of AUTOSAR hardware security modules (HSM)
First release! Lei Jun from Xiaomi made suggestions on automotive data security issues at the two sessions: Suggestions for building a complete automotive data security management system