Arcep has shared the initial results of some excellent navel-gazing it has undertaken, as the French telco watchdog tries to redefine its purpose as networks migrate to the cloud, and evolve to support a richer variety of services.
The first two bodies of work, available only in French for now, concern connected vehicles and virtualisation.
Arcep is not proposing any solutions at this point; it is not really even posing any questions. Instead it is identifying various issues it needs to discuss with interested parties to make sure that regulation keeps up with technological progress.
"In this era of continual innovation, telecoms networks are expected to undergo major upheavals in the coming years, as much in terms of their architecture as how they operate. This is why Arcep opened up a period of reflection to anticipate how networks are likely to evolve over the next five to ten years," Arcep said, in a statement.
To help with the reflecting, Arcep assembled a 10-person committee of academics, entrepreneurs and industry veterans "with varying areas of expertise". Try to imagine this without picturing Sartre having a thoughtful puff on his pipe. It's impossible.
Car trouble
Arcep seems a little troubled by the flourishing ecosystem around connected vehicles. The problem with all this unhindered innovation is that it is too scattergun, resulting in competing air interfaces and ambiguous business models.
It sees the need to establish "a unifying ecosystem between vehicles, telecommunication networks and road networks, which will pave the way for various uses in the field of road safety, traffic efficiency, environmental protection or driver comfort."
As far as Arcep is concerned, when it comes to enabling cars to communicate with each other and the world around them, it is a two-horse race between the IEEE-backed ITS-G5, and 3GPP's C-V2X, which both make use of 5.9-GHz spectrum. Some car makers favour the former, while others prefer the latter.
"These two technologies are not interoperable today," Arcep said while acknowledging that work is underway to change that. "The technological debate is considered regrettable as it generates many uncertainties that slow down the deployment of technologies and infrastructure along the roads."
Arcep wants stakeholders to chime in with their thoughts, and while it pose explicit questions, implicitly, the questions are there for all to see: To what extent can and should Arcep intervene in order to facilitate a unified ecosystem? Should it back one technology over another? Does it have any sway over technology decisions taken by car makers? Should it?
Virtual networks, real headaches
The second document grapples with new network architectures facilitated by NFV and SDN, and the new business models they might support, such as hosting virtual network functions – or even an entire network – on behalf of other operators or corporate customers.
Arcep wants to know how NFV and SDN can best be exploited to the benefit of innovation and competition, and what regulatory headaches all this might cause regarding interoperability, net neutrality, security, and national sovereignty.
Those last two considerations are particularly interesting, because they sound like they have the potential to become a bureaucratic nightmare.
"The relocation of certain functions abroad, facilitated by virtualisation, can also have an impact on the capacity of the state to implement its capabilities in the detection of cyberattacks or reaction in a crisis," Arcep explained "The fact that functions historically internalised by operators can be outsourced to external suppliers may also have an impact related to sovereignty when, for example, these actors are subject to foreign regulations."
In addition, when it comes to lawful interception of communications, France's current legal framework is clear that devices that enable such interception must receive authorisation from the prime minister.
"However, when network functions, subject to the authorisation regime mentioned above, are virtualised, there is the question of precisely which elements must obtain this authorisation," said Arcep. "Is it just the virtualised feature itself, or do you need authorisation for the cloud infrastructure, physical machines and operating systems that can perform the virtualised functions for which authorisation is required?"