The expansion of communication networks has made the efficient configuration and management of these networks challenging. Software-defined networking (SDN) facilitates the rapid provisioning of network services, improved network visibility and programmability, network function virtualization, and reduced operational costs, to highlight a few benefits. Because of its capabilities, SDN has become popular among network service providers and in enterprise and cloud networks. The scale of these networks and the amount of data storage/transfer these networks support must be noted here. Also, the security of SDN is widely debated because a compromised network controller could pose a risk to the whole network.

Keeping the aforementioned capabilities and use cases of SDN in mind, how about incorporating it into in-vehicle networks? The authors advocate for the use of SDN in in-vehicle networks. The authors predict that automotive Ethernet will replace the traditional in-vehicle protocol buses, such as CAN, LIN, and FlexRay, to attain better bandwidth and quality of service (QoS), and they believe that incorporating SDN will provide additional benefits such as dynamic reconfigurability, firewalling, programmable QoS, and network slicing and flow isolation.

Connected vehicles are already communicating with cloud networks. Software-defined vehicular networks have already caught the interest of the research community. In the near future, the components of an in-vehicle network could also become part of a wider network that is configured/controlled from outside, blurring the “in-vehicle” boundaries.

But many questions may concern the research community. In order to achieve high data rates, dynamic configurability, and high QoS, is it acceptable to open an in-vehicle network to configuration/control from external entities? Is the size of an in-vehicle network appropriate for SDN? Couldn’t a failed or compromised SDN controller in an in-vehicle network pose a risk to occupants? Will the introduction of SDN in an in-vehicle network lead to added complexity and deteriorated network performance (in an environment where we expect real-time communication), or change things for the better? The authors’ paper opens up new avenues for research.