From holger at freyther.de Wed Jan 1 16:31:21 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 1 Jan 2014 17:31:21 +0100 Subject: 30C3 aftermath In-Reply-To: <20131231143937.GN13435@nataraja.gnumonks.org> References: <20131231143937.GN13435@nataraja.gnumonks.org> Message-ID: <20140101163121.GA15836@xiaoyu.lan> On Tue, Dec 31, 2013 at 03:39:37PM +0100, Harald Welte wrote: > As I wasn't involved myself, I am not too exhausted to already think > about improvements for future events (31C3, ...) Daniel and me started to prepare a report for this years event. From laforge at gnumonks.org Wed Jan 1 18:49:42 2014 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 1 Jan 2014 19:49:42 +0100 Subject: OsmoDevCon 2014 / Date / Venue In-Reply-To: <20131105155825.GK12353@nataraja.gnumonks.org> References: <20131105155825.GK12353@nataraja.gnumonks.org> Message-ID: <20140101184942.GM7022@nataraja.gnumonks.org> Dear all, as the December 31st registration deadline has just passed, I'm happy to announce that all 17 requests for participation have been approved. We are still below the ~20 people limit of the venue. What we now need to do is to fill the schedule with talks / discussions. Please add your suggestions to https://openbsc.osmocom.org/trac/wiki/OsmoDevCon2014 even if it is just a topic you would like to discuss about, and not something that anyone feels compelled to hold a formal presentation about. Looking forward to seeing you in ~ 2 months in Berlin, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Wed Jan 1 18:46:37 2014 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 1 Jan 2014 19:46:37 +0100 Subject: 30C3 aftermath In-Reply-To: References: <20131231143937.GN13435@nataraja.gnumonks.org> Message-ID: <20140101184637.GL7022@nataraja.gnumonks.org> On Tue, Dec 31, 2013 at 08:13:15PM +0100, Sylvain Munaut wrote: > I think that although it'd be a nice hack, other solutions could be > better and handle more use case : > - Use of TCH/H with AMR-HR Ah yes, I forgot that this hadn't been used yet. > - Smaller cell > - Multi TRX ok, let's see what we can do on those two fronts. > Also, there isn't PoE everywhere. This years they had quite a variety > of switches, some with PoE, some with PoE+ and some with nothing so > each time we either need to find power or we'd need to put injectors > (which requires access to the patch room which would need more NOC > coordination and even then AFAICT some of them are only accessible > with the help of CCH staff). Ok. My information was outdated then, while some of the last two years the indication always was: All ports have PoE support. In any case, for a single sysmoBTS 1002 without external PA/LNA, we can clearly fit into the classic 15W PoE scheme and have no need for PoE+. > I also wouldn't bother with nanoBTS at all, we haven't used them this > year at all and it was really stable on day 2,3,4 once we fixed that > nasty SMS bug. Agreed. The nanoBTS was just in the box packed for 30C3 as it was still in there from 29C3 ;) > I also think multi-TRX could be fun (possibly using fairwaves HW), but > we can run out of ARFCN easily. I was thinking of ARFCN re-use. If the transmit power is low and we have ultra-low-radius cells, then we should be able to have a frequency re-use pattern. Of course not among immediate neighbors, but with one in between. Also, I don't think that 8 ARFCN is all we could get from the regulatory authority. I remember the DECT guard band being slightly wider than that. > It would be nice if we could sync the L1 of the BTS and use "shared > ARFCN" where for eg one TS is used by one BTS and another for another > BTS (dynamically of course so the capacity self-adapts). I think that's unrealistic and requires a lot of effort on all layers, including the BSC who currently has no view at all about that. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Wed Jan 1 21:44:02 2014 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Thu, 2 Jan 2014 01:44:02 +0400 Subject: 30C3 aftermath In-Reply-To: <20140101184637.GL7022@nataraja.gnumonks.org> References: <20131231143937.GN13435@nataraja.gnumonks.org> <20140101184637.GL7022@nataraja.gnumonks.org> Message-ID: On Wed, Jan 1, 2014 at 10:46 PM, Harald Welte wrote: > On Tue, Dec 31, 2013 at 08:13:15PM +0100, Sylvain Munaut wrote: >> I also think multi-TRX could be fun (possibly using fairwaves HW), but >> we can run out of ARFCN easily. > > I was thinking of ARFCN re-use. If the transmit power is low and we > have ultra-low-radius cells, then we should be able to have a frequency > re-use pattern. Of course not among immediate neighbors, but with one > in between. Also, I don't think that 8 ARFCN is all we could get from > the regulatory authority. I remember the DECT guard band being slightly > wider than that. We could also try to use adjacent ARFCNs for non-adjacent cells to increase frequency re-use. Compared to re-using the same ARFCNs, it requires less distance between interfering cells. Back side of the medal is that this setup requires very good Rx selectivity from the BTS equipment, as it could be easily jammed by close MS's, working with another BTS. So this will require very detailed frequency planning and probably some experimentation on the ground. >> It would be nice if we could sync the L1 of the BTS and use "shared >> ARFCN" where for eg one TS is used by one BTS and another for another >> BTS (dynamically of course so the capacity self-adapts). > > I think that's unrealistic and requires a lot of effort on all layers, > including the BSC who currently has no view at all about that. That's almost a shared OFDMA :) But I don't see how this could increase capacity, as number of available TSs will stay the same. AFAICT, it would even decrease capacity. Lets say we re-use TSs on ARFCN A. If we used it for a single cell, it would have interference radius of this cell. But if we try to share it with an adjacent cell, we'll have interference radius of these two cells, while number of available TSs stays the same. This may make sense only for better load balancing between cells on secondary ARFCNs. But this is possible only for multi-ARFCN BTSs, like our UmTRX based ones. Also a degree of such balancing can be done for multi-ARFCN BTSs on a more rough per-ARFCN basis instead of per-TS basis. I.e. one BTS can claim a whole ARFCN. This will also require changes to the BSC, but they seem smaller to me. OTOH, similar balancing can be achieved with the frequency hopping. This will lead to gradual decease of quality as the system becomes more and more loaded, though. Good thing is that the frequency hopping can be enabled even for single-ARFCN BTSs. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From 246tnt at gmail.com Thu Jan 2 00:32:09 2014 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 2 Jan 2014 01:32:09 +0100 Subject: 30C3 aftermath In-Reply-To: References: <20131231143937.GN13435@nataraja.gnumonks.org> <20140101184637.GL7022@nataraja.gnumonks.org> Message-ID: Hi, >>> It would be nice if we could sync the L1 of the BTS and use "shared >>> ARFCN" where for eg one TS is used by one BTS and another for another >>> BTS (dynamically of course so the capacity self-adapts). >> >> I think that's unrealistic and requires a lot of effort on all layers, >> including the BSC who currently has no view at all about that. The BSC part is almost trivial. Syncing the L1 is the nearly impossible part ... > But I don't see how this could increase capacity, as number of > available TSs will stay the same. It doesn't increase it in absolute terms, but allows to dynamically allocate the capacity. And it's definitely used in real networks, because my local network does it ... with 16 ARFCNs shared for traffic between all the local BTSs. Like, as soon as there is a talk in german in one of the hall, the bts serving that hall gets a lot more traffic than when If the allocation of TCH is static, then each hall needs the capacity to handle peak traffic, which may mean 2 ARFCN for each hall (and being right next to each other, you'd need at least 4 ARFCN to cover the 3 halls, assuming re-use between the two most distant ones). Now if you go with a 1 ARFCN + 1 shared ARFCN per hall, you can handle the same peaks in each hall with (2 + 1 ARFCN) ... > OTOH, similar balancing can be achieved with the frequency hopping. ??? What does frequency hopping do for load balancing ??? Cheers, Sylvain From ralph at schmid.xxx Thu Jan 2 11:57:20 2014 From: ralph at schmid.xxx (Ralph A. Schmid, dk5ras) Date: Thu, 2 Jan 2014 12:57:20 +0100 Subject: 30C3 aftermath In-Reply-To: <20131231143937.GN13435@nataraja.gnumonks.org> References: <20131231143937.GN13435@nataraja.gnumonks.org> Message-ID: <000201cf07b1$e0e036b0$a2a0a410$@schmid.xxx> Hi, > If we make smaller cells, this would mean that the BTSs would be > * PoE powered > * have no PA/LNA > * operate with reduced tx power (20mW?) and high rxlev_access_min > * use directly attached small rubber antennas I can confirm that this works just fine for GSM1800 with its 95 MHz spacing between up and down. This is the way I am using my USRP1 with WBX TRX board, about 50mW out. The antennae (I am using some cheap dlock commercial UMTS/LTE antennae) must be in 90 degree angle, "rabbit ear" style, otherwise about 20 dB are lost in the RX by desensing / overload, so it is only usable when no one can touch and rearrange the antennae, and when there is some space around them, to avoid increased RX/TX coupling. My setup can easily cover up to 200 m range on LOS, it is great for covering one up to maybe three rooms in a building. The house I live in, four story building, is 100% covered (I live on the 2nd floor, third in US counting style), and abt. 100 m up and down the road still connection is possible. > Regards, > Harald Ralph. From alexander.chemeris at gmail.com Thu Jan 2 12:48:58 2014 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Thu, 2 Jan 2014 16:48:58 +0400 Subject: 30C3 aftermath In-Reply-To: References: <20131231143937.GN13435@nataraja.gnumonks.org> <20140101184637.GL7022@nataraja.gnumonks.org>

Message-ID: On Thu, Jan 2, 2014 at 4:32 AM, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > >>>> It would be nice if we could sync the L1 of the BTS and use "shared >>>> ARFCN" where for eg one TS is used by one BTS and another for another >>>> BTS (dynamically of course so the capacity self-adapts). >>> >>> I think that's unrealistic and requires a lot of effort on all layers, >>> including the BSC who currently has no view at all about that. > > The BSC part is almost trivial. > > Syncing the L1 is the nearly impossible part ... This can be done when a GPS signal is available, but we're in-building, so I tend to agree that this is too hard to do. >> But I don't see how this could increase capacity, as number of >> available TSs will stay the same. > > It doesn't increase it in absolute terms, but allows to dynamically > allocate the capacity. > And it's definitely used in real networks, because my local network > does it ... with 16 ARFCNs shared for traffic between all the local > BTSs. > > Like, as soon as there is a talk in german in one of the hall, the bts > serving that hall gets a lot more traffic than when > If the allocation of TCH is static, then each hall needs the capacity > to handle peak traffic, which may mean 2 ARFCN for each hall (and > being right next to each other, you'd need at least 4 ARFCN to cover > the 3 halls, assuming re-use between the two most distant ones). Now > if you go with a 1 ARFCN + 1 shared ARFCN per hall, you can handle the > same peaks in each hall with (2 + 1 ARFCN) ... For this usecase I think we're fine with the rough granularity sharing, i.e. sharing on ARFCN level instead of TS level. Btw, one thing we'll have to take care is to "pack" existing calls into the non-shared ARFCNs when a shared ARFCN is to be moved to another BTS. Should not be a big problem, though - just a bunch of intra-BTS handovers. >> OTOH, similar balancing can be achieved with the frequency hopping. > > ??? What does frequency hopping do for load balancing ??? This is a poor man's load balancing solution. Supposedly it's used in real life network planning. The idea is that we can deliberately share some ARFCN between two closely located frequency-hopping cells. Then, if both cells are loaded and use those ARFCNs, signal will be degraded due to interference. But if one cell is under-loaded and other is fully loaded, then those ARFCNs will be used by the loaded cell with little to no quality degradation. This is based on the fact, that frequency hopping is following a pseudo-random pattern. Thus if two calls share 1 ARFCN out of N, it'll lead to "some" degradation of quality, which might be tolerable, as we have good quality coverage at the CCH. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From ralph at schmid.xxx Thu Jan 2 19:10:29 2014 From: ralph at schmid.xxx (Ralph A. Schmid, dk5ras) Date: Thu, 2 Jan 2014 20:10:29 +0100 Subject: 30C3 aftermath In-Reply-To: References: <20131231143937.GN13435@nataraja.gnumonks.org> <20140101184637.GL7022@nataraja.gnumonks.org>

Message-ID: <000901cf07ee$4d2a1c50$e77e54f0$@schmid.xxx> Hi, > This can be done when a GPS signal is available, but we're in-building, so I tend to agree that this is too hard to do. Should be easy to have a wired (off the shelf) or wireless (maybe has to be built) clock distribution. > The idea is that we can deliberately share some ARFCN between two closely located frequency-hopping cells. Then, if both cells are loaded > and use those ARFCNs, signal will be degraded due to interference. But if one cell is under-loaded and other is fully loaded, then those > ARFCNs will be used by the loaded cell with little to no quality degradation. In commercial installations it is even accepted that sometimes a burst gets lost. So capacity is increase by deliberately allowing collisions between the most distant stations, as usually FM suppression effect is good enough to avoid the collision. > This is based on the fact, that frequency hopping is following a pseudo-random pattern. Thus if two calls share 1 ARFCN out of N, it'll lead > to "some" degradation of quality, which might be tolerable, as we have good quality coverage at the CCH. Yep. > -- > Regards, > Alexander Chemeris. > CEO, Fairwaves LLC / ??? ??????? > http://fairwaves.ru Ralph. From andreas at eversberg.eu Fri Jan 3 17:20:54 2014 From: andreas at eversberg.eu (Andreas Eversberg) Date: Fri, 03 Jan 2014 18:20:54 +0100 Subject: 30C3 aftermath In-Reply-To: <20131231143937.GN13435@nataraja.gnumonks.org> References: <20131231143937.GN13435@nataraja.gnumonks.org> Message-ID: <52C6F176.9080100@eversberg.eu> Harald Welte wrote: > I did some brainstorming with Peter and Holger about the idea to assign > all phones interested in listening to the audio stream to the same TCH / > timeslot on any given BTS. This is highly experimental and > non-standard, but I think we can make it work by using late assignment > and ignoring the 100% bit errors in uplink. hi harald, looks like voice broadcast service for phones that don't support it :) let me think about it... first the phone is assigned to SDCCH, so we get informations about dialed number (audio broadcast number). then the BSC triggers assignment to the "shared" TCH. now the phone suspends layer 2 connection on SDCCH locally and resumes layer 2 connection on the TCH, to send the assignment complete message. as we need to ignore the uplink (many phones can be assigned to the same TCH), we need to send one UA frame to make the phone think that we received the SABM frame, which we didn't. (hopefully the phone receives that UA frame.) also we need to send one or several RR frames to make the phone think that we received the ASSIGNMENT COMPLETE message, which we also didn't. we send more UA and RR frames when new phones join the shared TCH. this will result in small audio gaps, which might not be a real problem. this all works until a phone tries to hangup or sends a keypad message. the layer 2 would run into timeout, because there is no RR frame with increased sequence number that acknowledges the hangup or keypad message. i see no problems with timing advance, since we don't care about uplink. when we use a fixed TA value of 3 (ordered on SACCH), we do not get any problem with interference of next timeslot, as long as the phone's distance is not above about 3km. but i see a big problem with layer 2: if a phone receives another UA (because another phone joins the TCH), it would run into an MDL_ERROR (unsolicitated UA response), that causes the RR layer of the phone to abort the connection. i have no solution to prevent this (yet). this is why i think it will not work. regards, andreas