Meeting minutes
Intro
Sudeep: welcome to all - this is our 8th teleconference meeting - hope all is doing fine in this difficult times, thank you for taking the time to join this call
Sudeep: today's agenda will cover 2 call to actions, followed by a presentation on 5GAA from Dario
Sudeep: 2 call for actions:
… the network information API, a work item driven by the Web Platform Incubator Community Group, is a candidate for inclusion in a WG charter
… we had an overview of the API a few weeks ago, and its implementations in Chromium
Call for any requirements for NetInfo API
Sudeep: please have a look and see if you have input on this proposal
… Another call for actions: a request from a W3C Member company, Peer5
… they've started a discussion around requirements for P2P CDNs with host-to-host connectivity, around IP address obfuscation
Sudeep: this is also relevant to the scope of our IG - we've had presentations around P2P CDN before
… please take a look at the problem statements on the github issue
… and provide your input
… Upcoming discussion in the IG will include a presentation from Cloudflare that Dom is arranging
… Now, handing over to Dario to talk about some of the insights from the 5GAA on predictive QoS
Presentation from Dario Sabella - MEC in ACTION: An Overview of Edge Computing Activities, Part2: Predictive QoS for Edge Computing, insights from 5GAA
Dario: this is a follow up to my presentation in January when we ran out of time
Minutes of the previous presentation
Dario: I'm an Intel delegate for 5GAA, also vice-chair of MEC
… last time we covered an intro to edge computing, the MEC standard and the use cases of interest
… Today we will cover Predictive QoS in the context of 5GAA
… 5GAA is a huge association, with over 130 members coming mainly from 2 family of stakeholders: automotive industry and telecommunications
… The goal of 5GAA is to bring together automotive, technology & telecom comapnies to work together to develop e2e connectivity solutions for future mobility and transportation services
… the goal is to make two worlds together, across a set of skills, perspectives, languages
… I'm coming from the telco background and it has been very useful to listen to requirements from car makers and turn those in terms of telco requirements
… it includes many aspects of C-V2X incl technology, standards... incl business models
… [5GAA Org structure]
… There are a number of WGs dealing with different activities (use cases & requirements, architecture, testing & pilots, standards & spectrum, business models, regulatory, security & privacy)
… [slide: What is C-V2X?]
… C-V2X: "Cellular-Vehicle to Everything"
… this includes vehicle-to-vehicle (V2V), vehicle to pedestrian (V2P), vehicle to infrastructure (V2I), vehicle to (cellular) network (V2N)
… bringing network to the car brings another "sensor" to the car
… it enables communications with other cars, other (vulnerable) road users such as cars and bikes, and infrastructure
… the 5GAA is collaborating with many organizations
… Looking more specifically at Edge Computing / MEC - it is a key technology for many use cases in 5GAA
… [slide: Automated and Connected cars - key drivers]
… there are 10s or 100s use cases defined by automotive stakeholders in detailed way, with a number of white papers published
… see www.5gaa.org
… One white paper might be of particular interest
Toward fully connected vehicles: Edge computing for advanced automotive communications
Dario: more recently, we've been looking at Predictive QoS
… this is a hot topic not only in 5GAA, but also in ETSI MEC, 3GPP
… this is seen as a key mechanism
… the idea is to enable a notification in advance on an upcoming network quality change (either better or worse)
… which enable to react depending on the use case
… [Slide: Predictive QoS in 5GAA]
… depending on the use case, the KPI to predict will change, with different type of reactions at the application level
… for instance, for a tele-operated driving, reaction might include changing route, parking the vehicles, etc
… to convey this information, the idea would be to reuse some of the existing APIs, e.g. MEC Service API
Making 5G Proactive and Predictive for the Automotive Industry
Dario: There is a stable draft in ETSI MEC for the MEC V2X API (MEC 030)
… it should be finalized in the upcoming few weeks and published as a standard soon
Multi-access Edge Computing (MEC); V2X Information Service API
Dario: this is just one functionality - stakeholders are free to define their own APIs as long they following the same REST patterns
… MEC isn't trying to define all the possible APIs of the 1000s of potential services
… I would like to propose to focus on predictive QoS based on the "infotainment use case", for which the KPI to be predicted is the data rate
… where the expected reaction would be to adapt the video quality
… the idea is to imagine a streaming video content - this is similar to the traditional video streaming, with the addition of mobility requirements
… The experiment we ran showed the impact of predictive QoS on this use case
5GAA live demos show C-V2X as a market reality
Dario: [Slide: In-Vehicle entertainment utlizing MEC over 5G Networks]
… The demo, led by Intel, Marelli, Terranet, Equinix, showed how MEC can support immersive HD entertainment for all occupants
… incl video streaming, gaming, VR, office work, online education, advertisement
… the underlying assumption is that the car is using the network and has access to edge computing capabilities
… This use case matches a promising market with predictions of $7 trillion passengers economy - with 300 hours a year spent behind a well, lots of opportunities
… [Slide: predictive QoS - reference scenario]
… Imagine a car going from one point to another; the car has a client app, which connects to an edge node
… there is a model of network characteristics mapped over the path
… MEC is used to convey these characteristics to the car
… the said info can be used to adapt network usage
… [Slide: Predictive QoS - reference scenario]
… Different use cases would be usable in different zones based on the QoS circumstances of the area
… This is import for car makers to enable or not specific autonomous driving services depending on the network
… this is thus business critical for them
… We have demos that covered 2 main concepts
… one shows the benefit of edge computing with different deployment options (e.g. how close the edge is to the user)
… the other one shows the impact of predictive QoS on multimedia delivery adaptation in a field trial in an urban environment
… [slide: benefits of edge deployments]
… The car app is communicating with the edge node, and a remote cloud node
… the car app is displaying HD video content to the passenger, as well as location-relevant information (e.g. advertizing)
… the content can be retrieved from either the edge or the cloud - the demo looks at the various level of "edge" scenarios
… [Slide: reference architecture used for IVE App Tests]
… [Slide: MEC Performance evaluation: preliminary comparative results]
… this shows difference in Round-Trip-Time depending on the server locations, esp using transcontinental servers
… The second part of the demo shows the impact of predictive QoS on adaptive streaming
… the first part of the work was to collect data on live measurements in Turin, sampled every second during a drive test
… this was coupled with a realtime emulation done by Univ of Pisa recreating network quality from the collected data
… The idea is to be able to make reliable predictions
… this was part of the Smart Road project for the city of Turin
… the emulator was fed with the data from the drive test
… then the MEC server was doing the video streaming adapted to the predicted evolution of the network
… this had a huge impact on the quality - e.g. this removed freezes
… [Slide: Predictive QoS - impact on performance, preliminary results]
… we collected data on packet interarrival time
… the more regular the video packets, the better the reception - better for buffering and playout
… both high interarrival time or high jitter have bad impact on the quality of experience
… you see a big difference on average latency, but even more so on the jitter of packet interarrival time, leading to much fewer freezes
… This concludes my presentation
… Predictive QoS is key to automotive stakeholders, esp in a set of well-defined use cases
Sudeep: thank you Dario for these great insights on 5GAA & QoS
EricSiow: in your view Dario, where are the collaboration opportunities between this community and 5GAA?
… Are there clear needs for APIs where we could help bridge the gap?
Dario: currently, MEC & Edge Computing are key strategic areas for 5GAA
… there is a working item spanning two domains of 5GAA called "MEC for Auto"
… I see possible synergies in this space - that work item is diving deeply into the topic, not only in the network side, but also for the application side
… that can be a point of contact with this group in W3C
… the work on predictive QoS is more or less done with the white paper published
… we have to ask ourselves - differentiating the actual prediction of the QoS from how to use the predictions
… making the prediction is probably not the most relevant for this group (it can be done in many ways - network, app, device)
… and then how these predictions would be used is likely more directly relevant
EricSiow: any thought how the 5GAA IPR policy might impact collaboration with other organizations?
… In W3C, all contributions are royalty-free; in cellular space, royalties are common
… has that been considered?
Dario: there is an IPR policy with well-defined procedures in 5GAA
… but I'm not the right person to give details on this
… the 5GAA secretariat would be the right group to approach to figure out how this would be addressed (e.g. via a MoU)
… I'll be happy to establish the connection if/when needed
Song: with your experience Dario, from 5GAA perspective, who will be the user for the V2X APIs? are they going to be the developers from car manufacturers? or third-party / independent developers?
Dario: the question is who will be developing the service - in automotive, this is generally a heterogeneous ecosystem
… with car manufacturers, their partners
… BMW has started to act as data center of consumers that can be used by third party / startup in a sort of app store, under the consent of the end consumer
… any of the stakeholders can be the API consumer
Song: since MEC is quite new for W3C, I would like to borrow some experiences from you to identify who will be the target developers within W3C
Dario: my presentation today was focused on automotive - but to be extra clear, MEC is not at all automotive specific
… it would be e.g. completely in scope e.g. for gaming
… for a W3C perspective, I think ideally you should look at widening the net to more use cases (e.g. VR as well)
Sudeep: thank you Dario for this presentation - we will follow up by email