 So thank you for inviting us and you know for us the magma community is a new one so we're excited to be here and get to know it better. The project I'm going to talk about is a research project that's a group of us at UC Berkeley working and collaboration with Shadi Hassan who's from Facebook and just a very quick and also I should mention Ji Hong is the PhD student leading the work and he's also going to chime in towards later in this talk. So just a quick outline what I'm going to cover you know this is going to be pretty high level and quick since we have 15 minutes just tell you a little bit about why we're trying to change or develop a new cellular architecture then talk a little bit about the overall approach we're taking with this architecture we call it cell bricks and you'll see why in a little bit and then Ji Hong's going to take over and talk a little bit about the prototype we've been building on top of magma and so with that you know what are we trying to do or what's the motivation for this research project quite simply we're trying to grow the tent in cellular I think you know we all know that a market in which you have a lot of competition is a good one it's good for consumers it's good for innovation good for the technology we also know that the cellular ecosystem is perhaps not the best example of a market with lots of competing providers in fact in the US the top three providers have over 98% of the user subscribers and so quite simply what we want to do is try and enable an ecosystem in which you can have lots of competing cellular providers so infrastructure operators and our goal so to enable this is to lower the barrier to entry for new entrants we want new cellular infrastructure providers to be able to enter the market more easily and to compete more easily with large or small other infrastructure providers and so the key we if we want to if we say we want to lower the barrier to entry we think the first step or the most important piece that we have to enable is to make sure that a cellular infrastructure provider with a small to a mid-sized footprint can play so what we mean by this could be for example a city government or regional business or an enterprise or university campus could set up you know even just one cell tower or maybe 10 or 100 and be a viable cellular infrastructure provider so they should be able to participate as equal citizens within the cellular ecosystem and in just focusing on the technical questions there are lots of ecosystem questions but even just looking at the technical architecture of the cellular infrastructure we think this is actually hard to achieve with today's architecture and at the highest level the reason for this is that the architecture we have today relies very heavily on these pre-established trust relationships or contracts and in-network coordination and these mechanisms are pretty heavyweight as a technical foundation so just to make this more concrete you know the three biggest examples probably of where we build on trust or in-network coordination are first very simply when you have a user or UE when you attach or you connect to the cellular infrastructure you attach to its MNO or network that you have a trusted relationship with so you connect to a network with which you have a contract saying that they are your provider so everything we build on top like authentication and accounting is built on the assumption of trust between the user and the infrastructure provider likewise when you have handovers when you have a user that's moving between cell towers within an MNO the fact that the user is enjoying seamless mobility that their TCP connections stay open that their applications are seamless as they're moving between towers is because within the network these towers are coordinating to make sure that that handover is seamless so again we're relying on in-network coordination and of course when you're roaming when you're accessing some other provider's network not your home provider the only reason you can do that is because that roaming the provider's network that you're roaming in has set up an agreement or built trust with your home operator you cannot just walk up to a random infrastructure provider and use their their infrastructure and these reasons when we start to think about shifting the cellular ecosystem to one where you have lots of providers potentially small scale providers like a mall or an enterprise campus this assumption that you're going to pre-establish trust doesn't scale so for example if I just took the previous picture and now said okay I have lots of smaller providers the assumption if you want broad coverage you're going to say that the user signs up with an MNO but now if we want broad coverage we're going to say that MNO has to have these contractual legal agreements with a whole number of other MNOs and that simply doesn't scale asking a new entrant to sign a thousand contracts with other providers is a very high barrier to entry likewise if we think of seamless mobility and we say we have a large number of infrastructure providers that you then what that means is that as a user is mobile we're quite frequently switching between not just towers but between administrative entities and administrative providers and here again having these providers coordinate to do seamless handovers would be overly heavyweight because again it requires these pre-established agreements between operators and you know one might ask what what if you have an MNO architecture something like Google Fire does that change the game does it make it simpler to have lots of large smaller scale providers and the answer is not really because all that having an MNO in the picture changes in today's world is the user signs up with the MNO but we'd still be asking the MNO to go out and set up established trust agreements with a large number of other providers and again that doesn't scale and so Google Fire for example today has two or three of these trust agreements in place not thousands and so given that context and given where we wanted to go which was to enable lots of competing providers the goal we have in Cellbricks is that we want to allow a user to consume cellular access on demand from any available infrastructure operator and any meaning it can be a small provider or a large provider it can be a trusted operator or even an untrusted operator so it's really a user should be able to walk up to any area whatever infrastructure is available they should be able to use it but importantly we want to enable that without requiring that providers have to establish trust beforehand or do any kind of heavyweight in network coordination and so just in terms of the players here how do we see this working we build on top of the MVNO idea we call an MVNO broker I think I believe this is actually terminology we borrowed from Magma and the way we envision this working is that a user is going to sign up with a broker just like they do with an MVNO today but the one shift we're going to make relative to an MVNO architecture is that we're going to say that a broker or an MVNO is going to on demand be able to leverage any infrastructure operator even though there's no trusted relationship with that MNO so we're going to ensure you can do things like billing and seamless mobility but we're going to enable that without requiring the broker to trust the cellular infrastructure operator in order to do that just a very high level what we end up doing is we refactor functionality that exists today in today's cellular architecture so if we look at today's MNO architecture all the functionality the data plane the control plane support for mobility and support for user management so your HSS subscriber database how you do accounting and billing all of that is concentrated in the MNO if we look at the MVNO architecture it doesn't really change the what the the network the functionality we put in the network instead the MVNO takes on some of the user management or the customer facing aspects of user management what we do with cell bricks though is quite different one we take all aspects of user management the subscriber database accounting billing authentication completely out of the network and located in the broker and the other major change we take is we take support for mobility so warming and handovers out of the network and into the user device so as you can see that's quite a refactoring but also taking quite a bit of functionality out of the network and I should mention we don't change the ZAN in any way all of these changes that would change us to the cellular core what are the potential benefits of this you know initial motivation and what was driving us was to lower the barrier to entry for new operators but in this process what we also think you can enable is more efficient use of infrastructure because now you can set up set up cellular infrastructure and it's not just going to serve the subscribers of one MVNO or one service provider it can service any user and so with especially with the densification problems that 5G brings we think this ability to make efficient use of infrastructure is important and finally just simpler infrastructure because we've taken a lot of the heavyweight machinery around mobility and around authentication and accounting out of the network so how do we do all this the two main challenges one is how do you do secure attachments in billing when you don't have mutual trust when you're connecting to infrastructure that you cannot assume is trusted and the second is how do we do this seamless mobility if we're not relying on in network coordination so just to very quickly give you a sense of what this looks like the way in which let me start with secure attachments and billing the way this works is that when a user goes up to an MNO the user is going to send a message that says something like I'm user bob my broker is Google Google Fi and the MNO I'm trying to get access from is MNO 3 the MNO is going to forward that to the broker the broker is going to check it and if it all looks good it's going to authorize the MNO to say okay I am actually Bob's broker and here is authorization for you to service Bob and they can exchange course parameters or billing parameters in the process so we make all of this secure is by leveraging public key encryption so this is a bit of a shift from how cellular networks cellular networks today do this with shared keys we're instead going to use it with public keys but all the machinery we're using is exactly how any online transaction works how any credit card transaction or when you use AWS or when you use any online service we're reusing exactly the same authentication mechanism and so what we can get now is three way authentication between the broker the MNO and the user that is cryptographically secure and cryptographically verifiable so you cannot have for example a broker come back later and say I didn't authorize that transaction the MNO actually has proof that the broker said yes please go and service my user so this is just secure attachment having evidence and securing that you're serving a valid user that belongs to a particular broker and that the MNO was actually the one the user wanted to connect to in order to do accounting we have the MNO send its usage statistics so the foundation for billing is that we can accurately account for the resources used and to do this we have the MNO periodically tell the broker what sense statistics of what resources the user used and so the broker is expected to pay the MNO accordingly but the broker needn't trust what the MNO told it and so in addition we have using hardware support on the UE we have the UE send statistics about the resources it believes it has used and using these statistics both the broker and the MNO can build up a reputation system so that brokers can over time favor certain MNOs that have better quality or that have better billing terms or so on so that there was attachments and billing at a very high level in terms of mobility seamless mobility just to dig a little bit deeper into what the problem is here today with handovers we assume that the network is coordinating to make the users mobility experience seamless what they're really doing is ensuring that a user's IP address is staying unchanged and if your IP address is unchanged then your TCP connections stay unchanged and so your application sessions persist and are fine we can't really assume this anymore in an ecosystem where we say we have lots of smaller providers because every time you're switching administrative boundaries you're going to change IP addresses and trying to preserve an IP address across administrative boundaries would be just way too hard here what we do really is leverage the fact that actually solutions to this problem have emerged from industry already there are a number of modern transport protocols like multi-path TCP or quick that are now these are ITF standards these are in every operating system they're available widely and what these transport layer protocols do is they handle mobility at the layer above IP or layer 3 and so now you can have a TCP connection or sorry a transport layer connection that is fine even if your IP address is changing underneath you and so we can have a user switch towers and be switching their IP address but your higher layer connection and your application is just fine with that so in some sense we actually don't have to solve this problem because other people have solved it for us already and so effectively what we're doing this is moving mobility support out of layer 3 and out of the network and into the transport layer and layer 4 and so with that just a very quick recap of the architecture we are taking we're trying to lower the barrier to entry for smaller scale or mid-scale providers so that we can have an ecosystem with lots of providers the way we want to do this is to allow a user to consume access on demand from any provider including potentially untrusted providers and the technical pieces to do this it turns out actually pretty simple it's moving authentication and accounting out of the network by moving to a model that is very much what online services do today with public key based cryptography and relying on layer 4 support for mobility instead of layer 3 with that we're going to switch to talking about we've prototyped the system and Ji Hong was going to talk a little bit about what we've built on top of magma so Ji Hong can I yes hi I'm Ji Hong today I'm going to talk about briefly talk about our prototype implementation to evaluate the end-to-end correctness of our cell brick design as well as some preliminary evaluation results so this diagram is the prototype we mainly consist of three components the first one is USRP and then USRP is essentially a software defined uh silver next one it's a software defined uh software defined radio devices that can provide that we use to provide radio connectivity between the UE and the EnoB because as Silva mentioned we require no changes to the RAN so we don't need to modify anything on the USRP and the second component we use is SRSLTE which is an open source software stack that we use for our UE and EnoB and know that because cell bricks require no changes to to our EnoB so essentially we keep that part unmodified and then silver next one and then the last one will be magma because the focus of the day we also leverage magma in our prototype specifically we use magma's HS gateway and we extend it as the core network and then we extend it to support the three way secure attachment that we just mentioned and also we use magma's orchestrator and we add a service called broker D which is responsible for the broker services in the cell bricks uh next slide please with with our prototype we are able to evaluate some key performance matrix specifically we measure the end-to-end latency of our attachment protocol and the goal here is to understand the relative performance of our secure attachment protocol compared with standard attachment and in our test step we essentially have the UE EnoB and access gateway in the local machines and then we vary the location uh we vary the location of our orchestrator which consists of both the subscriber DB for standard attachment and the broker D for our secure attachment and in this part we have uh we can essentially decompose the attachment latency for both schemes and there are I would not go into detail there are many two takeaways the first thing is that the actual processing mainly the crypto operation our secure attachment require add to only less than two millisecond end-to-end latency and secondly uh when you uh because cell bricks in our attachment protocol we make sure there's only one RTT between the uh between the telco and the broker while in standard attachment there are two RTT therefore as you can see on the right side of this plot when we deploy the orchestrator on the on the cloud our attachment actually has less much less attachment latency because of one less RTT uh next slide please and beyond just uh evaluation on the test bay we also try to perform emulation over over internet specifically what we do is the next bullet point is next what we do is that we try to perform emulation over existing cellular and wireless networks the I the goal here is that we want to understand the performance of real applications under real world conditions with a real world deployment so we picked four representative applications IPer video streaming web page loading and voice over IP and then what we do here without going to detail in high level is that first of all we need to detect handover we do so by logging and inspecting the baseband messages that uh modem receives and once the handover is detected we need to emulate IP changes because as mentioned today it's during handover your IP changes your IP usually stays unchanged so we actually need to emulate IP changes and we we do so with an injected latency and this latency is to account for the extra latency due to the attachment and the third step will be once the IP change once the IP changes happen mpdcp will react to and maintain the connection and know that mpdcp had a nice nice feature that it basically had the same sucky api towards the application so basically don't need to port any of the application logic and next slide please and with this emulation uh we were able to show in this table show us uh the key performance tricks for all four applications without going to detail the conclusion here is that more a host driven mobility in cell bridge actually incurred a negligible performance impact compared with the baseline in it's between across four applications it's between minus 1.6 percent to 3.1 percent compared with the baseline this indicates that our host driven mobility methods in cell bridge not only allow allow a more flexible and and simpler network you also have very competitive performance in terms of the performance either as received so this indicates that host driven mobility is actually a promising direction to explore further yeah that's all yes so just very quickly in conclusion you know we started this as a research project thinking let's just think about this clean slate you know this is what we want to enable not worry about whether it's deployable or backward compatible it turns out what we are finding is that actually the pieces we need to enable this are really pretty modest it's embracing publicly based authentication and doing three-way authentication secure counters and device hardware and really embracing or adopting mp new protocols like mp tcp and quick all of these seem to be well within reach and as young just mentioned we've been building a prototype and doing real world measurements this is something we continue to build on as well as extended for features like privacy or differentiated quals and so on and with that that was what we had thank you and I'm happy to take questions