Connected Cars – Charlemagne Protocol
Connected Cars – Charlemagne Protocol
Protocols are crucial part of the technology world. Protocols helped technology to penetrate deep into peoples lives and make a difference. In simple terms people communicate among each other with a language. In the technology world this language is represented by protocol. Its a direct comparison and can be strictly applied to real life. Take for example only when you can speak german language can you communicate well with germans. In the technology world, a bluetooth enabled phone speaks to a bluetooth enabled speaker to stream audio. Definitely concept of protocol is one of the greatest realisation of the technology revolution. Not really sure when the first protocol was evolved and how long it survived but TCP protocol which is being used now was first formulated in 1974 by IEEE.
Coming to our context of connected cars, my whole idea is to evolve a protocol for allowing the cars to communicate among themselves and to the fixed infrastructure. I am calling it the Charlemagne Protocol based on the King of the Franks who united most of Western Europe during the early Middle Ages and laid the foundations for modern France and Germany. This protocol resides in the HU of the car, part of the IVI system which is a computing powerhouse of the complete car. This protocol stack should be integral part of all vehicles, typically part of the vehicle communication framework inside the Head Unit or IVI system. In order to communicate to external world, the Charlemagne protocol can use any medium i.e over GSM or LTE or wifi. I am looking forward to evolve a standard communication protocol above the existing connectivity medium already functional. So my protocol will not have any of the layers below the network layer as per 7 layer OSI standard. The primary reason is that we already have a broad infrastructure in place for various devices to communicate. There is no reason to reinvent the wheel and lets utilise the existing communication medium be it DSRC or LTE. Its wise to evolve a protocol on top of the existing medium. Moreover in a moving car at any point of time many communication mediums can be active. So a feature or profiles functionality will greatly depend on the currently active communication medium and current state of the car.
The following is high level overview of the layers of the protocol. I have tried to map it with respect to the OSI 7 layers model.
This layer primary responsibility is to identify the currently active communication networks and ensure that there is minimum 1 active medium of communication available at any point of time for the vehicle. The system cannot function without at least 1 active communication medium, this requirement is validated and confirmed by this layer. The vehicle can support various communication mechanisms like GSM, LTE, DSRC, WLAN ….etc. The support can also be varying based on current location of the car and also the class of the car. That is, a high end model can support multiple communications mechanisms but a basic model supports only a few communication mechanisms. This layer identifies the best communication mechanism and helps the car to connect to external world. This is a continuous process since as the car travels we have to continuously monitor the underlying communication mechanisms and keep updating it.
This layer is responsible for making a connection to a particular service of interest. This service can be from an infrastructure or another vehicle. This connection is dependent on the transport medium currently available and not all services can be connected to via all transport medium. Based on the location of the car the number of connections active will keep changing and this is a very dynamic module.
The service discovery layer primary job is to connect and find out nearby service which can be utilised by the car. On a broad level this can be a discovery of services from infrastructure or discovery of services from other vehicles. Services from infrastructure will include connecting to toll gates, petrol pumps, parking place ….etc. Services from other vehicles can include connecting to nearby car for file streaming or information exchange like route, hazard information … etc. This discovery layer operates in 2 modes or sub classifications. Certain modes are continuous discovery and is not controlled by the user rather its programmed by the OEM. Certain modes can be controlled i.e turned ON or OFF by user based on his interest.
The following are more elaborate requirements for service discovery,
The car communicates with the nearby infrastructure to find information and point of interests. This is highly related or similar to point of interests feature of a navigation system. Basic idea is to connect to petrol pumps or toll systems or recreational areas based on interest of the user profile. Certain discovery likes toll gate or hazard on road are very important and is automated by the system i.e the vehicle automatically connects and communicates with such infrastructure. Other discovery like point of interest to car user can be controlled and programmed by the user itself. This can be turned on or off on need basis by the user.
Connecting and communicating with nearby vehicles to identify any common points of interest. This point of interest can be from OEM side whether to see if another car of their own make is travelling or can be from the navigation system to identify that they are travelling in the same route or can be from the HU user profile that close friends or family members are travelling.
This vehicle discovery can be tailored to meet the following requirements,
Discovery of vehicles of own make to share information and record information. This can also include car rental companies sharing common information, cars from the same company sharing information …. etc.
Apart from commercial reasons even cars among a group of families or friends can be made to communicate to share each others location and also to locate each other. The information exchange possibilities are end less and highly demanding use cases for technology enablement of mass.
Session Control Link
On top of the connection control layer, the logical link will be like sessions controlling the various communication happening between the cars. These are sessions established after connecting to either a specific infrastructure or to a vehicle. These sessions can be active as long as the connection between the service and vehicle is active. A single connection can establish multiple sessions also. The sessions can be similar to a typical TCP/IP sessions to exchange information across 2 entities.
This is the top layer of the Protocol. This layer is a collection of protocols derived to achieve the following functionalities. This can be extended based on requirements to support more and more features and functionalities.
File Streaming & Transfer
This is a protocol to connect to another nearby vehicle or infrastructure to stream live media or transfer files. This can either be a online radio channel streaming or a movie streaming from a site or even from a nearby vehicle which has a USB loaded with movies or songs.
Parking & Toll Gates
This layer is to connect to nearby toll gates and pay the fees on the go. This layer has to be customisable based on geographic location and the transport medium supported by the location.
This is very much similar to the hazard warning in the current navigation system. A common communication layer to exchange hazard warning on the planned pathway.
User Info Exchange
This layer will connect to nearby vehicles and infrastructure and exchange user specific information. This is a highly configurable module and what information exchanged is based on user interest. This can be connecting and information exchange with a home monitoring system or pairing with a friends car to see their route or live tracking of a shipment vehicle of interest. The use cases are very high and this layer should be extensible for future needs also.
The emergency call service can also be another module in this layer. This protocol layer gets activated in case of an emergency situation like car crash or a breakdown situation. This has to be flexible to accommodate more and more use cases based on geographic location.