System for authenticating and authorizing access to and accounting for wireless access vehicular environment consumption by client devices

Abstract

To provide a system and method configured to perform Authentication, Authorization and Accounting (AAA) functions.SOLUTION: A system and method are disclosed for authenticating and authorizing access to and accounting for consumption of bandwidth for IPv6 connectivity to the Internet over Wireless Access Vehicular Environment (WAVE) service channels by client devices using an Authentication, Authorization and Accounting (AAA) server. The AAA server authenticates and authorizes client devices to access WAVE service channels, and accounts for bandwidth consumption by the client devices using WAVE service channels to access the Internet. The AAA server enables an RSU infrastructure operator to quantify wireless bandwidth consumption by in-vehicle devices using the WAVE Service Channels, on a per-device basis.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] Related Applications Each of the following applications, including the original articles submitted at the time of filing, is incorporated herein by reference in its entirety: i) U.S. Provisional Patent Application No. 62 / 357,504, filed July 1, 2016; ii) PCT Patent Application No. PCT / IB2017 / 053981, filed June 30, 2017; iii) U.S. Patent Application No. 15 / 639,022, filed June 30, 2017. [Background technology]

[0002] In January 2016, the U.S. Secretary of Transportation announced that the U.S. Department of Transportation (USDOT) would proceed with Federal Motor Vehicle Safety Standard (FMVSS) 150, based on a vehicle-to-vehicle (V2V) communications technology called Dedicated Short-Range Communications (DSRC). DSRC operates over a 75 MHz frequency band centered at 5.9 GHz, previously allocated by the FCC to support a wide range of Intelligent Transportation Systems (ITS) applications. Between 2002 and 2009, the IEEE developed the 1609 suite of protocol specifications that govern the use of the band, divided into seven channels, each 10 MHz wide. Four of the channels support the Internet Protocol version 6 (IPv6) interface, meaning that either UDP / IPv6 or TCP / IPv6-based application software can operate over these channels.

[0003] The protocol specifications included in the IEEE 1609 suite, commonly known as Wireless Access Vehicular Environment (WAVE) and incorporated herein by reference, incorporate security provisions that ensure authentication of WAVE-enabled on-board equipment (OBE) attempting to communicate with roadside equipment (RSE). The terms OBE and RSE are generally synonymous with OBU (on-board unit) and RSU (roadside unit). OBUs typically include, but are not limited to, mobile computing devices capable of DSRC communications that meet the V2V requirements specified in SAE J2945 / 1 and SAE J2945 / 2 or the V2P requirements specified in future variations of SAE J2945. An RSU is typically, but not exclusively, a stationary or quasi-stationary computing device capable of DSRC communications, conforming to the IEEE 802.11p specification for the DSRC MAC and PHY layers, the WAVE protocol stack, and capable of broadcasting WAVE Service Advertisements (WSA) on the DSRC Control Channel (CCH). This includes devices that are not OBUs. OBU devices without valid security credentials can be effectively denied the RSU's WSA, which is typically achieved by simply discarding the transmission sent by the OBU. The WSA is a periodic message defined by the IEEE 1609 protocol suite that identifies the services available in the network.

[0004] These aforementioned security provisions present in the IEEE 1609 protocol are aimed at controlling access to services that reside on the RSU or are accessible to the RSU through dedicated application software on the RSU; i.e., services that the RSU is "aware of" and for which the RSU has policy responsibility for access control. Examples of such services include, but are not limited to, traveler information, in-vehicle signage, navigation, traffic management, weather information, safety, electronic payment, network services, and configuration management.

[0005] In the case of IPv6 communication, the role of the RSU is to route IPv6 datagrams towards the destination address. The WAVE architecture provides authentication of OBUs based on a digital signature in the header of WAVE Short Message Protocol (WSMP) messages originating from the OBU. The digital signature is generated by the OBU according to 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 authority ("Infrastructure Authority") may 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 transmitted using WSMP.

[0006] U.S. Patent Application No. 14 / 151,035, incorporated herein by reference, discloses a system 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 the user device to attach itself to an OBU using stateless address autoconfiguration (SLAAC), for example, over a WiFi peer-to-peer (WiFi Direct) interface. The OBU acts as an IPv6 router that connects the user device 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 to authenticate the user device. Summary of the Invention [Means for solving the problem]

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

[0008] Another aspect provides an AAA server operating by or on behalf of a DSRC infrastructure institution, the AAA server having at least one processor executing at least one computer program configured to communicate over the Internet with an OBU, a plurality of RSUs, that serve a plurality of mobile devices and / or a subnetwork of one or more mobile devices, to perform authentication, authorization, and accounting (AAA) thereby enabling the institution to account for WAVE service channel bandwidth consumption by each mobile device appropriately provisioned by the AAA server.

[0009] Another aspect provides a plurality of AAA servers operating by or on behalf of a DSRC infrastructure authority, each having at least one processor executing at least one computer program configured to communicate with a plurality of mobile devices and a plurality of RSUs over the Internet to perform authentication, authorization, and accounting, the plurality of AAA servers being arranged for load balancing of inbound Internet traffic, and enabling the authority to account for WAVE service channel bandwidth consumption by each appropriately provisioned mobile device and / or OBU serving one or more subnets of mobile devices in a single database, with access to the database being synchronized among the plurality of AAA servers.

[0010] Another aspect provides an RSU configured with an extended IPv6 management information base (MIB) and operable to identify packet and byte count statistics of WAVE service channel usage per client device. The client device may be an OBU, a non-DSRC mobile device IPv6 reachable through the OBU, or a DSRC-enabled user device. The IPv6 MIB is also operable to look up, for each datagram received from an IPv6 node operating in Mobile IPv6 route optimization mode, the mobile node's fixed "home address" carried in the datagram's Mobile IPv6 routing header. The RSU is operable to accumulate packet and byte count statistics of WAVE service channel usage per client device in non-volatile random access memory (NOVRAM), periodically send the statistics encapsulated in UDP / IP messages to the AAA server, and refresh the NOVRAM table only when the AAA server acknowledges receipt of the UDP / IP message.

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

[0012] Another aspect provides a non-DSRC mobile device operable to request "Internet subscription" credentials from an AAA server using a symmetrically encrypted communication channel established using SSL or a similar handshake protocol of manual authentication and key exchange, and operable to use the "Internet subscription" credentials when responding to an authentication challenge message received from the AAA server as defined by one or more example embodiments or aspects herein.

[0013] Other objects, features and advantages of the present invention will be readily appreciated as the same becomes better understood after reading the following description taken in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 2 is a system block diagram illustrating the authorization and authentication process between a user device and an AAA server in accordance with the present invention. [Figure 1b] FIG. 1 is a system block diagram illustrating one method for retrieving an IP source address from a routing table using the Simple Network Management Protocol. [Figure 1c] FIG. 1 is a system block diagram illustrating another method for retrieving an IP source address from a routing table using the Simple Network Management Protocol. [Figure 2] FIG. 10 is a system block diagram illustrating another embodiment of an authorization and authentication process between an in-vehicle unit and an AAA server. [Figure 3] FIG. 1 is a system block diagram illustrating an embodiment of an authentication process in accordance with the present invention. [Figure 4] FIG. 2 is a system block diagram illustrating an authentication process for an external device according to the present invention. [Figure 5] FIG. 1 is a block diagram illustrating a protocol stack on a wireless access vehicle environment utilizing a border gateway protocol. [Figure 6]FIG. 10 is a system block diagram illustrating a process for distributing security credentials according to another embodiment of the present invention. [Figure 7] FIG. 10 is a system block diagram illustrating yet another authentication and authorization process for an external device in accordance with the present invention. [Figure 8] FIG. 1 is a system block diagram illustrating communication between an AAA server and multiple roadside units. [Figure 9] 3 is a flow chart illustrating an authorization process in accordance with the present invention. [Figure 10] 1 is a system block diagram and flow chart illustrating blocking and unblocking of a client device, such as an in-vehicle unit, at an AAA server. [Figure 11] 1 is a system block diagram and flow chart illustrating an accounting process in accordance with the present invention. [Figure 12] 1 is a schematic diagram of a handshake protocol that enables key distribution for multicast message encryption. [Figure 13] FIG. 1 is a schematic diagram of a multicast message registration process. DETAILED DESCRIPTION OF THE INVENTION

[0015] Detailed Disclosure It is to be understood that the present invention is not limited in application to the details of construction or the arrangement of components set forth in the following description of exemplary embodiments or illustrated in the drawings. The present invention is capable of other embodiments and of being practiced and carried out in various ways. It is also to be understood that the phrases and terminology used herein are for descriptive purposes and should not be regarded as limiting. The use of "including," "comprising," or "having" and variations thereof herein means the inclusion of the items listed thereafter and equivalents thereof, as well as additional items. Additionally, the terms "connected," "coupled," and "decoupled," and variations thereof, used herein, are not limited to physical, mechanical, or electrical connections or couplings. Furthermore, as described in subsequent paragraphs, the specific mechanical and / or other configurations illustrated in the drawings are intended to be illustrative of embodiments of the present invention. However, other alternative configurations are possible and are considered to be within the teachings of the present disclosure.

[0016] In connection with some exemplary embodiments, due to WAVE security requirements, all nodes (both mobile and stationary) are required to have credentials using the cryptographic methods specified in IEEE 1609.2. The credentials are issued when the device is provisioned and are used to create digital signatures that allow the device to authenticate itself, such as when a mobile device broadcasts a Basic Secure 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 communications. Whether the service channel is available should depend on whether there is a Provider Service Identification (PSID) for this purpose that has been properly registered according to the procedures defined in IEEE 1609.12. It is generally assumed that the DSRC infrastructure is deployed and managed using various forms of public-private partnerships that all share the attributes of an "infrastructure authority" that addresses the problem of spectrum monetization within the framework of a business model. If an OBU complies with the functional requirements established in NHTSA safety standards, the decision of whether an OBU or a third-party user device connected to the OBU can be granted IPv6 connectivity over a WAVE service channel and whether bandwidth usage is charged may be at the discretion of the infrastructure authority. Accordingly, some exemplary embodiments may enable the infrastructure authority to allow or deny IPv6 connectivity to individual devices and measure the service channel bandwidth consumption associated with each device. This is accomplished by implementations of the present invention described herein.

[0017] The first step is "authentication", which is based on a "logon" procedure 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 difference between these two scenarios is a function of the business model available from the infrastructure operator and the choice made by the owner of the OBU, which can be an OEM manufactured device or an aftermarket retrofit. For example, if the owner of the OBU absorbs all costs related to IPv6 bandwidth consumption, regardless of which third-party user device is the communication endpoint, then the OBU owner can choose to use the OBU to authenticate the user. The logon originates from the OBU device. If the cost is attributed to a nearby third-party user device, bandwidth accounting is applicable to the user device, and therefore the user device should be the initiator of the logon.

[0018] A logon is essentially an IPv6 connectivity request through a nearby RSU. The user device or an OBU acting on behalf of the user device described above is the requesting device and may be referred to as the "client" or "client device." The logon message is digitally signed using a cryptographic key derived from a digital certificate issued by or on behalf of the infrastructure operator. The digital certificate is encapsulated in the logon message, allowing the recipient to decrypt the signature and verify the credentials presented in the certificate. The logon message is encapsulated in a UDP / IP packet addressed to a "Roadway Authorization Server" (RAS), a separate host maintained by the infrastructure operator. As disclosed in Application No. 14 / 151,035, when a particular RSU is prepared to provide IPv6 connectivity service to passing OBUs, it broadcasts the IP address and application port of the RAS service in a WAVE Service Advertisement (WSA). Credential verification follows the authentication step, and since some exemplary embodiments herein define the complementary functions of authorization and accounting, the RAS in some exemplary embodiments is referred to as an AAA server, as described in more detail below.

[0019] The authentication step is supported by an external system capable of verifying the credentials identified in the logon message. Such a system is defined as part of Federal Motor Vehicle Safety Standard (FMVSS) 150 and is called a Security Credential and Management System (SCMS). SCMS is based on a public key infrastructure (PKI) architecture, where asymmetric cryptographic keys are generated by a "root" certificate authority and encapsulated in digital certificates that constitute the client device's credentials. The technical architecture of SCMS evolved from a collaborative effort by USDOT and the automotive industry, as represented by the Collision Avoidance Metrics Partnership (CAMP). A detailed description of SCMS can be found at http: / / federalregister.gov / a / 2014-24482, which is a reference to The primary purpose of the SCMS is to ensure that devices participating in vehicle-to-vehicle (V2V) communications as defined by FMVSS 150 are properly authenticated and that their actions do not compromise consumer privacy. Through a secure link between the AAA server and the SCMS, the AAA server is able to request assistance from the SCMS components in verifying the security credentials of a particular device. The verification process is based on a digital signature, certificate information, and an encrypted unique identifier for the device, all of which are encapsulated in the logon received from the device. It should be understood that the digital signature, certificate information, and encrypted unique identifier can be transmitted separately and securely.

[0020] The next step is "authorization," which has two aspects. The first aspect is verification that the client device's credentials have not been revoked by the credential authority. This is done using a certificate revocation list maintained by the SCMS. The current specification of the SCMS requires that the certificate revocation list be distributed only to the OBUs and RSUs. However, to enable the AAA server to perform the above verification, the certificate revocation list should also be distributed to the AAA server. The second aspect is that the account associated with the client is in good standing, which is determined according to the infrastructure operator's policy.

[0021] The authorization step may be required only if the authentication step passes. The Boolean result of "fail" of the first step or the conjunction of both steps indicates that the AAA server This information is input to a mechanism that allows the AAA server to manage the IPv6 routing table of the RSU currently providing connectivity to the AAA server. The implementation of this functionality is based on the use of existing methods specified in IETF RFCs. In particular, adding Border Gateway Protocol (BGP) functionality to both the AAA server and the RSU allows the AAA server to perform Remote Triggered Black Hole (RTBH) filtering within the RSU, thereby blocking or unblocking IPv6 traffic from clients based on whether the client has passed authentication and authorization steps. This methodology provides an efficient, standards-based means of controlling access to the mobile Internet services that infrastructure operators wish to offer, linking the properly authorized credentials of client devices requesting the service to the IPv6 routing table of the RSU without requiring modifications to the WAVE suite of specifications.

[0022] The final step is accounting. When using an IPv6 interface, the RSU is configured to track service channel bandwidth consumption by each device and periodically send reports to the AAA server. To accomplish this, the Management Information Base (MIB) at the IPv6 layer can be extended to capture packet and byte count statistics per client. Consumption data is retrieved using a standard SNMP interface and periodically sent to the AAA server, for example, over a TCP connection.

[0023] In accordance with some exemplary embodiments, a DSRC RSU routes IPv6 datagrams received from or sent to an OBU via a WAVE service channel. If the owner of the RSU, which may be an "infrastructure authority," adopts policies to control and manage service channel bandwidth usage by individual OBUs and devices connected to the OBUs, a mechanism is needed to authenticate these devices, authorize their use of the service channel, and account for the amount of bandwidth consumed by each device. The present invention provides a server, commonly referred to as AAA (Authentication, Authorization, and Accounting), that supports these mechanisms.

[0024] A single-radio OBU device that complies with the required duty cycle to monitor both the safety or "V2V" channel (here designated CH172 at the "bottom" of the DSRC band) and the control channel (CCH or CH178) may not be suitable for providing IPv6 connectivity services because, at a minimum, its receiver would need to further divide its time between the safety channel, CCH, and the designated service channel. The incremental cost of a dual-radio device is low enough to warrant vendors configuring their OBU products, either aftermarket safety devices (ASDs) or retrofit safety devices (RSDs) as defined in the "V2V Readiness Report," incorporated herein by reference, as dual-radio devices. Therefore, throughout this disclosure, it is assumed that OBUs that provide access to service channel bandwidth are configured as dual-radio devices. However, it should be understood that the present invention can also be implemented using single-radio devices.

[0025] In the WAVE standard, IPv6 datagrams can be transmitted on the service channel without any restrictions, so an RSU that receives a datagram automatically routes the datagram toward its destination. However, if the RSU's management policy requires that IPv6 traffic be authorized by AAA, authorization for wireless IPv6 communication should be requested on behalf of the OBU or one or more devices connected to the OBU.

[0026] 1 illustrates the authorization and authentication process between a user device and an AAA server according to the present invention. The notification from the RSU indicating the authorization requirement is implemented in a WAVE Service Advertisement (WSA) 35. The WSA is a notification sent by the RSU on the WAVE CCH. Broadcast constitutes the method required by the WAVE standard for an RSU to inform an OBU what services are accessible through the RSU broadcasting the WSA.

[0027] The RSU 30 is configured by the infrastructure operator to issue a WSA containing the IP address and port of the AAA service to which the OBU can send authorization requests. As disclosed in U.S. Patent Application No. 14 / 151,035, the WSA has traditionally been used only to identify the address to which the OBU should send authorization requests. The present invention, as described further below, also utilizes the WSA to contain channel availability information that the OBU should use for channel configuration. The WSA 35 encapsulates both the IP address and port of the AAA server. The WSA 35 also encapsulates a provider service identification (PSID) that indicates that this RSU supports the availability of generic IPv6 connectivity under AAA management and an identifier for the available service channel. A different PSID is established to allow the OBU to distinguish between services that apply billing rates to the OBU for any nearby user devices and services in which each user device has its own billing account associated with it. The use of this distinction is further described below. Otherwise, as previously indicated, if AAA is not required, the WSA 35 is not required because access to the service channel can be automatic or unrestricted. As used herein, automatic means real-time or near-real-time automated processing by one or more processors without manual or human intervention. However, it should be understood that manual involvement may be required without departing from this invention. The payload of the WSA 35 must also include cryptographic keying material associated with the digital certificate issued to the AAA server and required by the OBU to encrypt data included in the authorization request sent to the AAA server, as described further below.

[0028] The contents of the WSA 35 are reported through a WSMP interface to process 21, which is typically a user application running in the OBU 20. Process 21 is implemented and performed by a processor resident in the OBU 20. It should be understood that the processor may be any readily available device capable of executing the processes described herein. The process steps or instructions are executed via the processor of the OBU 20 or the user device 10 to perform the functions / operations specified in the flowcharts and / or diagrams shown throughout the figures and discussed herein. Next, process 21 registers a "sender profile" with a MAC layer management entity (MLME) that specifies the service channel number specified in the WSA. This registration of the transmitter profile ensures that the MLME is always updated whenever a policy change changes the services advertised in the WSA. If IPv6 connectivity services are deactivated at a particular time or location (i.e., a particular RSU or cluster of RSUs), the PSIDs corresponding to these services will not exist in the WSA, and process 21 registers a new transmitter profile that does not include the corresponding service channel number. As described in IEEE 1609.4, if the channel router function of the IEEE 802.11p MAC layer (not shown in Figure 1) cannot find this service channel number, packets intended for transmission using this channel will be discarded.

[0029] The authorization function involves a request sent by OBU 20 to AAA server 40, shown in FIG. 1 by authorization request or message 25. An example of such a message 25 is disclosed in U.S. patent application Ser. No. 14 / 151,035, and takes the form of a UDP / IPv6 message. This message 25 is initiated by process 21, which listens to WSA 35. If the request has not already been authorized by AAA server 40, process 21 queues message 25 for transmission over the IPv6 interface. WSA 35 determines whether the advertised service will be charged to the individual account of the third-party user device, and therefore whether the authorization request is sent to the third-party device, e.g., a nearby smartphone or tablet. The message 25 indicates that the OBU is acting as a "representative" of the third party device, and the interface between the OBU and the third party device is, in some exemplary embodiments, a wireless link such as WiFi Direct (also called WiFi Peer-to-Peer), in which case the UDP payload of message 25 includes the IP source address of the user device.

[0030] The mechanism by which user device 10 attaches itself to OBU 20 requires that OBU 20 be configured to support the IPv6 "Neighbor Discovery" specification in RFC 4861, which is incorporated herein by reference. In this specification, network nodes advertise their routing capabilities to neighbors through periodic broadcasts of "Router Advertisements" (RAs) over interfaces over which neighbors may wish to join the network. A Router Advertisement is shown in FIG. 1 as RA 100. U.S. Patent Application Serial No. 14 / 151,035 discloses an attachment process for the Stateless Address Autoconfiguration (SLAAC) mechanism specified in RFC 4862, which is also incorporated herein by reference.

[0031] Prior systems, such as that disclosed in U.S. Patent Application No. 14 / 151,035, did not disclose how the IP source address included in the authorization request exemplified by message 25 is obtained. When a user device attaches itself to an OBU, the OBU, in some exemplary embodiments, may discover the IP source address due to receipt of a Router Solicitation message from the user device, which will result in the user device's address being added to the OBU routing table as defined in RFC 4861. Obtaining this information requires the implementation of SNMP in the OBU. There are two possible alternative methods, shown in Figures 1b and 1c, which illustrate well-known protocol layers, respectively. The simplest method (Figure 1b) is to configure process 21 to periodically issue an SNMP GET to the local host to retrieve the ipv6RouteTable object in the IPv6 MIB. 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 this is detected, a TRAP message is generated, which can be received by a handler function 25 registered with the SNMP layer by the process 21.

[0032] The use of WAVE as a platform for mobile Internet services that rely on TCP at the transport layer is often hindered by the fact that the OBU address changes as the device moves from one RSU to another. As a result, a user device that attaches itself to an OBU always discovers a change in its IPv6 address with each transition between RSUs, which disrupts TCP sessions and degrades the quality of any connection-oriented streaming services above the transport layer. The present invention overcomes these problems by enabling user devices for Mobile IPv6, as specified in RFC 6275 and incorporated herein by reference, configured for "Route Optimization" (Section 11.3.1) mode. According to one aspect of the present invention, the OBU 20 becomes the primary "care-of address" of nearby user devices. In "Route Optimization" mode, the "Home Address" is carried in the IPv6 Destination Options header. This address is fixed and used as a proxy for the IP source and destination addresses, because in Mobile IPv6 route optimization mode, the IP source and destination addresses are the "care-of address" addresses of the mobile node, which is either the OBU itself or, in the case of a DSRC-enabled user device such as a smartphone incorporating a DSRC interface, the RSU. Therefore, a proxy is needed to ensure granular accumulation of traffic statistics per individual user device, which is performed by the accounting function described below, rather than an aggregation of attached OBUs. This is the same mechanism described earlier in relation to the OBU obtaining the IP source address as shown in Figures 1b and 1c. Similarly, the required "home address" information can be obtained by a process 31 running in the RSU 30 by retrieving it from the Mobile IPv6 MIB using an SNMP GET call or by processing a TRAP generated for each datagram routed by the RSU.

[0033] In some exemplary embodiments, the OBU includes authentication information in request message 25, allowing both authorization and authentication to be combined into one step. This procedure is used when accounting for service channel bandwidth consumption is aggregated across all devices in the vicinity of OBU 20 and charged to a single account associated with OBU 20. As shown in FIG. 2, WSA 36 uses a separate PSID that reflects the nature of the service. In this case, AAA server 40 receives message 24 containing the information necessary to authenticate the client and therefore does not need to respond to an authentication challenge. The information necessary for authentication is well known and may include, but is not limited to, the smartphone's International Mobile Equipment Identity, a vehicle identification number, or other such personal identification information. The authentication method is described below. Path segments 28 and 29 in FIG. 2 are functionally equivalent to path segments 27 and 26 in FIG. 1. Also, in some exemplary embodiments, to facilitate the accounting process, the payload in message 24 should include the OBU's IP address instead of the actual source IP address. Subsequent IPv6 datagrams originating from the user device will include this address in their routing headers. This allows the RSU to accumulate datagram byte counts for active OBUs, as described in more detail below.

[0034] Referring again to FIG. 1, the RSU 30 is the first IPv6 hop of the authorization request 25 sent over the service channel. The RSU 30 then routes the datagram toward its destination. The routing is illustrated by path segments 26 and 27 in FIG. 1, which are the inbound IEEE 802.11p MAC frame received from the service channel and the outbound frame on whatever medium is deployed for backhaul to the Internet, respectively. For accounting of service channel bandwidth consumption by individual user devices, the RSU 30 caches the source IP addresses of datagrams in a non-volatile random access memory (NOVRAM) table of such addresses. In the accounting process of the present invention, the source IP of inbound datagrams and the destination IP address of outbound datagrams are matched against entries in this table, and the datagram byte count is stored in the NOVRAM table for the entry corresponding to the exact match. If the RSU is configured to account for the aggregated service channel bandwidth consumption of all devices in the vicinity of an OBU, the entry in the NOVRAM table must be the address of the OBU that can be parsed from the IPv6 header.

[0035] Upon receiving the authorization request 25, the AAA server 40 is configured to authenticate the client. FIG. 1 shows that the AAA server 40 sends a UDP / IP authentication challenge message 105 (or authentication challenge) to the IP source address associated with the request, which is the user device 10. The response mechanism is shown in FIG. 1 as authentication challenge response 103. The challenge response 103 functions to verify the sender's credentials and therefore requires a secure cryptographic methodology that allows the sender to prove its authenticity to the infrastructure authority. DSRC cybersecurity provisions are specified in IEEE 1609.2, and cryptographic keying material is contained in digital certificates generated and distributed by certificate authorities operated by or working with the infrastructure authority, resulting in these certificate authorities also being able to provide user devices with the same types of certificates (i.e., compliant with the IEEE 1609.2 specification) that are provided to OBUs and RSUs.

[0036] The user device 10 constructs an authentication challenge response 103, which includes an encrypted payload containing cryptographic keying material (essentially the public key of a certificate issued to the user device) and some unique identifying information, such as an International Mobile Equipment Identifier (IMEI). Successful decryption allows the recipient to authenticate the user device according to the asymmetric encryption techniques specified in IEEE 1609.2. Upon receiving the authentication challenge response 103, the AAA server 40 performs a search through a database for the IP source address. This database includes a table, and a row entry in the table may include, at a minimum, a unique device identifier, an IPv6 address, security credentials issued to the device by a properly authorized certificate authority, and accumulated WAVE service channel bandwidth consumption within the current reporting period. If an IP source address match is found, this means that this address has been encountered before and is already authenticated. However, if this address is a duplicate of another IPv6 address previously formed according to SLAAC in an entirely different OBU, the shortest time it takes for the OBU to leave the coverage area of ​​the RSU and then return to the coverage area of ​​the RSU may define the point at which the source IPv6 may be a duplicate address and therefore the AAA server 40 needs to authenticate the client.

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

[0038] The issuance of security credentials by the ECA 70 to the OBU 20 is indicated by operation 71 in FIG. 3. However, the functional specifics of the issuance of security credentials are part of a bootstrapping process defined by the SCMS, whereby the ECA assigns long-term enrollment certificates, etc., to each OBU, which is well known and beyond the scope of this disclosure. In one possible form, the enrollment certificate provides the credentials the OBU needs for authentication during subsequent procedures defined within the SCMS. These procedures have been designed to serve the dual purpose of preserving the anonymity of individual vehicles while ensuring that digital signatures accompanying basic secure messages are authentic in the sense that the cryptographic keying material used to create the digital signatures was properly issued by an authorized authentication management entity.

[0039] The design criteria for the SCMS architecture have as its primary objective the protection of consumer anonymity and do not include the requirement to "monetize" WAVE service channels based on bandwidth consumption per device. Because the present invention provides accounting procedures, the ability to associate bandwidth consumption with a specific device requires that security credentials, i.e., certificates issued by the CME, contain unique personally identifiable information (PII). In general, the SCMS design ensures that PII is not available in any certificates used by OBUs to digitally sign messages, such as basic secure messages. This ensures that the sending device's security credentials are verifiable, but the device's anonymity is protected because it is not identifiable. Therefore, infrastructure authorities requiring AAA functionality cannot rely solely on enrollment credentials to associate bandwidth consumption with any particular OBU or third-party device.

[0040] However, the use of WAVE bandwidth to provide mobile internet services is based on consumer discretionary choice. Therefore, it is not clear whether the infrastructure authority requires any kind of payment for subscription to the service. There is no privacy violation when requesting PII in this form. One example of PII that can be automatically obtained and sent to the AAA server is the vehicle identification number (VIN), which can be obtained by the OBU using a CAN bus connection to the engine control module (ECM) using a protocol defined in SAE Standard J-1979 or a similar protocol. This is the preferred PII because aftermarket OBU devices can be moved from one vehicle to another for charges to be applied to aggregate traffic through the OBU.

[0041] A preferred mechanism for establishing an association between the SCMS-issued credentials encapsulated in the enrollment certificate and PII that can be directly linked to a billing account is shown in Figure 3. Process 22 is an application-level software module running in OBU 20 with two main functional responsibilities. First, it maintains a listener for receiving credential certificates, as indicated by operation 71, which sends the certificate from the ECA, and an acknowledgment 72, which confirms (or rejects) receipt of the certificate. It should be understood that the certificate received in operation 71 may be, separately or together, an enrollment certificate, an identity certificate, or other authentication credentials used for authentication functions. For simplicity, the following discussion describes authentication using an enrollment certificate without limiting the present invention. Similar utilization of other credential certificates is also contemplated within this disclosure. To this end, process 22 is a required component of the OBU application software. Second, when operating within an RSU advertising a chargeable IPv6 connectivity service, process 22 is responsible for triggering a request 25 from OBU 20 to AAA server 40, which combines both authorization and authentication functions into one step. Process 22 encrypts the VIN obtained by querying the ECM using the standard protocol defined in SAE J-1979. It is worth noting that in the asymmetric encryption methodology specified in IEEE 1609.2, a private key is used only for decryption, while data encryption must be performed using a symmetric key derived from a public key. Therefore, to encrypt data that can only be decrypted by the AAA server, the OBU must obtain a public key published by the AAA server itself. This public key is associated with an enrollment certificate issued to the AAA server, and this public key is propagated to the OBU through a WSA broadcast by an RSU operating in the same domain as the AAA server, as described above. Process 22 then encapsulates the encrypted VIN, consisting of the digital signature and the public key required for its verification, as part of the payload of an authorization request 25, which must also include the OBU's enrollment certificate information.Process 22 then sends an authorization request 25 (process 41) to a recipient on AAA server 40, which possesses the private key necessary to decrypt the VIN. For simplicity of presentation, the two software functions described above are implemented within one process 22. In another embodiment, these two functions can be separated to create two separate processes.

[0042] The SCMS specification, by definition, defines the ECA as responsible for enrolling DSRC devices that comply with all standards required for certification of these devices (IEEE 1609.x, IEEE 802.11p, SAE J-2735, and SAE J-2945). However, if IPv6 traffic using WAVE service channels originates from non-DSRC mobile devices and it is the infrastructure authority's policy to create billing accounts for individual non-DSRC mobile devices, these devices will require similar credentials if their traffic is to be authorized by the AAA system. To issue such credentials, the AAA server is proximate to the OBU and can act as a certificate management entity only for non-DSRC mobile devices that can offload IP traffic to the WAVE service channel. The certificate generated is an "Internet Subscription Certificate" to distinguish it from an OBU enrollment certificate, etc. Actions 73 and 74 in Figure 3 illustrate the issuance of such credentials. Some In an exemplary embodiment, the communication path for distributing these credentials is based on an SSL session between the non-DSRC mobile device and the AAA server.

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

[0044] Additionally, the flowchart in Figure 9 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. Next, in step 120, the digital signature is verified, and if the signature does not verify, a notification is returned to the OBU 20. If the signature does verify, in step 130, the database 43 is queried for PII. If 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.

[0045] Typically, user registration is performed through a web user or web service interface provided by the DSRC infrastructure operator. The actual registration method is outside the scope of this disclosure. Whatever method is used, the infrastructure operator should be able to create an account that is associated with unique identifying information (PII), such as the vehicle's VIN.

[0046] It is a fundamental tenet of USDOT policy that DSRC infrastructure operation be distributed throughout the United States. It is anticipated that local jurisdictions, whether cities, counties, local government agencies, or state DOTs, will establish or oversee the establishment of independent DSRC infrastructure operators. While it is anticipated that in many, or perhaps all, cases, these operating entities will take the form of public-private partnerships, the partners' corporate structures, roles, and responsibilities, as well as the procedures for establishing policies implemented using the DSRC technology itself, may vary. With particular reference to this disclosure, there is no technical reason why policies regarding mobile Internet service need to be standardized across all jurisdictions. Each jurisdiction has the option to enable mobile Internet service through any RSUs deployed within its territory and under its control, and to apply whatever fee schedule for WAVE service channel bandwidth consumption it deems appropriate.

[0047] The last of the three authentication steps occurs when there is no local database match with the PII, in which case additional steps are required, as described below. To ensure interoperability of mobile Internet services across regions, each infrastructure authority should maintain an AAA server where vehicles associated with its territory can be registered. An example of this need arises in the following scenario: A vehicle is registered (with the DMV) as having an address in a region where the infrastructure authority's policy is for free mobile Internet service. The vehicle is currently traveling in another region that charges fees for bandwidth consumption and operates a management tool (AAA server) for this purpose. Each RSU in this region advertises the IP address and UDP port number of the only AAA server owned and operated by the regional authority. The OBU in the vehicle requests authorization to access the service. If the request is from a non-DSRC mobile device, the AAA server attempts to validate the credentials. Otherwise The AAA server requests validation from the ECA for the enrollment certificate used by the OBU. However, because the decrypted PII (e.g., VIN) does not appear in the AAA database, the infrastructure authority can assert the right to deny the vehicle access to the mobile internet service. Mechanisms for enabling or prohibiting access to the mobile internet service are described below. However, if the "external" vehicle is not registered with the AAA server, the infrastructure authority is operable to query the AAA server of the entire population, wherever they are deployed throughout the jurisdiction governed by the SCMS. If the infrastructure authority prohibits access to an "external" vehicle (i.e., a vehicle not registered with the AAA server), it is operable to forfeit any revenue that could have been generated from an account associated with the PII registered with the "remote" AAA server.

[0048] In short, if mobile internet services are to be accessible wherever a vehicle is operating, a mechanism is needed that allows the operator providing the service to authenticate "foreign" vehicles operating within its territory and arbitrate charges for bandwidth consumption with an AAA server in the home territory.

[0049] Figure 4 shows the sequence of steps required to locate "external" vehicles. As mentioned above, the role of the ECA with regard to issuing credentials to mobile devices is defined within the SCMS specification. However, the ECA embraces the additional role of authenticating devices that request mobile Internet services but cannot be found in the local AAA server database. This new role requires that the AAA server be integrated into the SCMS public key infrastructure (PKI) architecture.

[0050] PKI systems are commonly used in Internet transactions for computing devices to present security credentials to any other device requiring proof of authenticity. Security credentials can be derived from a trust "chain" or "hierarchy" whereby the digital certificate containing the credential itself should be authenticated according to the digital signature of the certificate's issuer. Authentication of the device based on the presented certificate requires several iterations before reaching a "root" certificate authority that does not derive its trustworthiness from another entity above it in the "trust hierarchy."

[0051] The role of the ECA is to incorporate the necessary functionality to support the various procedures or functions of the exemplary embodiments herein. In particular, the ECA is configured to issue certificates to any AAA servers that the infrastructure authority wishes to deploy. In doing so, it extends the SCMS trust hierarchy to the AAA servers that the infrastructure authority needs to manage the monetization of WAVE service channel spectrum. Furthermore, it maintains a NOVRAM table of the IP addresses of each AAA server to which it has issued a certificate. This ensures that if the client's PII cannot be found in the local AAA server's database, the ECA can query all appropriately certified AAA servers operating under the jurisdiction of the SCMS to determine whether the vehicle in question is registered anywhere, as shown in step 150 of the flowchart in FIG. 9.

[0052] Interrogation of a "remote" AAA server by an ECA is illustrated in Figure 4 by the interaction between ECA 70 and AAA servers 50 and 60. This representation is intended merely for purposes of simplifying the illustration and is not intended to imply that the interrogation process is limited to only two AAA servers. In the first case, ECA 70 sends a request 75 to a designated listener 56 running on AAA server 50, which then issues a query 55 for VIN to database 53. A binary result (found / not found) is returned to the ECA in response 76. Similarly, listener 66 in AAA server 60, which encompasses listener 66 and database 63, functionally equivalent to listener 40 and database 43, A request 77 to 6 triggers 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, security provisions exist to ensure the confidentiality of the VIN information sent by the ECA.

[0053] Alternatively, to separate the ECA's credential responsibility from any device credential requirements associated with a Mobile IP billing account as currently specified in SCMS, the AAA server is configured to issue "Internet subscription" certificates to DSRC OBUs and non-DSRC mobile devices, as described above. In this case, the communication path for distributing the "Internet subscription" certificate to the OBU is via DSRC instead of cellular, and the certificate information is secured with asymmetric encryption using the enrollment certificate, in some exemplary embodiments. An authorization request 25 from the OBU 20 requests authentication from the AAA server 40 using the Internet subscription certificate (instead of the enrollment certificate). This is shown in FIG. 6. The sequence of steps required to obtain an Internet subscription certificate is as follows: When WSA 35 (or 36) is first received, process 80 occurs by process 21 (FIG. 1) running on OBU 20. The OBU 20 requests an Internet subscription certificate by sending a UPD / IP message 81 to a process 82 running on the AAA server 40. This request includes the OBU's enrollment certificate information. · Process 82 sends a request / response exchange 83 to ECA 70 to verify that the enrollment certificate has not been revoked. · Process 82 sends a request / response exchange 84 to module 85 to generate an asymmetric cryptographic 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 enrollment certificate received in message 81 and returns this as the payload of message 86 to process 80 of OBU 20. · OBU 20 acknowledges receipt with message 87.

[0054] An additional benefit of the OBU's "Internet Subscription" certificate is that it eliminates the need for the ECA to query multiple AAA servers to search for "foreign" vehicles. The Internet Subscription Certificate should include the domain name of the AAA server that issued the Internet Subscription Certificate, which is included in the authorization request from the OBU (or authorization challenge response from a non-DSRC mobile device). Thus, the AAA server receiving the request can resolve the domain name to an IP address. Then, instead of scanning all remote servers until a match is found (requests 75, 77 and responses 76, 78 in Figure 4), only one UDP / IP request / response is required. The request or authorization challenge response from the OBU also includes the public key of the enrollment certificate of the AAA server that issued the Internet Subscription, which can be used to re-encrypt the VIN if the request / response needs to be forwarded to a remote AAA server, as described below.

[0055] This alternative path for authorization / authentication of "external" devices is shown in Figure 7. Process 41 running on AAA server 40 obtains the IP address of the remote AAA server 60 using a DNS address resolution request 47 to DNS server 90, and then forwards request 79 to AAA server 60. To ensure confidentiality of the PII in the payload of request 79, AAA server 40 re-encrypts the PII using a symmetric key derived from the public key of the remote AAA server 60, digitally signs request 79 using its own credentials obtained from the ECA, and includes both its certificate information and the re-encrypted PII in request 79. 79, allowing the remote AAA server 60 to verify the signature and decrypt the PII in the request. Because the AAA server 40's credentials are obtained from the ECA, this protects the private information contained in the request 79 and allows the remote AAA server 60 to authenticate the sender as linked to the SCMS chain of trust and provide a response 88.

[0056] A third condition of authorization is ensuring that the enrollment certificate itself is verified as not having expired or been revoked for some reason. Some exemplary embodiments of mechanisms for achieving authorization may include structuring request 46 so that its primary purpose is to verify that the enrollment certificate is up-to-date with the certificate revocation list maintained and disseminated by SCMS. However, if the certificate revocation list is propagated to the AAA server by SCMS, request 46, which asks the ECA to verify the received certificate against the certificate revocation list, is no longer necessary. Second, if the enrollment certificate is valid and only if the above-described method of directly querying the AAA server identified in the "Internet Subscription" certificate is not used, request 46 may specify that the PII (i.e., VIN) in the request was not found in the local database and should be searched for at a remote AAA server.

[0057] The AAA server 40 may respond to the sender of the authorization request. If the security credentials are invalid or have been revoked, or if the billing account is overdue or simply does not exist, governing policies may require the request to be rejected. However, it is not sufficient for the AAA server 40 to simply send a rejection notice to the client to ensure that IPv6 traffic is blocked. Because the process of granting authorization for an IPv6 connection is outside the scope of the IEEE 1609 specification, any device requesting such authorization will do so "voluntarily" and is not "obliged" to comply with this decision if authorization is denied. The WAVE specification does not prohibit routing IPv6 traffic toward a destination address specified in the datagram header, and there is no provision in WAVE for an RSU to block this traffic. As a result, a mechanism is needed to allow the AAA server 40 to filter IPv6 traffic originating from a specific OBU and, conversely, to remove filters applied to a specific OBU once it has been authenticated and authorized.

[0058] The preferred methodology for such a mechanism is one that can be implemented in an RSU certified as compliant with the USDOT recommendation, which implies a full implementation of the protocol stack above WAVE shown in FIG. 5. The filtering mechanism operates as application layer software using APIs provided by the RSU vendor that expose the transport layer of the protocol stack. The requirement for routers to discard traffic based on its origin arises in the case of denial-of-service (DOS) attacks. One method used by ISPs to protect against these attacks is called remotely triggered black hole (RTBH) filtering. RTBH filtering can be applied to both source and destination addresses, although in the specific case of DOS, filtering is applied to the source address. This methodology is described in RFC 5635, which specifies the use of an internal border gateway protocol to send RTBH filtering instructions to routers. The border gateway protocol, specified in RFC 4271, which is incorporated herein by reference, operates as a peer-to-peer session over a TCP connection on a well-known port (179), allowing routing information to propagate between pairs of routers.

[0059] Infrastructure operators typically have multiple RSUs and one or a very limited number of AAA servers all operating within the same autonomous system. This topology is shown in Figure 8, where In this example, the AAA server 40 runs multiple instances of the BGP finite state machine defined in RFC 4271, each with a TCP connection to an individual RSU 30. As shown in FIG. 10, RTBH filtering instructions are defined in RFC 4271 and are sent as update messages that specify addresses to be blocked (filtered) or unblocked by the receiving RSU 30. FIG. 5 illustrates the use of BGP by a software application in which the BGP service is invoked by a network administrator through a command line interface, in contrast to more traditional scenarios. In other words, the use of BGP in the context of the present disclosure is a fully automated process defined by the flowchart in FIG. 10, which can be described with respect to the following algorithmic steps: The authorization request 25 from the OBU 20 is received by the AAA server 40 . Authentication and authorization is performed in step 200 according to the mechanisms already described in this disclosure. The request is validated in step 210. If the request is invalid (either authentication fails or authorization is not granted), a "rejection notice" can be returned to the OBU in the form of a UDP message 92. · If the request is approved, a "Notice of Approval" 94 may be returned to the OBU. In both of the above cases, the response 96 to the OBU is shown as a dotted line to indicate that it is optional. The authorization request is not part of the WAVE standard, and therefore, as indicated above, the OBU is not obligated to send this request, nor to listen for or take any action regarding the response. Therefore, the implementation of the response message in the AAA server is not a requirement. In both cases, the result of the authentication / authorization process is the input 98 to the invocation of the BGP service, which sends an update message to the RSU that routed the OBU request to the AAA server. Depending on the result, this message instructs the peer BGP entity running in the RSU to block or unblock traffic originating from the requesting OBU. A TCP connection is chosen according to the IPv6 address of the RSU, which is obtained by parsing the global prefix and subnet ID from the IPv6 address of the OBU (see RFC4291 IP Version 6 Addressing Architecture, incorporated herein by reference). An alternative methodology for directing RSU blocking mobile-terminated traffic to a specified mobile destination address is to send an SNMP SET command instructing the RSU to set the MIB object ipv6RouteValid corresponding to the ipv6RouteTable entry for the specified mobile destination address to either true or false. This approach is not applicable to blocking (or unblocking) the routing of mobile-originated traffic.

[0060] accounting Since one goal of the present invention is to monetize the wireless spectrum, in some exemplary embodiments, the RSU is configured to track service channel bandwidth consumption by each device when using an IPv6 interface and periodically send reports to an AAA server. To accomplish this, the Management Information Base (MIB) at the IPv6 layer is extended to obtain per-client packet and byte count statistics, and the data is retrieved using a standard SNMP interface and, in some exemplary embodiments, periodically sent to the AAA server over a TCP connection. A preferred implementation is shown in Figure 11. A process 31 running in the RSU calls TRAP Handler Registration 33 to register a TRAP handler 32 with SNMP, which asynchronously reports byte count statistics per client. Whenever a packet is sent to or received from the WAVE IPv6 interface, the extended MIB provides statistics (Ipv6ByteRxorTxPacketByteCount) on a per-client basis, which results in the generation of a TRAP message 34. The TRAP handler 32 retrieves the TRAP. The AAA server 40 processes the statistics and notifies process 31 using callback procedure 37. Process 31 accumulates per-client statistics in a NOVRAM table and periodically sends a UDP / IP report (message 38) to the AAA server that is persistent (i.e., requires an acknowledgment). Before sending the acknowledgment, process 41 running on AAA server 40 calls database procedure 43 to store the information received in the report.

[0061] Multicast Push Notifications In connection with some exemplary embodiments, some IV (Infrastructure-Vehicle) WAVE applications use multicast techniques in a "one-to-many" configuration to send "push notifications" to mobile devices. There are two basic categories of such applications: (1) Spatiotemporal commercial advertising: For example, promotion of discounted products or services at a particular retail location on a particular day / time. (2) Roadside Alerts (RAs). These are advisory messages from road network operators that correspond to the type of information currently provided as telephone service by many state and local jurisdictions in North America. RAs include, but are not limited to, accident notifications, lane closures, travel time advisories, and other road network operational events. RAs can also include semi-static navigation information such as speed limits, distance to destination, parking restrictions, and school zone or construction zone warnings. RAs are constructed according to a standardized format defined in the SAE J-2735 message set, which is incorporated herein by reference.

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

[0063] Business Model In some exemplary embodiments, there are two models for generating revenue from push notifications: "advertising" and "subscriptions." With the "advertising" model, the sender of the push notification compensates the network operator in some manner for sending the message. In this context, "advertising" is not limited to purely commercial applications, but can also apply to public service announcements such as accident notifications, lane closures, travel time advisories, and other road network operational events reported according to the standardized format for roadside alerts (RAs) presented in the SAE J-2735 message set.

[0064] 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 multicast or "one-to-many" message delivery methods. Client devices that join a multicast group can receive messages sent to the multicast address associated with that group, which means that it is technically feasible to implement software that allows any device to receive multicast messages, regardless of whether it has a valid subscription.

[0065] Differentiating Client Devices in the "Subscription" Model In the case of an "advertising" model, in some exemplary embodiments, revenue comes from the source of the message, so from a business perspective, there is no need to restrict access to messages on different categories of client devices. However, if a "subscription" model were to be effective, in which individual client devices are associated with revenue sources, then access would need to be restricted to only client devices with valid subscriptions.

[0066] In some exemplary embodiments, such restricted access may be provided by encrypting the payload of the multicast message. Such exemplary embodiments are not necessarily limited to any particular encryption methodology for this purpose, but are solely concerned with the task of ensuring that all recipients authorized to receive these messages possess the keying material necessary for decryption. The focus here is on establishing methods to ensure that the keys necessary for decryption can be securely distributed to authorized devices.

[0067] In some exemplary embodiments, a reliable and secure mechanism supporting a "subscription" model for multicast messages is shown in FIG. 12, whereby a client device may request authentication / authorization from an AAA server for access to a service based on unicast Internet messaging. FIG. 12 illustrates that a roadside unit (RSU) 30 may use a WSA 37 to advertise a multicast service using a provider service identifier (PSID) associated with the "subscription model." As described in FIGS. 1 and 2, an on-board unit (OBU) 20 may send a request 25 to an AAA server 40 identifying the IPv6 address of the connected client (user) device. The AAA server 40 then issues an authentication challenge 105 to the client device 10, and the client device 10 responds with an authentication challenge response 106 encapsulating the digital credentials required to access the multicast service, including an ECDSA signature and validation parameters provided by the SCMS identity certificate (ID certificate) for the multicast service, consisting of a public key and elliptic curve domain parameters. As previously specified, the AAA server 40 verifies the signature and account status to determine whether to grant authorization to the client device 10. If authorization is granted, the AAA server 40 utilizes ECIES (Elliptic Curve Integrated Encryption Scheme) 107 to derive a symmetric key using parameters published in the identity certificate and then encrypts the payload of an ECIES message 108. The plaintext version of the payload in the ECIES message 108 encapsulates the keying material needed by any and all client devices that are authorized to decrypt the multicast message 110. The client device 10 decrypts the payload of the ECIES message 108 by performing an ECIES step 109. Different embodiments of the AAA server 40 may use different algorithms for symmetric encryption / decryption of the payload of the multicast message 110.

[0068] The services advertised by the RSUs 30 are preferably managed by the AAA server 40, since it is the AAA server that is responsible for verifying the subscription account associated with the client device. Furthermore, only the AAA server 40 can map the spatiotemporal parameters specified by the business or government agency ("multicaster") originating the multicast message to the correct selected RSU target address. This process is shown in FIG. 13. Each time the message content for a particular target geographic area changes, the multicaster 300 sends the new message content and spatiotemporal parameters to the AAA server 40 using message 301. The AAA server 40 then performs process 302 to assemble a new set of multicast messages targeted to the appropriate RSUs and schedule their transmission. Because client devices submit authentication / authorization requests when they encounter a new RSU, the AAA server 40 can also change the keying material for encrypting the outgoing multicast message payload 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.

[0069] In some exemplary embodiments, the AAA server described allows authorities to While the AAA server provides accounting for environmental service channel bandwidth consumption, in some exemplary embodiments, the functionality provided by the AAA server may be utilized for other processes, applications, or services for which the OBU and / or one or more user devices associated with the OBU have a valid account or may be a subscriber, requiring SCMS credentials to support authentication. For example, in the case of traffic signal preemption, an agency may verify with a traffic management center co-located with the RSU that is responsible for controlling the traffic signal that an authenticated OBU in an approaching vehicle is authorized for priority signaling at a specified intersection. Other exemplary embodiments may include vehicles licensed to operate in lanes reserved for use only by vehicles of a particular vehicle type.

[0070] Thus, in some exemplary embodiments, the OBU may be configured to request authentication and authorization from an AAA server for access to any services to which it subscribes, either on behalf of nearby non-DSRC mobile devices or for itself.

[0071] All of the individual components shown in outline or as blocks in the accompanying drawings are well known in the injection molding art, and their specific construction and operation is not critical to the operation or best mode of carrying out the invention.

[0072] While the present invention has been described in terms of what are presently considered to be the preferred embodiments, it is to be understood that the invention is not limited to the disclosed embodiments. On the contrary, the invention is intended to cover various modifications and equivalent arrangements included within the scope of the appended claims. The scope of the following claims should be accorded the broadest interpretation to encompass all such modifications and equivalent structures and functions.

[0073] Terms: The example embodiments described herein, including the RSU, the OBU, the AAA server, and / or the client or remote device, are described in the following clauses.

[0074] 1. An AAA server operating by or on behalf of a dedicated short-range communications infrastructure authority that transmits messages between on-board units (OBUs) and roadside units (RSUs), the AAA server having at least one processor that executes at least one computer program configured to communicate over the Internet with OBUs, RSUs that serve a plurality of user devices and / or a subnetwork of one or more user devices, to perform authentication, authorization, and accounting (AAA) functions, and to enable the authority to account for wireless access vehicle environment service channel bandwidth consumption by each of the user devices that have been appropriately provisioned by the AAA server.

[0075] 2. An AAA server operating by or on behalf of a dedicated short-range communications infrastructure authority that transmits messages between on-board units (OBUs) and roadside units (RSUs), said AAA server executing at least one computer program configured to communicate over the Internet with a plurality of user devices and / or OBUs serving one or more subnets of user devices, a plurality of RSUs, to perform authentication, authorization, and accounting (AAA) functions and enable an authority to authenticate said user devices and / or said OBUs and thereby authorize said user devices and / or said OBUs for access to any services subscribed to.

[0076] 3. A certificate management entity configured to issue an Internet subscription digital certificate for an IPv6 addressable user device and transmit the certificate to said user device over a secure communication channel, said certificate being an A The AAA server according to any one of the preceding clauses or the following clauses, including the domain name of the AAA server.

[0077] 4. An AAA server as described in any one of the preceding or following clauses, linked in a PKI chain of trust between components of a Security Credential and Management System (SCMS) and operable to process a request from a DSRC OBU for said digital certificate, said request encapsulating the OBU's personally identifiable information (PII) and secured by an asymmetric encryption algorithm specified in IEEE 1609.2, using an enrollment certificate issued to said OBU by SCMS, and operable to establish a secure communication channel for transmitting said certificate to said OBU using an encryption key of said enrollment certificate.

[0078] 5. The AAA server of any one of the preceding or following clauses, operable to process requests from non-DSRC mobile devices for the digital certificate, the requests encapsulating PII of the mobile devices, and wherein each mobile device initiates a handshake protocol to establish a secure, symmetrically encrypted communication channel with the AAA server.

[0079] 6. An AAA server according to any one of the preceding or following clauses, operable to receive authorization and authentication binding requests from an OBU, said request incorporating credentials in the form of a digital signature generated using a key from the Internet subscription certificate issued by said AAA server to said OBU, wherein the AAA server is operable to receive said authorization and authentication binding requests forwarded from said remote AAA servers on behalf of OBUs that have received said Internet subscription certificate from one or more remote AAA servers, and is operable to process requests from both the OBU and the remote AAA servers by cryptographic verification of the credentials correspondingly presented by said OBU and said remote AAA servers, and for each request, queries a non-remote AAA database for a match with PII contained in the request and returns a message to the requesting OBU or remote AAA either granting authentication or rejecting authentication together with a code indicating the reason for the rejection.

[0080] 7. The AAA server of any one of the preceding or following clauses, operable to receive an authentication request from the OBU on behalf of a non-DSRC mobile device, send a UDP / IP authentication challenge message directly or indirectly to an IPv6 address of the non-DSRC mobile device, and process a response to the authentication challenge incorporating credentials in the form of a digital signature generated using a key from the Internet subscription certificate issued by the AAA server to the non-DSRC mobile device, operable to receive the authentication request forwarded from a remote AAA server on behalf of the non-DSRC mobile device that received the Internet subscription credentials from the AAA server, and operable to process requests from both the non-DSRC mobile device and the remote AAA server with cryptographic verification of the presented credentials, query a local AAA database for a match with PII included in the request, and return a message to the requester either granting the authentication or denying the authentication along with a code explaining the reason for the denial.

[0081] 8. The AAA server of any one of the preceding or following clauses, operable to, if the domain name of a certificate management entity that issued credentials used by a user device to request authentication and authorization identifies a remote AAA server, use credentials obtained from the SCMS chain of trust to securely communicate with the remote server and forward the request to the remote AAA server.

[0082] 9. The AAA server of any one of the preceding or following clauses, operable to, if the domain name of a certificate management entity that issued credentials used by a user device to respond to an authentication challenge from the AAA server identifies a remote AAA server, securely communicate with the remote AAA server using credentials obtained from the SCMS chain of trust and forward the request to the remote AAA server.

[0083] 10. The AAA server of any one of the preceding clauses or the following clauses, operable to send an update message to an RSU within the same autonomous system using Remote Trigger Black Hole (RTBH) filtering together with an internal b Border Gateway Protocol, the update message being triggered by an authentication and authorization request for an Internet subscription service received from a user device, and encapsulating the result of the authentication and authorization request, the result being a failure to authenticate the mobile device or an authorization or denial of authentication to the user device.

[0084] 11. An AAA server according to any one of the preceding or following clauses, wherein, upon receiving an authentication request together with SCMS credentials issued to a multicast service identified by the PSID encapsulated in the request, the ECIES is used to encrypt and transmit to the requesting device the parameters and keying material required for symmetric encryption of the payload of a multicast "push notification" provided by said multicast service.

[0085] 12. A roadside unit (RSU) configured with an extended IPv6 management information base (MIB) and operable to identify packet and byte count statistics of wireless access vehicle vehicular (WAVE) service channel usage for each client device, the client device being either an on-board unit (OBU), a non-DSRC mobile device IPv6 reachable through the OBU, or a DSRC-enabled user device, the IPv6 MIB also operable to look up, for each datagram received from an IPv6 node operating in a Mobile IPv6 route optimization mode, the mobile node's fixed "home address" carried in the Mobile IPv6 routing header of the datagram, the RSU operable to accumulate the packet and byte count statistics of WAVE service channel usage for each client device in a non-volatile random access memory (NOVRAM), periodically send the statistics encapsulated in UDP / IP messages to an AAA server, and refresh the NOVRAM table only when the AAA server acknowledges receipt of the UDP / IP message.

[0086] 13. The preceding clause or clauses comply with the USDOT specifications found at http: / / docplayer.net / 11087167-Dsrc-roadside-unit-rsu-specifications-document.html or its functional equivalent. means an RSU described in any one of the following clauses:

[0087] 14. An RSU according to any one of the preceding clauses or the following clauses, operable to process RTBH filtering instructions from an AAA server within the same autonomous system.

[0088] 15. The RSUs listed above comply with the USDOT specifications found at http: / / docplayer.net / 11087167-Dsrc-roadside-unit-rsu-specifications-document.html or their functional equivalents. an RSU operable to broadcast a service announcement (WSA) encapsulating a public key of a Security Credential and Management System (SCMS) enrollment certificate issued to an AAA server operating in the same domain as the RSU;

[0089] 16. An OBU that complies with WAVE and IEEE 802.11p, is configurable for dual radio functionality, and executes at least one application level computer program configured to request authentication and authorization from an AAA server for IPv6 connectivity to the Internet on behalf of a nearby non-DSRC mobile device or for itself, and is configured with an extended IPv6 MIB operable to periodically look up the routing table using a synchronous method based on SNMP GET or to report "real-time" changes in the routing table when new entries are inserted into the routing table, or to look up addresses of nearby devices using an asynchronous method based on SNMP TRAP.

[0090] 17. An OBU compliant with WAVE and IEEE 802.11p, configurable for dual radio functionality, running at least one application level computer program configured to request authentication and authorization from an AAA server for access to any services to which it subscribes, on behalf of nearby non-DSRC mobile devices or for itself, and configured with an extended IPv6 MIB operable to periodically look up the routing table using a synchronous method based on SNMP GET or to report "real-time" changes in the routing table when new entries are inserted in the routing table, or to look up addresses of nearby devices using an asynchronous method based on SNMP TRAP.

[0091] 18. An OBU as described in any one of the preceding or following clauses, operable to request "Internet Subscription" credentials from the AAA server using an SCMS enrollment certificate from encrypting requests to and decrypting responses from the AAA server, and operable to use said credentials when requesting authentication and authorization from the AAA server for said IPv6 connection to the Internet.

[0092] 19. An OBU as described in any one of the preceding or following clauses, wherein after an authentication request is sent together with SCMS credentials issued to a multicast service identified by a PSID encapsulated in the request, an ECIES decryptor is used to decrypt ECIES encryption parameters and keying material required for symmetric decryption of the payload of a multicast "push notification" provided by the multicast service.

[0093] 20. A mobile device configured to communicate with an OBU for IPv6 connectivity to the Internet as described in any one of the preceding or following clauses, wherein after sending an authorization request with an SCMS credential issued to a multicast service identified by a PSID encapsulated in the request, an ECIES decryption is used to decrypt ECIES encryption parameters and keying material required for symmetric decryption of the payload of a multicast "push notification" provided by the multicast service.

[0094] 21. A system utilizing dedicated short-range communications (DSRC) to communicate with an OBU serving a plurality of user devices and / or one or more subnets of user devices over the Internet to facilitate communication between an on-board unit (OBU) and a roadside unit (RSU), the system comprising: a server for transmitting messages between the OBU and the RSU, the server having at least one processor executing at least one computer program configured to authenticate user devices, authorize user devices for access to a wireless access vehicular environment (WAVE) service channel, and account for bandwidth consumption by each of said user devices properly authenticated and authorized by said AAA server; A system having:

[0095] 22. A system according to any one of the preceding clauses, comprising a plurality of servers operating by or on behalf of a dedicated short range communications (DSRC) infrastructure authority.

[0096] 23. A system according to any one of the preceding clauses.

[0097] The present disclosure, clauses, claims, and figures should be considered to support any claim that recites any element, feature, structure, function, and / or step of any aspect and / or exemplary embodiment described in this disclosure, including any figure, clause, and / or claim 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 this disclosure, including any figure, clause, and / or claim herein.

[0098] The following citations are incorporated herein by reference: 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. IEEE 802.11p: IEEE STANDARD 802.11p-2010-IEEE Standard for Information technology- Local and metropolitan area networks-Specific requirements-Part 11:Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 6:Wireless Access in Vehicular Environments, available at https: / / standards.ieee.org / findstds / standard / 802.11p-2010.html U.S. Patent Application No. 14 / 151,035, available at http: / / www.google.com / patents / US20140195102 SCMS Vehicle-to-Vehicle Security Credential Management System; Request for Information, A Notice by the National Highway Traffic Safety Administration on 10 / 15 / 2014, available at http: / / federalregister.gov / a / 2014-24482 Request For Comments (RFC) 4861 (Neighbor Discovery for IPv6) September 2007, available at https: / / tools.ietf.org / html / rfc4861 RFC 4862 (Stateless Address Autoconfiguration) September 2007, available at https: / / tools.ietf.org / html / rfc4862 RFC 6275 (Mobility Support in IPv6) July 2011, available at https: / / tools.ietf.org / html / rfc6275 RFC 5635 (Remote Triggered Black Hole Filtering) August 2009, available at https: / / tools.ietf.org / html / rfc5635 RFC 4271 (Border Gateway Protocol 4) January 2006, available at https: / / tools.ietf.org / html / rfc4271 RFC 4291 (IPv6 Addressing Architecture) February 2006, available at https: / / tools.ietf.org / html / rfc4291 V2V Readiness Report DOTHS 812 014 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

[0099] All of the above-mentioned US patents and patent applications, and all articles, documents, papers, specifications, etc. referenced above, are hereby incorporated by reference.

Claims

1. 1. An AAA server operating by or on behalf of a dedicated short-range communications infrastructure authority that transmits messages between on-board units (OBUs) and roadside units (RSUs), the AAA server having at least one processor that executes at least one computer program configured to communicate over the Internet with OBUs, RSUs servicing a plurality of user devices and / or one or more subnets of user devices to perform authentication, authorization, and accounting (AAA) functions and enable the authority to account for wireless access vehicle environment service channel bandwidth consumption by each of the user devices that have been appropriately provisioned by the AAA server.

2. 1. An AAA server operating by or on behalf of a dedicated short-range communications infrastructure authority that transmits messages between an on-board unit (OBU) and a roadside unit (RSU), the AAA server having at least one processor that executes at least one computer program configured to communicate over the Internet with a plurality of user devices and / or OBUs, a plurality of RSUs serving one or more subnets of user devices, to perform authentication, authorization, and accounting (AAA) functions, and to enable the authority to authenticate the user devices and / or the OBUs and thereby authorize the user devices and / or the OBUs for access to any services subscribed to.

3. 3. The AAA server of claim 1 or 2, configured as a certificate management entity and operable to issue an Internet subscription digital certificate for an IPv6 addressable user device and transmit said certificate to said user device over a secure communication channel, said certificate including the domain name of said AAA server.

4. 4. The AAA server of claim 1, wherein the AAA server is linked to a PKI chain of trust between components of a Security Credential and Management System (SCMS), and is operable to process requests from a DSRC OBU for the digital certificate, the request encapsulating personally identifiable information (PII) of the OBU and secured by an asymmetric encryption algorithm specified in IEEE 1609.2, using an enrollment certificate issued to the OBU by the SCMS, and is operable to establish the secure communication channel for transmitting the certificate to the OBU using an encryption key of the enrollment certificate.

5. 5. The AAA server of claim 1, operable to process requests from non-DSRC mobile devices for the digital certificate, the requests encapsulating PII of the mobile devices, and each of the mobile devices initiating a handshake protocol to establish a secure symmetrically encrypted communication channel with the AAA server.

6. a AAA server operable to receive authorization and authentication binding requests from an OBU, the request incorporating credentials in the form of a digital signature generated using a key from an Internet subscription certificate issued by the AAA server to the OBU, the AAA server operable to receive the authorization and authentication binding requests forwarded from one or more remote AAA servers on behalf of an OBU that has received the Internet subscription certificate from the remote AAA server, and operable to process requests from both the OBU and the remote AAA server by cryptographic verification of the credentials correspondingly presented by the OBU and the remote AAA server, and each 6. The AAA server of claim 1, wherein the AAA server queries a non-remote AAA database for a request for a match with the PII contained in the request and returns a message to the requesting OBU or remote AAA either granting authentication or rejecting authentication together with a code indicating the reason for rejection.

7. 7. The AAA server of claim 1, wherein the AAA server is operable to receive an authentication request from the OBU on behalf of a non-DSRC mobile device, send a UDP / IP authentication challenge message directly or indirectly to an IPv6 address of the non-DSRC mobile device, and process a response to the authentication challenge incorporating credentials in the form of a digital signature generated using a key from the Internet subscription certificate issued by the AAA server to the non-DSRC mobile device; receive the authentication request forwarded from a remote AAA server on behalf of the non-DSRC mobile device that has received the Internet subscription credentials from the AAA server; process the requests from both the non-DSRC mobile device and the remote AAA server with cryptographic verification of the presented credentials; query a local AAA database for a match with PII included in the request; and return a message to the requester either granting authentication or rejecting authentication along with a code explaining the reason for the rejection.

8. 8. The AAA server of claim 1, wherein if the domain name of the certificate management entity that issued the credentials used by the user device to request authentication and authorization identifies a remote AAA server, the AAA server is operable to securely communicate with the remote server using credentials obtained from an SCMS chain of trust and forward the request to the remote AAA server.

9. 9. The AAA server of claim 1, wherein if the domain name of the certificate management entity that issued the credentials used by the user device to respond to an authentication challenge from the AAA server identifies a remote AAA server, the AAA server is operable to securely communicate with the remote AAA server using credentials obtained from the SCMS chain of trust and forward the request to the remote AAA server.

10. 10. The AAA server of claim 1, operable to send update messages to RSUs within the same autonomous system using Remote Trigger Black Hole (RTBH) filtering in conjunction with an internal border gateway protocol, the update messages being triggered by authentication and authorization requests for Internet subscription services received from a user device, and encapsulating the results of the authentication and authorization requests, the results being a failure to authenticate the mobile device or a grant or denial of authentication to the user device.

11. 11. The AAA server of claim 1, wherein, upon receiving an authentication request together with SCMS credentials issued to a multicast service identified by a PSID encapsulated in the request, an ECIES is used to encrypt and transmit to the requesting device the parameters and keying material required for symmetric encryption of the payload of a multicast "push notification" provided by the multicast service.

12. A roadside unit (RSU) configured with an extended IPv6 management information base (MIB) and operable to identify packet and byte count statistics of wireless access vehicle vehicular (WAVE) service channel usage per client device, the client device being an on-board unit (OBU), a non-DSRC mobile device reachable via IPv6 through the OBU. a Roadside Unit (RSU) configured to store, in a non-volatile random access memory (NOVRAM), the packet and byte count statistics of WAVE service channel usage for each client device, and to periodically transmit the statistics encapsulated in UDP / IP messages to an AAA server, and to refresh the NOVRAM table only when the AAA server acknowledges receipt of the UDP / IP messages.

13. 13. The method of claim 12, which complies with the USDOT specifications found at http: / / docplayer.net / 11087167-Dsrc-roadside-unit-rsu-specifications-document.html or its functional equivalent. RSU listed.

14. 14. The RSU of claim 12 or 13, operable to process RTBH filtering instructions from an AAA server in the same autonomous system.

15. Complies with the USDOT specifications found at http: / / docplayer.net / 11087167-Dsrc-roadside-unit-rsu-specifications-document.html or its functional equivalent and is in the same domain as the RSU. The RSU is operable to broadcast a service announcement (WSA) encapsulating the public key of a Security Credential and Management System (SCMS) enrollment certificate issued to an AAA server operating in the RSU.

16. an OBU compliant with WAVE and IEEE 802.11p, configurable for dual radio functionality, running at least one application level computer program configured to request authentication and authorization from an AAA server for IPv6 connectivity to the Internet on behalf of a nearby non-DSRC mobile device or for itself, and configured with an extended IPv6 MIB operable to report "real-time" changes in said routing table when new entries are inserted into the routing table, either periodically using a synchronous method based on SNMP GET, or using an asynchronous method based on SNMP TRAP, to retrieve addresses of nearby devices.

17. an OBU that is compliant with WAVE and IEEE 802.11p, configurable for dual radio functionality, and that executes at least one application level computer program configured to request authentication and authorization from an AAA server on behalf of or for itself a nearby non-DSRC mobile device for access to any services to which it subscribes, and that is configured with an extended IPv6 MIB operable to periodically look up the routing table using a synchronous method based on SNMP GET when a new entry is inserted in the routing table, or to look up addresses of nearby devices using an asynchronous method based on SNMP TRAP when a new entry is inserted in the routing table, reporting "real-time" changes in the routing table;

18. 18. The OBU of claim 16 or 17, operable to request "Internet Subscription" credentials from an AAA server using an SCMS enrollment certificate to digitally sign a request to the AAA server, the request including the public key of the enrollment certificate, the public key enabling the AAA server to encrypt a response, and operable to use the credentials when requesting authentication and authorization from the AAA server for the IPv6 connection to the Internet.

19. 19. The OBU of claim 16, wherein after an authentication request is sent together with SCMS credentials issued to a multicast service identified by a PSID encapsulated in the request, an ECIES decryption is used to decrypt ECIES encryption parameters and keying material required for symmetric decryption of payloads of multicast "push notifications" provided by the multicast service.

20. A mobile device configured to communicate with an OBU for IPv6 connectivity to the Internet as claimed in any one of claims 1 to 19 or claims 21 to 23, wherein after sending an authorization request together with SCMS credentials issued to a multicast service identified by a PSID encapsulated in the request, ECIES decryption is used to decrypt ECIES encryption parameters and keying material required for symmetric decryption of payloads of multicast "push notifications" provided by said multicast service.

21. 1. A system for facilitating communication between an On-Board Unit (OBU) and a Roadside Unit (RSU) utilizing Dedicated Short Range Communications (DSRC) to communicate over the Internet with an OBU serving multiple user devices and / or one or more subnets of user devices, the system comprising: a server for transmitting messages between the OBU and the RSU, the server having at least one processor executing at least one computer program configured to authenticate the user devices, authorize the user devices for access to a Wireless Access Vehicular Environment (WAVE) service channel, and account for bandwidth consumption by each of the user devices that are properly authenticated and authorized by an AAA server; A system having:

22. 22. The system of claim 21, comprising a plurality of servers operating by or on behalf of a dedicated short range communications (DSRC) infrastructure authority.

23. A system according to any one of claims 1 to 22.

Images