System for authenticating and authorizing access to wireless access vehicle environment and billing wireless access vehicle environment consumption by client device

Abstract

A system and method for authenticating and authorizing access of an IPv6 connection to the Internet over a Wireless Access Vehicle Environment (WAVE) service channel and charging bandwidth consumption of a client device over the IPv6 connection using an Authentication, Authorization and Charging (AAA) server is disclosed. The AAA server authenticates and authorizes the client device to access the WAVE service channel and charges bandwidth consumption of the client device that accesses the Internet using the WAVE service channel. The AAA server enables the RSU infrastructure operator to quantify the wireless bandwidth consumption of the in-vehicle device using the WAVE service channel on a per-device basis.

Description

Related Applications

[0001] This application is a divisional application of the invention patent application with the filing date of the parent case being December 28, 2017, the application number being 201780098255.8, and the invention name being "System for authenticating and authorizing access to a wireless access vehicle environment and charging for wireless access vehicle environment consumption by a client device". Each of the following applications is incorporated herein by reference in its entirety, including the original documents filed at the time of filing: i) U.S. Provisional Patent Application No. 62 / 357,504 filed on July 1, 2016; ii) PCT patent application PCT / IB2017 / 053981 filed on June 30, 2017; and iii) U.S. patent application 15 / 639,022 filed on June 30, 2017. Background Art

[0002] In January 2016, the U.S. Secretary of Transportation announced that USDOT is implementing Federal Motor Vehicle Safety Standard (FMVSS) 150 based on vehicle-to-vehicle (V2V) communication technology called dedicated short-range communications (DSRC). DSRC operates on a 75MHz band centered at 5.9GHz, which had previously been allocated by the FCC to support a wide range of intelligent transportation system (ITS) applications. During 2002-2009, the IEEE developed the 1609 protocol specification suite that governs the use of the frequency band, which is divided into seven channels, each 10MHz wide. Four of the channels support IPv6 (Internet Protocol version 6) interfaces, which means that applications based on UDP / IPv6 or TCP / IPv6 can operate on these channels.

[0003] The protocol specifications contained in the IEEE 1609 suite, commonly referred to as the Wireless Access Vehicular Environment (WAVE) and incorporated herein by reference, incorporate security provisions to ensure authentication of WAVE-enabled onboard equipment (OBE) attempting to communicate with roadside equipment (RSE). The terms OBE and RSE are generally interchangeable with OBU (onboard unit) and RSU (roadside unit). OBUs generally include, but are not limited to, mobile computing devices that support DSRC communications, meet the V2V requirements specified in SAE J2945 / 1 and SAE J2945 / 2, or the V2P requirements specified in future variants of SAE J2945. RSUs generally include, but are not limited to, fixed or quasi-fixed computing devices that support DSRC communications, comply with the IEEE 802.11p specifications for the DSRC MAC and PHY layers (i.e., the WAVE protocol stack), and are capable of broadcasting WAVE service announcements (WSA) on the DSRC control channel (CCH). OBU devices without valid security credentials can be effectively rejected by the RSU's WSA, which is generally achieved by simply discarding the transmission sent by the OBU. WSA is a periodic message defined by the IEEE 1609 protocol suite that identifies services available on a network.

[0004] These above security provisions presented in the IEEE 1609 protocol are intended to control access to services resident in or accessible to the RSU through dedicated application software in the RSU; that is, services that the RSU "knows" and the RSU has policy responsibility to control access to. Examples of such services include, but are not limited to, traveler information, vehicle signage, navigation, traffic management, weather information, security, electronic payment, network services, configuration management, etc.

[0005] In the case of IPv6 communications, the role of the RSU is to route IPv6 datagrams to their destination address. The WAVE architecture provides authentication of the OBU based on a digital signature in the header of the WAVE Short Message Protocol (WSMP) message originating from the OBU. The digital signature is generated by the OBU based on asymmetric encryption techniques, and the transmitted message also includes a certificate containing a public key so that the receiving RSU can decrypt the signature. The DSRC Infrastructure Management Authority ("Infrastructure Management Authority") can propagate a certificate revocation list to the RSU, which identifies OBU devices whose security credentials are no longer valid. This can be used by the RSU as a criterion for discarding OBU messages sent using WSMP.

[0006] In U.S. Patent Application 14 / 151,035 (incorporated herein by reference), a system is disclosed that enables a user interface device, such as a smartphone or tablet, to establish a connection to the Internet by using the mechanism defined in RFC 4861 for router discovery. This mechanism allows a user device to attach itself to an OBU using Stateless Address Auto-Configuration (SLAAC), for example, over a WiFi point-to-point (WiFi Direct) interface. The OBU acts as an IPv6 router, enabling the user device to connect to the Internet through any RSU that advertises the availability of one or more WAVE service channels for this purpose. The system also provides the basis for a method of user device authentication. Summary of the invention

[0007] In one aspect, a system and method are disclosed that perform authentication, authorization, and accounting (AAA) functions required to enable an RSU infrastructure operator to quantify wireless bandwidth consumption by in-vehicle devices using a WAVE service channel on a per-device basis.

[0008] Another aspect provides an AAA server operated by or on behalf of a DSRC infrastructure management agency, the server comprising at least one processor running at least one computer program adapted to communicate via the Internet with a plurality of mobile devices and / or an OBU operating a subnet of one or more mobile devices to perform authentication, authorization and accounting (AAA), thereby enabling the management agency to bill for WAVE service channel bandwidth consumption by each of the mobile devices that has been appropriately provisioned by the AAA server.

[0009] Another aspect provides a plurality of AAA servers operated by or on behalf of a DSRC infrastructure management agency, each server comprising at least one processor running at least one computer program adapted to communicate with a plurality of mobile devices and with a plurality of RSUs via the Internet to perform authentication, authorization and billing, the plurality of AAA servers being arranged to load balance inbound Internet traffic and enable the management agency to bill for WAVE service channel bandwidth consumption by each of the mobile devices and / or the OBU of a subnet operating one or more of the mobile devices, the mobile devices having been appropriately provisioned in a single database, access to which is synchronized among the plurality of AAA servers.

[0010] Another aspect provides an RSU configured with an extended IPv6 management information base (MIB) that is operable to determine packet and byte count statistics used by each client device's WAVE service channel. The client device may be an OBU, a non-DSRC mobile device that can reach IPv6 through the OBU, or a user device that supports DSRC. The IPv6 MIB is also operable to retrieve the fixed "home address" of the mobile node carried in the mobile IPv6 routing header of each datagram received from an IPv6 node operating in a mobile IPv6 routing optimization mode. The RSU is operable to accumulate packet and byte count statistics used by each client device's WAVE service channel in a non-volatile random access memory (NOVRAM), and periodically send the statistics (encapsulated in a UDP / IP message) to an AAA server, refreshing the NOVRAM table only when the AAA server has acknowledged receipt of the UDP / IP message.

[0011] Another aspect provides an OBU that is compliant with WAVE and IEEE 802.11p and is configurable to have dual radio capabilities, runs at least one application-level computer program adapted to request authentication and authorization from an AAA server on behalf of a neighboring non-DSRC mobile device or for itself to enable IPv6 connectivity to the Internet, and is configured with an extended IPv6 MIB that is operable to retrieve the addresses of neighboring devices when new entries are inserted into a routing table, to periodically retrieve the routing table using a synchronous method based on SNMP GET, or to report "real-time" changes in the routing table using an asynchronous method based on SNMP TRAP. It should be understood that other methods may be implemented to update the routing table without departing from the present invention.

[0012] Another aspect provides a non-DSRC mobile device that is operable to request "Internet subscription" credentials from an AAA server using a symmetrically encrypted communication channel established over SSL or a similar handshake protocol for mutual authentication and key exchange, and is operable to use these "Internet subscription" credentials when responding to an authentication challenge message received from the AAA server, as defined in one or more exemplary embodiments or aspects of this document. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Other objects, features and advantages of the present invention will be readily understood as they will become better understood after reading the following description taken in conjunction with the accompanying drawings, in which:

[0014] Figure 1a is a system block diagram showing the authorization process and the authentication process between the user equipment and the AAA server according to the present invention;

[0015] Figure 1b is a system block diagram showing a method for retrieving an IP source address from a routing table using the Simple Network Management Protocol;

[0016] Figure 1c is a system block diagram showing another method for retrieving an IP source address from a routing table using a simple network management protocol;

[0017] Figure 2 is a system block diagram showing another embodiment of the authorization and authentication process between the vehicle-mounted unit and the AAA server;

[0018] Figure 3 is a system block diagram showing an embodiment of an authentication process according to the present invention;

[0019] Figure 4 is a system block diagram showing an authentication process for an external device according to the present invention;

[0020] Figure 5 is a block diagram illustrating a protocol stack over a wireless access vehicle environment utilizing a border gateway protocol;

[0021] Figure 6 is a system block diagram illustrating a process for distributing security credentials according to another embodiment of the present invention;

[0022] Figure 7 is a system block diagram showing another authentication and authorization process for an external device according to the present invention;

[0023] Figure 8 is a system block diagram showing the communication between the AAA server and multiple roadside units;

[0024] Fig. 9 is a flow chart showing the authorization process according to the present invention;

[0025] Fig.10 is a system block diagram and flow chart showing blocking and unblocking of a client device (such as an in-vehicle unit) at an AAA server;

[0026] Fig.11 is a system block diagram and a flow chart showing a billing process according to the present invention; and

[0027] Fig.12 is a schematic diagram of a handshake protocol for implementing key distribution for multicast message encryption; and

[0028] Fig.13 It is a schematic diagram of the multicast message registration process. DETAILED DESCRIPTION

[0029] It should be understood that the application of the present invention is not limited to the construction details or component arrangements set forth in the following description of the exemplary embodiments or shown in the accompanying drawings. The present invention can have other embodiments and can be practiced and executed in various ways. In addition, it should be understood that the wording and terminology adopted herein are for illustrative purposes and should not be considered as restrictive. "Including (including)", "comprising (comprising)" or "having" and its variations used herein mean to include the items listed thereafter and their equivalents and additional items. In addition, the terms "connection", "coupling", "decoupling" and their variations are not limited to physical, mechanical or electrical connections or couplings. In addition, and as described in subsequent paragraphs, the specific mechanical and / or other configurations shown in the drawings are intended to illustrate embodiments of the present invention. However, other alternative configurations considered to be within the scope of the teachings of the present disclosure are also possible.

[0030] With respect to some exemplary embodiments, due to WAVE security requirements, all nodes (both mobile and fixed) are required to use the encryption method specified in IEEE 1609.2 with credentials. When the device is provisioned, the credentials are issued, and these credentials are used to create a digital signature that allows the device to authenticate itself, just as the mobile device broadcasts a basic security message (BSM) carrying a digital signature based on the issued credentials. However, when the device is provisioned, there is no explicit authorization to use the service channel for general IPv6 communication. Whether the service channel can be used should depend on whether there is a provider service identification (PSID) for this that is properly registered according to the process defined in IEEE 1609.12. It is generally believed that various forms of public-private partnerships will be used to deploy and manage DSRC infrastructure, all of which share the attributes of an "infrastructure management agency", which will address the issue of spectrum monetization in the framework of their business model. If the OBU meets the functional requirements specified in the NHTSA safety standard, the decision on whether the OBU or a third-party user device connected to the OBU can be approved for IPv6 connection through the WAVE service channel and whether to charge for bandwidth use may become a free choice of the infrastructure management agency. Thus, some exemplary embodiments may enable an infrastructure management organization to approve or deny IPv6 connections to various devices and measure the service channel bandwidth consumption associated with each device. This is achieved by implementing the present invention as described herein.

[0031] The first step is "authentication". This is based on a "login" process performed by a client device including a user device (e.g., a smartphone) or, alternatively, by an OBU acting on behalf of the user device. The distinction between these two cases depends on the business model offered by the infrastructure operator and the choices made by the owner of the OBU, which can be an OEM-manufactured device or an aftermarket add-on. For example, if the owner of the OBU bears all costs associated with IPv6 bandwidth consumption, the login will be issued from the OBU device regardless of which third-party user device is the communication endpoint. If the cost is attributable to a neighboring third-party user device, the billing of the bandwidth applies to that user device, which should therefore be the initiator of the login.

[0032] Login is essentially a request for IPv6 connection through a neighboring RSU. The user device or the OBU acting on behalf of the user device described above is a requesting device and can be referred to as a "client" or "client device". The login message is digitally signed using an encryption key obtained from a digital certificate issued by or on behalf of an infrastructure operator. The digital certificate is encapsulated in the login message, so that the recipient can decrypt the signature and verify the credentials presented in the certificate. The login message is encapsulated in a UDP / IP packet addressed to a "road authorization server" (RAS), which is an independent host maintained by an infrastructure operator. As disclosed in application No. 14 / 151,035, when a specific RSU is ready to provide IPv6 connection services to a passing OBU, it broadcasts the IP address and application port of the RAS service in a WAVE service announcement (WSA). Because the verification of the credentials constitutes an authentication step and because some exemplary embodiments of this article define the complementary functions of authorization and billing, in some exemplary embodiments, RAS is designated as an AAA server, as described in more detail below.

[0033] This authentication step is supported by an external system that is capable of verifying the credentials identified in the login message. Such a system is defined as part of the Federal Motor Vehicle Safety Standard (FMVSS) 150 and is called the Security Credentials and Management System (SCMS). SCMS is based on a public key infrastructure (PKI) architecture, in which asymmetric cryptographic keys are generated by a "root" certificate authority and encapsulated in a digital certificate that constitutes the credentials of the client device. The technical architecture of SCMS was developed by the USDOT in a joint effort with the automotive industry, represented by the Collision Avoidance Metrics Partnership (CAMP). A detailed description of SCMS can be found at http: / / federalregister.gov / a / 2014-24482 (incorporated herein by reference). The main purpose of SCMS is to ensure that devices participating in vehicle-to-vehicle (V2V) communications defined by FMVSS150 are properly authenticated and that their operation does not compromise consumer privacy. Through a secure link between the AAA server and the SCMS, the AAA server is able to request SCMS components to assist in confirming the security credentials of a particular device. The confirmation process is based on a digital signature, certificate information, and a cryptographically unique identifier of the device, all of which are encapsulated in the login received from the device. It should be understood that the digital signature, certificate information and the cryptographically unique identifier may be transmitted separately in a secure manner.

[0034] The next step is "Authorization", which has two aspects. The first aspect is to verify that the credentials of the client device have not been revoked by the credential issuing authority. This is done by using the certificate revocation list maintained by the SCMS. The current specification of the SCMS requires that the certificate revocation list be distributed only to the OBU and RSU. However, the certificate revocation list will also be distributed to the AAA server in order to enable the latter to perform the above verification. The second aspect is that the account associated with the client is in good standing, which is determined according to the policy of the infrastructure operator.

[0035] The authorization step may only be required if the authentication step passes. The Boolean result of the first step, "failure", or the logical combination of the two steps becomes the input to a mechanism that enables the AAA server to manage the IPv6 routing table of the RSU that is currently providing the connection to the client. The implementation of this capability is based on leveraging existing methods specified in IETF RFCs. Specifically, by adding Border Gateway Protocol (BGP) functionality to both the AAA server and the RSU, the AAA server is enabled for Remotely Triggered Black Hole (RTBH) filtering within the RSU, whereby IPv6 traffic from the client can be blocked or unblocked based on whether the client passes the authentication and authorization steps. This approach provides an efficient, standards-based means to control access to mobile Internet services that an infrastructure operator may want to provide, and links the appropriate authorization credentials of the client device requesting the service to the IPv6 routing table of the RSU without requiring changes to the WAVE specification suite.

[0036] The last step is billing. The RSU is configured to track the service channel bandwidth consumption of each device when using the IPv6 interface and periodically send reports to the AAA server. To achieve this, the Management Information Base (MIB) of the IPv6 layer can be extended to obtain packet and byte count statistics for each client. The consumption data is retrieved using the standard SNMP interface and transmitted to the AAA server periodically, for example, over a TCP connection.

[0037] With respect to some exemplary embodiments, the DSRC RSU routes IPv6 datagrams received from or transmitted to the OBU via the WAVE service channel. If the owner of the RSU (perhaps an "infrastructure management agency") adopts policies to control and manage the service channel bandwidth usage of individual OBUs and devices connected to the OBU, mechanisms are needed to authenticate these devices, authorize them to use the service channel, and calculate the amount of bandwidth consumed by each device. The present invention provides a server that supports these mechanisms, which is generally referred to as AAA (Authentication, Authorization, and Accounting).

[0038] A single radio OBU device that follows the required duty cycle for monitoring both the safety or "V2V" channel (now specified at CH 172 at the "bottom" of the DSRC band) and the control channel (CCH or CH 178) may not be suitable for providing IPv6 connection services, because at least its receiver will have to further divide its time between the safety channel, CCH and the specified service channel. The incremental cost of dual radio equipment is low enough to ensure that suppliers configure OBU products (aftermarket safety devices (ASD) or additional safety devices (RSD), as defined in the "V2V Preparation Report" (incorporated herein by reference)) as dual radio equipment. Therefore, in this disclosure, it is assumed that the OBU providing access to the service channel bandwidth is configured as a dual radio device. However, it should be understood that the present invention can also be implemented with a single radio device.

[0039] Since the WAVE standard allows IPv6 datagrams to be transmitted on the service channel without any restrictions, the RSU receiving the datagram will automatically route it to its destination. However, if the management policy of the RSU requires AAA for IPv6 traffic, authorization for over-the-air IPv6 communications will be requested on behalf of the OBU or one or more devices connected to it.

[0040] Figure 1a The authorization process and the authentication process between the user equipment and the AAA server according to the present invention are shown. The notification from the RSU indicating the authorization requirement is contained in a WAVE service announcement (WSA) 35. The WSA broadcasted by the RSU on the WAVE CCH constitutes the method required by the WAVE standard by which the RSU informs the OBU which services are accessible through the RSU broadcasting the WSA.

[0041] RSU 30 is configured by the infrastructure operator to issue a WSA including the IP address and port of the AAA service to which the OBU can send an authorization request. As disclosed in U.S. Patent Application 14 / 151,035, WSA has previously been used to identify only the address to which the OBU should send an authorization request. The present invention utilizes WSA to also include channel availability information that the OBU should use for channel configuration, as further described below. WSA 35 encapsulates both the IP address and port of the AAA server. WSA 35 also encapsulates the provider service identification (PSID) (to indicate that this RSU supports the availability of a universal IPv6 connection managed by AAA) and an identifier of an available service channel. Different PSIDs are established to allow the OBU to distinguish between services for which the OBU is charged billing fees for any adjacent user equipment and services associated with each user equipment and its own billing account. The utility of this distinction will be further explained below. Otherwise, as previously mentioned, if AAA is not required, WSA 35 is not required because access to the service channel can be automatic or unrestricted. As used herein, automatic refers to real-time or near real-time automated processing performed by one or more processors, non-manual and without human intervention. However, it should be understood that manual involvement may be required without departing from the invention. The payload of the WSA 35 must also contain cryptographic key material that is associated with the digital certificate issued to the AAA server and that the OBU requires to encrypt data included in its authorization request sent to the AAA server, as further explained below.

[0042] The content of WSA 35 is reported to process 21 through WSMP interface, and this process is usually the user application program that runs in OBU 20. Process 21 is implemented and executed by the processor that resides in OBU 20. It should be understood that this processor can be any easily available device that can perform the process as described in this article. The process steps or instructions that are executed by the processor of OBU 20 or user equipment 10 implement the functions / actions specified in the flowchart and / or figure that are shown in the whole figure and discussed in this article. Process 21 then registers "transmitter profile" with the MAC layer management entity (MLME) that specifies the service channel number specified in WSA. This registration of the transmitter profile ensures that whenever the policy change causes the service change notified in WSA, MLME is always updated. If IPv6 connection service is deactivated at a specific time or location (that is, a specific RSU or RSU cluster), the PSID corresponding to these services does not exist in WSA and process 21 registers a new transmitter profile that does not include the corresponding service channel number. As explained in IEEE 1609.4, when the channel router function of the IEEE 802.11p MAC layer ( Figure 1aWhen the service channel number cannot be found (not shown), the packet intended to be transmitted using this channel is discarded.

[0043] The authorization function involves a request sent by the OBU 20 to the AAA server 40, such as Figure 1a 35. The example of such a message 25 is disclosed in U.S. patent application 14 / 151,035, in which it takes the form of a UDP / IPv6 message. This message 25 is initiated by process 21, and process 21 listens to WSA 35. If the request has not been approved by AAA server 40, process 21 queues message 25 for transmission over the IPv6 interface. WSA 35 indicates that the announced service is accounted to the personal account of the third-party user device and therefore the authorization request comes from the OBU "representing" the third-party device (e.g., a nearby smart phone or tablet computer). In some exemplary embodiments, the interface between the OBU and the third-party device is a wireless link, such as WiFi direct (also known as WiFi point-to-point). In this case, the UDP payload of message 25 contains the IP source address of the user device.

[0044] The mechanism by which the user equipment 10 attaches itself to the OBU 20 requires that the latter be configured to support the IPv6 "Neighbor Discovery" specification in RFC 4861, which is incorporated herein by reference. In this specification, a network node informs its neighbors of its routing capabilities through periodic broadcasts of "Router Advertisements" (RAs) on the interfaces through which the neighbors may wish to join the network. Router Advertisements are broadcast over the network interfaces of the network. Figure 1a RA 100 is shown in FIG. 14. US patent application Ser. No. 14 / 151,035 discloses an attachment process according to the Stateless Address Auto-Configuration (SLAAC) mechanism specified in RFC 4862 (also incorporated herein by reference).

[0045] Existing systems (such as the system disclosed in U.S. patent application Ser. No. 14 / 151,035) do not disclose a method of obtaining the IP source address contained in the authorization request exemplified by message 25. When a user device attaches itself to an OBU, the latter may, in some exemplary embodiments, discover the IP source address due to receipt of a router solicitation message from the user device, as defined in RFC4861, which results in the user device's address being added to the OBU routing table. Obtaining this information requires the implementation of SNMP in the OBU. There are two possible alternative methods, respectively in Figure 1b and 1c They show the well-known protocol layers. The simplest approach ( Figure 1b ) is to configure process 21 to periodically issue SNMP GET to the local host to retrieve the ipv6RouteTable object in the IPv6MIB. The second method ( Figure 1c) is computationally more efficient, but requires an extension to the standard IPv6 MIB that defines new objects corresponding to changes in the routing table. When such a change is detected, a TRAP message is generated that can be received by a handler function 25 that registers with the SNMP layer via process 21.

[0046] Often do not recommend using WAVE as the platform of the mobile Internet service that relies on TCP at the transport layer, because the OBU address can change along with equipment moving from one RSU to another RSU.Therefore, the user equipment that will be attached to OBU itself will always find that its own IPv6 address changes along with each conversion between RSU, which will interrupt TCP session and also reduce the quality of any connection-oriented stream service above the transport layer equally.The present invention overcomes these problems by enabling user equipment to be used for mobile IPv6, which specifies and is incorporated herein by reference in RFC 6275, and is configured to " route optimization " (the 11.3.1st joint) pattern.According to one aspect of the present invention, OBU 20 becomes the main " care-of address " of adjacent user equipment.Under " route optimization " pattern, " home address " is carried in the IPv6 destination options header. This address is fixed and is used as a replacement for the IP source and destination addresses, since the latter are the "care-of" addresses of the mobile node in the route optimization mode of mobile IPv6, which is the OBU itself, or, in the case of DSRC-capable user equipment (such as a smartphone incorporating a DSRC interface), the RSU. Therefore, a replacement is needed to ensure granular accumulation of traffic statistics for each single user equipment (implemented by the billing function described below), rather than the total amount of OBUs to which these user equipment are attached. A mechanism similar to that explained above in conjunction with obtaining the IP source address of the OBU ( Figure 1b and Figure 1c ), the required "home address" information can be retrieved from the Mobile IPv6 MIB by a process 31 running in the RSU 30 using an SNMP GET call or by processing a TRAP generated for each datagram routed by the RSU.

[0047] In some exemplary embodiments, the OBU includes authentication information in the request message 25, which enables both authorization and authentication to be combined in a single step. This process is used where the billing for service channel bandwidth consumption is aggregated for all devices in the vicinity of the OBU 20 and billed to a single account associated with the OBU 20. Figure 2As shown, WSA 36 uses a different PSID to reflect the nature of the service. In this case, AAA server 40 receives message 24 containing the information required to authenticate the client, and therefore does not need to respond with an authentication challenge. The information required for authentication is well known and may include, but is not limited to, the International Mobile Equipment Identity or vehicle identification number of a smartphone, or other such personal identification information. The authentication method is described below. Figure 2 Path segments 28 and 29 in are functionally equivalent to Figure 1a Path segments 27 and 26 in the RSU. Also in some exemplary embodiments, to facilitate the billing process, the payload in message 24 should contain the IP address of the OBU, instead of the actual source IP address. Subsequent IPv6 datagrams originating from the user device will contain this address in the routing header. This enables the RSU to accumulate the number of datagram bytes of the active OBU, as explained in more detail below.

[0048] Back to Figure 1a , RSU 30 is the first IPv6 hop for the authorization request 25, which is transmitted over the service channel. RSU 30 then routes the datagram to its destination. Routing is determined by Figure 1a Path segments 26 and 27 in the figure are shown, and path segments 26 and 27 are the inbound IEEE 802.11p MAC frames received from the service channel and the outbound frames on any medium for the backhaul deployment to the Internet, respectively. In order to charge the service channel bandwidth consumption of a single user device, the RSU 30 caches the source IP address of the datagram in a non-volatile random access memory (NOVRAM) table of such address. In the billing process of the present invention, the source IP of the inbound datagram and the destination IP address of the outbound datagram are matched with the entries in this table and the datagram byte counts are accumulated in the NOVRAM table for the entries corresponding to the correct match. If the RSU is configured to charge the total service channel bandwidth consumption of all devices near the OBU, the entry in the NOVRAM table must be the address of the OBU, which can be resolved from the IPv6 header.

[0049] Upon receiving the authorization request 25, the AAA server 40 is configured to authenticate the client. Figure 1a The AAA server 40 is depicted sending a UDP / IP authentication challenge message 105 (or authentication challenge) to the IP source address associated with the request (ie, the user device 10). Figure 1a103. The challenge response 103 is used to verify the sender's credentials, so it requires a secure cryptographic method to allow the sender to prove its authenticity to the infrastructure management agency. Since the DSRC network security provisions are specified in IEEE 1609.2, and since the cryptographic key material is contained in the digital certificates generated and distributed by the certificate authorities (operated by or in cooperation with the infrastructure management agency), these certificate authorities can also provide the user equipment with the same type of certificates that will be provided to the OBU and RSU (i.e., in accordance with the IEEE 1609.2 specification).

[0050] The user device 10 assembles an authentication challenge response 103, involving cryptographic key material (essentially the public key of the certificate issued to the user device) and an encrypted payload including some unique identification information (such as its International Mobile Equipment Identifier (IMEI)). Successful decryption enables the recipient to authenticate the user device according to the asymmetric encryption technology specified in IEEE 1609.2. Upon receiving the authentication challenge response 103, the AAA server 40 performs a search for the IP source address in a database. This database includes a table whose row entries can contain at least a unique device identifier, an IPv6 address, a security credential issued to the device by a properly authorized certificate authority, and the accumulated WAVE service channel bandwidth consumption during the current reporting period. If a match is found for the IP source address, this means that this address has been encountered previously and has been authenticated. However, if this address is a repeat of another IPv6 address formulated according to SLAAC at a completely different OBU at a previous time, the minimum time it takes for the OBU to leave and then return to the coverage area of ​​the RSU can define the point at which the source IPv6 may be a possible duplicate address, so the AAA server 40 is required to authenticate the client.

[0051] The ability of the AAA server 40 to authenticate the client and authorize it to use the service channel depends on whether it implements the encryption / decryption process specified in the request. The preferred mechanism for authentication is Figure 3 , which depicts the process of issuing security credentials to a client device 10, which is used when the client device needs to be authenticated by the recipient of its message. These security credentials are issued by an entity called an Enrollment Certificate Authority (ECA), which is one of the Certificate Management Entities (CME) defined within the SCMS.

[0052] The ECA70 issues a security certificate to the OBU 20. Figure 371. However, the functional specification for the issuance of security certificates is part of the bootstrap process defined by the SCMS, whereby the ECA assigns each OBU a long-term registration certificate or similar certificate, which is well known and beyond the scope of this disclosure. The registration certificate provides, in one possible form, the credentials required for the OBU to authenticate in subsequent procedures defined within the SCMS. These procedures are designed so that the digital signatures that accompany basic security messages have a dual purpose, namely, to maintain the anonymity of individual vehicles while ensuring that the signatures are authentic (i.e., the cryptographic key material used to create them was properly issued by an authorized certificate management entity).

[0053] A primary goal of the design criteria for the SCMS architecture is to protect the anonymity of the consumer and does not include a requirement to "monetize" WAVE service channels based on the bandwidth consumption of each device. Because the present invention provides a billing procedure, the ability to associate bandwidth consumption with a specific device requires that the security credentials (i.e., certificates issued by the CME) include unique personally identifiable information (PII). In general, the SCMS design ensures that PII is not provided in any certificate used by the OBU to digitally sign messages (such as basic security messages). This ensures that when the security credentials of a transmitting device can be confirmed, its anonymity is protected because it is impossible to identify the device. Therefore, infrastructure management agencies requiring AAA functions cannot rely solely on registration certificates to associate bandwidth consumption with any specific OBU or third-party device.

[0054] However, the use of WAVE bandwidth to provide mobile Internet services is based on the free choice of the consumer. Therefore, there is no privacy violation when the infrastructure management agency requests some form of PII in order to register for the service. An example of PII that can be automatically obtained and passed to the AAA server is the vehicle identification number (VIN), which can be obtained by the OBU through a CAN bus connection with the engine control module (ECM) using the protocol defined in SAE Standard J-1979 or similar protocols. This is the preferred PII in the case of billing for the total traffic passing through the OBU, because aftermarket OBU equipment can be moved from one vehicle to another.

[0055] Figure 3The preferred mechanism for establishing an association between the SCMS-issued certificate encapsulated in the registration certificate and the PII that can be directly linked to the billing account is shown. The process 22 is an application-level software module running in the OBU 20, with two main functional responsibilities. First, it maintains a listener to receive the credential certificate, as shown in the operation 71 of transferring the certificate from the ECA and the confirmation 72 of confirming (or rejecting) the receipt of the certificate. It should be understood that the certificate received in the operation 71 can be a registration certificate, an identification certificate or other authentication credentials for the authentication function alone or together. For simplicity, the following discussion will describe the authentication using the registration certificate, rather than limiting the present invention thereto. It is envisaged in the present disclosure to utilize other credential certificates in the same manner. In this regard, the process 22 is an essential component of the OBU application software. Second, when operating within the scope of the RSU that announces the billable IPv6 connection service, the process 22 is responsible for triggering a request 25 from the OBU 20 to the AAA server 40, which combines both the authorization function and the authentication function in one step. Process 22 encrypts the VIN obtained by interrogating the ECM using the standard protocol defined in SAE J-1979. It is worth noting that in the asymmetric encryption method specified in IEEE 1609.2, the private key is only used for decryption, and the encryption of data must be performed using a symmetric key derived from the public key. Therefore, in order to encrypt data that can only be decrypted by the AAA server, the OBU must obtain the public key issued by the AAA server itself. As mentioned above, this public key is associated with the registration certificate issued to the AAA server and is propagated to the OBU through the WSA broadcast by the RSU operating in the same domain as the AAA server. Process 22 then encapsulates the encrypted VIN as part of the payload of the authorization request 25, which should also include the registration certificate information of the OBU, including the digital signature and the public key required for its confirmation. Then, process 22 sends the authorization request 25 to the receiver (process 41) of the AAA server 40 and has the private key required to decrypt the VIN. In order to simplify the representation, the two software functions described above are implemented in a single process 22. In another embodiment, the two functions can be decoupled, resulting in two independent processes.

[0056] The SCMS specification defines the ECA as being responsible for registering DSRC devices, which by definition comply with all the standards required for these devices to be certified (IEEE 1609.x, IEEE 802.11p, SAE J-2735, and SAE J-2945). However, when IPv6 traffic using the WAVE service channel originates from non-DSRC mobile devices and the policy of the infrastructure management agency is to create billing accounts for individual non-DSRC mobile devices, these devices require the same type of credentials if their traffic is to be authorized by the AAA system. In order to issue such credentials, the AAA server is enabled as a certificate management entity only for non-DSRC mobile devices that are adjacent to the OBU and whose IP traffic can be offloaded onto the WAVE service channel. The resulting certificate is an "Internet subscription certificate" to distinguish it from, for example, the OBU registration certificate. Figure 3 Operations 73 and 74 in exemplify the issuance of such credentials. In some exemplary embodiments, the communication path for distributing these credentials is based on an SSL session between the non-DSRC mobile device and the AAA server.

[0057] In some exemplary embodiments, in order for the AAA server 40 to authorize the OBU 20 to access the IPv6 connectivity services of the RSU 30, three conditions must be met. First, the security credentials of the OBU 20 are verified. This is accomplished by successfully decrypting the PII encapsulated in the request 25 using the public key of the registration certificate sent in the request and received via process 41. The decryption algorithm is implemented as a software module 42 running in the AAA server 40 and is invoked via a synchronous call from process 41, such as Figure 3 Second, a database 43 of subscribers registered in the AAA server 40 is queried by a search 45 to determine whether PII is found. This constitutes authentication of the OBU 20.

[0058] in addition, Fig. 9 The flowchart in Figure 1 summarizes these steps. In step 101, the AAA server 40 receives the authentication and / or authorization request. Next, in step 110, the OBU 20 digital signature is decrypted. Then in step 120, the digital signature is confirmed, and if the signature is not confirmed, a notification is returned to the OBU 20. If the signature is confirmed, in step 130, the PII is queried from the database 43. If the PII is found in step 140, a notification is returned to the OBU 20. Otherwise, in step 150, the request is forwarded to the ECA.

[0059] Typically, user registration is performed through a web user or web service interface provided by the DSRC infrastructure operator. The actual registration method(s) is outside the scope of this disclosure. Regardless of the method used, it is intended to enable the infrastructure operator to create an account associated with unique identification information (PII) (e.g., the vehicle's VIN).

[0060] A fundamental tenet of USDOT policy is that the operation of DSRC infrastructure will be decentralized throughout the United States. It is envisioned that local jurisdictions (whether cities, counties, regional municipalities, or state DOTs) will establish or oversee the establishment of independent DSRC infrastructure operators. Although it is expected that in many or perhaps all cases these operating entities will take the form of public-private partnerships, the corporate structures, the roles and responsibilities of the partners, and the procedures used to develop policies implemented using the DSRC technology itself may vary. With particular reference to this disclosure, there is no technical reason why policy regarding mobile Internet service must be standardized across all jurisdictions. Each jurisdiction may choose to enable mobile Internet service through any RSU deployed and managed within its area and apply any fee schedule it deems appropriate for bandwidth consumption of WAVE service channels.

[0061] The last of the three steps of authentication occurs when there is no local database match for the PII, which requires additional procedures as described below. To ensure cross-regional interoperability of mobile Internet services, each infrastructure management agency maintains an AAA server in which vehicles associated with the region can be registered. In the following case, an example of the need for such a service occurs. The vehicle is registered (with the DMV) as having an address within a region where the policy of the infrastructure management agency is free mobile Internet service. The vehicle is currently traveling in another region that charges for bandwidth consumption and operates a management tool (AAA server) for this purpose. Each RSU in this region will only announce the IP address and UDP port number of the AAA server owned and operated by the local management agency. The OBU in the vehicle requests authorization to access the service. If the request comes from a non-DSRC mobile device, the AAA server attempts to confirm the credentials. Otherwise, the AAA server requests confirmation of the registration certificate used by the OBU from the ECA. However, since the decrypted PII (e.g., VIN) does not appear in the AAA database, the infrastructure management agency can assert its right to deny the vehicle access to the mobile Internet service. The mechanism for enabling or disabling access to mobile Internet services is described below. However, if a "foreign" vehicle is not registered in its AAA server, the infrastructure management agency may be operable to interrogate the entire population of AAA servers, wherever those servers are deployed throughout the jurisdiction managed by the SCMS. If the infrastructure management agency prohibits access by "foreign" vehicles (i.e., vehicles not registered in its AAA servers), it may be operable to forgo revenue that might otherwise be generated from accounts associated with PII registered in "remote" AAA servers.

[0062] In short, if mobile Internet services are to be accessible anywhere a vehicle operates, a mechanism is needed to enable the operator providing the service to authenticate “foreign” vehicles operating in its area and reconcile the charges for bandwidth consumption with the AAA server in the home area.

[0063] Figure 4 The sequence of steps required to find a "foreign" vehicle is shown. As discussed above, the role of the ECA in issuing credentials to mobile devices is defined within the scope of the SCMS specification. However, the ECA includes an additional role for authenticating devices that request mobile Internet services but are not found in the local AAA server database. This new role requires the AAA server to be integrated into the Public Key Infrastructure (PKI) architecture of the SCMS.

[0064] PKI systems are commonly used in Internet transactions for computing devices to present security credentials to any other device that requires proof of authenticity. Security credentials can be derived from a trust "chain" or "hierarchy", whereby the digital certificate containing the credential(s) is itself authenticated based on the digital signature of the certificate issuer. Authentication of a device based on the certificate presented by the device may require several iterations to reach a "root" certificate authority that does not derive its trust from another entity above it in the "trust hierarchy".

[0065] The role of the ECA is to incorporate the necessary functionality to support the various processes or functions of the exemplary embodiments herein. Specifically, the ECA is configured to issue certificates to any AAA server that the infrastructure management agency wishes to deploy. By doing so, the ECA extends the trust hierarchy of the SCMS to the AAA servers that the infrastructure management agency needs to manage the monetization of the WAVE service channel spectrum. In addition, the ECA will maintain a NOVRAM table of the IP addresses of each AAA server to which it has issued certificates. This ensures that when a client's PII is not found in the database of the local AAA server, the ECA can query all appropriately authenticated AAA servers operating under the jurisdiction of the SCMS to determine if the vehicle is registered somewhere, such as Fig. 9 The flowchart is shown in step 150.

[0066] The ECA queries the "remote" AAA server at Figure 4 75 is illustrated by the interaction between ECA 70 and AAA servers 50 and 60. This representation is merely to simplify the diagram and does not mean that the interrogation process is limited to two AAA servers. In the first case, ECA 70 sends a request 75 to a designated listener 56 running in AAA server 50, which in turn issues a query 55 for the VIN to database 53. The binary result (found / not found) is returned to the ECA via response 76. Similarly, a request 77 to listener 66 in AAA server 60 (including listener 66 and database 63 that are functionally equivalent to listener 40 and database 43) will trigger the same type of binary result in query 65 and response 78. Since the AAA server is integrated into the PKI architecture of the SCMS system, there are security provisions to ensure the confidentiality of the VIN information transmitted by the ECA.

[0067] Alternatively, and in order to decouple the credentialing responsibilities of the ECA currently designated in the SCMS from the credentialing requirements of any device associated with the mobile IP billing account, the AAA server is configured to issue "Internet subscription" certificates to DSRCOBUs and to non-DSRC mobile devices, as previously described. In this case, the communication path for distributing the "Internet subscription" certificates to the OBUs is through DSRC, rather than cellular, and in some exemplary embodiments, the certificate information is protected by asymmetric encryption using the registration certificate. The authorization request 25 from the OBU 20 uses its Internet subscription certificate (instead of the registration certificate) to request authentication from the AAA server 40. This Figure 6 The sequence of steps required to obtain an Internet subscription certificate is as follows: When receiving WSA 35 (or 36) for the first time, process 21 ( Figure 1a ) generates a process 80 which runs in the OBU 20. The OBU 20 sends a UDP / IP message 81 to a process 82 running in the AAA server 40 to request an Internet subscription certificate. This request includes the OBU's registration certificate information. • Process 82 sends a request / response exchange 83 to ECA 70 to confirm that the enrollment certificate has not been revoked. • Process 82 sends a request / response exchange 84 to module 85 to generate an asymmetric encryption key pair for the OBU 20 and an Internet subscription certificate containing this information. Process 82 encrypts the information generated by module 85 using the public key of the registration certificate received in message 81 and returns it to process 80 of the OBU 20 as the payload of message 86 . The OBU 20 acknowledges receipt via message 87.

[0068] An additional advantage of an OBU's "internet subscription" certificate is that it eliminates the need for the ECA to interrogate multiple AAA servers in order to search for a "foreign" vehicle. Internet subscription certificates should include the domain name of the AAA server that issued them, which is included in the authorization request from the OBU (or in the authorization challenge response from a non-DSRC mobile device). Therefore, the AAA server receiving the request can resolve the domain name to an IP address. Also, instead of scanning all remote servers until a match is found ( Figure 4 Instead of requiring only a single UDP / IP request / response (requests 75, 77 and responses 76, 78 in the UDP / IP protocol), the request or authorization challenge response from the OBU also includes the public key of the registration certificate of the AAA server that issued the Internet subscription, which can be used to re-encrypt the VIN in the event that the request / response must be forwarded to a remote AAA server, as described below.

[0069] This alternative path for authorization / authentication of "foreign" devices is as follows Figure 7 As shown. The process 41 running in the AAA server 40 uses a DNS address resolution request 47 to the DNS server 90 to obtain the IP address of the remote AAA server 60, and then forwards the request 79 to the AAA server 60. In order to ensure the confidentiality of the PII in the payload of the request 79, the AAA server 40 re-encrypts the PII using a symmetric key derived from the public key of the remote AAA server 60, and uses its own credentials obtained from the ECA to digitally sign the request 79, and sends both its certificate information and the PII in the re-encrypted request 79, so that the remote AAA server 60 can both confirm its signature and decrypt the PII in the request. Since the credentials of the AAA server 40 are obtained from the ECA, this not only protects the private information included in the request 79, but also enables the remote AAA server 60 to authenticate that the sender is linked to the SCMS trust chain and provide a response 88.

[0070] The third condition for authorization is to ensure that the registration certificate itself is confirmed as not expired or revoked for some reason. Some exemplary embodiments of the mechanism for implementing authorization may involve constructing request 46 so that its main purpose is to verify that the registration certificate does not appear in the latest certificate revocation list maintained and propagated by the SCMS. However, if the certificate revocation list is propagated to the AAA server by the SCMS, request 46 is no longer required to require the ECA to verify the received certificate against the certificate revocation list. Secondly, and only when the registration certificate is valid and the method described above of directly querying the AAA server identified in the "Internet Subscription" certificate is not used, request 46 can explicitly ask whether the PII (i.e., VIN) in the request is not found in the local database and needs to be searched in the remote AAA server.

[0071] The AAA server 40 may respond to the sender of the authorization request. If the security credentials are invalid or have been revoked, the billing account is delinquent or does not exist at all; administrative policy may require that the request be denied. However, to ensure that IPv6 traffic is blocked, it is not sufficient for the AAA server 40 to simply send a rejection notification to the client. Since the process of approving IPv6 connection authorization is not within the scope of the IEEE 1609 specification, any device requesting such authorization does so "voluntarily" and has no "obligation" to comply with this decision if it is denied authorization. The WAVE specification does not prohibit it from routing IPv6 traffic to the destination address specified in the datagram header, and there is no provision in WAVE for an RSU to block this traffic. Therefore, a mechanism is needed that enables the AAA server 40 to cause IPv6 traffic originating from a particular OBU to be filtered, and conversely, to cause filters that have been applied to that OBU to be removed once the particular OBU has been authenticated and authorized.

[0072] The preferred approach for such a mechanism is one that can be implemented in an RSU certified to comply with USDOT recommendations, which means that a protocol stack on top of WAVE (such as Figure 5 As shown) has been fully implemented. The filtering mechanism uses an API provided by the RSU vendor that exposes the transport layer of the protocol stack as an application layer software operation. In the case of a Denial of Service (DOS) attack, the requirement arises for routers to drop traffic based on the point of origin of the traffic. One of the methods used by ISPs to defend against these attacks is called Remotely Triggered Black Hole (RTBH) filtering. RTBH filtering can be applied to both source and destination addresses, but in specific DOS situations, filtering is applied to the source address. This method is described in information RFC 5635 (incorporated herein by reference), which specifies the use of an internal Border Gateway Protocol to deliver RTBH filtering instructions to routers. The Border Gateway Protocol as specified in RFC 4271 (incorporated herein by reference) operates as a peer session over a TCP connection on the well-known port (179), allowing routing information to be propagated between pairs of routers.

[0073] Infrastructure operators typically have multiple RSUs and a very limited number (if not a single) of AAA servers, all operating within the same autonomous system. Figure 8 , where the AAA server 40 executes multiple instances of the BGP finite state machine defined in RFC 4271, each instance having a TCP connection to a single RSU 30. Fig.10 As shown, RTBH filtering instructions are sent as UPDATE messages, which are defined in RFC 4271 and specify addresses to be blocked (filtered) or unblocked by the receiving RSU 30. Figure 5The use of BGP by a software application is demonstrated, in contrast to the more traditional scenario of a network administrator invoking the BGP service through a command line interface. In other words, the use of BGP in the context of this disclosure is a fully automated process performed by Fig.10 The flowchart definition in can be described according to the following algorithm steps: The authorization request 25 from the OBU 20 is received by the AAA server 40 . • Authentication and authorization are performed in step 200 according to the mechanisms already described in this disclosure. In step 210, the request is validated. If the request is declared invalid (because authentication failed or authorization was not granted), a "rejection notification" may be returned in the form of a UDP message 92 to the OBU. If the request is authorized, an "Approval Notification" 94 may be returned to the OBU. In both cases above, the response 96 to the OBU is shown as a dashed line, indicating that it is optional. The request for authorization is not part of the WAVE standard, and therefore, as previously mentioned, the OBU is neither obliged to send this request nor to listen for a response or take any action on the response. Therefore, there is no need to implement the response message in the AAA server. In both cases, the result of the authentication / authorization process becomes the input 98 to the invocation of the BGP service, which sends an UPDATE message to the RSU, through which the OBU request is routed to the AAA server. Depending on the result, this message will instruct the peer BGP entity running in the RSU to block or unblock traffic originating from the requesting OBU. The TCP connection is selected based on the IPv6 address of the RSU, which is obtained by resolving the global prefix and subnet ID from the IPv6 address of the OBU (see RFC 4291 IP Version 6 Addressing Architecture, which is incorporated herein by reference). An alternative method for instructing the RSU to block mobile-terminated traffic for a specified mobile destination address is to send an SNMP SET command to instruct the RSU to set the MIB object ipv6RouteValid corresponding to the ipv6RouteTable entry for the specified mobile destination address to TRUE or FALSE. This method is not applicable to blocking (or unblocking) routing of mobile-initiated traffic.

[0074] Billing

[0075] Because one goal of the present invention is the monetization of radio spectrum, in some exemplary embodiments, the RSU is configured to track the service channel bandwidth consumption of each device when using the IPv6 interface and periodically send reports to the AAA server. To achieve this, the Management Information Base (MIB) of the IPv6 layer is extended to obtain packet and byte count statistics for each client, and the data is retrieved using a standard SNMP interface and periodically transmitted to the AAA server over a TCP connection in some exemplary embodiments. Fig.11 A preferred embodiment is shown. A process 31 running in the RSU calls TRAP handler registration 33 to register a TRAP handler 32 with SNMP so that each client byte count statistics are reported asynchronously. Whenever a packet is sent to or received from a WAVE IPv6 interface, the extended MIB provides statistics (Ipv6ByteRxorTxPacketByteCount) on a per-client basis, which generates a TRAP message 34. The TRAP handler 32 processes the TRAP and notifies the process 31 using a callback process 37. The process 31 accumulates statistics for each client in a NOVRAM table and periodically sends a UDP / IP report (message 38) to the AAA server, which is persistent (i.e., requires confirmation). Before sending the confirmation, the process 41 running in the AAA server 40 calls a database process 43 to store the information received in the report.

[0076] Multicast push notifications

[0077] With respect to some exemplary embodiments, some IV (Infrastructure to Vehicle) WAVE applications use multicast technology in a "one-to-many" configuration that delivers "push notifications" to mobile devices. There are two basic categories of such applications: (1) Geo-temporal commercials; for example, promoting discounted products or services at specific retail locations on specific dates / times. (2) Roadside Alerts (RA). These are advisory messages from road network operators that correspond to the type of information currently provided as a telephone service in many state and provincial jurisdictions in North America. These messages include, but are not limited to, accident notifications, lane closures, travel time advisories, and other road network operation events. These messages may also include quasi-static navigation information, such as speed limits, distance to destination, parking restrictions, school or construction zone warnings, etc. RAs are constructed according to the standardized format defined in the SAE J-2735 message set (incorporated herein by reference).

[0078] Due to the "one-to-many" communication topology of multicast WAVE services, the task of generating revenue from mobile subscriptions to these services requires a slightly different approach than the example described herein.

[0079] Business Model

[0080] In some exemplary embodiments, there are two models for generating revenue from push notifications: "advertising" and "subscription". For the "advertising" model, the originator of the push notification compensates the network operator in some way in consideration for the delivery of the message. In this context, "advertising" is not limited to purely commercial applications, but can also be applied to public service announcements, such as accident notifications, lane closures, travel time advisories, and other road network operation events reported according to the standardized format of Roadside Alerts (RA) defined in the SAE J-2735 message set.

[0081] In the "subscription" model of some exemplary embodiments, messages should only be received by devices associated with a paid subscription account. In both models, efficient utilization of network resources (i.e., bandwidth) is achieved by using a multicast or "one-to-many" messaging approach. Client devices that join a multicast group can receive messages sent to the multicast address associated with the group, which means that it is technically feasible to implement software that enables any device to receive multicast messages, regardless of whether it has an active subscription.

[0082] Differences in client devices in the "subscription" model

[0083] In the case of an "advertising" model, in some exemplary embodiments, since the revenue is derived from the source of the messages, there is no need from a business perspective to restrict access to the messages to different classes of client devices. However, if a "subscription" model is to be effective, where the revenue source is associated with a single client device, access must be restricted to only those client devices that have an active subscription.

[0084] In some exemplary embodiments, such limited access may be provided by encrypting the payload of the multicast message. Such exemplary embodiments are not necessarily limited to any particular encryption method used therefor, and only involve the task of ensuring that all recipients authorized to receive these messages possess the key material required for decryption. The focus here is on establishing a method to ensure that the key(s) required for decryption can be distributed to authorized devices in a secure manner.

[0085] In some exemplary embodiments, Fig.12 A reliable and secure mechanism supporting a "subscription model" for multicast messaging is presented, whereby client devices can request authentication / authorization from an AAA server to access services based on unicast Internet messaging. Fig.12It is shown that a roadside unit (RSU) 30 can use WSA 37 to advertise a multicast service with a PSID (Provider Service Identifier) ​​associated with a "subscription model". Figure 1a and Figure 2 As described in , the OBU (on-board unit) 20 may send a request 25 to the AAA server 40 that identifies the IPv6 address of the client (user) device connected thereto. The AAA server 40 then issues an authentication challenge 105 to the client device 10, which responds with an authentication challenge response 106 that encapsulates the digital credentials required to access the multicast service, including an ECDSA signature and parameters for verification of the signature provided by the SCMS identity certificate (ID Cert) of the multicast service (these parameters consist of a public key and elliptic curve domain parameters). As already specified, the AAA server 40 verifies the signature and the account status to determine whether authorization should be granted to the client device 10. When authorization is granted, the AAA server 40 employs ECIES (Elliptic Curve Integrated Cryptography Scheme) 107 using the parameters published in the ID Cert to derive a symmetric key and then encrypts the payload of the ECIES message 108. The plaintext version of the payload in the ECIES message 108 encapsulates the key material required for any and all client devices authorized to decrypt the multicast message 110. Client device 10 decrypts the payload of ECIES message 108 by performing ECIES step 109. Different embodiments of AAA server 40 may use different algorithms to symmetrically encrypt / decrypt the payload of multicast message 110.

[0086] The services advertised by the RSU 30 are preferably managed by the AAA server 40, since the AAA server is responsible for confirming the subscription account associated with the client device. In addition, only the AAA server 40 can map the geographic time parameters specified by the commercial or government agency (the "multicaster") from which the multicast message originates into the correct selection of the RSU target address. This process is as follows Fig.13 As shown. For each instance in which the message content for a particular target geographic area is changed, the multicaster 300 sends the new message content and geographic time parameters to the AAA server 40 using message 301. The AAA server 40 then performs process 302 to assemble a set of new multicast messages targeted at the appropriate RSUs and schedule their transmission. When the client device submits an authentication / authorization request when encountering a new RSU, the AAA server 40 may also change the key material used for the encryption of the multicast message payload delivered using the ECIES mechanism already described. The result of these steps of selecting an RSU, scheduling transmission, and encrypting the payload is a multicast message 303.

[0087] While the AAA server described in some exemplary embodiments enables an authority to charge for wireless access to a vehicle environment service channel bandwidth consumption, the capabilities provided by the AAA server in some exemplary embodiments may be used for other processes, applications, services, etc., for which the OBU and / or one or more user devices associated therewith may have a valid account, or may be a subscriber thereof, which requires a SCMS certificate to support its authentication. For example, in the case of a traffic signal preemption, an authority may confirm to a traffic management center responsible for controlling a traffic signal co-located with the RSU that an authenticated OBU in an approaching vehicle is authorized to perform priority signaling at a designated intersection. Other exemplary embodiments may include vehicles being permitted to operate in lanes dedicated only to vehicles of a particular vehicle type.

[0088] Thus, in some exemplary embodiments, the OBU may be configured to request authentication and authorization from the AAA server on behalf of a proximate non-DSRC mobile device or for itself to access any services subscribed thereby.

[0089] The various components shown in outline or as blocks in the drawings are well known in the injection molding art and their specific construction and operation are not critical to the operation or best mode for carrying out the invention.

[0090] Although the present invention has been described with respect to what are currently considered to be preferred embodiments, it should be understood that the present invention is not limited to the disclosed embodiments. On the contrary, the present invention is intended to cover various modifications and equivalent arrangements included within the scope of the appended claims. The scope of the appended claims should be consistent with the broadest interpretation so as to include all such modifications and equivalent structures and functions.

[0091] Terms:

[0092] The following clauses describe exemplary embodiments described herein, including RSUs, OBUs, AAA servers, and / or clients or remote devices: 1. An AAA server operated by or on behalf of a dedicated short-range communication infrastructure management agency for transmitting messages between an on-board unit (OBU) and a roadside unit (RSU), the AAA server comprising at least one processor running at least one computer program adapted to communicate with a plurality of user devices and / or an OBU operating a subnet of one or more user devices, and a plurality of RSUs via the Internet to perform authentication, authorization and accounting (AAA) functions, thereby enabling the management agency to charge for wireless access vehicle environment service channel bandwidth consumption of each of the user devices that has been appropriately provided by the AAA server. 2. An AAA server operated by or on behalf of a dedicated short-range communications infrastructure management agency for transmitting messages between an on-board unit (OBU) and a roadside unit (RSU), the AAA server comprising at least one processor running at least one computer program adapted to communicate with a plurality of user devices and / or an OBU operating a subnet of one or more user devices, and with a plurality of RSUs via the Internet to perform authentication, authorization and accounting (AAA) functions, thereby enabling the management agency to authenticate the user device and / or the OBU, and authorize the user device and / or the OBU to access any service subscribed thereby. 3. An AAA server as defined in any of the preceding or following clauses, configured as a certificate management entity and operable to issue an Internet subscription digital certificate for an IPv6 addressable user device and transmit the certificate to the user device via a secure communication channel, wherein the certificate includes the domain name of the AAA server. 4. An AAA server as defined in any of the preceding or following clauses, the server being linked to a PKI trust chain between components of a security credential and management system (SCMS), the server being operable to process a request for the digital certificate from a DSRC OBU, the request encapsulating the personal identification information (PII) of the OBU and being protected by an asymmetric encryption algorithm specified in IEEE 1609.2 using a registration certificate issued by the SCMS to the OBU, and the server being operable to use the encryption key of the registration certificate to establish the secure communication channel for sending the certificate to the OBU. 5. An AAA server as defined in any of the preceding or following clauses, the server being operable to process requests for said digital certificate from non-DSRC mobile devices, said requests encapsulating the PII of said mobile devices, each mobile device initiating a handshake protocol to establish a secure, symmetrically encrypted communication channel with said AAA server. 6. An AAA server as defined in any of the preceding or following clauses, the server being operable to receive a combined authorization and authentication request from an OBU, the request comprising credentials in the form of a digital signature generated using a key from the Internet subscription certificates issued by the AAA server to the OBU; operable to receive the combined authorization and authentication request forwarded from one or more remote AAA servers on behalf of the OBU that has received the Internet subscription certificates from the remote AAA servers; operable to process requests from both the OBU and the remote AAA servers by cryptographic validation of the credentials presented respectively by the OBU and the remote AAA servers, for each request, querying a non-remote AAA database for a match with the PII contained in the request, and returning a message to the requesting OBU or remote AAA approving the authorization or denying the authorization with a code indicating the reason for the denial. 7. An AAA server as defined in any of the preceding or following clauses, the server being operable to receive an authorization request from said OBU on behalf of a non-DSRC mobile device, to send a UDP / IP authentication challenge message directly or indirectly to the IPv6 address of said non-DSRC mobile device; to process responses to said authentication challenge, said responses containing credentials in the form of a digital signature generated using a key from said Internet subscription credentials issued by said AAA server to said non-DSRC mobile device; and to receive said authorization request forwarded from a remote AAA server on behalf of a non-DSRC mobile device that has received Internet subscription credentials from said AAA server; and to process said requests from both the non-DSRC mobile device and the remote AAA server by cryptographic validation of the presented credentials, to query a local AAA database for a match with the PII contained in the request, and to return a message to the requestor approving authorization or denying authorization with a code explaining the reason for the denial. 8. An AAA server as defined in any of the preceding or following clauses, which, in the case where a remote AAA server is identified by the domain name of a certificate management entity that has issued credentials used by a user device to request authentication and authorization, is operable to forward the request to the remote AAA server, using credentials obtained from the SCMS trust chain to protect communications with the remote server. 9. An AAA server as defined in any of the preceding or following clauses, wherein, in a case where a remote AAA server is identified by the domain name of a certificate management entity that has issued credentials used by a user device to respond to an authentication challenge from the AAA server, the server is operable to forward the request to the remote AAA server, using credentials obtained from the SCMS trust chain to protect communications with the remote AAA server. 10. An AAA server as defined in any of the preceding or following clauses, the server being operable to send an UPDATE message to an RSU within the same autonomous system using remotely triggered black hole (RTBH) filtering via an intra-bBorder Gateway Protocol, wherein the UPDATE message is triggered by an authentication and authorization request for an Internet subscription service received from a user device and encapsulates a result of the authentication and authorization request, wherein the result is an authentication failure for the mobile device, or an approval or denial of authorization for the user device. 11. An AAA server as defined in any of the preceding or following clauses, wherein, upon receiving an authorization request with an SCMS credential issued for a multicast service identified by a PSID encapsulated in the request, ECIES is used to encrypt parameters and key material required for symmetric encryption of the payload of a multicast "push notification" provided by the multicast service and transmit it to the requesting device. 12. A roadside unit (RSU) configured with an extended IPv6 management information base (MIB), which is operable to determine packet and byte count statistics of wireless access vehicle (WAVE) service channel usage for each client device, wherein the client device is an on-board unit (OBU), a non-DSRC mobile device reachable via IPv6 through the OBU, or a DSRC-enabled user device; the IPv6 MIB is also operable to retrieve the fixed "home address" of the mobile node carried in the mobile IPv6 routing header of each datagram received from an IPv6 node operating in a mobile IPv6 routing optimization mode; the RSU is operable to accumulate the packet and byte count statistics of the WAVE service channel usage for each client device in a non-volatile random access memory (NOVRAM) and periodically encapsulate the statistics in a UDP / IP message and send it to an AAA server, refreshing the NOVRAM table only when the AAA server has acknowledged receipt of the UDP / IP message. 13. An RSU as defined in any of the preceding or following clauses, which RSU complies with the USDOT specifications found at http: / / docplayer.net / 11087167-Dsrc-roadside-unit-rsu-specifications-document.html or its functional equivalent. 14. An RSU as defined in any of the preceding or following clauses, the RSU being operable to process RTBH filtering instructions from an AAA server within the same autonomous system. 15. An RSU compliant with the USDOT specification found at http: / / docplayer.net / 11087167-Dsrc-roadside-unit-rsu-specifications-document.html or a functional equivalent thereof, the RSU being operable to broadcast service announcements (WSAs) encapsulating the public key of a Security Credentials and Management System (SCMS) enrollment certificate issued to an AAA server operating in the same domain as the RSU. 16. An OBU compliant with WAVE and IEEE 802.11p and configurable to have dual radio capabilities, running at least one application-level computer program adapted to request authentication and authorization from an AAA server on behalf of a neighboring non-DSRC mobile device or for itself to achieve IPv6 connectivity to the Internet, and configured with an extended IPv6 MIB operable to retrieve addresses of neighboring devices when new entries are inserted into a routing table, to periodically retrieve the routing table using a synchronous method based on SNMP GET, or to report "real-time" changes in the routing table using an asynchronous method based on SNMP TRAP. 17. An OBU compliant with WAVE and IEEE 802.11p and configurable to have dual radio capabilities, running at least one application-level computer program adapted to request authentication and authorization from an AAA server on behalf of a neighboring non-DSRC mobile device or for itself to access any services subscribed thereby, and configured with an extended IPv6 MIB operable to retrieve addresses of neighboring devices as new entries are inserted into a routing table, to retrieve the routing table periodically using a synchronous method based on SNMP GET, or to report "real-time" changes in the routing table using an asynchronous method based on SNMP TRAP. 18. An OBU as defined in any of the preceding or following clauses, the OBU being operable to request "Internet subscription" credentials from an AAA server, wherein its SCMS registration certificate is used in encryption of requests to the AAA server and decryption of responses from the AAA server, and the OBU being operable to use the credentials when requesting authentication and authorization from the AAA server to achieve the IPv6 connection to the Internet. 19. An OBU as defined in any of the preceding or following clauses, wherein, following transmission of an authorization request with an SCMS credential issued for a multicast service identified by a PSID encapsulated in the request, ECIES decryption is used to decrypt ECIES encryption parameters and key material required for symmetric decryption of the payload of a multicast "push notification" provided by said multicast service. 20. A mobile device as defined in any of the preceding or following clauses configured to communicate with an OBU to achieve IPv6 connectivity to the Internet, wherein, after transmitting an authorization request with an SCMS credential issued for a multicast service identified by a PSID encapsulated in the request, ECIES decryption is used to decrypt ECIES encryption parameters and key material required for symmetric decryption of the payload of a multicast "push notification" provided by said multicast service. 21. A system for facilitating communication between an on-board unit (OBU) and a roadside unit (RSU), which communicates with multiple user devices and / or OBUs operating a subnet of one or more user devices via the Internet using dedicated short-range communications (DSRC), the system comprising a server that transmits messages between the OBU and the RSU, the server comprising at least one processor that runs at least one computer program adapted to authenticate the user device, authorize the user device to access a Wireless Access Vehicular Environment (WAVE) service channel, and bill for bandwidth consumption of each of the user devices that have been properly authenticated and authorized by the AAA server. 22. A system as defined in any of the preceding clauses, comprising a plurality of servers operated by or on behalf of a dedicated short range communications (DSRC) infrastructure authority. 23. A system as defined in any one of the preceding clauses.

[0093] This disclosure, clauses, claims and drawings should be construed as supporting any claim reciting any element, feature, structure, function and / or step of any aspect and / or exemplary embodiment described in the disclosure (including the drawings, clauses and / or claims herein), either alone or in combination with any one or more elements, features, structures, functions and / or steps from the same or any other aspect or exemplary embodiment described in the disclosure (including the drawings, clauses and / or claims herein).

[0094] The following references are incorporated herein by reference:

[0095] WAVE: IEEE WIRELESS ACCESS IN VEHICULAR ENVIRONMENTS (WAVE) - IEEE 1609 SERIES, available at http: / / www.techstreet.com / standards / ieee-wireless-access-in-vehicular-environments-wave-ieee-1609-series?sid=goog&gclid=Clbc_ZfFxs0CFQ6naQodjolKlg&product_id=1893147.

[0096] IEEE 802.11p: IEEE Standard 802.11p-2010 - IEEE Standard for Information Technology – Local and metropolitan area networks – Specific requirements – Part 11: Wireless LAN Media Access Control (MAC) and Physical Layer (PHY) Specifications Revision 6: Wireless Access in Vehicular Environments, available at https: / / standards.ieee.org / findstds / standard / 802.11p-2010.html

[0097] U.S. Patent Application 14 / 151,035, available at http: / / www.google.com / patents / US20140195102

[0098] SCMS Vehicle-to-Vehicle Security Credential Management System; Request for Information, National Highway Traffic Safety Administration notice dated October 15, 2014, available at http: / / federalregister.gov / a / 2014-24482

[0099] Request for Comments (RFC) 4861 (IPv6 Neighbor Discovery), September 2007, available at https: / / tools.ietf.org / html / rfc4861

[0100] RFC 4862 (Stateless Address Autoconfiguration), September 2007, available at https: / / tools.ietf.org / html / rfc4862

[0101] RFC 6275 (Mobility Support in IPv6), July 2011, available at https: / / tools.ietf.org / html / rfc6275

[0102] RFC 5635 (Remotely Triggered Blackhole Filtering), August 2009, available at https: / / tools.ietf.org / html / rfc5635

[0103] RFC 4271 (Border Gateway Protocol 4), January 2006, available at https: / / tools.ietf.org / html / rfc4271

[0104] RFC 4291 (IPv6 Addressing Architecture), February 2006, available at https: / / tools.ietf.org / html / rfc4291

[0105] V2V Readiness Report DOT HS 812014, August 2014. Vehicle-to-Vehicle Communications: Readiness of V2V Technology for Application, available at http: / / docplayer.net / 13180-Dot-hs-812-014-august-2014-vehicle-to-vehicle-communications-readiness-of-v2v-technology-for-application.html

[0106] All of the U.S. patents and patent applications discussed above and all of the articles, documents, treatises, specifications, etc. cited above are incorporated herein by reference.

Claims

1. A roadside unit configured with an extended IPv6 management information base, the extended IPv6 management information base is operable to determine packet and byte count statistics used by each client device, the client device being a vehicle-mounted unit, a non-dedicated short-range communication mobile device reachable via an onboard unit over IPv6, or a user device supporting dedicated short-range communication; the IPv6 management information base is also operable to retrieve, for each datagram received from an IPv6 node operating in a mobile IPv6 route optimization mode, a fixed "home address" of a mobile node carried in the mobile IPv6 routing header of the datagram; the roadside unit is operable to accumulate the packet and byte count statistics used by each client device in a non-volatile random access memory and periodically encapsulate the statistics in a UDP / IP message and send it to an authentication, authorization and billing server, refreshing the table in the non-volatile random access memory only when the authentication, authorization and billing server has acknowledged receipt of the UDP / IP message.

2. The roadside unit of claim 1, the roadside unit conforming to the USDOT specification found at http: / / docplayer.net / 11087167-Dsrc-roadside-unit-rsu-specifications-document.html or a functional equivalent thereof.

3. A roadside unit as claimed in claim 1 or claim 2, the roadside unit being operable to process remotely triggered black hole filtering instructions from authentication, authorization and billing servers within the same autonomous system.

4. A roadside unit that complies with the USDOT specification found at http: / / docplayer.net / 11087167-Dsrc-roadside-unit-rsu-specifications-document.html or its functional equivalent, the roadside unit being operable to broadcast service announcements that encapsulate security credentials and the public key of a management system registration certificate, identity certificate, or other authentication credential issued to an authentication, authorization, and billing server operating in the same domain as the roadside unit.

5. An on-board unit that complies with a wireless access vehicle environment and is configurable to have dual radio capabilities, runs at least one application-level computer program adapted to request authentication and authorization from an authentication, authorization and billing server either on behalf of a neighboring non-dedicated short-range communication mobile device or for itself to achieve IPv6 connectivity to the Internet, and is configured with an extended IPv6 management information base that is operable to retrieve addresses of neighboring devices when new entries are inserted into a routing table, to periodically retrieve the routing table using a synchronous method based on SNMP GET, or to report "real-time" changes in the routing table using an asynchronous method based on SNMP TRAP.

6. An on-board unit, compliant with a wireless access vehicle environment and configurable with dual radio capabilities, running at least one application-level computer program adapted to request authentication and authorization from an authentication, authorization and billing server to access any service subscribed thereto.

7. An on-board unit as described in claim 6, which is operable to request authentication and authorization from an authentication, authorization and billing server on behalf of a neighboring non-dedicated short-range communication mobile device and is configured with an extended IPv6 management information base, which is operable to retrieve the addresses of neighboring devices when new entries are inserted into the routing table, to periodically retrieve the routing table using a synchronous method based on SNMP GET, or to report "real-time" changes in the routing table using an asynchronous method based on SNMP TRAP.

8. An on-board unit as described in claim 5 or claim 6, which is operable to request "Internet subscription" credentials from an authentication, authorization and billing server, wherein the request to the authentication, authorization and billing server is digitally signed using its security credentials and a management system registration certificate, identification certificate or other authentication credentials, the request includes the public key of the registration certificate, identification certificate or other authentication credentials, which enables the authentication, authorization and billing server to encrypt the response, and the on-board unit is operable to use the credentials when requesting authentication and authorization from the authentication, authorization and billing server to achieve the IPv6 connection to the Internet.

9. The vehicle-mounted unit according to any one of claims 5 to 7, wherein: After transmitting an authorization request with security credentials and management system credentials issued for a multicast service identified by a provider service identifier encapsulated in the request, elliptic curve integrated cryptographic scheme decryption is used to decrypt the elliptic curve integrated cryptographic scheme encryption parameters and key material required for symmetric decryption of the payload of a multicast "push notification" provided by the multicast service.

10. A mobile device configured to communicate with the vehicle-mounted unit according to any one of claims 5 to 9 to achieve IPv6 connection to the Internet, wherein: After transmitting an authorization request with security credentials and management system credentials issued for a multicast service identified by a provider service identifier encapsulated in the request, elliptic curve integrated cryptographic scheme decryption is used to decrypt the elliptic curve integrated cryptographic scheme encryption parameters and key material required for symmetric decryption of the payload of a multicast "push notification" provided by the multicast service.

11. A system for facilitating communication between an onboard unit and a roadside unit, the roadside units communicating via the Internet with a plurality of user devices and / or an onboard unit operating a subnet of one or more user devices using dedicated short-range communications, the system comprising: A server for transmitting messages between the onboard unit and the roadside unit, the server comprising at least one processor running at least one computer program adapted to authenticate the user equipment, authorize the user equipment to access the wireless access vehicle environment channel, and bill for bandwidth consumption of each of the user equipment that has been properly authenticated and authorized by the authentication, authorization and billing server.

12. The system of claim 11, comprising a plurality of servers operated by or on behalf of a dedicated short range communications infrastructure management organization.

13. A system comprising a roadside unit, an on-board unit and / or a mobile device as claimed in any one of claims 1 to 10.

Images