 |
 |
Hi David Your points are noted. Apologies, but I do not have time to debate these issues over email. As I said, I am quite keen that we all get together to talk. So hopefully we will see you on September 20th. Kindest Regards Glenford ________________________________ From: David Lake <[log in to unmask]> Sent: 18 March 2019 16:07 To: Glenford Mapp; [log in to unmask] Subject: RE: Architectural developments for 5G? Glenford Interesting perspective and I share your frustrations! Declaring an interest here in my commercial life – I am a member through Dell of the Automotive Edge Computing Consortium (AECC) which is looking at the non-realtime aspects of Connected Vehicles currently. Pulling out specific comments and posting top-down which those unencumbered by the idiosyncrasies of the Microsoft suite will find annoying (sorry ‘bout that): “Right now we are still trying to store and process stuff in the centre of the Internet and only move to the Edge when we have to but this has to change” Yes, but we don’t have an architecture that allows us to do that by-design of 3GPP well into Rel 16. We can move the centre closer to the edge (translate – pick up the UPF and anchor point and place it down at the cell-site/pre-agg/aggregation as-appropriate) but quite frankly all that does is break mobility and keeps the same protocol choices in play. “networking, processing, storage/caching: all need to have low latency” Totally agree but today if you were to put Wireshark onto the last-mile between the eNB and the S-GW, you can see as-many-as 12 headers for the data. That is power, time and processing overhead which is insignificant for my kids watching YouTube (ermmm) “stuff” but wasteful for critical data/IoT, etc. “Heterogeneous Networking at the Edge:” Where is the edge? Could it be WITHIN the vehicle? Today it is at N6/SGi – no choice there. Do we actually need to push data anywhere? If we had a distributed data-model coupled with in-network compute/storage (i.e. make the elements the cloud) with defined policies (replication, push, security, etc) does that remove the need for the latency we think we seek? Is IP the correct protocol to try to be doing this with? “networking community, the 5G world, storage and processing people need to get together and bash out the interfaces that are needed” I’m not sure that it is just the interfaces. I think we have an architectural problem borne of the history and reality of the wired Internet (and by wired Internet I also mean today’s mobile networks which from an IP perspective are static). There are other aspects of ownership of the network attachment points which will be difficult to address – today we have clear lines of demarcation both in the stack and in the admin but much of that collapses if we start to break the siloes. I can also for-see a time when we have a single transport network with multiple service operators much like the Network Rail/TOC model (or more successfully, the 400kV and 132kV grids). “So we need to talk” YES WE DO! Happy to help put something together… David From: Next Generation Networking <[log in to unmask]> On Behalf Of Glenford Mapp Sent: 18 March 2019 15:12 To: [log in to unmask] Subject: Re: Architectural developments for 5G? Dear all I suppose I should say something as I work in the area of Connected and Autonomous Vehicles: I have been involved in building three Connected Vehicle Testbeds: one in Hendon, one in Central London and one in the city of York. These systems use DSRC WAVE or ETSI-G5 technology. We have used these testbeds to study things like latency, propagation models, backhaul and proactive resource allocation. Our observations: Low latency: if we want vehicular networks to work, you really need a low latency environment and that low latency needs to be supported everywhere. It is not enough to look at particular layers in isolation: networking, processing, storage/caching: all need to have low latency. In our view, you need to move services to the edge of the core network. Right now we are still trying to store and process stuff in the centre of the Internet and only move to the Edge when we have to but this has to change: for vehicular networks, the Edge should be the default environment. IEE: Hence, you need to provide an Edge environment, which integrates computing, communication, caching and storage. 5G does not have the interfaces for this and we are talking about something that is beyond current Mobile Edge Computing. We call the new environment the Intelligent Edge Environment (IEE). Heterogeneous Networking at the Edge: It is quite clear to us that the IEE needs to support a heterogeneous networking environment. As pointed out, you have an extremely large application space: from safety critical applications to Immersive gaming. Proactive Handover and Resource Management: We need to move to proactive handover and resource management algorithms. But to do that the system needs to know where you are, what is your likely network dwell time and where the entire local networking infrastructure is located in order to do efficient handovers and to move servers closer to the mobile user, if needed. As Jon has pointed out there are also massive security issues. I am fed up: In order to move this forward the networking community, the 5G world, storage and processing people need to get together and bash out the interfaces that are needed. But these communities still think they can ignore each other. Future Meeting: So we need to talk. In January 2017, Middlesex University held a meeting on Future Networks. It was the first time that I saw a bunch of people from the two communities in the same room! I have been wondering about holding another workshop on Future Networks this year again, maybe on or around September 20th. The workshop will be devoted to these issues. Do people think this would be helpful? Cheers Glenford ________________________________ From: Next Generation Networking <[log in to unmask]<mailto:[log in to unmask]>> on behalf of Psaras, Ioannis <[log in to unmask]<mailto:[log in to unmask]>> Sent: 17 March 2019 23:22 To: [log in to unmask]<mailto:[log in to unmask]> Subject: Re: Architectural developments for 5G? Mostly from an algorithm-land perspective, we’ve tried to approach the issues raised by John and Ning in a number of papers: - from a resource allocation angle based on markets, auctions and spot prices in [1], - trying to emulate past works on caching (static) content to caching active instances of (mobile) functions in [2]. Our rough (and rather expected) conclusion is that it’s relatively easy to find ways to optimise performance (from a resource allocation point of view) based on metrics, but it’s quite challenging to find/set these metrics :) E.g., best-effort won’t work for autonomous vehicles, but prioritising based on market approaches will be exclusive to some applications. The architectural and security issues that Jon raised are also not easy to tackle. Some thoughts (and more papers) on migrating named functions here: https://www.ee.ucl.ac.uk/~ipsaras/ddec.html<https://eur02.safelinks.protection.outlook.com/?url=https:%2F%2Fwww.ee.ucl.ac.uk%2F~ipsaras%2Fddec.html&data=02%7C01%7CG.Mapp%40MDX.AC.UK%7Cffb075e1d5474db333b008d6abbbd2b1%7C38e37b88a3a148cf9f056537427fed24%7C0%7C0%7C636885220529997262&sdata=%2FhzE4TG94P3vWNOruOD9o2jLyzYmAP1Ax1cye0j11BU%3D&reserved=0> Any feedback very welcome! Cheers, Yiannis. [1] FogSpot: Spot Pricing for Application Provisioning in Edge/Fog Computing, IEEE Transactions on Services Computing, Jan 2019, https://www.ee.ucl.ac.uk/~ipsaras/files/fogspot-tsc18.pdf<https://eur02.safelinks.protection.outlook.com/?url=https:%2F%2Fwww.ee.ucl.ac.uk%2F~ipsaras%2Ffiles%2Ffogspot-tsc18.pdf&data=02%7C01%7CG.Mapp%40MDX.AC.UK%7Cffb075e1d5474db333b008d6abbbd2b1%7C38e37b88a3a148cf9f056537427fed24%7C0%7C0%7C636885220530007266&sdata=YMTDFuWS85o5RVQRLHsRQNLmIkw%2BPQlTA8Py2oI01NY%3D&reserved=0> [2] On Uncoordinated Service Placement in Edge-Clouds, IEEE CloudCom 2017, https://www.ee.ucl.ac.uk/~ipsaras/files/cloudcom17-uncoordinated-service-placement.pdf<https://eur02.safelinks.protection.outlook.com/?url=https:%2F%2Fwww.ee.ucl.ac.uk%2F~ipsaras%2Ffiles%2Fcloudcom17-uncoordinated-service-placement.pdf&data=02%7C01%7CG.Mapp%40MDX.AC.UK%7Cffb075e1d5474db333b008d6abbbd2b1%7C38e37b88a3a148cf9f056537427fed24%7C0%7C0%7C636885220530017275&sdata=0FhVP52o%2BC9At16Zo2LFtc5rFyUUqVLDeabzINIVU6s%3D&reserved=0> On 16 Mar 2019, at 12:53, JOHN ADAMS <[log in to unmask]<mailto:[log in to unmask]>> wrote: I hope you don't mind, Ning, but I have forwarded your comments on my questions to the group. John ----Original message---- From : [log in to unmask]<mailto:[log in to unmask]> Date : 16/03/2019 - 11:41 (GMT) To : [log in to unmask]<mailto:[log in to unmask]>, [log in to unmask]<mailto:[log in to unmask]> Subject : Re: Architectural developments for 5G? Hi John, David: Regarding edge computing, well to put in simple words it is to put boxes (to be more precise - network functions) at the edge in order to achieve localisation. There are various 5G-oriented apps that conceptually require this feature, but certainly things need to be optimised in particular by taking into account delay and response time requirements as well as scalability issues etc.. For instance the more you move MEC to the edge, the shorter delay you can gain but the service coverage of each box (or network function instance) become more limited. In the opposite direction of course you can't push the box too deep into the network as this might affect delay and scalability. Coming to AI running at the edge that's even a wider topic, it can be used either for autonomic network resource management, or for specific OTT 5G applications. In both cases IMO the biggest challenge is how to achieve distributed AI based on edge computing rather than relying on centralised computing infrastructure. Coming to David's comments, just to clarify that (1) ITU 2030 and Richard Li's activities are positioned BEYOND 5G era, and (2) the focus is in the area of future Internet rather than the evolution of "x-Gs" so they are not positioned to be something like 6G. Regards, Ning ________________________________ From: JOHN ADAMS <[log in to unmask]<mailto:[log in to unmask]>> Sent: Saturday, March 16, 2019 10:23 AM To: [log in to unmask]<mailto:[log in to unmask]> Cc: Wang, Ning Prof (ICS) Subject: Re: Architectural developments for 5G? Thanks David, It seems to me that, if you take some visionary statements into account (there are many, ranging from automated cars to AI-based IoT for your home), questions/ studies like what I am asking about are needed rather than some of the simplistic statements that are going around that seem to assume the addition of edge processing is merely a case of adding the right number of boxes to your network. The possibnle scale implications are huge. John ----Original message---- From : [log in to unmask]<mailto:[log in to unmask]> Date : 16/03/2019 - 09:54 (GMT) To : [log in to unmask]<mailto:[log in to unmask]> Cc : [log in to unmask]<mailto:[log in to unmask]> Subject : Re: Architectural developments for 5G? Hello John, Have you spoken to Andy Sutton about this? I recall he told me about 5G requirements on the architecture that he and Richard Li worked on. Also, the new-ish Network 2030 initiative started within ITU may be looking at these questions, even though it’s not explicitly on 5G. I’m copying Ning to see if he can add to this, or contradict me ... Best rgds, David On 15 Mar 2019, at 17:26, JOHN ADAMS <[log in to unmask]<mailto:[log in to unmask]>> wrote: Dear all, Just a thought for today. An interesting talk last year at Coseners on the realities of 5G. Is the research community looking at local processing needs (or, rather, future needs) for applications that develop on the back of 5G? By 'local' I mean within the decision time frame required by the application and hosted somewhere on the network and replicated probably at or near the edge. The questions I have in mind are practical realisations that scale. There are several views on what that level of scale might evolve towards and what latency requirements of applications might drive the preferred solution and I don't wish to comment on every scenario. There are some open questions (I would guess) on an architecture for best scaling. Regards, John ________________________________ To unsubscribe from the NGN list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=NGN&A=1<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jiscmail.ac.uk%2Fcgi-bin%2Fwebadmin%3FSUBED1%3DNGN%26A%3D1&data=02%7C01%7CG.Mapp%40MDX.AC.UK%7Cffb075e1d5474db333b008d6abbbd2b1%7C38e37b88a3a148cf9f056537427fed24%7C0%7C0%7C636885220530027289&sdata=XI%2FuyYzY7B0GJSdJMDRmwheleqbJQAUe142pDWGdkRw%3D&reserved=0> ________________________________ To unsubscribe from the NGN list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=NGN&A=1<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jiscmail.ac.uk%2Fcgi-bin%2Fwebadmin%3FSUBED1%3DNGN%26A%3D1&data=02%7C01%7CG.Mapp%40MDX.AC.UK%7Cffb075e1d5474db333b008d6abbbd2b1%7C38e37b88a3a148cf9f056537427fed24%7C0%7C0%7C636885220530027289&sdata=XI%2FuyYzY7B0GJSdJMDRmwheleqbJQAUe142pDWGdkRw%3D&reserved=0> ________________________________ To unsubscribe from the NGN list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=NGN&A=1<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jiscmail.ac.uk%2Fcgi-bin%2Fwebadmin%3FSUBED1%3DNGN%26A%3D1&data=02%7C01%7CG.Mapp%40MDX.AC.UK%7Cffb075e1d5474db333b008d6abbbd2b1%7C38e37b88a3a148cf9f056537427fed24%7C0%7C0%7C636885220530037289&sdata=AGbgFe5RkSHmWD9FDoy2fF869WeDCPGuiA%2FlYfYoIsI%3D&reserved=0> ________________________________ To unsubscribe from the NGN list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=NGN&A=1<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jiscmail.ac.uk%2Fcgi-bin%2Fwebadmin%3FSUBED1%3DNGN%26A%3D1&data=02%7C01%7CG.Mapp%40MDX.AC.UK%7Cffb075e1d5474db333b008d6abbbd2b1%7C38e37b88a3a148cf9f056537427fed24%7C0%7C0%7C636885220530047298&sdata=fus5bAdhFID2W8nYPnOF49KNjlXhBnV4VTjERV7n9Os%3D&reserved=0> ######################################################################## To unsubscribe from the NGN list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=NGN&A=1