Methods, network elements, and media for reducing the processing load of V2X receivers

Abstract

Embodiments of this disclosure relate to methods, network elements, and media for reducing the processing load of a V2X receiver. A method for processing a first message destined for a Smart Transportation System (STS) station at a network element includes: receiving or generating the first message from a sending entity at the network element; performing one of the following based on the source or content of the first message: discarding the first message; or modifying the first message to provide an indication to the STS station of checks that the STS does not need to perform, thereby creating a second message; and forwarding the second message to the STS station.

Description

[0001] This application is a divisional application of the invention patent application with international application number PCT / CA2019 / 050417, international application date of April 5, 2019, entry into the Chinese national phase date of September 27, 2020, Chinese national application number 201980022823.5, and invention title "Method, Network Element and Medium for Reducing the Processing Load of a V2X Receiver". Technical Field

[0002] This disclosure relates to intelligent transportation systems (ITS), and more specifically to communication between ITS stations. Background Technology

[0003] Intelligent Transportation Systems (ITS) are systems in which multiple devices communicate to allow the transportation system to make more informed decisions about transportation and traffic management, as well as to make decisions more safely and in a more coordinated manner. ITS system components can be provided as part of fixed infrastructure (such as on bridges or at intersections) within vehicles and for use by other users of the transportation system (including pedestrians or cyclists).

[0004] The deployment of ITS systems has garnered significant attention in many markets worldwide, with radio frequency bands allocated for communications. In addition to vehicle-to-vehicle communications for both safety-critical and non-critical applications, further enhancements have been developed for vehicle-to-infrastructure and vehicle-to-portable scenarios.

[0005] An ITS station can be any entity that provides ITS communication, including vehicles, infrastructure components, mobile devices, and other options. In some cases, such an ITS station may intentionally or unintentionally transmit incorrect data. For example, the ITS station may have fault sensors that can provide fault data in ITS messaging. In other cases, a malicious user may insert false information into messages, causing the intelligent transportation system to malfunction. Typically, when such behavior is detected, the identifiers of one or more certificates of the misbehaving ITS station can be placed on a Certificate Revocation List (CRL), which can be used to manage misbehaving ITS stations. An ITS station receiving a message from another ITS station with a certificate on the CRL can then ignore the message or disregard the importance of the information within it.

[0006] However, using CRLs to manage misbehaving ITS endpoints has drawbacks. Specifically, because CRLs can cover very large geographic areas with numerous vehicles and other ITS stations, their length can be substantial. Furthermore, each ITS station can have multiple certificates, resulting in multiple CRLs for each ITS application or service type. Summary of the Invention

[0007] In a first aspect, a method is provided for processing a first message destined for a smart transportation system station at a network element, the method comprising: receiving the first message from a sending entity at the network element; modifying the first message by performing multiple security checks on the first message to provide the smart transportation system station with indications of the multiple security checks performed by the network element, thereby creating a second message; and forwarding the second message to the smart transportation system station, wherein the indications include a list of the multiple security checks and whether the security checks passed or failed.

[0008] In a second aspect, a network element configured to process a first message destined for a smart transportation system station is provided, the network element comprising: a processor; and a communication subsystem, wherein the network element is configured to: receive the first message from a sending entity at the network element; modify the first message by performing multiple security checks on the first message to provide the smart transportation system station with instructions on the multiple security checks performed by the network element, thereby creating a second message; and forward the second message to the smart transportation system station, wherein the instructions include a list of multiple security checks and whether the security checks passed or failed.

[0009] In a third aspect, a computer-readable medium is provided for storing instruction code for processing a first message destined for a smart transportation system station. When executed by a processor of a network element, the instruction code causes the network element to: receive the first message from a sending entity; perform multiple security checks on the first message to modify it to provide instructions to the smart transportation system station regarding the multiple security checks performed by the network element, thereby creating a second message; and forward the second message to the smart transportation system station, wherein the instructions include a list of the multiple security checks and whether the security checks passed or failed. Attached Figure Description

[0010] This disclosure will be better understood with reference to the accompanying drawings, in which:

[0011] Figure 1 This is a block diagram of an intelligent transportation system;

[0012] Figure 2 This is a block diagram illustrating the architecture for cellular-based vehicle-to-everything (V2X) communication;

[0013] Figure 3 This is a block diagram illustrating the architecture of cellular broadcasting for V2X communication;

[0014] Figure 4 This is a data flow diagram illustrating the process for verifying messages between the sending ITS station and the receiving ITS station;

[0015] Figure 5 This is a block diagram illustrating the logical roles in a security credential management system;

[0016] Figure 6 This is a process diagram illustrating the process used at the network entity to verify the V2X message transmitted to the receiving ITS station;

[0017] Figure 7 This is a process diagram illustrating the process of generating V2X messages for receiving ITS stations at the network entity; and

[0018] Figure 8 This is a block diagram of an example computing device that can be used in conjunction with embodiments of the present disclosure. Detailed Implementation

[0019] This disclosure provides a method for processing a first message destined for an intelligent transportation system station at a network element, the method comprising: receiving or generating the first message from a sending entity at the network element; and, based on the source or content of the first message, performing one of the following: discarding the first message; or modifying the first message to provide an indication to the intelligent transportation system station of an inspection that the intelligent transportation system does not need to perform, thereby creating a second message; and forwarding the second message to the intelligent transportation system station.

[0020] This disclosure also provides a network element configured to process a first message destined for an intelligent transportation system station. The network element includes: a processor; and a communication subsystem, wherein the network element is configured to: receive or generate the first message from a sending entity at the network element; and, based on the source or content of the first message, perform one of the following: discard the first message; or modify the first message to provide an instruction to the intelligent transportation system station for checks that the intelligent transportation system does not need to perform, thereby creating a second message; and forward the second message to the intelligent transportation system station.

[0021] This disclosure also provides a computer-readable medium for storing instruction code for processing a first message destined for a smart transportation system station, the first message, when executed by a processor of a network element, causing the network element to: receive or generate the first message from a sending entity at the network element; and, based on the source or content of the first message, perform one of the following: discard the first message; or modify the first message to provide an instruction to the smart transportation system station for checks that the smart transportation system does not need to perform, thereby creating a second message; and forward the second message to the smart transportation system station.

[0022] In the embodiments described below, the following terms may have the following meanings as provided in Table 1.

[0023]

[0024]

[0025] Table 1: Terminology

[0026] Intelligent Transportation Systems (ITS) software and communication systems are designed to enhance road safety and road traffic efficiency. Such systems include vehicle-to-vehicle (V2V) communication, vehicle-to-infrastructure (V2I) communication, vehicle-to-network (V2N) communication, and vehicle-to-pedestrian or portable device (V2P) communication. Communication between a vehicle and any of these can generally be referred to as V2X. Additionally, other components can communicate with each other. Therefore, the system can include portable device-to-infrastructure (P2I) communication, infrastructure-to-infrastructure (I2I) communication, portable device-to-portable (P2P) communication, and so on. Thus, as used herein, V2X includes any communication between an ITS station and another ITS station, where that station is associated with a vehicle, roadside unit, network element, pedestrian, cyclist, animal, etc.

[0027] This communication allows components of a transportation system to communicate with each other. For example, vehicles on a highway can communicate with each other, allowing one vehicle to send a message to one or more other vehicles to indicate that it is braking, thus allowing vehicles to follow each other more closely.

[0028] Communication also allows for potential collision detection and enables vehicles equipped with such devices to take actions such as braking or sharp turns to avoid collisions. For example, active safety systems on vehicles can take input from sensors such as cameras, radar, lidar, and V2X, and can act on these inputs by steering or braking, overtaking or enhancing the actions of the human driver, or promoting autonomous driving without human involvement. Another type of advanced driver assistance system (ADAS) is a passive safety system that provides warning signals to the human driver to take action. Both active and passive safety ADAS systems can take input from V2X and ITS systems.

[0029] In other cases, fixed infrastructure can warn approaching vehicles of their impending approach to a dangerous intersection, or warn other vehicles or pedestrians approaching the intersection. This warning may include the signal status of the intersection (Signal Phase and Timing (SPaT)) and the location of vehicles, pedestrians, or hazards at the intersection. Other examples of ITS communication are known to those skilled in the art.

[0030] Now for reference Figure 1It shows an example of an ITS station, as described in, for example, European Standard (EN) 302665 “Intelligent Transport Systems (ITS) – communications architecture” of the European Telecommunications Standards Institute (ETSI), provided in version 1.1.1 of September 2010.

[0031] exist Figure 1 In some embodiments, vehicle 110 includes a vehicle ITS subsystem 112. In some cases, the vehicle ITS subsystem 112 can communicate with the vehicle's onboard network 114. Figure 1 In this environment, the vehicle's onboard network 114 can receive input from various electronic control units (ECUs) 116 or 118.

[0032] The vehicle ITS subsystem 112 may include a vehicle ITS gateway 120, which provides functionality for connecting to the vehicle's onboard network 114.

[0033] The vehicle ITS subsystem 112 may also have an ITS-S host 122, which contains ITS applications and the functionality required for such ITS applications.

[0034] Additionally, ITS-S router 124 provides the functionality to interconnect different ITS protocol stacks (e.g., at layer 3). ITS-S router 124 may be able to, for example, translate protocols for ITS-S host 122.

[0035] in addition, Figure 1 The ITS system may include a personal ITS subsystem 130, which can provide ITS communication (ITSC) applications and communication functionality in handheld or portable devices such as personal digital assistant (PDA) mobile phones, user equipment, and other such devices.

[0036] exist Figure 1 The example shows an additional component of the ITS system, including a roadside ITS subsystem 140, which may contain roadside ITS stations that can be deployed on bridges, traffic lights, etc.

[0037] The roadside subsystem 140 includes a roadside ITS station 142, and the roadside ITS station 142 includes a roadside ITS gateway 144. This gateway can connect the roadside ITS station 142 to a private roadside network 146.

[0038] The roadside ITS station may also include an ITS-S host 150, which contains the ITS-S application and the functionality required for such application.

[0039] The roadside ITS station 142 may also include an ITS-S router 152, which provides interconnection of different ITS protocol stacks, for example, at layer 3.

[0040] ITS station 142 may also include ITS-S border router 154, which can provide interconnection between two protocol stacks, but in this case, it is interconnection with an external network.

[0041] exist Figure 1 In the example, another component of the ITS system includes a central ITS subsystem 160, which includes a central ITS station intranet 162.

[0042] The internal network 162 of the central ITS station includes a central ITS gateway 164, a central ITS-S host 166, and an ITS-S border router 168. The gateway 164, the central ITS-S host 166, and the ITS border router 168 have similar functionality to the gateway 144, the ITS host 150, and the ITS-S border router 154 of the roadside ITS station 142.

[0043] Communication between the components can be conducted via the ITS peer-to-peer communication network or via network infrastructure 170.

[0044] From the above Figure 1 It can be seen that V2X communication can be used for both road safety and improving the efficiency of road transportation, including vehicle movement and reducing fuel consumption.

[0045] V2X messages, defined by the European Telecommunications Standards Institute (ETSI), are divided into two categories: Collaborative Awareness Messages (CAM) and Distributed Environment Notification Messages (DENM). CAM messages are periodic, time-triggered messages that provide status information to neighboring ITS stations. Broadcasts are typically single-hop, and the status information may include station type, location, speed, heading, and other options. Optional fields in CAM messages may include information indicating whether an ITS station is associated with road works, rescue vehicles, or vehicles transporting dangerous goods.

[0046] Typically, CAM messages are transmitted 1 to 10 times per second.

[0047] DENM messages are event-triggered messages that are sent only when triggering conditions are met. For example, such a trigger might be a road hazard or abnormal traffic conditions. DENM messages are broadcast to the assigned relevant area via a geographic network. They can be transmitted over several wireless hops, and the event information can include detailed information about the event's cause, detection time, location, speed, orientation, etc. For example, up to 20 DENM messages can be sent per second over a duration of several seconds.

[0048] A similar concept applies to wireless access (WAVE) systems in Dedicated Short Range Communication (DSRC) / Vehicle Environments, where basic security messages are specified instead of CAM / DENM messaging from ETSI.

[0049] Cellular V2X

[0050] Various systems or architectures can provide V2X communication. One such example is cellular networks, as defined in the 3GPP specifications set. As mentioned above, another alternative is DSRC / WAVE using IEEE 802.11 radio technology. Therefore, although this disclosure describes cellular V2X communication, V2X messages can be equivalently transmitted over networks that are not 3GPP cellular networks. In particular, in one case, V2X communication can be performed via infrastructure using 802.11 technology.

[0051] Taking cellular as an example, various options are possible. These options include unicast uplinks and / or downlinks via the infrastructure. Other options include broadcast downlink transmissions via the infrastructure. Still other options include sidelinks broadcast by the device.

[0052] Various transport modes can be combined. For example, sidelink (PC5) or Uu unicast uplink transport can be used to acquire V2X messages from vehicles to cellular infrastructure and then to network elements such as V2X application servers. Then, any of Multimedia Broadcast Multicast Service (MBMS) broadcast, ProSe broadcast, or Uu unicast can be used to acquire V2X messages from the V2X application server via the cellular infrastructure to the ITS station.

[0053] For example, now refer to Figure 2 It illustrates an example 3GPP system architecture that can be used for uplink and downlink communication in the case of Uu unicast and PC5 transmission, as defined, for example, in 3GPP Technical Specification (TS) 23.285 “Architecture enhancements for V2X services”.

[0054] exist Figure 2 In the embodiments, each of the plurality of ITS stations is defined as a user equipment (UE). For example, these UEs are shown as UE 210, which may represent a vehicle ITS station; UE 212, which may represent another vehicle ITS station; UE 214, which may represent a pedestrian ITS station; and UE 216, which may represent a fixed roadside unit ITS station.

[0055] Each ITS station has an associated V2X application. Therefore, UE 210 has V2X application 220, UE 212 has V2X application 222, UE 214 has V2X application 224, and UE 216 has V2X application 226.

[0056] Each UE can communicate with each other through the PC5 broadcast interface.

[0057] In addition, V2X applications can use V5 reference points to communicate with each other.

[0058] For example, a cellular system may include an evolved universal terrestrial radio access (E-UTRAN) 230, which may be a base station of an evolved packet core (EPC) 232.

[0059] The evolved packet core 232 may include a mobility management entity (MME) 234 and a service / packet gateway (S / P-GW) 236.

[0060] Communication between the UE and the E-UTRAN can occur on the LTE-Uu unicast cellular communication channel. Furthermore, the E-UTRAN230 can communicate with the EPC via the S1 interface.

[0061] EPC 232, especially MME 234, communicates with Home Subscriber Server (HSS) 240 via the S6a interface. Additionally, S / P-GW 236 can communicate with V2X Application Server 250 using the SGi interface.

[0062] V2X Application Server 250 is a network entity at the application layer accessible via a 3GPP network that provides various services, including receiving uplink data from the UE via unicast or PC5, delivering data to the UE in a target area using unicast delivery and / or PC5 and / or MBMS delivery, mapping information from a geographic location to the appropriate target area on which MBMS transmission will take place, and providing the MBMS system with the necessary information to ensure that MBMS messages can be formatted and transmitted through the appropriate area.

[0063] V2X applications 220, 222, 224, and 226 communicate with the V2X application server. V2X control functions are used to provide the UE with the necessary parameters to use V2X communication.

[0064] exist Figure 2 In this embodiment, the V2X application server 250 can determine that the V2X message is the type that needs to be shared with other vehicles, which can be achieved using Uu unicast downlink, PC5 broadcast or MBMS broadcast or multicast.

[0065] For example, regarding MBMS, regarding Figure 3 A reference architecture for LTE-Uu-based V2X via MB2 is provided.

[0066] Specifically, refer to Figure 3 UE 310 can use the V1 reference point to communicate with V2X application server 312. This can be accomplished using the LTE-Uu interface between UE 310 and E-UTRAN 314.

[0067] Then, the E-UTRAN 314 can use the S1-MME interface and the M3 reference point to communicate with the MME 316.

[0068] Additionally, the E-UTRAN 314 can use the M1 reference point to communicate with the MBMS gateway 320. The MBMS gateway 320 can also use the Sm reference point to communicate with the MME 316.

[0069] The Broadcast / Multicast Service Center (BM-SC) 330 can use SG mb or SGI-mb reference points to communicate with the MBMS gateway 320.

[0070] Additionally, the BM-SC 330 can use the MB2-C and MB2-U reference points, respectively, for control plane and user plane services, to communicate with the V2X application server 312.

[0071] Therefore, use Figure 2 and Figure 3 These architectures can be used for unicast uplinks and / or downlinks via infrastructure. Specifically, ITS stations, such as those for vehicles, can utilize Uu unicast uplink and downlink messaging between V2X applications and E-UTRAN (or other similar enhanced node B (eNB)). This communication can be directed to V2X application servers, which can be used to deliver data to multiple users in the area using unicast messaging.

[0072] In this scenario, V2X control function 252 can be used to supply the UE with the parameters required for V2X communication, and MME 234 can be used to determine whether the ITS station is authorized to use V2X.

[0073] Regarding broadcast downlink transmissions via infrastructure, V2X application servers can support data delivery to appropriate target areas. In this case, V2X application services support "network edge" deployment of MBMS. Additionally, from the above... Figure 3 The BM-SC 330 provides the functionality to support MBMS “network edge” deployments.

[0074] From the above Figure 3 The MBMS gateway 320 allows IP multicast to multiple eNBs or E-UTRANs to enable communication with ITS stations that communicate with different eNBs.

[0075] Sidelink broadcast by the device

[0076] In another embodiment, the ITS station can communicate via sidelink communication in cellular V2X. This communication is based on a 3GPP network feature known as Proximity Service (ProSe). The interface, referred to as PC5, is a type of device-to-device (D2D) communication.

[0077] In contrast to the “uplink” from a device to a network or the “downlink” from a network to a device, the term “sidelink” refers to communication directly from one device to another.

[0078] Sidelink communication includes direct communication between devices without involving any infrastructure. In the case of V2X, this might involve a first ITS station broadcasting directly to other nearby ITS stations. Additionally, devices can be co-located with infrastructure nodes, allowing ProSe communication between the devices and infrastructure nodes.

[0079] Therefore, sidelink communication can be accomplished in an autonomous mode, in which no infrastructure components are used and the transmitting ITS station autonomously determines when to broadcast to other ITS stations. Alternatively, sidelink communication can be performed in a scheduled mode, where infrastructure components such as the eNB can schedule the time when ITS stations can transmit messages on the PC5 sidelink interface.

[0080] Security in V2X

[0081] In V2X communication, various security challenges need to be overcome. The first challenge involves trust between ITS stations. In particular, ITS stations can intentionally or unintentionally send messages with incorrect content. For example, unintentional message delivery could be based on sensor malfunction, etc.

[0082] Receiving ITS stations typically want to avoid taking action on incorrect messages. Therefore, vehicles receiving incorrect ITS messages might unnecessarily apply their brakes or swerve, causing traffic problems. In some cases, this problem can be overcome by performing a plausibility check on the information received in the V2X message and comparing it with information received from other sensors, such as cameras, lidar, and radar. However, this is not always possible.

[0083] Another security challenge in V2X involves privacy. In particular, no single entity should be able to track vehicles solely through V2X messaging. Therefore, road users should not be able to track each other, and additionally, the operator of the Security Credential Management System (SCMS) or the wireless network operator should also not be able to track road users.

[0084] Another security challenge of V2X is integrity and replay protection. Specifically, messages should not be tampered with, for example, by a "man-in-the-middle" attack. Previously transmitted and replayed messages should be detected.

[0085] Another security consideration in V2X is non-repudiation. For example, if an incident occurs, the message sender should not be able to deny sending the message. This is especially true if the message directly or indirectly contributed to the incident.

[0086] Based on the above, a security credential management system has been and is still under development. This system involves multiple parties, including the Collision Avoidance Measurement Initiative (CAMP) industry consortium, the U.S. Department of Transportation, the National Highway Traffic Safety Administration (NHTSA), IEEE, and the Society of Automotive Engineers (SAE). These organizations have created a solution based on IEEE 1609 and IEEE 802.11p. IEEE 1609 is a series of standards for dedicated short-range communications, and IEEE 802.11p features the V2X application layer specifications provided by SAE. Security aspects are standardized in IEEE 1609.2. This solution is sometimes referred to as DSRC / WAVE.

[0087] CAMP has also defined SCMS, which affects both proof-of-concept pilots and work under various standards. This security work is typically summarized below.

[0088] Specifically, regarding security, V2X messages have a specific format. Typically, a V2X message contains three main parts. The first part is the application message content. The second part is the message signature provided by the sending ITS station. The third part of the V2X message is the certificate signed by a certificate authority.

[0089] CAMP uses Elliptic Curve Qu-Vanstone (ECQV) implicit certificates for V2X communication.

[0090] To explain how to use implicit certificates, a simpler case using explicit certificates is first described. An explicit certificate contains the sender's public key, appropriate administrative information such as the identity of the Certificate Authority (CA), its validity period, the sender's identity, and the cryptographic algorithm identifier. This information is signed using the CA's private key. After verifying the accompanying signature using a trusted copy of the CA's public verification key, the recipient of the V2X message can then simply copy the sender's public key and any necessary information from the data structure.

[0091] The certificate authority generates a signature that forms part of the certificate by hashing the information in the certificate (including the sender's public key and management information) to produce a fixed-length scrambled block of data called a hash. The certificate authority's private key is then applied to this hash. The hash of the signature is called the certificate's "signature".

[0092] To verify the authenticity of the certificate, the recipient uses the certificate authority's public key to verify the signature in the certificate.

[0093] In this way, the receiver uses message signing to ensure that the message content was indeed sent by the sending ITS station, which has a private key paired with the public key provided in the certificate. Signing a message used with an explicit certificate involves first hashing the V2X message context in plaintext to produce a fixed-length scrambled block of data called a hash. The sender's private key is then applied to this hash, and the hash of this signature is called the signature. To verify that the signature and message content are indeed associated, the receiver first hashes the V2X message content and then uses this hash and the sender's public key to verify the signature.

[0094] As noted above, CAMP uses elliptic curve Q-Vanstone implicit certificates instead of explicit certificates for V2X communication. These are specified in IEEE 1609.2.

[0095] ECQV certificates do not contain the explicit sender's public key. ECQV certificates include management information (similar to the information described above for explicit certificates) and elliptic curve (EC) points known as the public reconstruction key. The recipient uses a short computation to calculate the expected sender's public key, which uses the issuing certificate authority's public verification key, the public reconstruction key, and the management information. Because ECQV certificates are smaller than explicit certificates due to the absence of a signature, they are preferably used in resource-constrained environments.

[0096] In a V2X environment, each ECQV certificate is at least 64 bytes smaller than an explicit certificate.

[0097] During use, the sender signs the V2X message content using its private key and sends the signed message along with its ECQV certificate to the receiver. The receiver then calculates the sender's verification public key from the ECQV certificate and the certificate authority's public key. The calculated public key can now be used to verify the signed message.

[0098] Based on the above, a vehicle or other ITS station can send a message to a receiving ITS station signed using one of its private key (referred to as 'a') and the corresponding implicit certificate (e.g., including (P, info)). In the above, P is the public reconstruction key, and info is the management information. The receiving station extracts the sender's public verification key by calculating eP+D, where e = hash(info, P), and D is a trusted copy of the certificate authority's public verification key.

[0099] The receiver then uses the sender's public verification key to verify the signature on the message. This is, for example, in... Figure 4 The image is shown in the middle.

[0100] refer to Figure 4 The sending ITS station 410 first forms a message at box 412. Then, as shown in box 414, the sending ITS station signs the message with the appropriate key a.

[0101] Then, as shown in box 420, the sending ITS station 410 sends the message, its signature s, and the corresponding ECQV certificate (P,info).

[0102] Then, as shown in box 440, the receiving ITS station 430 can check whether the certificate exists in the certificate revocation list. The certificate revocation list will be described in more detail below.

[0103] If the certificate is not on the revocation list, then receiving the ITS station 430 allows you to retrieve the public verification key A = eP + D. This is shown in box 442.

[0104] Then, as shown in box 444, the receiving ITS station 430 can use A to verify S.

[0105] One issue with the above is that a vehicle with a single static certificate could be tracked by infrastructure network components or other road users. To avoid this, an ITS station can be assigned multiple certificates within a certain time period, after which these certificates are discarded. For example, a vehicle or other ITS station could be assigned twenty certificates within a given week, after which these certificates are discarded.

[0106] ITS stations can reuse certificates, using each certificate only for a specific time period before another certificate is used. For example, each certificate might be used for five minutes before the next certificate is used. Each certificate can also include a different pseudonym as an identifier. This use of rotating certificates can prevent vehicles from being tracked by infrastructure components.

[0107] Misconduct organizations

[0108] The misconduct agency determines whether messages from an ITS site are trustworthy. If the misconduct agency determines that an ITS site is no longer trustworthy, the ITS site's certificate will be revoked.

[0109] In this way, the recipient of a V2X message can check whether the received certificate is still valid and has not been revoked. Typically, this is done by adding the certificate identifier of a certificate that cannot be trusted to a certificate revocation list.

[0110] However, this certificate revocation list can become very large. Approximately 20 certificates are issued per vehicle per week, and certificates can be issued for multiple years. In this respect, each vehicle or ITS station whose certificate is revoked adds many certificates to this revocation list.

[0111] In addition, the geographic area covered by CRL is usually very large, resulting in many ITS sites potentially being on the list.

[0112] To overcome this, CAMP decided to use hash chains. A hash chain starts with a seed value and hashes it, then hashes that hash, then hashes that hash again, and so on. The result is a series of values ​​called linkage seeds, each a hash of a previous linkage seed. Link values ​​can be generated from the linkage seeds.

[0113] When generating an ECQV certificate, the certificate authority places the k-th link value (or a portion thereof) in the management section of the certificate used for the k-th time. To revoke an ITS site, the misconduct authority places the current link seed in the CRL.

[0114] The receiver can quickly calculate the appropriate link value associated with the link seed on the CRL and compare it with the link value in the certificate. If the link values ​​match, the certificate and its associated V2X message are rejected.

[0115] ITS sites can calculate the link values ​​associated with each link seed on the CRL weekly and store them in memory.

[0116] However, the above description is simplified. For privacy reasons, CAMP requires two sets of hash chains. Typically, each set utilizes the behavior described above.

[0117] In CAMP, link values ​​are generated by two linking agencies (LA1 and LA2). Each linking agency generates random link seeds ls1(0) and ls2(0) for each ITS station. Then, the linking agencies iteratively generate link seeds ls1(i) and ls2(i) at subsequent time i, where i corresponds to the number of weeks.

[0118] Link values ​​are generated from these link seeds and are placed within the ECQV certificate. Two distinct link values ​​are provided for each certificate that a vehicle can use within a given week. For the time value (i,j), LA1 uses AES and XOR to compute the value plv1(i,j) as the ID. LA1 The functions ls1(i) and j. In this case, j corresponds to the given certificate used in week i.

[0119] More specifically, in AES operation, a first link seed is used as a key to generate a bit set, which is XORed with an equivalent bit set provided using a second link value, and this is provided by the transport ITS station in the certificate. This operation is performed by the certificate authority.

[0120] For each misbehaving ITS station, the CRL contains two link seeds from each linking agency. Receiving vehicles can generate all possible link value pairs from these seeds, which may be used by the misbehaving vehicle at any given time during the week or subsequent weeks. Vehicles receiving V2X messages perform the same AES and XOR operations as described above on the link value pairs derived from the link seed information in the CRL.

[0121] By comparing this sequence with the sequence received in the certificate, the V2X message receiving ITS station can determine whether a message should be discarded because it was sent by an untrusted vehicle.

[0122] Using this system, no single linking agency can track a specific vehicle without colluding with another linking agency.

[0123] Based on the above principles, regarding Figure 5 A CAMP system architecture is described.

[0124] In particular, Figure 5 An embodiment provides a structure in which at least two logical roles need to communicate in order to obtain sufficient information to track vehicles, thereby mitigating unauthorized communication. These two logical roles can be performed by different organizations.

[0125] exist Figure 5In one embodiment, the SCMS manager 510 sets a misconduct reversal policy as shown in box 512, and also provides technical information as shown in box 514.

[0126] Device Configuration Manager 520 provides SCMS configuration information to various devices 522. For example, Device Configuration Manager 520 can provide information such as changes to network addresses and network element certificates.

[0127] Registration certificate authority 524 issues a registration certificate to the equipment, which can then use the registration certificate for purposes such as spoofing certificates. Furthermore, different registration certificate authorities can issue registration certificates for different geographical regions, manufacturers, or equipment types.

[0128] Linking authorities (such as linking authorities 530 and 532) generate link values ​​that are used in certificates and support certificate revocation. Using two linking authorities prevents a single linking authority operator from linking certificates belonging to a specific device, thus preventing a single linking authority from tracking the device.

[0129] Location ambiguity agent 534 changes the device source address and prevents linking network addresses to locations.

[0130] The misconduct agency 540 determines which devices are misbehaving based on the reports it receives and adds these devices to a blacklist managed by an internal blacklist manager 542 and a CRL managed by a CRL generator 544. Misconduct detection is performed by a global detection module 546.

[0131] The pseudonym certificate authority (PCA) issues pseudonym certificates to devices, and each certificate is only valid for a limited and specified period. PCA PCAs can be limited to specific geographic areas, be used by specific manufacturers, or be used for specific types of devices.

[0132] Registration Authority 560 verifies and processes requests for pseudonymous certificates and forwards them to Pseudonymous Certificate Authority 550.

[0133] Intermediate Certificate Authority 570 is part of a chain of trust that leads back to Root CA 572, enabling the intermediate CA to issue certificates on behalf of Root CA 572. Root Certificate Authority 572 is a trusted entity whose certificates can be used to verify information or identity provided by the certificate issuer. Root CA can be managed by Root Management Function 574.

[0134] use Figure 5 Given this structure, fast signature verification is possible. Fast signature verification, specified in Section 5.3.1 of IEEE 1609.2, is a technique that can be used in conventional DSRC systems to reduce the processing burden when checking signatures. Specifically, this section specifies:

[0135] This standard specifies the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) as specified in Federal Information Processing Standard (FIPS) 186-4, optionally including additional information in the signature as specified in SEC 1 Version 2. See also Section 6.3.29: If the signature process follows the SEC 1 specification and outputs an elliptic curve point R to allow for rapid verification, R is denoted as EccP256CurvePoint, which indicates to the sender, at their discretion, whether compressed (-y-0), compressed (-y-1), or uncompressed.

[0136] However, using CRL to manage misbehaving vehicles or V2X endpoints has drawbacks for various reasons.

[0137] The first factor can be the length of the CRL, which can be very large. In particular, a CRL can cover a very large geographic area, and within such an area, there can be many modes of transport. Additionally, each ITS station or service type can have multiple CRLs, which can result in many large CRLs needing to be searched before identifying misbehaving vehicles.

[0138] For ITS stations acting as V2X message receivers, using large CRLs can be cumbersome in terms of processing and storage. Each ITS station must compare the identifier of the certificate for each received message with the identity of all certificates indicated by the CRL. This comparison determines whether the message can be trusted.

[0139] For example, in an urban environment, based on 100 adjacent vehicles or ITS stations, each ITS station can receive approximately 1,000 signed messages per second, with each ITS station sending 10 messages per second. This could be, for example, basic service messaging.

[0140] Additionally, supplying large CRLs or sets of CRLs to ITS stations may potentially waste cellular resources. Resources are also wasted when transmitting cellular network messages in the downlink that are only intended to be discarded by the ITS station receiver.

[0141] Based on this, according to embodiments of the present disclosure, a V2X application server can be used to process message passing and indicate such processing in message passing delivered to the ITS station.

[0142] For example, in the case of cellular V2X, where a message from a vehicle is sent or broadcast to another vehicle via a V2X application server accessed through the cellular infrastructure, the V2X application server can first determine whether the message from the sending ITS station is trustworthy. If the message is not trustworthy, the application server can choose not to forward the message to one or more other ITS stations through the cellular infrastructure, or choose to mark the message before sending it back to one or more other ITS stations through the cellular infrastructure.

[0143] Now for reference Figure 6 It illustrates the process at a network element such as a V2X application server. A V2X application server can be a trusted server associated with a cellular network or another type of network.

[0144] In particular, Figure 6 The process begins at box 610 and proceeds to box 612, where the message from a sending entity such as an ITS station is received by the application server. For example, the message at box 612 could be a basic security message. This message could have been sent by the ITS station or from another V2X application server within the network. If the message was sent by an ITS station on or near a road, it could be transmitted from the ITS station over the cellular network via the uplink using Uu unicast or a sidelink ProSe (PC5) connection.

[0145] The process proceeds from box 612 to box 620, where checks are performed on the message received at box 612. In particular, the checks in box 620 may involve one or more of a plurality of checks on the message.

[0146] Specifically, the first check could be whether the link value in the certificate of the message received at box 612 is associated with the link value calculated from the link seed provided on the CRL. More generally, the first check could be whether the certificate of the vehicle being sent appears on the CRL.

[0147] The second check at box 620 could be whether the certificate is authentic. In other words, this check could be whether the certificate signature matches the certificate content.

[0148] The third check at box 620 could be a check that the received message at box 612 is correctly signed. In other words, the third check could be that the V2X message signature correctly corresponds to the V2X message content, and that the message is correctly associated with the provided certificate. As mentioned above, the third check could optionally be implemented using a fast signature verification method.

[0149] The fourth check at box 620 could be checking the reasonableness of data in a V2X message. For example, a reasonableness check could be that if a vehicle reports traveling at 1000 km / h or at an altitude of 10,000 meters, such a report is unreasonable and the message can be discarded. This reasonableness check could use thresholds set on the V2X application server, for example, to determine whether the data in the message is within a reasonable threshold. It is understood that, compared to the case of receiving vehicles near the transmitting ITS station transmitting the original message, the V2X application server typically has less information available to process for performing a reasonableness check.

[0150] At box 620, any one or a combination of the four checks above can be performed in any order to determine whether the message is valid.

[0151] If the message is found to be invalid, the process can proceed to box 622, where the message is discarded. In other words, the message will not be forwarded into the cellular network for transmission to other vehicles.

[0152] Alternatively, the process can proceed from box 620 to box 624, in which the message is forwarded to the vehicle regardless, but additional information is added to the message to indicate whether the check has been performed in the infrastructure and whether the message indicates whether each check passed or failed.

[0153] Specifically, the message received at box 612 can be modified to include a notification before forwarding regarding whether a check has already been performed by the infrastructure and whether that check passed or failed. This can be indicated to the receiving ITS station if some or all of the aforementioned checks have already been performed. Thus, the burden of performing these checks can be removed from the ITS station's V2X message receiver processor, as the ITS station can choose not to re-perform the checks.

[0154] A new field in the message forwarded to the ITS station receiver can indicate that an inspection has been performed. Alternatively, a V2X inspection service provided by a V2X application server associated with the 3GPP network can be instructed to users on the 3GPP network broadcast channel.

[0155] For example, refer to Table 2 below, which shows the proposed new fields in the V2X CAM message that provide an indication of the "inspection service" that has been performed.

[0156]

[0157]

[0158]

[0159] Table 2: Instructions for "Inspection Service" performed on specific messages using new fields in V2X CAM messages

[0160] In Table 2 above, the new indicators are shown in bold. Specifically, ProxyPerformedCRLCheck is a data structure containing two indicators. The first indicator shows whether the proxy has checked certificates not identified on the CRL. The second indicator can indicate whether the check passed or failed.

[0161] Additionally, in Table 2, the ProxyPerformedCertCheck field can be a data structure containing two indicators. One indicator provides an indication of whether the proxy has verified the authenticity of the certificate provided by the vehicle that initially sent the CAM message. The second indicator can indicate whether the check passed or failed.

[0162] According to Table 2 above, `ProxyPerformedMsgSigCheck` can be a third field. This field is a data structure that can contain two indicators. The first indicator indicates whether the proxy has performed a check to ensure that the associated V2X message and its corresponding message signature provided from the ITS station that sent the original message are correct. The second indicator in this field indicates whether the check passed or failed.

[0163] Additionally, according to Table 2 above, the ProxyPerformedDataPlausibility field can be a data structure that contains two indicators. One indicator can be whether the proxy has performed a basic data plausibility check on the V2X message content. Basic data plausibility refers to the fact that plausibility checks can be optionally performed when sensor information from the sensors at the location of the V2X message source vehicle is not required. The second indicator can be whether the check passed or failed.

[0164] In the above indicators, the indicator can be represented by one or more bits.

[0165] However, the fields provided in Table 2 are merely examples, and more fields may be provided in some cases. In other cases, only a subset of the fields in Table 2 may be provided. Other options are also possible.

[0166] In one option, instead of instructing the receiving ITS station which checks have been performed by the network element, the network element instructs the ITS station which checks the ITS station needs to perform or which checks the ITS station does not need to perform.

[0167] Although Table 2 identifies CAM messages, a similar approach can be used for any specified V2X application message, including ETSI DENM messages or basic security messages defined by SAE.

[0168] Additionally, after performing security checks, the V2X application server can remove security information from the V2X message before forwarding it back to the cellular network. This saves radio resources. Furthermore, an implicit indication that a security check has been performed will be provided to the receiving ITS station. Examples of security information that can be removed from the V2X message forwarded at box 630 may include certificate removal and message signature removal.

[0169] Refer again Figure 6 If a message as shown in box 624 is forwarded, the receiving ITS station will need to trust the content of such a message. In particular, in order for the V2X message receiving ITS station to use checks already performed by the V2X application server, or in cases where the infrastructure has completely removed certain application-layer security information, thereby reducing the processing burden on the receiving ITS station, the receiving ITS station must be able to trust the infrastructure that has performed the checks and / or message modifications.

[0170] Trust can be implemented in various ways. In the first option, the V2X application server, or at least a portion thereof, that performs the checks and / or message modifications can be considered to be within the operating domain of a 3GPP operator. In this case, since the application server is located within the domain of a 3GPP operator, that domain will be considered trusted, and therefore the application server will also be considered trusted.

[0171] Trust between ITS stations and 3GPP operator domains, which are part of the cellular network and optional V2X application servers, can be established using existing methods. Specifically, ITS stations communicating with the 3GPP access network for V2X messaging purposes can use, for example, subscriber identity module (SIM) credentials to mutually authenticate themselves with the 3GPP network via the 3GPP attachment process.

[0172] In this way, vehicles can be confident that they are communicating with a genuine 3GPP network and therefore have the necessary level of trust. Thus, when a message created by the 3GPP network operator indicates that a V2X message application layer security check has been performed, the receiving ITS station can be confident that this check has indeed been performed. Similarly, if a message modification has been made, the receiving ITS station can trust that the modification was made within the 3GPP operator's domain.

[0173] In the second alternative, the V2X application server can sign its generated messages using a private V2X application server key. The ITS receiving station can be pre-supplied with the V2X application server's public key. In this way, vehicles receiving V2X messages from the network can verify the signature, thus gaining additional confidence that the trusted V2X application server has performed security checks and / or message modifications.

[0174] The second alternative introduces a new security processing burden on the V2X message receiving device. However, it still incurs less processing burden compared to existing solutions that utilize CRL lists, which require the message receiver to evaluate whether the identifier of the received certificate is indicated on the CRL. Furthermore, time optimizations to alleviate the burden on the receiving device could include optional information in the signature created by the V2X application server, allowing verification to proceed more quickly.

[0175] From box 622 or box 624, the process can optionally proceed to box 626, where the V2X application server can cache information to identify a certificate or entity associated with a V2X message that has failed one or more checks performed at box 620. In other words, the V2X application server can cache pseudo-identifiers used for messages so that it can more efficiently process future V2X messages from the ITS station using the same or associated certificate identifier. The pseudo-identifier can be, for example, a link value. The cache may also include adding associated information with the pseudo-identifier, including one or more of the following: security check results, message forwarding behavior, or message discarding handling. At step 620, when a new message with a first pseudonym identifier associated with a pseudonym identifier in the cache is received at the V2X application server, the V2X application server can access the cached information to accelerate or reduce processing by avoiding repeated security checks, determining message forwarding behavior, and / or determining message discarding actions, which may have been previously performed for messages associated with this first pseudonym identifier. Determining message forwarding behavior may include determining whether message field content has been added, removed, or changed in forwarded messages.

[0176] Alternatively, starting from box 620, if all checks performed by the V2X application server pass, the process can proceed to box 630, where a new V2X message containing the same or substantially similar content as the message received at box 612 can be forwarded to the cellular network for transmission to other ITS stations.

[0177] For example, message forwarding at box 630 can occur using any of the following: MBMS downlink, Uu unicast downlink, or ProSePC5 sidelink.

[0178] Optionally, additional information can be added to the message to indicate which checks have been performed within the infrastructure element, and optionally, which checks have passed. This removes the processing burden associated with performing these checks from the ITS receiver. Therefore, the message forwarded at box 630 can have fields similar to those described in Table 2 above.

[0179] Alternatively, as described above, the message forwarding behavior can also be cached at box 626 and used at box 620.

[0180] The process can proceed from box 630 to box 640 and then end.

[0181] Similarly, the process can proceed from boxes 622, 624, or 626 to box 640 and end there.

[0182] As those skilled in the art will understand, Figure 6 Implementations may require the application server to obtain the CRL. However, since V2X application server networks interface with 3GPP radio networks will typically need to distribute the CRL to ITS stations via the 3GPP radio network, the application server can simply retain a copy of this CRL for its own inspection.

[0183] Therefore, in addition to forwarding the CRL, the application server can also store this CRL for inspection at box 620.

[0184] Additionally, as those skilled in the art will understand, security and data legitimacy checks on V2X messages in application servers associated with 3GPP operators also apply if the initiator of the V2X message is not a vehicle or road user. For example, this can also be applied when the message is initiated by or transmitted via another V2X application server. Figure 6 This is an example of an implementation. When the V2X application server has already generated the message itself, the features of box 630 (such as ignoring security information or indicating that security checks have been performed) can also be applied. Therefore, even when the V2X message is initiated by the V2X application server, it is possible to indicate to the receiving ITS station that certain checks have been completed or to ignore certain security information from the forwarded message.

[0185] Specifically, in one embodiment, the above Figure 2 The V2X application server 250 can be combined with an ITS station to form a fixed infrastructure node with application layer capabilities. In this case, the V2X application server will act as an ITS station and form a network element.

[0186] refer to Figure 7 This illustrates the process at a network entity that also acts as a V2X application server. In this case, the application server does not edit messages being transmitted between ITS stations, but rather generates messages to be sent to one or more receiving ITS stations. In this respect, the process begins at box 710 and proceeds to box 712, where the message is generated.

[0187] For example, in one scenario, a V2X application server could form part of a traffic light system. In this case, the message generated at box 712 could include information about the stage and color of the traffic light, which could then be broadcast to vehicles approaching the intersection.

[0188] In other cases, V2X application servers may have other functionalities, and only the example of traffic light use is provided for illustrative purposes.

[0189] The process proceeds from box 712 to box 720, where security check information can be indicated in a message. For example, this indication can be accompanied by information similar to that described above with respect to Table 2. Specifically, the information added to this message enables the receiving ITS station to know which security checks need to be performed at the receiving ITS station.

[0190] In other embodiments, in block 712, the network entity may generate a message that does not include security information such as signatures and / or certificates that would appear in a standard V2X message.

[0191] Therefore, for example, if the V2X application server is a trusted network element, the ITS station knows that the certificate in the message sent from the V2X application server will not appear on the CRL, and therefore the receiving ITS station does not need to use the CRL to check any certificates that can be included in the message to determine the validity of the message.

[0192] Similarly, if the V2X application server is part of a 3GPP network, the certificate or signature may not need to be checked, and according to Table 2 above, these fields can be specified as already performed, thus alleviating the burden on the receiving ITS station.

[0193] Similarly, if the V2X application server has information about the validity of the data, it can also be added as a field to the message generated in box 712.

[0194] The process proceeds from box 720 to box 730, where the message is forwarded to one or more receiving ITS stations. As described above... Figure 6Similar to the messages forwarded in boxes 624 and 630, in some embodiments, the message may be forwarded at box 730 as a broadcast message or a unicast message.

[0195] The process proceeds from box 730 to box 740 and then ends.

[0196] Therefore, the above embodiments allow certain security checks to be performed at the network or to mark network-generated messages to indicate that no security checks are required, thereby reducing the burden on receiving ITS stations.

[0197] The application servers, ITS stations, and network elements described above can be any computing device or network node. Such computing devices or network nodes can include any type of electronic device, including but not limited to mobile devices such as smartphones or cellular phones. Examples may also include fixed or mobile user equipment, such as Internet of Things (IoT) devices, endpoints, home automation devices, medical devices in hospital or home environments, inventory tracking devices, environmental monitoring devices, energy management devices, infrastructure management devices, vehicles or devices for vehicles, fixed electronic equipment, etc. Vehicles include motorized vehicles (e.g., cars, sedans, trucks, buses, motorcycles, etc.), aircraft (e.g., airplanes, unmanned aerial vehicles, unmanned aerial vehicle systems, drones, helicopters, etc.), spacecraft (e.g., space shuttles, spacecraft capsules, space stations, satellites, etc.), ships (e.g., vessels, ships, hovercraft, submarines, etc.), rail transport (e.g., trains and trams, etc.), and other types of vehicles, including combinations of any of the foregoing items, whether currently existing or subsequently developed.

[0198] about Figure 8 A simplified diagram of a computing device is shown. Figure 8 The computing device can be any mobile device, portable device, ITS station, server, or other node as described above.

[0199] exist Figure 8 In this embodiment, device 810 includes a processor 820 and a communication subsystem 830, wherein the processor 820 and the communication subsystem 830 cooperate to perform the methods described above. In some embodiments, the communication subsystem 820 may include, for example, multiple subsystems for different radio technologies.

[0200] Processor 820 is configured to execute programmable logic, which can be stored on device 810 along with data, and the programmable logic in Figure 8In the example, it is shown as memory 840. Memory 840 can be any tangible, non-transient computer-readable storage medium. Computer-readable storage media can be tangible or transient / non-transient media, such as optical (e.g., CD, DVD, etc.), magnetic (e.g., magnetic tape), flash memory drives, hard disk drives, or other memories known in the art.

[0201] As an alternative or supplement to the memory 840, the device 810 can, for example, access data or programmable logic from an external storage medium via the communication subsystem 830.

[0202] The communication subsystem 830 allows device 810 to communicate with other devices or network elements and can vary depending on the type of communication being performed. Furthermore, the communication subsystem 830 can include a variety of communication technologies, including any wired or wireless communication technology.

[0203] In one embodiment, communication between the various components of device 810 can be achieved via internal bus 860. However, other forms of communication are also possible.

[0204] The embodiments described herein are examples of structures, systems, or methods having elements corresponding to the elements of the present application. This written description enables those skilled in the art to make and use embodiments having alternative elements that correspond in the same way to the elements of the present application. Therefore, the intended scope of the technology of this application includes other structures, systems, or methods that are not different from the technology of this application described herein, and also includes other structures, systems, or methods that are not substantially different from the technology of this application described herein.

[0205] Although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring that such operations be performed in the specific order shown or in a sequential order, or that all the illustrated operations be performed to obtain the desired result. In some cases, multitasking and parallel processing may be employed. Furthermore, the separation of the various system components in the above implementation should not be construed as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated into a single software product or packaged into multiple software products.

[0206] Furthermore, technologies, systems, subsystems, and methods described and illustrated as discrete or separate in various implementations can be combined or integrated with other systems, modules, technologies, or methods. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating electrically, mechanically, or otherwise through some interface, device, or intermediate component. Other examples of changes, substitutions, and alterations can be determined by those skilled in the art and can be made.

[0207] Although the specific embodiments described above have shown, described, and pointed out the essential novel features of this disclosure applicable to various embodiments, it should be understood that those skilled in the art can make various omissions, substitutions, and changes to the form and details of the illustrated system. Furthermore, the order of the method steps is not implied by the order in which they appear in the claims.

[0208] When messages are sent to or from electronic devices, this operation may not be immediate or originate directly from a server. They may be delivered synchronously or asynchronously from a server or other computing system infrastructure that supports the devices / methods / systems described herein. The foregoing steps may include, in whole or in part, synchronous / asynchronous communication to / from the device / infrastructure. Furthermore, communication from electronic devices may be to one or more endpoints on a network. These endpoints may be served by servers, distributed computing systems, stream processors, etc. Content delivery networks (CDNs) may also provide communication to electronic devices. For example, in addition to a typical server response, a server may feed or instruct data for use with the content delivery network (CDN) to await download by the electronic device later, such as subsequent activities of the electronic device. Therefore, data may be sent directly from a server or other infrastructure (such as a distributed infrastructure or CDN) as part of the system or separately from the system.

[0209] Typically, storage media can include any or a combination of the following: semiconductor storage devices, such as dynamic or static random access memory (DRAM or SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory; magnetic disks, such as fixed disks, floppy disks, and removable disks; another magnetic medium, including magnetic tape; optical media, such as optical discs (CDs) or digital versatile optical discs (DVDs); or another type of storage device. Note that the instructions discussed above can be provided on a single computer-readable or machine-readable storage medium, or alternatively, on multiple computer-readable or machine-readable storage media distributed across a large system that may have multiple nodes. Such one or more computer-readable or machine-readable storage media are considered part of an article (or article of manufacture). An article or article of manufacture can refer to any single or multiple components manufactured. One or more storage media can be located in a machine that executes machine-readable instructions or at a remote site from which machine-readable instructions can be downloaded via a network for execution.

[0210] In the foregoing description, numerous details have been set forth to provide an understanding of the subject matter disclosed herein. However, these implementations can be practiced without some of these details. Other implementations may include modifications and variations to the foregoing details. Such modifications and variations are intended to be covered by the appended claims.

Claims

1. A method for processing a first message at a network element, the method comprising: Multiple checks are performed on the first message, which is destined for an intelligent transportation system station, an endpoint associated with a road user; the multiple checks are performed on behalf of the intelligent transportation system station. The first message is modified, the modification providing the intelligent transportation system station with instructions for the plurality of checks performed by the network element, thereby creating a second message; as well as Forward the second message to the intelligent transportation system station. The network element is separate from and trusted by the smart transportation system station, and the indication includes a list of multiple security checks and whether the security checks pass or fail.

2. The method according to claim 1, wherein upon receiving the first message, the method further comprises: The security credentials of the first message are checked, and the check includes: finding whether a first identifier in the certificate received in the first message is associated with a second identifier of the certificate, the second identifier being determined based on information on a certificate revocation list.

3. The method of claim 2, wherein the first identifier in the certificate is a link value, and the information on the certificate revocation list is one or more link seeds.

4. The method according to claim 1, wherein upon receiving the first message, the method further comprises: The security credentials of the first message are checked, and the check includes verifying that the signature of the certificate in the first message matches the content of the certificate.

5. The method according to claim 1, wherein upon receiving the first message, the method further comprises: The security credentials of the first message are checked, and the check includes verifying that the first message has a signature that correctly corresponds to the content of the first message, and that the first message is correctly associated with the certificate in the first message.

6. The method according to claim 1, wherein upon receiving the first message, the method further comprises: Check the data validity of the data in the first message to ensure that the data value is within the set threshold.

7. The method of claim 1, wherein the network element is operated by an operator who also operates the cellular network.

8. The method of claim 1, wherein the network element has a previously established trust relationship with the smart transportation system station.

9. The method of claim 8, wherein the trust relationship was previously established using a cellular network attachment process.

10. The method of claim 1, wherein the first message is one of: a collaboration-aware message; a distributed environment notification message; or a basic security message.

11. The method according to claim 1, further comprising: The cache is used to send the entity's identifier and associated information, which includes one or more of the following: security check results, message forwarding behavior, or message discarding processing.

12. The method of claim 1, wherein the second message is formed without the need for one or more signatures or certificates of the sending entity, the sending entity sending the first message to the smart transportation system station via the network element.

13. The method according to claim 1, further comprising: Add the signature of the network element to the second message.

14. A network element configured to process a first message, the network element comprising: processor; as well as The communication subsystem, wherein the network element is configured as follows: Multiple checks are performed on the first message, which is destined for an intelligent transportation system station, an endpoint associated with a road user; the multiple checks are performed on behalf of the intelligent transportation system station. The network element is configured to modify the first message by providing the intelligent transportation system station with instructions for the plurality of checks performed by the network element, thereby creating a second message; as well as Forward the second message to the intelligent transportation system station. The network element is separate from and trusted by the smart transportation system station, and the indication includes a list of multiple security checks and whether the security checks pass or fail.

15. The network element of claim 14, wherein upon receiving the first message, the network element is further configured to check the security credentials of the first message, and wherein the check includes: Check whether a first identifier in the certificate received in the first message is associated with a second identifier of the certificate, the second identifier being determined based on information on the certificate revocation list.

16. The network element of claim 15, wherein the first identifier in the certificate is a link value, and the information on the certificate revocation list is one or more link seeds.

17. The network element of claim 14, wherein upon receiving the first message, the network element is further configured to check the security credentials of the first message, and wherein the check includes: Verify that the signature of the certificate in the first message matches the content of the certificate.

18. The network element of claim 14, wherein upon receiving the first message, the network element is further configured to check the security credentials of the first message, and wherein the check includes: Verify that the first message has a signature that correctly corresponds to the content of the first message, and that the first message is correctly associated with the certificate in the first message.

19. The network element of claim 14, wherein upon receiving the first message, the network element is further configured to check the data reasonableness of the data within the first message to ensure that the data value is within a set threshold.

20. A non-transient computer-readable medium for storing instruction code for processing a first message, the instruction code causing the network element, when executed by a processor of a network element, to: Multiple checks are performed on the first message, which is destined for an intelligent transportation system station, an endpoint associated with a road user; the multiple checks are performed on behalf of the intelligent transportation system station. By modifying the first message, the network element is made to be modified as follows: Provide the intelligent transportation system station with instructions for the plurality of checks performed by the network elements, thereby creating a second message; and Forward the second message to the intelligent transportation system station. in, The network element is separate from and trusted by the smart transportation system station, and the indication includes a list of multiple security checks and whether the security checks pass or fail.

Images