 So there's the topic load-based handover. Again, if you would like to follow the slides there, so you're also linked on the pre-talks for later reference. And I'll get the cable out of the way here. So just very quickly, I would like to go through the simple handover process just to clarify what is going on. So the MS, the phone is connected to a BTS, and the BTS knows what its neighbors are. So it's a config item in OsmoBSC. It says, I have this and that neighbor on this cell. And this neighbor gets sent to the phone by system information. And then the phone continuously monitors the RXLEV, meaning the receive levels of the neighbor cells of that cell that it's currently on. And the current cell also has the receive quality and the timing advance information. And so when a call is ongoing or whenever a channel is in active use, every so often measurement report gets sent. So at the beginning I was kind of confused like what is MI's rep, but it just means measurement report, which goes back to the BSE and the BSE can basically decide then what to do. Say the measurement report says the BTS2 is much better than the BTS1 in receive levels, then the BSE might say, here I have a channel available on BTS2 telling the phone to hand over to the other BTS. The phone would send a RATCH, which would be detected. The BSE would then conclude the handover, release the old channel and complete on the news. So this is simplified, left out some stuff. But basically then the phone is on the other BTS and will again get the neighbor lists from that BTS and it could continue from there. So that's the basic building block of handover. So the proper handover, if you have a distributed network, means that you should on each BTS configure its specific neighbors so that if a phone is at this cell, it knows which other neighbors it can easily hand over to. It's also connected to identifying the cells with RHCN and BSEC numbers that have a quite limited range. But the automatic, like the default behavior of automatic neighbors in awesome BSE is just every cell that we know is listed as a neighbor. So you can technically hand over to any other cell. That would obviously break into large networks, but that's the default thing to do. And so again, the BSE is free to gather any information that it likes. RXLEV, the quality, the timing advance, meaning the distance of the current call and whatever it knows about the neighbors and tells the phone to hand over to a different cell. Now the key thing here is we could take any information into account. So that's a huge topic we can, I don't know, depending on whether it's Christmas or not, but you know you can invent anything. Now the really useful thing is that like when you have a handover because of an RXLEV to another cell, then you go to the other cell and then suddenly the say the RX quality is bad and then you decide to hand over again and go back to the first cell and then the RXLEV is bad again and then you go back to the second cell, you oscillate the handover, stuff like this can happen quite easily. And also what you obviously want is to balance the load of your BTSs, which is what this talk is all about. So what we so far didn't do and also we see is take into consideration whether the other cell BTS2 is already full. We would just try to allocate a logical channel and if we got one then there we go. So in the end we might hand over a subscriber to a BTS and fill it up completely and then leave the others completely empty even though their receive levels weren't that far off the first one to begin with. So that's where the handover decision 2 comes into play. When Harold implemented the first handover it was already structured into do the handover and decide whether to do the handover. So we had the handover decision.c and Jolly actually a while back implemented an improved handover algorithm. We call it handover decision 2 and just like handover 1 it takes the receive levels quality, timing advance and interference into account. By the way interference is basically defined as you've got good reception levels but bad quality. But it also takes into account the congestion of other cells and once you did a handover or you did a handover and it didn't work there are penalty timers involved so we try to prevent oscillation between cells. And another thing the decision 2 takes into account is the voice codec. So for example if we're on TCHH and the quality is a bit low it would try to go to TCHF if there are free channels like tweak the codecs so that interference doesn't have that bad effects and would even assign within the same cell like a handover within one BTS. And yeah so what do I have here? That's where I based my work on the openbsc.git Jolly handover branch and it's sort of an old tradition now last year I talked about the dynamic time slots was it last year I think yes that was also work by Jolly that I took over and handover is just the same and the load based handover so I forward ported it to OSMOBSC quite recently and there were some breakages in handover that have been fixed like in OSMO BTS we didn't send the system information properly so often the phones would actually stop sending measurement reports for no apparent reason but now we're in the position to get measurement reports reliably and properly tested and well that's where the work is sitting now and ironically I'm now mostly working on inter-BSC handover and not the load based handover even though that needs some more attention actually. So let's just look at the tweaked or the new handover config because that tells you a lot about how this stuff works so this is like on the network level in the VTY this is the basic configuration is handover allowed or don't allow it zero it's handover is switched off and one is it is switched on and then you can decide which algorithm that's the new part the handover 01 existed before and another new thing recently added is you have a global configuration of handover but you also have the same configuration items on each BTS level so basically if a BTS has no handover config it uses the global config but as soon as a BTS also has handover config that applies for that BTS so basically I could say handover 01 on the network level handover is enabled everywhere and then I select handover algorithm 02 everywhere but on some say BTS05 I want the old or the simpler handover algorithm so then on BTS05 I pick handover algorithm 01 and only that BTS would behave differently from the network config is this for phones which are handing over from the BTS or to the BTS or both? Well it's mostly where the phone is at now like it depends like in handover decision 02 when you want to not congest the target cell it would obviously look at the target cells minimum desired free channels sort of like I mean in terms of this configuration so like for example if you have one base station and all its neighbor one base station is enabled handover and all its neighbors have disabled handover will it handover two BTS with disabled handover for example? That's a detailed question I think I'm not sure but I think we are not handovering two cells that have handover switched off but the default idea is like look at the cell where the phone is right now and some few config items we look at the target cell that we would handover to but basically if you are on BTS05 and handover is enabled then we would try to handover but let me check later on whether we handover cells that have handover disabled I think we don't so Paus said it would make sense to have handover from handover to but I don't know I think it makes sense the way it's right now if we have practical concerns we can certainly change it but before we had just one global config enable handover anywhere and have the same parameters anywhere at least now we can configure each cell based on its location and so on What does handover default do? It's the same as saying handover 0 or handover 1 It's a bit confusing I think So this is the same code working on the network and the BTS level and the default means default the default value if you look at the help it will always tell you the default I think the default for handover enabled is 0 so it's off and the default algorithm I think still is 1 so the idea is assume that you have configured the network level then you can go to the BTS level and say handover algorithm 2 and then if you want to go back to the network level then you can say handover algorithm default and then it will remove the setting of the BTS level doesn't make sense so there are default values and then on the network level you can set manual values and to remove the manual settings you can go to default again and the BTS would first look on the network level and the network level would then go look and the factory defaults the default defaults and this applies to all the config items that come from now on except one which I may remember to point out later so this is the handover the config we had all the time it's like how large is the receive level averaging window like how many values do we average to decide on well to have a value to decide with same how large is the window to average over our X quality and then that's both for the current cell and then the same for the receive level of the neighbor cells so that's just by how how large is the end by which I divide to average and then power budget interval and hysteresis that means how many I think satchels do I weight before I calculate the power budget and then the hysteresis is again like if I switch to one cell I want to obviously keep a distance before I switch back so if like you know it's the common hysteresis use case like you don't just have a threshold value you keep a distance before you switch back it's not really that important here now and then the maximum distance that's about the TA the timing advance like how large may the value become before I hand over it simply because it's too far away from you know and the handover too has the same plus some more stuff here it does also switch on assignment or not within the same cell this TDMA measurement I'm not really that familiar with but kind of it selects I don't know let's look it up later it also employs some minimum receive level and receive quality like if I'm in a cell and another cell is better than the cell I'm in but I'm still above this minimum level then don't bother to hand over I'm good enough you know why hand over why congest the hand over then the AFS bias is about so the AMR or AFS codec works better than the normal I don't know what is it EFR what so if we can hand over to such an LCHAN we prefer it so we just put a little bias on it even though the RX level is what 10 then say but if it's going to go to AFS then let's make it 12 so it comes in a bit better and we prefer that so that's a kind of a little tweak and then the min 3 slots is about congestion looking at it I had a bit of a different idea but the way it is now is that for each BTS or for all BTS I can say okay I want to have at least say 3 TCHH unoccupied and as soon as there are only 2 free then we would start to try and hand over to a different cell to again reach this 3 free LCHANs so this works for TCHF and TCHH separately then the next thing would be max handovers like how many handovers do I allow for a certain period of time I'm actually not sure about the period of time I think it's about how many handovers are currently active right now so if I set this to max handovers 5 and 5 LCHANs are already busy handing over I think it's even intended on across the entire BSE might have to revisit that one but the point is that you know I don't try to hand over everyone back and forth let's first finish a few handovers then look at the load situation again and only then start handovering again then the penalty times like when I went too far away of a cell and hand over to a different one let's wait a little few seconds before allowing handover again same for if handover failed don't retry right again and then failed assignment assignments just handover within the same cell then retries again is well okay if it failed don't retry but retry like three times and only then wait until you retry again it's like another little tweak into penalty timers and this last one is the one that is only existing on the network level is the congestion check timer which is configured globally the default is 10 seconds and the now is just if you want to trigger it manually for basically for me for debugging so that's a a lot of stuff there that is not present in the handover algorithm one and so here was I just dumped the documentation in case there were questions maybe we can have a look at the TDMA here power budget interval stronger neighbor oh shit I forgot when I click it goes back to the next slide let me see if I can search here no ah come on javascript stuff what happened now oh my god there you go right I can use I remember I can use this so where is the TDMA this is handover one handover two afs bias should be on the top so what does it say not much yeah what does it speak for yeah this should refer to measurement report handling in the BSC there are two modes of doing this you can either take all measurements or you can take a subset but I don't remember why is this Harold probably knows more about this this relates to DTX discontinuous transmission because if DTX is enabled there are only some bursts which are guaranteed to happen all the time and if no voice is being spoken then basically the silence detector in the voice encoder will detect that and there will be no bursts transmitted so of course if you do measurement averaging on those slots where the phone doesn't transmit anything you will get ridiculously high bit error rate so if you have DTX enabled on a channel then you can only look at the sub values for handover related measurements and if DTX is disabled you can look at the full values that's basically the difference so I don't really think it makes sense to have this manually configured but it should be automatically based on whether or not DTX is enabled on the L channel at the given time otherwise I don't understand why let's say you don't have DTX but then you restrict your measurements on some certain slots on the subset why if you have the other slots and you know there are valid bursts in uplink why not use them for the decision another question there I just have a suggestion that I might push as a patch to replace default with inherit inherit but then on the network level you inherit from the default so the network level maybe maybe a special case but for clarity I think that makes maybe some sense in my head the network level would be the default and then above that there would be another default but if you guys prefer that we can always change it of course yeah we can have an alias even better but then we would bike shed on which one we write back on the writing back the config file excellent and then you can set that policy back to default or to inherit perfect I think we call it inherent at some point then inherent default so here what I mentioned is the value that is going to be used on doing default or inherit is always shown in the bty config so on the bts level it would if I had a manual config on the network level it would also show them also show the manual config help me out here and there was an interesting instance that got me so I looked twice here on this one so in the bty to separate a range we use the dash now of course we also use the dash for negative numbers so this is actually negative 110 to negative 50 so it's not yeah it's not subtract 50 from 100 or something like that so I actually did deliberate tests in my bty test to ensure that this works as intended and it actually it does right so how is the time it's over okay so there were some test cases this is a really nice one I think I'm not going to go through the entire one but Jolly when he implemented it he invented this kind of testing script and this is interesting to note like this test case 23 is a neighbor is your friend and it goes something like this Andreas is driving along the coast on a sunny June afternoon suddenly he's getting a call from his friend and neighbor Axel Axel asks Andreas if you would like to join them for a barbecue Axel's house is right in the neighborhood and the weather is fine Andreas agrees so he drives so close to buy some tofu some halloumi cheese and so then here goes the real test while he's driving a different cell on the top of the store becomes better but inside the store the cell tower on top of the store has really bad reception so it goes back to the distant cell and going back outside the door it goes back to the cell on the store and then he goes back to his friend his friend Andreas and says Andreas wonders why he still has good radio coverage last time it was so bad and Axel says I installed a pico cell in my house now we can use our mobile phones down here at the lake and in my imagination at that point their mothers and girlfriends call and they both toss their phones in the water to have silence again so actually we could build a text adventure from this right a ussd an interaction right there you go so this is actually an interesting more interesting test case is like here we have a full rate codec and we would hand over but the other cell is congested so it has less than the configured three slots so that's something the handover algorithm the handover decision one wouldn't do and well what's the test doing it makes it creates two bts's it says I want in cell one I want four free tchf at all times and then it sends a measurement report that says well my current cell is rx left 20 the rx crawl is left out of the test but the other cell has much better rx quality but still we're not handing over and then as soon as I reconfigure the other target bts to have to want only three free tchf and I get another measurement report then okay oh then the algorithm sees we don't congest and then we hand over there's a big discussion behind that a theoretical one on whether you should prefer to hand over or to prefer to take in new calls so in literature a book I read from I got from Harold it actually says you should rather favor hand over because that's an ongoing call and you should not take up a new call and for that drop a call that is ongoing to ensure better radio service but anyway this is up to configuration with the settings we had before and what's this so this one shows you that when we're on tchf we might go and change the call to tchh if the tchf on the target cell is congested just to show a landscape of what the new hand over algorithm is capable of so what's really still missing is the work I did earlier from Jolli's branch the dynamic time slots isn't properly integrated with hand over decision 2 yet so far this hand over decision assumes a time slot has one it's either tchf or tchh and with dynamic time slots of course we could dynamically switch and this is not part I haven't looked into how to incorporate it in the best way and of course we need tests and I'm also implementing the inter-BSC hand over at the moment which is also interesting because that intermingles like before we used the BTS numbers to hand over a decide and now we suddenly also have RFCN and BISIC of remote BSS cells that we need to translate to location area codes and it becomes very interesting and intricate go on talking but my time is over any measurement reports my question is is it possible to manually trigger hand over from VTI or control interface yeah that's basically the first thing I implement when I try to test it I even have a hand over any command so I got tired of typing the time slot all the time so I have my test phone there or two of them and I just type hand over any and it picks the first voice call it finds and hand over it to the first three BTS it finds thanks but what if the base station you are going to hand over is has disabled hand over is it possible to enforce hand over there well this one if you disabled hand over that's in the hand over decision algorithm the hand over code that performs the hand over is not affected by that so if you are if you're on the VTI then basically you are the hand over decision and if you say hand over this to that cell then it's going to do it and you can't disable that really but you can configure the hand over algorithm to do what you want so I remember it's on yeah I remember talking about this some time ago and asking people nicely to do it and it's amazing to see it there thanks but the use case I'm thinking of there's a lot of different parameters to control hand over and I'm just trying to in my head figure out how you would do it when you want to only load balance you don't care about rx levels yeah so the current config is basically this min free slots like so that will just take precedence over equal well if I were inventing it now I think I would come up with more like a weighted approach not this is sort of a hard barrier of I want two free slots and if I have less than two free slots if I have more than two free slots I don't care I would not even bother to balance and but as soon as I have less than two slots well I would never populate the last slot until everything is full sort of I would more like favor like balance it out with the receive levels but you know it's I think it's very simple actually yeah say again yes you're free to implement hand over algorithms I was even thinking of you know if we have multiple msc's or even between multiple bsc's coordinate those hand overs it would even make sense to have some you know external interface that has a central database that's on a different page yeah so the other thing I wasn't clear about this AFS and AMR more or less synonymous there or what is AFS I tend to be okay right so you get a faster bit faster bit rate and supposedly better quality okay yeah just on the AR it doesn't full AFS and AHS does not necessarily convert into the quality because on AFS which is a full rate time slot you still could have the lowest possible AMR mode so AMR modes which specify the quality actually are separate the separate configuration so there is a certain mode of AMR which allowed on both full rate and half rate basically fit into the half rate so it could be used on both and above some mode only full rate is possible for those AMR modes but this is unrelated to hand over one other one other observation I had which is just an interesting thing to know is that apparently the configuration of neighbors is only a suggestion to a phone so phone can actually build its own neighbor list from various sources so for example it can remember other other RFKNs it saw before and add them to the neighbor list and still measure them I was surprised by this when I significantly reduced neighbor measurements on a network and then I still saw that phone is measuring other RFKNs it wasn't supposed to so that's and then I like googled and found that phone can build its own neighbor list from various sources not only from what from what I remember of the top of my head is that when we receive measurements we actually index it in the neighbor list like we don't actually the phone doesn't really send the RFCN it just sends the index in the neighbor list but I'm not really sure about that I thought I had read something like that in the code so maybe we can look at your point I read that it is possible to if it's possible there's a difficulty there because also just recently I within even the same BSE sell a BSEC could get reused even on the same RFCN so if a phone decides by itself who is the neighbors then it could bring up a situation where it's requesting an RFCN in BSEC that it sees over here and the BSE thinks it's the other one over there and so it should be allowed to do by the phone because the BSEC has to have the prime say on who is the neighbor of who okay time so then hand over command to whoever head over detected okay hand over complete