 Okay, well, thanks for the introduction. This is going to be a presentation about TPRS Edge, UMTS, HSPA, and other acronyms that exist in the cellular data communication world. Let me start with sort of a rhetorical question. How many people in this room have never used any of these technologies? Ah, okay, that's one, one, one, okay. The point that I'm trying to make is that, sort of, I mean, this is not a presentation about some cool hacks or some exploits or some security issues or anything like that. It's just a talk about how some technology works. And I think the last time that I remember such types of talks was probably something like 10 years or longer ago at the CCC, where we had something like TCP IP introduction, right? And, and this is probably the same kind of talk, but for entirely different protocols, which are not any newer, at least some of them are not newer than, than these talks that we had 10 years ago or something. But I think it's, it's sort of a mystery and a problem why there is technology that's so widespread, there are, there are literally more than a billion terminals out there on this planet that speak at least one of the protocols outlined in this presentation. And yet there are very few people who actually understand how this works if you go beyond the user traffic. Of course, well, if we, if we use a mobile phone to transfer internet data, TCP IP data, then of course everyone understands the TCP IP layers on top. But what about the, I don't know, five to seven, maybe 10 layers below that, you know, who, who understands them and who does something about them. Okay. Well, let's start with a slightly historical excursion, CSD, I'm not sure how many in this room remember what CSD is. It's a circuit switch data. And it was the first technology in digital cellular telephony systems to transmit data between terminals, not voice. So GSM is the first, to the best of my knowledge, it's the first digital cellular system. It was developed in the 1980s. That's something you always have to keep in mind. This goes back a very long time. GSM has first been deployed around 1990. And it's a pure circuit switch technology. So in, if you're, if you're correct or if you're true to the word, then GSM does not have any data capabilities except a CSD. You'll get to that. Circuit switch means it's like a voice call, you dial a number, you establish a connection and then you exchange data. So CSD sort of emulates the behavior of what people used in the 1990s, like modems on the public telephone network. And the data rates that you can achieve using CSD are sort of funny today. And it's 2,400, 4,800 and so on, bits per second. It's not megabits or kilobits, bits, whole bits, not half bits or quarter bits. I'm mentioning this because GSM on the lower layers has lots of quarter bits. Okay. Now, CSD is still supported by some operators today, but I'm not really going to cover it for the remainder of this talk. This is just, this is where all this is coming from. Circuit switch, it's not packet switch, that's sort of the important thing to notice. Then there was HS CSD. Not sure how many people remember that. It's channel bundling CSD. So imagine CSD is like you have an analog phone line and two modems on the ends and you communicate and now you have two or three or four of these phone lines and you get the aggregate bandwidth of them. It's not very surprising. So there was the option to run 38.4 kilobits and 57.6 kilobits, both very popular data transmission rates in analog telephony systems using modems. So HS CSD was able to deliver those bandwidths over GSM. However, it was very expensive because, well, if you occupy four circuits in a circuit switch system, you have to pay four times the amount of money, of course. And also you get four times the amount of load. So yeah, I think it was popular for a very short time. I still have a couple of phones that support it, but it's dead ever since GPRS came around. Now GPRS, the General Packet Radio Service, was specified almost a decade later than GSM and first deployed in a production network in 1999. GPRS is not an extension of GSM, really. It is a separate network that just shares the same TDMA structure, the same modulation, the same channels, the same bandwidths and so on. But logically it's really an entirely different network and your phone can register to GSM but not to GPRS and vice versa because those are two independent activities and two independent transactions that end up at different units in a network. The reason for this design is that GSM networks had already been deployed for about 10 years before GPRS came around and now the engineers had the task of implementing a packet radio system that can reuse as much as possible on the radio transmission side, the same modems, the same TDMA structure and so on. But add these services without making too many modifications to the very well-working and stable circuit switch side. So this is why there is a different infrastructure for that. The base stations are the same but anything beyond the base station is different in a GPRS network. It's packet switch, not circuit switched, so it's the first cellular technology, a digital cellular technology that allows you to send packets where you don't need to allocate an entire circuit of dedicated bandwidth for your data session. The bandwidth was around 56 to 114 kilobits per second. You cannot really say that very clearly because it depends on the exact multi-slot class support of the mobile station and the base station and various other aspects. So it's in that range typically with most of the phones. It's available, it was and is available virtually anywhere on the world except Japan and Korea because they had different 2G, 2.5G systems. Now edge, many people talk about edge. Edge means enhanced data rates for GSM evolution. You will notice that evolution is an extremely important term in cellular technology because everything is always either evolved or evolving or evolution. So technically speaking, edge is a superset of what people think it is. There is edge consists out of EGPRS and ECSD but ECSD almost nobody knows and most people just think of EGPRS when they say edge, well actually they think of edge but they mean EGPRS. EGPRS now means we use the EGPRS network but we add a little bit in terms of a different modulation scheme and in terms of slightly different channel coding and we get higher bandwidth than the old system. It uses the same radio channels, the same bandwidth, the same time slots, everything is like GPRS but it uses 8 phase shift keying, 8 PSK instead of the Gaussian minimum shift keying that GSM does. The no real change is to any of the higher protocol layers except some small information elements where you signal the availability of this system, otherwise it's entirely the same. Most phones support something like 236 kilobits per second and again like GPRS it's available almost anywhere in the world. Now UMTS, I'm just going through the history first and then we look more in detail into the individual systems. Well, there are obviously multiple typos in this slide, I apologize for that. It's the universal mobile telephony subsystem, not sub, just system. It developed around 96 to 99. So once again it's sort of developed at the same time as GPRS but for UMTS since it's a completely different system people needed new phones and so it was expected to take a longer time to pick up and it was a new, more expensive technology so it was sort of rectified to develop GPRS and UMTS in parallel. First commercial deployment also was three years after the first commercial deployment of GPRS networks and UMTS in its core specification actually also doesn't really have that high data rates. It's a 384 kilobits downstream and downlink to the phone and 128 kilobits on the uplink. It's not all that exciting if you think about it. It's an entirely new system. It's not a logical sort of extension or enhancement of the previous systems but it's an entirely new system. It's based on a modulation scheme called Wideband CDMA where CDMA is Code Division Multiple Access and especially in the US people always say it's a WCDMA network which is correct to some extent but there are many other WCDMA systems which are not UMTS so it's sort of an over-generalization. It supports circuit switched and packet switched services. So in UMTS from the very beginning they were looking at developing a protocol and developing a system that can work for both circuit switch services and for packet switch services unlike GSM which was entirely circuit switched and then they had GPRS which is entirely packet switched and so on and so on. The fixed part of the network heavily uses ATM over synchronous digital hierarchy systems so the lower layers of anything that does not go over a radio interface as you will see in the next couple of slides is almost always ATM based. So you can see it's developed in a community where people thought OSI protocols are a great thing and ATM are a great thing and all this strange IP and either that stuff that other people do is sort of amateur crap. Okay, now HSDPA is introducing a couple of new downlink channels. It's high-speed downlink packet access. It's the HSD-SCH, the high-speed downlink share channel. It was added in UMTS Release 5. The specifications are released in releases and they are numbered up to 98. They were based on the name of the year so there's Release 98 or Release 99 which are released in the respective year of the calendar but the further numbering does not necessarily correspond to any year. Some other physical channels that are sort of below this new channel and it introduces adaptive modulation up to 64 QAM so relatively complex modulation schemes and initially permitted 3.6 megabit second downlink and it also increases the uplink a slight bit from 128 to 384 but it's also not that impressive. HSUPA is actually called EUL, Enhanced Uplink, HSUPA is a marketing term from Nokia and it uses similar techniques as HSDPA but in the uplink direction, yeah, 5.76 megabits is sort of the... Then there's HSPA+, which is the latest extension to those standards, which was added in Release 7 of the specification and it permits up to 84 megabits in downlink and 20 megabits in uplink by using MIMO techniques QAM64 and also by combining actually two cells so a single phone can use two cells simultaneously in order to extend the band with beyond what a single cell could provide. It's a theoretical maximum of 186 megabits which is theoretical of course but nonetheless it's fairly impressive what they managed to squeeze out by evolving the UMTS technology further and further without going into LTE the next one around. Okay, now let's look at these individually in a bit more detail. At CSD, I'm skipping, it's not really all that interesting. Let's look at our standard diagram of a DSM and GPRS network. We have our mobile phones over here on the left hand side which connects over a radio interface called the UM interface to a device called the BTS, the base transceiver station. From there it's backhauled over typically an E1 line running a set of protocols called ABIS to a device called the BSC, the base station controller which connects to something called the PCU, the packet control unit which then in turn uses another E1 line with another set of protocols called the GB interface to the serving GPRS support node, the SGSN on the bottom here. The SGSN is taking care of mobility management, encryption, compression and all kinds of things for the actual data that gets transmitted to the phones over here. The authentication is handled by the SGSN in GPRS and the SGSN then connects over a GN interface to the GGSN. The GGSN is the gateway GPRS support node and is where the IP packets are the tunnels terminate towards the internet. So those entire nodes in this network establish transparent tunnels between the GGSN and the MS, the mobile station, the phone on the other hand side. The GGSN is the only IP only device in the network. Everything else is not really, doesn't really deal with IP. There's just some user data which we encapsulate somehow and we've wrapped it enough so we don't really have to touch the IP, needs to be properly wrapped to be able to transport it over our ATM and E1 and SDH and whatever other technologies. So if you look at the control plane stacking, what's the control plane? Well, the control plane is anything that's not your user data. Control plane is about setting up connections, authentication, taking care of handover, mobility management, all these kinds of things, that's the control plane and the user plane is where you actually have your IP data, your internet data that you want to transmit. So the control plane, let's first explain the diagram a little bit. We have the individual nodes listed here. There's the MS, the mobile station, it's not Microsoft, it's the mobile station. It may run an operating system from Microsoft though. There is the BTS and the CCU, the circuit control unit, which is the node represented here. There's the BSE, the base station controller and the packet control unit, the SGSN here and for the control plane, I didn't put the GGSN here but for example the HLR, which is where your subscriber data is stored and also involved in, for example, it lists what kind of services you have subscribed to or not this kind of data is stored in the HLR over here. Now the dashed lines are the individual interfaces between those nodes and the interfaces have always these strange names like UM, ABIS, GBG, Z and GN and all these small names. Now as you can see, there's a physical layer, the physical layer exists over the radio interface between the phone and the BTS and then we have other protocols on top. There's a MAC, an RSC and LLC protocol. The two lower ones, the medium access control and the radio link control, RSC and MAC layers, they terminate in actually the PCU here, the packet control unit and they are transparently passed not only over the radio interface here, this is your only radio interface, it's the UM interface and this is typically an E1 type line here on the back hall and they are transparently passed over here. They terminate in the packet control unit which then re-encapsulates the payload which is LLC logical link control protocol. It gets encapsulated in a new protocol called BSSGP, the base station subsystem gateway protocol, which gets then encapsulated in the NS, I think it's network service protocol, which then gets put into frame relay which gets put on top of an E1 line and then it gets backhauled to the SGSN, that's a sort of a centralized node in the network which then implements this entire same stack here, E1 with frame relay with NS with BSSGP but then also terminates the LLC layer which is coming directly from the mobile phone and then on top of that we have two sublayers called GMM, DPRS mobility management and SM which is not what you think it is, it is session management and all these terminate here basically, there's nothing that doesn't terminate at the SGSN in the control plane and then towards, for example, oops, sorry, that's the next slide, towards the home location register which is like your subscriber database, there's an entirely different set of protocols usually referred to as SS7 but more specifically it is an E1 line with MTP level 2 on top, MTP is message transfer part, MTP level 3 on top, SCCP on top, T-CAP the transaction capabilities application part and then map the mobile application part and those exist on completely different interfaces so what you can see from this is that each and every interface has a completely different protocol stacking, these protocols are independently specified, they're most oftenly specified by different working groups, you can see when you read the specs you can clearly see it's written by different people, they do not use the same encoding, they do not use the same information elements and so on so each of those protocol stacks is an entirely different beast that you encounter depending on the interface, now this is the control plane, now I'm going to talk about what happens on this control plane, just in another slide I'm just going to go through the user plane to show you how deep the stacking actually is, now let's assume you make your new smartphone, you do an HTTP request that gets into TCP of course, gets encapsulated into IP which then gets encapsulated in my favorite protocol, it comes straight out of Star Trek, it's called the sub network dependent convergence protocol, the SNDCP, you have to, Scotty you have to remodulate the sub network dependent convergence protocol, it wouldn't, we have fluctuations in the BSSGP, no, so the SNDCP, then the LLC, then the RLC, then the MAC and then we finally can transmit it and almost all of them get transparently passed through the BTS, some of them then terminate at the packet control unit here, another couple of them on the STSN and finally the user data gets passed over to the GGSN where it can enter, how can I say, the strange world of IP based networks, so when you're thinking about all your, I don't know, web vulnerabilities or whatever kind of higher level application level stuff, you're up here and there's lots of other stuff which a lot of people don't really look at in detail, below. Okay, now what are these individual layers, medium access control, sort of, I mean almost every physical layer has a medium access control layer, I don't need to say much about that, these numbers that you can see, like 44.060, I put them in here for reference, so if you want to learn more about these respective layers, this is what you type into Google or your favorite search engine, or you go directly to the 3GPP website and look up this specification. It's on top of what's called a PDTCH, a packet data traffic channel, it's a physical channel on the interface, and on top of Mac you have RLC, which takes care of, radio link control is the name, yeah, sorry, there's too many typos in those slides, I apologize, I will fix that immediately. The resource allocation, like which phone gets how many time slots and gets which amount of bandwidth and so on, is always determined by the network of course, right, it's not like some random arbitration or like you have an Ethernet where you have something like CSMACD and everyone can just try to send packets at any given point in time, no, no, no, this is not an unorganized Ethernet network, it's a very well structured, well thought through professional communications protocol, and because it's so professional, of course, it cannot rely on, I don't know, human readable message definitions, the messages have to be specified in a syntax in an abstract, well, no, actually not in an abstract syntax, but in a parsable machine readable syntax, and because there weren't enough of these syntaxes so far, they invented something called the CSN1, the concrete syntax location, which is very different from ASN, and the abstract syntax notation, so it's much more concrete in a sense, in the sense that, you know, in ASN1 you have the syntax and you have the encoding rules, and that's not very concrete, so in CSN1 there's no separation between the two, there's only one possible encoding and that's part of the specification. By the way, specification costs something like 10 euros and it's only available printed and you have to order it from France and have to do a wire transfer to the bank account, and it's quite funny, I mean, I think the amount of overhead they have for charging these 10 euros is sort of, well, okay, now the GB layers, the GB is again the interface between the BTS and the BSC slash PCU, there's the network service layer specified in 0816, which sort of maintains a possibly redundant set of physical links on top of frame relay, it does things like failover and load sharing among multiple links because sometimes one E1 line is just not enough, you need multiple of them, and then you need to somehow share the load. It's originally specified over frame relay, but sometimes actually people put a Cisco router behind it to encapsulate the frame relay in IP, so then you have the entire stack that I indicated, where is it, here, well, something like this stack up to NS in frame relay in some other encapsulation in IP and some other layers on the bottom, but then some other people also came up with the bright idea of putting NS directly into IP, well, sort of via UDP, so you can skip the frame relay part if you want. Now, on top of that, there is BSS GP, which maintains things called BSS GP virtual connections, BVCs, and each base transceiver station in your base station subsystem now establishes one logical connection, it's called a BVC, BSS GP virtual connection between the STSN and this BTS. BSS GP also implements flow control, and it's actually a hierarchy of token bucket filters, which are sort of encapsulated into each other, so there is one flow control for all the data going to one BTS, because of course you have an E1 link and at some point you might saturate that, so you need to have flow control on the entire link, and then you have flow control for each individual mobile station that connects to that BTS, and then you can have individual packet flows inside contexts of each individual phone which again have these flow control, so you have this hierarchy of three levels of flow control that make sure you're not flooding the BTS with packets coming from the high bandwidth internet which want to squeeze through the tiny radio interface between the phone and the network, because you have your bottleneck here, that's typically your bottleneck is the radio link here, but the packets of course come in from the internet over here, and somehow you need to make sure that you're not flooding that link in a completely unfair or undeterministic way. BSS GP is extremely inefficient if you think of it in terms of overhead, because each and every BSS GP message which is each and every of your TCP ACS, let's say you have a TCP ACS packet, it's like 20 bytes TCP header plus 20 bytes IP header, plus a little bit of S and TCP header, plus a couple of bytes LLC headers, plus a frame check sequence of 32 bits at the end of LLC, plus the BSS GP header and the BSS GP header now includes the full IMZ, the full radio access capabilities information element, which can easily be something like 30 bytes. So in the end, you want to send a single acknowledgement back to your phone. And on these interfaces here, you might easily say, see 100 bytes or even more for that for the single acknowledgement. So that's just something to keep in mind in terms of efficiency. Okay, now on top of that, we have my favorite, as I said, S and TCP. It, well, S and TCP is too many typos in here. LLC is between S and TCP and the lower layers. Let's talk about LLC first. It supports acknowledged and unacknowledged mode, but normally for IP communication, it's mostly used an unacknowledged mode. LLC actually, you might have heard in different contexts. I think LLC goes back to IBM mainframes, actually, where in S and A networks, there were LLC was one of the protocols used in those networks. It's though a different sort of a specific variant for GPS networks that we have here. The encryption of GPS happens on this LLC layer, and as well, check summing of the frames also happens on this layer. S and TCP now is on top of that, and it's a general purpose encapsulation for the packet data. Because when TPRS was designed, once again, remember the sort of, well, mid 1990s. I mean, a lot of people are already using the internet, at least that's how I remember it. But in the cellular industry and in the professional communications industry, they were still thinking of X25 and OSI protocols and all the marvels of X400 and all those things. And it was designed in a way that it can transfer IP as well as other protocols such as X25. So you can actually have X25 over GPS in accordance with the specifications. If we actually look at IP today, the S and TCP also takes care of IP header compression and also possibly V42 payload compression. So there can be arithmetic compression of the data built into this level. If you look at the control plane, what is GMM? GMM is mobility management, which, well, is like mobility management. If you know about that, then it's easy to guess what it does. It doesn't use the same thing. It's responsible for things like routing area update. This basically is your phone telling the network where it currently is located. Things like attach and detach when you switch on and switch off your phone or enter airplane mode or leave it. It also does take care of authentication, which is the same authentication method that GSM uses, using the same keys, by the way, and the same algorithms. It also reallocates the temporary identifier. GSM has a TimZ, GPRS has a P, TimZ. It's also something important. Anything that's in G... If you look at GPRS, everything has to start with a P. So you have the TCH, the traffic channel in GSM, and you have the PTCH, the packet traffic channel in GPRS. You have the BCCH in GSM, and you have the PBCCH in GPRS because it's a packet broadcast control channel. It's also a provision for delivering SMS over GPRS. If you look at only the layer 3 transactions on between individual nodes for performing a routing area update, it looks a little bit like this. First, you have your layer 1 establishment, then you establish the RLC MAC layers, and then on the LLC level, you encapsulate the GMM messages, like routing area update request, gets sent from the phone to the SGSN, oops. Then the SGSN behaves a little bit like the MSC in GSM networks. So it can do, for example, identity request, it can ask the phone about its IMZ, its IMEI, that kind of stuff. And then on the backhand side, just like an MSC would do it in the circuit switch world, it can ask the HLR and AUC to provide authentication information for performing the cryptographic authentication, which is then performed here. And then on the map interface here to the HLR, we see the location update request, insert subscriber, and so on. So really, if you know how an MSC behaves in a circuit switch network, just replace MSC with SGSN and most of the time things are pretty much the same. The next thing is session management, which establishes and maintains the tunnels to external packet data networks. So they don't talk about tunnels. Everybody, I guess, in this room knows what an IP tunnel, a VPN tunnel, and so on is, but most people don't know what is a PDP context. It's exactly the same thing, it's just that they use a different name. And of course, it has to start with P. So it's a PDP context, and it's not related to PDP 11. You can have multiple of these contexts active at any point in time. So actually, it's not that your phone can only have one connection to the public internet, but you can have a number of different tunnels, possibly terminating in different IP networks. It doesn't have to be the internet. I mean, there are many other options available. For example, the companies that operate M2M devices over GPRS, they quite often have their own tunnel endpoint, their own GGSN. And so the IP data doesn't end up in the internet, but it ends up directly in their own IP network, which is not a public network. The resolution of where do you connect to, which tunnel broker, which is called GGSN, do you use is done by the APN, the access point name. The mapping from access point names to IP addresses of the GGSN is done by using DNS, and they have private DNS zones, which are accessible only to the GSM operators for resolving those names and IP addresses. And then the tunnel establishment is passed to that particular GGSN. If you look at that procedure, you have a channel establishment and so on and so on, and you see something called a PDP context activation request, which is a phone saying, I want to have an IP tunnel established now. The GGSN will then make a DNS query on the APN that was specified by the phone, so like internet.eplus. whatever or something like that. There will be a response to that DNS, hopefully, the request, and then the GGSN establishes a GTPC connection to the GGSN and forwards that context activation request, and it will be acknowledged, hopefully the acknowledgment will be forwarded and then from that point on, he actually exchanged IP packets between the GGSN and your phone. This GTP protocol is once again specified in one of these fancy specs and 29.060. It's the only protocol at that time which was specified over IP networks right from the beginning. The idea was that the GGSN is an pure IP device. It doesn't have to have E1 connections. It doesn't have to have an SS7 stack. It doesn't have to have any of these fancy things. That's why Cisco built one of them. Because, you know, they wanted the IP network vendors, the router and switch makers to be able to build these devices. GTPC, the control side is used for this interface, and it's not used to be used in intranets or interoperator links that are private anyway. It might not be always the case, but at least that's how it was intended to be used. So far for GPRS, let's move into more current technologies. UMTS packet switched systems. The higher layers like GMM and SM are actually reused from GPRS. There's no change on them. This is like the circuit switch domain. Also the core control, for example, that existed in GSM is reused one by one in UMTS. But all the other layers below, they're really very different. Most of the, like the SGSN remains the same. The GGSN remains completely the same. But anything that relates to the radio access layer, to the BTSs and so on is not only different, but it's also called completely different. So there's no BTS, there's a note B, there's no BSC, there's an RNC. So all these things, the mobile phone is no longer the MS, it's now the MT. So it looks a little bit like this, at least if you use graphics that are available online. You have note Bs, these are your individual cells, which are connected over a link called IUB to the RNC, the radio network controller, which then connects to the SGSN here over an interface called IUPS, the IU interface for packet switched PS services. If we look at the protocol stacking, we will see some names that at least sound familiar like MAC and RLC. They are different in implementation though, would have been too easy. We see a new protocol called RRC, the Radio Resource Control. On top of that, we again have familiar names, GMM and SM are just the same. On the bottom half, we have lots of new stuff that comes in because it's now ATM and not frame relay or E1. Or it might be E1 physically below the ATM, but at least not frame relay. So you have all these adaption layers, if you've heard about AL2 and AL5, some people may be old enough to still have learned that in university. These are all adaption layers, how you can encapsulate stuff on top of ATM cells and ATM virtual circuits below. This is again the only radio interface that's specified and you can see again the node B doesn't really do anything. It just passes stuff on to the wired interface here and to IUB to the RNC, which is what used to be the BSC in older networks, where MAC, RLC and RLC layers terminate. RRC is translated into a different protocol on the same lever called RANAP, the Radio Access Network application part. And then RANAP is forwarded over SS7 actually, so you can see here MTP3B for wideband ATM links with SCCP on top or alternatively using an IP and ATM and then a SIGTRAN kind of stack up here. So RANAP goes back to the STSN, where also again SM and GMM terminate and the remaining part is just the same like in GPS. If you look at the user plane, there is one new protocol also, it's the PDCP, the packet data convergence protocol I guess, and then again you encapsulate your higher level protocols inside the PDCP protocol. MAC layers are specified in some specs, they have fancy numbers. The RLC takes care of encryption, so the encryption is one level lower than in the GPS networks, also takes care of segmentation, retransmission and so on. Interestingly, the RLC layer is not specified in any formal syntax, which in UMTS at least is very uncommon, so it's just like an IETFRFC for common protocols you find on the internet where there's a human readable description but not a formal syntax that describes the messages. However, the next higher layer, the RLC layer is again specified but not in CSN1, this time they switch to ASN1 and use packed encoding rules, P, R, in order to avoid the overhead that B, R or D, R would bring with itself. RLC itself takes care of measurement control, ciphering control, paging, radio barrier management, so which channels to use and so on, broadcasting system information and also has integrity checking. The RLC corresponds to the RR layer on GPRS. The PDCP is the replacement for SNDCP, not quite sure, they could have used SNDCP, I don't really see much difference between those protocols but they just are different and have a different name. It handles user data payload and header compression, there's a new compression scheme ROHC that GPRS doesn't do, it's robust header compression, it allows you not only to compress the TCP and the IP header but also RTP, so it's optimized for doing voice over IP so you can compress away not only RTP, UDP and IP headers and get rid of some of the overhead involved. It's between the user IP, the PDCP is between the user IP and RLC, if you look at this, it's here in that layer, it's immediately what comes below your IP messages. The RANAP protocol is between the RNC and the SGSN, it's again specified in ASN1, also uses PR encoding, never visible to the user, however the Vodafone UK and Alcatel Loos and Femtocells use RANAP also to the Femtocell, so if you're into looking at those devices you will find RANAP in there. There's also something called NBAP, the Node B application part which then is between the RNC and the Node B, again specified in ASN1, again not visible, however there are some Node Bs that sometimes you can buy from eBay and if you buy a real Node B then you will have to implement that protocol to talk to it versus RANAP which you need on the Femtocells. It's actually quite funny, I wouldn't have thought that a year or two ago that you can buy large UMDS base stations now on eBay but it's not horribly expensive, so sometimes it's like €1500 or something, it's not cheap but if you consider that from this BTS you can serve something like 240 concurrent voice calls or something, it's quite impressive actually to find those devices. They often come from places like Singapore or Russia or the United States, not sure in continental Europe you don't see that many being sold. Okay, the GTP layer between SGS and GTSN is the same as in GPRS, there's no real change, some new information elements or something but that's really it, there's no change at that point. Now if we look into HSPA plus the problem is if you go to the data rates that I have indicated like these 180 megabits theoretical maximum for a single base station the bottleneck of course becomes the SGSN because it's a centralized node where all the user traffic goes to, because the SGSN takes care of the compression, decompression, encryption, decryption, retransmissions and so on. I think the fast that I've seen you can buy is 40 gigabits throughput but most of them are actually smaller and if you think about a network like a nationwide network in Germany has about 20 to 30 thousand cells and well if you think each of them would have a load of 20 megabits or something like that you will see that this is not sufficient. So HSPA plus change in a way that they move basically move a small SGSN into each node B and then they talk GTP directly to the GGSN which is not even on that picture. So they move core network functionality out to the edge of the network in order to distribute the load that's created by those high bandwidths. So the segmentation compression encryption is no longer on a centralized node but it's at the base station at the edge of a network that's a fairly significant change to the centralized architecture that we had before. Okay, well that's sort of my quick run through the various protocol stacks. As you can see there are many acronyms on the slides that I didn't even mention and there's many more things that could be said and that can be learned and there's more than a thousand PDF files which each hundreds to thousands of pages which are ready for you to read. And I encourage everyone to go where most people have not gone yet, which is to look at cellular protocols and learn about technology and play with technology and not just leave it to Nokia Siemens Networks Ericsson and Huawei to do that for you. Okay, thanks for the attention. We have some time left for questions. Okay, so we have about exactly 15 minutes for Q&A. Please all of you remain seated while we are doing the Q&A session because it interrupts the speaker and the rest of the audience who wants to listen. If you have questions, please line up at the two microphones as always and Harold will answer your question. Hello. A couple of points. You said that everything is ATM all the way to the Note B and everything but in my experience at least new installations will definitely use IP all the way to make it even more complex than it is in the diagrams. Nevertheless, there are still a lot of equipment out there that runs on ATMs that are more expensive and bad. I'm not sure if that's a bit dated or what. It is indeed correct that more current equipment is replacing ATM with Ethernet over fiber optics out there that runs on ATMs and it depends a bit on the region. If you think of western Europe and the US I think the synchronous networks are more expensive but if you think of the less developed world then they actually they want the TDM style networks still even today they don't want anything else. Two more points. I don't know if you use that term but terminating the GTPU in the RNC and I mean that's something that's been implemented as well so it doesn't always go through the SGSN or the mini SGSN in Note B. Yes, that's correct. I did not claim that this presentation is a full comprehensive overview about all the possible configurations and networks but definitely there are options that you can do for configuring networks differently. There are always vendor specific changes. The reference architecture described by the specifications is not always followed to the last line by the individual vendors. Even in GPRS the PCU can be located inside the BTS or inside the BSC and you can do it with that and different vendors have different implementations but go ahead please. Just one funny note on the GTPC protocol you said it doesn't have any authentication but there is the one bit that says it's cool. I checked with the HLR I am allowed to connect the evil bit. I wouldn't call that authentication but yes it's a nice point to raise that there is a bit that says thank you. Harald, thank you for your talk. A question. Why is this so bloated? So much bloated because it's so error prone so if they started to make they could have said okay let's do a new network that is very simple and would work and it's not so error prone because if you have all these layers and they have bugs in the layers and maybe some range checking problems between the layers and the conversation encapsulation stuff like that for example you could embed the protocol inside the protocol and then if you un-encapsulate it you get the rest of the protocol and you can fast up everything. If you for example make a fake protocol in the lower layers and put it in the upper layer and then it starts to the onion so the layers so it puts the layers around away and then it says oh there is something on the protocol that should be there and then you can fast this stuff. I think the number one wrong assumption to make is that these systems are designed to be reasonable or to be efficient. The number one design criteria is every one of the industry representatives needs to make sure that all the patterns they hold apply to the specification and they want to add something to the spec that makes sure that their own patent portfolio is represented in the spec. The next thing is that there is reasonable grounds to the suspicion that it's made artificially complex in order to keep new market entrants and new competitors away because you have this existing club of manufacturers for equipment and it's like five or six companies worldwide and that would mean every random Joe would be able to implement this stuff and that's sort of of course it's very useful to have a complex system where only you with your thousands of engineers that know this stuff in and out can actually implement it quickly and you keep the competition away so that's sort of thoughts that I would want to give as a feedback on that. Which brings me to my question are you aware of any open source project that's working to implement 3G, something like OpenBSC, but for 3G? Well the simple excuse from my side would be as soon as you write it but more seriously speaking for the GGSN there is an implementation but that's very far away. If you look at the things here I'm not aware of anyone having done any open source implementations here. There are a couple of people who did some work with femtocells but it's not really in a way for operating femtocells it's more for doing men in the middle attacks and that kind of stuff. We did some also in the OsmoCom project we did some experimentation with all the major femtocell architectures that we found but it's mainly a question of priorities and available developer time. Definitely it would be very helpful for somebody to work on those things but it takes time it's complex and we need more people working on this. Okay, thanks. What about LTE? Will the complexity be more different? Different. But they do the bold fucking stacks and pick and everything stacked over each other they do the same. So let me say one thing all the things that I've talked to do not show you the complexity in layer 1. Layer 1 is more complex than any of the diagrams on here. It's the radio layer after the phone and layer 1 of 3G is already complex but I think LTE is less complex also it uses less how can I say less industry specific or uncommon coming from the internet background LTE is not using so many protocols that are completely unknown to people who have some non-mobile network experience. So it's more IP based and it doesn't do all this E1 and ATM and so on crap from the beginning but nonetheless then if you look at the security for example in LTE all the different keys and certificates and everything involved it's already that is again fairly complex complexity in different areas maybe. What about test benches? So all these providers need test benches to test their equipment and so it would be a huge room of vectors and states that you cannot test. So it would be so complicated that you cannot test the system and so you get so many bugs that go through maybe 10 years undetected and so if you do all these complex systems you will always fall over the bugs. Indeed it's a problem that starts to get recognized now but still I think there's no specification anywhere neither from the 3PGPP nor from the GSMA nor from individual operators that I would be aware of which would require something like the most simple fast testing of any of these interfaces before delivering a product. So requirements-wise the requirements are always functional requirements. It has to work if everything is correct and if the message comes in like this but there's never a specification that requires stability no matter what kind of random crap you throw at it that doesn't exist and it's sort of a bit difficult. Dita and I we have been in contact with a number of operators to do such kind of tests and some operators are actually open in us that they want to do that but they get a lot of pressure from the equipment manufacturers to not do it. So there is that enormous enormous pressure on some of those operators to not do any of this testing on those interfaces which makes me quite suspicious. Okay, we have 5 minutes left so we're going to take some questions from ISC. Wutang wants to know how hard would it be to host a man-in-the-middle attack with a fake base station like an MC catcher for GPRS? Sorry I didn't understand the question but I just repeated. How hard would it be to host a man-in-the-middle attack with a fake base station like an MC catcher for GPRS? So an MC catcher is not more difficult than in GSM because it's the same authentication and it's only one way authentication in GPRS as well. Doing a full man-in-the-middle attack is more complicated because authentication is how realistic do you want to be? A full man-in-the-middle attack means that you're sitting in between the real network and the telephone and you're passing data from left to right and you're eavesdropping or you're modifying the content or something like that. That's relatively hard given the fact that none of the GPRS encryption algorithms so far have been publicly released, disclosed or anything like that so it's completely unknown so far. But I would make the point that it's not required to do that because most people just access the Internet so it's sufficient if you set up a false base station and you route the packets to the Internet like a false Wi-Fi access point or something like that and that's very easy to set up. Another question what is the overhead added to IP, TCP or HTTP in UMTS or GPRS? No, that's very, very hard to say because there are so many first of all on which interface on UU, IUB, IUPS and so on and so on, there are many different interfaces and the next part is that it's difficult to say because there's compression involved and the question is how well can you compress the data or not so it's not easy to say but especially in GPRS the overhead is fairly large. If you think of something like doing VoIP over GPRS or Edge and you have very, very small messages with your speech codec data and then all these headers pushed in front of it the overhead is gigantic. Thanks for your presentation looking at this from the user's perspective I would do dial up using PPP most of the time which actually is the only protocol I'm missing on this slide is PPP actually used inside the network or is it only something I talk to my modem? It depends so a PDCP or a SNDCP those encapsulation protocols they have the capability of encapsulating either PPP or IP directly when you request the PDP context activation from your modem if you do that by by IT commands then you can actually request which one you want to have on a regular user interface of course you cannot, I would expect most of the connections to just use IP and the PDP that you speak is terminated on the phone itself but if not if the PDP is passed in here then you have an additional layer below here which is PDP and it goes all the way to the GGSN which then would decapsulate you don't need PPP for anything really because IP address for example IPCP kind of options for assigning dynamic addresses can be done by PDCP actually is done by the session management itself and you can also encapsulate IPv6 directly in SNDCP or PDCP you don't need PPP really at that point it would just add some more overhead I don't see what would be the gain unless of course you would want to do something like Apple Talk over PPP over GPRS would it be possible to put some very weird protocols so not IP for example put ISDN over UMTS or do maybe maybe some what sort of ARCNET over UMTS would it be possible or is it a problem? technically it's possible however you would have to control both the mobile station and the GGSN and while it is possible as a business it is possible to get your own GGSN attached to operators if you want to for example as the example I mentioned you don't want to go to the real internet but you want to go to your own private network it's possible to get a connection to this but it's very expensive and not really done in many cases so technically yes but I think as a regular user it's not feasible for economic reasons it's an open source GGSN so you could do some weird stuff yes, there is open GGSN which you could modify but the phone you would also have to modify and you would have to attach to that interface which in a real network you cannot easily do one last quick question how many cryptographic algorithms which are secret are still there in GPRS and UMTS? in UMTS none it's all specified in GPRS there is GEA1 and GEA2 GPRS encryption algorithm 1 and 2 so I think it's those two that's really it for encryption authentication there are more unknown algorithms but how can I say it's unknown doesn't mean it's unknown to everybody we're a little bit under pressure we have to stop here for the next talk I think we have a small announcement to make but first of all let's thank Harald so just come up here