Machine-to-Machine Protocol Adaptation System and Method for Multiple Carriers

Abstract

This invention discloses a machine-to-machine protocol adaptation system and method for multiple operators, belonging to the field of communication protocol technology. The key technical points include: obtaining message type, vehicle-to-machine related basic information, and message association data based on M2M messages and vehicle-to-everything (V2X) metadata; obtaining preliminary mapping results between multi-operator M2M message fields and unified V2X fields based on message type, message association data, and V2X semantic rules; obtaining operator link scheduling strategies adapted to multiple services based on the preliminary mapping results, vehicle network status, and service priorities; and obtaining optimized mapping rules and scheduling parameters based on the scheduling strategy, adaptation execution results, and historical adaptation data. This invention achieves closed-loop optimization of mapping rules and scheduling parameters through adaptation execution results and historical adaptation data, reducing cross-operator connection costs and improving the communication reliability, scheduling rationality, and global adaptability of multiple V2X services.

Description

Technical Field

[0001] This invention relates to the field of communication protocol technology, and more specifically to a machine-to-machine protocol adaptation system and method for multiple operators. Background Technology

[0002] With the global large-scale deployment of intelligent connected vehicles, vehicles need to achieve full-service communication such as eCall, OTA, and remote control across multiple operator M2M networks in different countries and regions. However, the M2M protocols used by different operators around the world (such as LwM2M, MQTT, OneM2M and various proprietary protocols) have significant heterogeneity in field definitions, operation logic, and transmission characteristics. This can easily lead to parsing errors where the same field is used for different purposes, and cannot meet the communication requirements of vehicle networking for multiple concurrent services, high reliability, and low latency. Therefore, existing technologies have shortcomings. Summary of the Invention

[0003] To address the shortcomings of existing technologies, the present invention aims to provide a machine-to-machine protocol adaptation system and method for multiple operators. By adapting the execution results and historical adaptation data, the system achieves closed-loop optimization of mapping rules and scheduling parameters, reduces cross-operator connection costs, and improves the communication reliability, scheduling rationality, and global adaptation capability of multiple services in the Internet of Vehicles.

[0004] To achieve the above objectives, the present invention provides the following technical solution:

[0005] This invention provides a machine-to-machine protocol adaptation method for multiple operators, comprising:

[0006] Based on the M2M message and vehicle-to-everything (V2X) metadata, we obtain the message type, basic V2X-related information, and message association data.

[0007] Based on message type, message association data, and vehicle-to-everything (V2X) semantic rules, preliminary mapping results between multi-operator M2M message fields and unified V2X fields are obtained.

[0008] Based on the preliminary mapping results, vehicle network status, and service priorities, an operator link scheduling strategy adapted to multiple services is obtained.

[0009] Based on the operator's link scheduling policy, adaptation execution results, and historical adaptation data, the optimized mapping rules and scheduling parameters are obtained.

[0010] As a further improvement of the present invention, based on machine-to-machine messages and vehicle network metadata, message type, vehicle network-related basic information, and message association data are obtained, including:

[0011] Based on the message header identifier and message characteristics of the M2M message, the corresponding M2M protocol type can be identified;

[0012] Based on the M2M protocol type and message content, extract the operation intent and message header feature information of the message;

[0013] Based on the M2M protocol type, operation intent, message header feature information, and vehicle network metadata, the message type, vehicle network-related basic information, and message association data are obtained.

[0014] As a further improvement of the present invention, based on the M2M protocol type and message content, the operation intent and message header feature information of the message are extracted, including:

[0015] Based on the M2M protocol type and operator protocol specifications, determine the correspondence rules between operation codes and operation intentions;

[0016] Based on the message content and corresponding rules, locate and extract the actual operation code in the message;

[0017] Based on the actual operation code and the corresponding rules, the operation intent and message header feature information of the message are matched.

[0018] As a further improvement of the present invention, based on message type, message association data, and vehicle-to-everything (V2X) semantic rules, a preliminary mapping result between multi-operator M2M message fields and unified V2X fields is obtained, including:

[0019] Based on message type, operator M2M protocol metadata, and vehicle-to-everything (V2X) semantic rules, basic semantic matching rules are constructed.

[0020] Based on the message association data and semantic matching basic rules, the candidate mapping results of the fields are calculated;

[0021] Based on the candidate mapping results and the semantic rules of vehicle networking, preliminary mapping results of multi-operator M2M message fields and unified fields of vehicle networking are obtained.

[0022] As a further improvement of the present invention, based on the candidate mapping results and vehicle-to-everything (V2X) semantic rules, a preliminary mapping result between multi-operator M2M message fields and unified V2X fields is obtained, including:

[0023] Based on the purpose of vehicle networking fields and vehicle networking semantic rules, establish constraints for intent verification;

[0024] Based on the candidate mapping results and constraints, filter and remove mapping entries that do not conform to the semantic rules of the Internet of Vehicles.

[0025] Based on the filtered mapping entries and semantic matching results, preliminary mapping results between multi-operator M2M message fields and vehicle-to-everything (V2X) unified fields are obtained.

[0026] As a further improvement of the present invention, based on the preliminary mapping results, vehicle network status, and service priorities, a multi-service-compatible operator link scheduling strategy is obtained, including:

[0027] Based on the preliminary mapping results and the service type corresponding to the service priority, the packet traffic characteristics are predicted and pre-scheduling is triggered.

[0028] Based on pre-scheduling, vehicle network status, and service priority, a link resource configuration scheme is allocated;

[0029] Based on the link resource configuration scheme, preliminary mapping results, and operator link status, an operator link scheduling strategy adapted to multiple services is obtained.

[0030] As a further improvement of the present invention, based on the preliminary mapping results and the service type corresponding to the service priority, packet traffic characteristics are predicted and pre-scheduling is triggered, including:

[0031] Based on the message header feature information, the M2M protocol message header structure, and the preliminary mapping results, the basis for predicting message traffic is determined;

[0032] Based on the prediction criteria and the business type corresponding to the business priority, the traffic impact level of the message is determined.

[0033] Based on the traffic surge level, service type, and preliminary mapping results, pre-scheduling is triggered.

[0034] As a further improvement of the present invention, based on the preliminary mapping results, vehicle network status, and service priorities, a multi-service-adaptive operator link scheduling strategy is obtained, which further includes:

[0035] Based on the preliminary mapping results, vehicle network status, and operator link session status, the link session synchronization results are verified.

[0036] Based on the link session synchronization results, vehicle network status, and service priority, the optimal alternative link is selected.

[0037] Based on the optimal alternative links, preliminary mapping results, and vehicle network status, an operator link scheduling strategy adapted to multiple services is obtained.

[0038] As a further improvement of the present invention, based on the preliminary mapping results, vehicle network status, and operator link session status, the link session synchronization result is verified, including:

[0039] Based on the preliminary mapping results, the M2M protocol session management specifications, and the vehicle network status, the evaluation indicators for session synchronization are determined.

[0040] Based on the evaluation indicators and the operator link session status, specific data for each evaluation indicator were collected.

[0041] Based on specific data, preliminary mapping results, and vehicle network status, the link session synchronization results are verified.

[0042] As a further improvement of the present invention, based on message type, message association data, and vehicle-to-everything (V2X) semantic rules, a preliminary mapping result between multi-operator M2M message fields and unified V2X fields is obtained, which also includes:

[0043] Based on message type, associated data, and vehicle-to-everything (V2X) semantic rules, message fragmentation and missing field conditions are identified.

[0044] Based on message fragmentation and field missingness, causal dependencies of vehicle network fields, and vehicle network semantic rules, the mapping data is completed and corrected to obtain the mapping data.

[0045] Based on the mapping data, message type, and message association data, the voting verification yields the preliminary mapping results between the multi-operator M2M message fields and the unified fields of the vehicle network.

[0046] As a further improvement of the present invention, based on message type, message association data, and vehicle network semantic rules, message fragmentation and field missing conditions are identified, including:

[0047] Based on message type, associated data, and vehicle-to-everything (V2X) semantic rules, determine the verification criteria for message integrity;

[0048] Based on the verification standards and message association data, the fragmentation status of the message is determined by comparison.

[0049] Based on message fragmentation, message type, and vehicle-to-everything (V2X) semantic rules, the missing field conditions are identified.

[0050] As a further improvement of the present invention, based on the operator's link scheduling policy, adaptation execution results, and historical adaptation data, optimized mapping rules and scheduling parameters are obtained, including:

[0051] Based on the operator's link scheduling strategy, adaptation execution results and historical adaptation data, operational data is collected, including mapping accuracy and service success rate.

[0052] Based on operational data, operator link scheduling strategies, and historical adaptation data, the optimization directions for mapping rules and scheduling parameters are analyzed.

[0053] Based on the optimization direction, operator link scheduling strategy, and historical adaptation data, update the mapping rules and scheduling parameters to obtain the optimized mapping rules and scheduling parameters.

[0054] This invention provides a machine-to-machine protocol adaptation system for multiple operators, comprising:

[0055] The terminal layer is used to collect vehicle network metadata.

[0056] The edge layer is used to obtain message type, basic information related to the Internet of Vehicles, and message association data based on M2M messages and Internet of Vehicles metadata; to obtain preliminary mapping results between multi-operator M2M message fields and unified Internet of Vehicles fields based on message type, message association data, and Internet of Vehicles semantic rules; and to obtain operator link scheduling strategies adapted to multiple services based on preliminary mapping results, vehicle network status, and service priorities.

[0057] The cloud layer is used to obtain optimized mapping rules and scheduling parameters based on the operator's link scheduling policy, adaptation execution results, and historical adaptation data.

[0058] This invention employs a method for adapting to multi-carrier M2M protocols. Based on message type, message association data, and vehicle-to-everything (V2X) semantic rules, it generates preliminary mapping results between multi-carrier M2M message fields and unified V2X fields. This is combined with operation intent correction and multi-channel voting verification to improve mapping accuracy. Simultaneously, it triggers pre-scheduling based on service priority and message length characteristics, generating operator link scheduling strategies adapted to multiple services, and introduces session synchronization to ensure service continuity during cross-carrier handovers. Finally, it achieves closed-loop optimization of mapping rules and scheduling parameters through adaptation execution results and historical adaptation data, effectively reducing cross-carrier integration costs and improving the communication reliability, scheduling rationality, and global adaptability of multiple V2X services. Attached Figure Description

[0059] Figure 1 This is a schematic diagram of the method steps of the present invention;

[0060] Figure 2 This is a schematic diagram illustrating the steps of obtaining message type, vehicle-to-everything (V2X) related basic information, and message association data according to the present invention.

[0061] Figure 3 This is a schematic diagram illustrating the steps involved in obtaining the optimized mapping rules and scheduling parameters according to the present invention. Detailed Implementation

[0062] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the embodiments of the present invention and the specific features in the embodiments are detailed descriptions of the technical solution of the present invention, rather than limitations thereof.

[0063] The term "and / or" in the following text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Additionally, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0064] like Figure 1 As shown in the figure, this application provides a machine-to-machine protocol adaptation method for multiple operators, including:

[0065] Based on the M2M message and vehicle-to-everything (V2X) metadata, we obtain the message type, basic V2X-related information, and message association data.

[0066] Based on message type, message association data, and vehicle-to-everything (V2X) semantic rules, preliminary mapping results between multi-operator M2M message fields and unified V2X fields are obtained.

[0067] Based on the preliminary mapping results, vehicle network status, and service priorities, an operator link scheduling strategy adapted to multiple services is obtained.

[0068] Based on the operator's link scheduling policy, adaptation execution results, and historical adaptation data, the optimized mapping rules and scheduling parameters are obtained.

[0069] Specifically, the terminal layer T-BOX (intelligent vehicle terminal) first collects vehicle operation-related data according to a preset period. This embodiment does not limit the value of the preset period; for example, it can be set to 100 milliseconds to meet the real-time requirements of vehicle networking services while avoiding excessive consumption of terminal computing power. The collected content is vehicle networking metadata, including the vehicle's unique identification code (VIN), the vehicle terminal's UTC synchronization timestamp, the T-BOX hardware model, the PLMN code of the current access operator, and the vehicle's latitude and longitude location information. Simultaneously, the operator network sends M2M messages to the terminal layer. M2M messages are machine-to-machine communication data packets provided by the operator network to the vehicle terminal, covering LwM2M, MQTT, OneM2M, and various operator-defined private protocol formats. The edge layer MEC node synchronously completes the aggregation and reception of vehicle networking metadata and M2M messages.

[0070] The edge layer performs fusion processing on the two types of converged data, extracting message header identifiers, service type identifiers, and network transmission characteristics to ultimately obtain message types, vehicle-to-everything (V2X) related basic information, and message association data. Message types are communication message categories categorized according to V2X business scenarios, including eCall alarm messages, OTA upgrade messages, remote control messages, and routine vehicle condition reporting messages. V2X related basic information consists of core vehicle operating status data, including vehicle speed, battery SOC, airbag status, and door lock status. Message association data is characteristic data from the entire message transmission process, including message length, end-to-end transmission latency, link packet loss rate, message sequence number, and carrier ID of the bearer link. During processing, all data is uniformly converted to UTF-8 encoding, and the unit of measurement adopts the metric standard to eliminate multi-source data format conflicts.

[0071] Next, the edge layer loads the vehicle-to-everything (V2X) semantic rules issued by the cloud layer. These V2X semantic rules are predefined binding specifications between unified V2X fields and actual business meanings. Based on message type, message association data, and V2X semantic rules, the multi-operator M2M message fields are matched and calculated with the unified V2X fields to obtain preliminary mapping results. These preliminary mapping results are the matching output of heterogeneous M2M message fields from multiple operators with unified V2X fields, serving as the core basis for subsequent link scheduling.

[0072] Next, the edge layer combines the preliminary mapping results, vehicle network status, and service priorities to generate an operator link scheduling strategy adapted to multiple services. Vehicle network status is a real-time communication indicator for onboard terminals accessing the operator network, including RSRP signal strength, network latency, link packet loss rate, and bandwidth utilization. Service priorities are preset three levels based on the importance of vehicle-to-everything (V2X) services. For example, level L1 corresponds to eCall and V2X security messages, level L2 corresponds to OTA upgrades and remote control, and level L3 corresponds to routine vehicle status reporting. Each level corresponds to a network latency threshold; for example, L1 services are limited to a network latency of less than 50 milliseconds, L2 services to less than 100 milliseconds, and L3 services to less than 300 milliseconds. This embodiment does not impose restrictions on network latency thresholds; for example, network latency thresholds are set according to the 3GPP V2X communication standard to ensure the transmission requirements of different service levels.

[0073] Finally, the cloud layer collects the adaptation execution results after the operator's link scheduling strategy is implemented. The adaptation execution results are the actual operating data of field mapping accuracy, service success rate, and link switching success rate. Combined with historical adaptation data, such as the historical adaptation data of the past 30 days, iterative optimization is performed. The historical adaptation data is the summary data of mapping logs, scheduling logs, and anomaly handling logs in the past period. The cloud needs to build a reinforcement learning closed-loop optimization model. The model state space includes three types of indicators: mapping accuracy, service success rate, and link communication cost. The action space is set to two types of operations: mapping rule adjustment and scheduling parameter modification. The reward function is composed of a weighted average of the communication reliability improvement rate and the cost reduction rate. The reliability weight is set to 0.6, and the cost weight is set to 0.4. The weight settings are only examples and this embodiment does not limit them. Those skilled in the art can determine them according to the principle of prioritizing the safety of vehicle networking services. That is, for the sake of service safety, a higher weight can be set for communication reliability. During model training, initial running data is collected first to build a training set. Then, the policy gradient loss is set to control the model update magnitude. The PPO algorithm is used to complete 1000 iterations of training. After the loss function converges, the model is deployed. The model performs a full iteration every 24 hours and updates local parameters every hour. Finally, the optimized mapping rules and scheduling parameters are obtained. The mapping rules are the execution specifications for field matching, semantic verification, and anomaly correction. The scheduling parameters are the configuration values ​​of link switching threshold, pre-scheduling trigger condition, and session synchronization threshold. The optimization results are synchronously distributed to the edge layer and terminal layer.

[0074] This embodiment constructs a standardized framework for the entire process of multi-carrier M2M protocol adaptation. Through data collection, feature extraction, field mapping, link scheduling, and closed-loop optimization, a complete technical logic closed loop is formed. It can stably generate preliminary mapping results between multi-carrier M2M message fields and unified fields of the vehicle network. Combining vehicle network status and service priority, it outputs operator link scheduling strategies adapted to multiple services. Through the adaptation execution results and historical adaptation data, it continuously optimizes the mapping rules and scheduling parameters, reduces the cost of cross-carrier integration, and improves the communication reliability, scheduling rationality, and global adaptability of multiple services in the vehicle network. It provides a feasible and iterative core execution foundation for the solution.

[0075] Furthermore, such as Figure 2 As shown, this embodiment provides a step for obtaining message type, vehicle-to-everything (V2X) related basic information, and message association data based on machine-to-machine messages and V2X metadata, including:

[0076] Based on the message header identifier and message characteristics of the M2M message, the corresponding M2M protocol type can be identified;

[0077] Based on the M2M protocol type and message content, extract the operation intent and message header feature information of the message;

[0078] Based on the M2M protocol type, operation intent, message header feature information, and vehicle network metadata, the message type, vehicle network-related basic information, and message association data are obtained.

[0079] Specifically, the edge layer first reads the header identifier of the M2M message. The header identifier is a fixed byte at the beginning of the M2M message, used to distinguish different protocol types. The edge layer matches the header identifier with a preset message feature library, and identifies the corresponding M2M protocol type based on the matching result. The M2M protocol types include four categories: LwM2M, MQTT, OneM2M, and carrier-specific M2M protocols.

[0080] For example, the input is the raw binary stream of an M2M message. An M2M message consists of multiple bytes of data. First, the message header identifier is extracted. Different protocol types correspond to different header identifier lengths. To ensure high coverage, the first 16 bytes of the message header can be uniformly extracted as a unified header identifier for subsequent identification. Next, message features are extracted. Message features include a header structure feature vector, length features, and format features. The header structure feature vector is obtained by converting the extracted header identifier. For example, for a message containing... byte message header identifier, The corresponding message header identifier is determined based on the protocol type:

[0081] ;

[0082] in This indicates a right shift of 4 bits. Indicates bitwise AND , and This involves standard bitwise operations at the computer's low level. Since key information in the protocol's message header is typically stored using 4 bits, this embodiment uses standard bitwise operations to split the high and low 4 bits, allowing for precise feature extraction and avoiding redundancy caused by using the entire byte. The length feature is the ratio of the extracted message header identifier's length to the total message length. The format feature is the value of a key field at a specific position in the message header identifier, such as the extracted... The high 4 bits are used as the protocol version number and are used as the format feature.

[0083] The pre-defined message feature library stores message features corresponding to each protocol type. This can be stored using a key-value pair structure, where the key is the protocol type and the value is the message feature corresponding to the protocol. Each protocol type has different message features, which can be generated according to the protocol standard. For example, for the MQTT protocol, the header structure feature vector is generated based on the first 16 bytes of the message; for the LwM2M protocol, it's based on the first 4 bytes; and for the OneM2M protocol, it's based on the first 9 bytes. Since the total message length is not fixed, the length feature corresponding to each protocol is a range. This range can be obtained by statistically analyzing the message lengths in historical data. For example, for the MQTT protocol, statistics show that in 90% of messages, the ratio of the message header length to the total message length is within [1%, 5%]. This range is used as the length feature corresponding to that protocol in the message feature library. Similarly, the ranges for other protocols can be obtained. The format feature is the standard value of the version number corresponding to each protocol. For example, the standard value for the MQTT 3.1.1 version number is 0x04.

[0084] During matching, the first step is to determine whether the length feature of the M2M message falls within the range stored in the message feature database. If not, the corresponding protocol type is the operator's proprietary M2M protocol. If so, a similarity check is performed, requiring the acquisition of the header structure feature vector and structural features corresponding to each key. Then, for each key, the similarity between its corresponding header structure feature vector and the header structure feature vector obtained from the M2M message is calculated. The similarity calculation between vectors is a technical means that can be implemented by those skilled in the art, such as using cosine similarity. After that, the similarity between the format feature corresponding to the key and the format feature obtained from the M2M message is calculated. The calculation principle of this similarity is the same as the calculation principle of the similarity of the header structure feature vector, which will not be elaborated in this embodiment. Then, the two similarities are weighted average to obtain the similarity corresponding to the key. Similarly, the similarity corresponding to each key can be obtained. Finally, the protocol type corresponding to the key with the highest similarity is taken as the corresponding M2M protocol type identified.

[0085] After identifying the protocol type, the edge layer parses the opcode field in the message content based on the identified M2M protocol type, extracting the message's operation intent and header feature information. The operation intent is the core execution purpose of the M2M message, including four categories: Read, Notify, Write, and Execute. The header feature information is the business identification data carried in the message header, including the message ID, communication topic, and protocol object ID (Object-ID). The edge layer locates the field offset positions according to the protocol standard, which is set according to the protocol frame structure standard to avoid errors in field extraction.

[0086] Finally, the edge layer integrates the M2M protocol type, operation intent, message header feature information, and vehicle network metadata uploaded by the terminal to generate basic vehicle network information. This involves binding service fields parsed from the M2M message, such as vehicle speed, battery SOC, airbag status, and door lock status, with VIN, UTC timestamp, and vehicle location to form traceable vehicle status and control command data, recorded as basic vehicle network information. Simultaneously, based on message transmission characteristics and service attributes, message association data is generated, including transmission characteristics such as message length, end-to-end transmission latency, link packet loss rate, and carrier ID. The data is bound to the M2M protocol type, operation intent, and message type to form message-related data. The binding establishes a correspondence between scattered data through an association key (such as message ID), piecing together isolated data into complete, traceable, and context-rich structured data. During the binding process, data standardization is performed to unify data format, units of measurement, and numerical precision. For example, during the processing, vehicle speed units are unified to km / h, location coordinates are unified to the WGS84 coordinate system, and time is unified to UTC time, eliminating conflicts between multi-source data and directly supporting subsequent field mapping.

[0087] This embodiment refines the core process of message preprocessing. It accurately identifies the M2M protocol type through message header identifiers and message features, extracts operation intent and message header feature information based on protocol standards, and integrates multi-dimensional data to generate standardized core message data. This solves the problems of chaotic M2M protocol types from multiple operators and ambiguous operation intent identification, providing accurate and stable input data for subsequent intelligent field mapping, improving the efficiency and accuracy of message preprocessing, and ensuring the reliability of initial data in the adaptation process.

[0088] Furthermore, this embodiment provides a step for extracting the operation intent and message header feature information of a message based on the M2M protocol type and message content, including:

[0089] Based on the M2M protocol type and operator protocol specifications, determine the correspondence rules between operation codes and operation intentions;

[0090] Based on the message content and corresponding rules, locate and extract the actual operation code in the message;

[0091] Based on the actual operation code and the corresponding rules, the operation intent and message header feature information of the message are matched.

[0092] Specifically, the cloud layer stores the M2M protocol specification documents of major global operators. The operator protocol specification is a standard that corresponds to the M2M protocol operation codes and functions defined by each operator. Before the edge layer executes an operation, it downloads the corresponding operator's protocol specification from the cloud layer. Based on the identified M2M protocol type, it matches the operation code with the operation intent from the protocol specification. This rule includes the binding relationship between the code and function clearly defined in the protocol standard. Each operation code is bound to a corresponding function, and the rule includes the storage location of the operation code corresponding to different protocol types. Since the message structure of each protocol type is fixed, the position of the operation code is fixed. For example, in the LwM2M protocol, operation code 0x01 corresponds to Read, 0x03 corresponds to Notify, 0x04 corresponds to Write, and 0x05 corresponds to Execute. The rules need to be updated regularly to synchronize with changes in the operator's protocol.

[0093] Next, the edge layer locates the storage position of the opcode in the M2M message according to the protocol frame structure in the rules, and reads the byte value at that position to obtain the actual opcode. The actual opcode is the actual operation instruction encoding carried in the M2M message and is the sole basis for determining the operation intent. Location-based reading avoids extraction errors caused by changes in message length. This method is a common protocol field extraction method in the industry and has better stability than dynamic matching. Finally, the edge layer prioritizes substituting the extracted actual opcode into the matching rules between the opcode and the operation intent to achieve accurate matching, thus obtaining the message operation intent. Simultaneously, it extracts message header feature information such as message ID, Topic, and Object-ID from the message header.

[0094] This embodiment achieves accurate identification of M2M message operation intent through standardized rule establishment, operation code extraction, and intent matching processes. It avoids field mapping errors caused by operation code confusion at the source, transforms protocol specifications into executable matching rules, automates and standardizes operation intent identification, provides core basis for subsequent intent verification and mapping, improves the professionalism and accuracy of message parsing, and ensures unbiased execution of vehicle network service commands.

[0095] Furthermore, this embodiment provides a step for obtaining a preliminary mapping result between multi-operator M2M message fields and unified vehicle network fields based on message type, message association data, and vehicle network semantic rules, including:

[0096] Based on message type, operator M2M protocol metadata, and vehicle-to-everything (V2X) semantic rules, basic semantic matching rules are constructed.

[0097] Based on the message association data and semantic matching basic rules, the candidate mapping results of the fields are calculated;

[0098] Based on the candidate mapping results and the semantic rules of vehicle networking, preliminary mapping results of multi-operator M2M message fields and unified fields of vehicle networking are obtained.

[0099] Specifically, since the message field names differ among different operators, but the vehicle-to-everything (V2X) platform requires unified standard fields, this embodiment addresses the issue of inconsistent message field names by using semantic matching basic rules and generating candidate mapping results. First, the edge layer obtains the current message type and synchronously loads the operator's M2M protocol metadata and V2X semantic rules distributed from the cloud. The operator's M2M protocol metadata is a list of fields defined and actually carried by the operator in the current message. This list includes multiple fields, each containing a field name, data type, numerical value range, and business meaning. For example, one field's field name is veh_spd, and its data type... :float, value range 0-220, business meaning: vehicle speed. The semantic rules of the Internet of Vehicles are unified semantic rules pre-defined by Internet of Vehicles service platforms and others based on national standards. They include the basic attributes of standard fields such as standard name, data type, and value range. For example, standard name: real-time vehicle speed, data type: float, value range: 0-220; standard name: door lock status, data type: bool, value range: 0 / 1. It also includes the binding specifications of unified Internet of Vehicles fields with business scenarios, that is, the message type used for each standard field. For example, real-time vehicle speed is suitable for regular vehicle condition reporting and eCall alarms, but not for OTA upgrades.

[0100] The edge layer also needs to construct basic semantic matching rules by combining three types of data. These rules include three constraints: semantic similarity threshold constraint, data type constraint, and numerical value range matching constraint. Specifically, the semantic similarity threshold constraint requires that the similarity between the operator's message field and the unified field of the vehicle network should be greater than a preset similarity threshold. For example, multiple sets of positive and negative samples can be prepared manually. Positive samples are matching pairs of actual operator fields and standard fields in the vehicle network, such as bat_soc → battery SOC. Negative samples are semantically unrelated field pairs, such as veh_spd → battery SOC. The cosine similarity of each positive and negative sample is calculated, and the lowest similarity in the positive samples and the highest similarity in the negative samples are counted. The average of the two similarities is taken as the preset similarity threshold. If it is greater than the preset similarity threshold, it is considered a semantic match; if it is less than the preset similarity threshold, it is considered a semantic mismatch. The data type constraint requires that the data type of the operator field must be exactly the same as the data type of the corresponding standard field, such as both being float or both being int. The numerical value range matching constraint requires that the numerical value or list corresponding to the operator field must be a subset of the standard field or list.

[0101] In practical applications, the edge layer first obtains the message type from the message association data, and then filters out the unified V2X fields that use the message type based on the message type and V2X semantic rules to obtain a standard field set. For example, if the current message is a regular vehicle condition reporting message, the standard field set includes: real-time vehicle speed, battery SOC, door lock status, airbag status, etc.; if it is an eCall alarm message, the standard field set only retains eCall-specific fields such as collision status, vehicle location, timestamp, and VIN, and removes irrelevant fields such as SOC. Next, based on the currently acquired operator M2M protocol metadata, each field is matched against a standard field set. Specifically, for each field in the operator M2M protocol metadata, fields that meet the data type constraints and numerical value range matching constraints are first identified in the standard field set. Then, the similarity between this field and each identified field is calculated, and the three fields with the highest similarity are retained. These three fields are candidate mapping results for this field. These three fields are only examples, and this embodiment does not impose any restrictions on them. A reasonable number can be set according to the number of fields. When calculating the similarity, the fields need to be converted into vectors. This step is a prior art method, and this embodiment will not elaborate on it. Finally, through the candidate mapping results and vehicle-to-everything (V2X) semantic rules, a preliminary mapping result between multi-operator M2M message fields and unified V2X fields is obtained.

[0102] This embodiment constructs an intelligent field semantic matching process, establishes basic rules for semantic matching through multi-dimensional constraints, generates candidate mapping results based on semantic similarity, and filters to obtain standardized preliminary mapping results. It abandons the rigid mode of traditional static hard-coded mapping, realizes adaptive matching of M2M message fields from multiple operators, improves the universality and accuracy of field mapping, and provides reliable data support for the subsequent generation of link scheduling strategies.

[0103] Furthermore, this embodiment provides a step for obtaining a preliminary mapping result between multi-operator M2M message fields and unified vehicle-to-everything (V2X) fields based on candidate mapping results and V2X semantic rules, including:

[0104] Based on the purpose of vehicle networking fields and vehicle networking semantic rules, establish constraints for intent verification;

[0105] Based on the candidate mapping results and constraints, filter and remove mapping entries that do not conform to the semantic rules of the Internet of Vehicles.

[0106] Based on the filtered mapping entries and semantic matching results, preliminary mapping results between multi-operator M2M message fields and vehicle-to-everything (V2X) unified fields are obtained.

[0107] Specifically, firstly, based on the purpose of vehicle-to-everything (V2X) fields and V2X semantic rules, constraints for intent verification are established. The purpose of V2X fields refers to the actual business functions of unified V2X fields, which are divided into three categories: status fields, control fields, and alarm fields. Among them, status fields refer to static / dynamic status data generated during vehicle operation that can be read / reported, such as real-time vehicle speed and battery SOC. Control fields refer to control command data issued by the platform to the terminal to change the vehicle status, such as door unlocking commands and OTA upgrade commands. Alarm fields refer to alarm data actively reported by the terminal to trigger emergency services, such as eCall collision status and airbag trigger status. The constraint condition for intent verification is the binding rule between the operation intent and the field purpose. The rule is formulated based on the business logic of the Internet of Vehicles to avoid functional confusion. For example, if the platform can only request to read vehicle status data from the terminal and cannot read control command data or alarm data, then the Read operation intent can only match the status field. If the platform can only send control command data to the terminal and cannot send status data or alarm data, then the Write operation intent can only match the control field. In this embodiment, the hard rules of business logic are solidified into constraints in advance to eliminate semantically matched but business logic incorrect mapping entries from the source, and avoid subsequent functional confusion, business disorder or even security risks.

[0108] Then, based on the rule engine and machine learning, and considering the candidate mapping results and constraints, mapping entries that do not conform to the semantic rules of vehicle networking are filtered and removed. The rule engine is responsible for basic constraint verification, while the machine learning model is responsible for anomaly scenario judgment. First, basic verification is performed based on the rule engine, requiring verification of each candidate mapping result for each field. Specifically, the operation intent is first obtained, then the purpose corresponding to one of the candidate mapping results is obtained, and then the constraints are called for verification. For example, if the operation intent is "Notify," it checks whether the purpose corresponding to the candidate mapping result is a status field; if so, it is retained; otherwise, it is removed. For anomaly scenarios not covered by the rule engine, such as special fields of operator-private protocols or business variant fields, a pre-trained intent verification model is used for verification.

[0109] For example, the intent verification model can employ a fully connected neural network. The training data consists of pre-labeled samples, including the operation intent, candidate mapping results, message type, and the actual labels. Labels are categorized as either legal or illegal. "Legal" indicates that, in abnormal scenarios not covered by the rule engine, the relationship between the candidate mapping result and the operation intent conforms to the general business logic of the Internet of Vehicles (IoV), will not cause functional confusion, and will not lead to data parsing errors or vehicle control safety risks. Conversely, if it violates the general business logic of IoV and causes confusion in reporting / control functions, it is defined as illegal. The labeled samples can be divided into training and validation sets in an 8:2 ratio. The model includes an input layer and hidden layers. The model consists of an input layer and an output layer. The input layer is used to input the concatenated result of one-hot encoding corresponding to the operation intention, candidate mapping result, and message type, respectively. The dimension of the input layer is equal to the dimension of the concatenated result. The hidden layer can be set to 2 layers. The output dimension of the output layer is 1. The output layer can use the Sigmoid function to map the output result to the [0,1] interval. The loss function used during training is the binary cross-entropy loss, which is used to measure the difference between the output result of the output layer and the true label. Then, the parameters in the model are updated according to the gradient descent method using the loss function until the preset maximum number of iterations is reached. The optimizer during training can be Adam, and the learning rate is set to 0.001.

[0110] In practical applications, the concatenation result of the one-hot encoding corresponding to the candidate mapping result verified by the rule engine is input into the intent verification model. The output layer will output the probability value obtained after mapping. If the probability value is greater than the preset probability threshold, it is judged as legal and the candidate mapping result is retained. If it is less than or equal to the preset probability threshold, it is judged as illegal and the candidate mapping result is removed. In this embodiment, the preset probability threshold is not limited. For example, it can be set to 0.5.

[0111] After obtaining the valid candidate mapping results for each field, for each field, select the valid candidate mapping result with the highest similarity as its corresponding preliminary mapping result. If a field does not have a preliminary mapping result, mark the field as a mapping anomaly and trigger the manual process.

[0112] This embodiment adds intent verification logic to semantic matching, realizing the upgrade from syntax mapping to intent mapping. It eliminates illegal mapping results through constraints, solves the parsing error problem caused by different uses of the same field, improves the accuracy of field mapping and business adaptability, avoids vehicle network business anomalies caused by mapping errors, and ensures the security and reliability of vehicle data parsing.

[0113] Furthermore, this embodiment provides a step for obtaining an operator link scheduling strategy adapted to multiple services based on preliminary mapping results, vehicle network status, and service priorities, including:

[0114] Based on the preliminary mapping results and the service type corresponding to the service priority, the packet traffic characteristics are predicted and pre-scheduling is triggered.

[0115] Based on pre-scheduling, vehicle network status, and service priority, a link resource configuration scheme is allocated;

[0116] Based on the link resource configuration scheme, preliminary mapping results, and operator link status, an operator link scheduling strategy adapted to multiple services is obtained.

[0117] Specifically, the edge layer first parses the packet header feature data based on the preliminary mapping results and the service type corresponding to the service priority, predicts the packet traffic characteristics, and triggers pre-scheduling. It first parses the packet header features using the M2M protocol packet header structure as a template, matches the native service type, and cross-validates with the preliminary mapping results to generate a structured traffic prediction basis. The prediction basis and service type are input into the pre-deployed traffic impact level classification model. After outputting the initial level, dynamic thresholds are used for fallback verification and network adaptation correction to determine the low / medium / high impact levels. Pre-scheduling is then triggered according to the final level matching rules to ensure stable service transmission.

[0118] An edge layer is used to build a packet traffic feature prediction model to accurately predict the traffic and transmission duration of the entire service lifecycle. The model inputs are packet header features, service type, and preliminary mapping results, and the outputs are packet traffic size and transmission duration. For example, an LSTM time series prediction network is used to build the model, with the input sequence length set to 16 and the number of hidden layer neurons set to 64 to ensure the time series feature extraction effect. The model uses various types of service packet traffic data to build a training set, and the prediction error threshold is set to 5%. After the error requirement is met, the training is completed, and the model is deployed in the edge layer to achieve real-time prediction of traffic features.

[0119] After triggering pre-scheduling, the edge layer generates a pre-scheduling instruction. This instruction includes the lead time for this pre-scheduling, the traffic impact level, the service type and priority, and the latest completion time for resource reservation. Then, using the pre-scheduling instruction as the core input, combined with real-time vehicle network status and service priorities, a link resource configuration scheme is generated. This scheme is the operator's detailed allocation rule for link communication resources. First, the service type and priority are extracted from the pre-scheduling instruction. The service attributes are cross-validated based on the preliminary mapping results to confirm the service's priority level, such as L1, L2, and L3 as mentioned above. Then, based on the traffic impact level and resource reservation timeliness requirements of the pre-scheduling instruction, corresponding communication resources are matched for different priority services. For example, L1 services are allocated URLLC high-reliability communication resources, L2 services are allocated eMBB high-bandwidth resources, and L3 services are allocated mMTC low-cost resources. Resource allocation is based on the 3GPP 5G vehicle-to-everything (V2X) communication standard to match different service transmission requirements. Finally, combining the latest completion time for resource reservation in the pre-scheduling instruction and the real-time vehicle network status, specific link bandwidth, QoS service level, and session persistence parameters are configured for the service, generating the final link resource configuration scheme. This scheme provides standardized allocation rules for operator link communication resources, clarifies the hard admission criteria for link selection, and provides a feasible basis for the generation of subsequent operator link scheduling strategies.

[0120] The edge layer combines link resource configuration schemes, preliminary mapping results, and real-time operator link status. Operator link status includes link bandwidth utilization, latency, packet loss rate, and session synchronization status. The link resource configuration scheme serves as a hard screening criterion. Combining core service transmission requirements with industry standards, the optimal operator links are selected, generating operator link scheduling strategies adapted to multiple services. For example, eCall services exclude operator links with excessively high latency (over 50ms), and OTA services exclude operator links with excessively small data volumes (less than 10Mbps), ensuring service transmission quality. For the selected compliant links, a comprehensive scoring and ranking is performed based on service priority. L1 services are prioritized by latency and transmission reliability; L2 services by bandwidth capacity and transmission stability; and L3 services by communication cost and long-term connection stability. The top-ranked link is selected as the optimal transmission link. Finally, the link switching timing, resource allocation method, and session persistence parameters are determined, generating operator link scheduling strategies adapted to multiple services to ensure service transmission quality.

[0121] This embodiment implements a pre-scheduling mechanism based on traffic characteristics. It relies on a message traffic characteristic prediction model to complete traffic prediction and trigger pre-scheduling, allocates communication resources according to service priority, and generates the optimal scheduling strategy in combination with link status. This solves the problems of network congestion and core service preemption caused by traditional post-scheduling, realizes pre-scheduling, ensures low latency and high reliability transmission of high-priority services, and improves the rationality of scheduling in multi-service concurrent scenarios.

[0122] Furthermore, this embodiment provides a step of predicting packet traffic characteristics and triggering pre-scheduling based on the preliminary mapping results and the service type corresponding to the service priority, including:

[0123] Based on the message header feature information, the M2M protocol message header structure, and the preliminary mapping results, the basis for predicting message traffic is determined;

[0124] Based on the prediction criteria and the business type corresponding to the business priority, the traffic impact level of the message is determined.

[0125] Based on the traffic surge level, service type, and preliminary mapping results, pre-scheduling is triggered.

[0126] Specifically, the traffic prediction basis is first determined based on the message header feature information, the M2M protocol message header structure, and the preliminary mapping results. The M2M protocol message header structure specifies the message header format for different operators' M2M protocols, defining the specific meaning of each field. Using the M2M protocol message header structure as a parsing template, the message header length and Object-ID field value are accurately extracted from the message header feature information. This value is then matched against the protocol specifications to obtain the native service type corresponding to that Object-ID. The accuracy of the native service type is verified based on the preliminary mapping results. For example, the OTA upgrade service matched by Object-ID=2000 must be consistent with the service meaning of the OTA upgrade packet data field in the preliminary mapping results. Inconsistencies are marked as abnormal, and the message header parsing results take precedence. The traffic prediction basis is then generated, containing three core components: the actual number of bytes in the current message, the final service type after cross-validation (e.g., OTA upgrade, regular vehicle condition reporting), and the preset service data volume matched according to the service type. The preset service data volume can be set based on the size of historical service data packets; for example, the estimated total data volume for OTA upgrade services should be ≥10MB.

[0127] Next, a traffic impact level classification model is built at the edge layer. The model's input features are single packet length, service type, estimated total data volume, and service priority. The output is a three-level traffic impact level: low, medium, and high. A decision tree classification algorithm is used, and the Gini coefficient is used as the node splitting criterion to ensure classification efficiency. When training the model, packet samples of different traffic levels can be used to construct a training set, which is divided into a training set and a validation set in an 8:2 ratio. For example, the classification accuracy threshold can be set to 99.8%, and deployment is completed after the threshold is reached.

[0128] After the edge layer obtains the initial traffic impact level from the model output, it combines dynamic thresholds for fallback verification and network adaptation correction to determine the final impact level (low / medium / high). Pre-scheduling is then triggered according to the final impact level matching rules to ensure stable service transmission. The dynamic threshold is a verification threshold dynamically updated based on the operator's real-time network load and historical service traffic data. It can be adjusted according to network capacity and service priority to ensure the level determination is compatible with the current network state. The level matching rules are preset scheduling and resource allocation logics for different impact levels, specifically including: allocating link resources 5 seconds in advance for high impact levels, allocating resources 2 seconds in advance for medium impact levels, and not triggering pre-scheduling for low impact levels. The advance scheduling time is set based on network switching latency; this embodiment does not impose restrictions on this. For example, if an OTA upgrade message is determined to be of a high impact level, the edge layer allocates high-bandwidth link resources to it 5 seconds in advance to avoid transmission interruption.

[0129] The edge layer then pre-allocates resources based on the level matching rules. For example, high-bandwidth links are allocated for high-impact services, reserving ≥10MB of continuous bandwidth resources and locking the session channel until the service transmission is completed. For medium-impact services such as routine vehicle condition batch reporting, 4G / 5G conventional bandwidth links are allocated, reserving the basic bandwidth resources required for the corresponding message transmission. For low-impact, high-priority services such as eCall alarms and remote control, pre-scheduling is not triggered, and URLLC high-reliability, low-latency channels are allocated to ensure transmission.

[0130] This embodiment refines the pre-scheduling triggering logic, determines the basis for traffic prediction through multi-dimensional features, accurately judges the traffic impact level based on the traffic impact level classification model, and triggers differentiated pre-scheduling according to the level to avoid network congestion caused by sudden large-volume services, realize the advance reservation and reasonable allocation of communication resources, improve the foresight and rationality of scheduling strategies, and ensure the stable transmission of large-volume services in the Internet of Vehicles.

[0131] Furthermore, in addition to the above-mentioned scheme for obtaining operator link scheduling strategies, this embodiment also provides a step for obtaining an operator link scheduling strategy adapted to multiple services based on preliminary mapping results, vehicle network status, and service priorities, including:

[0132] Based on the preliminary mapping results, vehicle network status, and operator link session status, the link session synchronization results are verified.

[0133] Based on the link session synchronization results, vehicle network status, and service priority, the optimal alternative link is selected.

[0134] Based on the optimal alternative links, preliminary mapping results, and vehicle network status, an operator link scheduling strategy adapted to multiple services is obtained.

[0135] Specifically, the edge layer first verifies the link session synchronization result based on the preliminary mapping results, vehicle network status, and operator link session status. It then obtains the comprehensive session synchronization degree of each link through the session synchronization degree calculation model. Finally, it determines whether the link is qualified for session synchronization by combining the qualification threshold corresponding to the service priority. The operator link session status is the running status of the M2M communication session, including session registration status, number of unacknowledged messages, and key negotiation status. The edge layer only retains links whose comprehensive session synchronization degree meets the corresponding service qualification threshold requirements and enters the subsequent screening process. This verification is set according to the M2M protocol session standard to ensure the continuity of service transmission.

[0136] An optimal link selection model is built at the edge layer. The model inputs include link session synchronization results, vehicle network status, and service priority. The output is the optimal candidate link. The model is constructed using the multi-attribute decision-making TOPSIS algorithm. Evaluation metrics include signal quality, session synchronization, communication cost, and latency. The weights of these metrics are dynamically adjusted according to the service level to adapt to the transmission requirements of different services. For example, for L1-level security services, session synchronization and end-to-end latency have the highest weights, prioritizing uninterrupted, low-latency transmission for urgent services. For L2-level high-volume services, signal quality and session synchronization have the highest weights, prioritizing stable and continuous transmission for high-volume services. For L3-level routine services, communication cost has the highest weight, reducing operating costs while meeting basic transmission quality requirements. The model's construction logic is as follows: first, the input evaluation metric data are standardized to eliminate differences in the units of measurement of different metrics; then, based on the weights corresponding to service priorities, the proximity of each link to the ideal optimal solution and the worst-case solution is calculated; finally, the optimal candidate link is output after comprehensive ranking. The model is trained using full carrier link status data, and the link selection accuracy threshold is set at 99.9% to ensure scheduling accuracy.

[0137] Finally, by combining the optimal alternative links, preliminary mapping results, and vehicle network status, a carrier link scheduling strategy adapted to multiple services is generated, which clarifies the link switching timing, resource allocation method, and session persistence parameters. For example, the eCall service is switched to a carrier link with high session synchronization and low end-to-end latency to ensure uninterrupted transmission of emergency services; the OTA upgrade service is switched to a carrier link with good signal quality and stable session synchronization to ensure smooth transmission of high-volume services; and the routine vehicle condition reporting service prioritizes links with lower communication costs to reduce operating costs while meeting transmission quality requirements.

[0138] This embodiment implements scheduling decisions based on M2M application layer session states, abandoning the traditional switching method that relies solely on physical layer signals. It uses the optimal link selection model to complete link screening, generates a scheduling strategy adapted to the service through session synchronization verification, solves the problem of service disconnection during cross-operator roaming, achieves seamless session-level switching, and improves the continuity and stability of vehicle network services.

[0139] Furthermore, this embodiment provides a step for verifying the link session synchronization result based on the preliminary mapping result, vehicle network status, and operator link session status, including:

[0140] Based on the preliminary mapping results, the M2M protocol session management specifications, and the vehicle network status, the evaluation indicators for session synchronization are determined.

[0141] Based on the evaluation indicators and the operator link session status, specific data for each evaluation indicator were collected.

[0142] Based on specific data, preliminary mapping results, and vehicle network status, the link session synchronization results are verified.

[0143] Specifically, the edge layer first determines the evaluation indicators for session synchronization based on the preliminary mapping results, M2M protocol session management specifications, and vehicle network status. Session synchronization is a comprehensive quantitative indicator that measures the synchronization status of M2M communication sessions. The evaluation indicators include four items: session registration rate, unacknowledged message ratio, key negotiation completion rate, and remaining session validity period. The weights of the four indicators are 0.3, 0.3, 0.3, and 0.1, respectively. The weights are set according to the degree of impact on session stability. This embodiment does not impose any restrictions on this. For example, the session registration rate is a basic prerequisite for session establishment, the unacknowledged message ratio directly reflects the risk of link session synchronization failure, and the key negotiation completion rate is a necessary condition for secure sessions. The three have a similar degree of impact on session stability, so they are set with equal weights. The remaining session validity period only affects the duration of the session and does not directly affect the synchronization status of the current session, so it is set with a lower weight. Among them, the session registration rate, key negotiation completion rate, and remaining session validity period are positive indicators, and the larger the value, the better the session synchronization status. The unacknowledged message ratio is a negative indicator, and the smaller the value, the better the session synchronization status.

[0144] Next, a session synchronization calculation model was built. The model input consists of four evaluation index values, and the output is the comprehensive session synchronization score. A weighted summation algorithm was used to construct the model. During the calculation process, the collected index data was first preprocessed. For the negative index of unacknowledged message ratio, positive processing was performed, converting it into a form where a larger value represents a higher synchronization score. The processing logic was to subtract the original unacknowledged message ratio from 100% to ensure that the change direction was consistent with other positive indices. Then, all index data were standardized to eliminate differences in the numerical range of different indices, making the contribution of each index to the final total score fair and comparable. Finally, the preprocessed index values ​​were weighted and summed according to the preset weights to obtain the comprehensive session synchronization score. For example, the calculation error of the model is controlled within 1%. The index weights can be updated according to the M2M protocol specification to ensure the accuracy of the calculation.

[0145] Next, session status data of each operator's link is collected in real time at a period of 100 milliseconds, and the specific values ​​of four indicators are extracted to ensure the real-time performance of the indicators. This collection period is set according to the typical reporting period of vehicle-to-everything (V2M) messages. For example, if the session registration rate of a certain operator's link is 98%, the proportion of unacknowledged messages is 2%, the key negotiation completion rate is 100%, and the remaining session validity period is 300 seconds, it can be directly used for synchronization calculation.

[0146] The edge layer calculates the overall session synchronization degree using a session synchronization degree calculation model. Differentiated qualification thresholds are set based on service priority, ensuring the transmission quality of high-priority services. For example, L1 services, which have the highest requirements for session stability, can require an overall session synchronization degree of no less than 95% to ensure no session interruption for urgent services. L2 and L3 services require an overall session synchronization degree of no less than 90% to ensure continuous transmission of service data. When the overall session synchronization degree of the link reaches the qualification threshold requirement for the corresponding service, the session synchronization is deemed qualified; otherwise, it is deemed unqualified, ultimately yielding the link session synchronization result.

[0147] This embodiment achieves quantitative evaluation of M2M session synchronization status. It completes synchronization degree calculation through standardized evaluation indicators, accurate data collection, and session synchronization degree calculation model to obtain objective link session synchronization results. This provides accurate quantitative basis for cross-operator link handover, improves handover success rate, and enables seamless cross-network handover of vehicle-to-everything (V2X) services.

[0148] Furthermore, in addition to the steps described above for obtaining preliminary mapping results, this embodiment also provides a step for obtaining preliminary mapping results between multi-operator M2M message fields and unified vehicle network fields based on message type, message association data, and vehicle network semantic rules, including:

[0149] Based on message type, associated data, and vehicle-to-everything (V2X) semantic rules, message fragmentation and missing field conditions are identified.

[0150] Based on message fragmentation and field missingness, causal dependencies of vehicle network fields, and vehicle network semantic rules, the mapping data is completed and corrected to obtain the mapping data.

[0151] Based on the mapping data, message type, and message association data, the voting verification yields the preliminary mapping results between the multi-operator M2M message fields and the unified fields of the vehicle network.

[0152] Specifically, this embodiment is an enhanced field mapping process for abnormal message scenarios, used to handle fragmented and missing field M2M messages in weak network environments. First, based on the message type, message association data, and vehicle network semantic rules, the message integrity is checked, and message fragmentation and field missing status are identified. Message fragmentation refers to the state where the message is split into incomplete fragments in a weak network environment, and field missing status refers to the specific state where message fields are lost or incomplete. The edge layer sets a message integrity threshold and outputs the degree of message fragmentation and details of missing fields. For example, integrity greater than 80% is considered slight fragmentation, 60%-80% is considered moderate fragmentation, and less than 60% is considered severe fragmentation. Required fields include VIN, timestamp, and core vehicle condition data. Missing required fields are judged as severe missing.

[0153] A weak network packet completion model is built at the edge layer. The model inputs fragmented packets, causal dependencies between fields, and historical state data, and the output is the completed mapping data. It is constructed using a Transformer neural network to learn the temporal correlations and causal dependencies between vehicular network fields. For example, the model includes three core modules: first, an input embedding layer, which converts the field values, missing tags, and causal dependencies between fields of the fragmented packet into vector representations, while embedding packet type and business semantic information; second, a multi-layer Transformer encoder, which learns the temporal correlations and causal dependencies between vehicular network fields through a masked self-attention mechanism, focusing on capturing the logical relationships between missing fields and existing fields; and third, an output layer that infers reasonable values ​​for missing fields based on attention weights and outputs the confidence score of the completed fields. During model training, a training set is constructed using fragmented / missing packet samples covering weak network scenarios such as tunnels and underground parking garages. The samples cover different degrees of fragmentation and different types of missing fields, allowing the completion accuracy threshold to be set to 99% to ensure the reasonableness and accuracy of the completion results and adapt to abnormal packet scenarios in weak network environments.

[0154] The edge layer first processes fragmented packets using a weak network packet completion model, outputting completed mapping data. Then, based on packet fragmentation, field missingness, causal dependencies between vehicle network (V2X) fields, and V2X semantic rules, it performs completion correction on the model's output mapping data to obtain the final mapping data. The causal dependencies between V2X fields refer to the necessary relationships between different fields in a V2X packet determined by business logic, communication protocols, or the vehicle state machine. In other words, the existence or value of one field must presuppose one or more other fields; this is the core basis for field completion. This relationship is pre-configured in the edge layer's V2X semantic rule base. For example, in an eCall alarm message, the airbag status field depends on the VIN and timestamp fields. The airbag status data only has business significance when the VIN and timestamp exist. The completion rule is to only complete fields that are logically necessary to exist, without fabricating unfounded data. The completed data comes from the vehicle's historical state machine to ensure data rationality. That is, the missing field value is inferred by combining historical message data with the same VIN and similar timestamps with the vehicle state transition rules. For example, the missing airbag status field can be inferred as triggered / not triggered based on the state transition rules of the vehicle collision event and historical messages, thus ensuring data rationality.

[0155] Subsequently, the mapping data, message type, and message association data are verified by voting on the mapping results of multiple operator links. This mechanism leverages the redundancy of multiple links in the vehicle-to-everything (V2X) network to improve the reliability of the mapping results. For example, the complete mapping results of the same service message on multiple operator links are collected, and the number of times the mapping value of each field appears is counted. If the mapping value of a certain field is consistent in more than half of the link results, the value is adopted. If there are no majority consistent results, or the difference between the results of different links exceeds a preset threshold, the field is marked as abnormal. This threshold is the upper limit of the result difference preset according to the service field type and accuracy requirements, and is used to quantitatively judge the consistency of the multi-link mapping results. For example, the vehicle speed field can be set to ±2km / h, and the battery SOC field can be set to ±1%. Combined with the service priority, the complete result with the highest confidence is adopted. Finally, the mapping data that passes the voting verification is the preliminary mapping result between the multi-operator M2M message fields and the unified fields of the V2X network.

[0156] This embodiment addresses the issues of fragmented frames and packet loss in weak network scenarios. It completes data repair through message integrity detection and a weak network message completion model, and generates mapping results by combining multi-link voting verification. This significantly improves the mapping success rate in complex network environments, ensures the integrity of vehicle network data, and solves the problems of service interruption and data loss caused by weak networks.

[0157] Furthermore, this embodiment provides a step for identifying message fragmentation and field missingness based on message type, message association data, and vehicle-to-everything (V2X) semantic rules, including:

[0158] Based on message type, associated data, and vehicle-to-everything (V2X) semantic rules, determine the verification criteria for message integrity;

[0159] Based on the verification standards and message association data, the fragmentation status of the message is determined by comparison.

[0160] Based on message fragmentation, message type, and vehicle-to-everything (V2X) semantic rules, the missing field conditions are identified.

[0161] Specifically, firstly, based on message type, associated data, and vehicle-to-everything (V2X) semantic rules, a message integrity verification standard is established. This standard serves as the basis for judging the integrity of a message and includes three requirements: message length error, mandatory field integrity, and checksum matching. For example, it is stipulated that the actual length of a complete message should not deviate from the standard message length for the corresponding service type by more than 5%. This error threshold can be set based on the typical transmission packet error range of the M2M protocol and needs to cover message length deviations under normal network fluctuations. Based on the service semantic rules corresponding to the message type, a set of mandatory fields for each service is defined. For example, mandatory fields for eCall alarm messages include VIN, timestamp, and airbag status, while mandatory fields for OTA upgrade messages include upgrade packet sequence number, data fragment length, and checksum. Missing mandatory fields indicate incompleteness, and the checksum at the message header or footer must be consistent with the checksum calculated from the message content to prevent data tampering or damage during transmission.

[0162] An edge layer is used to build a message integrity detection model, which is the core tool for automated anomaly detection. This model is directly related to the aforementioned verification standards. The model's inputs are message data and integrity verification standards, and its outputs are the degree of fragmentation and missing fields. It employs a fusion architecture of CNN and RNN. The CNN is used to extract message structural features, such as field position and length distribution, while the RNN is used to extract temporal correlation features, such as the continuity of fragment numbers and the temporal relationship of data blocks. The model can use message samples with different degrees of fragmentation to build a training set, covering all scenarios including mild fragmentation, severe fragmentation, single-field missing, and multi-field missing. The detection accuracy threshold is set to 99.7% to ensure accurate detection results.

[0163] Next, based on the fragmentation level output by the model, further comparison and verification are carried out to calculate the message integrity and determine the fragmentation status of the message. The integrity calculation method is the number of actual valid fields / the number of standard fields × 100%. The calculation result accurately reflects the degree of message fragmentation and provides a basis for subsequent completion.

[0164] Finally, based on the degree of message fragmentation, message type, and vehicle network semantic rules, the required and optional fields are checked one by one to clearly identify the missing fields, mark the name and type of the missing fields, and distinguish between the missing required fields and the missing optional fields. This provides an accurate basis for differentiated completion, such as distinguishing between the missing airbag status field (a required field) and the missing vehicle location field (an optional field) in eCall alarm messages.

[0165] This embodiment establishes a standardized message integrity detection system. By formulating verification standards, comparing integrity, and identifying missing fields using a message integrity detection model, it accurately determines the status of weak network messages, providing a precise basis for subsequent message completion, avoiding invalid completion and data fabrication, and improving the robustness and accuracy of message parsing in weak network scenarios.

[0166] Furthermore, such as Figure 3 As shown, this embodiment provides a step for obtaining optimized mapping rules and scheduling parameters based on operator link scheduling policies, adaptation execution results, and historical adaptation data, including:

[0167] Based on the operator's link scheduling strategy, adaptation execution results and historical adaptation data, operational data is collected, including mapping accuracy and service success rate.

[0168] Based on operational data, operator link scheduling strategies, and historical adaptation data, the optimization directions for mapping rules and scheduling parameters are analyzed.

[0169] Based on the optimization direction, operator link scheduling strategy, and historical adaptation data, update the mapping rules and scheduling parameters to obtain the optimized mapping rules and scheduling parameters.

[0170] Specifically, this embodiment represents a closed-loop optimization step in the entire multi-carrier M2M adaptation process. By continuously analyzing business operation data in the cloud, it reverse-optimizes the mapping rules and scheduling parameters in all the aforementioned steps, achieving self-iteration and self-adaptation of the solution. The cloud layer first collects operation data based on the operator's link scheduling strategy, adaptation execution results, and historical adaptation data. The operation data is the core operation indicator after the solution is implemented, including mapping accuracy, service success rate, link switching success rate, and traffic cost. Mapping accuracy is the ratio of the number of correctly mapped fields to the total number of mapped fields, and service success rate is the ratio of the number of successfully transmitted services to the total number of services. The cloud summarizes the operation data every 5 minutes to ensure data real-time performance. The target mapping accuracy is no less than 99.9%, and the service success rate is no less than 99.5%. The target values ​​are set according to the vehicle networking industry standards.

[0171] A closed-loop optimization analysis model is built in the cloud. The model takes operational data and historical adaptation data as inputs and outputs mapping rules and optimization directions for scheduling parameters. It employs a fusion architecture of big data analytics and reinforcement learning. For example, the model first cleans the collected operational data, removing outliers and filling in missing data. It then standardizes four indicators to eliminate dimensional differences. Simultaneously, it correlates historical indicator data for corresponding service types and operator links from the historical adaptation data, providing a complete data foundation for subsequent analysis. Based on the cleaned operational data, it conducts indicator trend analysis and anomaly localization, identifying the service types, operator links, and time intervals in which indicators deviate from target values, and initially pinpointing the source of the problem, such as low mapping accuracy. This model, which only appears in a certain operator's OTA upgrade service, aims to maximize communication reliability and minimize operating costs. It uses current and historical adaptation data as state inputs and adjusts mapping rule constraints, modifies scheduling parameter thresholds, and optimizes link selection strategies as the action space. Through iterative trial and error using reinforcement learning algorithms, it outputs the optimal optimization direction while considering the weights of different service priorities. For example, the reliability weight of L1 security services is higher than the cost weight. Finally, the actions output by reinforcement learning are converted into executable optimization instructions, clearly defining the types of rules / parameters to be adjusted, the adjustment direction, and the target value. The scope of the adjustment, such as local parameters or global rules, is also marked, providing a clear basis for subsequent updates. The model is pre-trained using all historical adaptation data and undergoes a full iteration every 24 hours to continuously improve the optimization effect.

[0172] The cloud platform compares operational data with target values, combines scheduling strategies with historical adaptation data, and uses a closed-loop optimization analysis model to analyze the optimization direction of mapping rules and scheduling parameters. For example, if the mapping accuracy is low, the basic semantic matching rules and intent verification constraints are optimized. For instance, in an operator's OTA upgrade message, the mapping accuracy between the upgrade package version field and the unified field for vehicle networking is 75%. Model analysis found that the basic semantic matching rules lacked constraints for verifying the association between the upgrade package ID and the version field, leading to the misidentification of the test version upgrade package version as the official version. The optimization direction is to add a verification condition for the association between the upgrade package ID and the version field to the basic semantic matching rules. If the service success rate is low, the link switching threshold and the qualified threshold for session synchronization are adjusted. For example, the link switching success rate of the eCall service was only 90%. Analysis revealed that the session synchronization qualification threshold was set too high, originally 95%, causing some links that met the session synchronization requirements to be mistakenly judged as unqualified. The optimization direction is to adjust the session synchronization qualification threshold from 95% to 93%, and at the same time optimize the triggering timing of link switching, pre-switching the link 10 seconds before the session synchronization drops to the qualification threshold. If the traffic cost is too high, optimize the operator link selection strategy. For example, for the routine vehicle condition reporting service in a certain area, high-cost operator links are prioritized. The optimization direction is to adjust the link selection weight, prioritizing low-cost operator links while meeting bandwidth and latency requirements, and limiting the usage ratio of high-cost operator links to no more than 20%.

[0173] Based on optimization directions, operator link scheduling strategies, and historical adaptation data, the cloud updates mapping rules and scheduling parameters to obtain optimized mapping rules and scheduling parameters, which are then synchronized to the edge layer and terminal layer. The update method varies depending on the object being adjusted. For example, real-time updates of local parameters refer to local scheduling parameters such as link switching thresholds, session synchronization qualification thresholds, and link selection weights, which are distributed to the edge layer through the cloud management platform and take effect immediately upon receipt without restarting the service. Daily updates of global rules refer to global rules such as basic rules for vehicle-to-everything (V2X) semantic matching, causal dependencies of fields, and packet integrity verification standards, which are updated daily during the low-traffic period in the early morning to avoid service fluctuations caused by frequent modifications. After the update, the edge layer automatically performs a verification using historical packet data to confirm the validity of the rules before officially enabling them. Through continuous closed-loop optimization, the solution can dynamically adapt to changes in operator networks and expansion of business scenarios, ensuring long-term reliability and cost-effectiveness.

[0174] This embodiment constructs a closed-loop self-optimization mechanism. Through data collection, closed-loop optimization analysis model to determine optimization direction, and rule parameter updates, it enables continuous iteration and upgrading of the adaptation scheme, continuously improving mapping accuracy and business success rate, reducing cross-operator connection costs, ensuring long-term stable operation of the scheme, and continuously adapting to changes in vehicle networking services and operator networks.

[0175] Furthermore, embodiments of this application provide a machine-to-machine protocol adaptation system for multiple operators, including:

[0176] The terminal layer is used to collect vehicle network metadata.

[0177] The edge layer is used to obtain message type, basic information related to the Internet of Vehicles, and message association data based on M2M messages and Internet of Vehicles metadata; to obtain preliminary mapping results between multi-operator M2M message fields and unified Internet of Vehicles fields based on message type, message association data, and Internet of Vehicles semantic rules; and to obtain operator link scheduling strategies adapted to multiple services based on preliminary mapping results, vehicle network status, and service priorities.

[0178] The cloud layer is used to obtain optimized mapping rules and scheduling parameters based on the operator's link scheduling policy, adaptation execution results, and historical adaptation data.

[0179] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0180] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0181] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0182] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A machine-to-machine protocol adaptation method for multiple operators, characterized in that, include: Based on the M2M message and vehicle-to-everything (V2X) metadata, we obtain the message type, basic V2X-related information, and message association data. Based on message type, message association data, and vehicle-to-everything (V2X) semantic rules, preliminary mapping results between multi-operator M2M message fields and unified V2X fields are obtained. Based on the preliminary mapping results, vehicle network status, and service priorities, an operator link scheduling strategy adapted to multiple services is obtained. Based on the operator's link scheduling policy, adaptation execution results, and historical adaptation data, the optimized mapping rules and scheduling parameters are obtained. Based on message type, message association data, and vehicle-to-everything (V2X) semantic rules, preliminary mapping results between multi-operator M2M message fields and unified V2X fields are obtained, including: Based on message type, operator M2M protocol metadata, and vehicle-to-everything (V2X) semantic rules, basic semantic matching rules are constructed. Based on the message association data and semantic matching basic rules, the candidate mapping results of the fields are calculated; Based on the candidate mapping results and the vehicle-to-everything (V2X) semantic rules, preliminary mapping results between multi-operator M2M message fields and unified V2X fields are obtained. Based on the candidate mapping results and vehicle-to-everything (V2X) semantic rules, preliminary mapping results between multi-operator M2M message fields and unified V2X fields are obtained, including: Based on the purpose of vehicle networking fields and vehicle networking semantic rules, establish constraints for intent verification; Based on the candidate mapping results and constraints, filter and remove mapping entries that do not conform to the semantic rules of the Internet of Vehicles. Based on the filtered mapping entries and semantic matching results, preliminary mapping results between multi-operator M2M message fields and vehicle-to-everything (V2X) unified fields are obtained; The preliminary mapping results between multi-operator M2M message fields and unified vehicle-to-everything (V2X) fields, obtained based on message type, message association data, and V2X semantic rules, also include: Based on message type, associated data, and vehicle-to-everything (V2X) semantic rules, message fragmentation and missing field conditions are identified. Based on message fragmentation and field missingness, causal dependencies of vehicle network fields, and vehicle network semantic rules, the mapping data is completed and corrected to obtain the mapping data. Based on the mapping data, message type, and message association data, the voting verification yields the preliminary mapping results between the multi-operator M2M message fields and the unified fields of the vehicle network.

2. The machine-to-machine protocol adaptation method for multiple operators according to claim 1, characterized in that, Based on machine-to-machine messages and vehicle-to-everything (V2X) metadata, the message type, basic V2X-related information, and associated message data are obtained, including: Based on the message header identifier and message characteristics of the M2M message, the corresponding M2M protocol type can be identified; Based on the M2M protocol type and message content, extract the operation intent and message header feature information of the message; Based on the M2M protocol type, operation intent, message header feature information, and vehicle network metadata, the message type, vehicle network-related basic information, and message association data are obtained.

3. The machine-to-machine protocol adaptation method for multiple operators according to claim 2, characterized in that, Based on the M2M protocol type and message content, the operation intent and message header feature information of the message are extracted, including: Based on the M2M protocol type and operator protocol specifications, determine the correspondence rules between operation codes and operation intentions; Based on the message content and corresponding rules, locate and extract the actual operation code in the message; Based on the actual operation code and the corresponding rules, the operation intent and message header feature information of the message are matched.

4. The machine-to-machine protocol adaptation method for multiple operators according to claim 1, characterized in that, Based on the preliminary mapping results, vehicle network status, and service priorities, an operator link scheduling strategy adapted to multiple services is obtained, including: Based on the preliminary mapping results and the service type corresponding to the service priority, the packet traffic characteristics are predicted and pre-scheduling is triggered. Based on pre-scheduling, vehicle network status, and service priority, a link resource configuration scheme is allocated; Based on the link resource configuration scheme, preliminary mapping results, and operator link status, an operator link scheduling strategy adapted to multiple services is obtained.

5. The machine-to-machine protocol adaptation method for multiple operators according to claim 4, characterized in that, Based on the preliminary mapping results and the service type corresponding to the service priority, the packet traffic characteristics are predicted and pre-scheduling is triggered, including: Based on the message header feature information, the M2M protocol message header structure, and the preliminary mapping results, the basis for predicting message traffic is determined; Based on the prediction criteria and the business type corresponding to the business priority, the traffic impact level of the message is determined. Based on the traffic surge level, service type, and preliminary mapping results, pre-scheduling is triggered.

6. The machine-to-machine protocol adaptation method for multiple operators according to claim 1, characterized in that, Based on the preliminary mapping results, vehicle network status, and service priorities, an operator link scheduling strategy adapted to multiple services is obtained, which also includes: Based on the preliminary mapping results, vehicle network status, and operator link session status, the link session synchronization results are verified. Based on the link session synchronization results, vehicle network status, and service priority, the optimal alternative link is selected. Based on the optimal alternative links, preliminary mapping results, and vehicle network status, an operator link scheduling strategy adapted to multiple services is obtained.

7. The machine-to-machine protocol adaptation method for multiple operators according to claim 6, characterized in that, Based on the preliminary mapping results, vehicle network status, and operator link session status, the link session synchronization results are verified, including: Based on the preliminary mapping results, the M2M protocol session management specifications, and the vehicle network status, the evaluation indicators for session synchronization are determined. Based on the evaluation indicators and the operator link session status, specific data for each evaluation indicator were collected. Based on specific data, preliminary mapping results, and vehicle network status, the link session synchronization results are verified.

8. The machine-to-machine protocol adaptation method for multiple operators according to claim 1, characterized in that, Based on message type, associated data, and vehicle-to-everything (V2X) semantic rules, message fragmentation and missing field conditions are identified, including: Based on message type, associated data, and vehicle-to-everything (V2X) semantic rules, determine the verification criteria for message integrity; Based on the verification standards and message association data, the fragmentation status of the message is determined by comparison. Based on message fragmentation, message type, and vehicle-to-everything (V2X) semantic rules, the missing field conditions are identified.

9. The machine-to-machine protocol adaptation method for multiple operators according to claim 1, characterized in that, Based on the operator's link scheduling policy, adaptation execution results, and historical adaptation data, optimized mapping rules and scheduling parameters are obtained, including: Based on the operator's link scheduling strategy, adaptation execution results and historical adaptation data, operational data is collected, including mapping accuracy and service success rate. Based on operational data, operator link scheduling strategies, and historical adaptation data, the optimization directions for mapping rules and scheduling parameters are analyzed. Based on the optimization direction, operator link scheduling strategy, and historical adaptation data, update the mapping rules and scheduling parameters to obtain the optimized mapping rules and scheduling parameters.

10. A machine-to-machine protocol adaptation system for multiple operators, used to implement the machine-to-machine protocol adaptation method for multiple operators as described in any one of claims 1-9, characterized in that, include: The terminal layer is used to collect vehicle network metadata; The edge layer is used to obtain message type, basic information related to the Internet of Vehicles, and message association data based on M2M messages and Internet of Vehicles metadata; to obtain preliminary mapping results between multi-operator M2M message fields and unified Internet of Vehicles fields based on message type, message association data, and Internet of Vehicles semantic rules; and to obtain operator link scheduling strategies adapted to multiple services based on preliminary mapping results, vehicle network status, and service priorities. The cloud layer is used to obtain optimized mapping rules and scheduling parameters based on the operator's link scheduling policy, adaptation execution results, and historical adaptation data.

Images