This is the third of four follow-on articles to Do Smart Highways Now—Delay is Not Smart, in which an integrated automated highway system is envisioned. This article will describe the communications infrastructure for the system.
The Layer 1 (radio link) component that carries signalling and control to and from the cars themselves arguably could be provided by any existing radio frequency based technology. The use of different radio link methods likely would result, based on which solution is optimal for a specific section of road or street. The specs for the transponder unit would require that it detect and establish a link with that method servicing the section the car was travelling in at any instant. Local terrestrial links would be the method of choice, providing both better reliability and lower latency due to the physics of the shorter distance. Satellite could be a fallback method, but shouldn’t be primary for the link to the cars themselves (if it’s used at all), as it would be less reliable for the opposite reasons that local terrestrial is better. Anything overhead (or even locally adjacent) could degrade a satellite signal or block it altogether, such as going through a tunnel or during heavy precipitation.
Naturally there will be structures of some type along the roadside or median for the local antennas at the tactical link nodes, placed as necessary for required coverage. These don’t have to be ugly, looking like dangling debris or bare tree branches in winter—artful ways to pretty them up are myriad. (I could even see using them in creative ways to also support diminished avian or chiropteran (bats) wildlife without degrading the signals, but that’s outside the scope of this subject.) In populated areas, street lights and traffic lights as well as building edifices are ready made sites for this purpose, as these have power and support structures already available.
The tactical link nodes will be those the transponders in the cars talk with. They are the system’s optical and aural nerves to the status on the ground, and also its means of delivering system commands to each car’s control system. It is the responsibility of the transponder unit in each car to maintain positive authenticated connectivity with the communications system. To help the transponder do this, it will receive a dynamic local “map” of the nodes immediately adjacent to the one it is connected to at any instant. Two helpful analogies to existing tech for this are routing tables used by Internet routers, and the Ephemeris data transmitted to local GPS units. The node map will reach further in the direction of travel, similar to the cardioid pattern of some microphones (no point in taking up memory space for where you’re not going, but good to have a longer view of where you are going). With this map instantly available, the transponder prepares ahead for hand-off to the next node along the route, to maintain an uninterrupted session with the central system.
All points in the communication path, especially those in the tactical segments, are assigned IPv6 addresses. These IPv6 addresses are registered in the distributed central system for instant response to any situation or incident. There are many features of IPv6 that are (as yet) mostly untapped. The dynamic real time variations in a vehicle flow system lend themselves readily to leveraging IPv6 features such as extension headers in each packet. By their nature these extension headers are user defined, offering a wide range of control and telemetry metadata possibilities within the IPv6 headers themselves. For example, packets could be marked as for either telemetry or control, and using this for sending them directly to their destination process within the receiving device. This could potentially reduce the amount of information that must go into the packet payloads, further reducing transmission volume and commensurate latency—as well as processing time once delivered.
As PKI (Public Key Infrastructure) is increasingly being integrated with IPv6, secure authentication will be increasingly workable between each transponder and the tactical node it is connected with. A unique routing address (IPv6) and authentication key (PKI), combined with a connection encrypted with proven widely used methods (e.g. TLS, IPsec, etc.), will provide requisite assurance that what the cars report and what the system commands are genuine and trustworthy. The IPv6 address and PKI public key of each transponder will be registered in the distributed central system. A transponder’s private key would be securely installed inside the unit—if it became damaged or otherwise quit working a new key pair would be generated, installed, and registered.
In addition to route location based node transfers, the nodes and transponder units would be configured to monitor for minimum signal strength and data rate. Upon detecting a drop below the design minimum level for any of those values, by either the node or the transponder, the communications system would hand off the transponder to the next acceptable node on the route. An acceptable node would be one that provided the requisite minimum performance specs.
The link from each node upstream to the system back end would be by the most optimal and practicable means available at each node’s geographic site. Options could include 4G/5G, WiMAX, fiber optic, or even cable modem. From there, the communication path would enter the Internet cloud and come out at one or more of the redundant gateways into the vehicle flow system’s distributed central system. It would travel through one (or a combination of) the encrypted means provided by VPN or dedicated circuits. The required consistent high throughput would not depend on prioritization within common services (although it would use them), but reliability would be assured through further telecommunications infrastructure build out.
It is conceivable that much of the connectivity would be provided through software defined network infrastructure. The building blocks for these are already available in offerings of orchestrated routing and switching capabilities from existing cloud services providers.
As would be done in the distributed central computing system, the communications system would monitor its own status, and execute pre-programmed self-healing measures (e.g. re-routing fallbacks) in event of the loss of a node or back haul connection.
Logistics support for the tactical nodes would be no different than that for similar installations. Provisions for electric power would be readily available in populated areas. Renewable power (solar, wind, etc.) would be a feasible augmentation, and in some cases reasonable primary power sources for some of the nodes. Ready and safe access for maintenance personnel also should be an integral optimized engineering design feature for all nodes.
Designed together with the other main components, the communications infrastructure would be able to seamlessly assume its function in the vehicle flow system.
—